When a research team is small or just one scrappy person, it’s easy to keep track of user research projects, artifacts, and takeaways. But as an organization scales their UX team, adds more researchers, and more folks in the company start to see the value of research and want access to findings, then you can run into a very hairy situation.
In an effort to prevent a research snag down the road, I always begin standardizing research artifacts and processes as soon as possible. If three researchers agree on a templated test plan, use it regularly, and choose a consistent naming structure, then by the time there are 15 researchers, that format is second nature. It’s also easier to teach and correct standardization one at a time as researchers join the team than all at once across a large, distributed team some time in the future.
If your organization is small or new, you may only need one or two templates to begin with, whereas larger organizations will have a pretty diverse collection right off the bat. Employ a little bit of content strategy before you start standardizing, and map out how many artifacts exist today, which ones are like and which ones are different, which ones are necessary and which ones might have been one-offs, and how many you’d like to keep going forward. Then build out a quick master sheet for each. [Tip: This doesn’t have to be time consuming -- two researchers in a room with a stack of sticky notes should be able to knock it out in a couple hours.]
Here is a list of artifacts I’ve helped standardize and templatize at past organizations. I’ll link each one to an example as I finish them out, so check back (or bookmark this page) if you’re interested in the template and some explanation.
User Research Artifacts:
Usability Testing Plan
User Research Plan
Usability Testing Summary
User Research Summary
Research Reports (Targeted: Executive, Development, Product, Marketing)
As I introduce templates, I get one of two reactions: “Wow, this is amazing” or “Thanks, I hate it.” Usually, managers, executives, product leadership, and tangential folks (like the delivery manager or a manager on a different team) really love templates and are grateful for the consistency they bring to deliverables.
Most often, it’s the rest of the UX and design team that says, “Thanks, I hate it” when I bring in templates. There’s a little bit of pride here -- “I’ve always done it this way” -- and sometimes a little resistance because they feel like they’re being told how to do their jobs. It helps to be clear that I’m not dictating how (although, when you get to processes, you do start touching how), but that we’re building a research library. And if all the books in the library were catalogued using different systems, how on earth would we find anything?
I believe it falls to user researchers to define the structure of how information about users is recorded, shared, and archived.
Sometimes, the pushback from the design and UX team is stringent. They just don’t see the value in spending extra time filling out a template than just doing the work. In those instances (and they’ve been rare), I tend to be agreeable, let them do their own thing, and double-down on standardizing all of my own work. What happens is that either slowly over time, folks begin to see the value of consistent formatting and quietly adopt it themselves, or the design and UX leadership is influenced by other departments’ satisfaction with the templates and enforces them as procedure.