How does user research usually proceed? The researchers go into the field, talk to the users, observe them, collect data, analyze it and present it to the product team. They make suggestions for iterations on the interface and wait for the dev team to implement them. But its familiarity does not make this process effective. It actually has potential problems on multiple layers.
4 potential problems with the traditional research workflow
1. Nothing substitutes meeting users directly
Some product team members may never encounter a single user in their job. For them, users exist only in the form of data and reports (if they ever read them, of course). But have they ever seen the product applied in real life with all the usability issues coming to the surface?
Have they seen their users hesitating or enlightened while searching for a feature or info? Reports cannot convey these little nuances that still hold great significance. That’s why nothing compares to talking to users face-to-face and seeing usability issues happen with your own eyes.
2. Information goes through only one filter
The researchers own the data. It means they bear the responsibility for collecting, analyzing, synthesizing, summarizing and presenting it to others. But in this case, the info goes through the cognitive steps and filters of only one person (or a couple) before it gets to the product team. Many details and insights can get lost this way. Having a cross-functional team in field research with permission to participate ensures all the info gets to different divisions quicker. More eyes see more.
3. Research has little effect on design decisions
Many researchers complain no one reads their reports or implements their recommendations. This results from research having no more influence on design decisions after the observations go before the product team. In many cases, some recommendations prove themselves technically unfeasible but only after conducting the user research and talking to the dev team. Had one of them in the field could have provided this information from the start, it could have saved valuable time.
4. Decision making is not effective
While the research data gets to the decision makers, it goes through several individual interpretations and thought processes of different team members. By the end, decision makers work with only fractions of the original data weighted by others’ judgements. This distances them from the users even more. Involving the product team directly in both collection and analysis of the data helps them make better decisions with better foundations.
We recommend you to check our free e-book, the Product Manager’s Guide to UX Design to learn more about Product Design processes!
So now we have identified the problem with the traditional research workflow. What can we do to make it more effective by creating a cross-functional field study team?
5 steps to carry out a field research with a cross-functional team
1. Have a solid research plan and cast
Having a solid, detailed research plan plays an even more important role for a cross-functional team with varying familiarity of the research methodology. Decide each member’s role in advance. Who can ask questions and who will only observe? You might need to bring some of them up to speed on the process. Clarify the research goals, the questions and the schedule for everyone in order to avoid unexpected situations and misunderstandings.
2. Limit the team size
The group size depends on the purpose and magnitude of the research but it doesn’t require a whole army. The best rule of thumb says to include at least one person on site from each key division that has influence on design decisions later. Don’t send more than two or three to individual user interviews since it will only frustrate interviewees.
3. Ensure a diverse team
Make sure your team contains people from various positions: researchers, designers, developers, business people.
More eyes see more and different eyes see differently. Developers might ask questions from a technical perspective (how could the product integrate with other systems the users have). Meanwhile, business people might be interested in how insights might affect their business strategy (asking questions about the users’ price preferences could have a big impact on pricing strategy, etc).
A more diverse research team ensures more diverse insights into a certain problem.
If you want to read more on smooth designer-developer collaboration, I suggest you read this article about design handoffs.
4. Do a collaborative data analysis
Check that your team continues the collaboration after the field study, too. They have to sit down and talk to each other a lot about what they have seen and heard. Talk about what the users did and how they used the product. Use this time to create user stories together. These stories boil down several key observations into one digestible story that team members share among each other. This makes the transformation of the info quicker and more understandable. Read more on collaborative data analysis technique here.
5. Let the team make decisions together
After doing field research with a cross-functional team, let them proceed with mutual decision making about the priorities and next steps. The team will usually have different views on the same issue, and that’s good. Considering all the different aspects and making a consensual decision will produce better output.
Doing field research with a cross-functional team can not only lead to better team alignment and communication but also help make better design decisions. Here, at our UX company, we think that nothing can replace letting everyone meet users IRL to see how they use the product with their own eyes. This way you place and keep users in your team’s head, improving their user-centered thinking in the end.
Have you ever tried to do a field research with a cross-functional team? What is your experience? We’d love to read about it in the comment section below!
Do not run away yet, there is an additional reading for you! Check out our Product Design book! We ship it worldwide.