Introduce your deliverable to start off right

During my recent presentation on “The Usability of Deliverables: Making Deliverables Easier to Present and Use,” I focused most of my time on the first section, “introducing the deliverable.”

This is a relatively easy thing to do that can help prevent a lot of confusion and misunderstandings. And it’s not UX-specific – anyone who presents anything can benefit from this. A developer came up after the presentation and told me how useful he’d found it.  

Possible items to include in a deliverable intro:

  • Intended audience
    • Who will be reviewing, approving, or using this deliverable?
    • Will there be multiple audiences using this in different ways?
  • Intended purpose
    • What is it that your deliverable audience is going to do, based on this document? 
      • Examples: Estimate the amount of effort something will take, convince someone to fund a project, develop an application, etc. 
  • Where this fits in the overall flow of the project
    • What were the inputs into this? 
      • Example: These wireframes were based on in-depth interviews with potential customers, functional requirements, and usability best practices
    • What will be next, based on this deliverable?
      • Example: These wireframes will inform the visual designs and functional specifications
  • Explanation of the type of feedback desired
    • Examples: Are you looking for feedback on your labels? On whether the tone is on-brand? Or whether the information hierarchy is right, based on customer needs?
  • Criteria by which this should be evaluated
    • What makes for a “good” deliverable?
      • Example: In reviewing this copy, consider whether our potential customers would view this information as relevant. 
      • Example: When looking at these visual designs, consider whether they invoke the “clean” feel that is central to our brand.
  • A glossary of terms used
    • You may need to reiterate definitions during your presentation, but putting them upfront can help avoid confusion
  • A legend to explain diagrams
    • You’ll still want your legend on the diagrams, but this can help set appropriate expectations for what the viewer is about to see 
  • An explanation of how to (literally) use the deliverable
    • For example, navigating around and using the built-in tools for Invision or Axure isn’t very intuitive

Keep in mind that your introduction for the same deliverable may vary from project to project. For example, sometimes copy in a wireframe may be considered intended ‘final’ copy, whereas other times it is placeholder copy.

Wireframes can be confusing to someone unfamiliar with them!*
Explain your deliverable – and how to use it – before presenting/sharing
Participants working on the activity while I pass out a few more sheets.
Everyone’s hard at work on the activity!

My presentation included a break for an activity. Participants chose a deliverable they felt needed an intro, and filled out a worksheet. Then they shared their intro with a partner, and got feedback.

*Work created with Scenes™ by SAP AppHaus (

Leave a Reply

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