Photo by Bob Brewer on Unsplash
Working within or alongside government, you’re constantly exposed to policy language that you need to understand well enough to effectively collaborate, build context, and deliver the work expected of you. As a human-centered design (HCD) practitioner, you bring yet another language to the conversation. “Wireframe,” “information architecture,” and “cognitive load” casually roll off your tongue between sips of coffee during the first meeting of the day, but your policy and other non-HCD colleagues might not catch what you’re trying to communicate.
HCD terms are jargon, even when they feel universal to us. Non-HCD colleagues likely don’t speak your design language or might use their own working definitions of design terminology based on previous experience. Circular debates about definitions, derailed working sessions, deliverables misaligned with expectations, and a lot of frustration are bound to happen.
When people misunderstand each other, it’s easy to think of it as a people problem rooted in poor communication skills, lack of subject-matter training, or stubbornness. However, the challenge of HCDers using a language that stakeholders may find unfamiliar is really a system problem. Disparate vocabulary systems are being used to create one end product—a productive working relationship. A possible solution is consolidating into one vocabulary system, which is indeed a long-term, uphill strategy, but there are ways you can work with or even bypass the language differences so your project can move forward with more clarity today.
First and foremost, translating your stakeholders’ words into clear design requirements is a core part of HCD work. When stakeholders use terms that may not be clear to everyone, it’s your responsibility to pause and engage with stakeholders to engineer clarity. There’s no way to escape it. It’s incredibly rare to go through a project without asking, “What did you mean by ___?” Fuzzy terms must be focused into concrete actions.
Some stakeholders may be resistant to this questioning—feeling challenged or at a loss for how to better articulate what they want. Address this explicitly: “I’d like to help us turn these ideas into specific design decisions that meet your needs. Asking questions can help me do that.” It reframes your expertise as facilitation rather than an interrogation.
It can be tiring to constantly act as translator, but eventually you and your stakeholders will be using more unified language and collaborating more smoothly. The process of translation will become practiced and expected.
When a stakeholder uses an HCD term and your translator (or detective) hat is on, make sure the questions you’re asking are specific to the topic of conversation. The better questions you ask, the more straightforward, actionable answers you’ll likely get.
Instead of “What do you mean by that?” try “When you say 'dashboard,' what are you picturing users doing there?”
If they say, “It’s just an MVP, so it doesn’t need much UX,” try “Which user actions need to work really well so we can learn from them?” You can get to an MVP with quality UX without continuing to use those terms in your conversation.
The best way to forgo misunderstandings about terminology is to avoid it altogether by describing rather than naming.
For example, instead of “interaction,” say, “When a user clicks ‘Submit,’ they will immediately see a confirmation.” Replace “user journey” with “the path from landing on the site to successfully renewing enrollment.”
Swap “increase usability” with “reduce the number of times someone has to re-enter information.” “Fidelity” becomes “level of detail.”
Descriptive language makes misunderstanding harder and shifts focus from terminology to user behavior.
When a client says, “Make it more intuitive,” “This needs better UX,” or “We just want some research,” they’re probably expressing a feeling like lack of trust in design decisions, pointing to a business risk like user adoption, remembering another interface they either loved or loathed, or leaning into ambiguity when requirements are vague.
Try to get to the actual problem the stakeholder wants to solve in using these terms:
Terms are often used as proxies for outcomes. “What kind of signal from users would mean this feature is successful?” could be a good follow-up to “We just want some research.”
Definitions invite debate, while examples invite alignment. Something tangible to react to moves conversations forward faster than theoretical accuracy.
Instead of saying, “That’s not what a persona is,” you could show two versions of audience documentation, such as one that supports marketing segmentation and one that supports design decision-making. Then, recommend which version (or parts) is more appropriate for the stakeholder’s needs and ask about any concerns with that direction. Maybe they don’t need personas (as designers know them) at all! Another kind of documentation might be more appropriate, even if stakeholders continue to call them “personas.”
Instead of arguing about “fidelity,” show a low-detail screen to test structure and a high-detail screen to test visual hierarchy. Before-and-after screens, this-vs-that comparisons, and annotated examples from stakeholders’ own products reduce abstraction and ensure that you and the stakeholder see the same thing regardless of which words are used.
Recognize and abandon your assumptions. Unless you’re 100% confident that stakeholders have a shared understanding of terms like “mockup” or “content strategy” and you feel that you absolutely must use a term, define exactly what you mean the first time you use it in any setting.
What seems common knowledge to you, fellow seasoned HCDer, could be completely new to someone else or could conflict with their existing, alternative understanding of it. Defining terms in the moment gives people a chance to learn or refresh their memory: “When I say ‘empty state,’ I mean [short, descriptive explanation].” It also helps uncover what kind of language misalignment you’re working with if stakeholders speak up in disagreement.
When defining a term, make it relevant to the design at hand rather than an abstraction. For example, if you say “workflow,” clarify that you mean the step-by-step path a user takes to complete a task, such as submitting a government form from start to confirmation on their website. Being repetitive is also part of the process, as different stakeholders might be in different rooms.
Glossaries can seem pedantic, but a source of truth for the meanings of HCD terms is nice to have in your toolbox to build language alignment.
Create a glossary of HCD terms that your HCD team and non-HCD stakeholders often use. Base it on industry references, such as Nielsen Norman Group and companies/organizations with established HCD practices. No need to reinvent the wheel, so a simple copy-paste, light editing for succinctness, and a link to the source will do. Include visual examples and store the glossary in a place accessible to anyone you work with.
Provide a link to the glossary in places your stakeholders care about, like project briefs and Figma files sent for review. Announce to stakeholders just once that it exists. Then expect everyone to forget about it. That’s okay!
The glossary is a living resource you can employ when you need to use HCD jargon. For example, during a presentation in which you advocate for an accessibility check, you can reference the glossary to recite a short definition of accessibility, link to the glossary entry on the relevant slide, move on with the presentation, and paste the definition in an appendix slide.
In another scenario, you recommend low-fidelity designs before jumping to the high-fidelity ones stakeholders asked for, and during the conversation, you bring up visual examples from the glossary to help stakeholders see the difference as you describe the value of your recommended approach. It’s these small educational moments where clarity is built without being heavy-handed.
Misused terms usually don’t need to be corrected.
Ask yourself: “Will this phrasing cause us to design the wrong thing or just call it the wrong name behind the scenes?” This redirects the conversation from vocabulary to outcomes. (Externally-facing terminology is a separate topic altogether.)
If a stakeholder says, “Add this to the persona” but means “Document this user need somewhere,” and the outcome isn’t affected, let it go. Momentum matters more than debating terminology, and correctness isn’t the same as effectiveness. As long as you and stakeholders have reached a shared understanding, the exact words used are less consequential.
If they say, “We already have research,” and describe a handful of user feedback from 3 years ago, respond with “That’s helpful context. For design decisions, I’ll also ask users about what they’re trying to accomplish and what slows them down.” Keep momentum and practice empathy.
Nothing undermines a system faster than inconsistency. Align on the same definitions and strategic approaches to language between research, content, and design practitioners on your HCD team.
Over time, your organization will develop a stronger HCD vocabulary because your team has modeled one consistently.
In government environments where trust and risk assessment are foundational, smoothly navigating terminology differences between HCD and non-HCD stakeholders goes a long way in progressing meaningful work.
There is a balance to reach between being a translator and a gentle teacher. Effort towards both is needed to get everyone on the same page and enable a project to move forward while building HCD maturity within your organization.
When a stakeholder doesn’t speak the language of design, the goal is to co-create a working understanding that supports better design decisions and better outcomes for the public.
As a principal product manager at A1M, I’ve helped a variety of federal Medicaid programs improve service delivery with better products, user support, communications, and team collaboration.
We are dedicated to creating simple, sustainable solutions. Learn more about our Services.
