Diving into deliverable details

Before creating a deliverable, pause and think about two key things:

  1. Who’s the intended audience?
  2. 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.” 


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?

Showing a scale of 'polish' from low to high. Low polish: interface sketches; usability report in Excel
High polish: high-fidelity designs; usability report in PowerPoint with visuals

How detailed should the deliverable be?

Shows scale for detail, low to high.
Low detail: no annotations; short findings/recs for a usability report
High detail: detailed technical annotations; findings/recs/quotes/video snippets for a usability report

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?

Zoom scale.

Zoomed out (low): storyboard, userjourney
Zoomed in (high): detailed wireframe or design

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. 

Editability scale, low to high. Low is sketches and print outs, high says "Anything done in common software tools (i.e. Microsoft)
Ironically, I first made these scales in Sketch before switching to PowerPoint – just in case I ever need to share these!

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. 

Interactivity, low to high. Low is static wires, high is full functioning prototype


Here are some example deliverables, and how I’d rate them along the scales discussed above.

Example of a sketch done in Freehand. Circles on vertical bars indicate where the image lies on the scales: Low polish, low detail, high zoom, mid editability, no interactivity
Low polish, low detail, high zoom, mid editability (possible, but requires account access), no interactivity
Example of a user journey, very high level, very detailed. High polish, high detail, zoomed out, mid-editability.
High polish, high detail, zoomed WAY out, mid-editability (created in InDesign)

Example of a page from a usability report. It includes goals, observation, recommendation, a screenshot, and a quote. The scales show mid-polish, high detail, zoomed in,  high editability
Mid-polish, high detail, zoomed in, high editability (built in PowerPoint)

Example of a visual design with hotspots indicated.
High polish, high detail (annotations), zoomed in, mid-low editability (Sketch + Invision), mid-interactivity (hotspots)

This post was highly inspired by “The Right Deliverables,” by Laura Klein. Check it out for a slightly different take on the same idea.

Leave a Reply

Your email address will not be published. Required fields are marked *