5 Tips for writing better User Needs
In the beginning, there was the User Need.
According to FDA, the User Needs are the starting point for building a safe and efficient medical device. However, User Needs can be elusive to an engineering team used to rigid techniques and accustomed to having "full information" when approaching a problem.
It is rather rare that the developer has the real and deep experience a User has and it can therefore be precarious to leave the User Need elicitation process in the hands of an engineering team. Here are some tips for eliciting better User Needs.
Consider the Intended Use
It has been said 100 times before, but I say it again: start out by considering the Intended Use and Indication for Use.
These two items will tell you:
- who is the device for (or rather, who do you say the device is for)
- why (or for what) is the user using this device (or rather, for what you say the device is to be used for)
The whole idea here is to get as close as possible to the user and the situation in which the user applies the device. What medical condition is the device intended to address? Where and under which circumstances is the device being used? In a hospital or an ambulance? During the night? In the rain? By a child? By a blind person?
Answering these questions will put you in the shoes of the user and will let you describe the user's needs in his or her own words. Imagining being the user in the situation where the need for using the device arises will also give you an idea of the constraints facing the user at the time of application.
Thus, considering the "who" and the "why" is generally a more fruitful starting point than elaborating on the "how" (which is what engineers tend to do).
Who is the user?
In a majority of cases, a medical device is handled by more than one type of User during the product's life cycle. This becomes clear when considering non-core usage tasks such as:
- transportation
- installation
- calibration
- maintenance
- service
- decommissioning
How did the device arrive at the usage location? How and by whom was it deployed? Was it carried in a pocket? Was it transported by air?
Apparently, it is important to consider all people involved with the handling of the device since these actions may have safety implications. Again, do not second guess the needs of these users but involve them in the process.
User Needs can be vague
Using fuzzy language (such as adverbs) when documenting requirements is a known bad-practice. However, User Needs may be written in a less prescriptive way if it captures important aspects of the User and the Usage. We know that, in the end, the Medical Device will end up being very concrete and void of any fuzziness.
The challenge thus lies in translating the potentially fuzzy language used in User Needs into concrete specifications in the Design Input Requirements and concrete Validation Tests. Make sure that the User Needs are well understood by the team deriving the Design Input Requirements and Validation Tests from the User Needs.
Not all input is User Needs
Costs, brand colors, production constraints are examples of important design input that are not necessarily User Needs. I usually recommend to my clients that they add an additional Design Control type for Stakeholder Needs in order to pick up this input which definitely influences the design, although it is not always required to be verified or validated.
When setting up the validation activities, you must be explicit about what you intend to validate and explicitly define the criteria applied to make this selection. By separating the input in the two mentioned Design Control Types makes it easy to explain which Design Controls are intended for validation (User Needs) and which are not (Stakeholder Needs).
Write User Needs with Validation in mind
The way User Needs are written will heavily influence the Validation activities. Since Validation is a resource-intensive (and therefore expensive) activity, it makes sense to keep a close eye on the proposed validation work that will be derived by a User Need when writing it.
If some of the validation activities are already known at an early stage, the team can use this knowledge to cleverly formulate the User Needs in a way to maximize the coverage of the known validation activities. By this, I do not mean that important User Needs should be left out but rather than formulating and structuring the combined User Needs can have a positive or negative impact on the validation effort.
By following these simple guidelines, you should be able to get more bang for the buck next time you elicitate User Needs.
Aligned Elements, the medical device ALM, manages end-to-end traceability of all Design Control items, including User Needs, Design Input Requirements, Validation and Verification Testing. If you are interested in an online demonstration of Aligned Elements, let us know on
