Every week, design briefs land in our inbox. Some are three lines in an email (“we need an app like Uber but for dog walkers, how much?”). Others are 40-page PRDs with no visual direction at all. Both cause the same thing: questions, delays, assumptions, and rework.
This article is the checklist we wish every founder had before the first call. It walks through the 11 sections of an app design brief that clients most often forget, and, more importantly, what actually happens on the studio side when each one is missing. If you fill these in, your first design round will look a lot closer to what you had in your head.
What is an app design brief (and what it is not)
An app design brief is a short, structured document that tells a designer what you are building, for whom, why, under which constraints, and how success will be judged. It is not a specification of every screen, and it is not a wireframe. Think of it as the decision context.
A useful brief for a mobile product usually fits in 2 to 5 pages. Anything shorter and the studio has to guess. Anything much longer and the important constraints get buried.
The four parts every brief contains
- Context: the product, the company, the problem, the users.
- Objectives: business goals and measurable success metrics.
- Constraints: platform, technical, brand, legal, budget, timeline.
- Deliverables: what you expect to receive and in what format.
The 11 sections below are simply those four parts, broken down the way projects actually break down.
The 11 sections clients forget in an iOS app design brief
1. A one-sentence product statement
Start with a single sentence: “[Product] helps [specific user] to [job to be done] so they can [outcome].”
What happens when it is missing: we receive a feature list instead of a product. Feature lists are impossible to prioritise visually, so the first round tries to give equal weight to everything. The home screen becomes a dashboard of tiles, you say “it feels cluttered”, and we redo the information architecture. That is typically one to two weeks lost.
Tip
If you cannot write the sentence without an “and”, you probably have two products or an unclear MVP scope.
2. Business goals and success metrics
Design decisions are trade-offs, and trade-offs need a tiebreaker. Tell us which number matters most: activation rate, paid conversion, session frequency, retention at day 30, support ticket volume, time to complete a core task.
- If the metric is activation, we will fight for a shorter onboarding and delay account creation.
- If the metric is paid conversion, the paywall gets real design attention and several variants.
- If the metric is retention, we invest in empty states, notifications, and habit loops.
What happens when it is missing: the studio optimises for what looks good in a portfolio, not for what moves your business. Reviews then become subjective (“I don’t love the blue”) instead of evidence based.
3. Target users, in the plural and in context
We do not need invented personas with stock photos. We need:
- Who are the two or three distinct user types (for example: customer, pro, admin)?
- Age range and tech comfort level.
- Context of use: indoors or outdoors, one hand or two, gloves, noisy, standing, driving, poor connectivity, short bursts or long sessions.
- Language(s) and country.
What happens when it is missing: we design comfortable 15pt labels for an app that will actually be used outdoors by users in their sixties, and the whole type scale, contrast ratio, and tap-target sizing gets reworked later. Context of use is the single most underrated line in any brief.
4. Scope: the screen and flow inventory
List the flows you consider part of version 1, and mark clearly what is out of scope. A rough count of screens is fine.
| Flow | In v1? | Notes |
|---|---|---|
| Sign up / sign in | Yes | Apple + email only, no password reset design needed |
| Onboarding questionnaire | Yes | Max 4 steps |
| Subscription paywall | Yes | Monthly + annual, 2 variants for testing |
| Social feed and comments | No | Planned for v2, do not design |
| Web admin panel | No | Separate project |
What happens when it is missing: this is where scope creep is born. Without a written inventory, every review call adds “just one more screen”. Ten of those and the project is 30 percent over budget with no one to blame. A signed scope table turns those additions into a clean change request instead of an argument. For the wider picture, see Free Design Brief templates.
5. States, not just screens
Almost nobody includes this, and it is half the work of a real iOS app. For each key screen, we need to know whether we are designing:
- Empty state (brand new user, zero data)
- Loading / skeleton state
- Error state (no network, server error, validation)
- Full state (power user with 500 items)
- Permission denied state (location, camera, notifications refused)
What happens when it is missing: the designs look beautiful in Figma with perfect demo data, then the developer ships an app that looks broken on day one. The fix is a mid-build “states pass” that nobody budgeted for. For the wider picture, see The Design Brief.
6. Reference apps and anti-references
Give us three to five apps you like, and for each one say what specifically you like: the onboarding, the navigation model, the typography, the illustration style, the tone of the microcopy. “I like Revolut” can mean six different things.
Then give us two anti-references: apps in your space that you find confusing, dated, or off brand. Negative examples narrow the design space faster than positive ones. This is treated carefully on itimap.com.
What happens when it is missing: round one becomes a style exploration, which is a polite word for a guess. Visual direction that could have been agreed in a 30 minute moodboard review gets discovered after the first full screen set.
7. Brand assets and design system status
Be explicit about what exists and how flexible it is:
- Logo files (vector, please) and whether the logo can be adapted for an app icon
- Brand guidelines: colours with hex values, typefaces and their licences for mobile app embedding
- Existing design system or component library, and in which tool
- Photography or illustration library, and who owns the rights
- Whether the app is allowed to deviate from the web brand
What happens when it is missing: two classic blockers. First, a brand font that is licensed for web only, discovered at handoff, which forces a full type substitution. Second, a print-first palette with 2.1:1 contrast that fails accessibility and has to be re-derived.
8. iOS platform constraints
This is the section that separates a generic “app design brief” from an iOS brief. Tell us:
- Minimum supported iOS version (most teams support the current release and the previous one).
- Device range: smallest supported iPhone, iPad support yes or no, landscape yes or no, Mac Catalyst, Apple Watch or widgets in scope.
- Dark mode: required at launch, or later? It roughly adds design and QA time to every screen, so decide early.
- Dynamic Type and accessibility target: which WCAG level, VoiceOver support depth, Reduce Motion behaviour.
- How native should it feel? Standard Apple navigation patterns and system materials, or a fully custom, branded interface? Apple’s recent move toward translucent, layered materials makes this a real fork in the road.
- App Store requirements: account deletion flow, privacy nutrition labels, tracking consent prompt, sign in with Apple if you offer other social logins, subscription management entry point.
What happens when it is missing: App Store review rejections and last-minute redesigns. The account deletion screen and the ATT consent moment are forgotten in nine briefs out of ten, and they are both mandatory for many apps.
9. Technical constraints and the handoff format
Designers should know the runway they are designing for.
- Is the app native (SwiftUI or UIKit), React Native, Flutter, or a wrapped web view? Each has different animation and component costs.
- Is there an existing backend and API that limits what data is available on a given screen?
- Third-party SDKs already chosen (payments, maps, chat, analytics, auth) and their default UI.
- Who builds it: your in-house team, a freelancer, or us? What do they want: a Figma file with components, exported assets, a token file, a clickable prototype, a specifications document?
What happens when it is missing: we design a custom camera flow for a Flutter build where the plugin only supports a fixed native UI, or a gesture-driven interaction that adds three weeks of engineering. Then the developer simplifies it alone, and the shipped app no longer matches the designs.
10. Content, copy, localization and legal
Interfaces are 80 percent text. Answer these:
- Who writes the microcopy: you, us, or a copywriter?
- Is real content available, or do we design with placeholder text? (Real content changes layouts, and “lorem ipsum” hides problems.)
- Which languages at launch? German and Finnish strings can be 30 percent longer than English, which affects every button.
- Right-to-left languages planned?
- Regulated content: finance, health, insurance, gambling, children’s apps. Which disclaimers, age gates, or consent screens are mandatory?
What happens when it is missing: a legal review at week eight introduces a mandatory consent step in the middle of a finished onboarding flow, and the whole sequence is re-spaced and re-prototyped.
11. Timeline, decision makers, and budget range
The three lines that keep a project honest:
- Hard deadlines and why they exist (funding round, trade show, seasonal launch, investor demo). A real reason lets us propose a smart reduced scope instead of a rushed full one.
- Who approves. Name one person with final say, plus the review cycle (for example, feedback consolidated within 3 working days). Design by committee with five reviewers and no arbiter is the most expensive thing in this article.
- Budget range. Not to inflate a quote, but to shape the proposal. A 6,000 euro brief and a 60,000 euro brief for the same product are two completely different processes, and we would rather tell you before you spend a month comparing offers.
What each missing section actually costs
| Missing section | Typical consequence | Rough impact |
|---|---|---|
| Product statement | Cluttered home screen, IA redo | 1 to 2 weeks |
| Success metrics | Subjective reviews, endless rounds | +1 to 2 review cycles |
| Scope inventory | Scope creep, budget overrun | 20 to 40 percent over |
| Screen states | App looks broken with real data | Unbudgeted states pass |
| References | Wrong visual direction in round 1 | 1 extra round |
| Brand and font licences | Type substitution at handoff | Every screen touched |
| iOS constraints | App Store rejection, missing mandatory flows | Launch delay |
| Tech stack | Undeliverable interactions, silent simplifications | Design and build diverge |
| Copy and localization | Layout breakage, legal add-ons late | Flow rework |
| Decision maker | Contradictory feedback, stalled approvals | Weeks of idle time |
| Budget range | Mismatched proposals, wasted sourcing | Weeks before kickoff |
A copy-paste app design brief template
Paste this into a document, fill it in, and send it with your first email. Bullet points are perfectly acceptable, and “I don’t know yet” is a valid answer that still saves everyone time.
- Product in one sentence: [Product] helps [user] to [job] so they can [outcome].
- Company and stage: pre-seed, funded, existing business adding an app.
- Primary success metric: and the current baseline if any.
- User types: 2 or 3, with tech comfort and context of use.
- Flows in scope / out of scope: use the table format above.
- States required: empty, loading, error, full, permissions.
- Reference apps: 3 to 5, with the specific reason for each. Plus 2 anti-references.
- Brand assets: what exists, where the files are, how much freedom we have.
- iOS constraints: min version, devices, iPad, dark mode, accessibility level, native versus custom, App Store obligations.
- Tech stack and handoff: framework, APIs, SDKs, who builds, expected deliverables.
- Content: who writes copy, real content available, launch languages.
- Timeline, approver, budget range.
The four questions we ask when a brief arrives incomplete
If you only have ten minutes, answer these and we can start:
- What does a user do in their first 60 seconds in the app?
- What single number will tell you this app worked?
- Which two apps should yours feel like, and why?
- What is not in version 1?
How to design a mobile app once the brief is ready
For context, here is where the brief plugs into a normal studio process:
- Brief and kickoff: the 11 sections above, one workshop to fill the gaps.
- Information architecture and user flows: agreed before any pixels.
- Wireframes: low fidelity, fast, cheap to change.
- Visual direction: moodboard plus 1 or 2 key screens, approved before scaling.
- UI design: all screens and states, built on components.
- Prototype and testing: 5 users is enough to catch the big problems.
- Handoff: components, tokens, assets, specs, and a live session with the developers.
- Post-launch: measure the metric from section 2 and iterate.
A strong brief compresses steps 1 to 4 dramatically. That is the whole return on investment: an afternoon of writing saves weeks of guessing.
FAQ
What is a design brief example for an app?
A minimal but usable example: “FitPlan helps busy parents follow a 20 minute home workout so they can train without a gym. Primary metric: day 30 retention. Users: 30 to 45, high phone comfort, training at home with one hand free. In scope: onboarding, workout player, weekly plan, paywall, profile (about 18 screens). Out of scope: social feed, Apple Watch app. References: Strava (clarity of stats), Duolingo (streak motivation), Headspace (illustration warmth). Anti-reference: generic gym apps with dark red gradients. iOS 25+ iPhone only, dark mode required, Dynamic Type support required, native SwiftUI, in-house iOS developer, Figma handoff. Launch in English and French. Deadline: end of Q1 for an investor demo. Approver: the CEO. Budget range: 15,000 to 20,000 euros.” That is a real brief in one paragraph.
What are the 7 main specifications of a design brief?
Most templates converge on these seven: function (what it must do), target audience, aesthetics (visual direction), materials or technology (the stack and platform), constraints (legal, accessibility, brand), budget and timeline, and success criteria. For mobile apps, add screen states and App Store requirements, which classic design brief templates predate. aspirity.com walks through the specifics.
What are the four parts of a design brief?
Context, objectives, constraints, and deliverables. Every one of the 11 sections in this article belongs to one of those four buckets.
How long should an app design brief be?
Two to five pages, or a single well-structured document of around 800 to 1,500 words. Clarity beats volume. A 40-page PRD with no visual direction and no success metric is a weaker brief than one clear page.
Do I need a brief if I already have wireframes or an existing app?
Yes, and it is even more important. Wireframes tell us what you decided, not why. Without the reasoning, a redesign either preserves mistakes or removes something that was there for a legal or technical reason.
What if I cannot answer the technical sections?
Write “to be defined” and say so explicitly. An honest gap is easy to plan for, an invented answer is not. Many studios, including ours, run a paid discovery phase precisely to fill those gaps before design starts.
Ready to send us a brief?
Fill in the 12-point template above, even partially, and send it over. We will reply with the gaps we see, a realistic scope, and an honest opinion on whether your version 1 is too big. A good app design brief does not make the project rigid, it makes the conversation fast.