|
|
|
First impression
A good user interface design can spell the difference between acceptance of a software product and its failure in the marketplace. If the end-users find the software to be too cumbersome or difficult to understand, then an otherwise excellent product could be doomed to failure. The developer’s goal should be to make the software professional-looking as well as easy to use.
Following are some fundamental principles for designing user interfaces. These principles have been adopted from an essay — A summary of principles for user-interface design — by Talin.
User profiling — know your user:
Before we can answer the question, “How do we make our user-interfaces better”, we must first answer the question, “Better for whom?” A design that suits a technically skilled user, may not suit a non-technical businessman or an artist. So try to tackle the following issues in the beginning.
— What are the user’s goals?
— What are the user’s skills and experience?
— What are the user’s needs?
It is better to directly contact the end-users because the interaction between users and developers has often radically transformed the development process.
The principle of metaphor — borrow behaviour from systems familiar to your users:
Often, a complex software system can be understood more easily if the user interface is depicted in a way that resembles some commonplace system. The ubiquitous “desktop metaphor” is an overused and trite example.
Once a metaphor is chosen, it should be spread widely throughout the interface, rather than used once at a specific point.
Metaphor is not always necessary. In many cases, the natural function of the software itself is easier to comprehend than any real-world analogue of it.
The principle of feature exposure — let the user see clearly what functions are available:
Some of the customers prefer user interfaces that utilise the power of abstract models: command lines, scripts, plug-ins and macros. Whereas, others prefer user interfaces that utilise their perceptual abilities.
In other words, they like interfaces where the features are “up front” and “in their face”. Toolbars and dialogue boxes are an example of interfaces that are pleasing to this personality type.
This does not mean that you have to make everything a Graphical User Interface (GUI). What it does mean, for both GUI and command line programs, is that the features of the program need to be easily exposed so that a quick visual scan can determine what the program actually does.
The principle of coherence — the behaviour of the program should be internally and externally consistent:
An interface should be coherent. In other words, it should be logical, consistent, and easy to follow. Internal consistency means that the program’s behaviour make sense with respect to other parts of the program. For instance, if one attribute of an object (like colour) is modifiable using a pop-up menu, then it is to be expected that other attributes of the object would also be editable in a similar fashion. External consistency means that the program is consistent with the environment in which it runs.
The principle of state visualisation — changes in behaviour should be reflected in the appearance of the program:
Each change in the behaviour of the program should be accompanied by a corresponding change in the appearance of the interface. When a program changes its appearance, it should be in response to a behaviour change.
A program that changes its appearance for no apparent reason will quickly teach the user not to depend on appearances for clues as to the program’s state.
One of the most important types of state is the current selection, which means that the object or set of objects that will be affected by the next command. It is important that this internal state be visualised in a way that is consistent, clear, and unambiguous.
The principle of shortcuts — provide both concrete and abstract ways of getting a task done:
Once a user has become experienced with an application, he will start to build a mental model of that application. He will be able to predict with high accuracy what the results of any particular user gesture will be in any given context. At this point, the program’s attempts to make things “easy” by breaking up complex actions into simple steps may seem cumbersome.
Additionally, as this mental model grows, there will be less need to look at the “in your face” exposure of the application’s feature set. Instead, pre-memorised “shortcuts” should be available to allow rapid access to more powerful functions.
The principle of grammar — UI is a kind of language, so know what the rules are:
Many of the operations within a UI require both a subject (an object to be operated upon) and a verb (an operation to perform on the object). This naturally suggests that actions in the user interface form a kind of grammar.
The grammatical metaphor can be extended quite a bit, and there are elements of some programs that can be clearly identified as adverbs, adjectives and so on.
The two most common grammars are known as “Action->Object” and “Object->Action”. In Action->Object, the operation (or tool) is selected first. When a subsequent object is chosen, the tool immediately operates upon the object. The selection of the tool persists from one operation to the next, so that many objects can be operated on one by one without having to re-select the tool.
Action->Object is also known as “modality”, because the tool selection is a “mode” which changes the operation of the program.
The principle of help — understand the different kinds of help a user needs:
There are five basic types of help, corresponding to the five basic questions that users ask:
1. Goal-oriented: “What kinds of things can I do with this program?”
2. Descriptive: “What is this? What does this do?”
3. Procedural: “How do I do this?”
4. Interpretative: “Why did this happen?”
5. Navigational: “Where am I?”
The principle of safety — let the user develop confidence by providing a safety net:
It is important for new users that they feel safe. They do not trust themselves or their skills to do the right thing. Many novice users think poorly not only of their technical skills, but of their intellectual capabilities in general.
A program with no safety net will make this type of user feel uncomfortable or frustrated to the point that they may cease using the program. The “Are you sure?” dialogue box and multi-level undo features are vital for this type of user.
The principle of context — limit user activity to one well-defined context:
Each user action takes place within a given context: the current document, the current selection, the current dialogue box. A set of operations that is valid in one context may not be valid in another. Even within a single document, there may be multiple levels.
It is usually a good idea to avoid mixing these levels. For example, imagine an application that allows users to select a range of text characters within a document, and also allows them to select one or more whole documents (the latter being a distinct concept from selecting all of the characters in a document). In such a case, it is probably best if the program disallows selecting both characters and documents in the same selection.
Another thing to keep in mind is the relationship between contexts. For instance, it is often the case that the user is working in a particular task-space, when suddenly a dialogue box will pop up, asking the user for confirmation of an action. This sudden shift of context may leave the user wondering how the new context relates to the old one.
This confusion is exacerbated by the terseness of writing style that is common among application writers. Rather than the “Are you sure?” confirmation mentioned earlier, something like “There are two documents unsaved. Do you want to quit anyway?” would help to keep the user anchored in their current context.
The principle of aesthetics — a program of beauty:
It is not necessary that each program be a visual work of art. But it is important that it not be ugly. Buttons look better if they are exactly the same size. In other words, to encode some of the rules of graphical design into the layout algorithm.
Another area of aesthetics to consider is the temporal dimension. Users do not like using programs that feel sluggish or slow. There are many tricks that can be used to make a slow program “feel” snappy, such as the use of off-screen bitmaps for rendering, which can then be forwarded, in a single operation.
The principle of user testing — recruit help in spotting the inevitable defects in your design:
In many cases a good software designer can spot fundamental defects in a user interface. User-interface testing, that is the testing of user-interfaces using actual end-users, has been shown to be an extraordinarily effective technique for discovering design defects. User testing can occur at any time during the project, however, it is often more efficient to build a mock-up or prototype of the application and test that before building the real program.
|
|
|
|
