What’s included
(05)Most interfaces are designed for the happy path, then break the moment a list is empty, a form fails or the text runs long.
-
Hierarchy
One thing on each screen is most important, and it looks it. People should know where to look and what to tap without reading everything.
-
Type and contrast
Text sizes that hold up on a small phone and colour contrast checked against accessibility guidelines, not judged by eye on a bright monitor.
-
Tap sizes and spacing
Buttons and links big enough for a thumb, with room between them, so people hit what they meant to.
-
Every state
Empty, loading, error, partial and full, drawn for each screen. Long names, missing photos and slow networks are designed, not discovered.
-
Light and dark, small and large
Layouts drawn for the screen sizes and themes your product supports, so the build team has an answer for each one.
When you need it
- Your product works but looks dated next to competitors
- Users miss the main button on key screens
- Developers keep asking what a screen should look like when something goes wrong
- Text is hard to read on a phone
How it runs
(04)You get a written scope, a fixed price and a start date before anyone begins.
-
Audit
We go through the current screens and list what is hard to read, hard to tap or missing a state.
-
Set the base
Type scale, colour, spacing and core components agreed first, so every screen uses the same parts.
-
Draw
Each screen in full, with your real content, then every state it can be in.
-
Check
Contrast, tap sizes and focus order tested, then reviewed against what the developers build.
What you leave with
- Final UI for every screen
- Empty, loading, error and full states for each
- A type, colour and spacing base
- Accessibility checks on contrast and tap size
- Organised design files your developers can work from
Also in Design
Start your project with us
FAQ
Answered questions.
Finished screens for every part of the product, in every state, plus the type, colour and components they are built from. You get working design files, organised and named, not exported pictures.
Yes. If the journey is sound, we keep it and redraw the screens. If we find a journey problem along the way, we tell you and you decide.
They overlap. UX decides what each screen has to do. UI decides how it looks and reads. If the journey itself needs work, start with UX strategy.
That is part of the brief. Screens are drawn on a set of components that map to code, and we stay through the build to answer questions.
