The 5C framework for clarifying a request before you design it.

When designers join a team, the first instinct is to draw what they are asked for. The hard part was never the drawing. It is working out whether the request deserves to exist — and five questions, asked before you open Figma, settle that.

How it goes wrong

Three requests, three quiet failures. Each one was drawn well and built on time.

1. The PM says: “We need a new campaign banner on the homepage.” The designer opens Figma on the spot, goes through three rounds, ships it — and conversion does not move.
2. An engineer says: “This feature is too complex. Can we simplify it?” The designer simplifies. After launch, the part users actually came for is gone too.
3. Marketing says: “The design isn’t eye-catching enough.” The designer swaps fonts and colours, and the feedback comes back: it no longer feels like the brand.

None of these are bad design. They are design done before anyone asked what the request was for. The framework below is how I stop that happening — and it is the start of thinking strategically about design rather than as a pair of hands.

The five questions

Ask them in order. Each one has a job, and each has a mistake it exists to prevent.

1. Core — what is this for?

Ask why do this at all, and what happens if we don’t. Establish that the problem is worth solving, so the loudest voice in the room is not what sets the roadmap.

2. Context — whose problem is it?

Ask the requester to walk you through the situation it happens in. You are making sure you solve something real, not a guess dressed up as a requirement.

3. Check — what is the evidence?

Is there data, user language, support tickets, or a competitor doing this? Give the request something to stand on besides one person’s opinion.

4. Cut-down — what is the smallest version?

Split it into must-have, nice-to-have, and can-wait. Point the team at the smallest thing that could work, and keep design and engineering cost down.

5. Confirm — what is the bet?

Turn it into a hypothesis you can test, and get the team to agree to it. For example: “If we add a notes field, support calls will drop by 20%.”

The same three requests, through the 5Cs

Try it on something real

1. Core: why do this? What happens if you don’t?
2. Context: whose problem is it, and in what situation?
3. Check: what data, interviews, or examples back it up?
4. Cut-down: what is the smallest version that could work? How would you split it?
5. Confirm: write one hypothesis — “If we add ___, completion rate goes up by ___%.”