Design Concept

Origin & evolution

The concept as a design artefact comes out of design thinking and the studio tradition that IDEO popularised. The ideation phase is explicitly divergent: generate many candidate ideas, defer judgement, prize quantity and variety over immediate feasibility. A design concept is one of those candidates, made concrete enough to discuss but not so finished that abandoning it feels expensive.

The discipline pairs that divergence with convergence. After generating a wide field of concepts, teams narrow deliberately, combining, refining, and selecting the few worth developing. A concept therefore carries a lifecycle status, from exploring through validated to selected or rejected, and the rejected ones matter: a recorded rejection with its rationale stops a team relitigating a path it already walked.

Gothelf and Seiden's Lean UX frames this more sharply: a concept is a hypothesis🧪HypothesisValidationA testable belief about a solutionView reference → about outcomes🏆OutcomeStrategyA desired business or user outcomeView reference →, not a deliverable. By that reading, the rationale field is not administrative — it is the explicit assumption🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference → the team is making, and the lifecycle status (exploring → validated → selected/rejected) is the record of how that assumption was tested. A concept without a rationale is a guess without a bet.

The lasting refinement is the discipline of keeping options open. IDEO's practice of generating multiple distinct concepts before committing, sometimes built into rough prototypes📱PrototypeExperience DesignAn interactive mockup for testingView reference → in parallel, exists because the first plausible idea is rarely the best one, and because comparing real alternatives produces better decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → than defending a single bet. A design concept is the unit that makes that parallelism possible.

How it works in practice

A team faces a design_question💭Design QuestionExperience DesignAn open design problem to exploreView reference →: how should a first-time user understand what the product does in under a minute? Instead of jumping to one onboarding screen, a designer shepherds three concepts. One is a guided tour overlay, status exploring, rationale "lowest build cost". One is a sample-data sandbox, rationale "shows value by doing, higher build cost". One is a thirty-second video, rationale "fast to ship, weak at teaching interaction". Each gets a rough sketch via design_concept_sketched_in_wireframeDesign Conceptsketched inWireframehierarchy. A quick test on five users sends the video to rejected (people skipped it) and the sandbox to selected, with a decision node recording why. The two rejected concepts stay in the graph, so when onboarding comes up again next quarter the team starts ahead, not from zero.

Design concept vs. its neighbours

• Wireframe▭WireframeExperience DesignA low-fidelity structural layoutView reference → is a concrete layout of a screen. A design concept is the broader idea a wireframe might sketch; one concept can spawn several wireframes, and design_concept_sketched_in_wireframeDesign Conceptsketched inWireframehierarchy records that. The concept holds the why; the wireframe shows one what.

Frank Chimero's The Shape of Design offers a complementary angle: design proceeds by asking "why" before it asks "how", and skipping that sequence produces work that is technically competent but purposeless. A design concept is where that "why" lives. Once it is collapsed into a wireframe or a prototype, the direction is assumed rather than questioned, which is why the concept needs🫀NeedUserA user need, pain, desire, or constraintView reference → to remain a distinct artefact rather than an informal sketch that disappears into a file.

• Prototype is a working model built to test a concept. The concept is the proposition; the prototype is the experiment🧫ExperimentValidationA test designed to validate a hypothesisView reference → that validates or kills it, via design_concept_realised_as_prototypeDesign Conceptrealised asPrototypecausal.
• Design question💭Design QuestionExperience DesignAn open design problem to exploreView reference → is the open problem the concept answers. A question can have several competing concepts; design_question_answered_by_design_conceptDesign Questionanswered byDesign Conceptcausal keeps the exploration anchored to the problem it serves.
• Opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → is a discovery-side construct, a space worth pursuing. A concept is a design-side response to it; opportunity_explores_via_design_conceptOpportunityexplores viaDesign Concepthierarchy is the import edge where discovery hands a problem to design.

In the graph

In the Unified Product Graph, design_concept🌱Design ConceptExperience DesignA possible design direction or approach is a leaf in the Experience Design domain of the Experience, Design & Brand region, sitting last in the creation sequence as the speculative end of design. Its edges model the full arc of exploration: inbound it is explored from an opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference →, answers a design_question💭Design QuestionExperience DesignAn open design problem to exploreView reference →, is inspired by an insight🔦InsightUser ResearchA synthesised finding from researchView reference →, and is committed to by a decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →; outbound it is realised as a prototype or a user flow🔀User FlowExperience DesignA navigation path through the productView reference → and sketched in a wireframe. The concept_status and rationale properties turn the canonical anti-pattern into a query: a design question with no concept answering it, or a concept stuck exploring with no decision, is an exploration the graph can flag before it quietly stalls.