parallel-concepts

Original：🇺🇸 English

Translated

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`.

5installs

Sourceowl-listener/designer-skills

Added on2026-09-05

NPX Install

npx skill4agent add owl-listener/designer-skills parallel-concepts

SKILL.md Content

View Translation Comparison →

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)