5 Sep 2011

We recently covered the topic of complexity in UI design. Particularly, how as UXers, we have a critical role in restraining the feature sets within our designs in order to reduce the 'scope complexity' on projects.

Less is less

First, this reduces risk. More features results in more guesswork. Tackling this increased complexity early in projects can easily constrain future design decisions and be a killer for projects. Essentially, creating the simplest possible design means there's less opportunity to screw things up.

Additionally, focusing on a tight feature set clarifies the proposition of your product and simplifies the experience for the user. In creating the minimal viable product (MVP), you're addressing the core needs of the user and stripping away unnecessary distractions.

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.

However, starting out with the minimal viable product is always more attractive. Complexity is incredibly difficult to strip away once your product has been launched, where you need to overcome customer inertia and challenging technical issues.

Thinking beyond scope complexity

"Complexity isn't expressed merely by feature creep, but also by any feature that behaves in an unnecessarily complex or unconventional way."

An interesting discussion that came out of our recent post on UI complexity was around other ways complexity can be defined. 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.

So, 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 inevitably 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 MVP was offset by the decreased internal complexity of certain technical and UI aspects of the system.

So, a minimal feature set doesn't necessarily translate into a simplified UI. 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 complexity of certain features.

Managing internal complexity - zoom out

Managing 'internal 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 complexity requires us to assess the solution at two levels simultaneously. Only through critical analysis of the solution end-to-end 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. Often, 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 behaviour 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 behaviour 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.

Wrap up

In order to determine the impact of scope complexity and internal complexity across the overall user experience, complexity needs to be understood within a context. Despite this, many of the discussions on complexity and simplicity are polarised around whether or not complexity is an additive property.

"The best software has a vision. The best software takes sides. When someone uses software, they're not just looking for features, they're looking for an approach."

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. Our intention is to continue to push clarity within our products, through a strong emphasis on an elegant minimal viable product.