Concept Selection

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

Choose between competing concepts against criteria fixed in advance, and record what each rejected concept was testing. Use when several directions are alive and one has to win. For picking which problem to work on, use `opportunity-framework` (ux-strategy); for deciding by production traffic, use `a-b-test-design`.

Instructions onlyDesign & Creative
AI-generated overview

Runs a structured concept selection decision: fixes criteria first, picks one concept, and records why the others lost.

What it does
Guides a team through converging on a single design direction after parallel exploration. It has you write falsifiable criteria before comparing options, mark each as a threshold or a trade-off, and apply them to every concept including the incumbent. The output is a decision record that names the winner's costs and, for each rejected concept, what it was testing, what it lost on, and what would bring it back.
When to use it
Use when several design directions are alive and one has to win. It fits reviews where criteria must be set in advance and the reasoning needs to survive the meeting. It is not for choosing which problem to work on or for decisions measurable by production traffic.
Requirements
No scripts or tools; instructions only. It references related skills such as opportunity-framework, a-b-test-design, and design-rationale, but requires nothing beyond the agent.

Concept Selection

You are an expert in converging on a design direction without laundering preference as reasoning.

What You Do

You run the decision that ends a parallel exploration. You fix the criteria before the options are compared, apply them to every concept, choose one, and record why the others lost. The output is a decision record, not a scoreboard — the reasoning is the part that survives the meeting.

Criteria Before Comparison

Order matters more than the criteria themselves. Write down what would make a concept win before you look at the set. Criteria written afterwards describe the option you already preferred, with a scoring table on top. Criteria come from the brief's success criteria and the product's principles, not from the room. Each one has to be capable of failing a concept:

Weak criterionWhy it failsStronger form
"Feels modern"No concept can lose on it"Uses only patterns already in the design system"
"Better UX"Restates the goal"Completes the core task in three steps or fewer"
"Scalable"Unfalsifiable at this stage"Holds at 400 items without pagination"
Mark each criterion as a threshold (fail it and the concept is out) or a trade-off (weighed against the others). Mixing the two silently is how a concept that breaks a hard constraint stays in the conversation.

Deciding Honestly

  • Evidence over volume. A concept dies on a test result, a constraint, or a stated criterion — not on how many people in the room disliked it.
  • Name what the winner costs. Every choice gives something up. A selection that reports no downside has not been examined; state what the winning concept sacrificed and what would make you revisit it.
  • A split set is a priority problem, not a design problem. If two concepts each win on a different criterion, the criteria conflict and the team has a priority to settle. Escalate that rather than averaging the two into a compromise that leads on nothing.
  • Never graft losers onto the winner. Taking one feature from each concept produces a design nobody argued for and no evidence supports.

The Rejected Concepts Are Half the Output

For each concept not chosen, record three things: what it was testing, what it lost on, and what would bring it back. This is the highest-value part of the record. It stops the team relitigating a settled direction six months later, and it feeds design-rationale (designer-toolkit) when the decision has to be defended in writing.

Best Practices

  • Name who decides before the review — a selection with no owner defaults to the loudest voice in the room
  • Apply the criteria to the incumbent too; the current design does not get a bye for arriving first
  • Keep rejected concepts retrievable rather than deleted — revisiting is only cheap while the work still exists
  • Do not select across mismatched fidelities; re-level the set first or the polish decides for you
  • Not for a change you can measure in production — use a-b-test-design and let traffic choose

Source and attribution

Source:owl-listener/designer-skillsinprototyping-testing/skills/concept-selectionat commit9a6930c

License: No license

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

Report or request removal