What we ask new clients before we ever open Figma

It's tempting to start a design engagement by jumping straight into moodboards and wireframes, and it's also a reliable way to end up redoing significant work later because a foundational question never got asked. We run a structured intake before opening any design tool, and it's saved us and our clients considerable rework over the years.

"Everyone who needs our product" isn't a usable design target. We push clients to name a specific primary user, ideally with a real example in mind ("someone like our client Sarah, a 34-year-old operations manager at a 50-person company") rather than a broad demographic description, since specific designs for a specific person consistently outperform generic designs aimed at everyone.

Before any layout decisions, we ask what a visitor needs to understand almost immediately, before they've read anything carefully. If the honest answer is three or four different things, that's a sign the messaging needs prioritizing before design work starts, not a problem the design itself can solve by trying to fit everything in.

Existing brand guidelines, a specific color that's legally protected or contractually required, an existing user base with established expectations: these constraints need surfacing before design work starts, not discovered midway when a stakeholder objects to a direction that conflicted with something the design team was never told about.

"We'll know it when we see it" is the answer that most reliably predicts a difficult, many-round revision process. We push for something more specific: a conversion metric, a stated brand feeling backed by reference examples, a specific competitor's site described as "we want to feel more premium than that one, more approachable than this one."

The same decision-maker clarity that matters for the whole project matters specifically for design review: one clear voice giving feedback, ideally in a single consolidated round rather than five different people commenting separately across multiple threads, produces meaningfully faster, more coherent design iteration than an unstructured group review process.

A visually striking design that ignores real technical constraints, a CMS that can't support a specific dynamic layout, a performance budget that rules out a particular animation-heavy approach, a legacy system that a new interface still has to integrate with, ends up either getting quietly watered down during development or blowing the timeline as engineering scrambles to accommodate it after the fact. We bring a technical lead into the intake conversation specifically to surface these constraints before design work starts, rather than treating design and engineering feasibility as sequential, disconnected steps.

Designing around placeholder "lorem ipsum" text or a client's best-guess draft copy is a common source of late rework once real, final copy arrives and doesn't fit the space the design assumed. We ask directly, before design starts, whether real copy exists yet, and if not, we either design with realistic length approximations based on similar existing content or explicitly flag which sections will need a design pass once real copy is finalized, rather than letting a mismatch between placeholder and real content surface as a surprise near launch.

A vague "we want to stand out from competitors" is far less useful than a specific list of the three or four sites a client's team actually checks and compares themselves against internally, since those specific sites reveal the real competitive frame the client is operating in, which is often narrower and more specific than a generic industry description would suggest. We ask for named competitors early, along with what the client likes and dislikes about each one specifically, since a directional statement like "more premium than X, more approachable than Y" gives design far more useful signal than an abstract adjective alone, and it surfaces disagreements between stakeholders about competitive positioning before design work has to accommodate two conflicting visions at once.

A meaningful chunk of this questioning happens during the proposal stage itself, before any formal engagement begins, both because it helps us scope the work accurately and because a prospective client's answers, or lack of clear answers, to these questions are themselves a useful signal about how ready the organization actually is to move into design work productively. A client who can't yet name a specific primary user or a concrete definition of success sometimes needs a shorter strategy or positioning engagement first, before design work would actually be well spent, and surfacing that gap during intake rather than three weeks into a design sprint saves both sides real time and frustration.

All of this intake would be wasted effort if it just lived in a call recording nobody rewatches, so we turn every answer into a short, written creative brief, one to two pages, that the design team references directly throughout the project and that the client reviews and signs off on before any visual work begins. This document becomes the shared reference point whenever a design direction is questioned later in the project, either side can point back to the specific, agreed answer rather than relitigating a decision from memory, and it's saved more than one project from a late-stage disagreement that turned out to be a simple case of two people remembering an early kickoff conversation slightly differently.

Most prospective clients expect this to be a quick, twenty-minute call, and it regularly runs closer to an hour once the specific, pointed follow-up questions start surfacing genuine disagreement between stakeholders who thought they already agreed on direction. We treat a longer-than-expected intake conversation as a good sign, not a delay, since it means real, substantive alignment is happening before design work starts rather than being discovered mid-project.