USABILITY
by Ian Piper (ian@vb-online.com)
September, 1995
Who needs HCI?
Part one of a series on usability design with Visual Basic
HCI?? That’s Human-Computer Interaction. Whoah! Before you move off to something more interesting, at least read this first paragraph. HCI spells usability. It means designing your programs so that they are easy to use. If you are writing programs in VB for real, ordinary, mortal people to use, you should be considering HCI as a fundamental part of your design. And you need to do it for reasons that will improve your life and the lives of the people who are your customers. A big claim, certainly. But here are a few of the improvements you will see when your programs are more usable:
When I say this, I mean that
I hate computer-techie verbiage, so I hope I’m not going to fall into the trap of talking too much of it. There are a few terms which I’m going to use throughout this article, and here they are, with their plain English renditions:
What is HCI?
Human-Computer Interaction is the study of the capabilities and limitations of people in conjunction with computer systems. You can also think of it as the actual processes and activities that people undertake in using these systems. That’s the academic analysis. I think of it more as a partnership between the system, the system designer and the end-user so that the designer can reveal the functions of the system to the user, and can ensure that the user’s wishes and needs are imparted clearly to the computer system.
You can see at the outset that this imposes an important duty on you as a designer: that of an interpreter, translator or communicator.
Designer software
You may be writing software as a one-person operation. In this case you probably have a vision of what your software will do, and you need to ensure that your user can share that vision. So the software needs to clearly reveal its functions to the user. This is not trivial. If you’re like me you write software to solve your own needs, so you have a clear view of what the software has to do. It’s hard to take a step back, look objectively at the system you are designing and work out the parts which users are not going to find easy to use. I hope that I can provide some practical advice for this.
More often as a designer you are writing software to someone else’s requirements. This makes some things easier, others more difficult. It’s easier because you usually have a chance to get an understanding of the user’s needs and the environment where your system will be used. It’s harder because you have are not usually in control of the design, and have to balance user needs and your expertise in design with the requirements of the sponsor of the project (who may be under pressure to deliver and see usability as an obstruction).
HCI is not just about interfaces
The most common misconception about HCI is that "GUIs make programs easy". I have personally encountered the view from project managers that the right place for usability is at the end of the project: "Look, we’ve started now. Let’s get the program written and then put a pretty picture on the front when we’ve got that out of the way". This cuts straight to the heart of the issue with usability. Usability design should be holistic - the entire structure of the program is important in ensuring you have good HCI. Just putting a graphical front end on an otherwise badly designed program does not make it easier to use.
HCI work is often incorrectly equated with GUI design. In fact I have found that some of the worst examples of usability design have occurred with Windows-based programs. Poor memorability, inconsistent functions and keyboard shortcuts, confusing and complex dialogs, misleading messages and a host of other indignities visited upon the poor benighted user are common in Windows-based software.
I think this situation is partly due to the fact that easy programming systems for Windows are now common. I like to draw the comparison with the situation when PostScript fonts and printers first became available. People suddenly realised that they had 35 fonts to play with, so naturally used all of them in every document. The results were predictable - visually confusing documents which were put together with little thought for design, layout or the job which the document had to do.
In contrast, one of the most clearly usable programs I have ever seen - the Novell Netware syscon utility - is still a character-based program.
In summary, the user interface is vitally important, but it is merely one component of an overall system design which has to take into account numerous factors.
HCI is about users, tasks and environments
The scope of HCI is not restricted to the layout of the screen display, but encompasses the whole of the input systems - for example the design of the keyboard, mouse or pen as input devices - and the output systems - what comes out of the computer may be the display of information on a screen in a graphical or text format, maybe supported by animation or sound, and it may be a printed result on paper.
HCI also has to take into account the environment within which the person has to interact with the computer, as this will have an impact on the type of input and output and the quality of the interaction.
For example, it would not be appropriate to have a system communicating with the user with extensive use of sound if the system to be used in an otherwise quiet office. A drawing program may work best with a pen input, but may have to be flexible enough to work with a mouse. Word processing systems are more frequently relying on a mouse, but a large number of users (particularly secretarial users) feel more comfortable with the keyboard, so the design should take this into account. In the organisation where I work this actually happened. The old corporate word processor was a highly unusable character-based system which was universally loathed. We moved to a Windows-based system. To our amazement, despite the considerable improvement in general ease of use, the secretaries were less happy with this than with the old system. The reason was that they were touch typists, and were used to being able to keep their fingers on the home keys and using keyboard combinations to do all of the tasks. With the new system they had to keep taking their hands off the keyboard and grabbing the (then) new-fangled mouse. In our selection of the new system we hadn’t considered all of the environments, users and tasks for which the new system would need to work.
Why usability is important for users
Your users are your sales force
If you are designing software on your own, for freeware, shareware or commercial use, you may never meet your users. So why should you care about what they think about its usability? Well, remember that your users can be your best sales force. They will recommend good products to others. Also, people want an easy life. I know when I look at a new piece of software I think about how easy it is to install, configure and run it without checking out the readme files. If it doesn’t shine here I junk it. There are plenty of programs which may be technically excellent but designed with so little thought that people end up using competitive products which are less feature-filled but more usable.
Happy users are effective users
People are more content using systems that are easy and enjoyable to use. This is important for the business in that a positive attitude to the work means that staff will be more motivated to get results and are more likely to stay with the job, leading to lower staff turnover. With a usable computer system the user can focus on the main purpose of the job rather than the technology of the system.
For the same reason, usable systems need less support. In my own organisation, it is a matter of record that most support queries result from users not understanding a function of the system which is probably working as designed. This may mean that the user wasn’t trained in the first place, that the user was trained but didn’t understand or has forgotten, or that the program is giving the user misleading advice or information. In any case this translates to a system that has not been designed with the tasks, needs and capabilities of the user as its most fundamental requirement.
Why HCI is important for developers
Do it right the first time
Designing a computer system once properly is likely to offer savings in time and money compared with designing once then modifying later. And if you have designed your system to reflect the tasks the user has to accomplish, their capabilities and shortcomings, then the chances are that you will get it right the first time.
Usable programs, re-usable programs
A piece of software which has been written with usability in mind tends to have been written in a modular and re-usable fashion. This is a controversial opinion, but I think it will prove to be the norm in future software development, and it is an area in which Visual Basic, in particular, shines. Because of the graphical and modular nature of the development environment, VB designers have an opportunity to make more usable progams than programmers in most other systems.
Perhaps I should explain exactly what I mean by re-usable code. I’m not talking about formal code version-control systems. I’m starting from the premise that programmers often write a number of programs which do similar things. With Windows programming tools this is made easy for you to some extent because you can use the common dialogs to give all of your programs the same appearance and behaviour for opening, saving, printing and similar functions. What we have here is a re-use of highly usable code, and what I’m suggesting is that in your own suites of programs you aspire to do the same thing. Identify the reusable funtions of your programs and try to design the code so that it can easily be lifted out and used elsewhere. You don’t need to build it into DLLs or VBXes, by the way. Visual Basic allows you to use forms and modules in a highly re-usable way if you follow a few rules, and I’ll be going into this in depth in a future article.
What should the designer be doing?
The main role of the designer in HCI terms is to enhance the quality of the interaction between humans and computer systems. Ted Nelson (of Computer Lib and hypertext fame) put forward a Ten Minute Rule, saying that this is how long it should take for a naive user to underestand how to use a new computer system. The Ten Minute Rule is probably too ambitious for most realistic computer systems, but a word processing package should not need five days of training to learn, and the basic features of an operating system for an ordinary user shouldn’t need a manual.
Without an appreciation of HCI the design of a computer system often starts from a functional standpoint - what can the computer (or the programmer) do? - rather than an attempt to understand the needs and capabilities of the users in conjunction with those of the computer and to develop the system with those factors at the centre. An ideal system should be able to provide information and choices for action to the user, and receive information and instructions from the user, in forms that the user finds convenient.
Achieving all of this involves having to gain an understanding of the abilities and shortcomings of both the human and computer components in the interaction.
The designer needs to consider what will be the most appropriate input and output devices for the system - dependent on the nature of the task, the type of user, the environment where the system will be used. In addition, he/she needs to choose the actual mechanism of communication between human user and computer - forms, menus, a command line spoken commands - and again this will be dependent upon the user, task and environmental factors listed above.
And that’s it for now
That’s all I have to say in the way of introductory comments. I hope I’ve provoked some thoughts in you about why it is so important for us as developers to gain a good understanding of the principles of design and the needs and abilities of our users as part of the process of writing good software.
What’s on the horizon
I will be going into the ideas I’ve introduced in this article over the next few issues. Here are some of the topics I’m going to deal with:
[About Ian Piper: Ian is payed by a large multinational company to spend all day playing with computers, and write free software in VB for fun. He also does freelance DTP and technical writing. Ian is working towards setting up his own telecottage, somewhere other than the South-East of England. When he can tear himself away from his computer he walks up large hills in places other than the aforementioned South-East of England. Ian can be reached at ian@vb-online.com]