What is the Secret to a Good GUI?

The personal computer user interface has come a long way since the day of toggle switches and LED’s. Despite all the technological advances, end users frequently still struggle operating software despite displays that support millions of colors and innovative software controls. What is the secret to a good GUI?

Written by Rob Somerville

First of all, a confession. I am  unrepentant, died in the wool, stoically intransigent CLI user. I probably only use 5% of the functionality of my word-processor. Apart from a few specialized applications I regularly use like, graphics and desktop publishing, if I cannot do what I need  at the shell prompt or via a web browser, a general sense of foreboding descends upon me whether I need to learn to use a new application. So much of this is because I know – irrespective of the operating system or hardware platform – that I will have not one, but two mountains to climb. Firstly, I will have to get my head around what the software does and doesn’t do (functionality), and secondly, I will need to understand where in the myriad of menus, popups, forms and dialogue boxes that the functionality actually lives, if it actually does exist at all. I must admit, over the years I am much more smitten with the quality of web interfaces rather than desktop designs, as the web truly is point and click – and straightforward.

The historical response to this is usually a dismissive RTFM (Read The Friendly Manual). However, with high-quality documentation pertaining to the user interface generally being the exception rather than the rule, after a cursory glance, I normally abandon this approach. The number of times I have encountered software where last minute revisions have not made it to the manual are too numerous to mention. So strike one to the CLI, man and info are your friends. Some *nix commands are even flexible enough if you get the switches the wrong way round (and not follow the example to be found at the start of the man page) to parse your erroneous request correctly, or as a worse case to report something vaguely sensible back. So once your application is written, at the very least, put some screenshots and user documentation together covering the most common (and not so common) use cases, or better still, an online video. New users will thank you for it.

The other hurdle is consistency. Unless your application is particularly flash or you are designing as part of a team, you will generally be responsible for the color scheme, fonts used, size of dialogue boxes, form fields, etc. Random sizes etc. do not inspire confidence. Pick a set of standards and stick to them. Error messages should be clear and right at the top of the form, unless you have the pleasure of using callbacks where you can highlight the offending field. If you are not validating user input, you are making a rod for your own back – invalid data input (or poor form logic) will generate a lot of support calls. Make messages informative – “Error code 76 at line 12275” might mean something to you – but to an end user on a steep learning curve and a tight deadline, this may mean printing off a copy of your online profile and throwing darts at it.

Complexity is a big problem with large applications. How do you incorporate a lot of functionality into a straightforward UI, especially if the screen estate is at a minimum? One useful design tip is to have a standard and expert mode. The former being a condensed and functional  subset of the later that is pre-populated with the most common defaults. Form design can be simplified by keeping the most commonly used functions on display, and allowing the user to add the relevant controls and additional functionality if required. Icons, if used, must have a working title that is displayed when hovered over, better still, give the user a choice of words and text. Often, icons do not accurately represent the functionality they perform. Keep clutter to a minimum. If there are lots of toolbars, split the functionality into groups and allow the user to show or hide the operations they most use.

Even before you start sketching out a design on paper, it is important to grasp how the intended audience thinks and works. An intuitive interface for Application A will be very different from Application B. People have different workflows depending on the task at hand, so resist the temptation to port a good design from one application to another. While the fundamentals will remain the same, subtle differences that make life easier may mean major re-coding – it is often better to start from scratch with a good brief and a clear understanding of what makes an excellent environment than trying to bend something else to fit. After all, the controls for a Boeing 747 are very different from a radio controlled drone. While both sets of controls fly planes, one is considerably more intuitive than the other. Always consider that what appears intuitive and second nature to you may not apply to your user base.                

How resilient is your application interface? The GUI is the gateway between the end user and the chaos of software and technology beneath. The best analogy I can think of from a defensive programming standpoint is that the GUI is like a bouncer or steward outside a rowdy nightclub on a Friday night. Helpful, informative, authoritative but firm and fair. It is the GUI’s responsibility to ensure that no undesirables get past, eject any troublemakers that do, but most importantly to ensure everyone has a good night out. Sadly, you cannot legislate or code against fools, but the more effort you put into this the higher the quality your application will be. Depending on the tool-kit you are using and the specific application you are designing, the onus for input validation may reside outside any form controls, and you may have to write extensive error trapping routines.       

Finally, test, test, test and test again. Try to break your design at every stage and iron out any flaws. Even before you start writing code per se, sit a sample of users down in front of your GUI, and listen to their feedback and ideas. Get continual feedback throughout the major milestones of the project. They are the people you are trying to make life easy for, and you will be surprised with the challenges that they often raise. Once you have successfully repeated this, you can proudly add the most important part of the UI – the Easter egg with your copyright notice and prevailing wisdom.