A few years back, I was on a call with a support client — an independent energy firm upgrading their aging CMS. I talked through content modeling improvements — taxonomy automation, meta description fields, IA concerns for their rebrand — while their IT manager clicked through a screenshare of the back-end of the site. It was a standard engagement: a client had asked us for help, and we were providing that help through helpful consulting.
Or so we thought. We were deep in conversation when something caught my eye on the screenshare. The IT manager — clearly more comfortable with internal systems and security than a traditional content management system — had forgotten he was sharing his screen. We watched as he opened Microsoft Word, typed the word "content,” and asked Word for thesaurus suggestions.
The implication was immediate: he didn’t know what the word “content” meant.
At the time, we thought this was a funny moment in an otherwise unremarkable consulting call. We laughed about it for a bit, and then eventually we realized this client wasn’t a great fit for us. We considered it a vetting failure and moved on.
But it kept coming back to me. We laughed a bit and shook our heads, yet in that moment — a moment when he was legitimately confused by the conversation, and actively looking to improve — he wasn't at fault at all. What did we expect? It isn’t his world.
It’s ours. And it’s our responsibility to demystify it.
Web Work is Mystical, and That’s Our Problem
I've spent my career in content strategy, which means I've spent my career translating between practitioners and the people we serve. And here’s what I've learned working alongside developers for two decades: the development process is mystical, magical, and completely confusing to anyone who isn’t involved day-to-day. We as web workers struggle to balance the line between deep domain knowledge and plain language communication, and developers are maybe some of the worst offenders.
I say this with love and with zero blame. Developers work in systems that are necessarily and legitimately complex. Developers are solving real technical problems. The words we use — migration, environment, deployment, repository, API endpoint — these words have specific meanings that matter to the work we do, and the complexity in what we do cannot be “dumbed down” from developer to developer.
But here's the uncomfortable truth: when we say "we need to migrate the database schema," your client hears "we need to do a scary expensive thing that might break everything and I don't understand why we're doing it."
Which is to say: we can't just blame clients for not understanding. We have to meet them where they are.
The Four Things That Matter
Demystification isn't a deliverable. It's not something you can hand over. It's a lens through which you approach all of your work. And while it's impossible to create a perfect checklist, everything really falls into four categories:
- Context - Helping others understand how our work fits into their existing mental models
- Translation - Helping others understand what we mean when we say certain things
- Involvement - Helping someone feel like they're part of what we’re doing
- Trust - Being open, honest, and trustworthy in the work you do
Let me break these down with the kinds of situations we often encounter.
Context: It's Their Process, Not Yours
As web professionals, we love to explain work in terms of our own processes. "We'll set up the development environment, then staging, then push to production after UAT." Great! Our team understands what’s next! Except … our client just heard a string of words that mean nothing to them.
While some of this is a translation issue — and we’ll touch on that in a second — mostly it’s an issue of context. It’s an issue of understanding how any of this fits into a client or stakeholder’s day-to-day.
So it’s on us to try explaining complexity in terms of their process — to help them understand the why and the what as it pertains to what they’ll interact with day-to-day: "We'll build the new features in a safe space where we can test without affecting your live site. Then we'll move it to a preview environment where your team can review it and make sure it works the way you need. Once everyone's confident, we'll move it to your actual website."
Same technical work. Completely different framing.
Seems simple, but there’s one question that always comes up: How deep do we go? How much do we explain?
The answer is annoyingly simple, and comes in three parts:
- We need to be clear about what each stage requires and how it fits with the next, AND…
- …how our work fits with their larger process, AND…
- …how our process exists within the context of their business.
For example: "We're rebuilding your authentication system because the current one creates security vulnerabilities and makes it hard to add new features you've asked for. This work will take three weeks. During the second week, we'll need about two hours from your IT security person to review our approach. This won't affect your users during development, but we'll need to schedule a maintenance window for the deployment."
You've just given them: what you're doing, why you're doing it, how long it takes, what you need from them, and what the impact will be. That's context.
Translation: Align Around Common Terminology
Every industry has jargon. Jargon isn't inherently bad — it's precise language that helps practitioners communicate efficiently. But jargon becomes a problem when it creates a wall between our team and the people we’re working with.
I once worked on a project where I was asked to deliver a "use model." I'd never heard the term. But instead of asking what they meant, I just nodded and figured I'd look it up later — and, at that time, I determined it was just another name for something we were already providing.
At least, that’s what I thought at the time. Three months in, this client asked where the use model was. Realizing I had not actually provided what they had intended, I promised it by end of week and then frantically tried to understand what they actually wanted. Eventually, I needed to swallow my pride and let them know that I had no idea what they were asking for. I had misunderstood the deliverable, because there was no standard definition within our industry: what they wanted was a map of how content supported different user journey stages, which I had misinterpreted as a user journey in and of itself.
Anyway, we adjusted and created a use model to what they expected. We still use it today, and we still call it a use model.
The lesson isn't that I should have known the term. The lesson is that I should have asked.
When we say "we need to refactor the codebase," does our client know what that means? When we say "technical debt," are our stakeholders picturing the same thing we are? When we mention "backwards compatibility," have we explained why it matters to them?
We don't need everyone to agree on common terminology. But we DO need to align around common terminology. And the easiest way to do this is simple: when we use a technical term, provide enough context that someone who doesn't know it can understand it. For example: "We need to refactor some of the backend code — basically, we're reorganizing how it's structured so it's easier to maintain and add features to. The functionality stays the same for users, but it makes our work more efficient and reduces the chance of bugs."
Now we’re all on the same page.
Involvement: What You Actually Need From Them
This is where things get tricky, because we as web professionals often underestimate how anxiety-inducing the technical process is for clients, even more so with development — an often completely foreign language stuck inside an impenetrable black box. So, the best thing we can do is invite them inside the black box.
Not to write code! Not to critique process! Simply to give them a view from the surgery theater — an open dialog that includes your clients and stakeholders. We need to be clear from the start about what's expected, what we’ll need, and how we’ll use it. It sounds like basic project management (and it probably is!) but it's also pretty difficult, because we often don't know how much access our clients need until we’ve hit a problem.
That's okay. You don't need to outline every aspect of your work. But the big things? You should have those figured out.
Give them logical time to review and provide feedback. Help them understand the many weeks it might take to migrate certain data. Get them the information they need as early as possible. Outline your needs for their involvement early so they can judge their ability to even take it on.
And here's something that matters more than you think: meet them halfway on tools. If they use Teams and you use Slack, sometimes you just open Teams. If they can't access Figma, you send them PDFs. Every moment of tool-based friction leads to frustration, and frustration leads to disengagement.
Should you be annoyed about using the wrong tool? Sure. But you know who else is probably annoyed? The people you're working with. They don't love it either. Being flexible builds goodwill. Being rigid builds walls.
Trust: Following Through on What You Say
Everything we've touched on to this point has been focused on welcoming clients and stakeholders into our world — the world of the web; of complexity and grey areas, of specialization and nuance. It's been about a foundation of inclusion, and it's all done in the name of one thing: trust. Without trust, nothing else works. And trust comes from three things: consistency, predictability, and accountability.
Consistency means showing up the same way, every time. Using the terminology you've established. Following the processes you've outlined. Maintaining the same standards for communication and delivery. When you tell a client you'll send updates every Friday, you send updates every Friday. When you establish a code review process, you follow it. Clients need to know that the version of you they get today is the same one they'll get next week.
Predictability means helping clients know what to expect and when to expect it.
Now, I want to be clear: predictability does not mean rigidity. It does not mean having everything perfectly set up at the start. But it does mean setting up the idea of change as a regular and predictable part of the process.
For example, early in my career, I was afraid to onboard new clients because I was still figuring things out. I was nervous I'd discover a better method halfway through and have to spring it on them, effectively admitting I had no idea what I was doing.
But, instead of being scared to adapt, I adjusted the model. I positioned work through a flexible system of results rather than rigid deliverables. Onboarding became less about specific outputs and more about what we're going to accomplish — while still giving clients a map of what to expect.
Communication around predictability is, essentially, communication around intent. “Our plan is to rebuild the API integration with your CRM. We'll start with the authentication layer, and depending on what we discover about the current data structure, we may need to add some data cleanup work. We'll have a better sense of that timeline once we're into the authentication work, and if additional scope is needed, we can revisit the timeline together."
You've given them predictability: here's what we're doing, here's what might change, here's when we'll know more, and here's how we'll handle adjustments.
Accountability means owning your work and your words. It means being honest about what you know and what you're still figuring out. It means when you make a mistake, you acknowledge it and fix it. It means being clear about expectations from the start — the words you'll use, the meetings you'll hold, the deliverables you'll provide — and then actually following through.
This is how trust is built: through consistency in how you work, predictability in what comes next, and accountability in everything you say and do.
The Point
We work on a lot of projects, which means we encounter a lot of people who simply do not understand what we do. Some of them will be frustrating. Some will make you want to slack your coworkers and laugh. Some of them are just trying their best and hoping we’ll let them catch up.
With every one of these examples, though, it’s important to understand the relationship between a skilled practitioner and those who depend on them. Like a mechanic explaining a repair, or a plumber explaining next steps, our clients are not experts in what we do. Of course they aren’t — that’s why they hired us.
More importantly: it's not their job to understand your world. It's your job to make your world understandable.
Listen. Be patient. Explain things in their terms, not yours. Build trust through consistency. And remember that the person searching for synonyms for "content" in Microsoft Word isn't the problem.
We are. And it’s on us to bridge that gap.
