01 / 06
User research & usability testing
Moderated and unmoderated sessions, diary studies and benchmark tests, run regularly through the project.
Continuous discovery
Experience Design & Development
UX design and front-end development, tested with your users.
We run user research, design the interface and build the front end for product and CX teams. Each short cycle ends with users trying the work, so costly decisions rest on evidence.
Illustrative usability test grid: six participants try four tasks in two rounds, and task success rises after the prototype changes.
What it covers · 6 parts
Six practices, run by one team.
Researchers, designers, writers and front-end engineers work side by side, so findings reach design and code without a hand-off.
02 / 06
Information architecture & journeys
Navigation, taxonomy and complete journeys across channels, checked with tree tests and first-click studies.
IA · journeys
03 / 06
Interaction & interface design
Screens, states and motion designed in your design system, including empty, loading, error and offline states.
Every state
04 / 06
Content & UX writing
Labels, guidance, errors and confirmations written with the design and consistent in every language.
Microcopy · clarity
05 / 06
Prototyping
Clickable flows or coded prototypes on live data, with as much detail as each question needs.
Click · coded
06 / 06
Front-end build & design QA
Accessible, fast front-end code built from your design system components, with automated visual and accessibility tests and design QA before release.
React · WCAG 2.2 AA
How it works
Two-week cycles, from benchmark to release.
Each cycle tests one question with one prototype, and the results set the work for the next.
-
Discover Wk 01–02
We review research, analytics and support data, recruit participants and benchmark the journey. An agent groups transcripts into themes linked to quotes; a researcher approves them.
- Research plan
- Baseline benchmark
- Participant panel
Gate · Do we know the benchmark to beat?
-
Design Wk 02–08
Journeys, screens and content designed in your design system, tested with users every fortnight and checked for accessibility from the start.
- Journey maps
- Interface designs
- Test findings
Gate · Did the prototype pass its test round?
-
Build Wk 06–14
Engineers build the front end alongside design, adding components to your design system, with automated accessibility and visual checks on every merge.
- Front-end code
- New components
- Automated checks
Gate · Does the build meet the accessibility bar?
-
Improve Wk 14–16
We release behind a feature flag, repeat the benchmark and compare task success, time on task and error rate with the baseline.
- Release
- Benchmark comparison
- Improvement backlog
Gate · Did task success beat the benchmark?
Timings are typical and shorten when the evidence already exists.
Usability findings · what you will see
Every finding has a severity, an owner and a fix.
Each test round lists every problem seen, how many participants hit it and whether the fix held on retest.
Critical 1
Delivery date hidden below the fold on small phones
Task 2 · 4 of 6 missed it
Owner: design · fixing
Serious 2
Promo code field read as required
Task 3 · 3 of 6 paused
Owner: content
Error on card number clears the whole form
Task 4 · 2 of 6
Owner: front end
Minor 1
“Continue” and “Next” used for the same action
All tasks · noted
Owner: content
Fixed and retested 1
Address lookup ignored flat numbers
Round 1: 5 of 6 failed
Round 2: 6 of 6 passed
What you keep
Designs and front-end code, handed over with the test evidence.
What we make for you is yours once it is paid for. Tools we already had stay ours, and you get a free, permanent licence to use them.
/handover/03-experience/
Experience Design & Development
- Research plan, findings & session clipsReport · clips
- Journey maps & information architectureFigma
- Interface designs with every stateFigma
- UX copy & content guidelinesDoc · Figma
- PrototypesFigma · coded
- Front-end code & componentsYour repos · Storybook
- Accessibility report & fixesWCAG 2.2 AA
- Usability benchmarkSheet · Dashboard
/handover/README
In every handover
- Decision record, with evidence linksDoc
- Assumption tracker, final statesSheet
- Research consent & retention logSheet
- Walkthrough session, recordedVideo
What changes
Three outcomes, each with a number you can check.
We run the same tasks before and after release and compare the results. We agree the baseline, target and measuring method in week one.
-
Outcome 01
Decisions tested with users
Every significant change is watched with users before release, and the recording is kept to settle later debates.
-
Outcome 02
Usable by more people
Keyboard, screen-reader, contrast and target-size checks run with the automated tests, so any accessibility drop shows up at once.
-
Outcome 03
Built as designed
Designers and front-end engineers work in the same cycle, so what goes live matches the approved design.
-
01 Task success, key journeysSame tasks, unmoderated, benchmark vs release89%from 61%target 85%
-
02 WCAG 2.2 AA criteria metAutomated checks plus manual keyboard and screen-reader pass100%from 68%target 100%
-
03 Screens matching the approved designDesign QA against the Figma source94%from 55%target 90%
Tools we use
From Figma to production, with one set of components.
The design, prototyping, front-end and testing tools we use most, with code kept in your repositories. We work with these tools; no partnership is implied.
- Figma
- Storybook
- React
- Next.js
- TypeScript
- Tailwind CSS
- Cypress
- Lighthouse
- PostHog
- Mixpanel
- Miro
- Notion
- Playwright
Frameworks we build to
Accessibility, speed, quality and privacy, checked while we build.
We build and test every journey to these frameworks. None is a certification we hold.
-
WCAG 2.2 AAWeb Content Accessibility Guidelines
Perceivable, operable, understandable and robust content, including 2.2 criteria such as focus not obscured, target size and accessible authentication.
How we apply itContrast, focus order and target size checked in the design file, then keyboard and screen-reader tests on every key journey before sign-off.
-
Core Web VitalsLoading, interactivity and visual stability
Good at the 75th percentile of page loads: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1.
How we apply itLCP, INP and CLS budgets set per template at design, then checked at the 75th percentile of visits after release.
-
ISO 9001:2015Quality management systems
Requirements for a quality management system built on process control, risk-based thinking and continual improvement.
How we apply itEvery stage ends at a written gate with an owner, and nothing is signed off before design QA against the approved design.
-
GDPRGeneral Data Protection Regulation (EU) 2016/679
Lawful basis, data-subject rights, data protection by design and by default, breach notification and DPIAs for high-risk processing.
How we apply itResearch participants give specific, recorded consent, and recordings and notes are deleted on a set retention date.
-
DPDP Act 2023Digital Personal Data Protection Act, 2023
Notice and consent, duties of data fiduciaries, rights of data principals, breach intimation and added duties for significant data fiduciaries, with the DPDP Rules.
How we apply itConsent notices for participants and users in India, with their data requests answered from the research log.
Services & packages
Research, design and front end, bought alone or together.
Commission a single research round, the design of a whole product or a team that designs and builds your front end.
- Categories
- 05
- Services
- 18
- Packages
- 05
How to buy
- 01Pick services. Enquire about one, or add several to a brief.
- 02Choose a package. A sprint, a fixed project or an ongoing team.
- 03Send the brief. We reply within one working day.
How we work with you
Ways to engage, from a question to an RFQ.
Ask a quick question, send a project brief or issue a formal RFQ. The lead for the work reads each one in full, and any services already in your brief go with it.
Or book a thirty-minute call-
01
For a first conversation, a press request or anything that does not need a scope yet.
You get A reply from a named lead
-
02Recommended
Goals, audiences, a budget band and timing, so our first reply can outline the work.
You get Options and a first scope after one call
-
03
Your documents, deadlines and the procurement and security rules the work must meet.
You get Receipt confirmed and a named bid lead
How it is priced
Each package shows its pricing model. Work starts once a written scope and quote are agreed.
Opens a project brief with this package chosen.
-
In your brief
- Typical length
- 1–3 weeks
- Pricing
- Fixed fee
-
In your brief
- Typical length
- 4–12 weeks
- Pricing
- Fixed price
-
In your brief
- Typical length
- 3–9 months
- Pricing
- Fixed price per milestone
-
In your brief
- Typical length
- Ongoing · 6-month minimum
- Pricing
- Monthly fee
-
In your brief
- Typical length
- Ongoing · 3-month minimum
- Pricing
- Time & materials
Compare what each package includes
| Package | Every engagement includes | Best for |
|---|---|---|
| SprintA short, fixed-scope engagement that answers one defined question. |
|
Discovery, a diagnostic, a prototype or a decision you need to make soon |
| ProjectA defined scope, delivered for a fixed price. |
|
Work you can describe up front: an identity, a platform or a set of tools |
| MilestoneA larger build in phases you approve and pay for one at a time. |
|
Programmes too large for one contract, where you want control at each step |
| RetainerReserved monthly capacity to run, improve and extend what we built. |
|
Live brands and products that need a steady team without hiring one |
| SquadA dedicated team that works inside your stack and sprint schedule. |
|
Teams with a clear roadmap that need more senior people quickly |
Questions
Asked before the first test round.
Anything else goes to the people who would do the work.
Ask a questionQ01How many users do you need to test with?
Five to eight people per round, testing one journey. That finds most usability problems, so we run several small rounds. Benchmarks and preference tests need larger samples, and we say which we are running.
Q02Do you design in our design system or make a new one?
Yours, if you have one; we add the components it is missing. If not, we hand over the components this work needs as the start of a design system, which our System Design capability can complete.
Q03Do you write front-end code or hand over designs?
Either. A design handover includes screens, tokens, every state and acceptance criteria. When we build, you get accessible front-end code in your repositories, reviewed by your engineers.
Q04How do you handle accessibility?
We build to WCAG 2.2 AA and check it at every stage: in design, on every merge and by hand before release. Where it matters, we also test with disabled participants.
Q05How do you know the new experience is better?
After release we repeat the baseline benchmark: task success, time on task, error rate and a usability score such as SUS or UMUX-Lite. We read the results alongside your product analytics.
Related capabilities
Design systems and product strategy build on this work.
System Design turns these components into a shared library; Product Strategy & Vision sets which journey to improve next.
Tell us what you need built.
You will speak to a lead who would run the work, and get a straight answer on fit.
Three ways to start
Every engagement starts with a written scope and a quote agreed before work begins.
Choose one of the three ways above