UX Research Playbook

If we do not understand who we are building for we build products for nobody.

Using research to support product decisions is a way that we ensure that our product development process is driven by users needs.

Research at its core aims to bring in the user needs of the people we build products for. With these voices, it creates empowered product decisions that are validated and targeted.

In open source product development the way we research to inform product decisions is done with a bit of a twist. The twist embraces various principles which we will share more about below. While many principles guide open source product development for this playbook we intentionally mention three.

The below steps have 3 principles which we’ll outline briefly:

1. Work in public

Work in public as much as possible and share the work as it progresses. This might include sharing work before it is finished.

2. Reach consensus

Allow the community and group to make decisions together and create processes that ensure that consensus is reached as the project proceeds.

Invite collaboration

The goal of this document is to outline the main steps taken when kicking off a research sprint. The following playbook is as mentioned a book to play; there is no set of rules to follow. Feel free to edit and modify this process as you and the team feel fit.

#1 Set the direction

Initially, the project may enter into the community looking for expertise on improving their existing product. They may also enter into the community looking to build a product from scratch. Usually, the project would have a kick-off call where they meet and set the direction together.

Goals and vision

Here we are looking for a high level overview of the project itself. Some questions that we can ask at this stage are:

What is the project about?
How did the project start?
What is the project's vision and where would they like to go in the future?
What is the user need (pain point, problem, etc.) that the project aims to solve?
Who is the intended target audience?

ii. Resources

Next, we’ll identify the capacity of the project to commit time and resources to conducting the research sprint.

Who is available to commit time and effort?
What period is the project looking to have this complete?

iii. Consensus

During this time it’s an idea for the team to brainstorm together as to what are the most important questions they would like to answer. The overarching goal of this exercise is to establish consensus in the group.

Essentially we are moving from the problem space to the solution space. Before moving into the solution space, the team should identify which areas in the problem space if solved will have the highest impact on the current product.

One quick way that consensus can be reached is by all collaborating on a Figjam/Penpot board. Link to resource.

Here’s how to do this.

Set up an open Figjam/Penpot board.
1. Asynchronous option: A variation to this is to allow for time to work on reaching consensus asynchronous. Practically this would be where the steps 2-6 are done by the group in their own time and then setting a date by which everyone has contributed.
On the board create 2 defined areas:
1. Area 1 = problem space.
2. Area 2 = voting space
Set a timer for 5 minutes and allow everyone to make sticky notes about either:

Problems that they would like to solve
Problems that they hypothesize that users are facing

Copy over the problem cards to a new area and label that voting
Voting:
- Set another timer for 2 mins.
- Everyone now can use a thumb to vote. Everyone gets 3 votes
Identify the top 3 voted areas
- Are they from a specific part of the user flow?
- Are the voted problems related to one screen?

Through this process of bucketing the team would have reached a consensus and narrowed the scope of the research effort. This then leaves the project team with a clear idea of the area of the product that will be focussed on during the sprint.

#2 Plan

Next, we move onto writing the project plan. This is done collaboratively and in public.

i. Define research method(s)

The first step is to define and agree upon which research methods should be used. The Bitcoin UX Research toolkit can help with selecting the appropriate mix of research methods and provides guidance about how to interpret the data.

The main questions are in these larger buckets:

1. Are we building the right thing?
2. We are going to launch, what do we do?
3. How do we set up a long-term research process?
4. How do we get buy-in from the rest of the team?
5. How do we come up with solutions to user problems?
6. What do we do with user feedback?
7. What are the needs of our users?
8. What are the problems our users are facing?

ii. Create a plan

Next, we’ll create a shareable plan in a document that would allow others to add comments and collaborate on the document in real-time. The project can choose to use Google Documents and turn on the share button which will allow readers to comment on the document.

The document will usually have a rough outline of the following areas:
1. Project background
2. Research goal
3. Research questions
4. Research method
5. Important links
6. Task list with

Status
Timeline
Related files
Notes or who is assigned to the task

iii. Work in public

Working in public means to sharing work as you go along. This could begin right at the point where you’ve created a plan and are about to kick off the sprint.

Inviting feedback for collaboration on your plan can be done in various channels.

They can be shared on:

Nostr
X
Bitcoin Design Community
Linkedin

It can also be shared with a selected group of people by messaging them directly. Invite people to comment on the research plan.

#3 Finalize

i. Revise

Now that there’s been some feedback on the initial plan created, it’s time to revise the plan.

The feedback at this stage could be a slight change to the research plan or it could be a complete pivot. This is one of the joys of working in public and opening the project to the larger ecosystem to provide feedback.

ii. Collab

Next you’ll create a public space where people who are contributing to the project can collaborate and keep track of the initiative. This can be done in a kanban style or in a project milestone format.

Kanban format example
Milestone format example

This serves as a great place to continuously go back to as the project progresses. We can keep track of the tasks that are completed as well as those that are yet to be completed.

#4 Execute

Next we’ll move onto the execution of the part, this would involve the actual testing or user interviews. With the execution of the research, some points to bear in mind are:

If there is more than one person conducting the interviews there should be a discussion or a guide book to ensure that everyone is conducting the interviews or doing the tests in the same way.

Ask people for consent with using the data. It’s always best to be open that the research findings will be shared in public and to get consent for this.

#5 Analyse

Analysing research can be done in different ways.

AI method:

Interviews can be automatically transcribed using an AI tool.
Export the transcript as a PDF
Upload to an AI tool and one can then chat with the data
Starting question “Bucket this data for me”
After the data has been put into larger buckets you can then start to ask more granular questions about the buckets that were mentioned.

Affinity mapping:

The traditional method of analysing UX research is using affinity mapping. This can be done by doing the following:

Export the transcribed interview into a document
Highlight the most interesting points
Copy and paste those points into separate sticky notes in Figjam
Bucket the sticky notes into areas that are similar, some examples might be:
Part of the UI it is referring to
Positive comments
Areas for improvement

#6 Share

Sharing the research that has been done makes it accessible and public to everyone involved on the project. There are two parts with sharing the research:

Share research findings with the project group
Share the research with the project and invite the group to think about solutions together. There is a section in the UX research toolkit which shares how to share research and how to share.

Make the research publicly available
Documenting the research in one place so that it is visible to everyone is good to set a historical base for other projects to look at and review. Research when made public is something that becomes available to everyone to refer to and share.

There are many places in which research research can be documented, the easiest to find is simply filing an issue on Github and continuing to add comments to the issue as new research becomes available.

#7 UX Solutions

The last step is sharing recommendations with the project based on the research done.

This can be done in 3 ways:

Encourage design thinking:
Open source projects thrive on collaboration and sharing solutions together. The traditional way of presenting research is to present solutions. Instead of presenting solutions show the challenges to the team that users are facing and allow the team to come up with UX solutions together.

Often with bitcoin technology the UX solution has to be practically implementable as well so having both the designers and developers on a call where the question is asked: how can we solve xyz?

User flows
If there are screens missing in the user flow that came up as a result of doing the research then it would be good to:
- First map out the current user flow
- Add in comments to the screens and make suggestions
Screen iterations
Take individual screens and then re-design them based on user feedback.

Bitcoin UX Research Toolkit