Nine UX deliverables and when to use them
Nine common UX deliverables are research findings, personas, journey maps, sitemaps, user flows, wireframes, prototypes, usability test reports and design systems or specifications. Each serves a specific purpose at a particular stage, from understanding users to building the product. The best teams create only the deliverables that help them make or communicate decisions.
Why deliverables matter
UX deliverables are the artefacts designers produce during a project: research findings, personas, maps, wireframes, prototypes and specifications. At their best, they help teams understand users, make decisions, align stakeholders and guide developers. At their worst, they become heavy documents that take weeks to produce and are never read.
The difference lies in purpose. Every deliverable should answer a question or support a decision for a specific audience. Before creating one, ask who will use it, what they need to know or decide, and what is the lightest format that will do the job. Often, a quick sketch or prototype communicates more than a long document.
The nine deliverables at a glance
| Deliverable | Purpose | Stage |
|---|---|---|
| Research findings | Summarise what was learned from users | Discovery |
| Personas | Represent key user groups and their needs | Discovery and definition |
| Journey maps | Show the end-to-end experience and pain points | Discovery and definition |
| Sitemaps | Show the structure of content and pages | Structure |
| User flows | Show the steps to complete a task | Structure and design |
| Wireframes | Show layout and content without visual detail | Design |
| Prototypes | Simulate how the product works | Design and testing |
| Usability test reports | Summarise test findings and recommendations | Testing |
| Design systems and specs | Guide consistent build and handoff | Build and handoff |
Research findings and personas
Research findings summarise what the team learned from interviews, tests, analytics and other sources, ideally with clear recommendations. Short summaries with quotes and video clips are more useful than long reports. Personas describe key user groups, their goals, behaviours and frustrations. They help teams keep users in mind, but only when they are based on real research rather than assumptions. Our post on sharing research insights covers how to present findings effectively.
Journey maps
Journey maps show the steps a customer takes to reach a goal, along with their thoughts, emotions, touchpoints and pain points. They are powerful for aligning teams across departments and identifying where to improve. Our guide to customer journey maps explains how to build one.
Sitemaps and user flows
Sitemaps show how content and pages are organised, which helps teams plan navigation and spot gaps or duplication. User flows show the steps a person takes to complete a specific task, including decision points and alternative paths. Both are useful before detailed design, because they make structure visible and easy to discuss.
- Sitemap: Big-picture view of pages and hierarchy.
- User flow: Step-by-step view of one task, including branches.
- Task flow: A simpler, linear version for one path.
- Screen flow: Flows built from actual screen thumbnails.
Wireframes and prototypes
Wireframes show layout and content placement without colours, images or detailed styling, keeping discussion focused on structure. Prototypes link screens together so people can click through a flow, from rough low-fidelity versions to polished mock-ups. Prototypes are especially valuable because they can be tested with users and help developers understand intended behaviour. Our post on prototype usability testing covers how to test them.
Usability test reports
After testing, a short report captures the key findings, their severity, how many participants were affected and recommended fixes. Highlight videos of participants struggling are often more persuasive than written descriptions. Keep reports concise and focused on action, with a clear list of what to change next.
Design systems and specifications
At handoff, developers need clear designs, component behaviour, states, spacing and assets. Modern teams increasingly rely on design systems and inspect tools rather than long written specifications. Documented components, with usage guidance and code, reduce ambiguity and keep products consistent. Our guide to building a design system from zero explains how to set one up.
Deliverables in agile teams
In agile teams, deliverables tend to be lighter and more frequent. Instead of producing a complete set of documents up front, designers create just enough for the next decision or sprint: a quick flow for planning, a prototype for testing, an updated component for the design system. Shared, living artefacts, such as a single design file, a research repository and design system documentation, replace many traditional documents. This keeps everyone working from the latest information and reduces time spent on documentation that quickly goes out of date.
Choosing the right deliverables
- Identify the decision: What does the team need to decide next?
- Know the audience: Who will use the deliverable, and what do they need?
- Pick the lightest format: A sketch, prototype or one-pager may be enough.
- Base it on evidence: Use research rather than assumptions.
- Keep it living: Update or retire deliverables as the project evolves.
Common mistakes
- Creating personas without research
- Producing long reports no one reads
- Polishing wireframes so much they look final
- Writing detailed specs instead of prototypes
- Letting deliverables go out of date
Frequently asked questions
What is a UX deliverable?
Any artefact produced during the design process, such as research findings, wireframes or prototypes, that helps teams understand users or build products.
Which UX deliverables are most important?
It depends on the project, but research findings, user flows, prototypes and design system documentation are among the most widely useful.
Are personas still useful?
Yes, when based on real research and used to guide decisions. Assumption-based personas can mislead teams.
Do developers need written specifications?
Less often today. Prototypes, design systems and inspect tools usually communicate details more clearly than long documents.
How detailed should wireframes be?
Detailed enough to show structure and content priorities, but simple enough that people focus on layout rather than visual style.
Should deliverables be shared with clients?
Yes, in a format suited to them, such as short summaries, prototypes and walkthroughs rather than raw working files.