Iterative Design

Overview

How do you compensate for never having complete information about what customers actually need?

The second pillar of Customer-Centered Design (the first being Know Your Customers): repeatedly cycling through design → prototype → evaluate with measurable goals, refining a website until it meets or surpasses them, rather than designing once and shipping. The premise is that no design team has complete information about customer needs, so the process is built to compensate for that gap rather than assume it away, and it forms the core technique of Usability Engineering.

The three-step cycle

Design — consider business goals and customer needs, set measurable goals, develop design concepts.
Prototype — build artifacts ranging from scenarios and storyboards to running sites (see Rapid Prototyping).
Evaluate — assess whether the prototype meets the goals set in step 1 (see Usability Evaluation Methods, and A/B Testing for live quantitative comparison of design variants).

The results feed the next iteration. Design patterns help move quickly through each step: high-level patterns rough out early features, low-level patterns help storyboard specific scenarios, and patterns are consulted again to fix problems evaluation turns up.

Why iterate: the cost of late fixes

Errors are roughly 10x more expensive to fix late in a project compared to when they are caught early, and 100–1000x more expensive once the site has shipped (a figure attributed to software-engineering research, e.g. Watts Humphrey). Downstream changes are expensive for three reasons: every later deliverable has to be made consistent with the change, one change often forces others, and anything touching source code/HTML is costly to redo. Studies cited from the Standish Group International attribute many IT project failures specifically to a lack of end-customer input — the problem iterative design is meant to solve.

Errors are roughly 10x more expensive to fix late in a project compared to when they are caught early, and 100–1000x more expensive once the site has shipped (a figure attributed to software-engineering research, e.g. Watts Humphrey).

The Marshmallow Challenge

A concrete demonstration of the same argument: build the tallest freestanding structure that can support a marshmallow’s weight, in 18 minutes, using 20 sticks of spaghetti, one yard of tape, and one yard of string. Run against many different groups, it consistently produces a counter-intuitive result: kindergartners outperform business school graduates. Adult teams spend most of their 18 minutes planning and negotiating status before attempting a single structure — often their first “prototype” is also their only one, so they discover it doesn’t stand only when time has nearly run out. Children skip planning almost entirely and start building immediately, running through several small structures in the same 18 minutes and improving on each failure. The design → prototype → evaluate cycle above is, in effect, exactly what the children are doing and the adults aren’t.

Kindergartners outperform business school graduates.

The right-feature / right-implementation framework

Design mistakes fall into a 2×2 grid crossing feature (right vs. wrong) with implementation (right vs. wrong):

Right feature, wrong implementation — e.g. a shopping cart that’s the correct feature for an e-commerce site but is hard to actually check out with. Iterative testing surfaces these.
Wrong feature, right implementation — e.g. a beautifully-built advanced search that most customers don’t understand or need.
Wrong feature, wrong implementation — neither useful nor functional.

The goal is the fourth quadrant: right feature, right implementation. Iterative design pushes a project toward it by continually feeding customer feedback about both dimensions back into the next design pass.

Not every iteration is a refinement, though. Even carefully evaluated ideas can still fail a user test outright — even the best usability experts cannot design a perfect interface on the first attempt — and when that happens, the right response is discarding the current direction for a genuinely different one, not polishing what’s already there. Because a test can call for that kind of change at any point, a project needs flexibility built into its whole architecture from the start, not just its surface-level design.

Even the best usability experts cannot design a perfect interface on the first attempt — and when that happens, the right response is discarding the current direction for a genuinely different one, not polishing what’s already there.

Goals and principles

Design goals (faster task completion, fewer errors, higher conversion, more repeat visits, etc.) come from analyzing business and customer needs — see Know Your Customers. Design principles — seven of them, adapted from Shneiderman, Nielsen, and Tufte — guide how patterns get applied to reach those goals; see Interface Design Principles. The two are complementary: goals are the destination, principles are the route.

Achieving goals requires testing and measuring. Useful metrics include task completion time, task success rate, ease-of-learning (time or attempts needed to reach proficiency), error rate (with errors explicitly defined in advance, since something as simple as clicking the browser Back button is ambiguous), shopping-cart abandonment rate, and subjective measures like satisfaction or “fun,” gathered via surveys. A metric like cart abandonment can have multiple root causes beyond interface design — pricing, missing inventory, surprise shipping costs — so a single number rarely diagnoses the actual problem on its own. Getting statistically meaningful numbers typically requires 20–50 research participants. These site-level metrics are themselves only proxies for higher-level business goals (e.g. revenue), which prototypes generally can’t measure directly.

Information architecture (structuring content), navigation design (helping customers move through that structure), and graphic design (visual communication via color, type, layout) are the three design activities iterative design is applied to; they overlap, and traditional “user interface design” sits mostly at the intersection of navigation design and usability evaluation. None can compensate for failure in another — rich graphic design can’t fix a poor information architecture, and vice versa.

This cycle scales up beyond a single prototype: the Web Site Development Process applies design→prototype→evaluate both across an entire project’s seven phases and within each individual phase.

For the complete summary of Chapter 4 of The Design of Sites — covering design goals and principles, rapid prototyping, and evaluation in their source context — see The Design of Sites: Ch. 4 — Involving Customers with Iterative Design.

Patterns

Process Funnel

Principles

Interface Design Principles

Processes

Sources

The Design of Sites: Ch. 4 — Involving Customers with Iterative Design (Chapter 4) is the primary source for the three-step design→prototype→evaluate cycle, the 10x/100–1000x cost-of-late-fixes figures, and the right-feature/right-implementation 2×2 framework.

Iterative Design (Wikipedia) (CC BY-SA) supplies the Marshmallow Challenge demonstration and the case that a failed user test can call for a genuinely different design rather than a refinement of the current one.