
User Interface Design
User Interface Design Pt. I
To begin, it’s worth explaining exactly what is meant by a User Interface (UI). This is a term given to the elements of the visual and interactive representation of a computer program and the ways in which a person can control it. This includes the buttons, menus, text boxes and other widgets you interact with on a particular program’s screen and it is the job of the computer programmer to design it.
OCC are currently developing a number of software products but this article will draw on examples from the new public sector contract management software; Controcc. Controcc is designed for social services and other public sector areas and deals with concepts such as contracts, providers, clients and services. As we were building an entirely new product, we had the ideal opportunity to concentrate on the UI design. This article looks at some of the principles involved in this type of development.
Building on Familiarity
Computer literacy is a skill requirement for an increasing number of professions. What exactly does it take to be computer literate? By definition, computer literacy is the ability to operate and work with a computer. Does this mean that in order to be considered computer literate you have to have experienced every single software product available? Of course not! In reality, practical experience with just a few programs is enough to learn the ropes. It’s safe to say that if you know how to open and save a document in Microsoft Word, you could easily do the same with a photo in Adobe Photoshop or even a file of type X in program Y. There’s a very good reason for this; most programs work in the same way.
A typical program for Microsoft Windows, for example, will likely have a File menu, toolbar and a status bar. Programmers can design UIs any which way they please, but generally stick to traditional designs because that’s how most other software works and that’s what the users of the system will be familiar with. Each software product is different of course, but there are commonalities which allow people to instantly recognise how to use it. Even if you didn’t know what the software was for, it’s a safe bet you could find out by clicking on the Help menu.
At OCC we pay very careful attention to this in order to make the software as easy to use as possible. We have achieved this in a number of ways, such as;
- Familiar Widgets and Layouts
- Navigation Style
OCC uses standard Windows menus, buttons, checkboxes, drop-down lists etc. and a logical, structured layout.
OCC uses a well known style of navigation. The left-hand frame allows the user to browse and search for information and the centre frame is used to display it. The display of the left-hand frame adapts to the current task and can show menus, lists and hierarchies, much like Windows Explorer, having very convenient Back and Forward buttons allowing you to retrace your steps - the kind of functionality we’ve come to expect from using the web. Furthermore, OCC uses hyperlinks to provide access to related information. We find this is a very effective means of advertising functionality as anyone who’s surfed the web will know that clicking the underlined writing will navigate somewhere else.
While these points may seem obvious, it is, however, all too easy to get the design wrong. For example, when you build a program from various blocks and assemble them, the parts may not make sense together. Although perfectly functional, the UI may be really quite impractical or even counter-intuitive, or worse still, the programmer may simply not have a clue, as is very amusingly illustrated in the Interface Hall of Shame. These particular screens are undoubtedly functional, but are especially ridiculous.
Designing a Pleasant UI
An essential part to a UI is the look-and-feel. If you’ve been using Windows programs for a while you’ll be all too familiar with the doom and gloom of grey buttons on grey boxes inside grey windows. Microsoft Windows XP and Microsoft Office 2003 have seen a big leap in UI design over their predecessors and sport very vibrant and colourful interfaces. Whether the greens and blues are to your taste or not, a splash of colour is certainly appreciable. Microsoft’s UI team have worked hard on picking colour schemes that are not only aesthetic, but also more contrasting and easier on the eye. The colour palette and harsh edges get smoothed out with each release.
All versions of Windows (and equally other Operating Systems too) have allowed you to personalise the appearance of your software. For example, people commonly change their colour schemes and fonts. Windows XP has brought the ability to further personalise your environment by allowing you to change the appearance of the widgets themselves. You can choose from the new Windows XP style buttons, classic grey style buttons or download any number of custom made styles. However despite this, the appearance of a significant proportion of software available remains absolutely unchanged by user preferences. The reason for this is that for a UI designer, adherence to these preferences is for the most part, strictly voluntary. Many designers don’t even realise that their users may have non-default settings and therefore don’t take them into consideration. What’s more, from a technical perspective, properly respecting user preferences is actually quite hard to do.
At OCC, we believe that efforts in this area are very worthwhile. Not only have we worked on creating a nice UI in Controcc, but we’ve also paid special attention to ensuring that Controcc’s appearance respects our users’ personalised settings and preferences. For example;
- System Colours and Fonts
- Widgets and Themes
- General Settings
The lettering and colours in Controcc, such as the menus, buttons, dialog boxes etc. respect the user’s chosen system appearance. We quite like the default appearance, but if someone wants the writing to appear differently, it can.
The appearance of widgets differs between versions of the operating system, and in Windows XP or newer, the user can choose different styles. Controcc’s widgets have been designed to react to their environment and will take on the system’s native appearance. If you run ContrOCC on Windows 2000, the application will have Windows 2000 style buttons. If you run it on Windows XP, it will have the XP style buttons - or a custom style if available.
Besides visual appearance, Controcc also considers certain system settings. One example is the animation setting. By default, Windows has animated effects, such as fading menus and sliding task groups. If a particular person finds these distracting, they can turn them off from the Windows display settings. In turn, Controcc will also turn off its animations.
Typically this sort of thing isn’t an issue for most people. It only starts to become an issue when a particular person changes the default settings, such as increasing the size of the text because they find it too small to read - only to find that certain software doesn’t change. If you have to work with that software on a daily basis, it can soon become aggravating.
Icons!
Icons, the small pictures used to represent actions or ideas, are very commonly used in software, and when used properly, play an important part in creating an effective UI. For example, pictures of a printer and some scissors are commonly used to represent the Print and Cut actions. Not only do they contribute to a vivid look and feel, but they are also a very effective way of labelling things within the system. Icons are easily identifiable and a good way of publicising functionality. Controcc uses icons to represent the following;
- Actions
- Entities
The program’s functions, such as “Save”, are available from various places, such as the main menu, the toolbar and popup context menus. These actions are assigned unique icons in order to both graphically represent their purpose and also to inform the user that any widget bearing this icon will perform the same, expected, action.
Controcc uses icons to represent the key concepts within the system, such as a contract, a service or a client. This has two benefits; one, a person looking at a screen with numerous fields can instantly understand that a field name “Authoriser” relates to a client because it bears the client icon. Two; it allows us reduce the clutter on screen as there’s no need to label the nature of fields, such as “Client: Bob Reeves” because the icon does this for us.
Screen Design Ethics
There’s more to UI design than the look-and-feel. There is a lot to be said for the way in which the content is arranged on the screen. A screen which contains the correct widgets may well be functional, but there’s no guarantee that it’ll be intuitive or even make sense to the end user, as the earlier pictures show. This final chapter discusses some of the mantra involved in OCC’s UI design process;
- Avoid Flooding the User with Excessive Controls
- Clear and Concise Labelling
- Maintaining Focus
- Contextual Help
- Tooltips
- Help Links
- “What’s This?”
As software evolves and the functionality increases, it’s all too easy to add buttons and menus to existing screens. There are many examples of software where new functionality has obviously been crammed in to a small space on the screen and as a result the entire screen becomes so perplexing to the user that they have no idea where to start. If there is more information than can sensibly fit on the screen, then it’s worth building a new screen or rethinking the design altogether.
In many cases, individual screens serve a variety of purposes. It is very important that fields are labelled clearly and concisely. For example, there is no point labelling a field “Client Address” when the field is being shown on the client screen. A field named “Date” makes little sense on a Contract screen, perhaps “Start Date” would be better. Furthermore, it’s a good idea to group related fields as this will help the user to understand their meaning.
It is very important to have a clear idea of the purpose of a particular screen. As software evolves, it’s very easy to bolt on related functionality to existing screens. A UI designer needs to ask themselves “What is the user doing on this screen? What do they need to see?” For example, when looking at the details of a service, information about service reviews is relevant, but not necessarily pertinent. It may be sufficient to show a summary of that information on the initial screen and then provide access to another screen with greater detail, should the user be interested. That way, the initial screen is kept as a concise overview and specific details which are not pertinent are easily accessible on demand.
Most commercial software comes with some form of help, typically in the form of online documentation. The larger the software the more important it is to have effective help. In software such as Controcc, a manual on its own is insufficient. If you happen to be stuck in a particular place, the last thing you want to do is open the manual and start reading through the contents in order to find help. Controcc employs a number of techniques to assist in this process and make the software easier to use. Such as;
Short descriptions appear over certain actions in order to explain their purpose.
Pressing F1 on any screen will open the online help browser and automatically display the appropriate page.
A new feature, similar to the Windows Control Panel, will allow a user to see a large description of any field on the screen, easily and instantly accessible by clicking the help pointer button and then the field in question.
Ongoing Development
Desiging a good UI involves a lot of planning and there are often many good solutions to the same problem. A particular design may seem ideal during the product development, but it's only until a substantial number of people start to use the software for real, that the problems emerge.
At OCC we are putting considerable effort into our products' usability and very much value any feedback, however trivial, from our clients. If you have an issue or suggestion regarding any of our products' usability, then please don't hesitate to contact the appropriate support team. If you have spotted a problem we are keen to hear about it as it is likely that others will spot it too.
In the next issue we will continue this topic and discuss aspects of workflow and the various techniques used by OCC to analyse and design the workflow in medium-to-large computer systems.

