18F/18f.gsa.gov

---
title: "What happens when the whole team joins user interviews"
date: 2016-08-16
authors:
- alan-brouilette
tags:
- user research
- how we work
- agile
- calc
excerpt: "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."
description: "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."
image: /assets/blog/calc-announcement/calc_homepage_2016.jpg
hero: false
---
The [CALC](https://18f.gsa.gov/2015/05/12/announcing-the-calc-tool/) 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](https://gdsengagement.blog.gov.uk/2015/09/03/periscope-about-user-research-for-gov-uk/)
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.”