Simple products break less

In working with engineers of all kinds, whenever my modest inputs are required to help ship better products, I like to say this: “Let’s make this feature work like a drum!” This expression is not my own – I “inherited” it from a good front-end developer friend, but it represents a principle in product design that I follow (more on that later). And believe it or not, it all started with cars and drums and LSD… as in Lean Software Development. Since we happen to be humans (even the geekiest of us), it often helps to remember why simplicity is the mother of genius – because simple things break less. This notion is at the core of great products and customer experiences.

A Little history: Hardware vs. Software

I take interest in precision engineering and love to study complex devices, including telescopes, watches, and other mechanisms. Naturally, I also have worked in digital design and industrial design. Many will argue that physical objects and devices are more difficult and expensive to develop, and so it may be unfair to compare those to software in terms of approaches to measuring usability and customer satisfaction. But I say that software and hardware are identical from the product development, usability, and customer experience perspectives. This is 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, whom I once had the pleasure of meeting in Seoul, 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 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, which Mary and Tom Poppendieck dutifully and wonderfully transposed into what most people in the world of manufacturing (and 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 customer experience – whether it be in the context of software development or car manufacturing or anything in-between – is superficial and purely historical. 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

How does a drum play into this? (pun intended)

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 a plain-text editor from Microsoft Word, but the kind that separates a drum from, say, a violin or an electronic piano or keyboard in terms of complexity.

A typical piano keyboard is a nightmare from the standpoint of lean manufacturing. It has hundreds of microchips and dozens of hardware buttons and contains a vast amount of computing capacity that translates human inputs into music, which – mind you – can only happen with speakers and only when electrical current is present. A common drum, on the other hand, has only a couple of parts and will play sounds anytime and anywhere. You get the idea: a drum is simple, while an electronic piano is not.

Back to Software

To transpose an electronic piano into the product development domain, it has many complex parts that come at a great cost. Although these parts provide a great utility, they make the underlying product less dependable, more prone to breakage and malfunctions, and more difficult to learn. The same naturally 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 – can’t appreciate, which in turn increases costs, increases break points, 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.

With 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 drum and not as a keyboard, while most products don’t ever need to turn into a keyboard. 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 an electronic piano, 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 thought that “premature optimization is the root of all evil” (courtesy of Donald Knuth) also comes to mind here.

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 to start a conversation.
 

The post Business and Beyond: Toyota, Drums, and Customer Experience (a Product Development Lifecycle Whitepaper) appeared first on HyperAbsolute: Business Ecosystem Blog by Sander Nizni.

Is Afghanistan at the top of your country list?

Are your users annoyed because the dropdown country list on your registration page starts with Afghanistan? They may be… do your research! And if they are, is this problem worth solving? The answer is far from obvious. And it has nothing to do with the stigma of “George Bush vs. Osama bin Laden.” Let’s start with Usability 101: about 6% of the 31-million Afghanistan population use the internet: that’s under 2 million… most of whom don’t speak English and/or don’t care about your site. Sorry for bluntness, but this is a business discussion. So, should a typical social networking hub or a retail site place Afghanistan at the top of the list? Or should it force its primary target markets (e.g, USA) to the top of the list?

Indeed, Afghanistan happens to be the first country in the world, alphabetically speaking. Still, many sites – especially those whose primary market segment is defined as either “USA audience” or “English speakers” – force the United States and/or United Kingdom to the top of the list. Problem solved? Not really. Because this may imply that any country or countries that appear above Afghanistan is/are “cool and important,” while other civilized nations (e.g., Australia, Brazil, France, Spain, Zimbabwe, etc.) are not. Not a politically correct solution then, is it?

In other words, if you are a Canadian, for instance, and your country dropdown on the registration page starts with United States, followed by Afghanistan, you are left wondering: “Am I welcome here?” Due to this concern, most global sites just leave Afghanistan at the top. What is the problem with that? Apart from the many sentimental implications, many users simply don’t have the patience to scroll down to choose their country and instead choose a random country near the top of the list (e.g., Afghanistan). In fact, I conducted my own research on this topic that involved analyzing a statistical sample of over 10 million web registrations across 11 retail and social sites, and the number of these “phantom” users is staggering – over 22%. Do you want your users doing that?

So, is there an elegant solution? Of course! The most intuitive one is – grow up! Don’t ask the user living in the United Kingdom or in Zimbabwe to click on the dropdown field and then scroll all the way down – that could involve 4-5 clicks and is inefficient. One may argue: “Even children know that you can type the first letter of your country, and then the selection will jump to the respective section in the country list down below, where you can further navigate using the arrow down key.” And I say, “Exactly, Ringo!” If your visitors are expected to use a letter key just to get closer to their country in the dropdown list, why not give them a chance to just type their country name in that field in the first place? This is why we have Ajax: when the user types the first letter or two of the country name, a list appears giving him/her all the countries that match. And, if you want to kick it up another notch, look up the visitor’s IP address and pre-populate the country field accordingly (but leave it modifiable so that users can override the value if they are registering while traveling in another country). Problem solved.

Do you want to talk about this? Do you know of a more elegant solution? Message me on Twitter or using the contact form on this site.
 

The post Web Form Usability: Afghanistan at the top? Really?! appeared first on HyperAbsolute: Business Ecosystem Blog by Sander Nizni.