Dedicated UX/UI Design Team | Figma & Design Systems

Structured user research before finalising designs for new features or product directions -- 5 to 8 user interviews conducted with a prepared discussion guide covering the user's current workflow, pain points, and mental model of the problem space. Jobs-to-be-Done (JTBD) framing identifies what users are actually trying to accomplish rather than what they say they want, which produces more durable design decisions than feature preference questions. Usability testing on interactive Figma prototypes with 3 to 5 users per round: task-based sessions with think-aloud protocol that surface where the design doesn't match the user's model of what should happen next; 5 users is typically sufficient to uncover 85% of usability problems per Nielsen Norman research. Heuristic evaluations of existing product areas against Nielsen's 10 usability heuristics identify systemic UX problems (visibility of system status, match between system and real world, error prevention) without requiring user sessions -- a faster audit method for existing products with known friction points. Hotjar or Clarity session recording analysis for products in production: identifying rage clicks, scroll drop-off points, and dead-click patterns that reveal friction the analytics funnel data cannot explain. Survey instruments (Typeform or Tally) for quantitative validation of qualitative research findings: confirming that the problem identified in 6 interviews is representative of the broader user population. Competitive analysis documents how the 3 to 5 closest competitors handle the same user problem -- identifying conventions users already know and gaps that represent differentiation opportunities. Research output formatted as insights with direct evidence (user quotes, task failure timestamps, heatmap screenshots) rather than opinions, so design decisions are traceable to user behaviour and defensible in stakeholder review.

Information architecture audits for existing products with navigation problems: card sorting sessions (open and closed) to understand how users categorise the product's content, tree testing with Optimal Workshop to validate whether users can find specific items in the proposed IA without seeing design context, and first-click testing on key task paths to confirm the navigation model matches user expectations before wireframes are built. Low-fidelity wireframes in Figma before high-fidelity visual design: grayscale layouts that establish structure, content hierarchy, and interaction model without the visual noise that steers stakeholder feedback toward colours and typography rather than flows and functionality. Annotated wireframes that document what each element does, the edge cases the engineer needs to handle (empty states, error states, loading skeleton layouts, maximum content length for dynamic fields), and the interaction model for complex components (which elements are clickable, what state change each interaction triggers, what the visual transition communicates to the user). User flow diagrams for multi-step processes (onboarding flows, checkout flows, settings architectures, permission management flows) that map every decision point, every error branch, and every exit before a single screen is designed in detail -- catching structural problems when changing them costs nothing instead of after screens are fully designed. Content priority framework for each screen: primary action, secondary content, and tertiary elements identified in wireframe annotations so visual design applies emphasis in the right places from the start. Wireframe review sessions with engineering leads before entering the high-fidelity phase: surfacing technical constraints (animation complexity, real-time data requirements, form validation complexity) that should inform the design approach rather than be discovered at implementation.

High-fidelity Figma screens covering all interaction 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 frames throughout so spacing is extractable as numeric values -- not manually measured with the Figma measurement tool. Named colour styles and text styles mapped to the design system tokens so CSS variables or Tailwind config values are unambiguous. Component variants in Figma covering every combination the engineer needs to implement: a button with 3 variants (primary/secondary/ghost) x 3 sizes (sm/md/lg) x 2 states (default/disabled) is 18 frames, each named with a consistent convention the engineer can search by. Edge case specifications as a dedicated page within the Figma file: maximum character-length strings, very long names in user-facing fields, RTL (right-to-left) layout for relevant markets, and the specific layout behaviour when content exceeds the designed dimensions. Engineering walkthrough before designs are marked implementation-ready: a synchronous session with the engineering lead to answer questions before they become build blockers or Slack threads at 3pm on a Friday.

Accessibility built into the visual design, not checked after: colour contrast ratios verified against WCAG 2.1 AA requirements (minimum 4.5:1 for normal text, 3:1 for large text) at design time using Figma plugins (Contrast or A11y Color Contrast Checker) rather than left to engineering to discover during implementation. Focus state designs for every interactive element: visible focus ring colour, shape, and thickness specified (not outline: none) so keyboard navigation is usable. Typography scale maintains a minimum 16px body text equivalent for mobile viewports; line-height set to at least 1.5 for body copy. Motion and animation specified with prefers-reduced-motion alternatives documented: every transition and animation has a fallback static state for users who have this accessibility preference enabled. Touch target minimum 44x44px for mobile interactive elements, with tap area extensions using CSS padding when the visual element is smaller.

Design system development starting from the token layer: colour tokens with semantic names (--color-surface-primary, --color-text-dim, --color-border-subtle) rather than raw values (--blue-500) so a brand colour change propagates to every component that references the semantic token, not just the components that happen to use that specific shade. Typography tokens (scale values, line heights, letter spacing, font weight), spacing tokens (4px base grid with named sizes: --space-1: 4px through --space-16: 64px), and border-radius tokens -- defined in Figma Variables and the corresponding CSS custom properties or Tailwind @theme config so changes propagate through both the design file and the codebase simultaneously without manual re-sync. Component library built on the token layer: button (primary, secondary, ghost, destructive, each in small/medium/large), input (default, error, disabled, with prefix/suffix slots), select, checkbox, radio, modal (size variants, scrollable body), tooltip (placement-aware), badge, card, data table, and navigation components -- all variants documented in Figma with interactive controls. Token documentation: what each token is for, what it maps to visually, and when not to use it -- the guide that prevents engineers from reaching for --color-primary when the correct token is --color-interactive-default. White-labelling architecture when the product serves multiple brands: one component library, one brand-specific token file per brand -- swapping the token file changes colours, fonts, and border-radius without touching a component. Contribution guidelines: process for proposing, reviewing, and merging new components into the system so the library expands with governance rather than accumulating inconsistent one-offs.

Design-to-development handoff tooling: Figma Dev Mode annotations marking specific CSS values, spacing, and interaction specs visible to engineers without the designer needing to create separate spec sheets. Zeroheight or Supernova used for living component documentation that stays in sync with the Figma library -- when a component variant is updated in Figma, the documentation page reflects the change automatically rather than requiring a manual documentation update. Design token export via Style Dictionary: a build step that reads Figma Variables (via the Figma Tokens plugin or direct API) and exports CSS custom properties, Tailwind config, and JavaScript constants in a single command. This eliminates the "Figma says 16px but the code uses 14px" class of discrepancy that creates rework between design review and production.