Learning by Shipping

products, development, management…

Designing for scale and the tyranny of choice

with 13 comments

Movie still from American Graffiti showing fancy hot rod carA 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.

Written by Steven Sinofsky

March 19, 2013 at 11:30 am

Posted in posts

Tagged with , ,

13 Responses

Subscribe to comments with RSS.

  1. Јe uis entièrement en accotd avec toi

    salopes asiatiques

    September 24, 2014 at 5:53 pm

  2. Paragraph writing is also a excitement, if you know then you can write if not it is difficult to
    write.

    http://www.youtube.com/

    September 19, 2014 at 12:15 am

  3. Nice post. I learn something totally new and challenging on sites I stumbleupon everyday.
    It’s always exciting to read content from other writers and practice a little something from other websites.

    memoria usb barata

    July 12, 2014 at 8:24 am

  4. It’s hard to find your page in google. I found it on 12
    spot, you should build quality backlinks , it will help you to rank to
    google top 10. I know how to help you, just type in google – k2 seo tips

    Marti

    July 10, 2014 at 7:09 pm

  5. Aw, this was a really nice post. Taking a few minutes and actual effort to
    create a really good article… but what can I say… I procrastinate a whole lot and never manage to get anything done.

    Stephanie

    May 24, 2014 at 7:37 pm

  6. It’s awesome too visit this site and reading the views of
    all mates on the topic of this paragraph, while I am also zealous of getting familiarity.

    www.psautotransport.com

    April 10, 2014 at 12:11 pm

  7. Generally I don’t read post on blogs, however I would like to say that
    this write-up very compelled me to try and do so! Your writing taste has been surprised me.
    Thank you, quite nice post.

  8. You make more money deciding what not to do than deciding what TO do. Adding a feature depends on having a known real customer willing to pay for it, rather than on millions who might want it for free.

    John cadwell

    March 21, 2013 at 9:12 am

  9. One of the hardest things in life is to say NO, to a meeting you have been invited to, to your kids, or to a party you don’t want to go. Arguably saying NO defines who we are more than saying YES, though there is a balance. It is important to stand by our principles and have the hard conversations but to always settle on a point of view and march to it. This is the same for software development but unfortunately human nature is to ‘people please’ and take the easy option which is to fudge the hard questions along the way and design a product based on the what if’s, to just add/enable the feature to be on the safe side, or add for a scenario we are unsure about. This ultimately leads to a product without a true identity (a schizophrenic product) and one that is inherently complex in terms of development, sustaining and most importantly usage. Today’s software products are expected to be intuitive and for them to be intuitive they need to be simple and clear on what their purpose is. The principle we start out with may not be the one we finish on but it better be a clear, minimal ambiguity and reasonably narrow. Too much and it will just go over the customers head. What jumps out from this post more than anything is the need to make those hard calls and not fudge the questions and to maintain focus. Things get ambiguous, there is uncertainty, that is life, and we deliver product to get feedback and act on it though acting on feedback is much tougher than people think. The easy option is to say ‘lets get it out there and then iterate’, great idea but much harder to do in practice and for that to work we again need to be focused and have narrow lenses.

    DesWalker

    March 21, 2013 at 8:34 am

  10. Steven, thank you for an insightful article. My experience almost exactly matches yours.

    (Typo: “done” should read “don’t” – paragraph before “Approach – Point of View”)

    Gus Gustafson

    March 21, 2013 at 8:32 am

  11. For storage and bandwidth constrained platforms, code size can have a cost too; I’m seeing complaints from iOS users about 1Gb updates for what sound like basic changes to apps (almost certainly because of images sized for retina screens, because assets are part of code size at the point of delivery). Is that another simplicity /complexity matrix for platform aggregation versus specific delivery? One app versus one app per different platform skus…

  12. One result of this “Evolution”, in both Motor vehicles and software, is that they cost more to maintain. Used to be, if something broke it could be fixed. These days, things have to be replaced. That costs money and there are environmental costs, as well. Of course, since current economic philosophy is that infinite growth is required, this is the direction that businesses go…
    (And, on a personal note, my Browser was just automatically updated to a new Version resulting in a massive drop in productivity for me. It has some Kind of automatic spell check going that’s randomly capitalizing words and underlining everything. But I can’t find a CHECKBOX in the Options to turn the behavior off! That’s Progress for you, and I may just Switch to Chrome or Firefox because of it.)

    Cindy Meister

    March 19, 2013 at 11:53 pm

  13. I don’t disagree with a lot of what you’ve said here, but there’s still a difference between a car and a computer, even in this modern age. Users of a car generally expect it to be capable of one or two concrete tasks: Getting them to where they want to go, and possibly carrying their cargo with them while they go there.

    The number of things users expect a computer to be able to do are not enumerable. Providing a simplified “do only what I think you need to do” model is great (and I’m all for it) but removing even the *option* of doing anything outside of that sandbox limits the utility of the computing device.

    (As a car analogy: If I wanted to make a modification to my Prius for some reason I can still do it — it’s just more difficult and will void my warranty. If I want to make a modification to my Windows RT tablet to enable me to solve my particular problem it is basically impossible, I am at the mercy of Microsoft to add the feature I want (and then never decide to cut it because I’m only one of 5% of people who use it and don’t matter anymore.))

    Anonymous

    March 19, 2013 at 2:13 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s