Skip to content
Senior web & app development · 20 capabilities
oakstone.digital
Apps & software / capability

UI/UX design
judged on the job done.

Product-focused design: flows, states and interfaces judged on whether the job gets done.

This is for you if
  • Your product works but onboarding loses people
  • Every new feature looks like a different product
  • Support answers the same "where do I…" question weekly
A sharper way forward

The work should
change the numbers.

Tools we reach for
FigmaStorybookTailwind CSSRadix UIMazeAxe

Design that only produces beautiful screens is a liability, because the screens are the smallest part. Real products are mostly states: loading, empty, partial, error, permission-denied, offline, too-much-data. Whoever designs those decides how the product actually feels.

We work in flows before screens, prototypes before pixels, and components before pages. Every project produces a design system rather than a folder of artwork, so the tenth screen is quick and consistent instead of a fresh negotiation.

Because the same team builds the thing, nothing is designed that cannot be built well — and nothing is quietly simplified during engineering without a conversation.

What's included

What the engagement
actually contains.

01

Research proportionate to risk

Enough interviews, analytics and support-ticket reading to stop guessing, without a six-week detour.

02

Job and flow mapping

The tasks people come to do, mapped end to end including the paths nobody demos.

03

Interactive prototypes

Clickable flows tested with real users before engineering commits to an approach.

04

Design system

Tokens, components and documented states, delivered in Figma and in code.

05

Accessibility by default

Contrast, focus order, target sizes and keyboard paths designed in, not audited in later.

06

Handover that holds

Specs, states and edge cases documented so engineering does not have to interpret intent.

What you get
  • Research findings and prioritised opportunities
  • Flow maps and interactive prototype
  • High-fidelity designs with all states specified
  • Design system in Figma and in code
  • Accessibility annotations
  • Usability test recordings and findings
Signals it is time
  • Your product works but onboarding loses people
  • Every new feature looks like a different product
  • Support answers the same "where do I…" question weekly
  • Design and engineering disagree about what was agreed
Common mistakes we fix

What usually went wrong
before we were called.

  • 01Delivering flat screens with no specified states for engineering to build
  • 02Research that runs for six weeks and changes nothing
  • 03Accessibility left to an audit after the design system is locked
  • 04A new visual language per feature because there is no component library
How we measure it
  • Task completion and time on task
  • Onboarding drop-off by step
  • Support tickets about finding things
  • Design-to-build rework rate
Typical timeline

4–8 weeks for a product area, including prototype testing

Practicalities

What week one
actually looks like.

First week

Support tickets, session recordings and analytics read together, then the jobs people come to do mapped end to end — including the paths nobody demos.

What we need from you
  • Access to analytics and support tickets
  • Five or six users for interviews
  • Existing design files and brand assets
  • A decision-maker for direction
Not included
  • Brand identity creation
  • Illustration or motion design at scale
  • Copywriting beyond interface text
  • Front-end build, unless scoped separately

Scope boundaries stated up front rather than discovered in a change request.

How the work runs

Four stages, visible throughout.

01

Model

The domain, data and permissions written down before any interface exists, because the schema outlives every screen above it.

02

Prototype

Flows and states tested as a clickable prototype, so the expensive disagreements happen in Figma rather than in code.

03

Ship in slices

One workflow at a time, in production, with tests and observability included in the definition of done.

04

Operate

Release tooling, monitoring and a documented handover so your team can run and extend what we built.

Questions buyers actually ask

UI/UX design, answered.

Yes — plenty of clients take our designs to an internal or offshore team. We deliver a documented system with states and specifications rather than flat images, precisely so it can be built well by someone else.

Proportionate to what a wrong answer would cost. A pricing page rework needs a fortnight of evidence; a new billing model deserves more. We propose the smallest research that removes the biggest uncertainty and say what we are deliberately not investigating.

We extend existing brands into product design systems. Full identity creation — naming, logo, brand strategy — is outside what we do, and we would rather point you to a specialist than sell you our second-best skill.

A better brief starts here

Make ui/ux design useful.

Bring us the hard thing. We will bring a point of view, a senior team and a clear next step.

Start a conversation