About Fit-for-Purpose Design

I got to thinking about Product Design the other day when I bought one of those "ab-roller" devices - the latest weapon in my seemingly never-ending battle against my ever-expanding girth.

Anyway, the shop I went to only had this one model and it was very cheap - surprisingly so. I was expecting the device to:

• Have the wheel made of aluminium, with some ribbing for strength
• Have the shaft made of steel, since that's where forces would be highest
• Have a ball bearing based rolling mechanism
• Have a kind of "tyre" for better grip
• Be fairly wide for stability

Instead, it was a simple device, pictured below:

So, it was made of plastic and had no ball bearing or other rolling mechanism other than a steel tube through a hole in the plastic. It did have a "tyre" type thing at least. My first impression was: "WTF is this?". But then I put it together and found that it was surprisingly stable, felt solid and rolled very well. I've been using it for a few days now without any issues.

It occurred to me that, contrary to my initial impression, this could be an example of a good, customer-centric design. Why? Well, it's cheap and does what it says on the box. If you consider most people's experience with home exercise equipment, it is this: you use it for a few days - maybe even months - and then...forget about it. I've seen many elliptical walkers and treadmills repurposed into places for hanging clothes to dry. It's for this reason that I buy cheap home exercise equipment.

So the makers of this product ostensibly know their market and have made this product to accomplish its purpose at the lowest possible cost.

I thought there's a lesson here for us Process folks: Don't over-engineer your solutions. Simplicity is a key factor in the success of any solution - not only because simple solutions are cheaper, but they also tend to have fewer potential points of failure. For example, if you can automate a task now, using a simple RPA bot, why go through the hassle of speccing out a core system change, or integration requirement that would a. cost more, and b. take a lot longer to implement. Back in the early days of my career, I was guilty of the opposite - I'd formulate fancy, ideal-state to-be processes that would invariably take months to get to.

The concept of a Minimum Viable Product (MVP) is an important component in the Agile space and we should adapt this concept in the Process Optimisation field as well. When solving problems, or trying to mitigate the root-causes of process performance issues, always seek to find the simplest solution - I've often made significant improvements to process performance metrics with actions as simple as adding a checklist to a process step, or improving an input form, or putting in simple poke-yoke mechanisms in a manufacturing step. Look for, and test, these types of changes before incurring the time and cost impacts of more complex solutions.

Pragmatism, not idealism, drives superior design. There's nothing wrong with "good enough"...or as we call it, fit-for-purpose.