Why a request and a task are not the same thing
Clients bring solutions dressed as ideas. “Add a carousel.” “Make the homepage feel more premium.” “Can we get a dashboard like the one our competitor has.” Treating that sentence as the task is how projects go over scope and over budget: a designer builds toward the literal read, and three revisions later everyone realizes the actual intent was something else.
My rule: nothing enters a design queue until the request has been turned into a task.
The system
1. Separate the request from the outcome underneath it. The question isn’t what the client described. It’s what actually changes for the user or the business if this ships. “Add a carousel” is a solution. “Surface more products above the fold” is the outcome, and it might not need a carousel at all.
2. Turn the outcome into a written brief before design starts. Objective, audience, constraints, what’s a must-have versus a nice-to-have, and a plain description of what done looks like. Handed over verbally at kickoff, this context evaporates by week three.
3. Attach acceptance criteria to the design task. The same discipline a developer ticket gets: readable at a glance, matches the existing component library, holds up at the smallest tested breakpoint. Vague feedback like “make it pop” has nowhere to land when the task already defines what success looks like.
4. Run exploration and refinement as two distinct phases. Exploration stays loose: several directions, built to test alignment before anyone commits to one. Refinement takes the chosen direction and pushes it to polish. A client reviewing an early concept gets told explicitly that what’s on screen is a direction to react to, still open to change, rather than a draft ready for sign-off.
5. Gather the references that define “good” before the designer starts. Competitor screens, past materials, mood boards, collected up front instead of surfacing mid-revision. A shared visual anchor turns feedback into something specific instead of a debate about taste.
6. Decide the feedback loop before the first draft ships. Who reviews, how their input gets consolidated into one set of notes instead of five scattered comment threads, and how many rounds are already built into the estimate.
It becomes a document that outlives the kickoff call
Every design task ships with a written brief and its criteria attached instead of relying on verbal context from the kickoff. Six weeks in, when a stakeholder asks whether the original idea was actually something else, the brief settles it before it turns into a debate nobody can win from memory.
What this looks like from the client’s side
Clients experience this as fewer revision rounds. The upfront questions read as diligence rather than friction, and by the time something ships, it already matches the outcome they actually wanted, however the original request was phrased.