Why Your Clients Can’t See the Big Picture (And What To Do About It)
You present an early-stage wireframe, a deliberate structural blueprint, and the first response is: “Can we make that button blue?” It’s the designer’s version of showing someone the floor plan for their house and receiving feedback on the curtains.
This is not a client problem. It is a communication problem. Not everyone can look at a rough sketch and mentally project the finished product. Most people cannot. The real question is not whether clients focus on the wrong details. It is whether we, as designers, set them up to focus on the right ones.
After running design projects through Sans Studio, across brand and product, I have found that the gap between what a designer intends to communicate with a lo-fi deliverable and what the client actually interprets is significant. Most designers present low-fidelity design as show-and-tell. This is a mistake which can lead to poor decisions and unproductive conversations. Closing the gap is itself a design challenge.
The fidelity trap
Low-fidelity work is designed to invite broad, conceptual feedback. Research from the Nielsen Norman Group (NNG) supports this: when a design looks incomplete, stakeholders recognise the work is unfinished and feel more comfortable offering honest, structural critique. People are more willing to challenge a rough sketch than a polished mockup.
However, this only works if the reviewer understands what kind of feedback you are asking for.
Without that framing, low fidelity becomes a liability. Some clients cannot look past the rough appearance. They see grey boxes and placeholder text and conclude you have not done the work. Others fill in the visual gaps themselves — imagining colours, fonts, imagery — and provide feedback on a version of the design that exists only in their head.
Why rough feels wrong
There is a well-studied cognitive bias called the aesthetic-usability effect. First identified by Kurosu and Kashimura (1995), it describes our tendency to perceive attractive things as more functional — even when they are not. Our brains equate beauty with quality. It is a halo effect for design: if it looks good, we assume it works well.
This bias operates at the level of first impressions, often within milliseconds. It works in reverse too. When something looks rough, unfinished, or visually plain, people instinctively downgrade their perception of its quality — including the quality of the thinking behind it.
This is the invisible headwind every designer faces when presenting low-fidelity work. You know the grey boxes represent months of research, information architecture decisions, and careful user journey mapping. However, the client’s brain is pattern-matching against every polished app and website they have encountered. Grey boxes do not match those patterns. So, something must be wrong.
It is not that clients perceive laziness. Their brains are wired to associate visual polish with competence, effort, and trustworthiness. A sketchy wireframe triggers the opposite associations — unfinished, uncertain, not ready — even when the structural thinking is robust.
Consequently, you hear feedback that feels disproportionately emotional for what should be a logical, structural review. Comments like “it doesn’t feel right” or “I’m not sure about this” are often not about layout or flow. They are visceral reactions to the aesthetics of the deliverable, misread as signals about the quality of the work.
As designer Cheryl Platz observes, if something looks near-complete, people are less likely to provide the hard feedback you need. They assume you already know about the structural issues and do not want to offend. Rough work, counterintuitively, is more honest. However, only if you help people past that initial “this looks unfinished” reaction.
You cannot switch off someone’s cognitive wiring. However, you can do two things: explicitly name the gap between how the work looks and the thinking it represents, and create enough context and narrative that the client’s attention shifts from the surface to the substance. Give their brain something else to evaluate.
The real problem: presenting when you should be narrating
The single biggest mistake designers make with low-fidelity work is treating it as a presentation. You share a screen. You show wireframes. You wait for feedback. The client, left to interpret without guidance, gravitates toward whatever is most tangible — which at this stage is usually the wrong thing.
The fix is storytelling.
Instead of showing screens, walk the client through a user journey. Do not say “here’s the dashboard.” Say: “Sarah is a new manager. She has just completed her onboarding assessment. She opens the app and this is what she sees first. Her eye goes here because this is the most important thing we want her to understand at this moment.”
This achieves two things. First, it anchors every piece of feedback in the user’s experience rather than the client’s aesthetic preferences. Second, it gives the client a role in the story — they evaluate whether the journey makes sense, not whether the interface looks good.
Seven things that help
1. Set the rules before you show anything
Before a single wireframe appears on screen, tell the client what they are about to see and what kind of feedback you need. Be explicit:
“What you are about to see is a blueprint, not the building. We are here to discuss whether the rooms are in the right place, not what colour to paint them. The visuals are deliberately rough so we can focus on structure and flow.”
This is not patronising. It is professional. You establish a shared language for the session and give the client permission to think at the right level of abstraction.
2. Make things look deliberately unfinished
There is a subtle but important difference between something that looks rough and something that looks lazy. Tools like Balsamiq, with their hand-drawn aesthetic, signal “this is early” in a way that a clean Figma wireframe does not. When components have a sketchy, marker-pen quality, clients instinctively understand they are looking at thinking-in-progress rather than a near-final deliverable.
If you work in Figma, consider using a lo-fi component kit or hand-drawing key screens to photograph and present. The medium sends a message about the stage of the work.
3. Use real content, not lorem ipsum
This seems contradictory. You want things rough, but the content should be real? Yes. The Interaction Design Foundation (IxDF) makes the case clearly: placeholder text like lorem ipsum is no longer advised because copy and images that differ significantly from your placeholders will affect the final user experience.
You do not need final copy. You need realistic copy. If a heading reads “Your Progress Overview” instead of “Lorem Ipsum,” the client can evaluate whether the information hierarchy makes sense. The conversation remains about whether the right content is in the right place. This is precisely what this stage should address.
4. Prototype the flow, not the pixels
Even a rough clickable prototype fundamentally changes the quality of feedback. When someone can tap through screens in sequence rather than examining flat layouts, they shift from evaluating what it looks like to evaluating what it feels like to use. This prompts a different thought process entirely.
This does not need to be elaborate. A few linked frames in Figma is sufficient. The goal is to make the experience sequential rather than static.
5. Direct the feedback with specific questions
“What do you think?” is the worst question you can ask at this stage. It is an open invitation to comment on whatever catches the eye — which will inevitably be a visual detail that does not matter yet.
Instead, ask task-oriented questions: “Can you find where you would go to check your team’s progress?” “Does the order of information on this screen match what you would want to see first?” “If you were a new user, would you know what to do next?”
This keeps the conversation structural and functional.
6. Use your research as an anchor
If you have done user research, discovery interviews, or workshops, and you should have, reference those findings as you present. “Remember when three of our test participants said they felt overwhelmed by too many options? That is why we have simplified this to two paths.”
This shifts the authority for design decisions away from personal opinion — yours or the client’s — and toward evidence. It is significantly harder for someone to argue “I don’t like it” when the response is “the users told us this is what they need.”
7. Know when low-fidelity is not enough
Some clients genuinely struggle with abstraction. Not everyone can look at grey boxes and mentally project the finished product. For those clients, a mid-fidelity approach — greyscale but clean, with real layout structure, proper typography scale, and meaningful content — is the better option.
This is not a compromise. It is reading your audience. The goal of any deliverable is to facilitate the right feedback at the right time. If a slightly more polished wireframe achieves that more effectively than a hand-drawn sketch, use it.
Reframing the conversation
The deeper principle here is that presenting design work is itself a design problem. You are designing an experience — the experience of understanding and evaluating a concept that does not fully exist yet. That experience requires the same rigour you would give to any user journey: clear entry points, guided navigation, appropriate context, and a well-defined action at the end.
When a client fixates on details at the wrong stage, it is not because they are difficult. It is because we have not given them the right framework to engage with the work.
The wireframe is not the deliverable. The conversation is.
And like any good design, that conversation works best when it starts with the user.