INTERFACE ACCEPTANCE · ENGLISH BUYER GUIDE
Accept the charging journey, not just the translated start screen
By Xiaochong Energy · · 6 min read
A buyer demonstration can show an attractive home screen without showing what a first-time driver sees after selecting a connector, waiting for authorization or encountering an unavailable output. Put the required languages and user journeys into the purchase scope, then collect evidence from the exact proposed configuration. A language menu is only the starting point.
This is a proposed procurement and usability-review method, not a claim that every model supports every interface feature. It is not electrical, accessibility, payment-network, cybersecurity or local-compliance approval. Qualified teams must confirm applicable requirements and model-specific procedures. Use authorised demonstration equipment and test accounts, not unscheduled experiments on a live public site.
1. Identify which system owns each instruction
List the charger screen, physical connector labels, any payment terminal, mobile application and site signage that a driver will encounter. For each, identify who supplies the wording, who translates it and who approves the final revision. Do not assume that the hardware supplier controls a third-party application's text or payment messages.
Record the charger model and firmware, screen-software revision, language-package version and connected backend or terminal configuration. Ask suppliers to identify any interface difference between the demonstration and the equipment being quoted. An edited sales video is not evidence that a particular software release contains the displayed workflow.
The W3C explanation of labels and instructions describes helping people understand the input expected by a control, without overwhelming them with unnecessary instructions. We use that as a general communication reference here. It is web guidance, not a charger-product certificate or a complete accessibility assessment.
2. Make a small language-and-state checklist
For every required language, ask for the states below on the intended configuration. Where a state is handled on another device, record that device and its owner. Mark unsupported states explicitly rather than accepting a blank cell as a pass.
| Journey stage | What the buyer should ask to see |
|---|---|
| Choose | The selected output and its relationship to the physical connector label, including an unavailable output. |
| Authorize | The supported access method, the action requested and the distinction between a pending and a completed request. |
| Wait or charge | The actual session state and any approved explanation of waiting, without displaying unsupported progress or invented completion times. |
| Stop and finish | The supported stop workflow and the model-approved completion and connector-handling instructions. |
| Get help | A readable support route and a station/output reference the operator can use, without exposing credentials or another user's details. |
Confirm language selection, the agreed default and what happens at the end of a session. Check long translations, line wrapping, special characters and right-to-left layout where requested. Review the complete screen, not just a separate spreadsheet of translated strings. Have a competent reviewer of the intended language assess meaning; a translation being present does not establish that it is clear.
3. Follow the physical connector through the screen journey
At a multi-output charger, photograph the authorised demonstration's connector labels and compare them with the on-screen selections. Record how the screen identifies the selected output before a start or stop request. The aim is to expose ambiguous mapping before rollout, not to impose a particular lettering convention on every supplier.
Use a fictional example: a pilot cabinet has outputs labelled A and B, while a connected payment device lists 1 and 2. The buyer should request a documented mapping and a demonstration that each selection addresses the intended output. Do not assume the lists use the same order. Confirm any label change across the cabinet, software, signage and support records together.
The asset-identity handover guide covers the underlying station and output references. This review focuses on what the driver actually sees.
4. Review pending and unsuccessful journeys
Ask for approved demonstrations of supported exceptional states, such as unavailable equipment, an authorization request that has not completed, or a session that cannot start. The supplier should choose a controlled demonstration method. Do not disconnect protection, interrupt a live installation or manipulate payment systems to manufacture a fault.
For each case, agree the expected wording, permitted next action and escalation route. A generic failure screen should not tell a driver to perform electrical servicing. Ask whether the interface distinguishes an unresolved result from a confirmed failure, and how the operator handles a user who asks whether an earlier request completed.
Where payment is included, keep payment authorization and charging-session state separate. A payment approval alone does not establish that energy is being delivered. Have the responsible providers demonstrate their agreed state transitions and exception handling using the approved test environment. Do not add an unconditional “try again” instruction to an unresolved transaction without provider confirmation.
Use the payment-readiness planning tool to organise responsibilities, and the offline-operation guide for the supported disconnected workflow. Neither provides payment-network or engineering approval.
5. Observe representative users under agreed conditions
Include people who have not watched the supplier's demonstration. Give them a defined task and observe which labels or instructions require explanation. Agree the trial conditions, observation method and acceptance criteria in advance. Record hesitations, mistaken selections and requests for help as findings, not as a statistically representative failure rate from a small pilot.
Review readability under representative planned lighting and viewing conditions with the responsible site team. Photograph or record the approved test setup so observations can be reproduced. Do not invent a brightness, contrast, mounting-height or reach specification from this checklist; obtain product evidence and the qualified local accessibility and site review.
Capture only the evidence needed for review. Use sanitised test identities and avoid storing payment details, private account information or access tokens in screenshots. Assign someone to approve and retain the evidence. The operator-training guide covers staff preparation separately from a first-time driver's interface.
6. Close findings against the version being ordered
Use one finding record containing the screen or workflow reference, language, configuration revision, expected result, observed result, evidence reference, responsible party and agreed disposition. Keep unresolved items visible when making the purchase decision.
After a wording or software change, repeat the affected journey and the related exceptional states. Confirm that the accepted language package is included in the delivery scope and that later updates have an owner. Ask which changes are included in the quotation, which require a separate service and what rights the buyer has to approved language files. Do not infer unrestricted source-code rights from permission to edit customer-facing text.
Attach the signed interface record to the factory and site acceptance plan. A screenshot pack supports that plan; it does not replace functional testing or a full local-compliance review.
Keep AC and DC interface responsibilities distinct
AC EV charger SKD kits and technical documentation: confirm the selected AC model, whether the user interface is on the charger or another agreed device, the supplied components and the assembly and interface-document revisions.
DC EV charger SKD kits and technical documentation: confirm the selected DC configuration, screen and output mapping, component scope, software and language-package rights, and agreed testing and repair-support responsibilities.
Xiaochong recruits businesses interested in local charger production or assembly. SKD components, production/assembly technical support and repair/maintenance technical support are scoped for each project. Available AC or DC technical documentation is free on request. Hardware, unrestricted source code or intellectual-property rights, certification, training, repair labour and exclusive territories are not automatically free or included. Agree exact models, document revisions, sharing permissions, licensing and support scope in writing.
Buyer questions
Does a translated start screen prove that the whole charging journey is translated?
No. Confirm the agreed language on selection, authorization, waiting, charging, stopping and support screens, including exceptional states. Record untranslated or truncated text against the tested software revision.
Can a payment approval message be used as proof that charging has started?
No. Define separate evidence for authorization and for the charging-session state. The user interface should communicate the actual supported state without treating payment approval alone as energy delivery.
What should be included in an interface acceptance record?
Record the exact model, software and language-package revisions, intended workflow, expected messages, observed result, sanitised evidence, reviewer and unresolved items. Repeat affected checks after an approved change.
Reference reviewed 1 October 2026: W3C WAI, Understanding Labels or Instructions. The charger-specific checklist and fictional connector example are original procurement guidance, not a W3C test suite or endorsement.
Request an AC or DC interface review
Send your country, company, AC or DC track, intended configuration, quantity, required interface languages and the user journeys you need demonstrated. Ask for free available AC or DC technical documents. Identify your proposed backend and any payment device so interface responsibilities can be agreed.
See the official partner programme, AC/DC SKD technical-output page and procurement guide. Only approved documents may be shared; this article does not release private factory files.
xc0225888@163.com · Sales 1: +86 137 1772 6888 · Sales 2: +86 134 2580 6997