Interface and product design as its own engagement, not a step before a quote.
Wireframes, a system, and a handoff a developer, ours or somebody else's, can actually build from. No commitment yet to who writes the code.
What this is
This is the design work itself: the structure of a product (UX) and the visual system it's built from (UI), delivered as files a developer can build from, separate from a decision about who does the building. There's a real difference between a pretty mockup and a spec. A mockup shows the best version of one screen with content that always fits. A spec shows what that screen does when the list is empty, when a name is three times longer than the placeholder text, when a request fails, and what happens on a small phone in landscape. A mockup that only shows the happy path hands those decisions to whoever builds it, usually mid-sprint, without the file open in front of them.
Accessibility gets treated the same concrete way. Contrast ratios that actually pass, a focus order that follows the visual layout, hit targets sized for a thumb rather than a mouse pointer, checked, not asserted in a sentence on a slide. These are decisions a design phase can make once, correctly, or a build can make later, inconsistently, screen by screen.
A design system is the difference between a product that feels like one thing and one that feels like several screens shipped by different people. A type scale, a spacing scale, color tokens, and the states every component actually needs, default, hover, disabled, loading, error, built once before the individual screens, so the second and third screen reuse a decision instead of re-inventing it slightly differently. Skipping this step doesn't save time, it moves the cost of making those decisions into the build, where it's more expensive and less consistent.
The file goes to whoever builds it, and about half the time that is not us, an internal team or a different agency, and that changes what the handoff has to contain. If we won't be in the room to answer a question the file leaves open, the file has to answer it instead. We're equally happy either way: designing what we go on to build, or designing what somebody else builds next.
What you get
Wireframes for the actual flow
Not just the primary screen, the whole path a user takes.
A visual design system
Type scale, spacing, color tokens and component states, so decisions get made once, not per screen.
Every screen designed for its edge cases
Empty, error, overflow, not just the happy path with sample content that always fits.
Accessibility checked concretely
Contrast ratios, focus order and hit target sizes, verified, not asserted.
An interactive prototype
For the flows that need to be felt rather than described, before any code exists.
A developer handoff
Figma dev mode or equivalent, with the spacing, states and assets a build actually needs.
Responsive behaviour specified
Not just a desktop and a mobile screenshot with everything in between assumed.
The source files
Handed over, whether or not we're the ones who build from them.
When this fits, and when it does not
A good fit
- You need the interface designed before you can even scope a build, and want a real answer to "how big is this" instead of a guess.
- An existing product looks inconsistent because every screen was designed separately, by different people or at different times, and nobody owns the system.
- You have a dev team already, in-house or elsewhere, and need a design they can build from without decisions being made mid-sprint by whoever happens to be coding that screen.
- The product needs to be tested with real users before committing engineering time to build it.
Not a good fit
- You want a full brand identity: logo, wordmark, brand book, tone of voice. That is graphic design, a different discipline, and we do not do it. Hire a brand studio and bring us the guidelines.
- You want moderated usability sessions with recruited participants and a research report at the end. We test flows against the people who will use them, but we are not a research agency and we will not staff a panel.
- You want a Figma file that looks good in a board deck. We spend most of the time on empty, error and overflow states, because that is where the build cost hides, and that work makes the file less pretty rather than more.
- You need three visual directions to choose between before you will commit. We do one, argued, and revise it. If a pitch of concepts is what you are buying, an agency that works that way is the right call.
- You already know exactly what you want built and just need it built. Design happens inside that engagement, so a separate design phase would only add a handoff you do not need.
How it runs
- 01
Understand the flow
What the product has to do and for whom, before a single screen gets drawn.
- 02
Structure
Wireframes for the whole flow, including the screens that aren't the interesting one.
- 03
Design the system
Type, spacing, color and component states, then the individual screens built from it, not before it.
- 04
Test the edge cases
Empty states, errors, long content, small screens, before calling a screen done.
- 05
Hand over
Files, a prototype and a spec a developer can build from, ours or somebody else's.
Questions we get
Do you also build what you design?
Often, yes, but the two are scoped and billed separately, and plenty of these engagements end with files handed to somebody else's dev team. We design either way.
What do we actually get?
Figma files, or whichever tool fits the project, an interactive prototype for the flows that need it, and a handoff spec with the states and measurements a build needs. Not a single polished screenshot.
Can you work within our existing brand guidelines?
Yes, and we'd rather you had them. Guidelines set the color and type decisions; the work here is the system and the screens built on top of them, not a rebrand.
How long does a design phase take?
Depends on how many flows there are and how much of the product is new versus existing. A focused flow is a matter of weeks, a full product is longer, and we scope it after seeing what exists, not before.
Need the interface designed before you can scope the build?
Describe the product and who uses it. We'll tell you what a design phase actually needs to cover before anyone commits to building it.