Do we get three concepts to choose between?

No, and the reason is worth a minute. When three directions are presented, the usual outcome is that the header is taken from the first, the colour from the second and the footer from the third, and the result is weaker than any of the three because the thinking that held each one together has been removed. We present one direction on one screen with the reasoning behind it. If it is wrong we change the direction, which is a different and much more productive conversation than picking parts.

What if we do not like the direction you present?

Then we change it, and that is exactly what the single-screen stage is for. It costs a few days rather than the whole project, which is why the direction is settled on one screen before the other thirty are built. What we ask for is what is not working rather than an instruction — knowing that it feels too corporate lets us fix the cause, whereas being told to make the blue darker fixes a symptom.

Do you write the words as well?

The interface text, yes — button labels, empty states, error messages, form help. That is a third of the design and it is not something to hand to someone else at the end. Marketing copy, long-form page content and product descriptions are a separate piece of work and are listed as out of scope in the proposal so there is no surprise in week three.

Will our developer be able to build this?

That is what handoff is for. Buttons and inputs are built as components, every colour and text style is named rather than loose, dead screens are moved to an archive page, and the developer gets a Dev Mode link plus a short document covering what changes at each breakpoint, which fonts are used and where they come from, which icon set, what is interactive, and which assets are SVG and which are PNG. Where your engineers want a call to walk through it, that is included.

Do you design mobile as well as desktop?

Yes, both, for every screen. A layout that works in columns at desktop width has to become a sequence on a phone, and the decision about what order that sequence runs in is a real design decision rather than something that happens automatically. Tablet is a third layout and is only included when it is agreed at the start.

Can we start straight here without wireframes?

Sometimes. If you already have a structure that everyone has agreed to, or an existing product being redesigned rather than invented, we can start from that. If the structure is still an open question, starting here means the structural arguments arrive disguised as taste arguments once the visuals exist, which is slower and more expensive than settling them first.

UI/UX & Design

High-fidelity product design

Every screen of your app or site finished in Figma — one visual direction, real content, and the empty, error and overloaded states that decide whether a build survives contact with real data.

From: $1,500–$12,000
Typical time: 3–8 weeks
Usually bought by: Startups

What this actually solves

Three versions of the same buyer arrive at this page. The first has a developer, or an AI that writes usable code, and has discovered that the constraint is not building — it is deciding what the thing should look like and behave like, screen by screen. The second has a product that works and looks like it was made in 2018, and has noticed that new customers treat them as smaller than they are. The third has an investor meeting in the calendar and knows perfectly well that the first impression is made by the interface, not the feature list.

What all three are really buying is a set of decisions. Design is not decoration; it is choosing what is seen first, what is seen second, what sits next to what, what the first action is, and what should not be on the screen at all. Those decisions get made by somebody. If nobody makes them, they are made by accident, and accident is a poor designer.

There is also a timing argument that is worth stating plainly, because it is the reason this work is bought before the build rather than after. Moving a button in Figma takes seconds. Moving it in code after the build takes an afternoon. Moving it after launch, with users and analytics and support tickets attached to it, takes days.

What we do, and in what order

Start from the structure. Existing wireframes, an existing product, or a short scoping pass if neither exists — page list, what each page is for, who decides on your side. That last question changes the timeline more than any other. Two to three days.
One screen as the visual direction. Usually the homepage or the primary working screen, with a small mood board showing the choices behind it, presented for approval. One direction, not three. The note that goes with it says what to do if it is wrong — tell us what is not working and we change direction rather than change the blue. Three to five days.
The rest of the screens, desktop and mobile. Once the direction is approved this moves fast, because the decisions are already made. Type scale, spacing scale, colour roles and component behaviour are fixed, so each new screen is composition rather than invention. One to three weeks.
The screens nobody designs. Empty search results. Empty cart. A form with an error on every field. Loading. Connection lost. A name far longer than anyone planned for. One item in the list. Twenty items in the list. This takes a couple of hours and it is consistently the reason engineering teams ask for the same designer again. Half a day to a day.
Componentise and clean the file. Buttons, inputs and cards as real components with their states. Every colour and text style named. Layers named. Superseded screens moved to an archive page rather than left floating next to the live ones. Two to three days.
Handoff. Dev Mode access plus a short written document — breakpoint behaviour, fonts and their source, icon set, interactive behaviour, and which assets are vector and which are raster. One day.

The craft underneath this is measurable rather than mystical. Spacing sits on one scale. Body text is never below 16px and line height runs at roughly 1.5 times the text size, with headings tighter. Paragraph columns stay near 60 to 75 characters, which in practice means a text column that does not exceed about 720px however wide the screen is. One typeface, two at most, and if two then obviously different rather than two similar sans-serifs. Text contrast is measured against a 4.5-to-1 threshold for body and 3-to-1 for large text, using a contrast checker rather than an opinion. Pure black is avoided because it reads as harsh on screen. Icons come from a single set — Lucide or Phosphor — so that stroke weights match.

What moves the price

The range is $1,500–$12,000 and three factors set it.

How many unique screens. A focused application of around ten screens sits at the bottom of the range. A full product across two platforms with forty screens and their states sits at the top. Unique is again the operative word — a list, a detail view and a form template cover a great deal of a product.

Whether a design system already exists. If there are usable tokens and components, a large part of the work is already done and the estimate roughly halves. If everything has to be established as we go, that establishment is part of the job.

How many review rounds are included. Rounds are counted and written into the proposal — typically one on structure and two on visual design, with further rounds charged. This is not a way of restricting feedback; it is a way of making sure the feedback arrives in batches rather than as a trickle over six weeks.

What usually goes wrong

Only the screen where everything is going well gets designed. Three orders in the list, a short customer name, a clean product photograph. Then real data arrives — one hundred and forty orders, a company name that runs to two lines, a photo shot on a phone in a warehouse — and the layout breaks in four places. The rule that prevents it is designing every screen three times over — with nothing in it, with a little, and with far more than anyone expects.

Three directions instead of one. It feels generous and it produces a composite assembled from parts of all three, and it leaves you believing your job is to choose rather than to judge. One direction, with the reasoning visible, and a clear invitation to reject the whole direction if it is wrong.

A light weight in a pale grey because it looks expensive. A 300-weight heading in soft grey looks refined on a new laptop in a dim room. On a five-year-old screen next to a window it has effectively disappeared, and at that weight and colour it also fails the contrast threshold outright. Body text never goes below 400 weight, and 300 is only used above roughly 32px in a dark colour.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Do we get three concepts to choose between?: No, and the reason is worth a minute. When three directions are presented, the usual outcome is that the header is taken from the first, the colour from the second and the footer from the third, and the result is weaker than any of the three because the thinking that held each one together has been removed. We present one direction on one screen with the reasoning behind it. If it is wrong we change the direction, which is a different and much more productive conversation than picking parts.
What if we do not like the direction you present?: Then we change it, and that is exactly what the single-screen stage is for. It costs a few days rather than the whole project, which is why the direction is settled on one screen before the other thirty are built. What we ask for is what is not working rather than an instruction — knowing that it feels too corporate lets us fix the cause, whereas being told to make the blue darker fixes a symptom.
Do you write the words as well?: The interface text, yes — button labels, empty states, error messages, form help. That is a third of the design and it is not something to hand to someone else at the end. Marketing copy, long-form page content and product descriptions are a separate piece of work and are listed as out of scope in the proposal so there is no surprise in week three.
Will our developer be able to build this?: That is what handoff is for. Buttons and inputs are built as components, every colour and text style is named rather than loose, dead screens are moved to an archive page, and the developer gets a Dev Mode link plus a short document covering what changes at each breakpoint, which fonts are used and where they come from, which icon set, what is interactive, and which assets are SVG and which are PNG. Where your engineers want a call to walk through it, that is included.
Do you design mobile as well as desktop?: Yes, both, for every screen. A layout that works in columns at desktop width has to become a sequence on a phone, and the decision about what order that sequence runs in is a real design decision rather than something that happens automatically. Tablet is a third layout and is only included when it is agreed at the start.
Can we start straight here without wireframes?: Sometimes. If you already have a structure that everyone has agreed to, or an existing product being redesigned rather than invented, we can start from that. If the structure is still an open question, starting here means the structural arguments arrive disguised as taste arguments once the visuals exist, which is slower and more expensive than settling them first.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about High-fidelity product design All UI/UX & Design services