Our Web Design Process: From Brief to Launch
Good websites are easier to build when the important decisions happen in the right order. Our process moves from business context and structure to design, development, testing and launch so the interface is built around a clear purpose rather than guesswork.
We need to understand what the website is supposed to change.
The first conversation is not about colours. We need enough context to understand the business, the website's audience and the reason the project exists.
That prevents a common problem: designing pages first and discovering the real requirements later.
Send Your Project Brief →What happens at every stage
Each stage has a job, an output and a clear reason for happening before the next one.
Understand the business before the website
We establish who the website is for, what it needs to communicate and which business actions matter most.
- Business and services
- Target audience
- Existing website where relevant
- Primary conversion goals
- Languages and markets
- Clearer project direction
- Initial requirements
- Priority user journeys
- Known constraints
- Questions that still need answers
Turn the brief into a defined project
We decide what belongs in the project, what does not and which parts need to be solved first.
- Required page types
- Core functionality
- CMS or commerce needs
- Project priorities
- Migration needs if redesigning
- Agreed scope
- Project boundaries
- Functional requirements
- Clear service path
- Basis for the build
Decide where the information belongs
Before visual design becomes detailed, we establish pages, navigation and the role of important content.
- Sitemap and page ownership
- Navigation hierarchy
- Content sections
- Internal links
- Conversion routes
- Website architecture
- Clear page hierarchy
- Defined content responsibilities
- SEO-ready structure
- Better basis for design
Translate structure into a visual system
Typography, spacing, cards, buttons, navigation and page hierarchy are designed as one system, not isolated screens.
- Visual hierarchy
- Responsive layouts
- Navigation patterns
- Buttons and interaction cues
- Reusable design components
- Consistent design direction
- Desktop and mobile behaviour
- Reusable UI system
- Clear interaction patterns
- Approved visual direction
Turn the approved system into the website
The front end, CMS, forms and required functionality are implemented around the approved structure and design.
- Responsive front end
- WordPress where appropriate
- Forms and core interactions
- Internal links
- Content implementation
- Functional website
- Responsive templates
- Manageable content areas
- Required interactions
- Launch-ready foundation
Review the website before real users do
We check the experience across important devices, pages and user actions before the website becomes the public version.
- Responsive layouts
- Navigation and links
- Forms and CTAs
- Important metadata
- Images and loading behaviour
- Reviewed live website
- Final content checks
- Launch essentials
- Redirect checks where required
- Post-launch review points
The process works faster when decisions have an owner.
You do not need to arrive with a finished sitemap, perfect copy or a technical specification. But we do need access to the business information and people required to make accurate decisions.
Tell Us About the Project →Feedback is most useful when it explains the problem.
Good feedback is not simply “make it bigger” or “I don't like this colour”. The useful question is what the design is failing to communicate or what a user may struggle to understand.
That keeps revisions connected to the project's goals instead of turning the process into random visual changes.
A website is not finished when the design looks finished
The public version needs functional, responsive and technical checks before launch.
Navigation, content, forms and CTAs are checked across relevant screen sizes.
Important navigation and contextual links are checked for correct destinations.
Enquiries, buttons and key user actions must work as intended.
Titles, descriptions, heading structure and crawlable links are reviewed.
Images, layout and front-end behaviour are checked for unnecessary weight.
Important text, contact details and launch-critical information receive a final pass.
The process adapts to the type of website
The stages stay consistent, but the decisions inside them change with the business.
Best Travel
The process centred on simplifying travel navigation, restructuring excursion presentation and rebuilding responsive page layouts.
View Live Website ↗BushPools
The challenge was organising a deep pool-service offering into a clear architecture without overwhelming the main navigation.
View Live Website ↗General Service House
The structure prioritised service categories, problem-specific pages and immediate telephone access for mobile visitors.
View Live Website ↗How long does a website project take?
There is no responsible single timeline for every website. A focused business website, a multilingual build, an eCommerce store and a complex redesign do not have the same scope. The project timeline is defined after the pages, content, functionality, approvals and migration requirements are understood.
The process stays clear. The scope changes.
Before we start, you may want to know...
Do I need to have all of the website content ready first?
Do you design the mobile version separately?
When do I review the website?
Can the project scope change after we start?
What happens if I already have a website?
Do you consider SEO during the build?
What happens after the website launches?
How do we start?
You do not need to know how the website should be built.
Tell us what the business needs. The process is there to turn that into the right website.
Start a Project →