Dealing with Soft Requirements

Dealing with Soft Requirements

In the ideal product development project, the client would provide a thorough and well-written set of requirements that can be unambiguously understood and implemented by the engineering team. Of course, this almost never happens in practice. Sometimes the requirements we’re given are so “soft” that they aren’t even really quantifiable. That kind of requirement can be extremely difficult to design to during a product development effort. So what can you do?

One approach is to use quick, low-cost prototypes to get early feedback from the customer on what “feels” right. This is a fairly common approach for things like graphical user interface design. But, as I want to show you in this post, it’s just as applicable to mechanism design.

“A solid, quality feel”

We recently designed a mechanism with a custom dual-stage switch for a customer who was very concerned with the actuation feel of the switch. They could tell us that it was important for the actuation to provide a “solid, quality feel with tactile feedback to the user, without being overly stiff.”  But they couldn’t articulate the required “feel” to us in a way that we could incorporate into the design process.  

As a designer, fulfilling a requirement like “solid, quality feel” with any level of confidence is extremely difficult. Although you might understand the intent of the requirement in general terms, you open your project up to risk if you continue the product development process without a clear definition of the desired feel. In the worst case, you’ll end up with a fully-developed design and a working prototype that feels great to your design team, but doesn’t meet your customer’s expectations.

Rapid prototyping to the rescue

The key to success in our mechanism design was to help our customer to quantify the desired feel of the switch. We designed and built (using our 3D printer) a prototype adjustable switch that could accommodate a range of push forces, detent stiffnesses, throw lengths, etc. Our customer stakeholders were able to feel the physical prototype in a variety of configurations, argue amongst themselves, and finally agree on which configuration felt best.

With an approach like this, there’s no need to ask the customer “How many Newton's of force and millimeters of throw were you intending with this requirement?” Your customer probably doesn’t know, and it’s likely that they don’t really care. They just want the thing you’re designing to “feel right”.

Capture.PNG

For our project, once the stakeholders had dialed in the settings that everybody agreed “felt” right, the prototype became our “gold standard” for quantifying the requirements. We tested the prototype with our universal strength tester to generate force curves that characterized the actuation. From the curves, we were able to find values for peak force, stiffness, distance to detent, and distance to hard stop. Unlike “a solid, quality feel”, these are quantifiable values that you can design and test against.

Requirements you can design to

With the high-risk “soft” requirement converted into a quantifiable, testable set of requirements, we could design, print, assemble, and test several different ideas for the final mechanism. By comparing the measured force curves for each of our ideas to the quantified feel requirements we were able to converge on a design that we were confident would be accepted by the customer.

This kind of approach can be applied any time you’re faced with a “soft” requirement that you can’t confidently design to. Just ask yourself “What requirements do I wish the customer had given me?” Then figure out how you can quickly put something in front of the customer that will let them show you what they want, and let you gather information to define the requirements you really wish they’d given you. You’ll reduce the risk in your development project, and be much more likely to deliver a design that delights your customer.

Launching Pigs?

Launching Pigs?

Teaching Students about Real Product Development

Teaching Students about Real Product Development