Learning by Shipping

products, development, management…

Posts Tagged ‘design

Avoiding mobile app bloat

Nemo BloatrBack in the pre-web days, acquiring software was difficult and expensive.  Learning a given program (app) was difficult and time consuming.  Within this context there was an amazing amount of innovation.  At least in part, these constraints also contributed to the oft-cited (though not well-defined) concept of bloatware.  Even these constraints do not seem particularly true on today’s modern mobile platforms, we are starting to see a rise in app bloat.  It is early and with enough self-policing and through the power of reviews/ratings we might collectively avoid bloatware on our mobile devices.

Product managers have a big responsibility to develop feature lists/themes that make products easier to use, more functional, and better overall–with very finite resources.  Focusing these efforts in ways that deliberately deprioritize what could lead to bloatware is an opportunity to break from past industry cycles and do a better job for modern mobile platforms.  There are many forms of bloat across user experience, performance, resource usage and more.  This post looks at some forms of UX bloat.

This post was motivated by a conversation with a developer considering building an “all in one” app to manage many aspects of the system and files.  This interesting post by Benedict Evans, http://ben-evans.com/benedictevans/2013/9/21/atomisation-and-bundling about unbundling capability and Chris Dixon’s thoughtful post on “the internet is for snacking” http://cdixon.org/2013/09/14/the-internet-is-for-snacking/ serve as excellent motivators.


The first apps people used on PCs tended to be anchor apps–that is a given individual would use one app all day, every day.  This might have been a word processor or a spreadsheet, commonly.  These apps were fairly significant investments to acquire and to gain proficiency.

There was plenty of competition in these anchor apps.  This resulted in an explosion in features as apps competed for category leadership.  Software Digest used to evaluate all the entries in a category with lists of hundreds of features in a checklist format, for example.  This is all innovation goodness modulo whether any given individual valued any given feature. By and large, the ability for a single (difficult to acquire and gain proficiency) product to do so many things for so many people was what determined the top products in any given category.  

Two other forms of innovation would also take place as a direct result of this anchor status and need to continue to maintain such status.

First, the fact that people would be in an app all day created an incentive for an ISV to “pull into” the app any supporting functionality so the person would not need to leave the app (and enter the wild world of the OS or another app that might be completely different).  This led to an expansion of functionality like file management, for example.  This situation also led to a broad amount of duplication of OS capabilities from data access to security and even managing external devices such as printers or storage.

As you can imagine, over time the amount of duplication was significant and the divergence of mechanisms to perform common tasks across different apps and the OS itself became obvious and troublesome.  As people use more and more programs this began to strain the overall system and experience in terms of resources and cognitive load.

Second, because software was so hard to use in the early days of these new apps and paradigms there was a great deal of innovation in user experience.  Evolving from command line to keyboard shortcuts to graphical interface.  Then within the graphical interface from menus to toolbars to palettes to context menus and more.  Even within one phase such as early GUI there were many styles of controls and affordances.  At each innovation junction the new, presumably easier mechanism was added to the overall user experience.

At an extreme level this just created complete redundancy in various mechanisms. When toolbars were introduced there was a raging debate over whether a toolbar button should always be redundant with a menu command or never be redundant with a menu command.  Similarly, the same debate held for context menus (also called shortcut menus, which tells you where that landed).  Note a raging debate means that well-meaning people had opposing viewpoints that each asserted were completely true, each unable to definitively prove any point of view. I recall some of the earliest instrumented studies (special versions of apps that packaged up telemetry that could later be downloaded from a PC enlisted in the study) that showed before/after the addition of redundant toolbar buttons, keyboard shortcuts, and shortcut menus.  Each time a new affordance was added the existing usage patterns were split again–in other words every new way to access a command was used frequently by some set of people.  This provided a great deal of validation for redundancy as a feature.  It should be noted that the whole system surrounding a release of a new mechanism further validated the redundant approach–reviews, marketing, newsgroups, enthusiasts, as well as telemetry showed ample support for the added ways of doing tasks.

As you can imagine, over time the UX became arguably bloated and decidedly redundant.  Ironically, for complex apps this made it even more difficult to add new features since each brand new feature needed to have several entry points and this toolbars, palettes, menus, keyboard shortcuts, and more were rather overloaded.  Command location became an issue.  The development of the Office ribbon (see JensenH’s blog for tons of great history – http://blogs.msdn.com/b/jensenh/) started from the principle of flattening the command hierarchy and removing redundant access to commands in order to solve this real-estate problem.

By the time modern mobile apps came on the scene it was starting to look like we would have a new world of much simpler and more streamlined tools.  

Mobile apps and the potential for bloat

Mobile app platforms would seem to have the foundation upon which to prevent bloat from taking place if you consider the two drivers of bloat previously discussed. Certainly one could argue that the inherent nature of the platforms intend for apps to be focused in purpose.

First, apps are easy to get and not so expensive.  If you have an app that takes photos and you want to do some photo editing, there are a plethora of available photo editing apps.  If you want to later tag or manage photos, there are specialized apps that do just that.  While there are many choices, the web provides a great way to search for and locate apps and the reviews and ratings provide a ton more guidance than ever before to help you make a choice.  The relative safety, security, and isolation of apps reduces the risk of trial.

Second, because the new mobile platforms operate at a higher level of abstraction the time to learn and app is substantially reduced.  Where classic apps might feel like you’re debugging a document, new apps building on higher level concepts get more done with fewer gestures, sometimes in a more focused domain (compare old style photo editing to instagram filters, for example).  Again the safety afforded the platforms makes it possible to try things out and undo operations (or even whole apps) as well.  State of the art software engineering means even destructive operations almost universally provide for undo/redo semantics (something missing from the early days).

Given these two realities, one might hope that modern mobile apps are on a path to stay streamlined.

While there is a ton of great work and the modern focus on design and simplicity abounds in many apps, it is also fair to say that common design patterns are arising that represent the seeds of bloat.  Yet the platforms provide capabilities today that can be used effectively by ISVs to put people in control of their apps to avoid redundancy.  Are these being used enough?  That isn’t clear.

One example that comes to mind is the share to verb that is commonly used.  Many apps can be both the source and sink of sharing.

For example, a mail program might be able to attach a photo from within the program.  Or the photo viewer might be able to mail a photo.

It seems routine then that there should be an “attach” verb within the mail program along with the share verb from the photo viewer.  On most platforms this is the case at least with third party mail programs as well.  This seems fast, convenient, efficient.

As you play this out over time the the mail program starts to need more than attach of a photo but potentially lists of data types and objects.  As we move away from files or as mobile platforms emphasize security the ability for one app to enumerate data created by another makes this challenging and thus the OS/apps need to implement namespaces or brokers.

The other side of this, share to, becomes an exceedingly long list of potential share targets.  It becomes another place for ISVs to work to gain visibility.  Some platforms allow ISVs to install multiple share targets per app and so apps show up more than once.  On Android there is even a third party app that is quite popular that enables you the ability to offer to manage this list of share targets.  Windows provides this natively and apps can only install as a single share to target to avoid this “spamming”.

As an app creator, the question is really how critical it is to provide circular access to your data types?  Can you allow the system to provide the right level of access and allow people to use the native paradigms for sharing?  This isn’t always possible and the limitations (and controls) can make this impossible, so this is also a call to OS vendors to think through this “cycle” more completely.

In the meantime, limited screen real estate is being dedicated to commands redundant with the OS and OS capabilities might be overloaded with capabilities available elsewhere.

A second example comes from cross-platform app development.  This isn’t new and many early GUI apps had this same goal (cross-platform or cross-OS version).  When you need to be cross-platform you tend to create your own mechanisms for things that might be available in the platform.  This leads to inconsistencies or redundancies, which in turn make it difficult for people to use the models inherent in the platform.

In other words, your single-app view centered around making your app easier by putting everything in the context of your app drives the feature “weight” of your app up and the complexity of the overall system up as well.  This creates a situation where everyone is acting in the interest of their app, but in a world of people using many different apps the overall experience degrades.

Whether we’re talking about user/password management, notifications, sounds, permissions/rights, and more the question for you as an ISV is whether your convenience or ease of access, or desire to do things once and work across platforms is making things locally easier at the expense of the overall platform or not?

Considering innovation

Every development team deals with finite resources and a business need to get the most bang for the buck.  The most critical need for any app is to provide innovative new features in the specific domain of the app–if you’re a photo editing app then providing more editing capabilities seems more innovative than being able to also grab a picture from the camera directly (this is sort of a canonical example of redundancy–do many folks start in the editor when taking a picture, yet almost all the editors enable this because it is not a lot of extra code).

Thinking hard about what you’re using your finite resources to deliver is a job of product management.  Prioritizing domain additions over redundancy and bloat can really help to focus.  One might also look to reviewers (in the App Stores or outside reviewers) to consider redundancy as not always more convenient but somewhat of potential challenge down the road.

Ironically, just as with the GUI era it is enthusiasts who can often drive features of apps.  Enthusiasts love shortcuts and connections along with pulling functionality into their favorite apps.  You can see this in reviews and comments on apps.  Enthusiasts also tend to have the skills and global view of the platforms to navigate the redundancy without getting lost.  So this could also be a case of making sure not to listen too closely to the most engaged…and that’s always tricky.

Designers and product managers looking to measure the innovation across the set of features chosen for a release might consider a few things that don’t necessarily count as innovation for apps on modern mobile platforms:

  • Adding more access points to previously existing commands.  Commands should have one access point, especially on small screen devices.  Multiple access points means that over time you’ll be creating a screen real estate challenge and at some point some people will want everything everywhere, which won’t be possible.
  • Making it possible to invoke a command from both inside-out and outside-in.  When it comes to connecting apps with each other or apps to data, consider the most fluid and normal path and optimize for that–is it going from data to app or from app to data, is your app usually the source or the sink?  It is almost never the case that your app or app data is always the starting point and the finishing point for an operation.  Again, filling out this matrix leads to a level of bloat and redundancy across the system and a lack of predictability for customers.
  • Duplicating functionality that exists elsewhere for convenience.  It is tempting to pull in commonly changed settings or verbs into your app as a point of efficiency.  The challenge with this is where does it end?  What do you do if something is not longer as common as it once was or if the OS dramatically changes the way some functionality is accessed.  Whenever possible, rely on the native platform mechanisms even when trying to be cross-platform.
  • Thinking your app is an anchor so it needs to provide access to everything from within your app.  Everyone building an app wants their app to be the one used all the time. No one builds an app thinking they are an edge case.  This drives apps to have more and more capability that might not be central to the raison d’être for your app.  In the modern mobile world, small tools dominate and the platforms are optimized for swiftly moving between tools.  Think about how to build your app to be part of an overall orchestra of apps.  You might even consider breaking up your app if the tasks themselves are discrete rather than overloading one app.
  • Reminding yourself it is your app, but the person’s device.  “Taking over” the device as though your app is the only thing people will use isn’t being fair to people.  Just because the OS might let you add entry points or gain visibility does not mean you should take advantage of every opportunity.

These all might be interesting features and many might be low cost ways to lengthen the change log.  The question for product managers is whether this was the best use of resources today and whether it builds the experience foundation for your app that scales down the road?

Where do you want your innovation energy to go–your domain or potential bloat?

–Steven Sinofsky

Written by Steven Sinofsky

September 24, 2013 at 6:00 pm

Posted in posts

Tagged with ,

Designing for scale and the tyranny of choice

with 16 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.


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.


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?


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.


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 , ,

%d bloggers like this: