A product that engineers understand intuitively and new users find confusing is a product with a design gap, not a user gap.

Structured discovery before any design output begins: project lead interviews to map business requirements, success metrics, technical constraints, and the internal disagreements about what the product should do that would otherwise surface as design revision cycles. User research to understand how target users currently solve the problem -- 5 to 8 user interviews with a prepared discussion guide using Jobs-to-be-Done (JTBD) framing: what job the user is hiring the product to do, what they use now, and what triggers the decision to switch. Assumption mapping using an impact/certainty matrix identifies which design decisions carry the most risk: high-impact, low-certainty assumptions are tested first; low-impact, high-certainty assumptions proceed to design without research. Competitive analysis documents how the 3 to 5 closest competitors handle the same user flow -- identifying conventions users already know (design leverage) and gaps in the market (differentiation opportunities). Affinity mapping groups raw interview findings into themes; research synthesis produces a documented findings report with direct user quotes and a set of design principles that guide decisions throughout the engagement.

The structural decisions that determine whether users can navigate the product without a tutorial -- site map, navigation hierarchy, menu depth and labelling, content grouping, and search and filter patterns. These decisions are cheap to change at a diagram stage and expensive to change at a built product stage, which is why they're documented and reviewed before wireframes begin. Card sorting sessions (open card sort to discover how users naturally categorise content; closed card sort to validate the proposed category structure against user mental models) produce a navigation structure that reflects how users think about the content, not how the development team organised the data model. Tree testing validates the proposed IA: users attempt to find specific items in the IA hierarchy without visual design cues, and the first-click success rate reveals where the structure fails before any screen is designed. For complex products with search: entity relationship documentation (what can be searched, what can be filtered, what facets make sense for which content types) and the interaction model for filter state management (URL parameters for shareable filtered views, query builder vs. faceted navigation).

Low-fidelity wireframes in Figma for all key user flows: grayscale layouts that establish content hierarchy, element placement, and interaction model without the visual detail that distracts the product team into feedback about colours and typography rather than structure and flow. Annotated wireframes document: what each element does, the logic that determines which state the user sees, edge cases the interface must handle (empty state, error state, maximum content, loading), and the questions the wireframe is leaving open for later. Interactive Figma prototypes for usability testing: click-through simulations of the primary user flows that can be tested with users on their own device without requiring a code prototype. Usability testing sessions with 3 to 5 representative users per round using think-aloud protocol: participants narrate their thought process as they attempt tasks, surfacing where the design doesn't match their mental model of what should happen. Task completion rates and first-click accuracy measured per flow. Iteration on wireframes based on testing findings before moving to high-fidelity -- the point of the wireframe phase is to discover and fix structural problems while the cost of change is still a few hours of Figma work rather than a sprint of rework.

Pixel-precise visual design in Figma built on validated wireframes -- which means the structure is already confirmed and visual design time is spent on visual decisions, not structural ones. Design tokens defined as Figma Variables and corresponding CSS custom properties: colour (semantic names like --color-surface-primary rather than --blue-500), typography scale, spacing grid, and border-radius -- so visual changes propagate system-wide rather than requiring screen-by-screen updates. Every component designed with all states required for production implementation: default, hover, focus-visible (keyboard navigation outline), active/pressed, disabled, loading (skeleton and spinner variants), error with accessible error message placement, success, and empty (zero-state with guidance copy). Auto-layout throughout so spacing is numeric and extractable rather than visually estimated. Responsive breakpoints for mobile (375px), tablet (768px), and desktop (1280px+) with explicit layout behaviour at each breakpoint -- not just a scaled-down version of the desktop layout. Dark mode variants using prefers-color-scheme media query where the product requires them. Typography choices informed by readability research: body text at minimum 16px, line height 1.5-1.6, line length 60-75 characters for reading comfort.

Interaction specifications that give development the information needed to implement behaviour correctly -- not just visual states, but the triggers, transitions, and logic that connect them. Animation specifications include: duration (150ms for micro-interactions like button press feedback, 250-300ms for panel reveals and modal entrances, 400ms for page-level transitions), easing curves (ease-out for elements entering the screen -- fast start, slow end; ease-in for elements leaving; ease-in-out for elements moving within the screen), and the specific property being animated (opacity + translateY for toasts; scale + opacity for tooltips; height or max-height for accordions). Figma Smart Animate prototypes demonstrate timing and easing before development begins -- removing interpretation ambiguity. Complex interaction specifications for drag-and-drop (ghost element on drag start, drop target highlight, reorder animation), inline editing (click-to-edit pattern with cancel/save affordances, keyboard shortcuts, focus management), multi-step wizard flows (progress indicator, back/forward navigation, validation gating on step advance), and data tables (column sort, row selection, bulk actions, pagination). Loading skeleton screens specified as components rather than spinners -- shaped to match the content they replace so layout shift is minimised when data loads.

Handoff is the end of the design process, not a file drop followed by weeks of Slack clarifications. Figma file organised for developer inspection: named components with self-documenting layer names, all styles as named Figma Variables (not one-off hex values), auto-layout frames with numeric spacing values rather than visually-placed elements, and a separate "Handoff Notes" page with annotations for every non-obvious interaction, edge case, and responsive behaviour. Design token export maps Figma Variables to CSS custom properties or Tailwind config values: the design token file is generated from Figma, not manually maintained alongside it. Component specification document covers: component API (what props or variants exist, what values are valid), state inventory (all visual states and the conditions that trigger each), and accessibility requirements (ARIA role, keyboard interaction, focus management, screen reader labelling). Walkthrough session with the engineering lead before build begins -- a 60-90 minute screen-share where the designer walks through every key flow and answers implementation questions before they become blocking Slack threads. Design QA review at the end of each sprint: designer reviews implemented screens against the Figma spec and documents discrepancies for the engineering team's next sprint. The review is not a rejection mechanism -- it's the quality gate that catches drift before it accumulates.