Hello friends, an apology for deploying a provocative title to catch your attention😉
All organizations aspire to "delight" the customers, quality is implicit and any slack in user experience can turn into an existential crisis for the product and organization.
No one can escape accountability when customers are not able to consume the product/service for the problem the product/service was intended to solve but,
what happens when customers discover a new workflow or configure/use the product in a way it was never designed or built 😟
Customer fault - A BIG NO
Now how can you find these "unusual", "out of the order" workflows before they are reported by customers?
Validation teams within an organization have the accountability to ensure these problems are found and fixed before the feature/product/service is available to the customer.
For products having limited complexity and combinations, validating these negative scenarios can work( especially with the automated test suite) but for a multilayer,multi-component complex product/service this approach(find & fix) will not scale.
Secondly, does it even make sense to spend time and resources in validating something which is not a revenue (💲💲)generating activity?
What is a better approach? - "Mistake proofing"
One such mistake-proofing technique is "Poka-Yoke". Poka ➡ "mistake", Yoke ➡"prevent"
Poka-Yoke is a process introduced by Japanese engineer Shigeo Shingo. The purpose of Poka-Yoke is to develop processes to reduce defects by avoiding or correcting mistakes in the early design and development phases.
Building a product that takes care of this unusual workflow in design and development is the best phase to avoid a humungous effort later( with the find & fix approach).
All the cross-functional team's product owners, software architects, development, validation, operations & support team should come together during the design phase and plug all the possible entry points preventing any inadvertent misuse of the product/service by the end-user.
"Remember Proactive is better than Reactive"
No comments:
Post a Comment