What happens when the whole team joins user interviews

The CALC team is an agile team of four -- six if you count the Scrummaster and the Product Owner -- building a simple means to load price data into the original CALC tool. They’re an Agile team, which means everybody pitches in on everything to some degree, and here, in their own words, is some reflection on what happened when they all scrubbed in on the Discovery phase.

How have you been conducting the Discovery phase?

Mark Trammell (design researcher): We've been running remote interviews where the participant shares their screen and shows us their workflow. Before each team member's first session, the two of us would talk about the script and what to expect. During the session, while the teammate is taking notes, I'd moderate, grab a few screenshots, and jot down anything that stood out to me. After each session, the two of us would discuss what we saw. During the next team standup, the teammate would briefly share what they saw with the rest of the team. The notes would be shared with the rest of the team and the set of notes covering all the sessions are synthesized to develop broad findings. This is really great, it turns out, because often the researchers end up being the voice of the users to the team, but on this project, the whole team is plugged into the users directly.

Atul Varma (developer/designer): The head of GDS research has talked about how the research team is the “ambassador” for the user in actively building empathy, not just filing reports. They also require all their team members to have regular contact with users.

How did scrubbing in on user interviews help you in your core role?

James Seppi (developer): Scrubbing in on this research gave me a lot more empathy for the users. I was already pretty jazzed, but once I saw the terrible workflow our target users have to go through, I was even more excited to improve their work lives. It ended up being very motivating, and really helped me understand our product owner’s enthusiasm for the product. Before, I understood the logical arguments for why the project would be good, but now I have a real understanding.

Heather Billings (front-end designer/developer): Getting to see what they’re already familiar with is hugely helpful, because it helps me know how to present the information they need in a familiar way when designing the new tool.

Atul: This was hugely helpful in getting to an understanding of how to motivate people to take the extra step of using this tool for the benefit of undefined others in the indefinite future. When a person said “It would be really cool if we could just do this without all the complexity” it was just great, because it showed there is already a desire for someone to do this kind of thing. We’re building something people want right now, and we know they want it. That’s very motivating.

Heather: What I’m hearing from the developers on the team, me included, is that being part of these interviews is giving all of us a lot more confidence that what we are doing is the right thing, which gives us much more confidence that what we are building is really going to be needed.

Did you get anything out of direct contact with users that you couldn’t have gotten out of a report?

Heather: Doing interviews like this, rather than reading transcripts and reports, I have a LOT fewer questions. When I’m in on the research, I am able to ask the questions relevant to me and my work of the users directly, instead of through an intermediary. It’s a lot faster.

Atul: It’s easy to help a friend or coworker because I know them and I can see their problems directly. Working on bigger projects is harder, because I don’t get to empathize with the user. This gives me an opportunity to do that.

Mark: What generally happens when a researcher is doing all of this alone is that they are trying to both report on what they saw and communicate it to the team in a way that is meaningful to the team. Doing it this way lets the team see what is meaningful to them directly and individually.

Final thoughts?

Mark: Working with non-researchers is hugely helpful to me, too, because I get to see what they think is important, both in session and in the debriefing. Since the team has responsibility, and aren’t just passively watching, it lets me see what they needed to know, instead of guessing.

James: Interviewing is exhausting. It was a ton of typing and a ton of questions. After ninety minutes, I was fried. But if I’m writing code on an interesting problem, eight hours will just...melt away.

Atul: Sitting in on user research interviews makes me feel like those parts of The Matrix where they instantly get knowledge injected directly into their brain. Remember that part, “I know kung fu”? In this case it's “I know government procurement.”