Product design

Product Design

Turn evidence and product intent into an understandable system, a purposeful environment, and testable experience. Use design artifacts to answer decisions; do not produce workshops, personas, flows, or polished screens as ceremony.

Workflow

1. Name the design decision, target situation, current evidence, constraints, and artifact needed next. Mark assumptions and supplied personas as such.
2. Write or inspect the provisional brief. Keep audience, problem, design factors, scope, open questions, and success evidence distinct from proposed features.
3. Select the smallest route that can increase confidence:
   • Process and environments for briefs, process choice, sensemaking, placemaking, autonomy, and fidelity.
   • Research and synthesis for research plans, behavioral interviews, observation, desk research, affinity work, personas, and empathy maps.
   • Problem framing for problem-space models, expectations, mental-model gaps, problem statements, empowerment statements, and How Might We questions.
   • Solution modeling for feature canvases, object-oriented UX, object relationships, moments, flows, and journeys.
   • Structure and prototyping for information architecture, thumbnails, wireframes, fidelity choices, interactive prototypes, testing, and delivery.
   • Autonomy and motivation when the experience uses choice, reward, progression, guidance, or engagement mechanics.
   • Habit and retention design together with autonomy and motivation for explicit habit loops, triggers, variable rewards, investment, gamification, sticky-product questions, engagement mechanics, or retention problems.
4. Keep observations, participant language, interpretation, design principles, opportunities, and solution ideas in distinguishable layers. Do not turn a repeated quote directly into a feature requirement.
5. Explore more than one structural or interaction direction. Compare agency, comprehension, consequence, accessibility, implementation constraints, and fit with the product outcome.
6. Prototype only the fidelity needed to answer the next question. Test with realistic tasks, content, states, and interruptions before increasing craft.
7. Update the design brief with what changed, why, unresolved risks, chosen and rejected directions, and the implementation or research handoff.

Operating Principles

• Treat process as a toolkit. Add an activity because it reduces a named uncertainty, not because a diagram says it comes next.
• Design the system before drawing screens. Identify actors, objects, rules, relationships, state, permissions, and consequences.
• Separate the problem space from the solution space long enough to understand behavior and context, then move between them deliberately as prototypes generate new evidence.
• Prefer empowerment framing: understand what people are trying to achieve and what helps them exercise agency, not only what is broken or painful.
• Preserve nonlinear exploration where people create, organize, compare, or solve problems in different valid ways. Use focused linear paths when order, safety, or one known outcome matters.
• Let hierarchy, layout, language, behavior, and visual character communicate the purpose of the environment. Craft is part of function.
• Make consequential state visible and actions recoverable. People learn by acting and observing results; defensive users do not explore.
• Treat behavioral influence as a design responsibility, not an automatic violation. Choice, reward, friction, urgency, and guidance may support user value and legitimate business retention; reject deception, coercion, disproportionate harm, and mechanics that depend on blocking informed choice.
• Scale research and testing rigor with risk, reversibility, novelty, and the cost of being wrong.
• Never invent participants, observations, quotes, usability findings, or evidence. When evidence is absent, deliver a plan, hypothesis, or clearly labeled provisional model.

An evidence register is the compact trace from a consequential claim to its source, date, participant or operating context, evidence type, confidence, and affected decision. Keep observed behavior, measured outcomes, interpretations, stakeholder claims, and assumptions visibly distinct. Link to raw evidence when access and consent allow; never turn the register into invented research.

Default Deliverable

For a broad product-design request, return:

1. Design decision, scope, constraints, and evidence register
2. Target situation, actors, environment, behaviors, and current alternatives
3. System model and important user or team mental-model gaps
4. Problem and empowerment framing with opportunities ordered for design exploration
5. Two or more solution directions with tradeoffs and non-goals
6. Chosen object, interaction, navigation, and state model
7. Prototype scope, fidelity, realistic tasks, and evaluation plan
8. Updated design brief, unresolved risks, and handoffs

Routing Boundaries

• Use product-management to decide product strategy, target market, outcomes, business viability, roadmap, release scope, and prioritization. Return here to shape the experience.
• Use effective-web to specify and implement browser UI, visual systems, accessibility, responsive behavior, performance, and frontend verification.
• Use this skill to frame design questions and synthesize supplied evidence. Recruitment, fieldwork, participant operations, and execution of a full customer research program remain outside its scope.
• Use decision-records when a durable design-system or interaction decision needs repository-level rationale and reopening conditions.