When experience matters (and when it doesn’t)

A little while ago I wrote this, which turned out to be more controversial than I intended.

increasingly of the view that domain expertise is a hinderance not an advantage when you’re doing service design & user research.

— Leisa Reichelt (@leisa) February 13, 2015

I wrote it after having several encounters, in close succession, where one of these had happened:

1. Recruiting scenarios where people assumed that previous domain experience was more important than the overall research experience, and capability, of the researcher.
2. Working with a researcher who had domain experience on a particular topic who kept shutting down team conversations based on experience they’d had in previous projects, which the rest of the team had not been involved in.

These are both anti patterns of domain experience in user researcher and should be avoided.

Recruiting user researchers

When you’re recruiting for a user researcher, there are three things that teams should be looking for:

1. Firstly, ensure that the user researcher has experience in the methods of user research you expect you’ll be using on the project. For example, don’t hire someone who has a decade of experience doing usability testing when you need someone who is strong in contextual research to work on the discovery phase of your project.
2. Secondly, be confident that the user researcher cares about the quality of the service that their team ultimately delivers, will be able to hold their own in the team and will be effective in communicating research findings in a way that compels the team to act on them. This is the hardest criteria to meet. Too many user researchers have had a great time doing research and making reports, then leaving the teams to do with it what they will. You want a user researcher who wants to have ‘skin in the game’, and wants to see their research valued and used in making service design decisions and in setting priorities for the team.
3. Finally, if the researcher has previous experience in the subject domain of the project, this can be an advantage. But only once the first two criteria have been met. These first two criteria are much more important for user researchers than subject matter domain expertise, and they’re also pretty hard to find.

When you hire a user researcher, the domain they should be most expert in is user research.

In teams, diversity is a strength

For most projects, having some subject matter expertise is essential. In most cases, that would be at best inefficient and at worst dangerous to do otherwise.

What is equally problematic, though, is a team full of people who have extensive experience working on the problem space they are just about to tackle.

Teams like this have so many shared mental models and assumptions about how things work, what things mean, where the constraints are, and how people think and work, and, despite their experience, not all of these things are right.

The CivicPatterns website calls this the Clean Room pattern and says:

If your project operates within any bureaucratic system, ensure that the person responsible for its design knows as little as possible about how the existing system works.

Most people hate dealing with bureaucracies. You have to jump through lots of seemingly pointless hoops, just for the sake of the system. But the more you’re exposed to it, the more sense it starts to make, and the harder it is to see things through a beginner’s eyes. Therefore, when building a system that helps someone bypass bureaucracy, start by designing how the system should be, with as little pre-knowledge as possible, and then, when you need to add any complexity, work as hard as you can to hide that from the user.

Lack of diversity in experience-levels (and lack of diversity in general) in the team will reduce their ability to consider a full range of service design options that can streamline the experience for users. This will limit the potential for transformation.

There are some roles where experience the domain of the project is essential and teams would be foolish not to include them. Designers and user researchers are not those roles.

Design your teams so they have diversity, in gender, in age, in backgrounds and in subject matter expertise and you’ll design better experiences for your users.