Approaching complexity
Often in product and design, we see complex and simple as opposite ends of a spectrum. We strive to create simple products and view complexity as the enemy of good design. But the reality is that it’s not that simple.
For every task, there is a necessary amount of complexity. For example, to slice a potato you need a potato and a knife. Then you push the knife through the potato. You can’t reduce this further without altering the outcome.
Whereas, simplicity is an intangible feeling. Your perception of ease based on that interaction. Was the knife sharp enough? Did you hold the knife correctly? Did you have a flat surface to reduce the risk of injuring yourself? Simplicity doesn’t come from removing necessary complexity but from complexity more usable.
In pursuit of value we’ll almost always create complexity in our products. This could be threads in a chat, recurring purchases for common items or adding optional attendees to an invite. Complexity is very often the manifestation of value and that’s fine.
But, when complexity isn’t considered or we don’t understand the system it exists within that can create complications. This is what we want to avoid.
How can we prevent complications?
Understanding a person’s mindset and how the systems behind the scenes work make this easier. Once we have that then we can apply some of these approaches.
Reframe the complexity
A system needing information in a particular way shouldn’t mean we’re constrained to that. We should reframe those requirements in a way that aligns with how peoples process that information.
Use common language
Every company has its own “insider” terminology but, speaking the user’s language goes a long way. It helps to minimise confusion and gives them the confidence to move forward.
As an example: When sending money to a savings account, internally we call this a “Deposit”. However, speaking with customers showed that they refer to this as “Topping up”. So that’s the terminology we should use when we talking to customers about deposits.
Expose complexity in favour of clarity
Sometimes hiding complexity can lead to confusion. If a person is unsure why we’re asking something they’ll be reluctant to answer. For example, when opening an ISA (Tax-efficient account) you’re asked to provide your national insurance number. This is a personal number that many people do not feel comfortable giving out. Yet, companies do need this for tax reporting purposes.
By explaining to people how we use their information we reduce that reluctance.
or shift it below the surface.
Once you understand the system behind the interaction you can look to shift the complexity off of the user and onto your product. An example of this is postcode lookup. Instead of typing their whole address we can ask for only the postcode and return a list of addresses to choose from. Reducing the amount of work a person has to do
Putting these into practice
Let’s look at running a person’s details through an identity check. As part of this, we need to provide a 3rd party with a person’s address and how long they’ve lived there for.
The 3rd party system expects to receive a duration formatted as years and months, for example, Years: 1 & Months: 3. We could ask our customers to fill this in for us. But, after speaking with people that’s not how they think. They aren’t machines counting the time they’ve spent living somewhere. Instead, they have memorable dates like the day they moved in or the day they brought home their puppy.
If asked to tell us how long they had lived at their address they’d first need to work it out. Taking the date they moved in and counting the time between then and today. For someone who moved in on the 22nd November 2017 their thought process would likely look something like this:
From 22nd November 2017 to the 22nd November 2019 is 2 years and then…
from 22nd November 2019 to the 8th September 2020 is 9 months (+ some remainder of days)
For most people this isn’t difficult but, does complicate things. Adding the need for time-consuming, error-prone mental arithmetic.
Instead, we can reframe the question to match the user’s way of thinking and ask them “When did you move in?” This removes a lot of the work a person would need to do and reduces the chance of an error from an incorrect answer.
We can then shift that complexity below the surface onto our systems. Which will work out the difference between the date provided and right now. Along with converting it to the correct format and passing it on to the 3rd party.
Complexity in our products is — for the most part — inevitable. It reflects the richness and nuance of the experiences we’re creating. Rather than trying to avoid complexity, we should be making conscious decisions about how we surface it.
If you liked this I’d highly recommend buying a copy of Living with Complexity by Donald Norman. I read it a few years ago and it’s stuck with me ever since, inspiring this article. You can find me on Twitter as @Petr_ie
And finally, a huge thanks to Charlie Pearce for the illustration and Alex, Zulfi and Ana for their comments and feedback! 🎉
