How to brief a designer when you're not a designer
A good design brief for a startup gives context, not polish: the problem you're solving, who it's for, what already exists, and what success looks like. Skip perfect formatting. A messy voice memo with real context beats a templated brief with none, as long as someone on the other end knows what to ask.
Why most startup design briefs fail before they start
Founders treat the brief like a test they have to pass. They open a template, stare at fields like "creative direction" and "brand personality," and either freeze or fill them with words that sound right but mean nothing. Then the designer builds something technically correct and completely off, and the founder can't explain why it's wrong, only that it is.
The brief didn't fail because it was short. It failed because it answered the wrong questions. A designer doesn't need your opinion on typography. They need to know what the product does, who's using it, what happens if this screen or site doesn't work, and what you've already tried. Everything else, they can propose.
What a design brief actually needs (and what it doesn't)
A brief is not a spec. You're not handing over a finished plan for someone to execute pixel by pixel, you're handing over enough context for someone to make good decisions without you in the room every hour. That distinction changes what belongs in it.
What it needs: the problem, the audience, the constraints (budget, timeline, tech stack, brand assets that already exist), and what "done" looks like in your head, even if that picture is fuzzy. What it doesn't need: mood boards you don't actually feel strongly about, a list of competitor names with no explanation of what you like or dislike about them, or design terminology you're guessing at. Guessed terminology is worse than none. A founder who writes "make it feel premium, kind of like Stripe" gives a designer more to work with than one who writes "modern, clean UI with good UX," because the second brief could describe almost anything ever shipped.
The five things to write down before you talk to a designer
The problem in one sentence. Not the feature, the problem. "Users sign up but don't activate" is a brief. "We need a better onboarding flow" is a request.
Who it's for. Not a persona deck, just who actually opens this thing and what they already know or don't.
What exists today. Screenshots, links, a Loom walking through the current state. Designers can spot what's broken faster than you can describe it.
Constraints that are non-negotiable. Launch date, budget ceiling, a tech stack that limits what's buildable. Say these upfront so nobody designs something you can't ship.
What success looks like, even roughly. A number, a feeling, a comparison to something else you admire. "I'll know it's right when it feels as fast as Linear" is usable. "I'll know it when I see it" isn't, though plenty of founders start there and that's fine too.
What a short brief actually looks like
Here's the difference in practice. A weak brief reads: "We need a redesigned pricing page, modern and clean, that converts better." A designer reading that has nothing to push against, no problem, no audience, no definition of "better."
A usable version of the same request reads: "Our pricing page gets traffic but a lot of drop-off before checkout, we think people don't understand the difference between the two paid tiers. Most visitors are technical founders comparing us to two other tools before they buy. We can't change the pricing itself before Q4, only how it's presented. Success looks like fewer support tickets asking 'what's the difference between these plans' and a bump in trial-to-paid conversion." That's five sentences, no templates, no design vocabulary, and it gives a designer an actual problem to solve instead of a vibe to guess at.
Notice what's missing: no font preferences, no color direction, no reference to a competitor's homepage. Those come later, once the problem is understood, and they matter far less than founders assume.
What to do if you can't write any of this down
Most founders can't, at least not on the first pass, and that's not a failure of preparation. It usually means the product decision underneath the design request hasn't been made yet. If you're not sure who the screen is for, that's a product question hiding behind a design one.
The move here isn't to force a brief you don't have. It's to talk it through with someone who can pull the actual brief out of a conversation, a rough Notion doc, or a voice memo recorded in the car. That's most of what a good design partner does in the first week: not executing a brief you hand over, but building one with you, then executing against it.
This is where artone.studio/intro is worth a look if you're at this exact stage, staring at a blank brief template and not sure where to start. A short intro call replaces the template entirely.
How the brief changes once work starts
A brief written before day one is a starting point, not a contract. The best startup design work treats it as something that gets revised as you learn what's actually true about your users, not as a document to defend. If the brief says one thing and the first round of feedback reveals something different, the brief was wrong, not the feedback.
This is also where clear feedback matters as much as the original brief did. We've written before about how to give design feedback as a founder, and the two skills are really the same muscle: being specific about the problem instead of prescribing the solution. A founder who can say "this doesn't solve the problem because X" is doing exactly what a good brief does, just later in the process.
When a brief isn't the right format at all
Some founders never write a brief and their design work is still excellent, because the brief happens verbally, in a call, and someone on the other side is responsible for translating that into direction. That's a legitimate way to work, arguably the better one for founders who think out loud rather than in documents.
At Artone, briefs arrive as docs, Looms, Slack messages, or rough notes typed on a phone between meetings, and we adapt to whichever one shows up. Razvan reviews every brief personally and turns it into the strategic context a design team actually needs, rather than asking founders to translate their own thinking into a format built for people who already speak design. That's less about being flexible for its own sake and more about where the real bottleneck usually is: not the founder's ability to organize a document, but whether the person on the other end knows which questions to ask.
If your team is choosing between a fixed-scope brief and an ongoing retainer where the brief evolves month to month, that's a different decision worth its own read: design retainer vs. project, for startups.
The one-sentence version
If you can answer "what problem, for whom, and what does good look like," you have a usable brief, even if it's four lines in a text message. Everything past that is a designer's job to figure out with you, not a test you have to pass alone.
If your four lines don't feel like enough, book a short intro call and walk through it live instead of guessing at a template.
