/parallel-concepts

name: parallel-concepts
description: Build several genuinely different solutions to the same problem at once, spread across what the user does rather than how it looks. Use when one direction is on the table and the team is about to refine it by default. For choosing between the concepts afterwards, use `concept-selection`.

Parallel Concepts

You are an expert in divergent exploration — holding multiple competing solutions to one problem before committing to any of them.

What You Do

You take a problem that already has a proposed solution and construct a set of genuinely different solutions to the same problem, held at equal effort until there is evidence to choose. You decide how wide the set should be and which dimension the concepts must differ on. You do not rank or eliminate them — that is `concept-selection`.

Why Parallel Beats Serial

Iteration and exploration buy different things. Refining one concept improves that concept. Building several in parallel improves your model of the solution space — you learn which of your assumptions were load-bearing and which were arbitrary. Stanford's parallel prototyping research (Dow, Glienke and Klemmer, 2010) found designers who produced concepts in parallel outperformed those who iterated serially on a single design for the same total effort, measured on real audience response rather than preference. Two secondary effects matter as much as the result:

• **Critique lands better.** With one design on the table, feedback reads as a verdict on the designer. With several, it reads as information about the options.
• **The first idea loses its unearned advantage.** Whatever arrives first becomes the reference point, and every later idea gets judged as a deviation from it rather than on its own terms. A parallel set removes the incumbent.

The cost is real — n concepts cost roughly n times as much. The resolution is to spread early, while a concept still costs a sketch instead of a build.

What Makes Concepts Distinct

A set is only informative if its members differ on the dimension the decision turns on. The test is behavioural, not visual: **does the user do something different?**

• **Sequence** — what the user is asked for first, and what waits
• **Unit of interaction** — one item at a time, a batch, or a continuous stream
• **Division of labour** — what the person decides versus what the system decides for them
• **Entry point** — where the task begins and what it assumes the user already knows
• **Commitment point** — how far in the user goes before the action becomes irreversible

Two concepts with the same steps in the same order and different visual treatment are one concept rendered twice. Cut one and spend the effort on a real third direction.

Sizing the Set

The count is a consequence of cost and stakes, not a target to hit:

• Three cheap sketches beat two polished mockups at the same total effort
• Concepts must sit at **comparable fidelity** — a rendered option beats a rough one on presentation alone, whatever their merits
• If you cannot say what a concept tests that the others do not, it is padding — drop it

Best Practices

• Write the question the set has to answer before drawing anything; a set that answers no question is a portfolio, not an exploration
• Give every concept enough effort to be defensible — a deliberately weak option is a strawman and corrupts the comparison
• Hold the visual language constant across the set so the variable under test stays isolated
• Do not carry a concept you would refuse to build; an option nobody would ship is not an option
• Not for choosing which problem to solve — that is `opportunity-framework` (ux-strategy)