AI suggests a website change: how do you decide whether to do it?

Before acting on an artificial intelligence (AI) suggestion, compare the relevant page with your current service information. Decide which parts to adopt and what still needs checking. Then give the person implementing the change the agreed wording and a clear way to check the work. Verify the implementation separately from any later increase in enquiries.

Here is a fictional example involving a company that maintains refrigeration systems in warehouses. The company, people, form, documents, AI suggestion, replacement wording and test procedure are invented for this explanation. They do not describe Supasaito, a real client or an observed response from a particular model.

The company’s form asks for a name, email address and message. Enquiries go to a shared inbox used by the sales team. Its marketing coordinator receives an AI suggestion about the form and works through it with the service owner and developer.

1. Read the suggestion beside the current form

The coordinator opens the form and compares it with the suggestion. The current wording is:

Heading: Request a service visit.
Fields: Name, Email address, Message.
Text shown inside the empty message field: Write here.

The coordinator also has this fictional sales note:

To assess a request, we need the type of system and the maintenance required. Sometimes we ask for these details after the first message.

The constructed AI suggestion says:

Explain which details to enter and add “Receive a reply within 24 hours”: the form will generate more enquiries.

The coordinator notices that the message-field instruction does not ask for the system and maintenance details sales needs. That gives them a concrete reason to consider clearer instructions.

The sales note does not, however, establish how many more enquiries the form could produce or whether anyone abandoned it. Nor does the supplied material confirm that the company can reply within 24 hours.

Before choosing the wording, the coordinator asks the service owner: “What enquiries does this form accept? Does submitting it book a visit, or does the team first need to assess the request?”

2. Use the service owner’s answer to prepare replacement wording

The service owner confirms the following information. This document is also fictional:

The form collects enquiries about planned maintenance. The team checks whether it can help and follows up by email. Submission does not book a visit. We have not confirmed a response time to promise on the website.

The coordinator reads this beside the AI suggestion. Because the form collects a planned-maintenance enquiry, they decide to make its heading describe that step more precisely. This is a decision to match the service information, not a measured finding that readers misunderstood the old heading.

The message field will explain which system and maintenance details help sales assess the request. The Name and Email address fields stay in place. The coordinator leaves out the 24-hour promise because the service owner has not confirmed it.

W3C’s Form Instructions tutorial recommends explaining relevant information and how to enter it. It also advises against using text inside an empty field as a replacement for a label. Taking that guidance into account, the coordinator keeps a field label and puts the instruction beside the message field.

The coordinator drafts this replacement for the service owner to review:

Heading: Ask about planned maintenance.
Fields retained: Name, Email address.
Message-field label: Describe your request.
Adjacent instruction: Tell us the type of system and the maintenance you need. If you do not know the model, describe what you know.
Before submission: The team will review your request and follow up by email to check whether it can help. Submitting this form does not book a visit.

The coordinator has rewritten the suggestion using the confirmed service information. They have not accepted it unchanged. The model remains optional, and no required field or response-time commitment has been added.

The service owner reviews whether this describes the accepted enquiries and follow-up correctly. If the next step after submission were still undecided, the coordinator would need that answer before describing it. Here, that part is confirmed, so they can prepare an implementation request.

For the related work of selecting company material and assembling a writing assignment, see our guide to preparing AI to write about your company.

3. Give the developer the agreed change and checks

After the service owner’s review, the coordinator approves the wording and places the current form text, replacement and service information in one work request. It records the decisions they have just made:

• Keep: the Name and Email address fields.
• Change: the heading, message-field label, adjacent instruction and pre-submission explanation, using the reviewed wording above.
• Leave out: any promise of a booked visit or a reply within 24 hours.
• Show first: a preview page with the changes, so the coordinator can compare it with the wording they approved.

The developer can now identify what changes and what stays. The coordinator also has something specific to check, rather than a general request to “improve the form”.

Next, the coordinator checks with the developer and sales team whether they can send a test from the preview and which inbox will receive it. They agree to use a test name and an email address the company controls. The message will begin “TEST: form submission check. This is not a service request.” Sales knows which message to look for and can distinguish it from a real enquiry.

At this point, the developer is preparing a preview of the approved wording. The coordinator will ask for publication after the display and submission checks below have also been completed.

4. Check the page and the received message, then record the result

When the preview is ready, the coordinator opens it beside the approved text. They compare the heading, label, message-field instruction and pre-submission explanation. They also check that no booking or 24-hour promise has appeared elsewhere on the page.

The coordinator then opens the page on a phone. They read the whole instruction about the system and maintenance details, followed by the explanation that submission does not book a visit. They check that none of that text is cut off. After entering text, they check that they can still identify the Name, Email address and message fields. If text is missing or a field becomes unclear, they show that screen to the developer and request a correction.

For the submission check, the coordinator enters the agreed test information. If the page shows a success message, they record that result. They then ask sales to open the shared inbox and find the message beginning “TEST: form submission check”. Sales checks that the test name, reply email address and message arrived. Only then can the coordinator also record receipt.

The coordinator also asks the developer to demonstrate the form’s error feedback. For example, if an email entry is rejected, can the person tell which field needs correcting and what to do? W3C’s form-notification guidance recommends communicating submission outcomes and helping people correct errors.

If sales has not confirmed arrival, the work request should say: “Success message checked on the page; arrival in the sales inbox remains unverified.” What appeared on the screen and what sales received are separate observations.

The coordinator specifies these checks in the work request before implementation. They define what must be true before the requested work can be considered complete: the approved wording is displayed, and the agreed display and submission checks have passed. These are the assignment’s acceptance criteria. They do not amount to a complete accessibility assessment.

Once those checks are complete, the coordinator asks the developer to publish the change. After publication, they open the actual page again, compare it with the approved wording and leave its reference and the check results in the same request.

Even then, the coordinator cannot report that the new wording caused more enquiries. If they want to investigate a later effect, they first decide what to examine. For example: did the enquiries sales received contain the system and maintenance details, and did sales need to ask for those details again? GOV.UK’s guide to designing with data similarly recommends identifying the action, expected impact and measurement when forming a hypothesis.

The coordinator and sales can agree a period and counting rule, then retain the enquiries and whether further clarification was needed. A complete enquiry, a suitable sales opportunity and a customer are different outcomes. Our article on AI mentions and customers explains why these stages need different records.

To establish that the wording caused a result, they would also need evidence that distinguishes its contribution from other explanations. The Cabinet Office’s testing and iteration guidance discusses planning comparison evidence when assessing impact. The coordinator can close the implementation request after the agreed wording is live and the page and submission checks have passed. Whether sales receives more complete enquiries must be investigated separately.

In this case, the coordinator adopted the part of the AI suggestion that clarified the enquiry process and the information sales needs. They excluded the unconfirmed response-time commitment and enquiry-growth promise. Carrying that decision into the replacement text, work request, page checks and inbox check makes clear what was changed and what was verified.

FAQ

01 Do I need a numerical performance case before changing anything?

In this example, the coordinator can make the heading more specific using the service information the owner confirmed. That correction is separate from demonstrating enquiry growth. Without growth evidence, they do not report that increase as established.

02 Must the whole change wait if the response time is unknown?

Here, the coordinator can explain planned-maintenance enquiries and email follow-up without promising a response time. If the service’s actual enquiry process were unclear, they would continue checking with the service owner before describing it.

03 Does a success screen establish that the message was received?

In this example, sales opens the shared inbox and checks that the test name, email address and message arrived. If that check is unavailable, the coordinator records the screen feedback and unverified receipt separately.

04 Is deciding not to change the page a valid outcome?

Yes. If the coordinator compares the current page with the service information and finds it already accurate and sufficiently explained, they can leave it as it is. They record what they checked and why they declined the suggestion in the work request or decision note.