“Simple Design” when building products is probably the most common leitmotif in tech companies. Yet we often only see one side of the problem when talking about product simplicity and/or complexity.
We easily recognize that successful products have to match their users’ mental model to feel simple. But each product has a second audience that we tend to ignore: the team working on it.
When designing, we optimize for the user, and that’s fair, but the team also has to deal with the product in order to maintain it, and that’s not something we should overlook. Because complexity has a huge negative effect: it makes the team slower, less motivated and less efficient. Which ultimately translates in less value for the end user.
Defining complexity
Once your software is a certain size, you’ll be completely dominated by complexity.
First, it might be interesting to define complexity. The thing I love with etymology is that it opens a window on the essence of ideas. The word “complex” comes from two latin words “com” (“together”), and “plectere” (“to entwine”). And if you look in the dictionary, you’ll probably find the words “many” and “parts” somewhere in the definition. Complexity is about entwining many parts together, making it harder to understand them as a whole because of their increased amount, as well as individually because of their new entanglement. The key word here is “understanding”. Complexity prevents understanding. And if a lack of understanding for the end user means difficulty to use the product, a lack of understanding for the team means difficulty to change the product.
In practice, complexity can be a real mental burden for the team. Each decision requires thinking about multiple facets: it’s harder for designers to keep the entire product in their head, it’s harder for engineers to think about side effects, it’s harder for customer support to understand and to explain how the product is supposed to work, it’s harder for analysts to find which part impacts the measures, it’s harder for the QA team to go through all the edge cases, it just makes it harder for the entire company to deliver value to the customers.
Cumulatively, this gets between the team and the product – the scale of the mental model required reduces their motivation to keep engaging with the product. As explained by Rich Hickey in this great talk, “once your software is a certain size, you’ll be completely dominated by complexity”.
Simple design and justifying complexity
Of course, some products are intrinsically more complex than others. But we should fight to minimize the “unnecessary complexity”, the complexity that isn’t justified by its value.
Features that don’t see enough usage, concepts that can be removed, steps that can be merged, literally anything that is not required. Good companies simplify for the user, great companies also do it for the team. The tricky thing is that both audiences are not affected in the same way by complexity. You might decide that it’s worth adding a new feature because the complexity cost doesn’t seem too big for the end user, but it might be very different for the team. There is no perfect solution to estimate the impact of complexity on the team, but the first step is to be aware of this question when making design decisions. The team (and the designer first) needs to develop a sensibility for complexity, a sense of vigilance for things that could be removed or decoupled.
Good companies simplify for the user, great companies also do it for the team.
The worst part of the problem is that the more complexity we add, the harder it becomes to simplify and to come back from it. Working on everything, even simplification, now takes more time and energy. It’s a vicious circle that creates exponential complexity.
As Hickey puts it, “simplifying is the most important work that we do, because doing this makes the rest of the work substantially and deeply easier”. But how do we simplify?
Untangling the elements
If we go back to our initial definition of complexity (“many” parts “entwined” together), it seems that there are two very high level ways to prevent it: one is to fight the “many” by reducing the amount of parts to the core essential, the other is to fight the “entwined” by untangling those remaining essential parts – in other words, to make the parts as few and as independent as possible.
Removing and untangling can be applied at many different levels of the product: removing features, concepts, content, visual effects, animations, steps, rulesets, etc; untangling the UI by composing screens and pages with modular components; untangling the onboarding experience by reusing screens and steps from the actual product.
Defining a clear conceptual model of the product can be a great simplification exercise.
First, you’ll never be able to map the entirety of your product, and even if you were, the benefits of this representation would become very questionable, (as brilliantly illustrated by Jorge Luis Borges’ short parable “On exactitude in Science”. So you’ll have to focus on the core parts: the main concepts, their most important properties, the main relationships between them. Removing or merging will become a necessity.
Secondly, you’ll get a clearer picture of the role of each concept in your product: how they will interact with each other, all the different places and contexts where they will be used. Decoupling and making everything more modular will become natural.
Avoid short-sighted thinking that would trap the team into a complexity hole.
Renowned UX designer Sophia Voychehovski Prater suggests a concrete method to approach this question. In a workshop that she ran with our product team at Intercom, she demonstrated that modelling a product, even as complex as Intercom, is a totally realistic exercise as long as it’s done with the proper tools.
Designing for simplicity
That probably sounds very abstract (and it is at this stage), but this exercise can help the team to build a simpler mental model of the product, enabling them to make more informed decisions, not only weighing the pros against the cons from the end user’s perspective, but also from their own understanding: how would adding this feature impact the conceptual model? Do we need to create a new concept, or can we reuse an existing one? Will that make these two parts more dependent? Are we entangling two concepts that could be separated?
That’s not easy work, but it’s definitely worth the effort. The goal is to avoid short-sighted thinking that would trap the team in a complexity hole. Look one step ahead when making design decisions; think about the user first, but don’t forget the impact of complexity on the team, or you might doom the product to slowly growing paralysis.
If this sounds like the sort of design challenge that you’d be excited to work on, we’re hiring designers.
Comments