From time to time, I come across situations where I need to clarify and point out some essential facts I’ve already discussed in this post about user requirements definition and in this one about writing user requirements.
A few weeks ago, a colleague suggested to me to include (in the user requirements of a new product) the fact that the product must be “user-friendly.”
And then more recently a start-up founder showed me a user requirement of a new medical device- still in development that was formulated with the expression “easy to use”.
Although both wanted to have the user requirement “easy to use” for good reasons. And both are laudable for taking into consideration the user in the development; unfortunately, they are both wrong.
Why is “easy to use” Or “user-friendly” Not A User Requirement?
Let’s consider it this way: First, do you think that writing user-friendly as a requirement will prevent us from developing a non-user-friendly device?
Also, do you think products are difficult to use when developed according to a user requirement like “difficult to use”?
I’m almost 100% sure that medical devices that are not easy-to-use had in their user requirements a sort of user-friendly or easy-to-use requirement.
What’s The Real Challenge Of “User-friendly” And “Easy-to-use”
The problem with “user-friendly” and all vague requirements is that they are vague, ambiguous, and unclear.
A user requirement like “The device must be easy to use” will be translated in design inputs (specifications) according to the interpretation of “easy to use” of the development team, which might not be aligned to what the user means by ‘easy to use.’
The requirement “Easy to use” will be very difficult to be properly validated by the users during the validation phase of the development.
Furthermore, simply because “easy to use” is not measurable, it will be almost impossible (apart from extreme cases), to define a dimension that will define the pass or fail of the validation test.
From a marketing perspective, the wording “easy to use” is a clear demonstration that the VOC was not conducted in-depth.
If during the interviews with users, the term “easy to use” arises, it is the responsibility of the interviewer to probe and understand what the users mean by “easy to use”.
If during customer observation (ethnography) the observer noticed some needs about usability; it is his job to describe in detail the situation and define the meaning of an “easy to use” device.
Overall, identifying the correct user requirement(s) related to the need for an “easy to use” device is a critical step of user requirements definition.
Examples Of Bad And Good User Requirements
Using an infusion pump used to administer drugs as a case study, I would like to show the difference between the vague “easy to use” requirements and well-written user requirements in relation to the simplicity of use.
| Vague user requirement | Proper user requirement |
| The infusion pump must be easy to carry. | As a nurse, I must be able to carry the infusion pump, with one hand only, for 5 minutes. |
| The infusion pump must be easy to install. | As a nurse, I must be able to lift the infusion pump and fix it to a piece of equipment stand without help. |
| The infusion pump numerical keypad must be easy to use. | As a nurse, I must receive positive feedback when pressing a button key. |
| The infusion pump must have a clear indication when not connected to the main power supply. | As a nurse, I must be able to understand when the device is not connected to the main power supply (i.e. running on batteries) from 3 meters. As a nurse, I must be able to quantify the battery life in hours and minutes. |
| The infusion pump loading of the administration line must be user-friendly. | As a nurse, I must not be able to load the administration line incorrectly. |
| The infusion pump screen must be easy to read. | As a nurse, I must be able to see on the screen key information (flow rate, volume infused, etc…) in all lighting conditions when operating the device. |
As you can see, the proper user requirements are more specific and they identify the typology of the user that will validate the solution developed.
Furthermore, they allow the development engineers to translate the user requirements into specifications and develop solutions to the user’s needs.
Conclusion
When “easy to use” or “user-friendly” become something specific, tangible, measurable, and possible to validate, the activities related to a well-written user requirement become clear to everybody in the team. Then, the work can be planned, and the solutions put in place can be tested by the user.
The “easy to use” requirement is wrong for the reasons explained before; as marketers, I think we must be obsessed with proper user requirements.
And if these kinds of requirements come to our attention, we must push to identify the user, collect the needs and define high-quality user requirements.
What other vague user requirements do you know? Please let me know your thoughts in the comment and don’t forget to hit the subscribe button for more relevant topics.