Your team has broken down a project into manageable stories and is trying to identify the priorities of the various tasks that will pave the way for the efficient completion of a project. Product owners prioritize the tasks based on the features that the business finds to be critical to the bottom line. Tech may have a different take on those priorities that may be from the perspective of technical dependencies. Hopefully, there is a big overlap between how various teams see the prioritization of the work. But how does one really make sense of the priorities for iterating to the end goal of the project effectively? How about we look at this from the what the user may expect?

The product you’re building has a purpose and solves a problem for users. Understanding the problem clearly and defining the solution are critical. How would a user use the product to go from A to Z? Let’s talk about red routes. If you’re not familiar with the term, it is a term borrowed from London’s transportation system, which emphasizes that the most widely used roads by the largest number of people must be efficient and require priority above all else. Withing UX, red routes are the most frequent and critical activities users would typically undertake to utilize a system to achieve an end goal for which the system was designed. For instance, if one were creating an email platform, some of the red routes would be the following:

• creating an account
• sending emails
• receiving emails (the user is mostly passive with this one, but the system still needs to fetch new emails)

Email applications typically have more bells and whistles; these just happen to be the most common and critical activities users undertake. Ok, but how can this help prioritize a product backlog? Once you’ve defined the red routes of an application, you will have a much better idea about which features should be prioritized high and which ones should be lower and in need of future iteration. In the best case scenario, these tasks should be defined after some research and the project as a whole should be the result of identifying a need. This is the best way in which to identify what users truly want.

Mapping Features in the Usage Matrix

If you already have a list of features the system should include, great! But be flexible because some of the assumptions you’ve already made in your mind about what should be a priority and what should be secondary may be shattered. We need to follow a pattern to get a more accurate measurement of needs. If you do not already have a list of features the system should include, this is fine too – doing this exercise may help you define those as you place them in the feature usage matrix.

Create a 4 x 4 matrix labeling the y-axis with the labels “All of the Time” to “Infrequent” and the x-axis with the labels “Few Users” to “All Users.” Now start brainstorming features the system should have. These need to be end-to-end goals and not small chunks of a bigger goal. Think of them as features or a user journey for completing a specific task (see the image above).

Defining the Red Routes and Identifying Priorities

Visualizations help. After you’ve identified the features the system needs to have and have plotted them in the Feature Usage Matrix, you may then easily distinguish between the highest priority items and the lowest. Obviously, the highest priority features that should be developed first are those in that are going to be used “All the Time” and by “All Users” and the lowest priority would be those that are going to be used “Infrequently” by “Few Users.” From this point forward, it’s a good idea to create an epic for each feature and break the feature into stories within the epic. Bare in mind that the underlying technical dependency of having a system on which these features may be built is inferred here. If the system does not exist it will need an epic of its own, and since it is the underlying dependency, it will need to be built first. However, doing this exercise beforehand will allow for the system to be architected in such a way as to accommodate the features known to be needed at some point. The more features are known during the architecture of a system, the more robust and flexible the architecture is likely to be to accommodate those features.

Why Red Routes?

If you’re still running your development workflow in a waterfall format, may God be with you. I feel for you. You cannot pivot well enough to build features in a user-centric way that typically yields the best results. If you’re more agile in your workflow, red routes will help you immensely. Among the other benefits already mentioned, they will help you identify your minimum viable product (MVP), let you create a more meaningful product roadmap for continual iteration and remove any usability obstacles on important user journeys.