I recently conducted research which revealed that we had failed to consider one of the most important questions for our users: what’s next?  During the research, users successfully got through each individual step.  When it was time to transition to the next step, they couldn’t figure out what to do.  They knew what their end goal was, they couldn’t figure out how to get there.  One of my recommendations to the team is to consider how we will guide the user through the whole process so that people can accomplish what they set out to do.

When we develop applications, we break workflows up into features, and we often break up features into smaller pieces.  This process helps us build software.  It’s very easy for this process to make its way into the interaction design process: we design part of a workflow, and forget to design the glue between the individual parts of the workflow that turns it from a string of features into a workflow that helps users accomplish their goal.

Laura Klein looked at this problem from the other direction: coming up with an idea to improve your product, and then watching it get bigger and bigger as you consider what happens next.  Nothing exists in a vacuum.  There is always something that happens next.  A successful product considers what happens next, and sets its users up for success in getting to that next step and accomplishing what they really want to accomplish.

User researchers are always asking for favors of people.  It’s the nature of research.  You’re asking your design team to help you get prepared for the research, often creating or helping to create the materials that you’ll use in your research.  You’re asking your participants to give up some of their time to be poked and prodded by you¹.  You’re asking your application team to make changes to their plans based on what you’ve learned in your research.  It can make a user researcher feel like they’re always taking and never giving.  It’s not true, of course: your work gives your designers and application team better insight, which results in a better product for your users.

I know that I’m asking a lot from many other people as I do my work.  As I’m doing so, I remember to thank them for their work.  I thank my participants for taking the time to talk with me.  I thank the design team for working with me and ensuring that we had the right design artifacts to share with study participants.  I thank the application team for helping me understand what they need to know, what they have time to implement, and how my work fits into their development cycle.  I thank everyone for being involved with the work, for sharing their thoughts and ideas, for listening to what we learned and asking questions to clarify points, and for sharing their thoughts and ideas for how we move forward.

Remembering these simple courtesies helps smooth the way for a user researcher.

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 Messenger¹ 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 feature² that truly meets our users’ needs and helps them accomplish their goals easier and with less cognitive load.