When a client shows up with ten spreadsheets.

Process · 5 min read

Most clients come to the first design session with a rough idea. Maybe a paragraph in an email. Maybe a few dot points. Maybe a voice note they recorded in the car. That's normal. That's fine. I'm used to pulling the idea out of people and shaping it into something a designer can work with.

Then there are the ones who show up with a workbook. I'm talking multiple sheets. Budget breakdowns by category and size. Task lists sorted by time. Content templates for every communication the app would ever send. Detailed user flows for each type of person who'd use the thing. That's a different conversation entirely.

I've had this happen once in a way that genuinely changed how the project ran. And I remember sitting there thinking, "No one ever does this." Because they don't. But when someone does, the difference is enormous.

It changes what the designer can do

When a client brings that level of preparation, the designer isn't starting from scratch. The information architecture is already half done. The content hierarchy exists. The user scenarios have been thought through. I'm not guessing what the categories should be or what language the app should use. It's all there in the sheet.

That means I can spend my time doing what I'm actually good at. Structuring the screens. Reducing the cognitive load. Figuring out how to turn ten columns of data into something a person can glance at on their phone and immediately understand. The design work goes deeper because the foundation is already solid. I'm not building the brief and the product at the same time.

It also means the developer gets better handoff notes. Because the content isn't placeholder text. It's real. The budget numbers aren't made up. They're based on actual research the client did. The task sequences aren't generic. They reflect the real workflow. Developers can build from that with confidence instead of guessing and coming back with questions every other day.

You don't need to be technical

I want to be clear about this. The client who brought those spreadsheets isn't a developer. They're not a designer. They don't know Figma. They don't know what an API is. What they know is their industry. They know how people in their space actually work. They know the pain points, the timing, the costs, the language. And they put all of that into a format they were comfortable with. A spreadsheet.

That's what subject matter expertise looks like in practice. You don't need to draw wireframes. You don't need to write user stories in a specific format. You just need to write down what you know. If you know that task A has to happen before task B, write it down. If you know that there are three tiers of pricing and each one has different inclusions, put it in a table. If you know what an email should say when someone signs up, type it out. All of that feeds directly into the design.

The format doesn't matter. A Google Doc, a spreadsheet, a Canva file, a PDF, a photo of a whiteboard. Whatever you've got, bring it. The more you bring, the better the app gets. It's that simple.

Preparation compounds

Here's the thing most people don't realise. The preparation doesn't just make the design phase better. It makes every phase better. The developer quotes come back more accurate because the scope is clearer. The timelines are more realistic because the content already exists. The feedback rounds are faster because the client has already thought deeply about what they want. They're not seeing it for the first time and reacting. They're comparing it to something they've already imagined.

Studies from the Project Management Institute consistently show that projects with thorough upfront requirements definition are significantly more likely to finish on budget and on time. That's not a coincidence. It's compound returns on early effort. Every hour you spend preparing before the first design session saves multiple hours downstream. And it saves money, too.

So look, I'm not saying you need to show up with a ten tab workbook. Most people won't and that's fine. But if you're the kind of person who has that in you, do it. Don't hold back because you think it's too much or too detailed or not in the right format. Bring the lot. I promise you, your designer will thank you for it.

Sources
Requirements Management: Planning for Success (Project Management Institute) - Projects with defined requirements have higher success rates.
Stakeholder Alignment in UX (Nielsen Norman Group) - Shared understanding between stakeholders and designers produces better outcomes.

Related blog posts:

Don't forget to do your homework →

How to prepare for your first app design project →

Why subject matter experts build the best apps →