How to deal with user needs when it is obvious the design meets the user need

[david316]

Hello,

When it comes to validating user needs, how do people handle user needs that are obviously going to pass validation and hence validation is pointless. For example, maybe I have a user need for a particular device that is something like:

-Device must be able to transport device around a hospital with in one hand.

Now assume that the end result of the design effort is a device that weights 100 grams and is clearly easy to carry with one-hand. Do we still need to validate it by getting uses to carry it around a hospital or can be say validation is not necessary as it is obvious the device meets the user needs.

 

[QAengineer13]

Hello,

When it comes to validating user needs, how do people handle user needs that are obviously going to pass validation and hence validation is pointless. For example, maybe I have a user need for a particular device that is something like:

-Device must be able to transport device around a hospital with in one hand.

Now assume that the end result of the design effort is a device that weights 100 grams and is clearly easy to carry with one-hand. Do we still need to validate it by getting uses to carry it around a hospital or can be say validation is not necessary as it is obvious the device meets the user needs.

David,

In summary it all comes to how good is your customer needs, the customer need establishes the relationship between the organization and the customer.
Customer needs Requirements are those characteristics that determine whether or not it meets the customer intended use

My 2c's while you are doing your VOC and requirement gathering having the sense of what customer needs and wants helps you to write a meaningful customer needs document.

Just as an example from your post.

"Device must be able to transport device around a hospital with in one hand" /......what does this mean " with in one hand" very ambiguous so its better to write requirmetns in a way you can verify/validate, if that makes sense!

"Now assume that the end result of the design effort is a device that weights 100 grams "...Why no greater than 100 grams....just to add context. So think about the intended use, needs and wants and write a meaningful need which the customer would embrace not to write just for the sack of ticking the box.

 

[david316]

Thank you. That makes sense but where I work (which I will assume isn't unique) prototypes and design concepts are created during a proof of concept stage in consultation with marketing. Marketing usually have done the VOC before or during this process. Then ultimately what happens is a concept gets finalised and design controls start....actually we usually start design controls quite a bit into the actual design.... As a consequence the user needs or customer requirements specification become a bit of a strange document because ultimately at this point in the project it is very unlikely any changes will be made based on "user needs". So the user needs document becomes less than ideal with generic things like "must be easy to use", "must be portable", etc. Furthermore, people don't want to validate the design meets the user needs because the reality is that if the user needs validation fails no changes will be made unless it effects safety. As a result we often end up with user needs which we don't validate and argue that its obvious the user needs is meet. e.g. we might have a user need "must be portable". Then we say..."its portable because it on wheels" and don't validate that its portable within the context of what the user actually whats. To a certain extend there is a rationale that by the time you end up validating the product it almost a waste of time for non risk or non therapy related user needs as ultimately failing one of these user needs (really a user want) is very unlikely to result in a design change. So given all of above, maybe the question is how to you justify poorly written user needs and justify not validating them.

Regards

David

 

[yodon]

It's been my experience that user needs are often kind of squishy like this.

In many cases, I've seen the user needs traced to specific system requirements (which get verified) and the trace matrix for the validation of the user need says something to the effect of "validation is covered by verification." Can't say I'm a big proponent of that but it seems to be acceptable.

In your case, my ideal verification would be a simple user study: get a prototype in the hand(s) of a good cross-section of your user population and have them 'transport' the device during normal working conditions. If they tell you it was able to be transported with one hand, you're validated. (Or course if they give you feedback that they had difficulty transporting it or ended up somehow damaging it, you're on the other side of validation.)

 

[david316]

Thanks Yodon. We have often also taking the approach of saying something like "validation is covered by verification of lower level requirements". I don't really like it but its good to know its not an uncommon approach.

 

[QAengineer13]

Thanks Yodon. We have often also taking the approach of saying something like "validation is covered by verification of lower level requirements". I don't really like it but its good to know its not an uncommon approach.

David,it now makes sense and I have been in situation where you are currently and Yodon's suggestion is what I followed. Thanks Yodon for explaining it very clearly.