We started the session with the topic title: Moving from Data to Design Insight. After the discussion, I found it a lot more appropriate to change the title to Moving from User Research to Design Insight.
There are plenty of resources discussing the importance of user research for the UX process. However, there seems to be fewer discussions around how to move the information discovered during the user research process, into something that is really useful for design. In other words, there seems to be fewer discussions over the analysis and synthesis process.
As a mid-level user experience researcher, I wanted to find out and see how other UX practioners made sense of their user research information.
So, how do we move from User Research, to finally derive Design Insight?
- Derive ‘Problems to be Solved’ before the Research Process
The group shared the concept of ‘Problems to be Solved’. Start first by determining the problem statement, and what you would like to achieve with the research process, BEFORE starting the research process:
E.g Problem Statement:
People are throwing away too much leftover food.
E.g Research Questions to be answered:
- What are people trying to achieve in their lives?
- What are people trying to achieve with my app/website?
- What are the key difficulties they face while using the interface?
- Why are they not able to do what they wanted to do?
Use secondary research to find out an overview (e.g number of searches around a certain keyword, clicks/hits of sections in current website, overall trends, perspectives), followed by primary research (e.g user interviews) to go in-depth, to answer the research objectives. Specifically, I would use secondary research to find out the WHATS, and primary research to find out the WHYS which I have discovered during the secondary research phase.
Having your problem statement and research questions laid out, and using primary/secondary research to help you answer these questions, will give you the answers to know what to design/prototype in the design phase.
- Use ‘Jobs to be done’ to guide your research process
Another concept that was shared was ‘Jobs to be Done’. Specifically, figure out what are the functional, social and emotional jobs that the product needs to be achieve for its users and stakeholders.
This is an extension of Clayton Christenson’s ‘Job To Be Done’ Theory, and seems to be a nice framework to figure out the types of jobs the new app/website should be doing.
- Figure it out with your team
Lastly, the most obvious answer is to discuss it with your team! Have cross-functional convergence meetings where research, design, development, production, business teams etc. get to hear about what was discovered in the research phase, and analyse the research findings together. The keyword here is cross-functional. Involve different parts of the team (eg. developers )early also encourages buy-in and avoid the situation of specifying unrealistic design and technical requirements. This will help the team decide the different implications for design, prototyping, content and development etc. for the project.
The group also shared that it will be best to have a good project manager to facilitate these sessions, and bring people from different teams together into this convergence meeting.
Finally, itt will also be useful for teams to present their own information and domain knowledge at these convergence sessions, so that they have a shared team knowledge on how the project can proceed.
In summary, first start with the Problem Statement and the Research Questions you want answered. Supposing you did not derive the problem statement/research questions beforehand, you can also categorise your findings into ‘Jobs to be Done’. Lastly, and most importantly, involve your teams in the analysis of the findings (as much as possible), because the success of a product also depends on how well your team can adapt your design/tech solutions etc. to your users’ needs.