A mockup that has never met a real user is only a guess.
It looks finished in the design tool. The screens are neat, the flow makes sense on a big monitor with clean test data and no rush. Then someone opens it on a phone, halfway through a job, with the messy data they actually have, and the parts that looked obvious turn out not to be.
Design that gets thrown over a wall to a separate build team loses something on the way across. Decisions get reinterpreted, edge cases get filled in by whoever is coding that screen, and what ships drifts from what was designed. The way to avoid that is to keep design and build close, and to test a design against real use before it is finished rather than after.
In SaaS platform development
The interface is the product. Onboarding, the empty state, the screen someone uses forty times a day: those decide whether a trial converts and whether a customer renews. Design here is a retention problem as much as a visual one.
In business operations software
People do not choose this software, they are handed it, and if it fights them they will route around it or resent it. Watts Group's surveyors use their app offline, in the field, on HS2 pre-condition surveys. That is the setting where a confusing screen costs real time.
01User research
Interviews, surveys and usability testing with the people who will actually use the software, so the design starts from what they are trying to do and where they currently get stuck.
02Information architecture and story mapping
We map the structure and the flows, often with story mapping and event storming, so the product is organised around the work someone is doing rather than the shape of the database behind it.
03Wireframes and interactive prototypes
Page layouts and user flows you can click through and test before a line of production code is written, which is exactly when changing your mind is cheap.
04Accessibility, to WCAG
Contrast, keyboard operation, screen-reader support and sensible target sizes, designed in from the start rather than retrofitted after an audit flags them. Accessible software tends to be clearer software for everyone.
05Front-end build, by the same team
We build what we design. The front end is developed by the people who prototyped it, so the interface that ships is the one that was tested, and it stays maintainable because it was built to the same standard as the rest of the system.
Software that people like using.
We build the front end on the same AWS foundation we use for everything else, so the design and the system underneath it come from one team rather than getting handed between two. We are an AWS Select Tier Services Partner and run a Well-Architected review on every engagement, which is part of why the thing you designed stays fast and affordable to run once real users arrive.
MHM Culture Segments TagTool
A survey and audience-segmentation platform used by arts organisations worldwide, its method made usable by venue staff, not only analysts.
Offline-first survey app
Watts Group, on HS2
Surveyors record pre-condition surveys on iPads in the field with no signal, on an app they call faster and easier than the tool it replaced.
Duwio
A SaaS platform for managing images where tagging and folders feel effortless, previews respond instantly, and teams work without tripping over each other.
The app has been very well received and has been a great success. It is significantly faster and easier to use than its predecessor - allowing our surveyors to produce more detailed reports.
We learn how the work is done before we design the screens for it.
- 01
Research
We spend time with the people who will use the software, through interviews, surveys and watching them work, to understand what they are trying to get done and where the current tools get in their way. The screens come out of that, not the other way round.
- 02
Prototype
Wireframes and interactive prototypes map the flows early, using story mapping to keep them anchored to real tasks. You get something to react to, and to argue with, while changing it still costs an afternoon rather than a sprint. Accessibility is considered here, as part of the design.
- 03
Build what we designed
Because we do the front-end build ourselves, the design is not handed to strangers to interpret. The people who prototyped it are the people who ship it, so its intent survives into the product, and once it is live we watch how it is really used and adjust.
The things buyers ask us first.
We already work with a design or brand agency. Where do you fit?
Alongside them, usually. We are software engineers who design for usability, not brand or graphic designers, and we do not pretend to be. Plenty of our best work has been taking an agency's visual design and turning it into a product that behaves the way it should, or handling the flows and interaction while they own the look.
Isn't UX just how the product looks?
Looks are part of it, but the harder part is whether someone can do what they came to do without getting stuck. The interface is the surface; the experience is the whole business of using the thing. We care about both, and we lead with the job the user is trying to finish.
Do you design in a tool and hand it over to developers?
We prototype, but we do not hand it over, because we do the build ourselves. Keeping design and development in the same team is how the intent in a prototype survives into the shipped product instead of getting reinterpreted on the way.
Can you improve the design of an app we already have?
Yes. We can research where your users get stuck, redesign the flows that are costing them, and, because we also do the front-end build, actually ship the changes rather than just recommend them.