In the first blog post of this series, we focused on introducing usability testing and the importance of establishing a study protocol, followed by recruiting, discovery, and analyzing. Now it’s on to wrapping up the project!
When a project wraps, everyone is eager to hear about the results. The team wants to know what needs to be fixed, and at this point, other departments want the full scoop after hearing about our work through the grapevine. While I can just send out an email with the key findings, it doesn’t always do the trick. It may get the ball rolling but it leaves out a lot of context, especially for those who haven’t been along for the ride. To paint everyone a better picture, I start putting together a presentation.
To kick things off, I ask myself:
• Who is the audience?
• What do they know about the product?
• What do they know about its users?
• What do they know about our process?
• What do they want to hear about the most?
The answers to these questions vary department to department, but my approach has been to cover as much as I can upfront. Then, I find the biggest whiteboard in the office and start storyboarding.
Typically, there’s three acts to these presentations. The first act is the introduction. It sets the stage as a mini study protocol, describing why we embarked on our journey, who we talked to, and how we got their feedback. The second act is the walkthrough. It’s the core of the presentation, revealing what the participants experienced while using the product. This act starts with a diagram that shows all of the tasks upfront and color-coded. This allows the audience to hone-in on where the participants were successful and where they had the most trouble. Then, I dig deeper into the problem areas with screenshots, videos, and quotes. The final act is the wrap up. It shows a summary of the key findings, the issues we’ll fix, and the participants’ overall sentiments with the product.
With the storyboard done, I start putting together my presentation, and make sure to get feedback as I go along. The UX team is the first audience to hear the presentation. This helps me vet the presentation for any gaps before I start sharing it with the other teams.
After incorporating the UX team’s feedback, I present to the product management team. I sometimes omit certain slides for this audience. As key stakeholders, they have more than likely been involved since the beginning, so they don’t need as much detail. Afterward, I also present to the documentation team so they can find ways to improve the Oracle Help Center. Finally, I branch out to other departments.
When the curtain closes on the final presentation, it gets archived and we set our sights on the next journey.
This blog is the final posting in a five-part series focusing on the journey UX designers must take with organizations as they work with stakeholders to ensure intuitive application interfaces and workflows are designed and implemented.