Using your own product consistently — or dogfooding — is a great technique for validating your work, especially when you fit the description of the target user. But it’s just not enough to create a great product. To do that, you need to talk to users and truly understand their needs, goals, and pains. That being said, it’s often easy to overlook who should be included in the research process. In this article, we’ll explore the benefits of including development teams in this research and techniques for doing this successfully.
We started thinking about this problem during our last research study, when we noticed something interesting: many of the developers we interviewed seemed confused by what we were doing, our methodology, and/or the format of our research. Our study included many different kinds of developers (yes, we know that developers cannot be lumped into just one group): some who used our products and some who didn’t, some who were in very technical roles and some in purely management roles, in large companies and small. And while most people we spoke with were very cooperative and volunteered great information about how they work, we discovered that it was the process of product research that was unfamiliar to them. So unfamiliar that they often didn’t know why we wanted to speak with them or observe their work.
It also helps our users to see that our developers are listening to them and trying to understand their workflows. By including developers on our team in interviews and other research and design activities, we’ve seen the following benefits:
Start at square one. Invite your developers to the next set of user interviews or usability tests that you’re planning. Tell them what you’re doing and why, and make them a part of the scheduling. It’s more than just involving them in the process though; it’s ensuring that you’re acting as one team unit. It’s not about us (designers and PMs) and them (developers). It’s only about us — and how all of us want to learn more about customers so that all of us can build a better product.
We started thinking about this problem during our last research study, when we noticed something interesting: many of the developers we interviewed seemed confused by what we were doing, our methodology, and/or the format of our research. Our study included many different kinds of developers (yes, we know that developers cannot be lumped into just one group): some who used our products and some who didn’t, some who were in very technical roles and some in purely management roles, in large companies and small. And while most people we spoke with were very cooperative and volunteered great information about how they work, we discovered that it was the process of product research that was unfamiliar to them. So unfamiliar that they often didn’t know why we wanted to speak with them or observe their work.
Why aren’t devs included in design research?
We started to think about the reasons for excluding developers from the design research process and have an educated guess as to why it happens: time is money. Those in product management or technical leadership positions have felt that tug towards a large goal. In those cases, any extra developer activity outside of coding seems unnecessary and superfluous. We think that most organizations feel this tug and deal with it by protecting their developers from anything that might be considered ‘outside the scope’ of their work. However, the very thing they consider to be ‘outside the scope’ might actually help developers to move faster and reach that deadline sooner.Why you should include devs in design research
Involving developers in user research is a win-win situation. Even though our developers are creating a product for other developers to use, it helps for them to understand the context around its usage and the constraints and pains within different organizations.
It also helps our users to see that our developers are listening to them and trying to understand their workflows. By including developers on our team in interviews and other research and design activities, we’ve seen the following benefits:
- Empathy building. Recently, we overheard two developers on our team asking the question: “Who’s the user for that?”. We’ve also overheard developers talking about specific personas by name: “What would Eric think about that?”. Our teams are thinking more about the end user and less about whether it’s just a cool feature or would be fun to code.
- Team buy-in. Sometimes (especially with developers building developer tools) developers will assume that they know and understand user needs implicitly. They don’t “feel” the pain. By including them in the research process, they get to see first hand how users’ needs might differ from their own. This helps to gain traction and buy-in around product changes that might not be exciting or resonate with them personally, but are still necessary.
- Feasibility feedback sooner. When developers participate in research, they often want to join design conversations as well. And they can often tell us whether something is feasible right away. We don’t waste any time wondering about the technical time and risks involved because our developers let us know the constraints right up front.
- Diversity of thought. Involving different roles in research also leads to better follow up discussions and research synthesis. A developer will make different connections and interpret different things than a designer or product manager. I can’t tell you how many times in follow up discussions, I’ve said, “Oh, I didn’t think of it that way.” Diverse input = all-encompassing output.
- Research empowerment and ownership. When developers are included in the research, it starts to become less enigmatic to them. They get more comfortable with it and learn more about the research toolkit and techniques. This enables them to feel more comfortable when they want to run their own research studies (yes, it can and will happen!). And it’s really great to see a small dev team interviewing people without any prompting at all.
How to get your devs involved in research
Although we build products for development teams and much of our experience is around including developers in dev tool research specifically, we think that any team creating products should consider including their dev team in product, design and usability research. Here are some ways in which you can get your devs teams involved (or how you as a developer can involve yourself) in the research that will shape the success of your products.
Start at square one. Invite your developers to the next set of user interviews or usability tests that you’re planning. Tell them what you’re doing and why, and make them a part of the scheduling. It’s more than just involving them in the process though; it’s ensuring that you’re acting as one team unit. It’s not about us (designers and PMs) and them (developers). It’s only about us — and how all of us want to learn more about customers so that all of us can build a better product.
- Invite your whole development team to the interviews. Don’t just send them a random calendar event, invite them in person. In order to keep a good dynamic with the interviewee, make sure there’re only two people in the room — one to lead the interview and one to take notes. You can still have more people join, but these people should be in another conference room, muted, with their video off (ala the Google Ventures Sprint interview setup). They’re just listeners. Encourage them to take notes during the interview/test session.
- Always schedule the time to discuss an interview or usability test right after the session. Ask everyone to talk through the things they heard, observed, and inferred. These are all different and distinct parts of synthesizing research. If some people don’t feel as comfortable speaking aloud, ask everyone to write things down on stickies and post them up for discussion.
- Involve developers in low-fi prototype creation that pulls in the user feedback they heard or observed. Many non-designers will tell you, “I can’t draw.” I often tell them that actual illustration skills aren’t necessary — if you can draw a line, a box, and a stick-figure, you can participate in a design exercise. Pulling them into these exercises will enhance the feeling of team cohesiveness and can prevent future roadblocks around feasibility.
- Invite some users (or people who represent a product persona) to come into the office and have a conversation about their problems, needs, and feedback with the development team. This kind of structure can sometimes feel more casual and conversational and still allows developers to learn about users.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
