Choose a journey, then name the test conditions
Imagine a Budapest furniture workshop preparing a Hungarian and German website. A visitor opens a project page, looks at a fitted kitchen and requests a consultation. Review that whole sequence with the owner and developer. The homepage alone cannot show whether the project gallery or enquiry form is ready.
Use a representative phone and a slower connection alongside the office laptop. Record the page, language, device and connection with each observation. Keep these conditions consistent when comparing revisions, and distinguish a first visit from a repeat visit.
Ask three separate performance questions
Google’s Web Vitals guidance distinguishes loading, responsiveness and visual stability through LCP, INP and CLS. Use those categories to organize the discussion.
Can the visitor understand the project while the page opens? Does the menu respond when tapped? Does the consultation button move while they reach for it? Ask the developer to connect each reported problem to something the visitor can see. A score should lead to an explanation and a proposed fix, rather than becoming the entire acceptance decision.
Give the main photograph a clear job
For the workshop, one useful kitchen photograph may explain the service better than an opening carousel. Agree which details must remain visible on a small screen before choosing the crop. Ask for a comparison that preserves material texture and readable captions while reducing unnecessary image weight.
Google’s LCP guide advises against lazy-loading the LCP image. Confirm which image fills that role before applying a blanket image-loading rule. Keep any additional project views because they help a customer decide, and give the content editor a repeatable image-preparation process.
Make the enquiry usable during the review
Tap through the menu, gallery and enquiry form while the page is still settling. Enter a longer message, correct an invalid field and return from another tab. Check whether the interface explains what happened after submission. Ask someone outside the project team to repeat the task without coaching.
If an embedded tool complicates the journey, compare keeping it with a simpler contact route. Preserve information the sales team genuinely needs. Removing useful instructions just to make the page smaller would be a poor trade.
Include the content people will actually publish
Repeat the review with the German project description, a long caption and the real image selection. Let the person who maintains the site make one routine content change, then repeat the customer task. This reveals whether the handover instructions are usable. Decide who checks new galleries and translated pages after launch, rather than leaving performance as an unnamed technical responsibility.
Finish with a short acceptance record
Keep a shared record of the remaining problems, their owners and the evidence needed to close them. Review a specific revision together. Save the tested page addresses so a later campaign or design change can be compared with the same customer journey.
- List the pages and languages included in the review, with device and connection conditions.
- Record a visible symptom for each issue and the person responsible for resolving it.
- Retest the complete enquiry after image or interface changes, including correction and confirmation.
- Agree who repeats the checks after content updates and when the next review happens.