Kafka optimisation you can read and control.
67% Faster to the aha moment
Median time to a team’s first savings insight, old vs new
- 67% faster to the first savings insight
- Health and savings readable at a glance
- Plain recommendations, clear controls
How we work with your product team
From an unclear UX problem to clear priorities, coherent design and a handoff your team can build from. Each stage produces something you can inspect, and ends at a decision that is yours.
- Complexity Many roles, unclear cause
- Understanding Scenarios clarified
- Decisions An order you approve
- Structured work Flows, states and handoff
Three starting points, depending on what already exists
You don’t have to start with an audit. We reuse the research you already have, and a task you can already name can start straight away.
-
Discovery
The problem is not identified yet
Something is wrong, but not what. We start with a diagnosis, not a full programme.
-
Evidence
Research already exists
Interviews, analytics or an audit already exist. We use what holds and research only the gaps.
-
Scope
The task is already defined
You know which part must change. We agree the piece and start there.
Each stage has an action, an artifact and a decision
-
“Will you actually understand our product?”
We work through roles, data, scenarios, permissions and constraints with the people who own the product and the people who own the code — not from a marketing description of it.
- You contribute
- Access to key people for a few sessions, plus any existing documentation.
- The artifact
- A scenario map and a live register of open questions.
The decision point
You confirm which scenarios are in scope, and which questions must be answered before design starts.
-
“We don’t know what’s wrong yet. Where do you start?”
We separate the facts from the assumptions in what you already believe, then choose the method that fits the question: observation, interviews, an expert review, or a study of one flow.
- You contribute
- Existing research, support themes, and an honest account of what is guesswork.
- The artifact
- Findings with their source, confidence, and impact on decisions.
The decision point
You agree which findings are accepted as the basis for the work, and which need more evidence first.
-
“How do you decide what gets fixed first?”
We weigh importance, the strength of the evidence, the effort involved and whether engineering can realistically take it now. Anything deferred is recorded with the reason.
- You contribute
- Business constraints, release dates that genuinely cannot move, and the engineering view of feasibility.
- The artifact
- An ordered backlog and a decision log that keeps the reasoning attached.
The decision point
You approve the order, including what is deliberately not being done yet.
-
“Will we get more than attractive mockups?”
We design the scenarios and their states — error, empty, loading, permission — keep the brand and technical constraints that are justified, and test feasibility with your engineers while the design is still changeable.
- You contribute
- Product decisions when a tradeoff needs an owner, and engineering availability for feasibility questions.
- The artifact
- Flows including failure and permission paths, components with their states, and acceptance criteria.
The decision point
You sign off the flow and the component behaviour, not just the visual appearance.
-
“What happens after you hand the design over?”
We agree the handoff set, answer implementation questions, and check what was built against what was specified. If development slips, we agree a smaller batch, limited support, or a pause.
- You contribute
- A named engineering contact and the build order you intend to follow.
- The artifact
- A numbered, linked screen map, developer-ready tasks, and a plan for verifying the implementation.
The decision point
You decide the delivery batches and whether continued support is worth buying.
-
“Will our scope and budget quietly grow?”
Scope, assumptions and revision points are agreed in named pieces. A new requirement is estimated before it is accepted, not absorbed silently and reported at the end.
- You contribute
- A decision-maker who can accept or reject a change request.
- The artifact
- Scope boundaries and a written change request with its consequence.
The decision point
You accept or decline each change, and can stop, pause or resequence at any piece boundary.
One change request, followed all the way through
-
The request arrives
A stakeholder asks for a new capability while design is already underway.
-
We size it first
Effort and impact are estimated against current scope — not waved through.
-
The tradeoff is shown
Taking it on moves something else. That cost is made explicit, not hidden.
-
Backlog & log change
The order is re-cut, and the reasoning is written down beside it.
-
Acceptance follows
New acceptance criteria are agreed, so “done” still means something.
Who does what, and what we will not do
-
Our side
We own the work from initial scope through final delivery, keeping quality.
What we own
- Scope & quality ownership
- Right specialists when needed
- Existing research & constraints preserved
-
Your side
You support the work with product context, access, and timely decisions.
What we need
- Product decisions & context
- Domain & engineering access
- Capacity aligned with delivery
Where AI makes the process more efficient
We use AI to speed up the mechanical parts of the work while keeping decisions in human hands.
How we use it
- Structure requirements and inputs
- Prepare variants and documentation
- Keep decisions and changes organized
Work that moved the metric
A serious analytics product shouldn’t look like a template.
17 Hours saved every week
Daily analysis down from 45 minutes to 20, across eight media buyers
- Rethought flows, not reskinned screens
- Eleven modules speaking one language
- A specific system, not a template
Tell us what needs to work better
You can bring a clear brief — or a product that feels harder to use than it should. We will discuss the situation, the useful scope and a realistic next step.
Frequently asked questions
How long does a UX audit take?
Usually 4–6 weeks for an agreed scope; the scope, the access we get and any added research set the exact timing. Some teams start with a UX audit to understand what’s wrong and what to prioritize. Others come to us with a product challenge ready to solve. From there, we can take on a focused project or work with you continuously as the product evolves. We agree on the scope upfront, so there are no surprise invoices.
Do you work with startups, or only bigger companies?
Both. We've worked with pre-launch startups and with enterprise platforms that have GDPR, HIPAA and WCAG to deal with. Most of what we do is SaaS, fintech and AI products, but really it comes down to whether you have a product behind a login that needs to turn sign-ups into active, paying users.
Can you work alongside our in-house design and dev team?
Yes, and often that's the setup. If your one designer is underwater, we can embed a senior product designer into your team and ship with your engineers, in your tools. We're not there to replace anyone. We fill the gap and leave you with a clean design system so things hold together after we're gone.
We think we just need a UX audit. Is that something you do?
Yes, and it's usually the right place to start. In a UX audit we go through your product properly, find where people are dropping off, and give you a prioritised list of what's costing you users and revenue. Some teams take that and fix things themselves. Others have us stay on for the redesign. Either is fine.
What does a project usually look like, start to finish?
Roughly: audit, research, design, then help you ship. The audit and user research show us where the real problems are (an audit is normally four to six weeks). From there we redesign the flows that matter, build a design system so it scales, and stay close while your team ships. The goal is never just a nice mockup. It's a change you can measure.
Do you work with teams in the US and UK?
Yes. We work remotely with US and UK teams regularly, shifting our hours to overlap with yours and joining your standups. Where your company is based has never been the thing that holds a project up.