Every time I sit down to design an application, the first question I ask myself is how simple should the interface be. For that, it pays to know what the target audience is, their level of expertise etc. But the most important aspect is ‘how simple can I make it?’
An application has a purpose, that of automating or simplifying some process. Already something that is implemented in code means a step forward has been taken, but how well does it address the issue(s)? This is partly solved in features and partly in the way they are presented, the UI.
I quite enjoy the way that UNIX tools have been traditionally written: do one thing, and do it well. Of course, these tools are mosty CLI and would be cosidered hard to use by modern standards, but the principle is still something we can abide by. Most modern tasks require a number of steps, and the problem itself, if worth tackling, brings some complexity to the table. That said, we still should design our applications in a way that minimizes the required clicks, toggles and switches the user needs to interact with before they can get their process underway. Think of the important points in the problem solution, and consider your program to be the glue that holds it all together1.
The best example for this is probably VisualHub, a program that simplifies the heck out of transcoding by way of pre-set profiles for what people do 80% of the time.
As for the title of this entry, the problem that I am most often faced with is ‘how far should I take this simplification process, without making the solution (my application) too case-specific?’ For many moons now I have been of the opinion that we should optimize and refine for those 80% of the use-case scenarios and hide the knobs and levers that let users tackle the rest — but still have them accessible. The issue that I find myself unable to escape from is that, no matter how well you try to design your application, there is a point at which you have made it as simple as possible, given the problem you are trying to solve. The baseline for simplicity should be chosen such that the user can do the work without any fuss, but not set low enough so that the whole application really fits only one usage scenario. It should also not alienate advanced users.
If the problem is far too complex to solve through a process that would fit the above requirements, I revisit the requirements and the specification — often enough there was a failure to observe how the larger problem could be split into smaller ones. For the smaller problems it will be more evident how a simple UI can be designed, and bringing all of the components together should also be more intuitive for designers and developers.
The first time I had to deal with this problem was during a project to develop a mock point-of-sale system for a restaurant. We have identified what the hostess would want to do (mark tables as in use, add items to orders, view bills etc). We then designed UI frames showing all the various screens that each of these tasks required and figured out which ones could be joined, without having the end-result more complicated than the sources. Be careful with the trade-off between the number of different views (windows, screens) that your application uses and the volume of information presented in each. I am more inclined to let one or two extra screens in the application, rather than combine two fairly different tasks into one. This deserves a case-by-case analysis, but in general such combinations will confuse the user. Also, stay away from wizards and other tree-like configuration options, they do not make things easier; rather, I would argue they increase the cognitive load on the user which is now required to remember the depth in the wizard at which they are, wonder about the alternative paths and what those offer etc.2
As you can see, even for these smaller details decisions are hard to get at. If you made everything a button in the main application window, you would either bombard the user with too many things at once3 or simplify things beyond usefulness.
What process do you go through when you need to design something, if your goal is, like mine, to maximize usability (through simplicity) but still produce something useful?
- Akin to the UNIX pipe if you will, and this also encourages object-oriented design, though you should focus on task-orientation. [↩]
- A good mix between ‘wizard’ and ‘flat’ design can be seen in PwnageTool 2 [↩]
- Think of new applications that you try, and how often you need to stop and figure out where you should begin [↩]
