01
Full interface design
Every screen at every breakpoint, in a real design tool, organised so a developer can find what they need without asking.
Design
Interfaces that are clear before they are clever.
Good interface design is mostly restraint: a clear hierarchy, honest labels, and enough space to think. We design every screen and every state, including the empty, loading and error ones that get skipped and then cause all the support tickets.
Why it matters
The short version.
Interface design gets judged on how it looks and earns its money on how it reads. The difference is hierarchy: what does the eye land on first, what can be safely ignored, and can someone who is tired and slightly annoyed still find the button? Attractive is a side effect of getting that right, not a substitute for it.
The part that separates a finished design from a pretty one is states. Real software is mostly not the happy path — it is the account with no data yet, the request that timed out, the user with read-only permission, the table with four hundred rows and a column of very long names. Designing those is unglamorous and it is where most of the support burden is decided.
We design in the browser-shaped reality of your actual content. Lorem ipsum hides every problem that real text creates, and real text always arrives eventually.
Real software is mostly not the happy path. The states nobody designs are the ones that generate support tickets.
Is this you?
You probably need this if…
- Your product works but looks like an internal tool nobody loved
- New features each look like they came from a different product
- People need training to do things that should be obvious
- You have developers ready and nothing good for them to build
What's involved
The actual work.
No two engagements are identical, but this is the shape of it.
02
Every state, not just the happy path
Empty, loading, partial, error, permission-denied, offline, and the one with far too much data in it. These are where products actually break down.
03
Clickable prototypes
Assembled so you can click through a real task rather than judge a picture of one.
04
Accessibility built in
Colour contrast, focus order, target sizes and labelling handled as we go, to WCAG 2.1 AA. Retrofitting it later costs several times more.
What goes wrong
Mistakes worth
avoiding.
Named plainly, because most of them are easier to avoid than to undo.
-
Designing only the full, ideal screen
Every screen has an empty version, a loading version and a broken version. If they were not designed, they were decided by whoever built them, under time pressure.
-
Treating accessibility as a final audit
Contrast, focus order and target size are cheap to build in and expensive to retrofit. Bolting it on afterwards usually means partially redesigning what you just finished.
-
Designing on placeholder content
Placeholder text is uniformly short and tidy. Real names, real addresses and real product titles break layouts that looked perfect in the file.
How it runs
Start to finish.
Each phase ends in something you can open, click or read.
-
01
Structure first
Wireframes to settle hierarchy and flow while changes are still cheap.
-
02
Direction
Two visual directions on your real content, not on placeholder text.
-
03
Build out
Every screen and state, refined against your feedback each week.
-
04
Handover
Files, specs and a walkthrough with whoever is building it.
Deliverables
What you walk
away with.
Yours to keep, whatever happens next.
Complete design files, organised and yours to keep
A clickable prototype of the key flows
Specs a developer can build from without guessing
An accessibility pass documented, not assumed
Questions
Worth asking.
Anything else — email hello@haddon.software and a human replies the same business day.
Yes, and you get the file. If your team works somewhere else we will fit in with that rather than make you migrate.
That is the normal case. We extend what you have into interface territory — brand guidelines rarely cover table density or error states, so that is the gap we fill.
Then that is what we quote. Small, well-scoped pieces of work are welcome; we would rather do one flow properly than pad a project.
If you need it. It is not free — it roughly doubles the visual review surface and needs its own contrast checking — so we will ask whether your users actually want it before assuming. When we do build it, it is defined in tokens so it stays consistent.
We work in weekly cycles rather than counting rounds, which tends to produce better results than a fixed number of formal reviews. The scope is agreed up front; iterating within that scope is just how the work happens.
Related
You might also need…
Want to talk it through?
The first call is free, runs about thirty minutes, and you'll get a straight answer about whether we're the right fit — including when we're not.