Busy Interfaces

Where is the kitchen sink? I can't find the kitchen sink!

I heard a business person criticise a program's interface as being too busy and she caught my attention. I design interfaces for a living so I was interested in this remark. She just wanted to focus on her task and not search through a visually crowded page to find what she was looking for. And I agree with her, simple is always better.

So where does this busyness (yeah that is a word, the internet said so, so it must be true) come from. A couple of places as follows:

Developers Trying to Sell

Trying to jam as many features into their products as they can. They do this so they can advertise a long list of features that users think when they see them that they may need them and the more you get the better the value. They also do it to keep up with the competition. If one software vendor announces that they can peel a boiled egg online in under 20 seconds, then they all feel they have to do better. And users tend to think "Oh, that would be handy". I don't know about you but I don't often peel boiled eggs online. And why would you need to do it so quickly? I like to take my time with my lunch.

Uses Catching On

It comes from users too. Who in the beginning don't really understand what is possible. But then I show them a few things and they catch on very fast. Before you know it they are asking for a level of sophisication that they never could have imagined. This is where feature creep comes from by the way. Users see possibilities. So after a few iterations you end up with a program and an interface to match that would have overwhelmed the same user six months ago.

How Do I Usually Handle This?

A simple inteface is best. There can be no argument about that. We want users to become productive quickly and a simple interface supports that. But some tasks are complicated. So I try to divide these tasks in to smaller pieces and handle them one after the other on simplier pages. Or I will suggest that some "improvements" be put in to development of a later stage. While it is in my best interest to come out of a requirements meeting or a walk through meeting with a list of improvements as long as my arm, it is not often in the customers best interest. I can give you an example. A representative of the customer, not my direct contact but senior in the organisation and therefore I could not ignore him, wanted an extra button. What it did is not important. And his reasons were sound. But we lanched this process without it because we had a deadline and I was going to go to work on this button immediately. But we found that in use the extra button and the function it provided would have caused more problems than it was worth and I think we may drop the idea.

Finally

My focus is always getting the job done, as simply and therefore as cheaply as possible. There will will be plenty of times we will need to get complicated, so let's not do it if we don't have to.