Build your user testing roadmap along your product roadmap

You undoubtedly have a roadmap for your digital projects. However, have you thought about building a roadmap for your user testing, i.e. a discovery roadmap? More and more product teams are implementing two roadmaps that operate in parallel: the first to steer the development of new functions, and the second to understand users' issues and to ensure that they are addressed during future developments. This is known as Dual Track Development.

Dual Track development, huh?

The benefit of operating two parallel roadmaps is to maximize your developers' effectiveness so that they only work on problems that will have an impact, saving development time, giving meaning to your team's tasks, and creating a way to kill off functionalities that have no potential.

In this article, I'd like to focus on the implementation of a user testing schedule, talking about this issue so that you can understand how important it is to identify your customers' problems, even before considering adding new features.

The good news is that this kind of roadmap is less onerous than an equivalent product roadmap. In reality, it will easily fit onto a standard sheet of paper!

Appreciating every testing opportunity

The first stage is for your entire team to recognize the incredible number of opportunities to listen to your users in two key areas:

1. The project lifecycle

It is never too early to reach out to your customers, and never too late, either! In fact, you must identify the problems they face before you even begin to think about the features, then challenge them throughout the development process, and pre and post-launch to start the process of optimizing your product. Whether it involves wireframes, prototypes or mock-ups, the graphical design stage is a perfect opportunity to take decisions based on user feedback. Indeed, it is much easier to make changes at that time than during the development phase, and this is the first moment where you can share initial, concrete feedback. Don't deprive yourself of this opportunity!

2. Test subjects

Once again, any digital interface is suitable for this approach:

Now that you can see what's possible, we will do some brainstorming to find test ideas that are aligned with your project.

Find ideas for user testing here

This involves a brainstorming stage. You may have references for different ways to generate ideas, but the important thing is to confront your ideas because they will help you to realign your team around the topics in respect of which you need to listen to your users. In terms of the format for ideas when listening to your clients, we recommend that you keep things simple, because there is no need to go into details yet. Personally, we use post-its and write down the three following items:

• The question or information you're looking for: what do you need to know? What hypothesis do you want to challenge?
• The test subject: site, prototype, application, in-store terminals, content, specific function, functionality offered by a competitor, etc.
• In what capacity: customers, co-workers, partners, etc. This will help you to specify who is experiencing the situation you are looking to address.

Rank your ideas

So, now you've finished brainstorming and are faced with all kinds of ideas for tests to carry out, to get a better understanding of your customers, and to choose the right developments to pursue.

Except that you can't test everything and even if you could, it wouldn't be worthwhile. To choose the most valuable tests, we will challenge each opportunity using a grid inspired by the PIE model used in A/B testing.

One difference, however, stands out immediately. This is the fact that our testing are generally carried out before the product is launched, and therefore restricted. Conversely, standard A/B testing involves the public as it is carried out after the product is launched. We therefore see the following two axes:

Priority, which measures the immediate availability of the test and also how easy you anticipate it will be to implement your findings. There will, therefore, inevitably be an element of uncertainty, but let's simply say that this element is designed to measure the practical effects.

• Priority, which measures the immediate availability of the test and also how easy you anticipate it will be to implement your findings. There will, therefore, inevitably be an element of uncertainty, but let's simply say that this element is designed to measure the practical effects.

• Impact, which combines the importance of the subject with the prospects for improving it significantly. For example, your purchase funnel is undoubtedly more important than the pages that describe your capabilities. On the other hand, if you've spent the last two years optimizing your purchase funnel, it might be time to move on and address another area that has greater potential for improvement.
  

Formalizing your discovery roadmap

Calendar, project plan, or something else?

We have prioritized the various ideas to be tested. You now need to schedule them in order. To achieve this, we don't need to assign dates to each activity. We will simply use the "Now, Next, Later" grid.

• Now: the tests to be carried out over the next few days. The fewer, the better, because this is realistic and demonstrates that your effort in prioritizing things has been successful.

• Next: your backup ideas, to be pursued once you've completed the tests in the Now category.

• Later: Test subjects to be addressed over the coming months. Remember to retain flexibility because, even if they seem important today, they might not matter in a few weeks' time.

How to shift priorities in the Now Next Later plan

Here is a table that seems to work well for our clients:

1. Anything that is both difficult and lacking in impact is simply removed from the roadmap. It might seem a shame at first glance, but it is also more realistic.

2. If, on the other hand, something has a high impact and is sufficiently feasible, it should be incorporated in the Now or Next phases. Typically, only one or two tests fall within the "Now" and others will naturally fall into the "Next" column.

3. All other tests (high impact, but low feasibility, or highly feasible with limited impact) go into the "Later " column.

What does this test roadmap look like in concrete terms?

Here's a practical example featuring Ferpection testing. You will note that only a few tests go in the Now category, so that we can be certain of completing them. Each test is linked to a problem that we will attempt to resolve for our users. We are also ruthless when it comes to deleting a test, rather than letting it continue aimlessly for weeks at a time.

Now it's your turn to build your test roadmap!

If you're interested in this approach, and you'd like support in implementing it, it's worth knowing that Ferpection is holding a training workshop dedicated to creating your discovery roadmap.

We are always asking our clients to help us define Ferpection's future during co-creation workshops. On this topic, check out our exercises and ideas for your creativity sessions.