concept-selection — Claude Code skill: pick one concept from many

---
name: concept-selection
description: 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`.
---
# 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 criterion | Why it fails | Stronger 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