Design Project Process: Stages, Reviews and Handover
TL;DR
In this guide
- Agree the work. Connect the business goal to deliverables, content and responsibilities.
- Review each stage. Approve the structure and design before judging the finished build.
- Plan the handover. Decide who edits the site and who handles ongoing care.
A design project process gives the client and design team a shared route from the initial conversation to usable work. For a website, that normally includes discovery, UX and visual design, development, then testing and refinement. The deliverables and approvals should reflect the agreed scope.
The guide at a glance
The stages and the decisions they support
01
Discovery and strategy
Agree the audience, business goal, page priorities, content and practical constraints.
02
UX, visual design and build
Review structure and the design direction in Figma, then build the approved work in WordPress.
03
Testing, review and handover
Check real content, mobile use and important journeys; make editing and care responsibilities clear.
Agree what each review is approving
A project moves more smoothly when an approval has a defined purpose. A structure review asks whether visitors can find the right information. A visual review asks whether hierarchy, typography, imagery and brand treatment support that structure. A development review asks whether the built pages and functions behave as expected.
The review should name the deliverable and its version. Agree what can still change at that stage and flag requirements that alter the original scope. A newly requested booking system, for example, needs a scope discussion rather than being treated as a small layout correction.
An example of a useful approval record
Illustrative example: A service business approves a five-page structure and an enquiry form. At the design review, the team records that the service hierarchy is approved, one photograph needs replacing and the form wording remains open. Development can use the approved structure while the open content items have a named owner.
A useful record might say: Deliverable: service-page design. Version: current Figma link. Decision: hierarchy approved. Open item: replace the customer quotation after permission is confirmed. Owner: client. Next review: revised page. This is an example of a record, not a promise of a particular project timetable.
Prepare for a usable handover
Ask what the finished work includes: editable page layouts, approved assets, access arrangements, instructions and any licences or accounts that the business must manage. Distinguish routine content editing from changes to shared templates or functionality.
For websites, keep launch approval separate from ongoing care. Updates, backups, content changes and future improvements need owners after the project closes. The exact support arrangement depends on the scope agreed for that site.
Put it into practice
Prepare for the next project stage
- A clear business goal and the audience the work must help
- An agreed list of pages, features or design deliverables
- Content and brand assets with their readiness recorded
- One person who consolidates feedback and confirms decisions
- A list of open items, owners and dependencies
- Editing, account ownership and ongoing-care questions
Keep in mind
Approve the decision, not just the screen
A page can look polished while the content or functionality is still undecided. State which part is approved so the next stage has a reliable starting point.
Common mistakes to avoid
- Approving placeholder copy as though it were final
- Reviewing an old version after the design has changed
- Adding a major feature without revisiting scope
- Leaving account ownership and editing questions until launch
