Design Brief Example
A design brief is a document that describes the core details of a design project. Design briefs are important as they set expectations, provide initial stakeholder requirements, and keep all parties on the same page. Once we understand what is needed for a given project, we can create a plan for how we will execute on it.
Parts of a Design Brief
-
Project Introduction
-
Users & Needs
-
Tasks
-
Timeline & Deliverables
Creating a Plan
Once we have a solid understanding of the requirements from our design brief, we can make plan to ensure we meet our deadlines. A simple plan should include:
-
Brief recap of the project and goals
-
All the people involved and their roles and responsibilities. This might include other members of our own immediate team, or other stakeholders we have identified.
-
A detailed breakdown of assets we will deliver, activities we will perform, and a high-level timeframe for when.
-
Any identified risks, assumptions or constraints.
Design Brief - Driver 🚚
Project Introduction
🚚 Driver is a mobile application that organizes all necessary information in order for drivers to view, organize, and complete their deliveries.
Users and Needs
The primary users of this application are delivery drivers with the primary goal of delivering their assigned shipments. They are usually on-the-go and/or distracted by traffic or other manual tasks such as loading, unloading and scanning. Education and tech background of this user type will vary skewing toward inexperience – we may expect some tech barriers in this user type. Additionally, we need to consider the use of this application from the perspective of a new user vs returning users.
Tasks
Here we might also indicate which tasks should = Key Screens ![]()
Key screens are the highest priority screens. They represent the essence of a digital product or service, and are typically structured around user needs and goals. If it’s a main step our user takes in accomplishing a goal, it’ll most likely be a part of a key screen.
|
Drivers need to be able to… |
Why? |
|---|---|
|
Login to the app |
In order to gain access to the application, pertinent information and functions |
|
Check in and out |
So that the driver appears on the VDB or not |
|
|
So that drivers know all necessary information related to the shipments they have been assigned |
|
|
In order to update status and chain of custody |
|
Perform required driver input (RDI) |
So that the driver can remain compliant with organizational requirements |
|
Establish proof of delivery |
So that all parties involved, including drivers, have proof a delivery has been completed |
This is a description of what the team is expected to produce for this project, and by when.
|
Milestone |
Tasks |
Deliverable |
|---|---|---|
|
Week 1 - Research |
Conduct User Interviews |
Interview script/questions, recordings, transcriptions, and findings Upload recordings to Dovetail Add insights to Productboard |
|
Week 2 - Synthesizing |
Create a detailed user flows outlining app functionality and send it to stakeholders for review and feedback |
User Flows in Whimsical |
|
Week 3 - Wireframing |
Create low fidelity wireframes for the application and send it to stakeholders for review and feedback |
Whimsical link to wireframes |
|
Week 4 - Prototyping |
Create a Figma prototype of the application |
Figma link to prototype |