In this guide 6 sections
A good brief names the users and how often they log in. It lists the three or four journeys that matter, the screens and exports you already have, the devices, and what is out of scope. One person must say yes.
Describe the users by what they do all day
Skip the job titles and write down habits. A billing clerk who keys sixty invoices before lunch needs a different screen from a branch manager who opens the system twice a week to approve discounts.
Count the people in each group and note how long each has used the current tool. Then say who is fast, who is hesitant, and who works in a shop with a shared counter PC and a barcode scanner. No designer can guess this.
- Each user group, headcount and daily hours in the tool
- Typical task and how many times it repeats
- Comfort with computers, spreadsheets and phones
- Anyone who reads reports but never types
Pick the three or four journeys that matter
Every business has a handful of routes that carry the work, such as quote to order, order to dispatch, complaint to resolution and month-end close. Name them in plain words. Write down the first and last screen of each.
Everything else is a side road. If you list thirty journeys, the designer will spread effort thin and you will get thirty average screens. Rank them, and say which single journey would hurt most if clumsy, because that one gets the most testing time.
Test the list with the people who do the work. Ask a clerk to walk through a journey aloud, and mark every step where she reaches for paper, a phone call or a second window. Those are the gaps.
Hand over what already exists
Send screenshots of the current screens, even the ugly ones. Add the Excel sheets people really use, the printed delivery note, the PDF invoice and the CSV export your accountant asks for each quarter. These show the fields that matter. They also show the order staff think in.
Mark what staff love and what they work around. A column everybody hides, a field filled with the same word each time, a sticky note on a monitor: each one is a design finding waiting for you.
Include one real week of data if you can. Anonymised orders show the longest customer name, the biggest basket and the oddest unit of measure, and the designer can size the columns to fit.
- Screenshots of the current tool, annotated
- Sample reports, forms and printed documents
- Exports sent to accountants, auditors or customers
- Logo, colours and any brand rules
State the devices, the network and the limits
Say where the software runs. A warehouse tablet used with gloves needs big buttons, and a reception desktop with a small monitor limits how much fits on one screen. A phone on a weak basement signal? That decides what must work offline.
Then draw the boundary. Name the modules you are not designing now, such as payroll or the customer portal, so nobody quietly designs them anyway. Add the date you need clickable screens and the date developers start.
Mention integrations too. If the screens must pull a customer from the accounts package or print to a label printer, say so now. A design that ignores the barcode printer will be redrawn.
Name one person who decides
Design drifts when five people give five opinions in one thread. Pick a single owner who can approve a screen, and tell the designer who else must be consulted and when. Warn them about the director who always appears at the last review.
Finish the brief with the questions you cannot yet answer, since a designer would rather see an honest gap than a confident guess. Then send the draft to two staff members from the floor, say a stores clerk and a dispatcher, and ask what you forgot.
UI/UX design brief template
A two-page fillable sheet. Page one has boxes for user groups with headcount, daily hours and device, plus a ranked table of core journeys with first and last screen. Page two lists existing artefacts to attach, scope exclusions, key dates and a single approver. Nothing else.
Open a blank worksheet to printQuestions owners ask
How long should a design brief be?
Two pages is plenty. Attach screenshots, sample reports and exports rather than describing them in prose, since a designer reads attachments faster than long paragraphs. Gaps will draw questions. Welcome them.
Do I need wireframes before briefing a designer?
No. Rough sketches on paper help, but the brief should describe people, tasks and constraints. Wireframes are the designer’s first output, and drawing them yourself can narrow their thinking too early. Leave the layout open.
What if my team cannot agree on the main journeys?
Run a short workshop with one person from each group, and have each write the three tasks they repeat most. Overlaps show the core journeys, while the leftovers become a second phase listed in the brief.
Should the brief include a budget?
Yes. Give a range, or at least a ceiling. It helps the designer choose between a full set of states for every screen and a lighter pass, and it avoids proposals that miss your reality.