How user research can help prioritise product requirements "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 12 January 2013 True Case Study, Lean Startup, Prioritisation, Product Focus, User Research, Mind the Product Mind the Product Ltd 733 Product Management 2.932
· 3 minute read

How user research can help prioritise product requirements

Many people think of user research as either something you do towards the end of the project as a check and balance before going live, or once the project has already gone live to make sure it’s working as it should. However, research doesn’t always have to focus on what you have created. It can be done much earlier in the project to help prioritise product requirements by looking at solutions that already exist in the market.

Overwhelmed with ‘cool’ ideas

Let me demonstrate the value of this exercise from a project I was involved with. We were called into a situation where a product team was overwhelmed with requirements and ‘cool’ ideas for a new high profile community website which would accompany a TV show.  The product manager was struggling to stem the flow of ideas and get everyone to focus on an agreed scope. It didn’t help that the very excitable client kept adding more and more requirements to the list.

A feeling some of you might empathise with: they felt they didn’t have the time for research, they just needed to get started. After some discussion they conceded that they couldn’t afford to accommodate all the requirements and needed an independent perspective on what they should focus on. So we kicked off a piece of user research to validate their list of requirements.

More focused list of validated requirements

A week and a half later, we had conducted several research sessions with target users and listed all of the core requirements users had for the new product. The research was focused on understanding what users needed, what they currently used, and what they would need the product to do in order for them to switch to it. Essentially we sat next to target users in a one-to-one session and they showed us which websites they used.

We observed how users interacted with competitor’s offerings while they explained what they found useful, what was frustrating and what they felt was missing. Then we asked them to complete tasks on  a variety of other websites which contained the features and functionality being considered as potential product requirements. This gave us insight into which content, features and functionality worked for users and which did not. We were able to establish which of the product requirements were valid and which would be unlikely to offer users anything more useful or different than existing offerings.

Comparing user requirements with the previously generated list of requirements quickly allowed the product team to isolate new core requirements which would meet the needs of the business.  A list of 63 requirements was whittled down to 17 which were focused, manageable and more importantly everyone on the project agreed with.

Months later when the site went live, users loved it and the client used it to showcase the site internally as a great success. The product team were delighted they hadn’t spent valuable time and resources developing for requirements that users simply didn’t need.

Steps involved in user requirements research

A research project doesn’t have to take weeks, a good UX researcher should be able to develop a focused research plan to tackle you’re list of requirements. Here’s a simple breakdown of the core steps to consider:

  • Pick some websites that offer similar functionality and include these in the test
  • List the questions you need answering in the research. Make these as detailed as possible i.e. Do users experience any confusion when interacting with the search filters on
  • Investigate what users need from this functionality: what helps and what hinders?
  • Establish what they currently use and identify what’s missing from their experience
  • Explore what would make them switch from what they currently use to a new service
  • Draw up a list of user requirements and compare against your other requirements

At the start of a project, testing products that already exist on the market can put you in a great position. Before any scope document is agreed or any code is written, you can establish which requirements will really help users and which probably won’t be worth the effort.  Having an in-depth understanding of what users need from your product so early can help you focus the entire product team on those features which will really offer a great user experience to your target audience.

Comments 1

Join the community

Sign up for free to share your thoughts