It covers our product UI/UX design work for your product, based on the proposal you accepted, and it sets the ground rules for how we’ll run the project day to day.
We’ll use it to keep decisions, reviews, handoff, and payment predictable so the design holds up when engineering starts building. If anything in the proposal and this agreement describe the same point, we’ll follow this agreement so there is one source of truth.
Scope of work
We’ll do product UI/UX design for the product and platform(s) described in the accepted proposal. The goal is to turn what we learn from stakeholders and users into flows, screens, and systemised UI that your engineers can build without guessing.
The deliverables included in this project are listed below. If a deliverable is not on that list, we can still help, but we’ll treat it as a change and price it before we start so your team is not surprised late in the schedule.
* UX audit findings report * Research summary pack * User flows and IA map * Wireframes and prototype * UI design system library * Handoff-ready UI screens
Payment
To book the project dates, we invoice 40% of the total price when the proposal is signed. We start holding time for the team once that booking payment is received. We invoice the remaining 60% when the finished work is handed over, meaning the agreed deliverables are ready for your team to use and we’ve scheduled the handoff walkthrough.
Each invoice is payable within 14 days of its date. If an invoice becomes overdue, we pause work and handoff until the account is back in good standing, and we shift the timeline by the length of the pause. We do this to protect your schedule and our team’s time.
Reviews and changes
A revision round is one consolidated set of feedback from you on a phase deliverable, given as a single list that we can work through. It includes clarifying questions and reasonable tweaks inside the approved direction, like adjusting hierarchy, states, copy placement, or a flow step. It does not include a new direction after you have approved the previous one.
Each phase includes the review cycles shown in the scope for your chosen tier. If feedback arrives scattered across calls, chat, and multiple documents, we will ask you to consolidate it before we revise. Changes beyond the included rounds, or new directions after approval, are quoted and agreed in writing before we do the work.
Who owns what
Once the final invoice is paid, you own the finished deliverables from this project: the UX audit findings report, research summary pack, user flows and IA map, wireframes and prototype, UI design system library, and handoff-ready UI screens. You can use them in your product, share them internally, and provide them to your developers and contractors so they can build and maintain what we designed.
We keep ownership of our underlying tools, templates, methods, and any reusable components we bring to the project. We also keep our working files and drafts unless the accepted proposal says you are receiving editable source files. If you are receiving source files, we’ll hand over the Figma file(s) set up with named components and styles, annotated flows, and notes for states and edge cases.
Portfolio use
We may show the finished work from this project in our portfolio, on our website, and in private presentations to prospective clients, because that is how our work gets evaluated. When we share it, we focus on the outcomes and the design decisions, not your confidential data.
If you need the work to stay private, tell us in writing before kickoff. We will then treat the work as non-public and we will not post it. If you want a time-based hold, for example until launch or until an internal announcement, we can do that too as long as we agree the timing in writing before we share anything.
What we’re responsible for
We’re responsible for delivering the work we agreed to, in the formats we agreed to, and for showing our reasoning so your team can build from it. We’ll document flows, states, edge cases, and handoff notes, and we’ll do a handoff walkthrough with your PM and engineers so build questions get answered.
We are not responsible for engineering implementation, app store approvals, security testing, performance, analytics accuracy, or legal compliance, because those depend on how the product is built and operated. We also cannot be responsible for issues caused by changes made after handoff by others. If something we delivered is unclear or inconsistent, tell us promptly and we’ll work with you to resolve it within the agreed scope.
Ending the project
Either of us can end the project if it’s no longer workable. We’ll agree the notice period with you in writing, and we’ll use that time to close out work in progress in a tidy way instead of stopping mid-stream.
If the project ends, you pay for the work completed up to the end date, including any committed time and any approved changes already in progress. Once your account is up to date, we’ll hand over what has been completed so far in its current state, along with any relevant notes needed for your team to continue. If the booking payment has been made, it holds the time we reserved and is not refundable once work has started.
Signature
