The most brilliant ideas and the toughest problems can’t be solved if the team is not aligned. Fortunately, product design is not a one woman or man job. We work in a cross functional team full of diversity and creativity. Therefore, we just have to enable the team to do thorough user research together to develop great user-centric products.

This article is our approach to building high performance teams and solving the toughest problems in start ups and big organisations alike. I will cover a process we have iterated on multiple times with different product teams. However, it is not a brand new process and is inspired by great thought leaders from our industry.

With this toolbox you facilitate the team towards a meaningful and clear goal, provide structure, clarity and a respectful environment to work in. Think of it like a jazz band. We have the people, we have the process, now we need to create a common understanding of the music.

Get everyone involved

We focus our time and effort into learning about the users and the problem space that we work in. Evaluating their way of working and if they actually have a problem that we can solve or not. In order to get this far you have to establish trust and understand each other within the team. This process is the first tangible outcome that you discuss within the team and get feedback to align on the first couple of weeks. It builds trust and enables you to implement their feedback to create a common understanding on how to work and approach problems.

Getting the whole team on board with user research can be tiresome but as a result you empower ownership and make user centricity the forefront of your product development. Moreover, we highly recommend to unite with your SCRUM Master, if available, to move into one aligned direction. Ultimately, with this toolbox, everyone is involved in every step - engineers take notes, do competitive research and, if confident enough, also conduct in-context interviews. As a result you speak one language and make sure everyone is working towards the same goal without neglecting the greater context.

Establishing team work

Phase 1 is all about getting to know each other, discover together and align the team onto this process. Explain all the little methods and how every member of the team can contribute. Why, for example, a prototype persona based on assumptions and expert knowledge is important. - How it can help to recruit the right users for the in-context interviews. It is important to really explain the goals of each exercise and the emotional curve of research to the team and the product owner. If the product owner is not used to work in an agile and user centric environment you have to go deeper and explain what the benefits of research are! Be mindful that recruiting can take a while. If you are working on an internal product you might have access to them already. To source outside of your organisation will take longer.

Observe

In phase 2 the team researches everything together - Competitive research, in-context interviews, shadowing, technical potential, data sources, … Contrary to everyones belief, there is no perfect moment for you to research your users behaviour and their underlying needs. Therefore, whenever you have the chance use the simplest formula for research: Think of a hypothesis - a research question you have to answer, gather evidence with any method, interpret what this evidence means. Consequently you are organising the ethnographic study together with your team based on the most critical hypothesis you identified.

When it comes to ethnographic studies, people tend to think that this is a expensive and time consuming process. - Truth be told, I am not able to help with the expensive part. Depending on your product space and user group your company might need to allocate a higher budget for user research than it first intended to. However, every dollar spend is 100 dollars saved on product design and development time at a later stage in the PLC. - That is to say, I am able to help you with the time consuming part.

Be also mindful of the enjoyment of engineering. The engineers will want to start building as soon as possible. It is your task to bring the user into the team and keep the team focused on research. The outcomes of every activity are always shared and discussed. You have to get used to the mantra “show and tell”. Therefore, it is important to share the discussion guide and research plan with your team and get feedback. Remember you are doing the research together! Possible questions that belong in your discussion guide: How do people work today? What is missing? How can we ease their pain?

Reflect

Phase 3 is a critical one. You want to get your team into one room - a “war room” (based on Stanley Kubricks book Dr. Strangelove). This room will be your base of operations for the next week to analyse and synthesis the data you gathered during you ethnographic study. As a result, the entire product is at risk if you don't take the time to reflect thoroughly. It takes experience in reconstructing the data and a lot of organisations fail to understand the importance of this step.

Each team member goes through their notes and looks for patterns, needs, frustrations and general observations and writes them on post-its. Start looking for opportunities when the team is clustering them at the wall. The goal of this week is to form a clear understanding of the problems and align the team on one goal / problem for the next few weeks. Usual outcomes next to the aligned goal / problem are personas, a user journey and a possible mental modal.

Small tip: The three steps are intense and can be very tiring for the team. Celebrate your success, you have one aligned team and a goal for an MVP. Go out for dinner and drinks! You also want to grow a culture within your organisation. The outcomes of those past weeks should always be shared with your colleagues outside the team. Learn from each other at each step of the way. 

Make

At phase 4 it is time to create first artefacts. Together as one team you come up with the detailed problem statement. This is also the time where you usually prepare the Design Sprint. Most importantly, stakeholder management is highly important and relevant for a successful Design Sprint. Moreover, you have to manage expectations not only within but also outside the team. Explain the emotional curve of Design Sprints to the decider. Explain every outcome of each exercise to the participants.

D - Design, Data or Discovery - Sprint

Phase 5: The field study and the war room exercise should give you enough problems for a detailed Sprint Challenge. The D. Sprint also further aligns you as a team. We suggest to include at least half your team as participants. Furthermore, keep your participants engaged and have a great agenda prepared. After the D. Sprint it is important to write a summary and send it out to your participants. Letting them know what the final outcome is! As a result our close colleague the SCRUM Master will be able to start the product backlog. If you are interested in knowing more about Design (Data, Discovery) Sprints drop a comment below.

Evolve

The final step: To kill or not to kill, that is the question. Your outcomes from the research, the first design sprint and your rapid ideation sessions should give the team a great picture of the problem and solution space.

But one questions remains. Is it worth it to continue? Is there value for the user? Value for the organisation? How can we measure this? These are all questions your team has to answer and decide wether to kill the product and move to the next opportunity or pivot into the right direction. This is one of the hardest decisions the team will face. You are already emotionally invested into the product.

It is better to fail fast and often than waste valuable time on development. If you decide to continue and pivot don’t forget to schedule regular formative user feedback sessions to evaluate the value of your solution and not the usability! This will increase your chances for product market fit later on.

Bonus Round

These six steps are always evolving and we constantly experiment. However, there are a few things that you need to keep in mind when taking this process for your team.

• You need to have a dedicated team. These weeks are intense!

• You need to be able to get to your audience and meet them in time!

• You need to have an initial assumption or overarching question!

• Have weekly design critique sessions, which are not limited to discuss designs but also outcomes of your research and problems!

• You need to be able to analyse and synthase the data. If not, get help!

• You need to do the whole process as a team, together with engineers, data scientist, product owner and if possible sales.

• Make sure to share, print and plaster all your outcomes on the walls of the product room for everyone to see. It doesn’t cost much!

You can adapt this process to fit your way of working and your time frame. As an example the last team managed to align through this process within six weeks but it can take much longer. That said, never choose “beautiful designs” before functionality. You still have to be quick and have those iteration cycles as short as possible. You achieve this by continuously conduct formative user feedback sessions with your users together as one team. While testing always think about the most critical hypothesis you need to validate first.

In conclusion

Whatever design process you and your team adopts to do thorough user research, iterate, iterate, iterate. If at times it becomes difficult to align keep to this process and rearrange phases instead of skipping them. If you are interested in learning more about this process or any methodologies used, drop a comment below. Thank you for reading.

As a UX Designer I appreciate all the feedback I can get to improve this process. I highly encourage you to drop a comment below. Special thanks goes out to our team at BI X, who is embracing this toolbox to learn and come up with innovative new ideas and Mayumi Genda who has supported me, commenting on, and contributing to this work.