Web Design Process: Brief to Launch

A good web design process turns a business goal into a website that people can understand, use and measure. It is not a straight hand-off from a brief to a designer, followed by a dramatic reveal. The strongest projects make important decisions in the right order, test assumptions before they become expensive to change and leave the business able to manage what has been built.

This guide explains the journey from the first conversation to launch and ongoing improvement. It is written for business owners and marketing teams commissioning a new website, so each stage includes the decisions, evidence and sign-offs you should expect.

What is a web design process?

A web design process is the structured sequence used to define, plan, design, build, test and launch a website. It connects commercial aims with user needs, content, visual design, technical delivery and measurement.

The stages often overlap. Content work can expose a missing page; prototype testing can change a user journey; development can reveal a constraint in an integration. The purpose of a process is not to prevent iteration. It is to make responsibilities and decisions visible so changes happen for a clear reason.

1. Define the commercial brief

Begin with what the website needs to change for the business. 'We need a modern website' describes an output, not an outcome. A useful brief explains the audience, current problem, priority services or products, commercial action and evidence that will show whether the project is working.

• Which customers should the website attract or support?
• What should a suitable visitor understand, feel or do?
• Which enquiries, bookings, purchases or applications matter most?
• What is failing on the current site?
• Which business systems, deadlines and approvals constrain the project?
• Who can make the final decision when opinions differ?

Record a small set of measurable launch and post-launch checks. These might include whether every form reaches the correct team, whether key actions are tracked and whether suitable enquiries can be distinguished from unsuitable ones. Do not promise a revenue result that the website alone cannot control.

Use our marketing agency brief guide to organise the starting information

2. Understand users and their real tasks

The project team needs more than a broad audience label. 'SME decision-makers' may include a founder comparing providers, a finance lead checking risk and an operations manager looking for implementation detail. Each arrives with different questions and a different level of urgency.

Use evidence already available: sales-call notes, search queries, customer-service questions, analytics, form submissions, on-site search and feedback from people who lost confidence or got stuck. Short conversations with real customers can reveal language and objections that internal teams overlook.

• What triggered the visit?
• What must the person know before taking the next step?
• Which proof reduces uncertainty?
• What could prevent them completing the task?
• What happens after the website action?

Turn those findings into priority journeys rather than fictional profiles with irrelevant detail. A journey should show the visitor's question, the information needed, the intended action and the business response.

3. Agree scope and information architecture

Scope defines what will be designed and built. Create a page inventory covering existing pages to keep, improve, merge, redirect or remove, alongside genuinely new pages. For each page, note its purpose, audience, owner, required content and primary next step.

Group information around how visitors think, not the organisation chart. Navigation labels should be clear enough to predict what follows. If several services have different evidence, processes or audiences, they may need separate pages; if they answer the same intent, splitting them can create repetition.

• Page list and navigation structure
• Required forms, calculators, booking tools or ecommerce functions
• CRM, email, payment and analytics integrations
• Content and asset responsibilities
• Languages, locations and accessibility requirements
• Redirects, domains, hosting and security responsibilities
• Explicit items outside the agreed scope

Approve the scope before detailed design. This creates a reliable basis for effort, dependencies and change control while still allowing discoveries to be discussed openly.

4. Plan and write the content

Design cannot solve missing content. Before polishing layouts, decide what each page needs to communicate and what proof supports it. Start with the priority pages and difficult messages, not the easiest company-history copy.

Write for a reader who does not share the team's internal language. Explain the offer, intended customer, process, evidence and next step. Replace unsupported superlatives with concrete facts the business can substantiate. Obtain permission for testimonials, client logos, photography and case-study details before they are treated as launch assets.

• Page objective and primary search or user intent
• Main heading and opening explanation
• Essential questions and objections
• Relevant evidence, examples or specifications
• Primary and secondary calls to action
• Images, video, downloads and ownership details
• Named reviewer and approval date

Content and design should then develop together. Real copy exposes whether a layout can handle a long service name, a complex comparison or important conditions without hiding them.

5. Wireframe the priority journeys

A wireframe is a low-detail plan for page structure and interaction. It shows the order of information, navigation, forms and calls to action before colour, photography and decorative choices dominate the discussion.

Wireframe the most important and unusual pages first. A homepage alone cannot prove that a service comparison, product filter, application form or booking journey will work. Test the complete path from entry page to confirmation and the follow-up the business must deliver.

• Can a new visitor explain the offer after the opening section?
• Does the order answer questions before asking for commitment?
• Is the primary action clear without removing useful alternatives?
• Can a keyboard or mobile user complete the journey?
• Does the confirmation step explain what happens next?

Sign off the journey and content hierarchy, not every pixel. Changes are still possible later, but the team should be aligned on how the page works before visual design begins.

6. Create the visual system and prototype

Visual design should make the content easier to understand and the brand easier to recognise. Establish typography, colour, spacing, imagery, icons, buttons, form states and reusable content components. Check contrast, focus indicators and readable text sizes as part of the system rather than as a final correction.

A prototype can demonstrate menus, transitions, responsive behaviour or a complex interaction before it is fully developed. Use it to resolve uncertain behaviour, not to simulate every page. Review designs at realistic mobile and desktop sizes with real content.

Feedback should refer to the agreed audience and task. 'Make it pop' gives the team no decision rule. 'The next step is hard to distinguish after the pricing comparison' identifies a problem that can be tested and fixed.

7. Develop, integrate and prepare the CMS

Development turns the approved system into responsive templates and working functions. The build should use appropriate semantic structure, reusable components and clear content-management controls. Editors need enough flexibility for routine updates without being able to accidentally dismantle the design system.

Connect forms, CRM records, payment or booking systems in a controlled environment. Define how errors are handled, where data is stored, who receives notifications and how a failed integration becomes visible. A success message is not proof that the enquiry reached the business.

• Responsive templates and navigation
• Content-management roles and editable fields
• Form validation, notifications and data routing
• Analytics and conversion-event specifications
• Consent controls and privacy information
• Redirect rules and canonical URLs
• Backups, security updates and recovery ownership

Load approved content before final testing. Placeholder copy and stock images conceal layout, accessibility and performance problems that appear only with the real material.

8. Test accessibility, performance, privacy and measurement

Quality assurance should cover the complete experience, not just whether pages look correct in one browser. Test common devices, browsers and screen sizes; keyboard navigation; forms and validation; links and downloads; error states; integrations; tracking; and the content itself.

The W3C Web Accessibility Initiative advises integrating accessibility throughout production and evaluating early and regularly. Automated checks are useful, but they do not replace keyboard testing, screen-reader checks where appropriate or feedback from people using different access methods.

W3C WAI: planning and managing web accessibility

Performance testing should include loading, responsiveness and visual stability. Google's Core Web Vitals use Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift to represent those aspects of real-user experience. Treat lab tools as diagnostic evidence and review field data after launch when enough real usage exists.

web.dev: Core Web Vitals

For a UK website, plan consent behaviour before adding analytics, advertising tags or embedded services. ICO guidance says non-essential cookies must not be set before the user gives appropriate consent, and people must receive clear information. The exact setup depends on the technologies and purposes involved, so record what is used and obtain appropriate advice where needed.

ICO: cookies and similar technologies guidance

• Submit test enquiries and verify receipt in every destination.
• Check tracking only fires on the intended completed action.
• Test consent choices and confirm non-essential tools respect them.
• Review titles, descriptions, headings, indexation rules and structured data.
• Crawl links, redirects and missing pages.
• Proofread names, prices, qualifications and contact details against approved sources.
• Record unresolved issues, owners and launch decisions.

9. Launch with a controlled handover

Choose a launch plan that names the person responsible for domains, hosting, deployment, DNS, redirects, tracking and final approval. Take a backup, freeze avoidable content changes and agree what would justify delaying or rolling back the release.

Immediately after launch, test priority pages and actions on the live domain. Confirm redirects, forms, integrations, analytics, consent controls, robots directives and canonical URLs. Ensure the XML sitemap reflects the live URLs and submit or monitor it through Google Search Console where appropriate.

Google Search Central: build and submit a sitemap

Handover should cover more than login credentials. The business needs an editable-area guide, training, ownership records, licence details, integration documentation, backup and recovery arrangements, maintenance responsibilities and a route for reporting faults.

How long should the web design process take?

There is no responsible universal duration. Timing depends on scope, content readiness, integrations, decision speed, accessibility requirements, migration complexity and the number of approval rounds. A small brochure site with prepared copy is a different project from a multilingual ecommerce platform or a service with several system integrations.

Ask for a plan built around dependencies and decision dates rather than a launch promise alone. Identify who supplies content, how long approvals take and which integrations rely on third parties. Keep a visible list of decisions and changes so delays are understood rather than hidden.

What should happen after launch?

Launch creates a usable baseline, not a finished source of truth. Review technical health, search visibility, user behaviour, conversion tracking and enquiry quality. Compare real questions and sales feedback with the assumptions made during planning.

• Check forms, bookings and payments routinely.
• Review Search Console and analytics for unexpected changes.
• Keep software, dependencies and security controls maintained.
• Add or improve content when customer questions reveal a gap.
• Test meaningful changes against a defined outcome.
• Revisit accessibility as content and components change.
• Document releases so performance can be interpreted accurately.

For a redesign, preserve and monitor valuable URLs rather than treating the new visual design as a clean slate. The migration work deserves its own plan.

Use our website redesign SEO checklist

Plan a website around the result it needs to create

A useful web design process makes the hidden work visible: research, prioritisation, content decisions, accessibility, integrations, testing, measurement and ownership. That clarity gives creative work a purpose and reduces the risk of discovering a fundamental problem just before launch.

The Digital Cogs plans, designs and develops websites and landing pages around clear commercial journeys. If you are replacing an underperforming site or preparing a new digital service, we can help define the scope, build the experience and put useful measurement in place.

Explore The Digital Cogs web design and development services

Discuss your website project with our team