What we look at before opening Figma
© The journey from idea to interface is one of thoughtful reduction.
The brief is never the real brief
Every project arrives with a written brief a set of goals, a rough scope, a sense of what success should look like. But the written brief is almost never the complete picture, because it's usually written by whoever had time to write it, based on whatever problem was most visible when they sat down to type. The real scope of the work is usually somewhere underneath that document, waiting to be found.
Before we open any design tool, we spend time with the actual product or business as it exists today not the pitch version, the working version, with all its inconsistencies and workarounds intact. That gap between the written brief and the observed reality is usually where the real project lives, and skipping past it to start designing means solving the version of the problem someone described rather than the version that's actually happening.
Usage data over assumptions
It's tempting to start with a mood board, because it feels like creative momentum — something visual to react to, something to show a client in the first week. But visual direction chosen before understanding how people actually use a product tends to solve for taste rather than behavior, and taste alone rarely fixes a business problem that's rooted in confusion or friction.
Review analytics and drop-off points before any visual exploration
Read support tickets for recurring language and complaints
Identify the three pages customers interact with most and audit those first
The intake conversation that actually matters
The most useful part of any kickoff isn't the parts everyone expects the timeline, the budget, the deliverables list. It's the harder question underneath: what does this project actually need to be true in six months for it to have been worth doing? Most clients haven't articulated this clearly, because the written brief usually focuses on outputs, not outcomes.
Getting a real answer to that question, even an imperfect one, changes how every subsequent decision gets made. A homepage redesign meant to reduce support tickets gets approached differently than one meant to raise a funding round, even if the visual brief looks identical on paper. We ask this question in the first meeting, before anything else, because everything downstream depends on the answer.