Developers Use It Easily, But Do New Users?

There Are Unexplained Assumptions Even with Familiar Operations

Developers turn on the device, check its readiness, and naturally proceed with necessary operations.
If they have worked with the same prototype for a long time, they might know meanings that are not written on the screen.

But what about users encountering the device for the first time?

The fact that a developer successfully demonstrated the device does help in explaining its operation.
However, that alone makes it difficult to conclude that targeted users can safely use it under the same conditions.
Finding out what aspects of the developer's experience fill in the gaps is the starting point of this article.

This text is meant as a self-review question for medical device development teams.
It is not operational instructions for a specific device nor a substitute for product-specific usability evaluation plans.
The device mentioned in the examples is a hypothetical prototype for illustrative purposes.

Looking at Users, Environments, and Interfaces Together

The FDA’s Human Factors Considerations describe the interaction between the user, usage environment, and user interface.
This perspective examines user experiences, sensory and operational abilities, ambient light and noise, as well as device displays and controls.

The interface is not limited to the screen and includes all aspects where users interact with the product.
The FDA’s Applying Human Factors and Usability Engineering to Medical Devices was released on August 3, 2026.
This article references the scope and definitions from that guidance.

It is essential to distinguish between the guidance's recommendations and legal obligations and not apply U.S. materials directly as domestic approval requirements.

The questions and tables below have been created internally by MedQraft and are not direct translations of the original tables.
They summarize aspects of the overall procedure, testers, and passing criteria, and should not be used as is.

Examining "Who Writes" in Actual Roles

Can a single line stating "used by medical professionals" fully describe the usage scene? You can delve deeper into who the intended users are, their familiarity with the product, and the specific operations they undertake.

For instance, if one person prepares the device and another checks the results, you can ask how the information from the preparation stage is conveyed to the subsequent user.

Even among users with the same job title, those who use the product daily might have different expectations than those using it for the first time.
This is why merely knowing job titles does not allow for assumptions about experience.

In the review, distinguish between verified user information and the development team’s assumptions.
Any areas requiring actual user observation or interviews will remain verification tasks.
It is more useful to highlight what needs to be known rather than documenting unverified user behavior as definitive requirements.

Hypothetical Case: Demonstrating Two States with One Light

Consider a hypothetical prototype of a portable measuring device.
When the power is on and measurement is ready, the same indicator light turns on.
The development team knows that internal preparation takes time and waits before proceeding.

Can a user encountering it for the first time interpret the light as indicating that preparation is complete? The review here is not simply whether the color of the light is appealing.
The critical question is how users interpret that indicator and how that interpretation influences their subsequent actions.

This case does not report a problem with a specific product.
The team can start by writing down the meaning they believe the indicator is trying to convey.
Then, they can observe what information the user sees to decide when to start acting.

Proposals like differentiating the indicator or changing the wording can become design candidates, but determining what is sufficient must be based on the product's context and verification results.
One should not conclude that changing the color arbitrarily resolved the issue.

Distinguishing Preferences from Actual Behaviors

"It was easy to use" may be a valid comment, but that alone does not reveal which steps were difficult.
If you pre-organize the behaviors you want to observe during internal exploration, the questions can become more specific.
For example, you could document points where users hesitated, a scene where they explained an indicator with a different meaning, or stages they needed help with from an instructor.

Separating the fact that users hesitated and the developer’s speculation about why is also crucial.
Before jumping to conclusions about the reasons, it is important to confirm what the user understood.

The above table serves as an example to aid record-keeping and is not a test judgment table.
The criteria or conditions for determining success or failure should be independently established for actual purposes.

Linking Modifications to Reverification Questions

After concluding observations, connect the findings with design amendments.
Rather than simply writing "usability improvements," describe what was unclear, and how you intend to alter the information.

In the hypothetical indicator case, the goal might be to differentiate between power-on and preparation complete.
Keeping this aim recorded will clarify how you will verify the results of the changes later.

During the verification process, you can also review new questions that may arise to avoid confusion between different states.
It is useful to record observation conditions, versions of the prototypes used, and guidance provided.

Bundling results from different versions or explanation conditions makes it difficult to clarify why results differ.
In relation to this, you can also refer to the article discussing comparison conditions for performance test results.
While the purpose of the tests differs, the practical question remains that comparison conditions must be clarified.

Do Not Equate Internal Exploration with Final Verification

FDA guidance differentiates between formative evaluations that explore strengths, weaknesses, and unforeseen user errors during design and usability validation testing that evaluates user interaction effectiveness and risk control at later development stages.

You should not state that final verification has been completed simply because a developer demonstrated the device or received some feedback.
Efforts to organize questions and review prototypes internally can be utilized for preparing the next investigation and evaluation.

However, it must be clear how far the results can be interpreted.
This approach involves distinguishing between what was confirmed in the observations and what remains unconfirmed.

The actual target user, tasks, conditions, and methods for assessment must be planned according to the product's intended use and associated risks.
This article contains no information to determine test plans specific to products, so it does not present any specific personnel or evaluation methods as sufficiently adequate.

Five Questions to Bring to the Next Design Meeting

• Can users determine their next actions without the development team’s explanation?
• Have you validated the intended user roles and experiences in reality?
• What are the conditions in the environments where the product will be used that have not been observed yet?
• Have you documented the distinctions between observed facts and assumptions about the causes?
• Are the modification objectives, verification results, and remaining questions interconnected?

In meetings, instead of trying to answer all questions immediately, you can choose one assumption that remains and designate it as a verification task for the next check.
If issues arise during this process that connect to the product's risk analysis, they lead to related reviews.
You can explore these perspectives further in the article discussing the connections of medical device risk management evidence.

Sources include the FDA’s publicly released guidance and definitions originally mentioned.
The guidance date is August 3, 2026, and the document verification date is September 21, 2026.
This text does not cover newly announced regulatory obligations and contains internally created hypothetical prototypes, tables, and questions by MedQraft.
It does not imply the suitability assessment of specific products or the provision of clinical services.