Learning by Shipping

A post by Alex Limi, of Mozilla, Checkboxes that kill your product, is a fascinating read for anyone in the position to choose or implement the feature set of a software project.  What is fascinating is of course the transparency and admission of the complexity of a modern software product.  Along with this is a bit of a realization that those making the choices in a product are in some ways the cause of the challenge.  Things are not quite so simple but are also not so difficult.

Simple

By now we are all familiar with the notion that the best designs are the simplest and most focused designs.  Personified by Apple and in particular the words of Steve Jobs, so much of what makes good products is distilling them down to their essence.  So much of what makes a good product line is only shipping the best products, the smallest set of products.  So much has been written, including even in Smithsonian Magazine, about the love of simplicity that inspired and is expressed in the design language of Apple’s products based on a long history of design.

It is exceedingly difficult to argue against a simply designed product…so long as it does what you want or when it does more than competitive products.

In fact it is so difficult to argue against simplicity that this post won’t even attempt to.  Let’s state emphatically that software should always do only what you need it to do, with the fewest number of steps, and least potential for errors due to complex choices and options.

On the other hand, good luck with that.

Anyone can look at any software product (or web site or hardware product) and remove things, decide things are not valuable to “anyone” or simply find a new way to prioritize, sort, or display functionality, content, capability.  That’s really easy for anyone who can use a product to do.  It is laudable when designers look back at their own products and reflect on the choices and rationale behind what, even with the best intentions, became undesired complexity, or paperclips.

The easiest type of simplicity is the kind that you place on a product after it is complete, hindsight is rather good when it comes to evaluating simplicity.  This is simplicity by editing.  You look at a product and point out the complexity and assume that it is there because someone made some poor assumptions, could not decide, didn’t understand customers, or a whole host of other reasons.

In fact, many choices in products that result in complexity are there because of deliberate choices with a known cost.  Having options and checkboxes costs code and code costs time in development in testing.  Adding buttons, hinges, or ports is expensive in materials, weight, or even battery life.  Yet designers add these anyway.  While data is not a substitute for strategy, looking at usage data and seeing that nearly every bit of surface area is executed, validates these choices (one could go through Limi’s post and reverse engineer the rationale and point to the reasons for baggage).

It is enormously difficult in practice to design something with simplicity in mind and express that in a product.  It is an order of magnitude more difficult than that to maintain that over time as you hope for your asset to remain competitive and state of the art.

Difficult

Software is a unique product in that the cost of complexity is rarely carried by the customer.  The marginal cost for more code is effectively zero.  While you can have lots of options, you can also effectively hide them all and not present them front and center.  While you can have extra code, it is entirely possible to keep it out of the execution path if you do the work.  While you can inherit the combinatorics of a complex test matrix, you can use data and equivalence classing to make good engineering assumptions about what will really matter.  Because of these mitigations, software is especially difficult to design simply and maintain in a simple state even if you accomplish a simple design once.

Here are seven reasons why simplicity in software design is incredibly difficult:

• New feature: enable/disable.  You add a new feature to your product but are worried about the acceptance of the feature.  Perhaps because your new feature is an incredibly innovative, but different, way to do something everyone does or perhaps because your new feature is based on a technology that you know has limits, you decide to add the checkbox.  The easy thing to do is to just add a “do you want to use this” or the first time you see the feature in action you offer up an option to “keep doing this”.  Of course you also have to maintain a place to undo that choice or offer it again. Play this out over the next release and evolution of the feature and you can see where this leads.
• New feature: can’t decide. You add a new feature and it clearly has a modality where some people think it should go left and others think it should go right (or scroll up or down, for example).  So of course the easy thing to do is just add an option to allow people to choose.  Play this out over time and imagine what happens if you decide to add a new way or you enhance one of left or right and you can see the combinatorics exploding right before your eyes.
• New way of doing something: enable compatibility.  You add a new way to do something to your product as it evolves.  Just to be safe you think it would be best to also have the old way of doing something stick around so you add back that option—of course software makes this easy because you just leave the old code around.  But it isn’t so easy because you’re also adding new features that rely on the new foundation, so do you add those twice? Play this out as the new way of doing something evolves and people start to ask to evolve the old thing as well and the tyranny of options gets to you quickly.
• Remove feature: re-enable. As your product evolves you realize that a feature is no longer valid, useful, or comes at too high a cost (in complexity, data center operations, etc.) to maintain so you decide to remove it.  Just to be safe you think it is a good idea (or customers require it to be a good idea) to leave in an option to re-enable that old feature.  No big deal.  Of course it is important to do this because telemetry shows that some people used the feature (no feature is used by zero people).  Play this out and you have to ask yourself if you can ever really remove a feature, even if there is a material cost to the overall system for it to be there.
• Environmental choice: customize.  Your product is used in a wide variety of environments from consumer to enterprise, desktop to mobile, managed to unmanaged, private network to internet, first time to experienced people, developers or end-users, and so on.  The remarkable thing about software is the ability to dynamically adjust itself to a different usage style with the simple addition of some code and customization.  The depth and breadth of this customization potential makes for a remarkably sticky and useful product so adding these customizations seems like a significant asset.  Play this out over time and the combinatorics can overwhelm even the largest of IT administrators or test managers.  Even if you do the work to design the use of these customizations so they are simple, the ability to evolve your designs over time with these constraints itself becomes a constraint—one that is likely highly valued by a set of customers.
• Personality: customize.  You design a product with a personality that reflects the design language across every aspect of the product from user interface, documentation, packaging, web site, branding and logos, and more.  Yet no matter what you do, a modern product should also reflect the personality of the owner or human using it.  You see no problem offering some set of options for this (setting some background or color choices), but of course over time as your product evolves there is a constant demand for more of these.  At some extremes you have requests to re-skin the entire product and yet no matter what you try to do it might never be enough customization. Play this out over time and you face challenges in evolving your own personality as it needs to incorporate customizations that might not make sense anymore.  Personality starts to look a lot like features with code not just data.
• Competitive: just in case. The above design choices reflect complexity added during the development of the product.  It is also possible to make choices that do not arise out of your own choices, but out of choices that come from responding to the market.  Your main competitor takes a different approach to something you offer and markets the heck out of it.  You get a lot of pressure to offer the feature that same way.  The natural reaction is to put in a quick checkbox that renders some element of the UI your way as well as competitor’s way.  You battle it out, but rest assured you have the objection-handler in place so sales and marketing don’t stress.  Play this out and you can see how these quick checkboxes turn into features you have to design around over time.

Of course we all have our favorite illustrations of each of these.  You can imagine these at a very gross level or even at a very fine level.  The specifics don’t really matter because each of us can see immediately when we’re hitting up against a choice like this.  Play the design choice out over the evolution of the product/feature and see where it goes.

It is important to see that at the time these are not dumb motivations.  These are all legitimate product design approaches and tradeoffs.  Another way people see simple is that while you’re designing it you know how it will definitely not appeal to a set of customers.  You can take a bet on convincing people or you can be a bit safer.  Product development is uncertain and only hindsight is 20/20.  For every successful product that is simple, there are a lot of simplicity approaches that did not pan out over time. Minimal can be simple, or just a minimal number of customers.

What can you do?

Evolution

Software is definitely in a new era.  The era of excess configurability or even infinite customization is behind us.  The desire for secure, robust, long battery life along with incredible innovations in hardware that bring so many peripherals on board means that designers can finally look at the full package of software+hardware through a different lens.

If you draw an analogy to the evolution of the automobile, then one might see where the software world is today.  And because we see software and hardware inextricably connected today, let’s say that this applies to the entire package of the device in your hand or bag.

In the golden era, as some would say, of automobiles it was the height of hip to know the insides of your car.  A fun after school project for a guy in high school would be to head home, pop the hood on the Chevy, and tune the engine.  Extra money earned on the side would go to custom parts, tools, and tweaking your wheels.  You expressed yourself through your car.

Then along came the innovations in quality and reliability from car makers in the 80’s.  They saw a different approach.

When I was 16 my father took me to look at cars.  We stopped by the dealer and during the pitch he asked the salesman to pop open the hood. I am sure the look on my face was priceless.  I had literally no idea what to look for or what to see.  Turns out my father didn’t either.  Electronic fuel injection, power steering, and a whole host of other things had replaced the analog cars he knew and loved (and currently drove).  Times had changed.

I have not looked under the hood of a car since.  My expectation of a car is that it just works.  I don’t open the hood.  I don’t service it myself.  I don’t replace parts myself.  I can adjust the seats, set the radio presets, and put an Om sticker on the back.  I want the car’s design to express my personality, but I don’t want to spend my time and energy worrying if I broke the car doing so.  Technology has advanced to the point where popping the hood on a car is no longer a hobby.  The reliability of being able to drive a 2002 Prius for over 100,000 miles without worrying comes with fewer options and customizations, but I got a car that cost less to operate, took less time as an owner to maintain, and was safer in every way.  Sold.

Today’s sealed Ultrabooks and tablets, app stores, and even signed drivers represent this evolution.  Parts that done wear out, peripherals that you don’t need to tune or adjust at the software level, thin, light, robust, reliable.  Sold.

Approach – Point of View

How can you approach this in the products you design? As you can imagine there is a balance.  The balance is between your point of view and making sure you truly meet customer needs.

A point of view has to be one of the best tools of design  A point of view is the reason for being, the essence, the very nature of a product.  In a world where just about every product (but not all) is made of similar ingredients and solve problems that can kind-of, sort-of be solved in other ways, what distinguishes one product from another is a unique point of view that is followed through in the design.

A point of view says who the product is for and why.  A point of view says the benefits of a product.  A point of view says why this product is better, faster, and differentiated in the marketplace.

A point of view also guides you in deciding how to be simple.  Simplicity comes from adhering to your point of view.  If you have a clear point of view then simplicity follows from that.  Is something consistent with your point of view?  If so then it sounds like a candidate.  If not, then why are you considering it?  Is your point of view changing (it can, but be careful)?

But we don’t all have the luxury of declaring a point of view and sticking to it.  You can share your point of view with customers, or potential customers.  You can articulate your point of view to the market.  You can also adapt and change.  The market also adapts and changes.

That’s why product development is so exciting and interesting.  The answers are not so simple and the journey is complex, even if the goal is product simplicity.

–Steven

PS: Interested in a Harvard Business teaching case study on this topic, then perhaps check out http://www.hbs.edu/faculty/Pages/item.aspx?num=34113 (Microsoft Office 2007).  This is a paid link for which I receive no compensation.