UX/UI Design
Design that works in practice — researched, tested and ready for engineering hand-off.
Good UI is the part users see; good UX is the part they feel. A product can look polished and still be frustrating if the flows are designed around how the database is structured rather than how a user thinks. We research actual user behaviour first, design the interaction model around it, then apply a visual layer that is coherent, accessible and fast to build.
Our design work ends at a Figma file an engineer can open and implement without a translator. We define spacing tokens, colour systems, component states and interaction behaviours explicitly — not approximately — so the gap between design and production is as small as possible. Because the same studio often builds what we design, we know exactly what to specify and what can be resolved in engineering.
What this covers
User research: interviews, usability testing, jobs-to-be-done analysis and heuristic review
Information architecture, user flow mapping and navigation modelling
Wireframes and low-fidelity prototypes for early-stage validation and stakeholder alignment
High-fidelity UI design in Figma: responsive layouts, component library and design tokens
Clickable prototype for user testing and investor presentations
Accessibility review: WCAG 2.1 AA compliance across colour contrast, focus management and ARIA
Design system documentation: usage guidelines, do/do-not examples and component states
Deliverables
- A Figma file containing all screens, components and design tokens, organised for hand-off
- A clickable prototype covering the primary user journey
- A design system or component library with documented usage and interaction states
- A brief research synthesis document covering the key user insights that drove the design decisions
What we build with
UX/UI Design
UX/UI design is the practice of turning user behaviour evidence into interaction models, and interaction models into visual interfaces that engineers can implement without interpretation. It ends where production CSS begins — not at a static screenshot, but at a Figma file containing every state, every token, every accessibility annotation needed to build the thing correctly.
The discipline spans four concerns: understanding what users are trying to accomplish (research), defining how the product should be structured to support those tasks (information architecture and interaction design), making it visually coherent and accessible (UI design and design systems), and closing the feedback loop after it ships (usability testing and measurement). Skipping any one of these in favour of moving faster typically costs more time in the next iteration than it saves in this one.
From user behaviour to production-ready design
The sequence below applies to a new product surface or a significant redesign. For incremental changes where evidence already exists, we compress or skip stages — we do not run research ceremonies for their own sake.
- Stakeholder alignment: goals, constraints, non-goals and an audit of existing knowledge
- User interviews framed around jobs-to-be-done — outcomes the user is hiring the product to deliver, not feature requests
- Heuristic review of the current product against Nielsen's ten usability principles
- Competitive UX audit: interaction patterns worth adopting or deliberately avoiding
- Synthesis: affinity mapping, opportunity statements and a prioritised friction list
- Navigation model and information architecture defined as a labelled site map
- User flow diagrams for the two or three journeys that deliver core value
- Low-fidelity wireframes for key screens — paper or Figma frames with no colour or imagery
- Flow walkthrough with stakeholders to surface misalignments before visual work begins
- Colour system defined as named tokens (color.brand.primary, color.feedback.error) with WCAG 2.1 AA contrast ratios verified in Figma before any component is produced
- Typography scale, spacing system, border-radius and elevation tokens documented in a Figma Variables set
- Core component library: buttons, inputs, navigation, modals, data display — each with all interactive states (default, hover, focus, disabled, error)
- Responsive layout grid defined for mobile, tablet and desktop breakpoints
- Accessibility annotations on every component: focus order, ARIA roles, label associations and keyboard interaction
- Linked Figma prototype covering the primary user journey — enough fidelity to provoke realistic user behaviour
- Moderated usability tests with five to eight participants from the target user group
- Task-completion rate and time-on-task recorded per session
- Findings synthesis: a ranked list of usability issues with severity rating and proposed design fix
- One round of design iteration on high-severity findings before handoff
- Design token export via Style Dictionary — spacing, colour, typography, shadow and radius as CSS custom properties or TypeScript constants consumed directly by the component library
- Component annotation: every state, variant, motion spec and accessibility note written as Figma annotations, not verbal instructions
- Dev Mode inspection enabled with accurate measurements, token linkage and asset export
- Pull request review for visual regressions during the engineering sprint — designer stays in the loop until the screen ships
Research & synthesis
Establish a shared, evidence-based picture of who the user is, what they are trying to accomplish, and where existing flows create friction. Outputs replace assumption with documented findings the whole team can cite.
Information architecture & wireframes
Translate research findings into a structural model before any visual design is applied. Wireframes are tools for testing hierarchy, flow and labelling — not a low-fidelity version of the final mockup.
Visual design & design system
Apply a coherent visual language to the validated structure. Design system work happens in parallel with screen design, not after it, so tokens and components are reusable from the first produced screen.
Prototype & usability testing
Build the cheapest artefact that can answer the riskiest unresolved assumption, test it with real users, and iterate before a line of production code is written.
Handoff & implementation support
Prepare Figma artefacts for engineering in a form that preserves intent and eliminates the back-and-forth that accumulates when intent must be inferred from a static image.
How we'd choose
There's rarely one right answer — these are the trade-offs we weigh before recommending an approach.
Design system: Build from scratch vs Adopt (Material / shadcn / Radix) vs Hybrid
The default assumption — that every product needs a bespoke design system — is expensive and usually wrong. The right approach depends on your timeline, your brand differentiation requirements, and your team's capacity to maintain what they build.
| Criterion | Build from scratch | Adopt a foundation (Material / shadcn / Radix) | Hybrid (primitives + bespoke token layer) |
|---|---|---|---|
| Time to first usable component | Weeks — every primitive (button, input, modal) must be built and tested from zero | Hours to days — foundation components are immediately usable with minimal configuration | Days to one week — primitives are ready; token and theme layer adds a short setup phase |
| Brand differentiation ceiling | Unlimited — every visual decision is intentional and owned | Limited by the foundation's design language; theming can go only so far | High — token layer gives full control over colour, typography, spacing and radius while keeping accessibility primitives intact |
| Accessibility baseline (WCAG 2.1 AA) | Must be engineered in full — keyboard interaction, ARIA attributes, focus management and screen-reader semantics are your responsibility | Handled by the foundation for core primitives; gaps are rare but possible at the edge | Handled by the primitive layer (Radix UI, Headless UI); the token layer does not introduce regression risk |
| Long-term maintenance burden | Highest — every browser quirk, interaction edge case and accessibility update is yours to own | Lowest — the foundation absorbs upstream fixes; your customisation layer is thin | Moderate — primitives absorb the hard maintenance; visual token changes are low-risk |
| Team capacity required | Significant — needs at least one engineer who has built a component library before | Minimal — standard adoption requires primarily configuration, not component authoring | Moderate — token architecture and theming require one experienced design-system contributor |
| When to choose this path | Established brand with complex interaction patterns that no foundation handles, and a team large enough to own the maintenance indefinitely | Early-stage products, internal tools, or any product where shipping velocity outweighs visual differentiation | The most common right answer: products that need a distinct visual identity but cannot afford the maintenance cost of building accessible primitives from scratch |
Anti-patterns we actively prevent
Each of these failure modes is common enough to have a name, and avoidable with the right process decisions made before design begins.
Accessibility as a post-build audit
Colour contrast, focus management, ARIA roles and keyboard interaction are treated as a compliance checkbox run after visual design is locked. At that point, fixing a contrast failure may require changing the brand palette; fixing keyboard behaviour may require rearchitecting an interactive component. The cost is disproportionately high relative to addressing it at design time.
Accessibility is a design constraint from the first wireframe. Contrast ratios are checked in Figma against WCAG 2.1 AA before any component reaches code. Focus order is specified in the interaction annotation. ARIA roles are part of the component handoff spec. Automated linting (axe-core, eslint-plugin-jsx-a11y) runs in CI. Manual screen-reader testing is an acceptance criterion for any flow that changes keyboard or focus behaviour.
Designing for the happy path only
Screens are designed for the first-time user, the full dataset, and the successful state. Empty states, error states, loading states and edge-case inputs are left to engineering to improvise. The result is a product that looks designed for two minutes and undesigned for the rest of the user session.
Every component in the design system has an explicit state inventory: default, hover, focus, active, disabled, loading, error, and empty. Every screen has a defined behaviour when the data is absent or the operation fails. Usability testing includes failure scenarios, not just the happy path.
Design tokens defined in the mockup, not in the system
Designers hardcode hex values, pixel measurements and font sizes in individual frames rather than referencing a token. When the primary colour changes, it must be updated in every frame manually. When engineering implements the same hardcoded values in CSS, the design and the codebase have no contractual link — they drift independently.
Tokens are defined in a Figma Variables set (or a linked token plugin) and exported via Style Dictionary before the first component is produced. Colour, spacing, radius and typography values are applied by token reference in every Figma frame. Engineering consumes the same token names as CSS custom properties, so a single token change propagates correctly across both the design file and the production codebase.
Common questions
Can you design for a product you did not build?
Yes. We audit the existing product, run a heuristic review to identify the highest-friction areas, and design improvements that fit within your existing tech stack constraints. We need a brief from your engineering team about what the current architecture can support before we start.
How do you ensure the design actually gets built the way it was designed?
Precise Figma specifications, design tokens that map directly to CSS variables, and — when we are also doing the engineering — developers sitting in the same team as the designer from the start. Interpretation gaps are almost always a communication gap, not a skill gap.
Related capabilities
Have something in mind?
Tell us what you're building or stuck on. The first consultation is free — no obligation, no hard sell.