Originally published on UXmatters, March 25, 2014

It’s interesting that many popular apps from the 90s are not available on the market anymore. New Internet users will never hear about RealPlayer or ICQ, products used by millions 10 years ago.

I think one of the reasons why they are gone lies behind the bad user experience of their end-users. Lots of new features turned the simple and usable apps into hulking space stations.

The paradox of choice

There’s an interesting psychological concept called the paradox of choice. According to it, the more choices we have, the less happy we are with the chosen option. Putting it in the UX words: the more options a product offers, the less satisfied the end-user will be.

Some companies have never understood that. ICQ used to be the most popular online communication tool in the world. Released in 1996, it succeeded with getting 100 million accounts registered by 2001.

Year after year, ICQ grew to the point where the company had to offer a second product — ICQ Lite. It included “only the most popular features of ICQ”. Their original instant messenger app was so bloated with features that a simplified product had to be released.

RealPlayer is another example of a product with too many features. Initially it was only a simple media player. However, it end up offering CD burning, audio recording, RealPlayer Music Store and more. In 2006, PCWorld magazine included RealPlayer on the list of ”The 25 Worst Tech Products of All Time“.

LiveChat, a communication tool for website owners, was also a feature-loaded product a few years ago. We have been developing it since 2002 and that’s what it looked like after 4 years on the market:

Feature-overloaded version of LiveChat in 2006

It let you monitor traffic on your website, chat with on-site visitors, manage your business contacts list, integrate with ICQ/MSN messengers and even make phone calls from within the app.

We thought it was a good way to build the product. “If we will solve all the problems our customers have, we’ll finally make a perfect app” — such approach seemed logical to us.

In the beginning, adding new features was a pleasant task. We loved using new technologies and our clients loved getting what they asked for — a classic win-win situation.

However, we reached a point when there was no more room for new features. Adding another one was no longer a 1-hour job. Where to place that new button? How to easily explain a new feature to customers?

Feature-overloaded product was also way harder to maintain. A small change in one place could easily cause a bug in another one.

Also, along with the new features, the number of product use-cases grew exponentially. We were surprised with some of the ways our product was used. For example, we provided agent-to-agent chats so that they could help each other while serving challenging customers. As it turned out, some of our clients were using that feature to collect pizza orders in their company. These customers didn’t really need our product. They might have used Skype with the same effect.

Escaping from the trap

In 2009 we took a step back and finally understood that’s not a good way to go. We made a decision to simplify the product as much as possible.

At first we planned to cut off the features in the existing product. But we felt it would be just like painting the grass green. Small iterative changes would only change the product’s appearance. However, we strived for improving the whole experience of our users. This is why we decided to create the new version of our application from scratch.

After 11 months of hard work we released our new application and new product website. We also provided our customers with lots of high-quality materials that helped them better understand the product.

The results were satisfying. After the first 6 months, we were getting 20% more customers a month. And after a year, 70% of customers decided to migrate to the new product.

Our new customers were spreading the word about a great UX of the app. Here’s one of the examples of that: “I’m loving everything about #livechat You guys have a beautiful UI/UX experience” (link).

Simplified, easy-to-use LiveChat version in 2014

Lesson learned: Product teams should be assertive

During our product redesign process, I learned how important it is to properly manage feature requests from customers. They really want to be helpful and bring value to the product. Even though their requests are biased by specific use-cases, it’s natural that other people may have the same problem. This could be your definitive proof for making the “let’s build that!” decision. However, it’s a short-sighted perspective. You should not rush with building something new just because of a single tweet or email.

Being assertive during the design process brings value in the long run. It keeps your product clean, easy-to-use and worth recommending. The problem is, people are more comfortable with making short-term decisions. Junk food and cigarettes would not be so popular otherwise. Long-term vision is something that a good product manager must always keep in his mind.

Being assertive is especially hard for developers. Blindly following the path of building new features is similar to the way they work. Getting a task, completing it, moving forward. By nature, a developer loves building things, so the idea of removing features feels like a step backwards.

How to keep your product clean?

I would recommend several ideas to prevent from building unnecessary features in online products.

1. Build universal features when possible.

Learning how customers use a product can be an eye-opener. You may find interesting use-cases that your product offers. For example, Gmail can be used not only for sending emails, but also as a todo list. When an email lands up in the inbox, you can keep it there unless the task associated with this email is completed. It’s an effective technique if you receive tasks via email — you don’t need any other tool to write down your todos.

2. Consider enabling features for customers that really need it.

A corporate customer has different requirements compared to a freelancer. But you can still build a single product for both audiences. Using Gmail as an example once again: both small and big enterprises use it for their online communication.

Different feature plans are the way to go. The user is required to make only one choice — to pick a plan. All following interactions with the product are tailored to user’s needs. That’s way better than showing him unnecessary product features over and over again.

3. Display features in an appropriate moment.

Users don’t need to see all available features all the time. Facebook is a good example of displaying them contextually. When you sign out of Facebook, they suggest you to use a mobile app. It’s presented in the best possible moment: right when you may need it.

When a user signs out of Facebook, a suggestion to use their mobile app appears

4. Have a strong product vision and stick with it in everything you do.

Many product teams have no clear sense of which direction they are going. Subversion, a dominant player in the version control systems industry of the 90s, is a good example.

Subversion solves the problem of many people working on the same source code. Many software projects rely on Subversion, but they also use other tools in their everyday work. Managing bugs, feature requests and collaborating to open-source projects is their bread and butter. This is what people behind GitHub.com understood a few years ago. They made a product with the following vision:

_Build software better, together._ > >

It turned out that developers like the idea of working on a project with a single tool. The team behind GitHub didn’t focus on features. They focused on profits that end-users will achieve thanks to the product. Subversion was just one of the required components. GitHub has all of them included. From developers’ perspective, it’s how it should always look like.

Subversion followed the wrong direction. Their fuzzy vision statement is a good proof of that:

_Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations._ > >

5. Revise your whole product experience from time to time.

Keeping product clean and clear requires you to permanently question the available features. The Internet is a young medium. What is useful today may be gone tomorrow so don’t let the grass grow under your feet.

MySpace.com is a prominent example of that. The team behind it was building lots of features, but could not decide which one was the most important. A “place for friends” offered the users photos, videos, emails, blogs, forums, groups, games, apps, friends list, page themes and more. What’s even worse, they displayed all this stuff on a single page. Eventually, people started using other products that offered similar functions in a cleaner, better designed interfaces (for example: Facebook).

MySpace missed the moment of rethinking why the product existed. That realization would lead the team to focus on most important things and bring a truly valuable product.

Conclusions

You should avoid putting new features development as your highest priority. Keeping a product easy-to-use requires you to constantly question available features. When there’s no clear reason for something to exist, bite the bullet and remove it from your product. It will help you focus on essential features in the future.

People are comfortable with building new things. But with every new released feature, another part of the product may suffer. Never forget about fundamental values of the product. Remember your product vision and stick to it with everything you do.

Don’t let your product compete in the features rat race. It will move your product development efforts in the wrong direction.