There's a moment I love in client conversations. You've been trying to explain something technical, and you can see they're being polite but not following. Then you say "it's kind of like..." and give them an analogy, and their face changes. "Oh! Okay, now I get it."
That moment is worth chasing. A good analogy or a quick sketch can do in ten seconds what ten minutes of verbal explanation couldn't. For those of us who work in technical or abstract fields, these are some of the most powerful tools we have.
Why this works
The human brain doesn't process new information in a vacuum. It processes it by connecting it to things it already knows. That's what analogies do: they give someone a familiar structure to hang unfamiliar ideas on. "Authentication tokens work like hotel key cards" lands instantly because people know how hotel key cards work.
Visuals work for a similar reason. When you sketch boxes and arrows on a whiteboard, you're taking something invisible (data flow, system architecture, user journeys) and making it literally visible. People can see relationships, spot gaps, ask better questions.
When you rely only on verbal explanation for complex things, misunderstandings hide beneath polite nodding. Clients leave meetings thinking they understood, then realize later they didn't. Analogies and visuals catch those gaps in real time.
How to think about analogies
Use what they already know. The best analogies come from the client's world, not yours. For an e-commerce client, use shopping and retail analogies. For a healthcare client, use patient flow. For anyone, restaurants and buildings tend to work because everyone has experienced them.
Keep it simple and acknowledge the limits. No analogy maps perfectly. That's fine. Just say so: "This analogy breaks down when it comes to [X], but the core idea holds." Pretending an analogy is more precise than it is leads to confusion later.
Have two or three ready for your common topics. If you explain authentication every few months, develop a go-to analogy and test it with different people until you find one that consistently lands. I use the hotel key card one for authentication and the restaurant one for system architecture because they just work.
How to think about visuals
Simplicity is a feature. A rough sketch with five boxes and three arrows beats a polished diagram with fifty boxes and a hundred arrows. The goal is clarity, not comprehensiveness. If someone can't understand your diagram in 30 seconds, it has too much on it.
Sketch while you talk. This is underrated. Drawing in real time, narrating as you go ("so the user starts here, clicks this, which sends a request here..."), creates shared understanding in a way that pre-made slides rarely do. It also invites the client to jump in and add to it.
Match the visual to the purpose. Diagrams for showing relationships. Flowcharts for processes. Side-by-side comparisons for before/after. Simple numbered lists for steps. Don't use a complex diagram when a numbered list would do.
What good looks like
The system architecture analogy
Client asks: "How do all these parts work together?"
"Think of it like a restaurant. The website is the dining room where customers interact. The API is the waiter, carrying orders between the dining room and the kitchen. The database is the kitchen, where all the ingredients are stored and dishes are prepared. And the backend services are the individual kitchen stations: one handles orders, one manages inventory, one processes payments. Each has a specific job, and they communicate through the waiters."
Why It Works
Everyone knows restaurants. The roles map cleanly. And it naturally extends: "When we add a mobile app, that's like adding a drive-through window. Same kitchen, different way to order."
The real-time sketch
During a user flow discussion, you draw on a whiteboard or shared screen:
"So the user starts here [draw box: Homepage], clicks this [arrow to Products], filters by category [branch], adds to cart [box: Cart], checks out here [box: Checkout], payment happens here [box: Payment], confirmation here [box: Done].
Where do you see friction? Where should we add something?"
Why It Works
Everyone can literally see the flow. It invites collaboration. The client can point to a specific box and say "this is where we lose people" instead of trying to describe it verbally.
The data relationship diagram
```
[Customer] ---has many---> [Orders]
| |
has one contains
| |
v v
[Profile] [Order Items]
```
"Each customer can have many orders, but only one profile. Each order contains multiple items. This structure means we never duplicate information."
Why It Works
A complex database concept explained visually in five lines. No jargon needed. Clear relationships at a glance.
The before/after comparison
Side-by-side diagrams:
Before: current process with 8 steps, including 3 manual handoffs that each take 1-2 days.
After: proposed process with 4 steps, automated handoffs.
"Right now, information passes through three manual handoffs, each taking 1-2 days. With the integration, those become instant. Total process time drops from 7-10 days to 2-3."
Why It Works
The visual makes the improvement tangible. Numbers quantify it. You don't need to explain the technical details of the automation because the diagram tells the story.
The authentication analogy
"Authentication works like a hotel key card system. When you log in, you get a token, like checking in and getting a key card. The card is programmed for your room and your stay. Every time you access something, you tap the card to prove you're authorized. When your session expires, or you log out, the card stops working. The system never needs to check with the front desk again because the card carries the proof."
Why It Works
Maps perfectly to the technical reality. Naturally explains tokens, sessions, expiration, and authorization levels without using any of those terms until the client has the concept.
What bad looks like
The tortured analogy. "The database is like a library, but the books are actually thoughts, and the librarian is a robot, but not a real robot, more like an algorithm..." Stop. If you have to keep qualifying the analogy, it's the wrong analogy.
Using technical concepts to explain technical concepts. "It's like the OSI model's transport layer, or if you know Erlang's actor model..." If they knew those things, they wouldn't need the analogy.
The overwhelming diagram. Forty-seven boxes, dozens of arrows, tiny labels, acronyms with no legend. This doesn't communicate; it intimidates.
The condescending setup. "I know this is hard for you, so let me use a really simple analogy..." The analogy might be great, but you've already insulted them.
The analogy that collapses. Client asks a reasonable follow-up question and the analogy completely falls apart. "Um, well... the analogy doesn't really work there. Forget the restaurant thing." Better to acknowledge limits upfront.
Getting better at this
Build a personal library of analogies. For the concepts you explain regularly, develop two or three different analogies. Test them with different people. Note which ones consistently land. Over time, you'll have a go-to for every common topic.
Practice low-fidelity sketching. You don't need to be an artist. Boxes, circles, arrows, and labels are all you need. Practice sketching while talking until it feels natural. Tools like Excalidraw make this easy even for people who think they can't draw.
Tailor to your audience. An analogy from the client's industry will always land better than a generic one. Manufacturing client? Use production line analogies. Finance client? Use portfolio analogies. The extra thought shows you understand their world.
When an analogy doesn't land, try a different one. "Let me try a different comparison..." is perfectly fine. Having alternatives ready is what separates someone who uses analogies occasionally from someone who uses them well.
Learn basic visual principles. Even simple diagrams benefit from hierarchy (important things bigger), proximity (related things grouped together), and white space (don't cram). These aren't design skills; they're communication skills.
How this connects
Analogies and visuals are the primary tools for explaining complex concepts without condescension. They reduce the need for technical deep-dives by making concepts intuitive. They make status updates more scannable. They make dependency chains visible. They focus group attention in meetings. They turn abstract discussions into concrete ones.
Things to try
- Pick the three concepts you explain most often. Develop one analogy for each this week.
- In your next client meeting, sketch something while explaining. Even a simple box-and-arrow diagram.
- Create one visual diagram of your current project's architecture or workflow.
- After using an analogy, ask: "Did that comparison make sense?" Pay attention to whether they reference it later. That's how you know it stuck.
- Start collecting good analogies when you hear them. Podcasts, articles, conversations. Build a library over time.
A rough whiteboard sketch that creates understanding is worth infinitely more than a polished diagram that confuses. The best analogies aren't clever; they're familiar. When a client's eyes light up and they say "Oh, now I get it," that's the whole point.