Before creating a deliverable, pause and think about two key things:
- Who’s the intended audience?
- What will they be doing with this deliverable?
You may have multiple audiences, and this is an exercise worth going through for each of them.
Your audience might include developers, designers, business stakeholders, project managers, account executives, etc. What they each want to do with your deliverable may be different.
Some examples:
- Developers may want to use it to build something, or estimate a level of effort
- Designers may want to use it for a source of inspiration or as input into design decisions
- Business stakeholders may want to confirm the project will meet their business needs, or use your work to prove to someone else that a project needs funding
“Instead of always creating the exact same deliverables or whatever’s easiest – photos of whiteboards, powerpoint decks, Photoshop mockups – think about the audience for the deliverable and what you’re trying to communicate.”
https://qwww.usersknow.com/blog/2016/7/28/the-right-deliverables
Once you’ve written down your primary and secondary audiences, and determined their goals, it’s time to work on the details of the deliverable itself.
The following is an example of a useful framework for thinking about your deliverables. Taking a step back and thinking, “is this the right place on the [whatever] scale given my audience and their need?” can help you be more thoughtful about producing the right deliverable.
For example, I’m used to at least medium ‘polish’ (see below) with wireframes. But I had to adjust that to very low polish for a client recently, where they hadn’t given me enough info to understand the basic functionality, much less how to lay the page out, and I had limited hours to work with. My rough sketch enabled them to give me feedback on only the flows and functionality, almost completely ignoring layout. If I’d stuck to my standard wireframe, it would have taken me twice as long to gather the info I needed. (In case anyone is wondering, I used Invision Freehand for the sketching)
Deliverable framework: scales to consider
How polished should the deliverable be? That is, how much time should you spend making the deliverable itself look good?
How detailed should the deliverable be?
For both polish and detail, this is a combination of what your deliverable users want/need, as well as a matter of time and iteration cycles. If you don’t have much time, some quick sketches to start might be the way to go.
And spending a lot of time on annotations when you’re sitting next to a BA who will be doing functional specs may not be the best use of your time. On the other hand, if your BA is offshore, you’re probably going to need a lot more detail (communicating across time changes is tough!).
What level of zoom should your deliverable be at? Basically, are you 5 ft away from the end product, or 10,000 ft away?
You might start projects with more ‘zoomed out’ deliverables, and proceed to ‘zoom in’ along the way. To be honest, I haven’t tried using this language with clients yet, but I could see it as a valuable tool to discussing what they’re looking for upfront. Last year, I assumed a client was looking for very zoomed out deliverables, and it took three meetings to figure out he wanted something really zoomed in!
How editable should the deliverable be? If you want to edit something later, or if someone else might want to, sketches or printouts can be problematic. Also potentially problematic are software such as Sketch or KeyNote, if you’re sharing with colleagues that have PCs (those are both Mac-only programs). Consider the software and medium you use.
How interactive should the deliverable be? (Applicable to wireframes/designs/concepts/etc.) Is it enough to just do hotspots to link pages? Do you need to ‘lock’ navigation to show the intended experience? Or perhaps most of it can be entirely static, but there’s one or two pieces where it’s worth mocking up the animations and interactions – showing can be easier than telling.
Examples
Here are some example deliverables, and how I’d rate them along the scales discussed above.
This post was highly inspired by “The Right Deliverables,” by Laura Klein. Check it out for a slightly different take on the same idea.