Before you rebuild your website, test five customer journeys
Turn a vague website redesign brief into five practical tests: finding a service, comparing options, checking credibility, making contact, and coming back.
Areza Digital
“The website feels dated” is a reasonable observation. It is a difficult brief to build from.
It does not tell you whether customers understand the offer, whether the enquiry form works on a phone, or whether the team can keep the content current. A new layout might help. It might also leave the expensive problems untouched.
Before planning the rebuild, test five journeys a customer might actually take. The result should be a short list of observed problems and clear requirements for fixing them.
1. Arrive on a service page without seeing the homepage
A visitor may arrive through a search result, a recommendation, or a link in an email. Start your test on a specific service page rather than assuming everyone enters through the homepage.
Give the person a plausible situation: “Your company needs a website that the team can update. Someone sent you this page. Decide whether it is relevant.” Then let them explore.
Ask what the company offers, who the service is for, and what they would do next. Listen for their own explanation. Repeating the headline is not the same as understanding the offer.
If they cannot explain it, inspect the page’s first useful information. Does the heading name the service? Does the supporting text describe a recognisable job? Are important limits buried further down? A vague sentence in a large typeface is still vague.
A useful requirement: a new visitor can identify the service, recognise whether it fits their situation, and find the next step without returning to the homepage.
2. Compare options and understand what is included
Choosing a supplier often involves a more practical question than “Do I like this design?” A customer wants to know what they are buying and where one responsibility ends and another begins.
Ask the tester to compare two relevant services or packages. For a website project, have them find out whether copywriting, content entry, hosting, and maintenance are included. If prices depend on scope, can they understand what changes the estimate?
Watch for answers assembled from guesses. The team may know that “website design” excludes development, but a customer may reasonably read it as a complete website.
Use the gaps to improve the offer, not just the page layout. Name the deliverables, the inputs you need, and the decisions that affect timing. Where there is no fixed price, explain how a quote is prepared rather than inventing a reassuring starting figure.
A useful requirement: the visitor can describe the scope and identify what still needs to be agreed before work begins.
3. Check whether the evidence supports the claim
Ask someone to find a reason to trust the company with their particular project. Do not point them towards the testimonials or explain a case study while they read it.
Look at what they use as evidence. Can they tell what the team actually made? Is a project relevant to their problem? If a result is stated, is its context clear enough to understand?
An attractive screenshot shows appearance. It does not explain the brief, the team’s contribution, or what changed after launch. A useful project description can be short: the starting problem, the work delivered, and a result you can support. If you do not have measured outcomes, describe the verified deliverable instead.
Small studios do not need to imitate a large agency’s client wall. A specific explanation of who does the work and how feedback happens may answer questions that a row of unfamiliar logos cannot.
A useful requirement: the visitor can find relevant, accurate evidence and distinguish completed work from illustrative concepts.
4. Make contact on a phone, including correcting a mistake
Use a real phone for this journey. Open the form, enter a realistic message using test details, correct an invalid field, and complete the submission. Also check that the form can be reached and used with a keyboard.
Are labels still visible after typing? Is it clear which fields are optional? Can the person correct one error without losing the rest of their message? Labels should describe each control and be associated with it in the page markup, as explained in W3C’s form-label guidance.
Then follow the enquiry beyond the browser. Check that it reached the intended system and person. A form can be pleasant to use while delivering nothing useful to the team. Our guide to website enquiry handovers covers that part in detail.
Be precise about the confirmation. The visitor should know whether the message was received and what happens next, without having to guess whether another click is required. W3C’s notification guidance covers clear success and error feedback.
A useful requirement: someone can submit and correct an enquiry on their device, understand the result, and reach the right person behind the website.
5. Come back through an old link or another language
The first visit is only one route. Test a saved link to an old service, a bookmark to a deeper page, and a return from the contact form using the back button.
If the site supports more than one language, switch while reading a specific service. Does the visitor stay with the equivalent content, or land on a homepage and have to find it again? Read the translated content too. A working language control does not prove that the page makes sense in that language.
For a planned rebuild, collect important old URLs before changing the structure. Decide which have a meaningful replacement and which should lead to a clear not-found page. Sending every removed page to the homepage makes it harder to tell what happened. Our website migration guide goes into the wider migration checks.
A useful requirement: returning visitors can reach the content they expected, or understand that it has gone and find a relevant way forward.
Watch performance during the journey
While someone tries these tasks, note slow main content, delayed responses to taps, and elements that move while they are reading. Run a technical check alongside those observations.
The good Core Web Vitals thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds, and CLS at most 0.1, assessed at the 75th percentile of visits. Field measurements matter; a single lab run does not describe every customer’s experience. Google’s Core Web Vitals guide explains the measures and the difference between lab and field data.
Treat the numbers as evidence about usability, not a forecast of revenue. A fast page can still describe the wrong thing.
Turn observations into a brief someone can use
Test with people who are unfamiliar with the site but understand the kind of purchase involved. Give them a task, stay quiet while they work, and record what happened. A small qualitative check helps find problems; it does not establish how often the whole customer base experiences them.
Use a compact worksheet:
Swipe or scroll to compare.
| Journey | Observation | Change to investigate | Acceptance check |
|---|---|---|---|
| Compare services | The tester assumed maintenance was included | State what happens after launch | A fresh tester can identify the maintenance arrangement |
| Make contact | Correcting an email cleared the message | Preserve valid fields after an error | The original message remains after correction |
| Return in another language | Switching language opened the homepage | Link equivalent service pages | The same service stays open in the chosen language |
These are example findings, not claims about your website. Record your own evidence and assign an owner to each change.
Prioritise tasks people cannot finish, then tasks they complete only with help. Cosmetic refinements can follow. This gives the redesign a purpose you can check when the work is ready.
If you are considering a website rebuild, bring the pages and journeys that are causing trouble. We can help turn them into a workable brief, then design and build around what needs to change. Talk to us about your website.