Pair Comparisons Exercise
Our first exercise is very simple. Write down each feature on a separate piece of paper. Then compare every single feature to every other feature (this doesn’t take as long as it sounds like it might). You are simply looking for an order of preference. So the question for each pair is; “which feature is the most important? Feature X or Feature Y?”
You can do this by yourself or you can do it in a group. Every time a feature wins a comparison – it gets a point (list all the features on one sheet of paper and record the points by each).
So if you have 5 features you would need to compare; 1 and 2, 1 and 3, 1 and 4, 1 and 5, 2 and 3, 2 and 4, 2 and 5, 3 and 4, 3 and 5, and 4 and 5. That’s 10 comparisons in total.
You don’t have to limit this technique to comparing features, you could also compare competitors, job candidates, or anything else you need to prioritize quickly with it.
The “Buy a Feature” Exercise
In this exercise you give your participants a stack of cash (virtual currency created yourself ideally – real money is not required). They will use the cash to buy features from a list of features. You price the features based on how much effort they will take to implement. So a simple feature might be 1 Mickey Mouse Money and a more complex one might be 20 Mickey Mouse Money.
The key to the exercise is that the players aren’t provided with enough cash to buy all the features (or otherwise the game would be pointless) and thus are forced to prioritize what they really want. It may be that they want a couple of expensive but incredibly useful, from their perception, features or it may be that they want a laundry list of smaller features.
How to Play – Developing a List of Features
Given that every product is different; there is no standard list of features that you can use. However, building your list will normally involve listing the features asked for by users, features used in competitors’ products, features that you’ve come across during the research phase of your UX project and any other features identified within the business as possibly useful too.
It’s important that the features you list are meaningful to users. So this exercise is of low value if you want to discuss backend or technical details. Users don’t care what programming language you use or how you optimize your databases – that’s not their purview. They do care about how they can share things with friends or how they can save stuff for later use, for example.
It’s important not to overwhelm your users in this exercise. You don’t want to present them with a list of 200 features because they’ll find it impossible to provide meaningful feedback – there’s too much choice in that kind of list. The ideal list is going to be no more than 25-30 features long. If it’s much longer than that – reduce the feature list in house (use the pair comparisons exercise above to do that) before compiling the final list.
Finally, you want to write each feature on a separate card and include its name, a brief description of the feature and of course the price of the feature. Pricing should always be based on the complexity of implementation. Something that’s twice as hard to implement as something else – should cost twice as much.
How to Play - Deciding How Much Cash to Give Your Participants
The object of this exercise is to get people to make decisions about what matters to them and that means limiting their supply of cash. If they can buy every feature – you won’t learn anything. You need to get the participants to make hard decisions about what they want.
We think that “enough” is probably the right amount to buy 1/3 – ½ of the features on the table. Don’t choose a currency that relates to your local currency; it tends to make users think of the cost of the work you’re doing. Just pick something random (Mickey Mouse Money) and use that instead.
Then make the money and print it out to go with the feature deck (or raid your local Monopoly set for pre-printed cash).
How to Play – Setting Up Shop
You can run this exercise with up to 4 people (any more and it becomes really confusing) at once but 1 on 1 is good too. You pretend to be a shop keeper. Your participants can see the prices and they have the money.
They are free to ask questions before they make a purchase or purchases. This allows you to guide them through features if they’re not quite sure what the descriptions on the cards mean. They are not required to spend all their money. After all, you don’t want people selecting features they don’t want.
The participant hands over money to the shop keeper for every feature they purchase. The shop keeper should ask why they want the feature and make a note of the reasoning.
The exercise ends when either they have run out of money or they have purchased all the features that they are interested in.
When trying to select priorities and preferences it can be quite tricky to do it from a list. These two exercise make it much easier to assign priorities and make decisions based on them. Neither technique requires anything more than a little paper and a little time and can thus be used in almost any UX environment even if there’s not much budget for UX testing.