Design deliverables should communicate content quickly, succinctly, and directly. But UX professionals often produce dense, complex, and inscrutable documents that don't convey our intent, or are so laden with jargon and insider UX terminology that they go over the heads of our colleagues and stakeholders.
(It’s ironic that UX professionals focus so much on understanding their products’ end users, but don't extend the same sort of user centeredness to coworkers who are the target audience for their deliverables.)
We can, however, use a simple method called the sketch test to learn about the effectiveness and understandability of deliverables, documents, reports, and visualizations. The idea is simple and resembles the telephone game: you give your deliverable to a colleague and ask her to create a short sketch or summary of your document. Observe what she sketches and writes. Then identify confusing or unclear elements, and iterate on the deliverable.
How to Perform a Sketch Test
The procedure is simple:
1. Print a copy of the deliverable (such as a wireframe, usability testing report, wireflow, persona, journey map). For deliverables that are inherently interactive (such as a high-fidelity prototype), consider representing them with a series of screenshots.
2. Recruit a sketch-test participant from your target audience. For example, if you're preparing a wireframe for developers, recruit a front-end developer. If you'll be sharing a usability-testing report with a product owner, find a product owner or project manager. Note that while it is only rarely appropriate to recruit usability testing participants among your coworkers, for the sketch test it is perfectly fine, since they are the actual end users of your deliverables.
Your colleagues' time is valuable, so be sure to compensate them with a small, but attractive incentive. Since a sketch test takes about 15 minutes or less, a nice cup of coffee at a local coffeehouse, lunch, or another small thank-you gift can often suffice.
3. Give the sketch-test participant the printed copy of the deliverable. Place a blank pad of paper and a pen or pencil right next to the person.
4. Invite the participant to write directly on the deliverable, but also make scratch paper available. Explain that the printed version of the deliverable is just a scratch copy, and that you welcome any comments.
5. Ask the participant to explain the concepts in the deliverable. But first:
- Explain that the current version of the deliverable is a work in progress, and that you are still developing the format of the document. While content suggestions can be welcome, at this point do not ask for them explicitly — keep the focus on making the deliverable clear and direct.
- Note that you want to make this document easier to understand.
- Give the participant time to read the deliverable. Ask your participant to use the think-aloud protocol during the initial reading of the document.
- Ask the participant to pretend that she is presenting this document, and have her explain the deliverable to you.
Simply making the participant aware that ideas can be written down either on scratch paper or directly on the printed copy of the deliverable will encourage your participant to be more forthcoming.
6. Watch and listen as your participant explains the concepts in your deliverable. While it is tempting to focus primarily on what the participant says (especially direct suggestions for changes), the observation process can provide equally or even more important insights. Watch for areas of the document that the participant refers to when explaining ideas in order to figure out if your document needs to be reorganized and if there are any missing points. (If the participant explains something “wrongly,” you should follow standard user-research protocol and avoid correcting the misconception, or you will bias the data from the rest of the session.)
7. Ask your participant open-ended follow-up questions if he offers vague or potentially insightful explanations of your deliverable. Be careful not to ask leading questions, or ones that propose solutions to problems that emerge during the sketch test — instead, probe to find the nature of any misunderstandings, and the assumptions that your participant brought to the session. The echo, boomerang, or Columbo methods can be valuable techniques to prompt your participant to explain an intriguing statement further without unnecessarily priming or leading their responses.
8. At the end of the session, explain the intended “correct” meaning of the document to your participant, to avoid having him leave with an erroneous understanding of your work. If the participant made a “mistake” in interpreting your document, make an effort to avoid having him feel stupid by pointing out that you clearly hadn’t explained that item well enough and that catching issues early, before they impact the full team, is why you’re testing the deliverable. Finally, thank the participant for helping you and the team.
Feedback to Look for During a Sketch Test
The sketch test can help surface two types of problems with deliverables: (1) content that is not easily perceptible in the document (e.g. using blue text to annotate a screenshot made it difficult to notice against a similar background), and (2) content that is not comprehensible (e.g. the purpose of a dendrogram being misunderstood as showing user preferences for various content). Whether or not a deliverable is comprehensible depends largely on the audience member's prior experience, expectations, and mental models, and these contextual details can be exposed by the sketch test.
During a sketch test, notice if your participant exhibits any of the following behaviors, which may indicate that something in the deliverable is difficult to understand or may need more emphasis:
- Circling or underlining elements
- Drawing something to represent content that your deliverable presents in text, or employing a different visual metaphor than you currently use for data visualization or infographics
- Making notes or edits on your sketch, or suggesting terminology or wording for concepts other than those shown in the deliverable
- Reading the same passages or studying the same images several times
- Struggling to explain something to you
- Explaining something incorrectly to you
Improving the Deliverable Based on the Sketch Test
If your participant struggles to explain your deliverable easily, you will likely need to revise it before sharing it with your colleagues.
Look at your participant’s sketch pad; these notes can be invaluable to you as you revise your deliverable. Pay attention to statements that:
- Use a different visual metaphor or presentation for the same data. While the particular suggestions your participant offers for alternative visuals may not be what you ultimately choose to use in your deliverable, there can be useful insights to be learned from how your participant chooses to express the idea.
- Attempt to keep track of steps or event sequences (especially with documents such as proposed user workflows, or usability-testing reports that note steps taken to accomplish a task).
- State intermediate inferences, explanations, or reiterations of facts presented earlier in the document. By not making these explicit when needed, you may have put an extra load on the reader’s short-term memory.
- Expose the participant's unfamiliarity with core concepts in your deliverable, demonstrate lower domain expertise than expected, or different expectations for what the content of the deliverable should be.
Feedback About the Content of the Deliverable
During a sketch test, you may receive feedback not only about the format of your deliverable, but also about its content. For example, if you're testing a wireflow, your sketch-test participant may suggest changes to the layout of the various screen designs represented in the wireflow. This is perfectly acceptable — while the main intention with the sketch test is to find flaws in the format of your deliverable, getting an additional review for your ideas is an opportunity to further refine them before formally sharing a finalized deliverable with project stakeholders.
Conclusion
Conduct audience-based testing in order to increase understanding of UX deliverables such as documentation, infographics, wireflows, and data visualizations. Do a quick sketch test: provide a printed copy of your deliverable, recruit a representative colleague, and ask them to explain to you what your deliverable communicates. Provide scratch paper for the participant to take notes on while explaining ideas to you. Your-participant’s notes and the verbal feedback can provide insights about how your deliverable can be improved to better match your audience's mental models and expectations.
Learn more about communicating UX ideas clearly in our full-day UX Deliverables seminar.
Reference
Michael J. Albers, "Infographics and Communicating Complex Information," Design, User Experience, and Usability: Users and Interactions (July 21, 2015)
