I recently presented “The Usability of Deliverables: Making Deliverables Easier to Present and Use” at the Cleveland 2019 World Usability Day conference.
When deliverables aren’t easy to present and use, it’s a headache for everyone – both the creator and the consumer/reviewer of the deliverable. Why not spend a few extra minutes and avoid known hurdles?
Before we dive in, a quick definition:
- Deliverable: A thing that you produce as part of your job, generally intended for others. Could include a wireframe, a user research report, an email, a workshop, etc.
The three sections I presented on were:
I was originally inspired by alistapart article, called “Looking for Trouble.”
While they use the term ‘client,’ the concepts are applicable to anyone reviewing or using a deliverable.
“Clients shouldn’t be the ‘forgotten user.’ We create great products for them by focusing on their end users—while forgetting that clients experience us twice over, meaning their user experience with the product and their user experience with us.”
This is a really core concept to everything I presented: that we think of our deliverable consumer the same way we think of our end users, and think of our deliverables just as we think of the end product.
Someone will be reviewing, approving, and/or using this deliverable – who are they? What is the purpose of this deliverable for them? Will they be using it to estimate the amount of effort something will take? Convince someone to fund a project? Develop an application? etc.
Overall, as the alistapart article put it:
For every touchpoint our clients have with us, we could be asking the same questions that we do of our users:
How do clients interact with our products, e.g., a wireframe, design, or staging site?
What knowledge do they have when they arrive, and what level must we help them reach?
What are the common stumbling blocks on the way there?