What if?

There are 171,476 words in the English language, but these two words put together, forming a seemingly innocent question, are rife with danger.

These two words have cost companies untold money, time and resources – and all too often at the expense of user experience too.

Why?

It’s to do with a misunderstanding of features.

The Danger of Features

The more features the better, right?

We’ll set ourselves apart by having more features than our competitors.

Give the people what they want…and what they want are more features.

Features, features, features.

But what if this isn’t true? What if the focus is all wrong?

It can seem counterintuitive, but features aren’t always a good thing.

This is down to two reasons:

  • Features add complexity
  • Features add cost

Features involve a trade-off. Each new feature adds complexity, crowding out existing features, making the interface more cluttered and placing an additional mental burden on users – i.e. they come at the expense of user experience.

Implementing new features also doesn’t come cheap. There are costs in designing, building, testing, supporting and maintaining a feature.

Features vs. Goals

How have we gotten to this point?

Why do companies often try to compete on features? A feature arms race, if you will.

The problem stems from asking the wrong question, the question of “What if?”

Every time we ask this question, we lose sight of what’s important. We lose sight of why people use a product. We forget that a product is merely a means to an end – it’s a tool to help users solve their problems and achieve their goals.

No one is thinking I’m going to use Microsoft Word for its kerning or macros features. They’re thinking I’m going to use Word to solve the problem and accomplishing the goal of writing a report that is due.

How do we overcome this all too common misunderstanding?

We start by asking different questions – the right questions. Once we do, we soon start to see that adding more features may not always be in our interests.

Instead of What If? We ask:

  • Does anybody need the feature?
    • What is it solving and who is it solving it for?
  • What is the cost?
    • What is the cost to design, build, test, support and maintain it?
  • What is the trade-off?
    • What complexity is being added?
    • What impact does it have on the core features of the UX?

Once we start asking the right questions, we’re in a much better position to decide whether a feature should be implemented or not.

We don’t just consider all possible scenarios and build features to account for them. We use well-reasoned analysis instead. Analysis that is hopefully backed by user research that enables us to make an informed decision.

So just because we can do something, it doesn’t mean we should.

Edge Cases vs. Use Cases

Have you ever heard of the Pareto Principle, which states that 80% of the effects come from 20% of the causes?

It’s no different in design. 80% of users will only use 20% of the features.

We have our most common use cases that, naturally, are used by most of our users, and the edge cases that are used by the minority.

So, does this mean that we should just disregard the edge cases? All the what ifs?

No. Not at all.

If there is a genuine problem that needs solving, it is relevant to enough users, and can be built within time and budget, design and build away.

Well, almost.

There is one more thing to consider. How will it impact the UX?

If designed well, we can keep all our users happy and improve the product without negatively impacting the core features of the UX. In fact, the overall UX will be improved as we start to take into account and design for the edge cases.

It’s all to do with prioritization.

The problem comes when the edge cases are given just as much priority as the use cases instead of the importance they each deserve.

How to Prioritize

Always remember that the UX should flow as smoothly as possible. In an attempt to accommodate all likely edge cases this flow can be interrupted and the UX suffers.

So, we learn to prioritize and deprioritize by placing a feature into one of three categories:

  • Primary Features: Things most users do, most of the time.
    • These should be most prominent.
  • Secondary Features: Things some users do, somewhat often.
    • These should be on the UI but not as prominent
  • Tertiary Features: Things that few people do, infrequently – i.e. the edge cases.
    • These should be included (if you think they are solving a problem for enough people), but users need to work a little harder to find them.

An Example – Gmail

Gmail-Use-cases-vs-Edge-cases
Gmail-Use-cases-vs-Edge-cases

When you open Gmail what are you looking to do? You likely want to create and send a new message, read and reply to your unread messages, and search through old messages.

In Gmail, these three tasks are given priority. You can’t miss them.

On the other hand, if you want to view your calendar or add tasks, these are still featured in the UI but are less prominently displayed in the right panel.

And far less common is someone who might want to forward a message to another address if the message contains a certain word.

Google hasn’t completely forgotten about this feature. It exists but has rightly been deprioritized. It takes a bit of work to do, but that’s fine because the minority have to work a little harder while the vast majority can enjoy the clean, intuitive interface.