How to Choose a Web Designer in the UK

List the services, audiences and actions the website must support, then identify forms, booking or commerce functions. Explain who supplies text and images. Ask each designer to price the same brief so the comparison is about a usable website rather than an unspecified number of pages.

Confirm domain ownership, hosting access, maintenance and what you can edit yourself. Check revision allowances and how content is exported if you leave. Review relevant live examples on a phone and test their contact journeys alongside the visual design.

Describe the customer who will use the site and the decision they need to make. For a hypothetical furniture-restoration workshop, that might be understanding which repairs can be assessed and sending suitable photographs for an initial enquiry. The site should explain that an assessment is required rather than implying that every photographed item can receive an immediate fixed quotation.

Write the journey in ordinary language: discover the service, understand the limits, prepare the information and contact the workshop. Use it to judge proposals. A designer may suggest a different page structure, but should explain how it supports those steps. This worked example is a planning method, not an account of a JASOTO client project or a promise of more enquiries.

Prepare a page list, the main functions and the information available for each. Include service pages, contact arrangements and any genuinely needed booking, shop or language features. Say who will write the copy, provide photographs and approve factual details. List existing URLs that must keep working. A short, specific brief is more useful than asking several suppliers to quote for an undefined modern website.

Invite questions and record the answers in the shared brief. If one designer spots a missing dependency, give the same clarification to the others. Keep optional additions separate so you can see their effect on the work and price. An inexpensive proposal may cover a smaller task; an elaborate presentation may assume content and integrations that your business cannot yet supply.

Ask for examples relevant to your intended journey and clarify what the designer actually contributed. They may have designed the interface while another team wrote the content or built the booking function. Open an example on a phone and try to find the service information, understand the next step and use a normal contact route. Keep notes on observable behaviour.

Do not submit fake customer enquiries to another business as part of your comparison. A supplier can demonstrate a test environment or explain a journey without creating work for an unrelated owner. Ask what was checked before launch and how issues were resolved. A visually appealing portfolio image cannot establish whether the live site is accessible, maintainable or suitable for your particular customers.

Make a content inventory before accepting a page count. For the restoration workshop, the useful material may include the assessment process, genuine examples of suitable work and limits on what photographs can establish. Identify the source and approver for each item. Keep customer permissions and image rights with the relevant records rather than assuming that an image found online is available to reuse.

Ask how old content will be reviewed and moved. Preserve useful explanations and established links unless there is an evidenced reason to change them. If a supplier proposes a large blog package, ask which unanswered questions it covers and whether existing pages could answer them better. Distinct photographs need an accurate context; a stock picture should not be presented as proof of your own completed work.

Include practical accessibility checks in the project discussion. Ask about page titles, headings, useful image alternatives, visible keyboard focus and clear form labels. Try the important journey using the keyboard and enlarged text as well as your usual phone. Record an issue in terms of the step it prevents a visitor completing so the supplier can reproduce the problem.

W3C WAI explains that its Easy Checks provide an initial review and do not establish comprehensive accessibility. Use that distinction when a proposal mentions an automated score or a quick checklist. Ask what assessment is included, which people will test the journey and how unresolved issues will be documented. Seek an appropriately scoped specialist review where the project requires more than the initial checks.

Describe what a visitor needs to send and what happens afterwards. The workshop might request a description and suitable photographs, while explaining that an enquiry is not a confirmed booking. Agree the success message and where the staff record arrives. Decide who will notice an undelivered message and how the business can test the route without using real customer information.

Ask the designer to show missing-field messages, an unsuitable attachment and a temporary failure. A form that looks complete in a screenshot may still leave a visitor uncertain about whether it worked. Review labels and instructions before adding more required fields. Collect the information the actual enquiry process needs and ask the responsible person to assess any proposed collection, storage or third-party handling.

For an existing site, list important addresses and the pages that should replace them if a move is necessary. Ask for an explicit redirect plan rather than expecting search engines or customers to guess the new location. Check ordinary navigation links and the public sitemap against the final pages. Retain a copy of the old content and URL list for comparison after launch.

Ask who will review canonical URLs, indexing controls and the accessibility of the final public content. These decisions should match the actual domains and languages being used. Do not accept a blanket promise that launching a redesigned site improves rankings. Google describes useful original content and clear technical foundations as relevant to search discovery, while giving no ideal page length or special markup requirement for generative AI search.

Turn a proposal about AI visibility into named deliverables. Examples include making the public service explanation readable, keeping business details consistent and checking that the sitemap lists the intended canonical pages. Ask whether proposed structured data describes facts visible to the visitor. An article or business schema label should not introduce an invented rating, service or office.

Agree how results will be reported. Microsoft says Bing AI Performance measures observed citations without establishing a page ranking or placement inside an answer. That is different from a visit, a submitted enquiry or work accepted by your business. Keep those measures separate and record their dates. A designer should explain the implementation they can verify and identify outcomes that depend on external search systems.

Prepare the approved business name, contact route, opening arrangements and real service area before the designer creates profile text. Make someone responsible for changes when those facts move. Compare the website with the business listings you actually manage, including JASOTO where relevant. Publishing a new website does not automatically correct a separate business profile or verify its ownership.

Google Business Profile guidelines emphasise accurate real-world representation. Use the correct rules for each publishing service and distinguish a customer-facing address from a service area. Ask the designer to avoid generating many location claims from a template without evidence that the business serves those places. A useful local page answers a real visitor question using facts the owner can confirm.

Keep the scope beside each price. Record design, implementation, writing, migration, testing and training as applicable, then identify which subscriptions or ongoing services are separate. Ask how changes outside the brief will be estimated and approved. This guide does not give a universal web-design price because different proposals may include substantially different work and continuing obligations.

Discuss maintenance in practical terms. Who updates service information, investigates a broken form and checks that an integration still works? Ask which tasks your own team can perform and what training is provided. Review the actual renewal, notice and handover terms before agreeing them, obtaining appropriate advice where needed. A low launch charge alone does not describe the cost of keeping the site useful.

List the domain, hosting, website administration and connected services involved in the project. Identify the business owner for each and the role the supplier needs. Use supported account invitations where available and retain business ownership with the appropriate people. The supplier should explain its access requirements without requiring the business to lose visibility of its own systems.

Ask what you receive at handover: approved content, usable image files and rights records, a change log, routine instructions and the agreed export or transfer materials. Confirm what can be moved if you change suppliers. Arrange a named contact and an access-removal process at the end of the engagement. Keep those details in the business records rather than relying on a former staff member to remember them.

Review the version that is actually due to launch. Use the agreed customer journey, the content inventory and the old URL list as acceptance checks. Confirm contact links, visible business facts, photographs and key pages on a phone. Ask for evidence tied to that version, including unresolved limitations. An earlier mock-up is not proof that the completed enquiry route works.

Plan a way to restore service if the launch introduces a serious problem. Record who can revert the release or correct the affected page and which checks follow. After launch, repeat the important journey on the public domain and review actual enquiries with the business team. Use that evidence to improve the site, while avoiding claims that every change in traffic was caused by the design work.

Include the rights and context of each published photograph in the content review. A licensed archival image can illustrate a subject without representing the business premises or completed work. Check that its caption, alternative text and credit remain understandable on the final page. Keep the source and licence with the handover records so a later editor knows what can be changed.

If the site uses translations, identify who can check their meaning and maintain them after a service change. Test language links against the corresponding content rather than sending every visitor to an unrelated homepage. Ask the designer to document any languages or pages outside the agreed scope, so an incomplete translation is not mistaken for an approved version.