What the Machine Asks You to Justify
The PM leans forward in the review and says: “why this layout?”
You know the answer. It’s just not a sentence.
“It depends,” you say. “On a few things.” And then you start listing them — whether the primary user is a first-timer or a returning admin, whether the team is optimizing for speed or confidence, what the CEO said last quarter during the business review where leadership audits the roadmap and someone always says the product feels too dense. The PM pushes back on two of them, agrees with one, asks a question that reframes the third. Fifteen minutes later you’ve made a decision neither of you had at the start of the meeting.
The criteria were always there. The conversation excavated them.
Now try the same thing with Claude.
The criteria are still there. You can type them. But the machine can’t weight them — doesn’t know which quarterly review you’re referring to, doesn’t know this feature is three weeks from a board presentation, doesn’t know that when your PM says “confidence” she means something specific she learned from a bad launch two years ago. The list is articulable. The judgment about which item wins, right now, in this context — that part lives somewhere else.
This is not a failure of the tool. It’s a map of what the tool can and can’t do. And working along the edges of that map is how you find out what you actually know.
Early on, AI feels like a smarter search engine. You ask questions and the answers come back. The quality of the interaction seems to depend on which questions you know to ask — a prompting problem, solvable with practice.
Then you have the experience that changes the framing.
You’re in a session. You paste a screenshot of a settings page and type: Give me feedback on this design. The feedback comes back. It’s not wrong exactly. Whitespace between sections feels tight. Navigation hierarchy is unclear. You stare at the output. You know something is off but you can’t immediately say what.
So you try again — more context this time, more specificity. The feedback improves. You keep going. By the third iteration you’ve written a prompt that’s two paragraphs long and mentions the user type, the task, the screen width constraint, the stage of the work, and what you’re worried about.
Now read your first prompt back. Three words. Give me feedback.
The discomfort isn’t that the AI failed you. It’s that you can hear yourself — vague, less certain of what you’re asking than you thought. It’s the feeling of hearing your own voice on a recording. Not bad. Unfamiliar. You sound like someone who hasn’t finished thinking yet.
What happened: the quality of the output reflects the quality of the question, which reflects how clearly you’ve articulated the problem to yourself, before you typed anything. When the output is generic, the diagnosis is almost never “bad AI.” It’s that your request assumed context the machine doesn’t have — and you didn’t realize you were assuming it. The things you left out weren’t things you forgot to mention. They were things you knew so automatically they didn’t feel like information. They felt like air. The machine made them visible.
There’s a second experience, subtler and more revealing.
You’re working on a stakeholder brief. You’re moving fast, comfortable. It feels like working with a smart colleague who’s read everything and forgets nothing.
Then you type: Use the tone from our last agency brief.
The output comes back wrong. Not bad — wrong. The register is off. It reads like a capable writer doing an impression of the kind of document you meant, rather than the document itself.
You try to correct it. More direct. More decisive. Less hedging.
Still off.
You go looking for the original brief to share as a reference. You spend five minutes searching before realizing you’re not sure which one you meant. You’ve written a dozen briefs. “Our last agency brief” is a feeling, not a file. When you finally find a candidate and read it back, you discover you can’t fully explain why it sounds right. It just does. Something in the sentence rhythm. Something in how it handles uncertainty without telegraphing it.
You spend twenty minutes trying to define what you can hear but can’t describe. Eventually you produce something workable — not by explaining the tone but by writing three sentences that demonstrate it and saying: match this.
What happened: the gap between what you know and what you’ve defined. Working with human colleagues, you don’t always have to define things like tone — good partners absorb it. They sit in the same meetings, read the same briefs, pick up the patterns over months. You’ve never had to make any of it explicit because the knowledge transferred through proximity and repetition. The machine has no proximity. Every session starts from zero. What you call “shared understanding” with your team might be shared — or it might be that everyone on your team is quietly filling in the same gaps you never articulated, in slightly different ways, and nobody has noticed yet.
Here’s where this gets complicated.
Some “it depends” is a cop-out. You haven’t done the thinking. The machine forces you through it, and what comes out the other side is sharper, more useful work. But some “it depends” is the job.
Design decisions don’t always come from rules. They come from reading a room — knowing this particular client has been burned by that particular mistake, knowing this stakeholder needs to feel heard before they’ll hear anything else, knowing this color is too aggressive for this moment even though it tests well. The tastemaker in a room isn’t the person with the most rules. It’s the person who knows when to apply them and when to steer around them. A machine can approximate taste from patterns. What it can’t do is walk into a room and feel it.
So the question isn’t: how do I systematize all of this? The question is: can I tell the difference between judgment I’ve earned and habit I’ve never examined?
Because not everything that feels like taste is taste. Some of it is convention. Some of it is a decision someone made in 2009 that got handed down as wisdom and nobody has questioned since. Working with AI — being forced to explain yourself to something that cannot politely let you off the hook — is useful precisely because it sorts those two things out. The goal isn’t to systematize everything. It’s to know what you’re choosing to keep in your hands, and why.
The deeper the mode of engagement, the harder the question the machine asks. And the hardest ones aren’t about how you work. They’re about what you believe.
Ask a designer why they use an 8px grid and most will say something about consistency. Press them on why 8 and not 6 or 10, and the answer gets vaguer. Press again and you’re usually at “that’s just what we use” or “it’s an industry standard.” That’s not a reason. That’s inheritance.
Design is full of these. Practices we follow because we were taught them, because our tools default to them, or because questioning them would mean questioning the people who taught us. Oftentimes, becoming better educated is a luxury we don’t have time for. Most conventions work fine. Some work well. A few are actively wrong for our context, and we follow them anyway because we’ve never been forced to justify them from first principles. Writing a procedure for a machine — one that needs the principle behind the rule, not just the rule — is one way to find out which is which.
The double diamond is a good place to start. Diverge, converge, diverge, converge — this has been the mental model for the sanitized version of the design process for nearly two decades. It’s clean. It makes sense in a slide deck. It implies that designers have the space to explore widely, synthesize carefully, explore again, and land with clarity.
Most working designers have never had that space. Not in startups where the brief arrives two days before the review. Not in agencies where the project scope was set before you were hired. Not in product teams where engineering has already started building and your job is to catch up. In those environments, the double diamond isn’t a process you execute imperfectly. It’s a process you were never going to execute at all.
What you actually develop in those conditions is something different and harder to name: a compressed practice. A fast audit of what exists. A case built on the strongest rationale available. Pressure-tested against known constraints, pre-loaded with anticipated objections. You walk into the room with something you can defend.
That’s not a broken version of the double diamond. It’s a different skill — one the double diamond has no name for. The convention worth interrogating isn’t the framework. It’s the guilt. Most designers who’ve built real things under real pressure carry a low-grade belief that they’re cutting corners — that somewhere, someone is doing it properly with full research phases and clean convergence points, and they’re improvising by comparison. That belief is the inherited convention. Worth asking: does the double diamond describe how good design actually gets made, or how design is supposed to look in a case study?
User personas have been the same format for a long time. A name, a photo, demographics, goals, frustrations, maybe a quote. They look thorough. That’s the problem.
Paste a persona into Claude and ask for design recommendations. It will take your user seriously — reference their goals, build on their frustrations, produce confident output. The response reads like user-centered design. And then you realize the person the machine just designed for was invented in a two-day workshop, built on assumptions your team had going in, and hasn’t been updated since the product changed direction eighteen months ago.
The persona format doesn’t just fail to serve its purpose well. It creates the appearance of user-centeredness without requiring the substance of it. Professional enough that nobody questions it — including the machine.
When I tried to layer a persona into a procedure, I had to ask the question the format has always let me avoid: what is this actually for? Not what it is. What it’s for. The honest answer is that I use personas for two completely different jobs that the standard template serves poorly.
The first is alignment — making sure the team is designing for the same person, with the same understanding of how that person makes decisions. For this job, a persona doesn’t need a name or a photo or a backstory. It needs decision criteria: when this user encounters a tradeoff between speed and accuracy, which do they choose? What does “trust” mean to them in a product context? The standard template gestures at these under “goals and frustrations” and buries them under demographic data that has no bearing on component-level choices.
The second job is empathy — reminding the team during a long sprint that a real human will use this. For this job, the demographic detail does matter. A story matters. But the standard template produces a profile that reads like a marketing segment, not a person. It triggers analysis, not recognition. We need to be able to see ourselves in our target audience.
Your most useful persona work probably does one of these jobs without fully knowing that’s what it’s doing. The unified persona driving team prioritization is doing alignment work. The customer story you tell in a product review to argue for a feature is doing empathy work. They’re different documents for different moments, and treating them as one artifact means the one you have is probably doing neither particularly well. The machine can’t tell the difference, so it uses whatever you give it for both — which is how you end up with AI-generated recommendations that are user-centered in tone and wrong in every decision that matters.
“The design system is the source of truth.” Most design teams say this. Almost none of them mean it — not because they’re being careless, but because it’s the wrong frame.
Truth doesn’t need a source. What a design system is is a hypothesis: this is how we believe the product should work, documented well enough to produce consistency. The shipped product is the test of that hypothesis. When they diverge — and they always do — something learned something. A component got modified in production because the documented version didn’t hold up under real conditions. An engineer built a better solution than the spec described. A designer created a variant that worked and never made it back to the library.
Those divergences are worth examining. The system that never drifts isn’t a healthy system. It’s a frozen one. What mattered most in those moments, that overrode the clean workflow?
The convention worth interrogating isn’t whether to have a design system. It’s whether you treat it as a living test of your product hypotheses or as a document the product is supposed to comply with. Those two stances produce completely different cultures — different conversations about who owns reconciliation, different relationships between design and engineering, different answers to the question of what “correct” even means when the system and the product disagree.
The interrogation doesn’t produce a verdict. It produces a distinction: between the conventions worth keeping and the ones you’ve been following on autopilot. Conventions grounded in perceptual or cognitive science — Fitts’s Law, reading patterns, the way visual hierarchy actually works in the eye — tend to survive. Ones inherited from a specific era of technology, justified by authority rather than evidence, or too vague to test against anything real tend not to.
The ones that don’t survive aren’t necessarily wrong. They’re untested. And untested conventions produce unexpected results in the moments when they matter most.
A convention you’ve interrogated and kept is stronger than one you’ve never questioned. You know its limits. You know when to break it. You know why you follow it when you do. That knowledge is the difference between expertise and habit wearing expertise’s clothes.
The machine doesn’t make this distinction for you. It follows whatever you tell it to follow. But writing down the convention, turning it into an instruction clear enough for a machine to execute, forces you to look at whether you know why you believe what you believe.
Some of what you find is judgment you’ve earned. Keep that. Hold it tight. Some of what you find is a rule you were handed and never examined. That part is worth a closer look.