March 15, 2018

Looking for 80% of interface features nobody uses

Olga Shavrina
We consider everything we've implemented in the interface extremely important. We've invested so much time, blood and sweat and thought it carefully (I wish it was true).

But the thing is the longer a product lives the more it overgrows with "useful" features that prevent customers to use 20% of functions they really need.

Some features just cluttering up an interface and prevent customers to find a feature they need quickly. But others are more insidious – they don't show themselves, but cause excess background processes. They slow down the whole system, complicate architecture and make the bugs to appear more likely.
Moments you have to consider
Complex professional products such as Adobe Creative Suite or Oracle have loyal (and expensive) customers that know the project backwards and forwards, became experts and use 80 if not 100% of its features. If you remove some of these functions – loyal customers can abandon you. Please be careful.
After you find an unpopular feature – you don't have to delete it. You can simply move it a little deeper, e.g. put it under an "advanced" link.
Sometimes a feature is unpopular because nobody knows about it. E.g. it is hidden deep in a menu structure, has a confusing name or you simply forgot to tell your users about it.
Ok, let's figure out how to find unpopular features in a product.
A precise and reliable way to figure out the feature is popular – to measure how many clients use it, and how many – don't. Sounds easy, right?

However, in practice, things may not be that simple. At first let's define what "use" means in this case. It differs for different features. E.g. we can tell a person uses a like button if he presses it at least once a week. The same person uses an auto-email campaign if he launched it a year ago and it still works.

We are lucky if our analytics system already gathers this data and we can simply look at it. If not – we should formulate a task to a programmer to send the data to the analytics system and then wait for the data to gather.

Having the data at hand we should make a correct conclusion. Say 100 customers pressed a button one time a week. So what? Is it good or bad? We should compare this number with something that makes sense, e.g. with the number of pressings the other button or with the total number of events or customers.

Some features we are interested in are not explicit actions. Say we have a dashboard with a lot of numbers and diagrams and it's not clear which of them users watch and which not. You can use Eye Tracking tool if you have it. I don't.
Hide and watch a reaction
The simple way to figure out a function is unpopular is to hide it and watch a users' reaction. If nobody cares – a feature can be permanently removed.
The method is violent. Be careful using it. If you constantly remove important features from the product your customers will hate you.
If customers ask you to return a feature – it means they need it. It is an opportunity to talk about a feature – you can ask "why do you need it", "why can't you live without it", wonder is everything good in the current implementation. It's an opportunity to improve a feature and make a product more useful.

An ideal situation if you can experiment with different groups of customers. E.g. hide features for beginners and advanced customers separately. And if advanced users ask to return a feature but beginners don't – maybe it's a good idea to show the feature to advanced users only.
Example #1
Our analytics page in Convead had a combo box to select a segment of visitors in order to watch analytics only by this segment. We considered this feature very cool and told everybody about it.
Unpopular combo box an Convead analytics page
For developers, this combo box caused data redundancy and monstrous overhead that slowed down the whole system. CTO grumbled every day.

Suddenly we had an idea to hide a combo box for a couple of days. It was hard for us but we hide it and... nothing happened. Only one ONE client mentioned the absence of a combo box. It determined the fate of a feature.
Example #2
One of the new Convead sections – push notifications MVP – was a pain in the ass for the technical support team. The thing is that push notifications depend on a web browser customer uses and we can't always control it. We could fix some issues but it required time and resources.
Push-notification section in Convead
So we had to decide – close the module or improve it. We hide it for few days and got many requests that told us the feature is important. So we decided to proceed with customers interview, examine how to improve a feature and open it again.
Bugs as an indicator
Nobody likes bugs and we should try to reduce the amount of them, but sometimes bugs can be a useful indicator in product decisions.

Sometimes you find a critical bug incompatible with a life of an "important" feature and realise with horror that it was deployed to production two weeks ago. How did it happen nobody noticed such a bug? It's a sure sign nobody uses a feature or uses it not the way we wish.
Example #3
I recently found out a bug in our segmentation tool – date variables were compared in the date/time format accurate to a second. In this case for e.g. a rule "last order happened one day ago" can be true only if it happened exactly 24 hours 0 minutes and 0 seconds ago. It's ridiculous.

If you use this condition you surely notice something is wrong because in 99.9% of cases you will get a zero result. But if nobody noticed a problem it means the feature is pretty unpopular.
Serious bug in a Convead segmentation tool. It's hard not to notice it if you use this feature
You can just ask
Fast and cheap method. However remember, users are insidious and to the question "Do you need a feature" answer "Sure, give me two" and then don't actually use it.

Without going into details, questions should be concrete – about actual user's experience so he won't have a ground for fantasy.
Wrong questions

Do you need a green button?

Do you like a green button?

Don't you mind if we remove a green button?

What you would like to be changed in a green button?
Right questions

How many times did you press a green button last week/month/year?

How did you solve your tasks before we added a green button on this page?

Why this green button is important for you? How exactly do you use it?

What you won't be able to do if we remove a green button? Why it is important to you?
And if he can't remember when and why he pressed a green button and never did anything like that before so he most likely won't do it in the future even if he swears to you he desperately needs it.

By the way user interview perfectly detects features users don't know about. You ask a user "How many times did you press a button last week?" and get an answer "Wow, I didn't know you have such a button".
The "80% of customers use 20% of product features" rule is probably studied in a kindergarten already. But what to do with the rest 80% features is not clear.

Startup owners vote for removing them, big and old companies who have a lot of experienced users try to be cautious. It is your right to decide the future of each unpopular feature but in the first place, you should find it.

I formulated four ways to find unpopular features: measure what customers use or not; hide and watch a reaction; analyse bugs and interview customers. It's likely you know more ways – tell me, I'll be grateful.
Olga Shavrina
Product manager. Human being