Swimming with Dolphins

While working on a new feature for radiation therapy planning software, I interviewed Nicole (not her real name) about her work as a dosimetrist. A dosimetrist is the person who maps out the treatment plan for someone receiving radiation therapy for cancer treatment. This means defining the size and shape of the tumor, any organs such as the heart that need to be avoided, specialized zones to ensure maximum efficacy, etc. all from a set of images taken of the patient’s body, and every body (literally) is different.

Nicole, like many other dosimetrists, not only has years of experience but a degree in medical dosimetry. She is, to put it mildly, an expert. I knew ahead of time that there was simply no way that I would be able to understand the problem as well as she did. I needed a different approach.

Working with experts can feel a little bit like swimming with dolphins: you can get in the water, but you’ll have a hard time keeping up.

Thankfully, this is something I have experience with. Working with experts, that is, not swimming with dolphins. Almost my entire design career has been spent working with expert users in industrial and medical domains. The key to success is humility: acknowledging that you will not reach that same level of understanding of the problem as your users, and that’s ok. You need to stop trying to design FOR experts, and start designing WITH them.

This is where co-design, or participatory design, is not only valuable, but essential.

What is Participatory Design?

At its most basic, participatory design is about the democratization of the design process, and involving users in actual design decisions, as opposed to just research participants.

One of the earliest uses of participatory design as a guiding principle was in the UTOPIA project in Sweden in the early 1980s that engaged with the Nordic Graphic Union for the design of computer graphics workstations[1]. One of the remarkable things about this case study was that the researchers were required to involve the end users in the design process because of rules and regulations around creating software for unions in Sweden at the time.

Because of this principle of democratization, participatory design has also been used successfully with historically marginalized groups so as to avoid imposing a power dynamic as part of the design process. Whether this is successful or not is a much more complicated issue that requires it’s own space.

Why we should trust our users

There is an element of distrust of users in a lot of design aphorisms, such as that users don’t actually know what they want or that famous Henry Ford quote. It’s honestly quite insulting and treats our users like children who have to be coddled. As a side note, children also often know what they want.

Leaving aside Henry Ford’s virulent antisemitism, that quote is too often used to insult and denigrate users, when in fact it is a great lesson in why participatory design is so valuable. While a “faster horse” may not be the best solution, a good designer knows to look for what the real problem is: faster transportation. The fact that the answer to that is a car has more to do with the enabling technology of the time than anything else. (Personal blimps, anyone?)

Users may have trouble expressing a solution outside of their personal experience, but they know what their problems are, and I’ve seen a lot of (good) designers have trouble getting past their own preconceived notions. That’s why a designer working with a user is so valuable. The designer can push the user on possible solutions, and explore lots of different options, and the user can push on the designer where there is a gap in knowledge, which there almost always is when dealing with an expert.

So, how do you do this?

There are many different ways to work with expert users. These are just some of my favorites.

The Pen

During one workshop I ran, there was an interest in the group to get something concrete on paper, so I decided to use “acting as the pen” to establish a rough UI for a specific workflow, while validating requirements and building a glossary of well understood terms. It sounds like a lot, but it is quite easy.

I started by drawing a wireframe based on my best understanding of the problem. People in the audience chimed in and provided feedback in real time, correcting things I had wrong or adding additional insights. Developers are great to add to this mix, too, because they can provide immediate insight into how difficult a solution is to implement, and we can immediately iterate around other ideas.

When you are doing this, make sure that someone is taking pictures throughout, and even better if you can record it on video. This is a great workshop activity to get everybody involved, and can really raise the energy of a room.

Why does this work?

Most people do not see themselves as creative, and they especially do not see themselves as artistic. There is a social anxiety about drawing in front of other people, so you can remove that by doing the drawing yourself, and having them direct. Plus, it’s much easier to correct something right in front of you then discuss hypothetical designs.

This works great both one-on-one or in a group in front of a white board, it works in person on a piece of paper, or remotely in design software, especially one that is designed for collaboration (you know the one I am talking about).

Bodystorming, Storytelling, and Paper Prototypes

This is another great exercise that is not just very informative, but can be a lot of fun. I used this on a research project that looked at redesigning the locomotive cab. We had a group of engineers and conductors for a few days in a dedicated design space. First, I built a very rough paper prototype of a locomotive cab with a single chair, some large foam blocks, controls drawn on printer paper and post-it notes, and a rolling whiteboard as the window.

We went in with the hypothesis, based on preliminary research, that drivers were not getting all the information they needed. We had a single ask of everybody: “Tell us a story about a time when you didn’t have the information you needed in the cab.” We had them divide into groups of two, and write a script for the story, and then act it out.

I have never heard so much cussing during a research project before or since, but that also shows you how involved the participants got.

Why does this work?

Telling stories is a lot easier than coming up with immediate insights. Plus, having something physical to interact with, especially when the thing you are researching is physical, helps tremendously in getting people-oriented in the space: participants can point to specific things (air boarding) and it helps ensure a shared understanding.

Some other advantages of Participatory Design

Ethics and Accessibility are baked in (mostly)

While this is not a guarantee, it’s much harder to ignore ethics and accessibility when the people affected by it are also part of the design process. Assuming you have a good relationship with your users, and they actually have a modicum of control of the design, they will point out the places in your software that hurt them or put them at risk in ways you (as the designer) may not be aware.

It Engenders Greater Buy-In

When you design with the people who will be using the product, they will be more likely to be engaged in the final product because they had a hand in designing it and they can see the results of their work. This is especially true in enterprise, industrial or medical software. You know, experts. When Nicole sees a variation on her idea in the product, she will have a lot more faith that it is the better solution.

It has requirements gathering, usability testing, and design all in one!

It’s like installing a warp drive in your design process. Instead of going from talking to subject matter experts, synthesizing the research, developing insights, building wireframes, and conducting usability testing, you can do a little bit of all of that in one fell swoop. To a point, of course. You should still do those things, it just makes them more effective.

It’s a form of design evangelism

Participatory design isn’t just about including end-users in the design process, but stakeholders, product managers, developers, anybody really. When you expose everybody to the design process, it shows the value of design, and when you include stakeholders and developers in design decisions they also will have greater trust in the outcomes. And why not? The people who will be building the software will be able to provide invaluable insight into what is feasible.

A philosophically different view of your users

One of the biggest issues I have found with design education is that, in the worst case scenario, it creates designers who believe that they know better than their users. This kind of arrogance is detrimental to the whole practice. This attitude shows up in all kinds of places and it’s just plain wrong. Emblematic of this is an article from 2001[2] wherein Jakob Nielsen declares the “First Rule of Usability? Don’t Listen to Users” and “Users do not know what they want.” One would hope that Mr. Nielsen has updated his thinking since then, but I haven’t been able to find anything to that effect.

This phrase is the height of hubris, not to mention incredibly patriarchal. It’s not only untrue with your typical user, but even more so with an expert user, who not only knows what they want, but knows the domain a whole lot better than you do.

The fact is, users DO know what they want; they just aren’t always able to articulate it. That’s where designers come in.

While not a panacea to this problem, participatory design goes a long way to forcing the designer to be humble by having them give up that all too often coveted gem: the design decision, and I don’t think that’s a bad thing.