App UI/UX Design Brief: Users, Flows and Screen States
TL;DR
In this guide
- Start with users and tasks. Describe what people need to accomplish before listing screens.
- Include the missing states. Loading, empty, error and success conditions affect the design.
- Define the deliverables. A prototype, interface design and functioning application are different outputs.
An app UI/UX design brief explains who will use an application, the tasks it must support and the interface decisions the design team needs to resolve. It is useful for a new app, a dashboard or an existing product that is difficult to use. Start with the problem and scope before deciding how many screens are needed.
The guide at a glance
The three foundations of an application design brief
01
Users and tasks
Identify roles, goals, starting conditions and the important decisions.
02
Flows and states
Describe complete journeys, permissions and what happens when data or actions fail.
03
Prototype and handover
Agree the screens, interaction detail and information needed by the implementation team.
Describe the users and the problem
Name the main user groups and what each needs to do. A manager reviewing work and a team member submitting work may need different information and permissions. Describe the current process, the difficulty and the outcome the design should support.
Avoid beginning with a feature list copied from another product. A reference can help communicate an idea, but explain which interaction is useful and why. Record what is known from actual user evidence and what is still an assumption to investigate.
Map a complete task before counting screens
Describe the beginning, decisions and completion of the main flow. What brings the user into the app? What information do they need? Which actions are available? What should happen afterwards? A list of screens can miss the transitions that make a task usable.
Illustrative example: A team dashboard allows a contributor to submit a project update and a manager to review it. The flow includes finding the project, reading the latest status, entering an update, resolving missing information and seeing confirmation. The manager needs a review view and a clear decision record. This is a design example, not a delivered case study.
Include loading, empty, error and success states
A screen filled with ideal example data shows only one condition. Describe what appears before data loads, when no records exist, when access is unavailable and when an action fails. Include long names, varied content and other realistic data conditions that can affect layout.
For the dashboard example, an empty project list should help the user understand the next step. A failed update should explain the problem and preserve useful input where appropriate. A successful submission should make completion clear. These states should be part of the brief rather than left for the developer to invent.
Define accessibility and device requirements
Identify the devices and input methods that matter for the actual audience. Consider smaller screens, keyboard operation, focus, contrast, labels and meaningful error feedback. State the review requirements and responsible people instead of assuming a polished visual design proves accessibility.
W3C’s form tutorials provide useful background for labels, instructions, validation and feedback. Apply that guidance to the actual interface and test the implemented result; a design mockup cannot demonstrate every runtime condition.
Separate a prototype from application engineering
A clickable prototype can show a proposed journey, but it does not necessarily store data, authenticate users or connect business systems. UI design can define components, hierarchy and states; UX work can clarify tasks and flow. Engineering implements the connected application.
State whether the engagement needs discovery, interface design, a prototype, usability review or developer handover. If engineering is required, identify the implementation team and the technical decisions still outstanding. Application design does not automatically include backend development, hosting or app-store publication.
Use a compact app design brief
- Purpose: the business or user problem to resolve.
- Users: roles, access differences and important tasks.
- Flows: the journeys included in this phase.
- Data: real or representative content, with private information protected.
- States: loading, empty, error, success and permission conditions.
- Devices: relevant screen sizes and input methods.
- Deliverables: screens, components, prototype and handover detail.
- Review: who approves the work and what demonstrates usefulness.
Prioritise the first phase and record later ideas separately. This helps distinguish a usable design scope from an unlimited product roadmap.
Make developer handover actionable
Agree how the design explains components, interaction rules, content constraints and responsive behaviour. The implementation team should be able to identify what is approved, what is illustrative and what still needs a decision. Include a route for handover questions.
Review the built task against the design intent and user need. Visual consistency matters, but a complete acceptance review should also check behaviour, states and accessibility. The scope should identify who handles that review.
Put it into practice
Prepare these inputs for an app design conversation
- The user problem and main business goal
- User roles and the important tasks for each
- Current workflow and known usability concerns
- A prioritised list of flows for the first phase
- Representative content and relevant system constraints
- Loading, empty, error and permission conditions
- Device and accessibility requirements
- Prototype, handover and implementation responsibilities
Keep in mind
Screens are the result of a task flow
Define the complete task before choosing a screen count. Two screens can still hide a complex approval flow, while several screens may support a simple guided process.
Common mistakes to avoid
- Copying another product’s feature list without a user problem
- Designing only the ideal filled-data state
- Treating a prototype as a connected application
- Leaving permissions and error behaviour to the end
- Assuming application design includes every engineering task
- Requesting an unlimited product roadmap as one fixed design scope
A few useful answers
Common questions
Do I need a complete technical specification before design?
You need enough context to define the users, tasks and constraints. Unknown technical decisions should be recorded and resolved with the implementation team.
Can the brief be for a dashboard rather than a mobile app?
Yes. The same approach helps with dashboards and other interfaces. The flows, roles and devices should reflect the actual product.
What is the difference between UI and UX design?
UI design concerns the interface people interact with. UX work considers the task and experience around that interface. The deliverables and review method should make the scope concrete.
