A new product experience
Shape the first usable version of a product: core journeys, screens and states, tested with representative users before engineering commits to build.
Learn: can target users complete the core task without help?
Services / Product Engineering
UI/UX design.Evidence about users, turned into interfaces that work.
We design web and mobile experiences grounded in research about the people who use them: structure first, tested prototypes, accessibility built in and handoff your engineers can build from without guessing.
Research-led. Platform-native. No design-award promises.
The business case
Design is judged by what users can do, not how it looks.
A good interface removes effort from a specific task. That comes from understanding the work — including the workarounds your users invented — and testing the design while it is still cheap to change.
When this service fits
You are building a new product, redesigning a complex application, or your team ships inconsistent screens because no shared system exists. We also run usability research on live products.
What we tell you early
What evidence we can reach and what we cannot, the limits of small research samples, and that formal accessibility conformance requires a separately agreed audit. We design to prepare for it, not to claim it.
Work we take on
Different problems. Same evidence standard.
The right engagement depends on your users, product and risk. These are example situations, not pre-packaged promises or claims about past results.
A complex application redesign
Rework a dense operational or business application so users find, understand and complete their work faster — without breaking the workflows power users rely on.
Learn: do task times and error rates measurably improve for existing users?
A design system
Turn scattered screens into a reusable component library with tokens, patterns and usage guidance, so new features ship consistent by default.
Learn: do teams build new screens faster with fewer one-off decisions?
usability research for a live product
Run structured usability studies on a product in the field: where users struggle, why they abandon and what changes would help.
Learn: do the findings change what the team builds next?
An AI feature experience
Design how people interact with AI: input, expectations, confidence, correction and review. Make probabilistic behaviour understandable rather than magical.
Learn: do users trust, verify and recover from AI output appropriately?
Service & process mapping
Map a multi-channel service end to end — web, mobile, support, offline — and design the experience across the boundaries where users currently get lost.
Learn: do handoffs between channels stop losing users?
How the work flows
Research in. Tested design out. Findings loop back.
Evidence about users shapes the structure, the structure becomes a designed interface built from shared components, and usability findings return to refine the next iteration.
What we always deliver
Designed states — not just happy paths — plus component libraries with tokens, specified behaviour and documented reasoning engineers can build from directly.
What we keep out
Decoration without a job, redesigns that break the workflows power users depend on, and claims of statistical certainty from small samples. Deferred work stays visible with a reason.
Research & discovery
Understand the work before designing the screen.
Design decisions are only as good as the understanding behind them. We ground the work in evidence about users, tasks and constraints — and say plainly when evidence is missing.
Users, tasks and context
Interviews, support evidence, analytics and domain constraints, combined into a picture of who does what, where and why. Small samples are treated as signals, not proof.
Existing-state review
Walk the current product or process, including workarounds users invented themselves. The workarounds usually explain what the design must fix.
Assumption mapping
Separate what is known, assumed and unknown. Risky assumptions get tested early, before they are expensive to reverse.
Success measures
Agree what evidence would show the design worked: task completion, time, error rates, support volume or adoption. Measures are defined before the redesign, not after.
Information architecture & flows
Structure first. Screens second.
Most interface problems are structure problems. We define how the product is organised, how people move through it and what happens when things go wrong before pixel work begins.
Content and object model
What exists in the product, how it relates and who may act on it. The structure maps to the data model engineering will build, not to a mood board.
Journey and state maps
Every core journey mapped end to end, including empty, loading, permission, error and recovery states. The unhappy paths are designed, not improvised.
Navigation and findability
Navigation, search and labelling tested against how users actually think about the work, not internal terminology.
Prioritised scope
A visible list of what is in scope, deferred and excluded, so estimates and reviews rest on agreed boundaries.
Interface design & design systems
Consistent, accessible and honest interfaces.
We design interfaces that follow platform conventions, respect accessibility and scale beyond the first release — with components your engineers can actually reuse.
Platform-native conventions
Web, iOS and Android each get patterns their users expect: navigation, controls, gestures and system behaviours are respected, not reinvented.
Component libraries with tokens
Colour, type, spacing and state tokens defined once and shared with code, so design and implementation stay aligned as the product grows.
Every state designed
Empty, loading, validation, error, permission and recovery states are part of the deliverable. A screen is not done when the happy path looks good.
Content design
Interface language, terminology, errors and empty states written deliberately. Clear words prevent more support tickets than any visual polish.
Prototyping & usability testing
Test the design while it is still cheap to change.
Prototypes exist to retire risk: navigation, terminology, workflow order and the assumptions behind the design. We test with representative users and report what we find, including what fails.
Clickable prototypes
Interactive prototypes of the critical journeys, built in Figma, for stakeholder review and user testing before implementation begins.
Moderated usability sessions
Structured sessions with representative users on realistic tasks, with findings recorded against agreed measures. Small samples reveal severe problems, not statistical truth.
Findings that change decisions
Each round produces ranked, specific findings: what blocked users, what confused them and what to change. Findings are traceable to the evidence behind them.
Iteration with a stop rule
Design iterates until the agreed measures are met or the remaining issues are documented as accepted limitations. Perfect polish is not the goal; confidence is.
Accessibility & inclusive design
Accessibility is an engineering requirement, not a final check.
We design for people using keyboards, screen readers, magnification and reduced-motion settings — and build the evidence so conformance can be assessed properly.
WCAG-informed design work
Contrast, focus order, touch targets, dynamic type and reduced-motion alternatives designed in from the start, aligned to WCAG 2.2 guidance.
Assistive-technology review
Designs reviewed against keyboard and screen-reader paths for critical journeys, so implementation inherits structure rather than improvising it.
Inclusive content and imagery
Plain language, meaningful labels and alternatives that work for the widest realistic audience, including localisation considerations where relevant.
Honest conformance claims
Formal accessibility conformance requires a separately agreed audit by qualified assessors. We prepare the groundwork and document what remains.
Design-to-engineering handoff
A design is finished when engineers can build it without guessing.
We deliver designs engineers can implement directly: specified states, behaviour, tokens and edge cases — and stay available during implementation to answer what arises.
Specified behaviour
Interactions, transitions, validation and edge cases written down, not left to interpretation. Ambiguity is resolved before build, not discovered in QA.
Token and component alignment
Design tokens and components mapped to the code's design system, so implementation does not drift from the specification.
Implementation support
Design review of built increments against the specification, with fixes agreed while they are still cheap.
Living documentation
Usage guidance, decision records and the reasoning behind patterns, so future teams extend the system instead of breaking it.
Tools & methods
Standard tools, used with discipline.
We use industry-standard design and research tooling, connected to your engineering workflow. These are options, not a requirement to use everything listed.
Research & discovery
User interviewsUsability testingAnalytics reviewJourney mapping
Evidence gathered with the access you can provide; sample sizes are stated honestly with their limits.
Design & prototyping
FigmaFigma variables & tokensInteractive prototypes
Shared source files, component libraries and clickable prototypes for review and testing.
Design systems
Token architectureComponent librariesUsage documentation
Reusable foundations mapped to your code's design system so implementation stays aligned.
Accessibility
WCAG 2.2 guidanceContrast auditingKeyboard & screen-reader review
Inclusive design built in from the start; formal conformance audits are a separate, qualified scope.
Collaboration & handoff
Figma Dev ModeStorybookDesign decision records
Specifications, tokens and reasoning engineers can work from directly, with review during implementation.
Content design
Interface copyTerminology standardsError & empty-state writing
Deliberate language that reduces confusion and support load.
Validation tooling
Usability session toolingTask metricsFindings registers
Structured evidence from each research round, ranked and traceable.
Tooling choices follow your team's existing environment and workflow. We prefer shared, reviewable sources over private design files nobody else can open.
Delivery approach
From an assumption to a design engineers trust.
You work with designers and engineers inside the same process. Reviews, research sessions and decisions stay connected to the agreed success measures.
- 01
Frame the engagement
Define the product, users, constraints and success measures. Agree what evidence exists, what must be gathered and the boundaries of the work.
Output: Engagement brief, success measures and research plan.
- 02
Research and structure
Run discovery with the available evidence and users, then define the information architecture, journeys and state maps for review.
Output: Research findings, journey maps and reviewed structure.
- 03
Design and prototype
Design the interface on the agreed structure, build clickable prototypes of critical journeys and align components with the design system.
Output: Design files, component library and interactive prototypes.
- 04
Test and refine
Run moderated usability sessions on realistic tasks, rank findings and iterate the design until measures are met or limits are documented.
Output: Test findings, revised design and accepted-limitation notes.
- 05
Hand off and support build
Deliver specified designs, tokens and behaviour documentation, then review implementation increments against the specification.
Output: Handoff package and design review of built increments.
What your team brings
A decision-maker, access to users or the closest available evidence, brand guidelines and any existing design system. For regulated products, bring compliance stakeholders into scoping early.
Decisions without surprises
We share research findings as they arrive, including uncomfortable ones, and keep scope changes visible. Acceptance decisions have named owners; taste disagreements are settled against the agreed measures.
Handover & ownership
Your design. Your system. A team that can extend it.
Design files, tokens and documentation live in your workspace from day one. The handover makes the system understandable to the people who will extend it.
Research findings
Evidence about users, tasks and current-state problems, with sample sizes and limitations stated honestly.
Structure and design
Information architecture, journey and state maps, interface designs and a component library built on shared tokens.
Tested prototypes and findings
Clickable prototypes of critical journeys with ranked usability findings and the design decisions they changed.
Handoff and guidance
Specified behaviour, tokens, usage documentation and decision records engineers can build from directly.
Delivery does not include unlimited maintenance of the design system or a conformance certificate. We can agree ongoing design support, or hand over fully to your own team.
Related engineering services
Choose the support your next stage needs.
UI/UX design connects directly to the engineering that implements it. Product development and dedicated capacity can carry the work forward.
Questions before starting
The practical details.
Do we need research if we already know our users?
Usually some, yes. Teams know their users' opinions well but often have blind spots about actual behaviour, especially around workarounds and abandonment. We match research depth to the risk: light discovery for low-risk work, structured studies where a wrong assumption is expensive.
Can you work with our existing brand and design system?
Yes. We prefer it. We work within your brand guidelines and extend your design system where the product needs new patterns, documenting additions so they stay consistent.
What if we don't have access to users for testing?
We work with what is available: support tickets, analytics, sales and operations teams, and any customers willing to participate. When no users are reachable, we say so plainly and design against documented assumptions instead of pretending tests happened.
Is this service only for new products?
No. Redesigning a complex existing application, running usability research on a live product and building a design system are common engagements. Each is scoped against its own goal and measures.
Do you design for both web and mobile?
Yes. Web, iOS and Android each follow their own platform conventions, and we design accordingly. Cross-platform consistency is achieved through shared structure and tokens, not identical screens.
How does this connect to engineering work?
Design deliverables specify behaviour, states and tokens engineers can implement directly, and we review built increments against the specification. Most engagements hand off into our engineering services; design-only engagements are also fine.
Do you guarantee accessibility compliance?
No. We design to WCAG-informed practice and prepare the evidence, but formal conformance requires an audit by qualified assessors — a separate scope we can help arrange. We do not issue compliance certificates.
How is the work priced?
We agree a paid first sprint with one goal — often a research round or a tested prototype of one critical journey. Further work is scoped against findings and the backlog. Research access, participant recruitment and specialist audits are identified separately.
Start with the evidence
Bring the product.
Let's design what users actually need.
Tell us who uses it, what they struggle with and what success looks like. We'll agree a practical first sprint.