01 / THE DETAIL
Protect the business facts
We begin with approved services, coverage, contact details and claims. Existing URLs, call routing and useful content are recorded before a redesign. Your team identifies what is current and what should change. Missing project permissions, credentials or prices stay out of the public copy until the underlying facts and publication scope are settled.
02 / THE DETAIL
Design around real decisions
A sliding door repair inquiry may need symptoms and photographs; a planned roof replacement may need an estimate route. We use those distinctions to plan navigation, service explanations and contact prompts. Layout, typography and imagery support that structure. A distinctive brand needs its own composition, rather than a copied page with another colour applied.
03 / THE DETAIL
Build for ordinary devices
Pages receive responsive layouts, readable text, meaningful headings and keyboard-accessible controls. Relevant images use suitable formats and dimensions. Essential navigation and contact information should remain usable when optional effects fail. Illustrations are identified as illustrations; genuine project photographs need permission and accurate context. We do not manufacture customer proof to fill a section.
04 / THE DETAIL
Release the working contact journey
The release record covers desktop and mobile behaviour, approved call destinations, page metadata and redirects where needed. A form requires a real receiving setup and an actual receipt check. Error handling is tested too. A polished confirmation screen alone is insufficient. Any pending dependency is written down before the site is described as ready for inquiries.
USEFUL QUESTIONS
BEFORE YOU START.
Can useful parts of our existing site remain?
Yes. We assess existing content, URLs and contact paths before deciding what to retain. A redesign should preserve useful work and account for URL changes. Rebuilding everything is not an automatic requirement, and unchanged search performance cannot be guaranteed during a migration.
Who approves the service descriptions?
Your business approves operational facts and technical service explanations. We can organise the information and write clearly, but we should not invent what your team repairs, where it travels or which credentials it holds. Approval responsibilities are established in the brief.
What happens after launch?
The handover identifies the published pages, contact setup and known dependencies. Maintenance and future changes need an agreed scope and owner. Testing confirms release behaviour at a stated time; it does not mean forms, integrations or business information can remain unchecked indefinitely.