User Experience Research With GitHub

Posted by Chrissie Brodigan on January 3, 2015

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

The most important principle in user research is making it ridiculously easy to share across teams. Insights that are siloed, aren’t very useful. At GitHub all engineer, 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 literally sit next to code, so as you might imagine interesting things happen all the time.

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.

  • Cutsomer 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 and has 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 to 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, 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 discussionand 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 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 issues that are relevant. It’s useful to have research associated as a cross-reference within the actual code timeline.

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

Shared history

The final report is merged into an internal Jekyll blog (also hosted on GitHub), which becomes the source of truth 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.


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 to change the way we look at developing product.

We’re smarter together than we were managing individual channels. Using GitHub to organize our research, has brought us closer to our customers’ needs, and that has helped to developed 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.

*Photo credit: kindest colleague Jordan McCullough