01 / 06
User research & usability testing
Moderated and unmoderated sessions, diary studies and benchmark tests, run on a cadence rather than once at the end.
Continuous discovery
Experience Design & Development
Opinions are cheap. Put it in front of someone.
Experience Design & Development takes an idea through research, interaction design and a working front end in short, rigorous loops. Each loop ends with something a real user can try, so the expensive decisions are made on evidence rather than on taste.
An illustrative usability test grid: four tasks attempted by six participants across two rounds, with task success rising after the prototype was changed.
What it covers · 6 parts
Six practices, one loop
Research, design, content and front-end engineering run in the same fortnight rather than in a relay, so what is designed is what ships.
02 / 06
Information architecture & journeys
Navigation, taxonomy and end-to-end journeys across channels, validated with tree testing and first-click studies.
IA · journeys
03 / 06
Interaction & interface design
Screens, states and motion designed in your design system, including the empty, loading, error and offline states most work forgets.
Every state
04 / 06
Content & UX writing
The words in the interface written with the design: labels, guidance, errors and confirmations that read the same in every locale.
Microcopy · clarity
05 / 06
Prototyping
From clickable flows to coded prototypes on live data, at whatever fidelity the open question needs.
Click · coded
06 / 06
Front-end build & design QA
Accessible, performant front-end code built from the same components, with visual and accessibility regression tests in CI and a design QA pass before release.
React · WCAG 2.2 AA
How it runs
Two-week loops, each ending in evidence
Every loop carries one question, one thing to try and a session with users. The backlog is rewritten by what comes back.
-
Understand Wk 01–02
Existing research, analytics and support data reviewed, participants recruited, and a benchmark taken of the journey being changed.
- Research plan
- Baseline benchmark
- Participant panel
Gate · Do we know the benchmark to beat?
-
Design Wk 02–08
Journeys, screens and content designed in the system, prototyped and tested every fortnight. Accessibility reviewed at design, not after.
- Journey maps
- Interface designs
- Test findings
Gate · Did the prototype pass its test round?
-
Build Wk 06–14
Front-end engineering alongside design, with components contributed back to the design system and automated accessibility and visual checks on every merge.
- Front-end code
- Component contributions
- CI checks
Gate · Does the build meet the accessibility bar?
-
Validate Wk 14–16
A release behind a flag, the benchmark repeated, and task success, time on task and error rate read against 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.
What a test round produces: each problem seen, how many participants hit it and whether the fix held when we tested again.
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
Designed, built and tested. Handed over as working code.
Journeys, the prototype that proved them and the production front end, with the test evidence attached.
/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
People finish what they came to do. Three measures that show it.
The same tasks are timed before and after release, so the improvement is measured, not described. Baseline, target and instrument are agreed in week one.
-
Outcome 01
Decisions backed by sessions
Every significant change was watched with users before it shipped, and the recording exists to settle the argument later.
-
Outcome 02
Usable by more people
Keyboard, screen-reader, contrast and target-size checks run in the same pipeline as the tests, so accessibility does not regress quietly.
-
Outcome 03
Design that survives the build
Designers and front-end engineers in one loop, so what is drawn and what ships are the same thing.
-
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%
The stack
From Figma to production. One component set the whole way.
Design, prototyping, front-end and testing tools we use most for experience work, in your repositories. Technologies we work with, not partnerships.
- Figma
- Storybook
- React
- Next.js
- TypeScript
- Tailwind CSS
- Cypress
- Lighthouse
- PostHog
- Mixpanel
- Miro
- Notion
- Playwright
Frameworks we build to
Accessible and fast by default. Checked in the build, not after it.
Frameworks every journey is built and tested to. Frameworks we build to, not certifications 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 passes 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 written into the design spec per template, and checked at p75 in field data 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 design QA against the approved source before anything is called done.
-
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 recorded, specific consent; recordings and notes have a retention date and are deleted on it.
-
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 India-based participants and users, with data-principal requests answerable from the research log.
Services & packages
Research, design and front end, in one loop.
Commission a single round of research, the design of a whole product, or a team that designs and builds the front end together. Every engagement ends with something a real user has tried.
- Categories
- 05
- Services
- 18
- Packages
- 05
How to buy
- 01Pick services. Enquire about one, or add several to a brief.
- 02Choose how to engage. A sprint, a fixed project or an ongoing team.
- 03Send the brief. We reply within one working day.
Start a project
Ways to engage. Same team, same standard.
Three ways in, from a two-minute question to a formal RFQ. Each is read in full by the lead for the work, and anything already in your brief goes 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 lead, not a sales queue
-
02Most useful
Goals, audiences, a budget band and timing. Enough for us to come back with a shape, not only questions.
You get Options and a first scope after one call
-
03
Your pack, your 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 how it is priced. Every engagement starts with a written scope and a quote agreed before work begins.
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 |
|---|---|---|
| SprintOne fixed question, answered in one to three weeks. |
|
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 system, a set of tools |
| MilestoneA larger build, split into gated phases you approve and pay for one at a time. |
|
Programmes too big to fix in one contract, and teams that want control at each step |
| RetainerReserved monthly capacity to run, improve and extend what we built. |
|
Brands and products after launch that need a steady team without hiring one |
| SquadA dedicated team working inside your stack, tools and sprint cadence. |
|
Teams with a clear roadmap that need more senior hands, fast |
Questions
Asked before the first test round.
Anything else goes straight to the people who would do the work.
Ask a questionQ01How many users do you need to test with?
Five to eight participants per round finds most usability problems in a single journey, which is why we run many small rounds rather than one large study. Benchmarks and preference tests need larger quantitative samples, and we say which kind we are running and why.
Q02Do you design in our design system or make a new one?
In yours where one exists, contributing the missing components back to it. Where there is none, we build the parts this work needs and hand them over as the start of one, which is where System Design picks up.
Q03Do you write front-end code or hand over designs?
Either. Handover includes designs, tokens, every state and acceptance criteria. When we build, it is accessible front-end code in your repositories, reviewed by your engineers.
Q04How do you handle accessibility?
WCAG 2.2 AA is the working standard: contrast and target sizes checked at design, automated checks on every merge, and manual keyboard and screen-reader passes on each key journey before release. Where it matters, we also test with disabled participants.
Q05How do you know the new experience is better?
From a benchmark taken before the work starts: task success rate, time on task, error rate and a standard usability measure such as SUS or UMUX-Lite, repeated after release and read alongside the product analytics.
Keep going
A good screen should not stay one of a kind. These make it repeatable.
System Design turns the parts into a library; Strategy decides which journey to improve next.
05 · Pairs well
Built to grow
System Design
Structuring how a product's parts fit together so it can grow without breaking.
Explore Systems
02 · Pairs well
What to build next
Product Strategy & Vision
Spotting the product experiences worth building next to meet real business ambitions.
Explore Strategy
The discipline
From signal to shipped
Product & Experience Design
All five capabilities, the loop they share and how an engagement moves through it.
Back to the overview
Let’s build what happens next.
Tell us what you’re building. We’ll answer straight.
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