[ 02 — APP DESIGN ]
Web and mobile products designed to be fast, clear and genuinely pleasant to use.
[ 01 — THE PROBLEM ]
What this usually looks like
Before
- People need training to use something they should have understood immediately.
- It looks right on the designer's laptop and falls apart on a mid-range Android phone.
- Support spends its day answering the same question, which is really a design problem.
- The app is beautiful and nobody finishes signing up.
After
- Flows designed around the one thing each screen is for, then tested with people who have never seen it.
- Built and measured on a real mid-range phone over a real connection, not on fibre in an office.
- The questions support keeps answering become labels, states and defaults in the interface.
- Every step of a signup or checkout measured, so you can see where people leave rather than guess.
[ 02 — WHAT YOU GET ]
Deliverables, not deliverable-sounding words
User flows
The journeys that matter, drawn end to end, including the error and empty states everyone forgets.
Clickable prototype
A real prototype you can hand to someone and watch them use, before a line of production code exists.
A design system
Colour, type, spacing and components as tokens, so the twentieth screen costs a fraction of the first.
The built interface
Responsive, accessible to WCAG 2.2 AA, fast on a mid-range phone, and wired to your API.
Handover assets
Source files, the component library and the notes a future developer needs to extend it correctly.
[ 03 — HOW IT WORKS ]
The steps, and how long each one takes
- 01
Frame the problem
2–4 daysWho is this for, what are they trying to finish, and what currently stops them.
- 02
Wireframe the flows
3–5 daysStructure before surface. Cheap, fast, deliberately ugly, so decisions are about the flow and not the colour.
- 03
Design and test
1–2 weeksVisual design, then five people who have never seen it try to complete the main task while we watch.
- 04
Build
3–8 weeksComponent by component against the design system, reviewed on real devices as it goes.
- 05
Measure and tune
1 weekAnalytics on the funnel, performance budgets enforced, and a pass over whatever the numbers expose.
[ 04 — EXAMPLES ]
What people use this for
Customer self-service portal
Letting customers do for themselves what they currently phone or email about.
Internal tool nobody dreads
The screen your team lives in all day, designed for speed and keyboard use rather than first impressions.
Marketing site that converts
Fast, clear, and built so the content team can change it without a developer.
Most software fails on the surface, not in the database. We design the screens first, test them with the people who will actually use them, and only then build.
Designed for the phone people actually have
Everything ships accessible, responsive and quick on a mid-range Android over a patchy connection, because that is what most of your customers are on. We hold a performance budget during the build rather than optimising at the end, which is when it is expensive and half-hearted.
Tested before it is built
Five people who have never seen the product try to finish the main task while we watch. It is a small sample and it finds most of the problems, and it costs a morning rather than a release.
[ 05 — STACK ]
What we build it with
Chosen because they are boring, well supported and easy to hire for. Nothing here will be abandoned next year.
- Next.js
- React
- TypeScript
- Tailwind CSS
- React Native
- Three.js
[ 08 — FAQ ]
App Design: questions people ask
Let's talk about app design.
Tell us the problem. We will tell you what we would build, what it costs and how long it takes — before you commit to anything.