We design interfaces that survive being built, which means every component comes with its loading, empty, error, and long-content states, and every colour pair clears accessibility contrast before it reaches a developer. Design that hands off cleanly is the difference between a build that ships and one that gets renegotiated.
“Our developers keep asking what happens when it’s empty.”
Every component we hand over includes its empty, loading, and error states. See the process
“The design looked great and shipped badly.”
Usually a handoff problem. Tokens and states fix most of it. See the plans
“Our interface has fourteen shades of grey.”
That’s what a design system prevents. The review counts them for you. Start with a review
“We need brand and logo work.”
That’s the branding service, not this one. Different discipline. Read who this isn’t for
These figures cover every Gatilab service, not this one alone. We’d rather say that plainly than imply a per-service record we haven’t published.
Brands we’ve delivered work for
Everything is delivered as tokens and components rather than flat screens, because a picture of an interface is not a specification for one.
For teams with a live product or site who know the interface is inconsistent but not why.
Up to 10 screens · 1 to 2 weeks
Credited against a design system booked within 30 days.
For products and sites that keep growing and need consistency to stop being a per-screen argument.
Quoted from component count · 5 to 8 weeks
Every colour pair we ship clears 4.5:1, verified, not eyeballed.
For product teams shipping features monthly who need design capacity without a full-time hire.
3-month minimum
Capacity is named in advance. We won’t quietly take on more than we can do well.
Most design handoffs fail at the same three places: states, tokens, and responsive behaviour. Each stage here targets one.
Week 1
We count every colour, type size, spacing value, and near-duplicate component in the current interface. The number is usually much higher than teams expect, and it makes the problem concrete rather than aesthetic.
You leave with: A written inventory, with the duplicate count.
Week 2
Colour, type, spacing, and radius become named tokens with light and dark values, each pairing checked for contrast. Getting this right first means individual screens stop being colour decisions.
You leave with: A token set, contrast-verified in both themes.
Weeks 3 to 6
Every component gets its default, hover, focus, active, disabled, loading, empty, error, and long-content states. The states are the actual work. The default state is the easy part and the one that usually ships alone.
You leave with: Components with every state specified, not just the happy path.
Weeks 7 to 8
Documentation covering when to use each component, what not to do with it, and how it behaves responsively, plus a walkthrough with the developers who’ll build it.
You leave with: Docs, a walkthrough, and files in your own workspace.
UI design is easy to sell as pretty pictures. Two of these are reasons we decline.
Something not covered? Ask directly and you’ll get a straight answer, not a calendar link.
Because states are where interface work actually lives. A dashboard with data is the easy view. The same dashboard with no data yet, with one item, with a failed request, with a name forty characters long, or mid-load is four or five real designs. Teams that skip them get those decisions made by whichever developer hit them first, at 5pm.
Usually, and in your workspace under your account, so ownership is never a question. If your team works somewhere else, say so. What matters more than the tool is that you get tokens and documented components rather than flat pictures of screens.
Included, and not optional. Every colour pairing we ship is measured against WCAG contrast thresholds rather than eyeballed, in both light and dark. We’ve caught brand colours that fail at small sizes on our own projects, so this isn’t theoretical. Interactive targets get checked for size too.
Yes, and extending a system you already have is usually the better purchase. The review will tell you honestly whether the existing system is worth building on or whether it’s accumulated too many exceptions to be a system anymore. Both answers happen.
Usually a sign the design ignored a technical constraint, so the first question is what made it impractical rather than who deviated. The retainer includes reviewing what got built and either fixing the design or documenting the deviation as the new standard. Systems that don’t absorb reality stop being used.
We design responsive web interfaces and web apps. Native iOS and Android have their own platform conventions that deserve someone who works in them daily, and we’d be learning on your budget. We’ll say so rather than take the project.
Share a link or a few screenshots of the interface and tell us what keeps getting argued about. We’ll tell you whether it’s a component problem, a token problem, or a process problem, before you buy anything.
