Designing Explicit Interview Guides

Censored excerpt of the improved interview guide.
I learned a thing this past week, so I figure I’ll share with the class.

As part of a product definition, we needed to conduct user interviews that aren’t included in our SOW. Our initial research plan, which I thought was quite thorough, included a timeline, activities, budgets, goals, and a gap analysis. Thorough or not, it was rejected. The stakeholder wanted more information — she needed to see our questions, and wanted to know how the collected responses would influence our designs. So I hunkered down with my team to catalogue the rationale for each question.

I say hunkered…but it didn’t actually take very long. And at the end of it, we had a much stronger interview guide than when we started.

The initial draft of the guide was a collaborative effort, but it turned out that many team members had differing ideas about why a question would be valuable. By talking each of them through with the group, we all gained a broader perspective on what we were looking to learn and how the findings would influence our design work. We also discovered some questions were poorly worded for their intended goal. Together we workshopped them for greater effect. It was a powerful learning opportunity for everyone, especially those team members with limited research experience.

Thanks to the stakeholder’s request, the whole team is more prepared than we otherwise would have been, myself included. Going forward, I’ll begin incorporating this into my process, both when working solo and with a team.

Oh, and it worked. Our stakeholder gave us the green light to proceed after reviewing the improved interview guide.