What we do · 05 · Product & Experience Design
Product strategy, user research, UX and UI design and design systems, tested with users before full build. We run user research, set product strategy, design the UX and UI and build the front end. Results are measured against a baseline agreed at the start.
Illustration: a plan-change screen for “Your platform”, half grey wireframe and half finished interface, with the interview quote behind the idea and a usability result: five of six participants completed the task unaided.
What we offer
Each is scoped and delivered on its own. Used together, each passes its evidence to the next: strategy comes with its research, design with its test results.
Options tested and costed
Options for using new technology, shaped into a plan your teams can build.
What to build next
Research-backed product vision, prototype and roadmap that set what to build next.
Designed, tested, built
UX and UI design tested with users in moderated sessions before full build.
From idea to live feature
AI features, models and agents designed into your product and tested before launch.
Product & Experience Design
Design systems in Figma and code, so teams build new screens without redrawing them.
Why now
Each step from sketch to live code makes a decision harder to reverse. We test the costliest assumptions in sketches and prototypes and hand the evidence to the build team.
The loudest request wins a quarter of engineering time, and nobody wrote down what would prove it wrong.
Findings arrive after the design is signed off, so they can only shape the next release.
A demo on five prompts goes live, and the first sign of trouble is a support ticket.
Name each assumption and test it with the simplest sketch or prototype that can answer it. The evidence stays with the decision.
How it works
Step through five stages of one illustrative idea. Six pieces of evidence become a journey, a wireframe, a tested prototype and a release. Each assumption moves from “untested” to “measured”.
The canvas shows the same six blocks at each stage: interview quotes, then a journey from noticing the need to the plan being changed, then a wireframe and a prototype of a plan-change screen with a “what changes” panel, then the released screen.
Stage 05 of 05 · Staged rollout · product analytics
Released to 10% of users, then to everyone. Plan-change contacts are tracked against the baseline for four weeks.
| Assumption | State | Evidence |
|---|---|---|
| A1People want to change plan without talking to anyone | validated | Self-serve completion 94% (illustrative) |
| A2Downgrades are mainly about price | invalidated | Closed |
| A3Fear of losing data blocks the switch | validated | Panel viewed in 71% of changes |
| A4Self-serve cuts plan-change contacts by 30% | measuring | −41% at week 4 · target −30% |
Illustrative example. Participant counts, ticket volumes and results show what we measure; they are not client results.
How we work with you
Each stage ends with a question answered with evidence before budget moves to the next. You can start at whichever stage your product is in.
Timings are typical for all six stages and shorten when you start at a later stage.
We name the decision the work supports and the assumption most likely to break it, then agree the measure of success.
Gate · Is the question worth answering?
Interviews, analytics, support tickets and a review of what exists, tagged in one evidence base so every finding keeps its source.
Gate · Is there a problem worth solving, and for whom?
Journeys, information architecture and wireframes for each option, drawn to equal depth and sized with the engineers who would build them.
Gate · Can we build it, and at what cost?
Prototypes tested with your users. For AI features, the evaluation set runs before anyone sees a demo.
Gate · Did people complete the task?
Front end and components built from the design system, with accessibility and performance checks on every change and a staged release.
Gate · Does it meet the bar we agreed?
We review results against the week-one baseline with your team. What we learn starts the next round.
Gate · Keep, change or retire?
How we use AI
We use AI to gather, sort and check evidence. It never approves its own work: a named person reviews every theme, prompt and release.
An agent groups transcripts into themes linked to their quotes; a researcher approves, merges or rejects each one.
AI features are prototyped on the live model and realistic data, so tests show the answers users would get, wrong ones included.
Every AI feature gets a versioned evaluation set: expected behaviour, refusals and failure cases, run on each prompt or model change.
Automated contrast, target-size and keyboard checks run on every component change; a person reviews what automation cannot judge.
Illustration of an AI research-synthesis run: 24 transcripts are redacted for personal data, 312 quotes are tagged and 5 themes are proposed; a researcher approves three, rejects one and merges one, and the run is logged with the model, prompt version and reviewer.
What changes
Decisions flow from tokens to components, patterns and surfaces, with an automated check at each step. New screens use parts that have already passed those checks.
01 · Tokens
02 · Components
03 · Patterns
04 · Surfaces
The capability pages use the same diagram for research operations, AI evaluation and operating models.
Tools we use
We work in your teams’ tools and hand everything over in them. These are the technologies we use most for research, design, build and measurement.
Evidence, journeys and decisions in one place.
One library in design and in code.
Usability, accessibility, performance and behaviour.
Models chosen per task by tests on your own examples.
How we check quality
Our design and front-end work is built to these frameworks. They are not certifications we hold; each is a set of checks we run and record.
Level AA by default: 4.5 : 1 text contrast, focus never hidden behind sticky UI (2.4.11), targets at least 24 × 24 px (2.5.8) and a single-pointer alternative to every drag (2.5.7).
Checked inAutomated component tests · manual screen-reader pass
Speed budgets set during design and measured at the 75th percentile of visits: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1.
Checked inLighthouse CI · field data
Consent, purpose and retention for every research recording and every analytics event we propose.
Checked inConsent log · retention schedule
India’s Digital Personal Data Protection Act, 2023: notice, consent and individuals’ rights designed into each flow.
Checked inConsent and notice patterns
Quality-management principles applied to delivery: documented stages, gate reviews and logged corrective actions.
Checked inGate reviews · decision records
People are told when they are interacting with AI, and the risk tier is decided while the feature is still a sketch.
Checked inDisclosure patterns · risk note
The four functions (govern, map, measure, manage) applied to discovery, evaluation and post-launch monitoring.
Checked inEvaluation set · monitoring plan
The design records an AI management system asks for: intended use, oversight and change history.
Checked inDesign documentation
Prompt injection (LLM01) and excessive agency (LLM06) handled in the interface: untrusted content labelled, consequential actions confirmed by a person.
Checked inRed-team cases in the evaluation set
What you get
Each engagement ends with a handover of evidence, decisions and files. 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/01-consulting/
/handover/02-strategy/
/handover/03-experience/
/handover/04-ai-product/
/handover/05-systems/
/handover/README
Outcomes
Before design starts, we agree a baseline and a target for each measure. Both readings use the same method, so the comparison is fair.
Services & packages
Choose a service and your enquiry reaches the right team with it attached. Each can be bought as a sprint, a fixed-scope project or ongoing capacity.
How to buy
How we work with you
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 call01
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
In your brief
In your brief
In your brief
In your brief
In your brief
| 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 |
| EnterpriseA multi-workstream programme with a dedicated team, governance and agreed service levels. |
|
Large organisations running change across markets, portfolios or business units |
| SquadA dedicated team that works inside your stack and sprint schedule. |
|
Teams with a clear roadmap that need more senior people quickly |
Questions
Anything else goes to the team that would do the work.
Enquire
No. You can start wherever your product is: a strategy question, a design to test, a front end to build or a design system to consolidate. We test only the open assumptions that matter to your next decision.
Yes. We work in your Figma, code repositories and ticketing tools alongside your people. At handover your team gets the working files and decision record, so it can carry on without us.
Consulting ends in a decision; discovery ends in a scoped build plan. Consulting starts from a choice you face, discovery from a problem to explore. One often leads to the other, so we scope them separately to keep the advice independent of the build.
Design Consulting & SolutioningA roadmap says what and when; a strategy explains why. It shows why these bets beat the alternatives, what must be true for each to work and what you will stop doing. We write both, strategy first.
Product Strategy & VisionFive 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.
Experience Design & DevelopmentThis capability designs the product; Technology & Intelligence engineers the AI underneath. Engineering covers the models, document search, agents and infrastructure. Design decides where AI belongs in the journey, what people see and how the feature is tested with users. Most AI products need both, and the two teams work as one.
AI Product Strategy & DevelopmentBrand Systems sets the rules; System Design makes them buildable in products. Brand Systems covers expression, assets and tone on every channel. System Design covers your product’s tokens, components, states and versioning, in Figma and in code.
System DesignYou 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
