In my last post about design simplicity, I touched on the difficulties involved in what does and doesn’t make the cut for a design.

Recently I noticed a forum post where one of the developers behind Plex (a really amazing media centre application for OS X) had to defend removing features.  I still think their reasoning is correct, but due to user backlash they decided to put the feature back into the next version.

This is the main reason for feature creep and too many options.  People have different tastes and use products for different purposes.  The problem is, by kowtowing to existing users, you continue to alienate potential ones that you didn’t even realise you were alienating.

So let’s say you have a feature that tests equally well – 50% of your users love it, and 50% of your users find it confusing and difficult to use.  Do you keep it (to satisfy the 50% of users) or lose it (to preserve simplicity)?  What about you have two different versions of a feature that you have A/B tested and each are equally popular in those tests?  It can be tempting to even provide both!

However to preserve a simple design, it’s at this point you need to make a subjective choice.  You need to evaluate:

• What will be better for the product’s image?
• What will provide extensibility for future plans?
• What provides a qualitatively better experience?

For instance — you may be trying to choose between a dropdown list and a radio button.  Which to choose?   A dropdown list takes up less real estate — is that important? Do users find it easier to make a choice if they can see everything all at once, as with a radio button?   Is the list of options going to grow in the future?

As a designer or usability expert, it’s easy to get caught up in always finding the “best” user experience or what the user “wants” most, but it’s important to remember that some aspects to design cannot be measured or quantitatively known.  A simple design will go a long way to giving your design universal appeal and application potential.

The hardest part of being a designer is choosing what goes into the product.

Deciding what should and shouldn’t go in is actually a very difficult choice.  You don’t want it to be overcomplicated, but you want to have a competitive edge.  Sure, it seems easy — just throw out whatever people don’t need and put everything else in.  Unfortunately every user is different.  I read an article which claimed that people only used 20% of Microsoft Office features, and so 80% should be removed.  Unfortunately, each person uses a different 20% of the features.

So how do you decide what goes in without overloading your product?  The easiest features to be sure about are the ‘standard’ ones.  What are the must-have aspects of your product to make it work?  What does everyone love about your competitors?  Put these in!

The rest?  While usability testing will give you some idea of what people would want or like, a user saying they’ll use something in a usability session does not mean they will actually use it.  To decide what might be used, you will need to use some of your best judgement, some user feedback, but most of all, pick features which are ambiguous.  People will always do surprising things with your product.  How people customize and appropriate a system for their own use is called “articulation work” in design academia, and the more ambiguous you make your design, the more people can appropriate it in innovative and surprising ways.

I think Twitter is a great example of articulation work.  Ostensibly it’s just a status update system.  However, people use it for all sorts of things — microblogging, link sharing, ad-hoc meetings, connecting with corporations, getting the news, etc.  What facilitated this was a simple system with a few key features – such as the “@” and “#” operators, and a real time search.  From these basics, the community began using it in new and unexpected ways.

So when you’re trying to keep things simple and to decide “should I put this feature in?”, wonder “how might this be used in other ways?”  It’s much better to put in one feature which can be used in a multitude of ways, rather than overload on catering to everybody.

However, the question remains — how do you decide which treatment for a particular feature makes it in?  For example, say you allow a user to select something via a drop down or with radio buttons, and both test equally well.  How do you decide which to use without providing alternative methods of interaction?  I’ll cover that in part 2.