UI design with every state drawn, not just the happy path
A screen is easy to design once. The expensive part is defining every component, every state and every edge case so the build does not become a negotiation.
What is UI design?
UI Design is the interface layer of a digital product: the components, their states, the tokens that define colour, spacing and type, and the rules that govern how they combine. It suits Australian teams building an application or a large site who need developers to implement a defined system rather than interpret static pictures.
Get a fixed written quote- Typical timeline
- 4 to 9 weeks
- What drives cost
- The number of unique components, whether you need one theme or several, how much of the accessibility work must be documented for an external audit.
- Best for
- Applications, portals and products with recurring interface patterns
- You own
- The Figma files, the token definitions and the annotated specifications
- Built with
- Figma libraries, semantic design tokens, WCAG 2.2 AA annotations
Your handover
Every component needs its states drawn, not implied
A button is not one thing. It is default, hover, focus visible, active, disabled, loading and, in some contexts, success or error. A text input is empty, focused, filled, invalid with a message, valid, disabled and read only, and each of those has to work at a range of widths with content that is longer than anyone expected. A table has a loading skeleton, a populated state, a single row, five hundred rows, a filtered no results state and a first use empty state that should teach rather than apologise.
- 01Component inventory mapped to product flows
- 02Two layer token set with agreed naming
- 03Figma component library with variants and states
- 04Contrast and focus appearance checked to WCAG 2.2 AA
- 05Form, table, navigation and feedback patterns
- 06Responsive rules at defined breakpoints
- Clickable prototype of the primary flows
- Keyboard order and screen reader annotations
- Recorded handover walkthrough for developers
The full list
If those are not drawn, a developer invents them at midnight, and the invented version is inconsistent with the four other places the same pattern appears. We produce a state matrix for every component and draw the ones that matter, which is why the file count is higher than clients expect and the build is shorter than they expect. The empty and error states are the ones that get skipped, and they are the ones users see when they are already frustrated.
- Interaction states: default, hover, focus visible, active, disabled
- Data states: loading, empty, partial, populated, overflowing, error
- Content extremes: the longest realistic label and the shortest
- Responsive behaviour at the breakpoints the product actually needs
- Light and dark themes where the product will support both
- Right to left or long word behaviour where community languages are served
Focus indicators must not be obscured by sticky headers or floating chat widgets, which is a layout decision as much as a styling one.
Design tokens, and why naming them is the real work
Tokens are the named values a design system is built from: colour, spacing, radius, type sizes, shadow, motion duration. The technique is not complicated. The judgement is in the naming, because names determine whether the system can change later without a rewrite. Two layers work best. Primitive tokens record raw values with neutral names, and semantic tokens describe purpose, such as the colour of a destructive action or the surface behind elevated content. Components only ever reference the semantic layer.
More on design tokens, and why naming them is the real work
That separation is what makes a theme switch, a rebrand or an accessibility correction a change in one file rather than a hunt through four hundred screens. It is also what makes handover unambiguous, because the names in Figma match the names in the codebase and nobody translates between the two. We agree that naming with your engineers in the first week, not at handover, since retrofitting a naming convention onto a half built front end is a job nobody enjoys or budgets for.
How the engagement runs
How the interface work runs
We do not start with screens. Starting with screens produces a set of pictures that happen to share a colour palette, and the underlying inconsistencies appear during the build. We start with an inventory of what the product actually needs, define tokens, build components in isolation, then assemble screens from them. Screens become compositions rather than originals, which is what makes the tenth screen fast instead of slow.
- 01InventoryAudit the flows and list every component and pattern the product genuinely requires
- 02FoundationsColour, type scale, spacing, radius and motion defined as tokens with agreed names
- 03Contrast passPalette tested against WCAG 2.2 AA before it is applied to anything
- 04ComponentsEach one built with variants and states, reviewed in isolation with an engineer
- 05PatternsForms, tables, navigation, filtering and feedback assembled from the components
- 06Screens and prototypeReal flows composed and made clickable for review and testing
- 07AnnotationBehaviour, keyboard order, focus handling, announcements and responsive rules documented
- 08HandoverLibrary published, tokens exported and a walkthrough recorded for the build team
Two decisions on your side that keep the project moving
Engineers are in this process from the beginning. A weekly session where a developer reviews the components being drawn catches the ones that are expensive to build for the value they add, and it catches naming drift before it hardens. If we are also doing the build, the same people carry it through. If your team is building, the handover pack is written for them rather than for us.
Choose the right level
Build on an existing component library or design from scratch
Starting from an established open-source library is often the right call, and saying otherwise is usually a designer protecting scope. The question is how much of your product's value lives in the interface itself. A back office tool used by trained staff gains almost nothing from bespoke components and gains a great deal from proven accessibility and keyboard behaviour. A consumer product where the interaction is the product is a different case.
Approach
01
Off-the-shelf styled library
Suits
Internal tools, admin panels, early stage products proving a concept
The trade off
Your product looks like every other product using that library
02
Headless library with your tokens
Suits
Most commercial products, teams with limited front end capacity
The trade off
Some visual constraints remain, and you inherit the library's release cycle
03
Fully bespoke component system
Suits
Products where the interaction itself is the differentiator
The trade off
You own every accessibility and keyboard edge case, which is real ongoing work
04
Vendor platform theming
Suits
Systems built on a platform that controls its own interface
The trade off
You style within the vendor's limits and nothing more
How we work this out during scoping
There is a middle path most teams land on, which is an unstyled or headless component library providing behaviour and accessibility, with your visual system applied through tokens. You inherit years of solved keyboard and screen reader problems and still look like yourself. We work through this with your engineers during scoping, because the decision constrains both the design files and the front end architecture that follows in the build.
What WCAG 2.2 AA actually constrains in an interface
Accessibility conformance is usually discussed as a virtue and delivered as a retrofit. In interface design it is a set of concrete constraints that change what you draw, so we work to WCAG 2.2 AA from the first component. Body text needs a contrast ratio of at least 4.5 to 1 against its background, and large text at least 3 to 1. Interface component boundaries and meaningful graphics need at least 3 to 1, which is the rule that quietly rules out the pale grey input borders and low contrast disabled states that dominate current design fashion.
Version 2.2 added criteria that hit interface work directly
Version 2.2 added criteria that hit interface work directly. Focus indicators must not be obscured by sticky headers or floating chat widgets, which is a layout decision as much as a styling one. Interactive targets need a minimum size unless spacing or an alternative provides equivalent access. Any drag interaction needs a single pointer alternative. Help mechanisms must appear in a consistent place across pages. Authentication must not depend on a cognitive test such as recalling or retyping a code where a paste is blocked. Each of those is cheap to design in and awkward to add afterwards.
When UI design is not the thing you need yet
If nobody has agreed what the product does or how a user gets through the core task, interface design will surface that disagreement in the most expensive possible way, one screen at a time. That work belongs in UX design: flows, information architecture and testing with people who resemble your users. Drawing components before the flows are settled means drawing them twice.
The rest of the answer
The other case is scale. If you are building a marketing site with a dozen templates, a full tokenised system with a component library is more machinery than the job needs, and website design covers it properly at a lower cost. Interface systems pay off when components are reused hundreds of times across a product, when several developers work in parallel, or when the product will keep growing for years. If none of those are true today, buy the lighter thing and revisit it when they are.
How we scope it
Four ways to scope your UI Design project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
UI Core
The essentials, done properly, not a template
Fixed written quote, agreed before work starts
- Component inventory mapped to product flows
- Two layer token set with agreed naming
- Figma component library with variants and states
UI Full identity
A complete identity your team can apply without us
Fixed written quote, agreed before work starts
- Everything in UI Core
- Contrast and focus appearance checked to WCAG 2.2 AA
- Form, table, navigation and feedback patterns
- Responsive rules at defined breakpoints
UI Brand system
A system that holds up across products and campaigns
Fixed written quote, agreed before work starts
- Everything in UI Full identity
- Clickable prototype of the primary flows
- Keyboard order and screen reader annotations
- Recorded handover walkthrough for developers
UI Brand care
Applying and extending it as the business grows
Rolling monthly, quoted in writing
- New assets and applications as they come up
- The system extended rather than reinvented
- Files and source artwork kept in order and in your name
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Ownership and handover
Do we own the design files and the tokens?
Yes. The Figma library is transferred to your organisation, the token definitions are exported in a format your build can consume, and the annotations come with them. Nothing is held in an account we control. If you engage another developer later, they get the same published library and walkthrough we would have used ourselves.
Do you deliver the design system as code as well as design files?
We can, and it is a separate scope worth deciding early. Some clients want Figma plus token exports and will build the components themselves. Others want the component library implemented and documented in code. The second is more work and removes a translation step. We quote them separately so you can choose on the basis of your team's capacity.
Will this pass an accessibility audit?
Design decisions that affect conformance are made to WCAG 2.2 AA and documented, which removes a large share of the findings an audit typically raises. Conformance is a property of the built product, though, not of a design file. Keyboard behaviour, focus management and announcements have to be implemented correctly too, so we annotate them and recommend testing the build before any formal audit.
Detail and edge cases
How long does UI design take?
Usually 4 to 9 weeks. Foundations and the first pass of components take the early weeks, patterns and screens the middle, and annotation and handover the end. The size of the component inventory drives the number more than anything else, so we agree that inventory in week one. Adding a second theme or a native mobile variant extends it.
What makes one interface project cost more than another?
The number of unique components, whether you need one theme or several, how much of the accessibility work must be documented for an external audit, and whether the product is web only or also native. data-heavy products with complex tables and filtering cost more than content led ones. We size the inventory during scoping and send a fixed written quote.
Can you work with our existing developers and their framework?
Yes, and the earlier we meet them the better the result. We agree token naming with your engineers up front so the design and the codebase share a vocabulary, and we review components with them as they are drawn so nothing expensive gets designed in isolation. We work comfortably alongside React, Vue and native mobile teams.
Related services
Get a fixed written quote for your interface work
Send us the product, the flows and who is building it. We reply within one business day with a component inventory estimate and a fixed written quote.