Looking for 80% of interface features nobody uses

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.