UX Design

UX design decides how a product is structured and how it behaves: what the user is trying to achieve, in what order, and what happens when something goes wrong. It covers user research, journey mapping, information architecture, wireframing, and usability testing. It is not visual design — that is UI — and the two fail in different ways. A poor interface on a sound structure is fixable; a polished interface on the wrong structure needs a rebuild.

Cost depends on how much research the product needs and how many flows are in scope. A focused piece — a heuristic review, a handful of user interviews, and wireframes for one core journey — is a small fixed-price engagement. A full research-through-tested-prototype scope for a complete product is larger, and is quoted fixed-price before it starts. If you are not sure which you need, a scoping conversation costs nothing.

A focused engagement on one core journey typically runs two to four weeks. A full product scope — research, journey mapping, wireframes, prototype, and usability testing — usually runs six to ten weeks, depending on how quickly we can get access to users. Testing rounds are the part most often compressed, and the part that most often pays for itself.

Ask to see the research, not just the screens. A partner who can show you what they learned, what it changed, and what they got wrong in testing has actually done the work. Ask whether they test with real users or only with stakeholders. And ask what you own at the end: the files, the research, and the right to hand it to another team should all be yours.

Five users per round of testing is usually enough to find most of the problems in a flow. The value comes from testing more than once, not from testing with more people: five people find the big issues, we fix them, and the next five tell us whether the fix worked. If your users fall into distinct groups, such as office staff and field crews, plan on four or five from each group, because they hit different problems. For research interviews at the start, six to eight people across those groups gives enough to see patterns rather than one person's preferences.

Research is usually a small share of the build budget, and it is cheapest when it happens before any code is written. A focused round of interviews and testing on one core journey costs a few weeks of design time. Changing the structure of a product after it is built means reworking screens, data and logic that developers have already finished, and often retraining the people using it. That is the comparison that matters: a few weeks of research against rework on the most expensive part of the project. We quote research as a fixed price, separately from the build, so you can see both numbers.

When your users are hard to reach, we go to them and keep the sessions short. Field workers, farmers, clinicians and shift staff rarely have an hour to spare at a desk, so we test on site, over a phone call during a break, or with a prototype they can try in ten minutes on their own device. We ask you to help with introductions, because a request from someone they know gets a much better response than one from us. Where we still cannot reach enough people, we lean on support tickets, usage data and the staff who deal with those users every day, and we say clearly which findings rest on thinner evidence.

At minimum, five to eight representative users for a research phase gives us enough signal to work from. More is better, but a small number of well-selected participants reveals the majority of usability issues. If you have limited access to users, we can work with what is available and supplement with desk research and competitive analysis.

Yes, and that is often where UX work has the most immediate impact. We start with a heuristic review and, where possible, an analysis of existing usage data or support tickets. That tells us quickly where the product is failing users before we go near research.

Deliverables depend on the scope, but typically: a research findings document, journey maps, annotated wireframes or a clickable prototype, and a recommendations summary. Everything is produced in Figma and documented so your team or another designer can continue from where we leave off.

Both, depending on the project. For greenfield products we typically run UX ahead of development so designs are validated before build begins. For iterative work on existing products we run alongside development, designing and testing features as they move through the backlog.

UX defines how the product works: structure, flow, and interaction. UI defines how it looks: visual design, typography, colour, and component behaviour. They are connected — a polished interface built on a flawed structure still fails users. We do both, either together or in sequence depending on what your project needs.

Yes. The research findings, journey maps, wireframes, and prototypes are yours, handed over in Figma files your team or another designer can continue from. No licence, no ongoing dependency on us to open your own work.