Prioritising features can be a contentious experience. The importance of doing this is growing, largely thanks to mobile, to concentrate on the most important data and actions. Considering User Satisfaction and Dissatisfaction at the requirements stage not only gives us clues to guide our early design decisions, but it also helps get the entire project team involved in focusing on what really matters to the user.

Background

Volere, an umbrella for a set of requirements resources, offers a requirement shell; two pieces of information I would like to focus on from there are the Customer Satisfaction and Customer Dissatisfaction attributes. This requirements shell is shown below in its entirety:

Volere requirements shell, taken from: http://www.softed.com/Summary/Volere.aspx

How to Prioritise

Satisfaction and dissatisfaction is expressed in Volere using a 1 to 5 scale:

  • Satisfaction uses 1 for "uninterested" and 5 being "extremely pleased";
  • Dissatisfaction uses 1 for "hardly matters" and 5 for "extremely displeased".

What this gives us is two different perspectives, which can give you interesting insight into a user need.

An Example

Putting the above scales into practice, consider the following statement:

The train shall arrive on time.

From a satisfaction point of view, unless you are like my son who has a particular fondness for trains at the moment, I would expect the average response to be some where on the lower half of the scale. In contrast,  if the train happens to be late then would I suspect the consensus to be nearer the higher end of the scale, near to "extremely displeased"!

Where on the Scale

Needless to say, the values should be derived from actual end-users, and as per User-Centered Design, validated throughout the project.

Satisfaction and Dissatisfaction ratings might also help mitigate the finding of when ask[ing] users if they want a new feature, 90% of the time they’ll say yes. That is a hypothesis I am yet to test.