Clients answer factual questions well and aesthetic ones badly. This is how to handle the second kind — and a way to audit the questions you ask today.
“How should it feel?” comes back as clean, modern, professional. Every client, every time. Nothing to design from, and nothing to point at when someone changes their mind later.
Two options on screen, one pick. Six seconds, no vocabulary required, and the answer is a decision you can hold them to.
People cannot author taste. They recognise it instantly. Everything below follows from that one fact.
Show → Choose → Reflect → Lock
Show two options. Make them pick one. Say back what their picks mean in plain language. Have them confirm it.
Never a word list. Render the thing itself — two layouts, two type treatments, two colour ways. Stimulus, not vocabulary.
Two options, one pick. No “both”, no slider. The constraint is what produces the signal. Where you need priorities, force a fixed count: pick exactly three.
Do not echo their clicks. Translate them into a sentence about their business — “Homeowners who care most about trust → get a quote.” This is where a wrong answer gets caught, and where they see you were listening.
An explicit button: Approve, Confirm, Sign off. Never auto-saved. The press is the artefact — a dated record of what was agreed before anyone designed anything.
Every locked choice resolves to a named value.
Not “considered and precise” but tone: considered, density: tight. Each one maps to something real in the build — a token, a component variant, a content field. If a choice cannot be mapped, it was not worth asking. This is what turns intake into a spec your developers can act on instead of a summary someone has to interpret.
Run every question in your current intake through this. Most pass unchanged. The ones that fail are the ones producing your worst answers.
| Kind | Example | Handling |
|---|---|---|
| Fact | Who buys from them. What they want that buyer to do. What is broken now. | Ask directly. They are the only source and they answer well. |
| Judgement | Tone. Density. Pace. Restraint against expression. | Convert to a forced choice on rendered options. |
| Yours | Page structure. Components. Grid. What sits above the fold. | Do not ask. Asking hands them your job and costs you authority. |
Not from asking more. The formula is fixed; three things move underneath it.
| Axis | Small engagement | Large engagement |
|---|---|---|
| Respondents | One person, one sitting | Six stakeholders, answered separately, never in a room together |
| Stimulus | Generic samples | Made from their own material — their products, their sector, their existing system |
| Weight of the lock | A note in the file | A signed gate. Reopening it is a change order. |
The counterintuitive part: as the engagement grows, the instrument gets shorter. Depth comes from more people answering the same few questions, not from one person answering more of them.
Length signals uncertainty. A short, sharp instrument reads as expertise; a long one reads as an agency that has not decided anything yet.
Two assumptions break, and the method survives both.
“The client” stops being a person. It becomes a committee, and one answer is no longer a brief. Six people answering separately is something better: a map of where the project will break. If the founder picks restraint and the marketing lead picks expression, you have found that in week one instead of week eight, and you have it in writing. Disagreement is the deliverable.
Taste stops being the main risk. A large company already has a brand system, so direction is partly pre-decided. The question changes from what do you like to which reading of your existing system is right, and do your own people agree on it. Same mechanic, different material: the options you show are now competing interpretations of something they already own.
What the instrument really produces at that level is not direction. It is a documented, multi-party record of consent, dated before design began — which is the only thing that settles an argument in month three.
The method is deliberately generic, so the last step has to be yours. Copy the prompt below into any capable model. It interviews you about your existing process, then returns an instrument shaped to it — same logic, your questions, your handoff.
You are helping me redesign my agency's client onboarding. The goal is to capture design direction reliably and hand it to my developers as a spec rather than a summary. Follow this method: - Facts (things only the client can know) are asked plainly. - Judgements (tone, density, pace, anything aesthetic) are never described in words. Show two rendered options, force one pick. - After the picks, say back what they mean in one plain sentence about the client's business. - The client presses an explicit button to lock it. Nothing auto-saves. - Every locked choice resolves to a named value that maps to something in the build. - Anything I could decide myself is not asked at all. Interview me one question at a time. Do not produce any output until you have asked all of them and I have answered. Push back when an answer is vague. Ask me about: 1. Every question in my current intake, and the format it is asked in. 2. Which of those answers I cannot design from, and what they usually come back as. 3. Who fills it in today, and who holds veto power but never fills it in. 4. What my design system or brand rules already fix, so the instrument does not ask about settled things. 5. What my developers chase me for in week one that the client could have answered. 6. Where this sits in my process, and what happens the moment it is submitted. 7. What a locked choice is worth to me: a note in the file, or a gate that costs money to reopen. Then produce: - A revised question list in three groups: ask plainly, convert to forced choice, stop asking. - For each forced choice: the two options, what I would render to represent each, and the sentence said back to the client. - The structured record it outputs. Field names, value types, allowed values. - How each field maps to my build — token, component variant, or content field. - What I should delete from my current process, and what it costs me to delete it. Ask your first question now.