Research artifact boilerplates

When I joined the IBM Cloud team, I found research documentation, data, insights, and tools were spread out and rather thin. I decided to split my time between individual assignments, at first only for the product I led design for, and building general tools for faster research work. My first task was to plan and organize research workflows that work best on the infrastructure team and plan to scale from there.

As there was little on the IBM Design Research website to this effect at the time, and most other resources seemed ad-hoc, I sought to create resources for fast turnaround on research validation, testing, and information gathering that we already had. Based on my previous experience, my peers’ experience, a bunch of wiki and web pages, info in Slack, and our research documents, I decided to start with boilerplate templates.

I didn’t want teams using commonly Google-able templates in a checklist-like way that someone may assume is a way to compute the usability of a service with certainty. Rather, I wanted to create things to more easily start doing research with or reference for communicating research in a valuable way outside of the design researchers’ domain. This became the goal of my boilerplates, to speed up creating and using specific artifacts and providing organizational consistency across offerings.

So far I’ve created these:

• The problem definition guide and worksheet details how to frame problems to invite stakeholders to want to listen to users by articulating user, client, and stakeholder issues as problems to be researched and appropriately resolved.
• The expert evaluation protocol and worksheet details how to quickly identify clear strengths and weaknesses in a service, as well as to provide opportunities for improvement, when the researcher is unable to do research with users.
• The usability test protocol is a lengthy guide for evaluating with users in different degrees of fidelity and how to report the results to stakeholders
• The recruiting guide is a generic way for folks on my team to tell me what all they need and expect out of a study in a way that I can quickly turn around a plan and start recruiting. Before, recruiting took over a week of back-and-forth and discovering resources and helping designers articulate their research goals. Since sharing this guide and templates, I am able to within just few minutes understand and plan and act.
• The feedback pool is a list of all sponsor users and individuals I’ve personally recruited that have indicated they would give feedback. It includes their position and generic title that I use to link back to our teams’ target groups and personas, allowing me to constantly evaluate them to ensure we have a good understanding of these moving targets. It also includes some high-level data about their jobs to help provide a consistent way to reference what jobs we are designing for as much as the people.
• The customer map is a Mural board used to work with sales and support folks to create a set of stakeholder artifacts. The goal here is to set the flavor of how design, research, offering, sales, and support can work together to understand what we need to do to improve the experience for all users at a client.
• The target group & stakeholders document organizes roles (like “network engineer”) and related personas into target groups. It also contains the internal stakeholders for the offering and related teams in design, development, sales, and support.
• The jobs & as-is document organizes those target groups by their job stories and need statements, as well as the as-is journey and associated pain points. These can be used as a quick way to organize content for a more high-fidelity journey map in a deck form.
• The hills & user stories document finally builds on the other artifacts to collect user stories based on each target group, role, or persona into hills. These are focused on iterations, so each new set of hills and user stories can be added to the document, pushing the others down and providing an easily searchable history.
• The co-creation/research session plan to help articulate and scope such sessions that often require a lot of people’s time and have a higher social impact for failure
• A work-in-progress guide to help other researchers understand and use Bayesian statistics for design research.