User Experience Research With GitHub

2015-01-03

How do you organize and archive your research, interviews and testing sessions?

The most essential principle in user research is making it ridiculously easy to share findings across teams. Insights that are siloed aren't very useful. At GitHub, all engineering, design, support, legal, finance, sales, marketing, and documentation teams' workflows are driven inside of GitHub, so I use our platform to organize research.

Here's the rub: I'm not an engineer, so creating this workflow took time to learn, but it's worked out better than I could have hoped and gets research closer to the people working on projects. Our user interviews and insights sit next to code, so as you might imagine, interesting things always happen.

How we use GitHub to organize and share data

• Research studies–Begin as GitHub Issue. We discuss goals, hypotheses, approach, interview guide, and interview schedule.

• Customer interviews–Begin as an empty pull request, and the engineers/designers who pair on interviews share notes. The notes become a markdown file merged into a folder with a URL, so it's easy to reference it in future discussions and studies.

  • Using a pull request allows us to use GitHub @ mentions to call out specific teams and individuals if we learn things along the way that are interesting to people not present at the interviews. (All remote interviews are recorded on BlueJeans[RIP], and we include a link to the video inside the notes).

• Reports–Begin as an empty pull request, follow a simple template, and are driven by discussion and collaboration:

  • Abstract/tl;dr of our findings.

  • Background: Why we studied this, who participated, what we learned.

  • Observations: What we observed from our interviews.

  • Recommendations: Things to consider for shipping to GA.

  • Aspirations: Planning for the future.

Everyone's a researcher

We collaborate in writing the report and then paste the abstract, background, and recommendations sections as an issue with @ mentions to create cross-references to both teams and any code (pull requests) or relevant issues. Having research associated as a cross-reference within the actual code timeline is useful.

The interview guide, interviews, final report, and other assets (photos, images, etc.) all live together inside a folder inside a repository called "uxr."

Shared history

The final report is merged into an internal Jekyll blog (also hosted on GitHub), becoming the truth source for all studies. This is especially helpful for future employees who want an easy way to get at the findings but who didn't go through the process of how the research came together. Unlike the uxr repo, the blog is also pretty nice to look at and mobile-friendly.

Outcomes

Over the past two years, we've created, adopted, and shared research-driven strategies across the company. What began as an experiment for us has helped change how we look at developing products.

We're smarter together than we were managing individual channels. Using GitHub to organize our research has brought us closer to our customers' needs, which has helped develop a culture that embraces empathy.

Keeping research organized and alongside our applications code and inside of our engineering workflow has created immensely valuable connections between the humans who design and develop GitHub and the humans who use GitHub.