Wheelchair Human Factors: Where Usability Lands in Testing

Start with the rule: usability is not a test item of its own

People often ask which item covers human factors and usability in wheelchair testing. The question is set up wrong. There is no item called a usability test. Usability is a requirement that runs through the whole file, and it is split across three places: the technical requirements in the parts dealing with controls and handling, the use-error analysis inside risk management, and the wording of the accompanying documents and markings. Cut a corner in any one of the three and the other two will surface it.

So the working rule is this: first decide which of the three landing points your problem belongs to, then decide how to close it out. Get the landing point wrong and no amount of verification will fill the gap.

Landing point one: controls and handling

How a powered product handles is not a matter of opinion. The ISO 7176 series carries technical requirements for it. The parts dealing with the control system address whether the behaviour of the control device is predictable, whether an unusual order of operations can produce unintended movement, and whether the response in a fault state is safe. ISO 7176-14 is the core part on this line.

One point is regularly misread. Control system requirements govern system behaviour, not whether the product is pleasant to use. A joystick that feels stiff, or a menu structure buried too deep, is a product experience issue and will not fail on this line. But movement continuing after the joystick is released, unintended movement during a mode change, or recovery from a fault state dropping straight back into a drivable state, are all system behaviour, and they map directly onto a verdict.

Here is how to tell them apart. Rewrite the thing that worries you as one sentence of the form: under these conditions, the system did this unintended thing. If you can write that sentence, the issue belongs on this line. If you cannot, and all you can say is that users find it awkward, it is a design improvement. It does not enter the test verdict, although it may well enter the risk file.

Landing point two: use error inside risk management

Under the ISO 14971 framework, use error is a source of risk to be identified, evaluated and controlled, on the same footing as mechanical and electrical risk. Typical use-error scenarios on wheelchairs include forgetting to switch back after moving between push mode and drive mode, using the chair with an optional part not fully seated, misusing the brake on a slope, failing to lock during a transfer, moving the chair while it is on charge, and the attendant and the user reading the same control differently.

The order of treatment for these scenarios is fixed and cannot be reshuffled. First ask whether design can eliminate the risk. If it cannot, ask whether a guard or a structural limit can reduce it. Only when neither is achievable do you fall back on information for safety. Plenty of teams jump straight to that last layer and write every use error up as a warning in the manual. It gets challenged during risk file review, because information for safety is a weaker measure, and leaning on it as the primary control leaves the residual risk argument without support.

A concrete failure is worth spelling out. On one product family the mode selector sat close to the carry handle, so users knocked it while lifting the chair. The team's response was to add a warning in the manual. The review question was blunt: if the accidental contact comes from where the parts sit, why not move them or add a guard against inadvertent operation? The outcome was a design change plus a re-run of the related test items. Had the same issue been caught at the planning stage through a use-scenario walkthrough, the only thing changed would have been a drawing.

Landing point three: documents and markings

Everything in risk control that lands on information for safety has to be honoured in the manual and on the product markings, and the two have to correspond item by item. A common review method is to take the list of control measures from the risk file and compare it against the entries in the manual; anything without a match is counted as a measure not implemented. The detailed practice on that chain is a topic of its own, so only one point needs repeating here: a warning is a control measure, not a disclaimer, and it should read as an actionable instruction rather than a reminder to be careful.

Decision table: which landing point does the symptom belong to

When you need validation with users involved

Not every product needs an organised validation activity with users, but the situations below are worth doing, and doing before design freeze.

When the operating logic differs noticeably from existing products. Established user habits interfere strongly; however sound the new logic is, a conflict with habit produces operating errors.

When the product is aimed at users with cognitive or upper-limb limitations. In those use situations, error tolerance in the operating steps matters far more than operating efficiency, and internal engineering review rarely surfaces the real problems.

When the product involves both an attendant role and a user role. The two roles often expect different things from the same device, and operating errors in dual-role scenarios tend not to show up in routine laboratory items.

When a new interaction method is introduced, for example an additional control entry point or an additional operating mode. A new entry point means a new path to operating error, and the use-scenario analysis has to be walked again.

Validation does not have to be elaborate. What matters is the record: which scenarios were run, what behaviour was observed, which behaviours were judged to be use errors, and how each was handled afterwards. That record is the direct evidence supporting the argument in the risk file that residual risk is acceptable.

The self-check sequence

Start by listing the use scenarios. Break the product down into action sequences across the whole span, from unpacking, assembly and adjustment through daily use, transfer, cleaning and on to storage and transport. Do not write only for normal use.

Then ask three questions of every action. Can this step be done wrong? What happens if it is done wrong? Would the user notice that it went wrong? The last question is the one people skip, and errors that go unnoticed are exactly the class that does the most harm.

Next, assign the landing point. Anything you can express as unintended system behaviour belongs on the controls and handling line, and you should plan to verify it with test items. Anything you cannot express as system behaviour, and that depends on people to avoid, belongs to use error and is handled in order of control priority.

Then map the measures. Every control measure has to point at a specific design feature, structural feature or document entry. If it cannot point at one, it has not been implemented.

Finish with a change review. Any design change touching interaction sends you back to the scenario list to see whether it needs updating. For the supporting test items on powered products, see powered wheelchair testing.

Common misconceptions and what they cost

The first is treating usability as pre-launch experience polish. Find an interaction problem at the sample stage and the fix usually touches structure or control logic, invalidating completed test items along with it. The cost is a new slot in the schedule.

The second is substituting warnings for design. Risk file review asks you to justify why the risk cannot be eliminated by design, and if you cannot justify it you go back and change the design.

The third is considering only the user and not the attendant. In real wheelchair use, attendant operation accounts for a fair share of the total, and a gap in those scenarios shows up in a cluster once real-world feedback comes in.

The fourth is treating use-scenario analysis as a one-off document. The product goes through a revision, the scenario list is not updated, and the risk argument for the following version has a broken link.

To see how this kind of work proceeds on real projects, look at the case studies; for what supporting test items we can cover, see our services.

On accreditation and the limits of a conclusion

It should be set down clearly that an accreditation mark only demonstrates that the laboratory holds the corresponding technical competence within its accredited scope; it does not constitute a commitment regarding the outcome of market access in the target market. A test report states whether the submitted sample meets the requirements of the cited standards under the stated conditions. A large part of the human factors and use-error material sits in the risk management file and the accompanying documents, judged during quality system audit and registration review, and the report does not replace those judgements.

If you want to walk through it together

On the human factors line, the money goes into timing. Complete the use-scenario walkthrough before design freeze and you are changing drawings; discover the problem once samples are on site and you are changing the schedule. We can come in while you are settling the control concept, work through the scenario list, the landing point assignment and the mapping of control measures with you, then set which test items are needed and which content is closed out through the risk file instead.

To discuss a specific product, call +86 132 4819 8029, or send the documentation through request a quote and we will come back with proposed test items and a schedule based on the product form and your target route.