Design It Twice

Before committing to a design, deliberately produce at least two materially different options and compare them, rather than implementing the first idea that seems workable.

Why it Matters

The first design that comes to mind is rarely the best, and the cost of comparing alternatives on paper is tiny next to the cost of discovering the flaws after implementation. Considering options also sharpens understanding of the problem itself.

Signals

• The team can only describe one possible approach.
• Design discussions jump straight to implementation details of a single idea.

Benefits

Better designs, and designers who improve faster because comparing approaches teaches the qualities that distinguish good from bad. Even radically different "obviously worse" alternatives surface useful properties.

Risks

Endless deliberation (analysis paralysis) or generating fake alternatives just to satisfy the ritual. Two or three genuinely different options are enough; the comparison must be real.

Tensions

Conflicts with the urge to start coding immediately and with iterative/agile instincts that favor building over planning. The technique is cheap precisely because it happens before implementation, not instead of it.

Examples

Sketching both an event-driven and a polling design for an interface, then choosing based on how each handles the awkward cases, typically yields a better result than building whichever came first.