As part of my work at the BFI I’ve been thinking about how best we can integrate a more user centred approach to the prioritisation of the user stories in the project backlog, after all we’re designing the site for the user not us so why shouldn’t they have a say in what features and pages get built?
One solution to this problem is to use the Kano Model of Customer Satisfaction which was developed by Professor Noriaki Kano in the 1980′s. In a nutshell Kano says that user preferences for functions or features can be distilled into 5 categories:
1) Attractive Quality – The ‘nice to haves’ or delighters, features and functions which add to the experience but are not essential and wouldn’t be missed if not included. For example the little bag of sweets that Firebox include in their parcels.
2) One Dimensional – features which (when they work and are done well) add a great deal but cause frustration when they do not deliver as promised.
3) Must Be – The givens. These are the things we expect to be provided and while they do not add to the users satisfaction cause a great deal of frustration when missing or badly implemented.
4) Indifferent – Features which are neither good or bad and do not result in either satisfaction or dissatisfaction with users.
5 Reverse – The best way to describe this is assuming that all your users are alike. For example a gadget which is so overloaded with features it is at the expense of the user who thinks your product is overly complicated.
Kano illustrates this best in this diagram:
Now using the Kano Model in user centred design is well known, in fact Andrew Harder who gave an excellent talk on Kano as part of his User Research as a generative partner with design talk at this years UX People which is what inspired me to look into this further.
We will be using a variation of the model to test users appetite for the features we are proposing as part of our usability testing sessions. We conduct one round of user testing towards the end of each sprint (I’ll talk about our approach to user testing in another post). At the end of the testing session we will ask users to rate the features of the wireframes (a feature could be a page, a section or a widget) and use an aggregate of those ratings as a guide for when the Product Owner is prioritising User Stories (features) in the Project Backlog.
The rating we will use will look something like this:
How would you feel if feature x was to be in the new site?
These responses are then aggregated according to the persona (we recruit users for testing against personas, I’ll talk further about how we use personas in another post). So for example if we recruited 5 people who matched our Nick persona and 3 of them responded very positively to feature X then the corresponding user story in the backlog might read. “Nick really likes feature X and would like to see it included” or if we didn’t have a majority the story could read ” On the whole Nick really likes feature X and would like to see it in the new site”
So there you go. This model isn’t intended to replace the Product Owners backlog prioritisation function but should help act as a sanity check when looking at the user stories.