Interface design that another team implements. No code ships from this engagement, and that is the point of it.
Do I need this, or do I just need a site
The honest split, including when the answer is no.
This service pays for itself on some projects and is a waste of money on others. Here is which is which, stated before you buy rather than after.
Worth buying when
- The interface has real states
- Empty, loading, partial, failed, permission-denied. Every one of those is a design decision, and leaving them to be improvised during implementation is where products get ugly.
- There are roles that see different things
- Admin, member, guest. Role differences multiply screens fast, and working them out in a design file is far cheaper than working them out in code.
- A team will build it and needs a specification
- Developers who are not in the room need a document, not a conversation. That document is the deliverable here.
Not worth buying when
- It is a marketing site
- A site with pages, sections and a contact form does not need a separate design phase billed by the hour - the design system inside a website build already covers it, at a fixed price. Buy the build.
- The product does not exist yet as a decision
- If what it does is still being argued about, hours spent drawing screens are hours spent drawing the wrong screens. Settle the product question first.
- Nobody on your side can approve anything
- Hourly work with no decision-maker burns the cap on revisions of revisions, and ends with a file nobody owns.
What is delivered
Four artefacts, in this order.
Flows
6-12 h
Every path through the product as a diagram, including the ones that fail. This is where most of the real thinking happens and where scope problems surface early enough to be cheap.
Wireframes
12-30 h
Structure and hierarchy at low fidelity, so the argument is about what goes where rather than about colour.
Interactive prototype
15-40 h
High-fidelity screens wired together, clickable on a real device. Testable if you have users; convincing for stakeholders if you do not.
Handoff specification
8-16 h
The written document: components, every state, edge cases, keyboard behaviour, focus order, and the accessibility notes carried into implementation.
Hour ranges are typical, not a quote. The cap is agreed for your specific scope before any work starts.
How hourly billing is kept honest
The cap, and what happens when it is reached.
- A cap is agreed before the first hour
- Derived from the flow count and the state count, not from a feeling. It is a ceiling on what you can be billed, not a target to be spent.
- Hours are reported weekly
- What was done, how long it took, and how much of the cap remains. Sent whether or not you ask for it.
- At 80% of the cap, the work pauses for a decision
- You are told what is left, what it will take, and given the choice to raise the cap, cut scope, or stop with what exists. Nothing is billed past a cap you have not agreed to.
- Hours come off a build with this studio
- If the same interface is then built here, the design hours already paid for are deducted from the build price in full. The design phase is not sold twice.
- Rate
- EUR 65 per hour
- Minimum engagement
- 10 hours
- Billing cycle
- Monthly, in arrears
Against the weekly reports, so nothing on the invoice is a surprise.
How it proceeds
Intake to handoff, with the sign-off named at each step.
Intake
Scope and cap
The flows are counted, the states estimated, and a cap proposed in writing with the reasoning behind it.
You supply
What the product does, who uses it, and what already exists.
Phase 1
Flows
Every path diagrammed, including failure paths.
You supply
Sign-off on the flows before wireframes start.
Phase 2
Wireframes
Structure and hierarchy, low fidelity, argued and settled.
You supply
Sign-off, from the named decision-maker.
Phase 3
Prototype
High fidelity, wired, testable on a real device.
You supply
Review, plus test findings if you ran any.
Handoff
Specification and transfer
The written spec, the Figma file transferred to your account, and a working session with your developers.
You supply
A developer in that session who will actually build it.
What raises the number
Where the hours actually go.
| Decision | Effect on the price | Why |
|---|---|---|
| Each additional user roleA second role does not add a few screens, it multiplies the state matrix across every screen that already exists. | + 20-40% on the hour cap | |
| Designed for phone, tablet and desktop separatelyNot a resize. A complex table or a multi-step form becomes a different interface on a phone and has to be designed as one. | + 30% on the hour cap | |
| Design system built alongsideWorth it when more than one team will build from it, and waste when a single developer builds one product once. | + 15-25 h | |
| Working from an existing productAuditing what exists, and deciding what to keep, costs real hours before a single new screen is drawn. | + 8-16 h |
Send the flow list and the roles and a cap comes back with it, usually the same day. Or write to info@urbanuplink-ltd.com with whatever documentation already exists.
Asked about design work
Questions about UX/UI.
Which tool is the handoff in?
Figma, with developer mode enabled and the file shared to your account rather than to a link that expires. The written specification is a separate document, because a Figma file describes what a screen looks like and says almost nothing about what happens when a request fails.
Can our developers work from it?
That is the only thing it is designed for. Every state is drawn - empty, loading, error, partial, permission-denied, too-long-string - and the specification names the behaviour rather than leaving it to be inferred from a screen drawn only for the case where everything goes right. Developers can and should send back the cases that are missing; correcting those is inside the cap.
Do you do user research?
Desk research on your existing product data, support tickets and competitors: yes, and it is billed at the same hourly rate. Recruiting and running a research programme with real participants is not offered, because doing it properly needs a specialist and doing it badly is worse than not doing it.
Do you test with real users?
No moderated testing sessions are run here. If you have users available, the prototype is built to be testable and the findings are worked into the design inside the cap - but recruiting them, moderating the sessions and analysing the recordings is not part of this service.
What if we change scope mid-way?
Expected, and handled by the cap rather than by a change-request process. When new scope will push past the agreed hours, you are told before the work starts, with an estimate. You then raise the cap, drop something else, or stop. Nothing is billed past a cap you have not agreed to.