Engineering services
UI/UX Design
We design what your site or app looks like and how people move through it, so visitors find what they came for instead of giving up.
Part of your product’s journey
Of the eight stages we run, this service covers Design. We also run the others.
What this makes possible
Two different things are sold under the name design. The first produces attractive screens. They look finished in a presentation, then fall apart when an engineer asks what the screen should show when the list is empty. The second produces a complete instruction set: every screen drawn in every condition it can be in, every path through the product walked, every reusable piece named. The developer then assembles rather than guesses. We do the second kind.
Our approach in more detail
This is not about being precious. Screens nobody defined are where the schedule quietly goes. A screen drawn only for the case where everything works gets built three times. Once as drawn. Again when someone realises it needs to show something while the data is still arriving. Again when someone notices that a user without permission can reach it. Deciding at design time what all of those look like costs a day. Finding them during the build costs about a week each, and what ships is whatever the developer improvised at six in the evening.
So we work on the path before the pixels. What is the person trying to finish? What is the shortest honest route to it? Which of the current steps do not earn their place? Then the screens themselves. Then a kit of reusable pieces — buttons, forms, tables — with a rule for when to use each. Then a check that the product works for people with weak eyesight or who navigate by keyboard, so that is a decision rather than an accident.
What you get
- Step-by-step user journeys and a clear page structure
- Screen layouts, and a note on how each part behaves
- Finished designs for every screen
- A reusable kit of buttons, forms and other common parts
- Layouts that work on a phone, a tablet and a desktop
- Notes that make the design usable for people with disabilities (WCAG 2.2 AA)
How we get there.
- 01
Journeys and structure
We map every journey the product has to support, including the ones nobody puts in a demo: recovering a forgotten password, a failed payment, an administrator correcting somebody else’s mistake. You get a diagram of the paths and a full list of screens. It is also where features get cut, because seeing all the paths at once makes the redundant ones obvious.
- 02
Rough layouts and behaviour notes
Structure before decoration, so the arguments about what matters most on a page happen while the drawings are still cheap to redo. Each layout carries a note on how it behaves: which fields are required, when they are checked, what the user sees while the system is thinking. Reviewed with you before any visual design starts.
- 03
Interface design
Finished screens at the sizes that matter for your traffic, not a token phone view added at the end. Every screen comes drawn in each of its conditions: loading, empty, error, success, disabled, and no permission. Real content where we have it and realistic content where we do not. No placeholder text in a file we hand over.
- 04
A reusable kit
Colour, type, spacing and corner rounding defined once and named, rather than typed in by hand across a hundred screens. Each piece is documented with its variations and a rule for when to use which. This is what stops the product drifting six months later, when somebody adds a page and picks a new shade of grey.
- 05
Accessibility pass and handover
We check that text stands out clearly enough against its background, and that the keyboard moves through a page in a sensible order. We check that form fields have real labels and useful error messages, and that tap targets are big enough for a thumb. The standard we work to is WCAG 2.2 AA, the accessibility benchmark most organisations are measured against. Then a walkthrough with whoever is building it, so questions are answered by a person rather than guessed at from a file.
A little more detail.
The process, the fit, and the questions worth asking before we begin.
Is this the right service for me?
- Not for you if you want the visuals without the journey work. We do not take briefs that begin at “make it look modern”, because the result is screens that cannot be built as drawn.
- Not for you if sign-off runs through a committee with no single decision-maker. The rounds multiply, the cost follows, and the design ends up as an average of opinions.
- Not for you if you need finished screens inside a fortnight for a product of any real size. We would be skipping the awkward conditions, and you would pay for that during the build.
- Not for you if you have not launched and have not spoken to any users. Design makes a proposition clearer. It cannot supply one.
- Not for you if the brand is unsettled and will be revisited after launch. Designing the same product twice is the most expensive thing on this page.
A worked example
Hypothetical scenario
Illustrative: a multi-step signup
Say you are designing signup for a product where a person’s identity has to be verified before the account can be used. The obvious design is four steps, one after another. Mapping the journey surfaces the awkward truth: verification is not instant. Step four involves a wait of minutes or hours, and the user will close the tab. That single fact reshapes everything. The account has to exist in a partly usable state. There has to be a screen explaining what is pending and what can be done in the meantime. There has to be an email that brings the person back, and a path for verification failing and being tried again with a different document. Four screens turns out to be nearer eleven once every condition is counted. A journey of this shape takes three to four weeks to a design a developer can build straight from, and finding those eleven now is the whole point.
An illustration of our approach, not a delivered client project.
How long does a design engagement take?
As a planning assumption: a marketing site of five to eight pages is two to three weeks. A focused application with a handful of core journeys is four to six. Something with several types of user and an admin section runs eight or more. What moves the number is how many distinct user types and journeys need every condition covered, not the number of screens.
Can you work with our in-house designer or existing brand?
Yes. If you have a brand, we design inside it and extend it where it has gaps, because brands rarely say what an error message or a data table should look like. If you have a designer, the usual split is that they own the visual direction and we own the journeys, the conditions and the reusable kit. What does not work is two people owning the same screens with nobody named as the decider.
What do the developers actually receive?
A Figma file holding the named colour, type and spacing values, plus documented reusable pieces with their variations. Every screen in every condition, and layouts for each screen size. Notes on anything whose behaviour is not obvious, and accessibility notes. Plus a live walkthrough. If we are building it too, those named values go straight into the code rather than being typed in again.
How many rounds of revision are included?
Two structured rounds at each of three checkpoints — journeys, rough layouts, visual design — with your feedback gathered into one list per round. A revision that reverses a decision signed off at an earlier stage is quoted separately, because redrawing the journeys after the visual design is close to starting again. We say this up front so nobody is surprised later.
Do you do design without the build?
Regularly. The handover is written for a team we will never meet. If your developers are in another country or another company, we run the walkthrough at a time that works for them and stay available for questions during the build. That part is included rather than billed by the hour.
Bring the pieces together
Tell us what you need to achieve. We’ll help you scope the work and see how it fits your wider product.