//For · UI/UX designers

North for UI/UX designers

Product work arrives shaped like a sprint and gets billed shaped like an hour, which is how a two-week engagement becomes a four-month one nobody can end. The remedy is defining the unit of work before the first stand-up.

Sell the block, not the hour.

That is the whole rule for product work, and it is worth stating first because almost every other problem on this page follows from breaking it. UI and UX engagements naturally arrive in sprint-sized pieces: two weeks of discovery, two weeks of wireframes, a block of screens, a handoff. Billed by the hour, those blocks have no edges. The client cannot see what a week bought, you cannot see when the engagement ends, and both of you spend the retro arguing about whether the Slack thread on Thursday counted.

The engagement with no end

Hourly billing survives in product design because the work is often hard to see at the start: a legacy product with nine hundred screens and no design system is a genuine unknown. The trouble is that hourly billing never converts back. Four months in, you are still on the same timesheet, the scope has been rewritten three times, and there is no document that says what finished looks like.

The rung between hourly and a full fixed price is a block: two weeks, a stated number of screens, a fixed sum. The client keeps the option to stop after any block. You keep the option to re-quote when the requirements change. Nobody polices an hour.

Five stakeholders, one designer

Product teams review by committee. The product manager, the engineering lead, the head of marketing, the CEO, and someone from support who was cc'd. Each has a real perspective and each sends feedback separately, which means one round of revisions is actually five, spread over nine days, several of them contradictory.

The fix costs one question on the discovery call: who owns the feedback? Write that name into the proposal, define a round as one consolidated message from that person, and let the team reconcile the other four opinions on their side. It is a small sentence. It is the difference between two rounds and nine.

Handoff, and what "done" means

The last week of a product engagement is where the goodwill goes. The screens are finished, and then the developers have questions, and answering them is somehow part of the project, and answering them is still part of the project three weeks later. Handoff has to be a deliverable with edges: an annotated file, a component list, named states for each screen, and a stated window (a week, say) for questions after delivery. Past the window, questions are a new engagement, quoted separately.

This is the flat part of the page. It is administrative, it is the part nobody enjoys writing, and it is the part that decides whether the engagement pays.

The engagement, on paper

You paste the notes from the discovery call. North drafts three options that are genuinely different jobs, named by their shape ("Audit", "Audit and redesign", "Redesign and handoff"), with the scope inside each written as countable things: twelve screens at final fidelity, two rounds with a round defined as one consolidated message, a component library of a stated size, a handoff pack. Each line says, in one sentence, what it does for this product, taken from the call rather than from a template. Each option carries a short defence of its price naming the parts of the scope that carry the number.

You edit the draft and send it from a confirmation screen; the client reads it in a private room and accepts. The agreement, drafted from the same scope at the same time, appears at that moment; the client checks their email once and signs, and the signature is bound to that address. After signing, the accepted option can become stages that match your blocks (discovery, wireframes, screens, handoff), each with a date, ticked off as it lands, watched by the client in the same room. Finished stages become invoice lines that remember what was already billed, so the invoice at the end of block three does not charge for block two. Stages, and card payment on your own Stripe account, are part of the paid plan.

If you genuinely bill by the hour on a rescue job, North's proposals are the wrong shape. They are fixed options with totals, because that is the unit the product is built to defend. Use it for the engagements that have edges.

What stays in your other tools

North does not track time, does not connect to your design file, and does not run a ticket board. There is no Figma link in it and no burndown. Developer handoff still happens wherever it happens now; what North gives you is the sentence in the signed agreement that says where it ends.

Common questions

Should a freelance UX designer charge hourly or per project?
Per defined engagement where the scope can be seen, and by the day where it genuinely cannot. An audit of an existing product is a known shape; a redesign of a product whose requirements change weekly is not. The middle rung most experienced product designers actually use is a two-week block at a fixed price, with a stated number of screens, which keeps the client's option to stop and removes the timesheet argument.
What counts as a finished screen for billing purposes?
Write it down before the work: a screen at final fidelity, in the shared file, with its states covered (empty, loading, error) and its components named. Without that sentence a screen is finished when the client stops asking about it, which can be never. Define developer handoff the same way: an annotated file and a component list, not an open-ended promise to answer questions.
How do I handle stakeholder feedback from five people on a product team?
Name one person as the feedback owner on the call and write the name into the proposal. Feedback then arrives consolidated, once per round, in one message, and the four other opinions get reconciled on their side rather than in your inbox at eleven at night. A round that is not defined this way will cost you roughly a day each time it opens.