the scaling of user experiences

A colleague pointed me at an article by Jonathan Courtney titled “Want the Best User Experience? Make it Harder to Add Features”.  I thought I would read an article that preached to my choir.

I have long advocated delivering fewer and better features over delivering a laundry list of features.  How does a feature fit into the overall user experience?  If we cut part of it, do we negatively impact the user experience?  It is much better to deliver fewer features that create a great user experience, rather than delivering a laundry list of features that don’t quite fit together to meet the user’s needs and goals.

Except the article isn’t actually about being harder to add features.  There is only one sentence that I think comes close to the title of the article, which is this one: “It means that adding features down the line will need to be a careful process of consideration rather than just something that’s tacked on.”  This is dead-on: we shouldn’t just add features to add features.  We should carefully consider how a new feature fits into our existing application and how we can make it fit into our users’ workflow as seamlessly as possible.

Then the author takes us down a completely different path:

We’re at a time when apps and software are becoming more and more focused. Successful companies that previously took the kitchen sink approach have done a u-turn and are now decoupling features to create entirely separate experiences. Foursquare has separated its “checking in” function to Swarm. Facebook created Messages (and many other apps), Path recently released Talk.

Now I see that the article really isn’t about user experience and the number of features in an application.  It is only talking about mobile development, and specifically about social media on mobile.  Even worse, it skips over user reaction to these decisions in mobile social media apps.  A quick glance at the iTunes Store reveals how popular this method is with users. In separating Foursquare into two applications, Foursquare went from having a 4-star rating to a 2.5 star rating, and the new Swarm app has a 1.5 star rating. The current version of Facebook Messenger1 also has a 1.5 star rating. Only Path has retained its 4-star rating, although it’s interesting to note how many of its reviews specifically say that they didn’t use the private message feature before the split (that is, the feature that is now the basis for Talk).

By focusing an application on a single use-case, we run the risk of not thinking about the user’s overall goals and workflow. How do all of these individual use-cases come together to create a workflow? Can users seamlessly continue their workflow, regardless of what application it’s in? Does the concept of single-use application work for desktop or web applications that aren’t social media?  The author provides no evidence.

We should not deliver a laundry list of features, but rather deliver a fantastic experience on a subset of those features. Let’s not deliver 80% of a feature so that we have enough time to get another feature on the laundry list. Let’s deliver 100% of a feature2 that truly meets our users’ needs and helps them accomplish their goals easier and with less cognitive load.

  1. that is, the version where Facebook forced users to use Messenger to send messages; in previous versions of the Facebook and Messenger apps, usage of Messenger was optional.
  2. Okay, maybe 95%.