The “deliverable”. A simple concept to understand (something you “deliver”), but difficult to explain properly.
One way to describe a deliverable would be as a piece of work or an artifact that is a collective of a larger group of work. For example: a sitemap, a nav model, and a search definition would all fall under the umbrella of “information architecture”. To formalise this deliverable there might be a document that contains all these artifacts and a cover sheet with some versioning information.
Furthermore, artifacts and deliverables may also be standalone and interchangeable. A wireframe, for example, may be used as a deliverable on a project to show a manager you are making progress, provide developer information about the structure needed, or collect a milestone payment from a client.
The important thing to take away is that a deliverable is not something that should be done for the sake of an output, but to provide greater lucidity or bring the project/product closer to the desired end state. Therefore, it’s important to think critically as to why you’re creating a deliverable and to what level of fidelity/formality as there’s potential for wasting a lot of time!
Who is Your Audience?
Deliverables have an audience, and sometimes there’s some overlap as shown in the Venn Diagram below. Understanding that audience is an important first step in understanding the need for the deliverable and the level of fidelity or formality that may be required.
Generally, the product manager or any internal manager will largely be interested in the discovery and definition phase. This is when the business needs and processes are being hashed out and the product is being defined. Therefore, if they request some representation of what the product may look like down the line, it might be better to deliver a hand drawn sketch of some layouts, rather than waste time on coding a prototype, for example.
Developers are tasked with programming what has been discovered, defined and designed into final representations through code. There is a lot of room for misinterpretation with wireframes. Whatever layouts are delivered to a dev team need to be pixel perfect and specs should be created, as your average developer will create exactly what you request, especially if they are an outsourced team!
In the case of clients, deliverables may need to be more polished and serve as marketing tools (to show how good the agency is). You’ll sometimes use deliverables to influence the external stakeholder, or in meeting part of a contractual agreement when working with a “milestone payment structure”.
What Type of Environment Are You Working in?
Not only does the audience play a massive part in how the deliverable should be created, but also the structure of the organisation. Nothing remains constant, even within the same structure (such as a consulting firm); deliverables may vary from project to project. The descriptions below are generalisations, but a good starting point if you’re having a hard time trying to hash out what type of outputs may be needed.
Consulting Gigs and Digital Agencies
Deliverables are often of higher fidelity in this environment as you’re goal is not only to move the project forward, but also educate the client and ensure that they are ‘wowed’ by the deliverable. Effectively, it’s reassuring the client that they have made the right choice going with you over a competitor.
This is critical in the tendering stage when a number of consultancies are competing for the same job. However, keep in mind there are a number of other things that clients have in mind when making their selection; such as technology expertise, resources etc.
The deliverables in a “hackathon” are conceived with the purpose of presenting to a panel of judges. There’s may be a slide deck, and you might present some storyboards, product roadmaps.. Anything that will evoke emotion, communicate a problem and resolution to the issue and demonstrate a clear vision of the steps ahead! This is probably not the occasion for a fully developed prototype, unless you have members on your team with that capability.
In my experience, freelance gigs (especially those carried out online) are often very small in scope. It’s often “Wireframes needed for X app” or “Usability report for X website”. These deliverables are primarily used to signify completion rather than progress and are often tied to milestone payments.
Start up deliverables focus largely around discovery, validation and definition, as the entrepreneur is trying to crack the market. Design is important too and deliverables within the refinement phase of the project will revolve around pivoting the idea and making changes off the back of feedback from users and early stakeholders.
By “Product team” I’m referring to a company that has one or more digital products and internal staff. These teams generally use deliverables in an end to end process. They may be lower fidelity, except for when the product manager needs to communicate and package information for executives. Each deliverable tends to align more to different phases of the UX process.
Deliverables Within the UX Process
Deliverables may also fall into a number of phases within the UX Design process:
As you can see, earlier on in the process there are more deliverables as the project starts broadly and there is more work spent planning and trying to identify the right thing to work on. This model is probably most applicable to product teams and there is a lot of crossover in role during the first two phases. UX Designers, Product Managers and Business Analysts may all be collaborating on customer journey maps, for example.
Why Create Deliverables?
Why we create deliverables, as listed above, is contextual. Reasons are based on role, type of organisation, audience and many other factors. Here are five of the most common reasons for creating deliverables:
- To meet contractual obligations.
- To signify progress.
- To influence people.
- To make things clearer and move the project closer towards an end goal.
- To make a largely intangible process more visible with a number of outputs.
My personal approach is to keep the common deliverables front and center of my process; such as personas, prototypes, and user interviews. I keep the less common deliverables on the periphery; such as focus groups and domain models.
I also like to explore deliverables I may not have heard of before. There are so many different methods out there. It can really give you a broader perspective and make you a better designer to add some new deliverables to your workflow.
Well that covers deliverables! Here are some details to take away:
- Artifacts are normally a number of diagrams included under the umbrella of something larger. However, an artifact can also be a standalone deliverable (such as an interactive prototype).
- Artifacts and deliverables are a way to communicate design, with stakeholders internal and external, and to elaborate on vision. They communicate potential solutions to challenges and problems faced by designers every day.
- Deliverables should not be created for the sake of an output, but as a way to progress through to creating the final product and achieving the objectives defined.
- Phases of the project should be a pretty good indicator of when to use each deliverable, but when in doubt you should refer back to the scope of the project and be aware of some deliverables that are more often used than others!
- Deliverables are geared towards certain stakeholders (usually management, developers and external clients). They may be used for all of these groups, but relevance to each one will vary.
- Designers need to give instructions to those we work with. Whether it be to developers, collaborative agencies, or other stakeholders.
- Clarity is important. We use a number of diagrams, or deliverables to communicate ideas.
- Deliverables can serve as milestones to mark progress, but primarily they should be a way to communicate a design concept.