The Interface Design Process

Key ideas#

Three steps, repeated#

The cycle is initial design, then a prototype, then testing and modification, repeated. More care in the first step shortens the third but lengthens the first; the trade-off is unavoidable. Start on paper, because a screen editor tempts you to polish a variant you’ll throw away five minutes later. Golovach also counts the technical writer as an ally: the clearer the interface, the less there is to explain, so writers are good detectors of bad design.

Seven stages of initial design#

1. Define the functionality. Features are almost impossible to remove once sold, so plan several versions ahead. Treat sales requests, such as complaints or competitors’ features, as symptoms to analyze, not orders. Combine two analyses. User goals: people want results (toast, not a toaster). User actions: how they reach those results today, which you learn only by observing them. Beware of egocentrism: “I need it, so everyone does.”
2. Write user scenarios. These are plain-language descriptions of interaction with named characters and no implementation detail, covering every type of task. They become test material, and they already reveal unnecessary steps.
3. Pause for inspiration. Ask “could this be fundamentally better?” while change is still cheap.
4. Design the overall structure. Split the system into independent blocks of about three functions each and define the links between them. Links can be logical; based on how users group concepts, found by card sorting with at least four or five target users; or procedural. Sometimes it is worth enforcing a sequence to cut errors and learning time.
5. Design the screens. This is the least algorithmic stage. Golovach recommends the Keystroke-Level Model from the GOMS family (Card, Moran and Newell) here. You break each design alternative into elementary operations (keystrokes, pointing, moving a hand between mouse and keyboard, deciding) and add up their standard times. That lets you compare designs without a prototype. The model suits experienced users and ignores learning, errors and satisfaction. Also watch for adaptive functionality: the system taking on more complex logic so that the user’s logic becomes simpler. It is found only by observing users.
6. Build a glossary of every term in the interface: button labels, menu items, window and mode names. Then iterate. Shorten, test comprehension with users, use one name per concept, align with the platform’s style, and use verbs for commands.
7. Assemble and check. Combine structure, screens and glossary, and plan how exceptions are handled, such as commands unavailable for a given object. Then rewrite every scenario without looking at the schema and compare. Mismatches almost always appear, and now is when they are cheapest to fix.

Expert review#

An expert review doesn’t replace testing, but it needs no prototype, so it can happen early. Several experts beat one, one after another beats all at once, and more context leads to deeper findings. Keep the report short (one or two pages) to avoid nitpicking.

Prototype fidelity#

Golovach names four levels: paper; a slide presentation with screens linked by hyperlinks, which is enough for most systems; realistic screens without logic; and working code, for areas that can’t be faked. The main mistake is over-polishing an early prototype.

Testing#

Testing finds weak spots, but not strengths or new ideas. Don’t ask users what they want; observe what they do. The methods are silent observation (best for finding ambiguities and measuring speed and errors), thinking aloud (finds problems but distorts timing), and drawing the screen from memory afterwards (shows what users actually noticed). During a session, never interrupt, apologize, promise fixes or blame. Don’t call it “user testing”, or participants will think they are the ones being tested. Test from the start; experience shows in fewer iterations, not in none.