Jun 03 Toyota, LSD, revolvers and UX… What’s in common?

Original post: June 3, 2011 | GoogleScholar | Academia.edu

Simple products break less

I don’t love guns, but sometimes a gun can help tell a story. So, this post is a bit odd but is fun and educational. All those who have worked with me in software teams have heard me say, “Let’s make this feature work like a revolver!” This expression is not my own – I “inherited” it from a good friend who is a front-end developer, but it represents a principle in product design that I follow. And believe it or not, it all started with cars and revolvers and LSD… as in Lean Software Development. Since we happen to be humans (even the geekiest of us), sometimes it helps to remember why simplicity is the mother of genius – because simple things break less. This notion is at the core of usability.

A Little Usability history: Hardware vs. Software

The bulk of my work is in software and websites, and I have never owned a Toyota and have little use for handguns or street drugs. But I do take interest in precision engineering and love to study complex devices, including telescopes, watches, and other mechanisms. I also have worked on several challenging hardware projects, including those for WebMD and Air France-KLM. Many of my colleagues may argue that hardware is more difficult and expensive to develop, and so you can’t compare software and hardware fairly in terms of approaches to measuring usability. But I say (and I will prove to you, if you don’t agree) that software and hardware are identical from the usability perspective.

For starters (hold your breath until after you conquer the next section), hardware and software are similar because

• both are designed for humans;
• both are designed to serve a specific need or to solve a specific problem;
• both can be expensive to develop and expensive to market;
• both can break;
• both are less likely to break when they have fewer moving parts.

From Toyota to LSD, to Agile

Did you know that the hip word “lean” goes all the way back to Korea over 60 years ago? To be exact, in 1947, Chung Ju-Yung founded Hyundai Group Companies and then dedicated the next 50 years of his life to turning Hyundai into a global conglomerate with over 150 thousand employees. Ju-Yung, with whom I had the pleasure of working in 1995-1996 at Hyundai Motors in Seoul (fresh out of college), survived and prospered – not because he had a rich grandfather but because Hyundai was the first to use the so-called “lean manufacturing practices,” which helped the company develop amazing economies of scope and scale, starting with the manufacturing construction (its core industrial business) and about 40 years later leading to cool things like my Hyundai Genesis Coupe or your Hyundai widescreen display.

More specifically, lean manufacturing practices have their origins in the so-called Just-in-Time (or JIT) inventory control system – a production strategy that strives to improve a returns on investment by reducing in-process inventories and the associated carrying costs. By mid 1950′s, Toyota went on to “adopt” the JIT system, when Taiichi Ohno, and Eiji Toyoda developed what was then called the Toyota Production System, or TPS. In turn, because Toyota officially adopted and publicized the approach, it is also historically credited for the lean practices in manufacturing, albeit incorrectly.

A few decades later, in 2001, Kent Beck studied TPS inside-out and wrote what is known as the awesome Agile Manifesto (every serious product designer and product manager must click this link!) which Mary and Tom Poppendieck dutifully (and wonderfully) transposed into what most people in the world of software know today as Lean Software Development – a concept that was popularized by the book with the same title, which the Poppendiecks published in 2003.

More about Lean

The textbook – and the Wikipedia – definition of Lean Software Development is this: LSD is a translation of lean manufacturing and lean IT principles and practices to the software development domain. Again, the translation started with the original (be it the chicken or the egg), and the original had little to do with software as we know it. In other words, the supposed “break” between software and hardware in the context of usability (and that’s our focus here) is superficial and purely historic. Now, for the record, lean development – or LSD specifically – can be summarized by seven principles that, according to Wikipedia, are “very close in concept” to their manufacturing counterparts (listed here in the order of importance):

• Eliminate waste
• Build integrity in
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• See the whole

Now, how does a revolver play into all this?

The lean approach to product development, which – as we now know – started with new industrial manufacturing trends decades ago, is about simplicity. Not the kind of simplicity that differentiates Notepad from Microsoft Word, but the kind that separates a traditional revolver from a magazine-loading handgun – e.g, a Glock. We are talking a functional device versus a work of art.

A typical Glock handgun is a disaster from the standpoint of lean manufacturing. Sure, it has its dedicated market and makes money (so does Rolls Royce, although many who can afford a RR choose to invest money into cheaper cars), but it certainly fails on the very first item in the lean list – waste elimination.

Guns are Bad… Back to Software

To translate Glocks into the software domain, they have a lot of unnecessary “code and functionality” that come at a great cost, while only marginally increasing the overall product experience (the “hip factor” aside) but not necessarily its performance or dependability. Aesthetically, there is nothing wrong with it, but functionally speaking, Glocks are difficult to sell to many people who want a dependable gun. To elaborate, an average Glock has about 40 parts. Compare that to an average revolver, which has about 25. In plain English, a mechanism that engages more parts has more parts that can break. Glocks are light, true, but they are only slightly more accurate than quality revolvers and they are twice as likely to jam or to break – because their design is complex and includes a number of breakable polymer parts. It is no wonder that cyberspace is full of horror stories from Glock owners who love their S&W revolvers.

The same applies to software products: beyond a certain point in development, many products become uncontrollably complex and result in a slew of features that a vast number of users – including many power users – don’t appreciate, which in turn increases costs, increases bugs, and potentially lowers product usability and customer satisfaction. Practically speaking, there is something known as the Law of Diminishing Marginal Returns – a fundamental economic principle, which is defined as the decrease in the marginal (incremental) output of a production process as the amount of a single factor of production is incrementally increased, while the amounts of all other factors of production stay constant.

A classic example is adding more workers to a job, such as assembling a car on a factory floor: at some point, adding more workers causes problems such as workers getting in each other’s way or frequently finding themselves waiting for access to a part. In all of these processes, producing one more unit of output per unit of time will eventually cost increasingly more, due to inputs being used less and less effectively. Eventually, by increasing the product’s function you may actually be increasing its cost to a point of incurring an operating loss, directly or indirectly.

The same applies to software. In my mind, a good practical example is Skype, which I find to be a rather invasive application that I’d love to run on my MacBook Pro all the time… but choose not to because it consumes more system resources than I am willing to give up in exchange for the privilege of being easily accessible to my international colleagues in Paris or Amsterdam.

That in mind, I like to say – as one of my good colleagues taught me in 2006 – that all good products must start out as “as a revolver” and not as a Glock, while most products don’t ever need to turn into a Glock. So, don’t let my odd metaphor confuse you when you hear these words from me while discussing an app, a website or a software project. For at the root of every successful digital product there lies a simple principle: if you are going to make a Glock, be sure that you have the advertising budget and the positioning strategy to market this baby to the people who will appreciate it. Otherwise, keep your product simple and don’t add things to it just because they are “nice to have.” The same goes for premature optimization. Better yet, don’t make guns and don’t sell them or use them: guns are bad.

And every time you feel like questioning this logic, play with an Apple device to remind yourself that successful products don’t have to be complex, nor do they have to please everyone. Speaking of successful products that can be improved, I have written a related post about sealed batteries in Apple devices – check it out.

Do you want to continue this discussion? Message me on Twitter or using the contact form on this site.