Design for the job, not the screenshot
An app is judged by whether people finish what they came to do. So we design the route through it first: what someone needs to see, in what order, and what they can skip. The screens come after, and the styling last.
How we design an interface
- Watch the job. Talk to the people who will use it, and look at what they do now, spreadsheets and all.
- Map the flow. The fewest steps from arriving to done, and what happens when something goes wrong.
- Prototype. A clickable version, or straight into a working staging copy when the data matters.
- Test with real people. Small, quick sessions that find the confusing parts before launch.
- Build it and check it. The same team designs and builds, so what ships matches the design.
What good looks like in practice
Plain states. PLZ's match centre has a clear state for every point in a game: upcoming, live, half-time, full-time and postponed. Nobody has to wonder whether a score is old.
Error screens that help. In the Doorstep Glass Recycling driver app, a missed collection needs a real reason, and a miss that was the company's fault goes to a red screen first, so it gets fixed rather than forgotten.
Fast first, fancy second. Visit Dundee's AI assistant shows the grounded answer at once and lets the conversational version arrive afterwards. The page went from 3.7 seconds to 0.31, and still works with JavaScript off.
Accessible by default
We design and test against WCAG 2.2 AA: contrast, focus states, keyboard use, screen reader labels, motion that respects the visitor's settings. In October 2026 an audit across 35 pages of the Visit Dundee platform went from 837 failing elements to none.
Accessibility is not a separate phase. It is cheaper and better when it is part of the first sketch.