I recently came across a fascinating product for the visually impaired and associated background story: the SmartCane™. It does one thing, and apparently does it well, and doesn’t try to address more than a single well-defined problem. The developer of this add-on for canes came to understand that the plain cane only detects obstacles near ground level, but does indicate to the user when there are higher obstacles, such as a sign, tree branches, road barriers, car doors, or even a person immediately ahead. The solution: an add-on ultrasound unit so the cane which vibrates in proportion to the proximity of the object – that's about as simple and direct as it can be.
The SmartCane (Figure 1 ) was brought to market in 2014 and retails for around $50. It is a basic but carefully engineered and validated design, both technically and from a user perspective. As with most good “simple” products, there's more to its final design realization that you might assume at first.
The SmartCane mounted on a standard, basic cane used by the visually impaired appears simple, but is the culmination of many design iterations and user feedback.
Beyond being impressed by both the objective and design, I was fascinated in reading the story behind the development. The project was initiated by Rohan Paul of New Delhi, who started working on it in 2004 as an undergraduate; he is now a postdoctoral fellow at MIT and co-founder of the Assistive Technologies Laboratory (the SmartCane website has a detailed narrative here, full specifications here, a review of the design process and beta-stage user feedback here, and much more — all very interesting).
But what really struck me was how long it took to get this fairly simple design refined and into production and distribution, and how many others are involved. It is manufactured and distributed via a partnership between the Saksham Trust (a Delhi-based nonprofit), manufacturer Phoenix Medical Systems, and the Indian Institute of Technology.
Engineers with any experience know – or have been repeatedly advised – that it's a good idea to keep designs and their execution as simple as possible at the system, electronic circuitry, software, and mechanical levels. Sometimes complexity is unavoidable given the nature of the project, but too often features creep driven by both marketing requests – especially when the add-ons cost little. Let’s be honest here: it's not always marketing to blame, either, as sometimes engineers want to realize their dreams of a nearly perfect design, and so add bits and pieces to get closer to that design heaven.
One of the biggest challenges for any engineering team is to see that inflection point where significant additional effort results in almost negligible improvement. Yet we know that simple products have fewer things to go wrong, fewer unexpected or unanticipated surprises, and in general are a good thing. There's a corollary to “keep it simple” that “the perfect is the enemy of the good.” In other words, striving for perfection where it may not been urgently necessary may also mean that the product never gets released. It' not a new situation, at all; it was nicely captured in the classic 1981 book The Soul of a New Machine by Tracey Kidder.
However, the impressive capabilities of today's components and software make it hard to adhere to the concept of keeping it simple. It's so easy to add one or more extra features or functions, many of which the user will never use or know about. Today's smartphones are a good example, but they are only the latest in a long line of such examples.
The further lesson here is that, once again, having a better solution is only small part of the story. It takes time and energy to optimize the design, set up for manufacturing, find the resources (including people and money), and establish a marketing channel. Design complexity usually adds to these issues and problems.
Have you ever been the asked to add extra features to a product for minimal gain but with considerable design aggravation? Or have you ever asked this of others?