Application Teams Can Deliver A Better User Experience (Part 3: Managing Scope)

Back in the good ‘ol days, application development endorsed a “more is best” model, with features being thrown in willy nilly so the product owners could proudly declare “but wait…there’s more!” Even today, many enterprise application projects unapologetically include the phrase “rich feature set”; as if that were a good thing. Sometimes it is — but not often. Features are important, but narrowly scoping those features can make them more usable and the resulting applications simpler. Simpler applications are easier to build with a great UX. Monolithic applications can deliver a great UX, and some examples of such applications do exist, but they are the exception to the rule.

Simpler is always better, well…

Sure, tackling too few use cases could result in an application not being useful, but this is rarely a risk for most application development. Far more often, development teams tackle too many use cases at the request of project sponsors. Remember, new features can always be prioritized and added later, but it is way more difficult to remove features once some of your users have grown accustomed to using them … or to even determine which features to remove.

I would argue that the success of most applications depends partly on their design simplicity and narrowly focused use cases. Purposeful design matches better with people’s mental models and therefore delivers a better UX than applications that attempt to enable too many tasks.

Aggressively Limit Use Cases

Delivery teams should seek to limit scope as much as possible, especially for individual development iterations or project releases. In agile development environments, it is even more essential to narrow scope. In fact, I strongly recommend focusing on just one or two use cases at a time. Once a use case is fully implemented, sponsors should take a step back and question whether additional functionality is needed. Ask these questions with regard to remaining use cases:

  • Should these be separate applications?
  • Are they critical for the adoption of this application?
  • Do I need more data regarding user behavior to decide whether additional use cases are even necessary?

There is no downside to narrowing scope

One of my recent clients nailed it on the head … “It sounds obvious to say that simple is better, but in practice, it’s really hard. To limit features in a meaningful way, you need to have a much better handle on what users really need. We…[launched]…after we had implemented only the most important handful of user stories. By forcing that priority in a severe way, we managed to shove a lot of features down on the list. By ignoring [features] that had no clear meaningful personas or scenarios attached to [them], we found that nobody missed the features after launch. And for those cases where we did find missing features that were valuable and important, we were thorough in examining the desired outcomes. In many cases, they just didn’t belong in the portal at all, and instead were made into their own applications.”

A simple, intuitive application is unlikely to grow from a whiteboard prototype that confuses the heck out of your development team. When prototyped ideas seem overly complex, it is time to reduce the functionality being tackled. Instead, by focusing prototyping sessions on individual scenarios and possibly even limiting applications to a couple (or even one) scenario, prototyping can be more effective and detailed.

Use what you already know

Personas and scenarios should inform all scoping, particularly if they themselves have been prioritized. In some cases, it may be useful to limit the personas being addressed by a project to only one or two in order to give use cases a laser focus.

User studies can help in a project. Without the insight into user needs, teams may add features in order to increase the odds of success — mistakenly thinking that users might find something of value amid a massive feature set. Here’s a hint: they probably won’t be able to find it in the mess anyway. User studies reveal the relevancy of all features, making prioritization and the resulting simplification easier.

Additionally, analytics and user studies can reveal unnecessary complexity where it might exist. If users coming to your application are only there because it is the “company site,” they are forced to then determine where to go to accomplish a given task. By treating each task logically as a separate application, designs can be explored that make such tasks easier to find and accomplish.

Of course, simplicity gained from multiple applications must be balanced with the complexity incurred with many applications. Will users need to switch between applications to accomplish a given task? For example, is information in one application needed by another, requiring users to copy and paste data? By focusing on scenarios — which should describe such common workflows in detail — such trade-offs can be avoided by building applications that focus on tasks and outcomes rather than features.

This post is the third in a five part series. Next: Application Teams Can Deliver A Better User Experience (Part 4: Prototyping)