Product design

Design an understandable, coherent experience for the intended audience and task. Respect the user's visual direction and established product behaviour.

Understand the design context

Inspect the relevant brief, screen/flow references, design tokens, components and target platforms. Discover the project's actual files and tools; do not assume Figma access, a particular framework or a mobile-first product. Inspect reference images before describing or recreating their details.

Identify the user's goal, primary action, information needed to decide, entry/exit points and constraints. Existing tokens and components take precedence over generic styling preferences. For a new product, propose a small coherent visual foundation before proliferating screens.

When the project has a shared design specification, maintain foundations and cross-feature patterns there and link feature-specific flows to it. Identify the approved reference revision, supported environments, acceptance targets and reviewer; do not treat a template or an unreviewed mockup as an approved design.

Design the experience

1. Map the journey and meaningful alternatives, including cancel/back, interruption, validation and recovery. Keep technical implementation details out of product copy unless users need them to decide.
2. Establish hierarchy, navigation and a deliberate visual direction: typography, spacing, color, imagery and motion tied to the audience and product. Premium quality comes from clear, consistent execution; choose decoration only when it serves the brief.
3. Reuse or extend existing components with purposeful variants. Give new global components a real reuse/ownership reason. Keep one authoritative token system.
4. Design the relevant loading, empty, error, disabled, success and permission states. Use realistic variable-length content, not only ideal mock data.
5. Account for target widths, safe areas, keyboard, scrolling, text scaling, locales, assistive technology and reduced motion. Do not shrink critical text or targets merely to match a mockup.
6. Explain trust signals, prices, consent and irreversible actions accurately. Label unverified claims and sponsored content according to product requirements; avoid deceptive urgency or hidden choices.

Produce and inspect the result

Use the deliverable requested: flow description, wireframe, design-file changes, prototype or implementation. Use available tool-specific guidance for the selected medium. Inspect the actual rendered result when possible, checking affected states and representative widths. A source-code read is not visual inspection.

Record new business behaviour as a requirement proposal rather than silently introducing it through a screen. Continue requested implementation when authorized; a design-only request does not authorize app changes or publishing.

Deliver

Link the design/artifact, explain the main choices, identify reused or added components, and report the visual/interaction checks actually performed. Flag open behaviours and untested platforms. Self-review is part of creation; a dedicated design-quality pass can independently compare the result with requirements.