The best products don’t focus on features, they focus on clarity. Problems should be fixed through simple solutions, something you don’t have to configure, maintain, control. The perfect solution needs to be so simple and transparent you forget it’s even there.
However, elegantly minimal designs don’t happen by chance. They’re the result of difficult decisions. Whether in the ideation, designing, or the testing phases of projects, UX practitioners have a critical role in restraining the feature sets within our designs to reduce the complexity on projects.
Why you should reduce complexity in scope
Over-designed and complex products typically stem from a ‘more is better’ philosophy. Expanding the feature count beyond what’s truly needed is perceived to increase the overall value. Essentially, increasing scope has connotations of giving your audience flexibility. Equally, reducing scope implies you’re limiting your customers.
If we begin to discuss scope as complexity, instead of flexibility, it changes the conversation as it reinforces there’s a correlation between the two. Indeed, they’re really the same thing. Complexity is scope. Every new feature creates additional guesswork. To put it bluntly, increasing scope means there’s more opportunity to screw things up.
As well as making things more difficult upfront, unnecessary features set up additional complexity with future releases. This is because the user interface groundwork early in projects establishes constraints. We have to live with the consequences of our initial design decisions through future iterations. So a tight focus on features early on is crucial. The alternative, trying to solve too much too soon, means initial design decisions become high risk.
As well as reducing the technical complexity, an elegantly minimal feature set clarifies the proposition of your product and simplifies the experience for the user. Any feature that doesn’t help solve problems for your audience should be thought of as a distraction, an unnecessary obstacle that undermines the value of your product.
Properly defining scope
Where to define the scope isn’t easy. Different users will have varying requirements. There’s also the grey area, where removing functionality can result in a drop in the value and revenue of your product.
Also, simplifying a design to reduce it’s perceived complexity doesn’t always work and can create significant barrier for users. A good example is financial software, where the user interface is built around tasks which are inherently complex.
However, simply because a task is complex doesn’t create an excuse for designing a complex user interface or user experience. We should architect solutions around how much control is truly needed. Truly exceptional experiences are crafted when complexity is removed whilst the level of power and control is maintained.
Preventing scope creep
Once your initial scope (or the level of complexity you’re comfortable with adopting) has been defined, the best approach is tackle one feature at a time. Design the first iteration around the most critical and well understood problem.
From this approach additional features can often feel like a simple and natural extension, an easy way to make extra revenue. Despite the sometimes low cost of designing additional features, there are hidden costs.
Unnecessary features are a distraction for developers and designers. They draw people away from optimizing the little details or other things you could be doing to help your existing customers. They also dilute the core proposition of your product and the prominence of the most important features.
Clearly understand what new features you need to add and what the implications of developing them are. Classify features into mandatory and nice to have and the put all the mandatories through a review to ensure they really are mandatories. Ultimately, you have to accept there’s a gray area where, as you strip out features, the expected revenue will fall.
Why you should reduce internal design complexity
Complexity cannot simply be expressed by feature creep. It can still exist within a minimal viable product, as features themselves can behave in unnecessarily complex or unconventional ways.
Despite successfully restricting a tight constraint on features to an elegant minimum, we need to think about the complexity of the features themselves. This can lead to instances where the most appropriate remedy to internally complex features is an additional feature.
Here’s an example. On a recent project, a client insisted on an autosave function for a particular part of an interface when the addition of a save button would have made the interaction and its outcome much more intuitive to the user (as testing later confirmed).
The increased complexity of expanding the scope of the minimum viable product was offset by the decreased internal design complexity of aspects of the system’s technical and user interface.
So, a minimal feature set doesn’t necessarily translate into a simplified user interface. Cumbersome interactions or poorly designed user journeys can easily offset the benefits of removing unnecessary features. Equally, it’s sometimes necessary to expand the system’s scope to to reduce the internal design complexity of certain features.
“What happens to user experience in a minimum viable product?”, by Ryan Singer, http://feltpresence.com/articles/9-what-happens-to-user-experience-in-a-minimum-viable-product
“The Dirtiest Word in UX: Complexity”, by Francisco Inchauste, http://uxmag.com/design/the-dirtiest-word-in-ux-complexity
“Uncertainty and Scope”, by Ryan Singer, http://feltpresence.com/articles/4-uncertainty-and-scope
“How Instagram Stays in Focus”, by Joshua Porter, http://bokardo.com/archives/how-instagram-stays-in-focus
“Flashback: Every time you add something you take something away”, by 37signals, http://37signals.com/svn/posts/2917-flashback-every-time-you-add-something-you-take-something-away
Managing internal design complexity
Managing ‘internal design complexity’ relies upon a paradox. The phrase implies the complexity of any given single feature. However, the significance of ‘internal’ complexity is not constrained to a single feature. Managing internal design complexity requires us to assess the solution at two levels simultaneously. Only through critical end-to-end analysis of the solution can we make a similarly effective judgement about whether any single feature is as simple as it can—or crucially—should be.
When looking at a feature set and deciding what can be safely eliminated without endangering core goals, reductionism is a double-edged sword., Taking the simpler view inherent in the ‘Minimal Viable Product’ mentality will result in cleaner, easier, more elegant and achievable designs. No less regularly, however, the process of reduction blinds us to unseen compromises in the functional simplicity of the solution as a whole.
The broader, zoomed out view may actually guide us to adding function to a feature here or there, all in the service of simplicity at the more general level.
Take the above example of the autosave function: the complexity of correctly intuiting the behavior of this single feature is one thing. Adding a function to the feature reduces the chance of the feature being misunderstood or misused. Beyond that, however, it would also have ensured that the instance of counter-intuitive behavior does not set precedents for how the wider solution is perceived.
This is the paradox: you can have the most elegantly minimalist feature set imaginable, but you will not attain simplicity if you don’t apply the principle of simplicity both holistically and flexibly. Features that are simple in isolation can become a contagion.
A core difficulty with discussing complexity and user interfaces is that it’s easy to misclassify the level of complexity. It’s a qualitative concept. As such, it’s important to keep a check on the subjective nature of our discussions. We have to be aware that complexity can only be reduced to a particular point, past which designs can lose both their utility and appeal.
It’s also not whether a design approach is more or less complex. The issue is that we’re talking about the experience of the system, not a quantitative measure of complexity. Ultimately, to determine the impact of scope complexity and internal design complexity across the overall user experience, complexity needs to be understood within a context.
The result is that many of the discussions on complexity and simplicity are polarized around whether or not complexity is an additive property. But, perhaps there’s nothing wrong with that, you should have a clear opinion on the products you make. Software should have your personality ingrained within it.