The Hidden Curriculum of Design Work

How to uncover the real need behind vague feedback — and choose the right way to respond

Why the question a client asks is rarely the only question you need to answer

Most of the friction I run into as a freelance designer doesn’t come from difficult clients. It comes from vague feedback — not because clients are being unreasonable, but because they often don’t have the vocabulary to name what’s actually bothering them.

A client will say “can you make the header pop more?” What they may actually mean is closer to: the hierarchy still doesn’t feel convincing, but I don’t have the vocabulary to diagnose why. Answering the literal request — bigger, bolder, more contrast — sometimes fixes nothing, because the real issue was never the header’s size.

I’ve learned that the fix isn’t always “ask better clarifying questions.” Sometimes the faster move is to change the format of the answer entirely.

Often, the vocabulary gap is the problem — not the client. A lot of what reads as vague feedback is someone sensing that something’s off without having the design language to point at it.

Asking more questions isn’t always the fastest response. For clients who think visually, walking them through what I’d change in words is often slower and less convincing than just showing them. A conversation asks them to picture a change they may not have the vocabulary to describe; a visual makes it concrete instead.

So instead of describing it, I test it. I’ll put together a couple of variations built off the main design — not nine throwaway directions, just enough branches off the core layout to make the difference visible — or do a rough, fast rearrangement of components that are already grouped together. It takes minutes, and it closes the vocabulary gap faster than more conversation would.

It has a name, sort of

I’ve started thinking of this as part of work’s hidden curriculum — a term I first came across in education research. Philip Jackson coined it in 1968 to describe the unspoken norms schools teach alongside math and reading. Some writers have since borrowed the phrase for workplace expectations: there’s the job in your offer letter, and then there’s an unwritten second job of navigating expectations nobody actually trains you for.

I’m using it loosely here rather than as a precise academic category, but the frame fits design work particularly well — nobody hands you a syllabus for reading a client’s real question. You mostly learn it project by project.

The pattern shows up with everyone, not just clients

The larger pattern also appears with developers, although the information gap is different. A client lacks the vocabulary to diagnose a design problem. A developer asking “what’s the spec for this state?” doesn’t need reassurance or exploration — they need exact implementation details. Hand them the vibe instead of the exact values, and you’ve just created three more Slack messages and a delay. Same designer, same underlying skill, but a completely different decision sitting behind the question each time.

There’s a real risk on the other side of this too, though. The goal isn’t to confidently invent a story about what someone “really” means and answer that instead of what they asked — that creates a different problem, because it reads as not having listened at all. Staying provisional works better: acknowledge what was actually asked, then make your read visible before acting on it.

“I think the issue may be the hierarchy rather than the header size — let me show you two quick variations so we can test that”

That does both at once: it names the hypothesis and moves straight into the format that actually resolves it, instead of asking the client to verbally confirm a design problem they may not have the vocabulary for in the first place.

The curse of knowledge explains part of the problem: designers can forget which context exists only in their own heads. That’s how a developer gets three sentences of rationale instead of the one value they need. But not every mismatch is a knowledge problem. Sometimes the other person is looking for reassurance, confidence, or help making a decision — not more information at all.

A rough framework, if you want one

1. Ask what decision the other person needs to make, then make your read visible. A client asking for another revision may be deciding whether the direction is fundamentally wrong. Acknowledge what they asked for, then briefly name the concern you think may be underneath it and propose a way to test it.
2. Match the format to the person, not just the depth. When the right format is unclear, ask. When showing is faster than explaining, test it directly.
3. Save it for when it matters. This is a tool for real stakes — deadlines, trust, a design direction that keeps bouncing back — not something to deploy on every small ask.

What changed for me

What stands out, looking back, is that the mistake was never a skill gap. It was a guessing gap — assuming I knew how much translation someone needed instead of checking. Once I started treating how I presented the work as its own design decision — not an afterthought to the real work — client conversations got shorter, and the work stopped bouncing back and forth as much.