Bring one complete customer attempt to the first conversation
“People have trouble with the French form” is a useful reason to investigate, but it leaves several different problems inside one sentence. The visitor might not understand a field, might be unable to correct an error, or might submit successfully and then receive no reliable confirmation. A first project conversation becomes much more productive when it follows one attempt far enough to distinguish those possibilities.
Use a fictional equipment supplier's request F-18 as an example. The French page describes an equipment inspection. The customer selects an item, enters a contact address and submits. A red message appears beside the equipment reference. The team initially asks for a new French website because it assumes the translation has discouraged customers.
Prepare evidence that can be shared safely
The project owner creates a synthetic request with a fictional contact and an equipment reference reserved for testing. They record the starting page, selected language, field labels, entered values and exact error. A screenshot includes the nearby label and explanatory sentence; an isolated red word is not enough to interpret the problem.
They also identify what they cannot establish. The browser message does not prove that a request was stored. The absence of an email does not prove the reverse. No one repeatedly submits a real customer request to manufacture evidence. If a controlled attempt is needed, the receiving environment and responsible person are agreed first.
Bring the relevant page and a short description of the normal staff task. The developer needs to know whether the reference identifies equipment already known to the supplier, a model the customer chooses, or a free-text description. Those are different input rules even if all three have been called “reference” in meetings.
Compare the instruction with the implemented rule
In F-18, the approved business instruction permits an equipment reference with a space between the family and serial number. The page shows the example MX 420. The validation accepts only the compact form MX420 and returns a generic French message asking the visitor to check the field.
The evidence now supports a precise question: should the business accept the spaced form and normalize it, or should the displayed instruction require the compact form? It does not support replacing the whole site or merely retranslating every page.
| Evidence | Observation | Decision it informs |
|---|---|---|
| Approved reference rule | Spaced and compact input identify the same fixture item | Business meaning of the input |
| Published example | MX 420 | What the visitor is encouraged to enter |
| Validation result | Spaced form rejected | Where the journey diverges |
| Stored test record | None for the rejected attempt | Boundary of the observed failure |
Resolve the rule with its owner
For this fictional supplier, the equipment-data owner confirms that spaces are presentation only for this reference family. The first release therefore accepts both approved forms, converts them to the agreed internal reference and explains genuinely unknown references separately. It does not strip punctuation from every other identifier in the system.
A second reference family includes meaningful separators. Its fixture remains unchanged and continues to use its own rule. That control prevents a convenient fix for MX 420 from silently corrupting a different kind of reference.
The French reviewer approves the field guidance and correction message together. The same business rule is checked in the English version; language differences must not create contradictory acceptance rules unless the business has deliberately defined them.
Agree what the first piece of work will prove
The bounded task is to align this field's instruction, validation and stored reference. Acceptance covers the spaced form, compact form, unknown reference, independent reference family and retained values after an error. In the approved test environment, the successful request reaches the ordinary staff view with the intended equipment identity.
The project owner can now ask for a useful estimate. The developer can identify access and dependencies. The reviewer can judge a specific customer journey. Broader redesign may still be worthwhile, but it has its own reasons and scope.
Bring a similar evidence trail to the project conversation. If the receiving record is already wrong despite a correct form, the next investigation may belong to business integrations instead of page design.