The difficulty of simple design – part 1

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.