Parallel Concepts

by owl-listener9a6930cf84a8No license2.8K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 4 weeks ago

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

Instructions onlyDesign & Creative
AI-generated overview

Guides building several genuinely different solution concepts for one problem in parallel before committing to any single direction.

What it does
This skill instructs an agent to take a problem that already has a proposed solution and construct a set of genuinely different solutions held at equal effort. It explains why parallel exploration beats serial iteration, defines what makes concepts distinct through behavioural differences such as sequence, unit of interaction, division of labour, entry point and commitment point, and gives guidance on sizing the set. It produces a set of comparable-fidelity concepts plus the question the set must answer. It does not rank or eliminate concepts.
When to use it
Use when one direction is on the table and the team is about to refine it by default, or when you want to explore the solution space before committing. It is meant for early, cheap exploration while a concept still costs a sketch rather than a build. For choosing between the concepts afterwards, a separate selection skill is indicated.
Requirements
No scripts or tools required; instructions only. The agent needs no packages, credentials, or network access.

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)

Source and attribution

Source:owl-listener/designer-skillsinprototyping-testing/skills/parallel-conceptsat commit9a6930c

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal