A web design and development agency should turn business goals,
audience needs and technical constraints into a website your team can
run with confidence.

That means more than supplying attractive page designs. A complete
service covers discovery, information architecture, content, interaction
design, a suitable content management system, dependable development,
accessibility, performance, testing, launch and handover.

The best-fit agency is the one that can explain its decisions, show
its evidence and leave clear ownership behind.

When an agency is the right
fit

An agency or multi-skilled delivery team is useful when the project
crosses several disciplines. Typical examples include:

  • a new website that must support several audiences or services;
  • a redesign with established search traffic and URLs to protect;
  • a content-heavy site that needs a new publishing model;
  • ecommerce, membership, booking or account functionality;
  • integration with CRM, analytics, recruitment or operational
    systems;
  • accessibility and performance requirements across many
    templates;
  • several stakeholders who need a controlled decision process;
  • a launch that requires migration, training and continued
    support.

A small brochure site with clear content and standard functions may
not need a large agency structure. A focused designer-developer can be
faster and simpler. The delivery model should match the work, not the
provider’s preferred team shape.

What the service should
include

Discovery and measurable
goals

Discovery establishes what the website must help people do and what
the organisation must be able to manage.

Useful inputs include customer questions, analytics, search demand,
sales and support evidence, content performance, technical constraints
and interviews with the people who operate the current site. The output
should separate facts, assumptions and open questions.

Goals need observable measures. “Modernise the brand” is
directionally useful but difficult to accept. “Help prospective clients
find the right service, see relevant evidence and make a qualified
enquiry” can be mapped to pages, journeys and analytics.

Information architecture
and content

Information architecture defines the pages, relationships, labels and
navigation that help users find their way. It should be based on
audience tasks and content ownership, not the organisation chart.

Before page design, the team should create:

  • a content and URL inventory;
  • audience and task priorities;
  • a proposed sitemap;
  • page-purpose and ownership decisions;
  • navigation and cross-linking rules;
  • content migration, rewrite and deletion actions;
  • redirects for any URL changes.

Content is a delivery dependency. Placeholder copy conceals layout
problems and delays decisions about evidence, calls to action and
editorial effort.

Site hierarchy becoming organised content cards and reusable interface components before resolving into a page design
A coherent site starts with an information structure and
component system that make the essential customer journeys easy to
follow.

UX and visual design

Design should show how real content and interactions work across
screen sizes and input methods. It includes hierarchy, spacing,
typography, components, form behaviour, errors, focus states and
responsive rules.

Accessibility belongs in this stage. The W3C
introduction to web accessibility explains that accessible websites
allow people with disabilities to perceive, understand, move through and
interact with the web. A visual review alone cannot establish that.

A useful design review asks:

  • Can people recognise the page’s purpose quickly?
  • Is the next action clear without removing meaningful choice?
  • Does the layout survive long headings, errors and missing
    images?
  • Can all controls be used by keyboard?
  • Is focus visible and ordered sensibly?
  • Are form labels, instructions and errors explicit?
  • Does the mobile version preserve essential content and actions?

CMS and editing model

The CMS should fit the people who publish, the content relationships
and the expected support model.

Agree page types, reusable components, editor permissions, preview
and approval workflow, scheduled publishing, media handling and
governance. Give editors enough flexibility to do their work without
allowing routine changes to break layout or meaning.

Ask the agency to demonstrate common tasks with a realistic editor
account. Creating a page, replacing a document, updating navigation and
correcting a form message reveal more than a feature list.

Development and integrations

Development turns the agreed system into reusable, testable
components. It should follow documented conventions, protect secrets,
validate input and keep custom behaviour understandable to the next
developer.

Every integration needs a source of truth, field mapping,
authentication method, error behaviour, logging, recovery path and
owner. One successful request is not enough evidence for production
readiness.

Performance and technical
quality

Performance budgets should reflect the site’s users, content and
commercial priorities. Test representative pages with realistic images,
fonts, scripts, consent tools and third-party services.

The Core Web Vitals
guidance identifies loading, interaction and visual stability
measures, but no single lab score proves the whole experience. Combine
repeatable lab tests with field data when sufficient real-user traffic
exists.

Technical QA should also check semantic HTML, metadata, crawl
controls, structured data where relevant, forms, security headers,
browser behaviour and error pages.

Website release moving through responsive, performance, accessibility and handover quality gates
The design is only ready to launch when the same experience holds
across devices, performance conditions, accessibility needs and the
handover process.

A dependable delivery
process

1. Agree scope and governance

Name the decision-maker, working team, reviewers and owners of
content, integrations and legal checks. Define outcomes, exclusions,
acceptance criteria and the change process.

2. Audit and plan

Review the existing site, evidence and systems. Produce the sitemap,
content plan, technical approach, migration needs, measurement plan and
risk register.

3. Prototype key journeys

Test structure and interaction with representative content before
polishing every screen. Prioritise the journeys with the greatest user
value or delivery uncertainty.

4. Design the system

Create the reusable components, responsive behaviour, content rules
and documented states that form the website. Review accessibility and
editorial use alongside appearance.

5. Build and integrate

Develop in controlled increments, using realistic data. Demonstrate
completed journeys rather than isolated pages and record decisions that
affect future support.

6. Test and prepare launch

QA should cover content, devices, browsers, keyboard and
screen-reader use, forms, performance, analytics, integrations and
redirects. Prioritise defects by impact and evidence.

7. Launch, verify and hand
over

Use a launch runbook with backups, responsibilities, verification and
rollback decisions. If URLs change, follow a mapped redirect and
monitoring process; Google’s
site-move guidance is a primary reference for search-related
migration work.

Handover should include source and account ownership, deployment
instructions, CMS training, component guidance, support boundaries and
unresolved work.

A realistic project example

Consider a professional-services business with several overlapping
service pages. Visitors struggle to understand which offer fits, while
the marketing team duplicates content because page ownership is
unclear.

The project could begin with search, analytics and enquiry evidence,
then assign one purpose to each service page. A prototype would test the
new navigation and one complete enquiry journey. Development would
provide controlled service, insight and case-study templates, while the
migration plan maps each existing URL to a retained, merged or
redirected destination.

Proof would include the owner map, usability findings, redirect
tests, analytics validation and monitored live behaviour. Any claim
about leads or search visibility would require verified baseline and
post-launch data.

Cost drivers and
dependencies

Cost depends on the number and complexity of templates, content
readiness, bespoke interactions, integrations, migration volume,
accessibility work, performance constraints, stakeholder process and
depth of testing.

The schedule depends on access, content decisions, feedback,
third-party systems and approvals. A credible proposal states these
dependencies and shows decision points rather than promising an exact
outcome before discovery.

Common mistakes

  • Starting visual design before page purposes and content are
    agreed.
  • Selecting a CMS because the agency prefers it.
  • Reviewing only ideal desktop screens.
  • Treating accessibility and performance as pre-launch tests.
  • Rebuilding every weak page instead of consolidating it.
  • Changing URLs without a redirect and monitoring plan.
  • Adding third-party tools without an owner or failure process.
  • Launching before analytics and enquiry routes are verified.
  • Leaving accounts, source code or documentation under supplier-only
    control.

Questions to ask an agency

  1. What evidence will shape the sitemap and page priorities?
  2. Who owns content strategy, writing and migration?
  3. How will you choose and configure the CMS?
  4. Which accessibility checks are manual?
  5. How will performance be tested with production-like content?
  6. What is the approach to URLs, redirects and search monitoring?
  7. How are integrations tested when they fail?
  8. What will our team own at handover?
  9. Which support and maintenance work is excluded?
  10. How will disagreements or scope changes be resolved?

Next step

Prepare your business goals, priority audiences, current sitemap,
analytics access, known problems, content owners, integrations and
launch constraints. That is enough for a useful first review.

I can help turn that evidence into a focused web design and
development brief. Review
selected work or start
a conversation.

Frequently asked questions

What
is the difference between web design and web development?

Design defines structure, content presentation, interaction and
visual rules. Development implements that system in code and connects it
to the CMS and other services. Strong delivery keeps both disciplines
involved in shared decisions.

Should
one agency handle strategy, design and development?

It can reduce handoff risk, but only if the team has genuine
capability in each area. A specialist partnership can work equally well
when ownership, deliverables and decision rights are clear.

How do I compare agency
proposals?

Compare assumptions, scope boundaries, evidence, acceptance tests,
named responsibilities, dependencies, ownership and support. A lower
headline price may exclude content, migration, accessibility, analytics
or post-launch verification.

Can a redesign keep our
current CMS?

Yes. If the CMS remains secure, supportable and suitable for editors,
retaining it may reduce migration risk. Audit the current implementation
before deciding.

What should happen after
launch?

Verify live journeys and data, monitor faults and search behaviour,
train owners, resolve launch issues and review evidence against the
original goals. Improvement should continue through a prioritised
backlog.