You Don’t Know What You Know

Last month I tried to teach an AI how I run a design critique.

I’ve run hundreds. I can walk into a room, look at a screen, and give feedback that moves the work forward without detonating the relationship, setting back the timeline, or confusing the question of who made the call. I’ve been doing it long enough that it mostly happens without thinking. So writing the procedure — clear enough that a machine could follow it — should have taken ten minutes.

It took two hours. And the first version was wrong.

Not wrong in a typo sense. Wrong in a you don’t actually know your own process sense. I wrote down what I thought I did. Then I ran it. The AI followed my instructions to the letter and produced generic, surface-level feedback. The kind of feedback I would have frowned at in a real critique. Button contrast could be improved. Consider adding more whitespace between sections. Navigation hierarchy is unclear. All technically accurate. None of it useful.

The problem wasn’t the machine. The problem was me.

In fourth grade, my class had to write instructions clear enough for someone else to follow. My friend wrote about making s’mores — the way a marshmallow moves from golden dust to dark crust, how the texture evolves depending on how long you hold it over the flame. You could see and smell the whole process. I wrote about fishing at the local pond, with PBJ sandwiches. My friend stared at me after he read it. Did I put whole sandwiches on the hook, or mush them onto the line? He questioned my success rate based on how quickly soggy sandwiches dissolve. My instructions only made sense to me because I already knew how to do it. This was my first experience writing for others.

I thought about that a lot when I sat down to describe my critique process in enough detail that a machine could run it. What I’d written down was the surface — the part I’d describe if someone asked what I do. What I’d left out was the logic underneath: the reasoning I’d developed over years that I’d never had to articulate because I’d never had to teach it to something without intuition.

My actual process, when I finally excavated it: I look at a design for thirty seconds without reading any copy, checking whether the visual weight distribution tells me what matters before I process a word. I identify the single most important decision the designer made and evaluate whether the rest of the design supports or undermines it. I check whether the design solves the stated problem or an adjacent easier one — designers frequently solve different problems than the ones they were given, because the real problem is harder. Then I give feedback in order of structural importance: layout before color, flow before polish, decisions before details.

None of that was in my original procedure. I didn’t know it was in my process until the machine’s output forced me to ask: Why is this wrong? What’s missing? What do I do that I didn’t tell it to do?

The machine didn’t teach me how to give feedback. It taught me what my feedback process actually is.

Every experienced designer has a gap between what they practice and what they can explain. You know how to run a critique, but not the decision tree you use to prioritize which feedback to give first. You know a layout feels off, but not always the principle it violates. You know a design system component needs refinement, but the standard you’re holding it against lives somewhere between your training, your taste, and years of accumulated pattern recognition that you’ve never had to name.

This gap is fine when you’re doing the work yourself. Your unconscious expertise carries you. The gap becomes a problem in two situations: when you try to teach someone else, and when you try to teach a machine.

Teaching a junior designer, you can fill the gaps in real time. They ask follow-up questions. You improvise. You point at the screen and say “see how this doesn’t feel right?” and rely on shared visual intuition to close the distance. A machine has no visual intuition. It follows your instructions. If your instructions skip the invisible part, the output reflects exactly what you wrote down: the surface, without the substance.

There’s a concept in psychology called the competence ladder. You move from unconscious incompetence — you don’t know what you don’t know — to conscious incompetence, to conscious competence, and finally to unconscious competence: you do it automatically. Most senior designers live at the top of the ladder. That serves execution. It doesn’t serve improvement, and it makes expertise nearly impossible to transfer. When you can’t see your own process, you can’t improve it, can’t identify which parts are principled and which are habit, can’t separate the conventions you follow because they work from the ones you follow because that’s how you were trained.

Writing your expertise down as a procedure a machine can follow forces you back down the ladder — not to incompetence, but to visibility. You have to see your process again.

After working through this with enough design tasks, a pattern emerged. Designer expertise doesn’t hide randomly. It hides in layers, and they get harder to find the deeper you go.

The first layer is sequencing. You do things in a specific order. The order carries a logic you’ve never had to name. When I’m designing a payment flow, I work out the error states before I finalize the success state — not as cleanup at the end, but before I touch the happy path. Because what the error states reveal is what the product actually does: what happens when a card is declined, when a session times out, when a 3DS challenge interrupts the flow. Design success first and you’re designing an assumption. Design errors first and you’re designing behavior. That sequencing decision is real expertise. It’s also unspoken — until you try to write a step-by-step procedure and realize you’ve never stated it.

The second layer is criteria. The private evaluation standards that are more specific than any principle you’d name, granular enough to actually run a test. One of mine: I won’t approve a form until I’ve designed what happens when every field errors at once — not some, all. Not because that scenario is likely. Because the way a form handles its worst state tells you whether the designer was solving for the user or for the happy path. The principle I’d cite in a design review is “error handling should be clear and recoverable.” The criterion is the test I run. They’re not the same thing. The principle is a value. The criterion is how I find out whether a design meets it. Most designers have dozens of these. They accumulate through experience, which means they can’t be taught directly — only recognized once you try to write them down.

The third layer is the hardest to see, because it isn’t about the task in front of you. It’s about whether the task in front of you is the right task. Senior designers do this constantly and almost never consciously. A designer shows you a settings page redesign. You look at it for thirty seconds and realize the settings page isn’t the problem. The product has too many settings because the defaults are wrong. The redesign will make the page cleaner and fix nothing that matters. You give feedback at the systems level, not the page level.

How do you write that as a step? Michael Polanyi called this tacit knowledge — the things we know that exceed what we can say. This is where that gap is widest. It draws on every related product you’ve shipped, every user behavior you’ve absorbed, every decision you’ve watched succeed or fail. None of that fits in a set of instructions. All of it informs the call you make in thirty seconds when you look at a settings page and know something is wrong before you can say what. You can learn to notice where you make it. Writing the steps is what builds that noticing.

The way product design gets taught hasn’t changed much in ten years. You sit in critiques until you can run one. You watch a senior designer read a stakeholder — absorb the anxiety in the room, redirect it toward something useful — and try to hold onto what they did so you can do it yourself next time. You learn by proximity. You absorb what you can and guess at the rest.

What gets transferred is always partial. What you can observe is what the senior designer can perform in front of you. What stays hidden is the part that lives in the gap between what they do and what they can explain — the sequencing, the criteria, the moment they silently reject the stated problem and solve a different one.

The companies sending “use AI more” Slack messages are running the same play. The mandate assumes exposure creates capability. If you’re near the tool often enough, the skill will emerge. It won’t. Proximity has never been sufficient, and the mechanism that makes it insufficient is exactly the gap this piece is about. What emerges from proximity is a partial transfer of observable behavior. What doesn’t emerge — what has never emerged from proximity alone — is the logic underneath.

What actually changes the transfer problem is the work of making the tacit explicit. Writing a procedure clear enough for a machine to follow. When I paste a transcript of a creative session into Claude, it doesn’t improvise — it follows a procedure I wrote for exactly this task, producing three documents in a specific order for a specific reason: an internal snapshot first, because that’s the raw material; a leadership synthesis second, because it restructures observations into decisions; an agency brief last, because its tone depends on what the synthesis revealed about priority. That sequence was in my process before I wrote it. Writing it was how I found it.

An operations designer on my team ran that brief procedure for the first time during a sprint and came back twenty minutes later — not with a question about the output, but about the template itself. Why was the brief split into two files? Why did one go to engineering and one to stakeholders?

She had been using her own brief format for two months without knowing it served two completely different purposes. The engineering team needed machine-readable JSON — a spec. The stakeholder version was a narrative, a persuasion document. Same source. Different jobs. She had been sending one document with both things mixed together to people who needed only one of them.

That conversation didn’t happen because I explained the format better. It happened because she watched the procedure produce two files with two different structures for two different audiences — and the question she asked was better than any question she’d asked about briefs before.

Most learning about process happens in theory, before the work. This happened in the middle of a sprint, with a real deadline, on a real problem. The machine didn’t teach her my process. It made my process visible enough to ask about.

There is a version of the “AI will take your job” panic that understands this and a version that doesn’t. The version that doesn’t focuses on tools — which ones are fastest, which ones produce the best images, which ones can write the deck. The version that does asks a harder question: what does it mean that the machine can only do what you can tell it to do?

Because that’s the real question: not whether AI is replacing design expertise, but whether you have any to reveal. The designers who are building faster, thinking more precisely, teaching better with AI aren’t the ones who found the best shortcut. They’re the ones who did the uncomfortable work of paying attention to what they actually do — and found out it was different from what they thought.

The technology isn’t new in kind. People have been trying to make tacit design knowledge explicit since the Bauhaus. What’s new is the machine’s tolerance for ambiguity, which is zero. Every previous attempt to systematize design knowledge still let the practitioner off the hook — you could always fall back on “you’ll understand when you’ve done it for a while.” The machine doesn’t allow that. It follows what you wrote. And what you wrote is always, at first, incomplete.

That incompleteness is not a failure. It’s the finding. Start there.