Simplify your job search
Get 5+ job offers from top companies with 1 application
Get job offers

Leveraging User Research for More Effective Feature Prioritization

The project’s scope is firmly rooted in well-considered facts. The approach has been validated with consumers and business owners to ensure that it will deliver value. The project budget is based on accurately crafted estimates created by well-informed technologists. Last but not least, the timeline has been determined by the number of resources available to do the estimated work.

I have never been on this project. From conversations I’ve had with others, it seems that projects such as these are as common as spotting a unicorn flying over a double rainbow. It’s far more likely that a few people were handed a project charter, brainstormed a list of features that got passed around and mysteriously became the project scope. Estimates are based on whatever details can be found. And the deadline was set before the project funding was even approved.

Gail Swanson

No matter the methodology used, members of the project team do the best they can with what they are given. Whether challenged by the release date, resource availability, a lack of information, or a low budget, it’s usually up to the team to establish priorities for the features in order to determine the project scope, plan releases, or plan a sprint. The team will ultimately be more successful if it considers what will make the product successful rather than narrowly focusing on a tactical plan for knocking out the to do list set before them.

I used to think that as a user experience designer my only concern should be representing the users’ interests and fighting for the features that benefit them. This approach will put you at odds with those who represent business interests and technical resources. ‘UX versus The World’ is not a recipe for success and harmony. The different skills brought together on a project all have to compromise to create the best product given the current conditions.

UX professionals are well suited to be the facilitators of this compromise. Our role requires us to communicate with many constituencies and develop empathy. We can direct the team toward the solution that delivers the most business value through the best user experience possible. Some of the best guidance to identify high priority features comes from the research you have about your users.

The more firmly you root your priorities and scope in real data and information, the better decisions you will make. You will also minimize the number of times you revisit and debate those decisions. Product decisions based on gut feelings or personal opinions are more vulnerable to fire drills and occupy hours with circular debate.

What information do you need about your users to determine feature priority? The most important details for this exercise are the ones that define the user’s goals and needs that are most closely related to the project’s goals.

Confirm that the feature will be used at all

According to the CHAOS Summary 2009 Report, “50 percent of software features are not used or wasted, while other features are sorely missed.” That adds up to a lot of unnecessarily complex software. How can you predict what people will use? Try a round of Contextual Inquiries where you watch people perform the tasks in their normal environments, their offices or homes. Do they use similar features on other websites or ignore them altogether? Do they already have a tool for that microtask that they’re happy with, one that integrates well into their workflow?

You can also test the feature with paper prototypes and gather feedback on whether the feature is desirable. Ask the participants for examples of how they might use the feature. If you are redesigning an existing application, benchmark analytics can reveal current functionality that is not being used and should be cut from the new version.

Frequency of Use

Features used frequently should be given high priority. It’s a pretty straightforward idea, but one not frequently mentioned in scope discussions. Des Traynor created a grid to evaluate features according to how often they are used and by how many people.

Image copyright @contrast. Used with permission.

“The amber sections represent danger. If you’re building features that only a small sliver of your customer base heavily depend on, your product is doing more than it should. These customers won’t be happy if you remove these features, but they’re worth very little to you.”

Holding up the functionality against your personas should give you a pretty clear picture of how often someone would be using the feature, and knowing how your personas map to your actual user population will reveal the number of users that would be exhibiting that behavior. This is a useful perspective when you need to trim scope from your project. Odds are that there is a small set of features in your product that people will use frequently. From both the user and business perspective, these features deserve the greater proportion of your attention and project budget.

Value — Forget the long tail

“5% of your website produces 25% its value.” According to Gerry McGovern, a very small portion of your website is delivering a large portion of its value.

Shift your focus from a diverse offering of content and features and hone in on the limited areas that are getting the job done. These areas tend to be the ones most frequently used by the greatest volume of users. They might also be features that are the most essential for completing the user’s goal or delivering the business value. The shopping cart may only be used by 15 percent of your site visitors, but they are the users that are putting money in your pocket.

Not every problem needs a solution

Traditionally, designers have tried to ferret out every possible scenario that could play out with their design and ensure that every pathway is accounted for. This requires a lot of effort. Plus there’s always that looming risk of finding the edge case that screws up the whole design. You add complicated features and options to your website just to make sure that something that a user is unlikely to do won’t trip them up. Before you add features that will make things more difficult for your most frequent use cases, consider the results if you did nothing.

If this is truly an unlikely scenario, is it important that the error is prevented? Will it prevent the user from purchasing your product, or will it merely require that user to undergo a few extra clicks to finish the task? What will the user experience if they go through the scenario? It may cost you more to prevent a handful of users from hurting themselves than the benefit your business will gain from satisfying them. Graceful failure may be the most appropriate route.


User research often uncovers the costs of a bad user experience. The most obvious costs are incurred directly supporting users through call centers, robust training and documentation. Costs also increase from low productivity, inaccurate data, bad sales leads, high user abandonment, and low morale when the product design does not meet the user needs. Features and design solutions that reduce these costs may warrant a high priority.

Task Priority

How important it this task to the user? Take a look at how someone currently gets this job done. Examine the current process that would be replaced by the feature.

  • Is it a pivotal part of their role and the primary way that they add value?
  • How painful is the current process for completing the task?
  • Can the user accomplish their goal be without the feature?

Additional consideration should be given if the current process takes up a lot of the user’s time and leaves them feeling that their effort didn’t accomplish anything of value. Does the user currently have to undergo a lengthy process that includes redundant data entry in multiple applications?

Problem Severity

How bad is the problem that the feature solves? You can actually calculate the severity according to the number of users that encounter the problem, how often then encounter it, how disruptive it is, and whether a user will repeatedly experience the issue or be able to learn and adapt to it after a few encounters.

Do the user goals align with the project goal?

This can be a tough one for UX designers to accept. The feature may be important. It may be a great idea. But does it belong in this project? It’s easy to get stuck in the mindset that now is your only chance to deliver to your users. You’ve got to make sure you get all the features in with the first release. Relax…breathe. Software changes over time. We learn a lot when what we build gets in the hands of users. You may change your mind about adding that feature or find that something else will work better. Stubbornly fighting for features that don’t move you toward the goal at hand is not a good way to win friends and influence people. Place priority on making the features that align with the current business goal the best that they can be. If your users still need that other feature, campaign for a project to address it directly.

Product Adoption and Customer Retention

There are some features that users just won’t do without. Sometimes the little things are the ones send someone on a quest for similar app that does what they want a little easier. Mobile apps and shopping websites are especially vulnerable to this. If leaving out a feature, like integrating to a map application, will cause your users to walk away, it deserves a high priority.

Gail Swanson

Many designers like to begin their process with a blue-sky view rather than constraining themselves by technological constraints. Unfortunately, these designers set themselves up for arguments and frustration because the context of the project was not considered. Blue-sky designs get picked apart and implemented piecemeal. On top of that, developers have to save time by implementing less costly versions of the carefully crafted interaction design. What ships falls somewhere between a Frankenstein monster and Swiss cheese, neither of which provides much business value. It doesn’t matter that your design carefully considered your users’ needs. What matters to your users is the quality of the product that shipped.

Waterfall projects are often derailed by frequent shifts in scope. Agile teams fall prey to similar issues when user stories are prioritized according to stakeholder opinion or worse yet, political motivations. What feels like the most important feature to deliver today, is heavily influenced by the most recent fire drill and the CEO’s shifting focus. Add on what you learn during the project and it can start to feel like your target will never stop moving.

A project prioritized according to user research has solid footing. When the winds of change blow, you will have criteria established to justify staying the course or make the right adjustments.

About the Author

Gail Swanson

Gail Swanson is a Senior User Experience Consultant at Centare. She has been designing innovative, and engaging experiences for a variety of corporations since 2000. As an advocate of Agile UX, Gail believes in the power of collaboration. She is dedicated to making your every day just a little bit better by delivering technology that empowers its users. A self-diagnosed information addict, Gail writes about real world UX work in her blog, Practically UX.


  • Jon-Mikel Bailey Reply

    Great post! This should be required reading for any team about to embark on a web development project. It applies is so many ways. This question is especially crucial and often never gets asked… DO THE USER GOALS ALIGN WITH THE PROJECT GOAL? Thanks for this!

  • Julian Reply

    Best article I’ve read in a while!

  • Theo Reply

    Great article, a must read!

  • Roland van Ipenburg Reply

    From a UX point of view it makes sense that features used frequently should be given high priority, but when implementing security there is also the cell in the matrix “one of the people – one time” which could be an attack vector bringing the whole business down. And up from there a whole lot of “features” in the long tail need to be implemented and tested anyway, even if it’s just a message saying that feature is not supported. It could be even cheaper to provide a feature than disable it because the logic of frequency of use could be just an extra requirement that doesn’t decrease the project scope.

  • Clifton Reply

    We’ve been holding user interviews, prototype testing and focus groups (although they come with a level of deception themselves) to determine which features we should be developing.

    There’s an anecdote we like to keep in mind about a web tracking company that dumped thousands into a visualization feature, and since its introduction, exactly zero customers have used it, despite many of them requesting the feature outright during tests.

    It’s necessary to listen to your users, but their requests aren’t prescriptions. Always ask yourself why someone’s making a request. You might find that implementing a similar but different feature satisfies several different requests without doing exactly what’s been asked. And they’ll probably never even remember what they wanted in the first place.

    • Gail Swanson Reply

      This is one of the biggest contributions that UXers make to a project. Uncovering the issue that a user is having, the inspiration for the feature request. Understanding the problem that the user is trying to solve via the requested feature will prevent you from adding bandaids to your product that end up complicating the experience rather than making it easier to use.

      Asking a user what features they need/want is a common misstep. Get to know what they do, how they think about their work, and that will lead you in a better direction.

    • Jimmy Reply

      That’s an excellent point, and one I’ve seen many people misunderstand. Simply asking users ‘what feature do you want’ doesn’t work, because many users can’t see beyond the workflows and features in the existing product, even when what they really need is a completely new paradigm or approach. As Gail mentions, simply asking about features usually creates add-ons and ‘sticking plaster’ fixes, when what’s really needed is a radical reworking of a tool’s functionality.

      Clifton, it sounds like you’ve seen this happen fairly often. What, in your experience, is a good way to communicate the problems with this ‘ask the user’ approach when speaking to project managers?

  • Guy Reply

    I see ‘Few of the people – all of the time’ and either think: separate the function out or determine whether the few are on to something that the many should know about. Or as Roland touched on, the function may be a special use case for only a sub-set of the users.

  • Adrian Reply

    This blog is definitely going to help a lot in web development. It has discussed all the pros and cons of the project in details and this will really be helpful for development of websites and its designing. Besides, its going to help in evaluating the market prospects of a particular project before launching it. Really a very useful blog. Thank to you!

  • Todd Zaki Warfel Reply

    Great article on using user research to effectively prioritize your business and design decisions. I’m a huge fan of this approach—using data to help guide design/business decisions.

    The biggest challenge I’ve had in 15 years of design and research is finding a way to quantitatively analyze user research. Much of it what we as a field collect during this type of research is unstructured qualitative research. I’ve used the same methods everyone else has—spreadsheets and post-it notes.

    I’ve been waiting for years for a better way to do this. Something less subjective, more quantitative. Around a year ago, I got tired of waiting and teamed up with a talented application developer to build it ourselves.

    Basically, it’s a collaborative, real-time, team-based decision app. Observation notes from anyone doing UX research on a project are aggregated in real time (no more merging excel files together). The app also prioritizes your data based on value and feasibility. So, observations that are significant to customers, have high value to the business and are feasible to pull off, float to the top of your data set. Items that are low-value, low-feasibility fall to the bottom. The decision algorithm is weighted, giving higher priority to value than feasibility.

    The app also highlights themes in your data, and shows not only the connections between data, but also how strong that connection is. The app launches publicly at the end of this month. You can sign up to get notified at

  • Dibts Reply

    I believe this is among the such a lot vital info for me.
    And i am glad reading your article. But want to observation on few common issues,
    The web site taste is perfect, the articles is actually nice : D.
    Just right process, cheers

  • Jason Rutgers Reply

    Users need a platform where they’re able to share feedback, but that’s not all. What good is feedback if it doesn’t get used? Feedback should be easily accessibly by the support team and integrated directly into the helpdesk.

Leave a Comment on This Article