Concepts of Interface Quality
In short What makes an interface “good”? Vlad Golovach compares six competing answers, from Shneiderman’s measures to ISO usability and commercial success, and turns them into eight questions you can ask of any screen. For analysts, they give a ready-made frame for usability requirements and UI reviews.
Based on: V. Golovach, User Interface Design 2: The Art of Washing an Elephant (in Russian), part II “What Is a Good Interface”.
On this page
Key ideas#
Everyday words don’t work#
“Convenient”, “simple” and “usable” are how people judge interfaces, but they are too vague for professional work. “Simple” may not even be achievable: an aircraft cockpit is more complex than a hang-glider’s controls without being badly designed. Golovach’s advice is not to use these words in your own work, but to expect users to judge in exactly these terms.
Shneiderman’s measures#
Ben Shneiderman proposed five measurable characteristics: speed of performance, rate of user errors, subjective satisfaction, time to learn, and retention of skills over time. Their strength is precision, since “faster” is easier to work on than “more convenient”. Golovach lists the weaknesses. The measures are incomplete (operator fatigue isn’t covered) and they conflict (speed against learning). In practice you can usually improve only two at once, and the concept doesn’t say which two. Learning time and retention are also hard to measure and often irrelevant for daily-use systems.
Three design philosophies#
- User-centered design (UCD): study the audience and optimize for it; the developer’s opinion doesn’t count. Golovach’s objections: where users are paid and easily replaced, as at a cashier’s terminal, productivity outweighs their opinion. People also adapt, so complaints about a new version fade after a few weeks. And the research is expensive and open-ended.
- Task-centered design (TCD): an interface is good if users’ tasks get done efficiently. This allows economic estimates and keeps projects manageable, but it has no stopping rule. More tasks always looks better, which feeds feature creep.
- Goal-centered design (GCD), which Golovach prefers to call motive-centered: people perform tasks to satisfy personal motives. His example is a secretary entering a meeting dictated over the phone. The task view yields “support creating calendar events”. The motive view (not getting blamed for a wrong entry) reveals that accuracy matters more than speed. A practical tip: list the audience’s motives and compare them with the task list. Mismatches point to gaps in your task analysis.
Usability (ISO 9241-11)#
The standard combines the earlier ideas (specified users, goals, and measures of effectiveness, efficiency and satisfaction) and adds context of use: equipment, noise, interruptions, monitoring of staff, required speed. Golovach finds the standard’s terms vague. He suggests replacing them with Shneiderman’s measures and replacing “context of use” with the more concrete “environment”.
Commercial success#
Golovach considers this the most practical concept: a good interface helps the product sell. Measures are not equal here, and satisfaction matters more commercially than error count. Related points:
- Users call “simple” what is familiar, and “convenient” what needs no unproductive actions. So look for extra steps and remove them.
- Improvements should be explainable in a few words and should look good in screenshots.
- When buyer and user differ, choosing whom to serve is a real dilemma. The common mistake is to forget one side entirely.
- The designer is paid by the client and should work for the client’s success. An unsuccessful product doesn’t help users either.
He adds one more test, deliberately provocative in wording: is the interface “sexy”, meaning something people want to have?
How to apply it#
- Write usability requirements in Shneiderman’s terms, with numbers: task time, error rate, learning time, satisfaction score. Pick the two that matter most for this system and say so.
- Elicit motives, not just tasks. Ask what people fear and what they want around each task.
- Capture the environment as a source of requirements: noise, interruptions, devices, gloves, supervision.
- Run the eight questions on each screen fragment in prototype reviews.
Review checklist: the eight questions#
Golovach applies these to one fragment at a time, in order. If any of the first seven reveals a problem, keep working on that fragment before going further.
- Can interaction with this fragment be made faster?
- Where might it cause errors, and can that be changed?
- What here gets in the way of learning?
- Do we know anything about the users that makes it bad?
- Does it satisfy all known user motives?
- Does it fit the environment users work in?
- Are any tasks handled inefficiently? (Narrate the user’s path aloud, in the first person.)
- Would people want it, and can it become more desirable?
Example#
At The Workshop, a fictional chain of bike-repair workshops, the analyst runs the eight questions on the front-desk check-in fragment:
- Speed: the phone-number field is not focused when the screen opens.
- Errors: the repair-type list has two near-identical entries.
- Learning: nothing shows which fields can be left for later.
- Users: many front-desk staff are new seasonal hires.
- Motives: staff fear quoting a wrong price in front of the customer, so the estimate needs a “subject to diagnosis” note.
- Environment: the counter is noisy and busy, so no sound-only alerts.
- Tasks: narrating the path reveals two screen switches to find a customer’s previous bike.
- Desirability: managers want check-in to feel as quick as at competing shops.
Each finding becomes a change request.
Sources and further reading#
- V. Golovach. User Interface Design 2: The Art of Washing an Elephant, v2.11 (in Russian; freely distributed), 2010, part II “What Is a Good Interface”.