\u201cSimple Design\u201d 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.<\/p>\n
We easily recognize that successful products have to match their users\u2019 mental model<\/a> to feel simple. But each product has a second audience that we tend to ignore: the team working on it.<\/p>\n When designing, we optimize for the user, and that\u2019s fair, but the team also has to deal with the product in order to maintain it, and that\u2019s 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.<\/p>\n Once your software is a certain size, you’ll be completely dominated by complexity.<\/p>\n 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<\/em> the product.<\/p>\n In practice, complexity can be a real mental burden for the team. Each decision requires thinking about multiple facets: it\u2019s harder for designers to keep the entire product in their head, it\u2019s harder for engineers to think about side effects, it\u2019s harder for customer support to understand and to explain how the product is supposed to work, it\u2019s harder for analysts to find which part impacts the measures, it\u2019s 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.<\/p>\n Cumulatively, this gets between the team and the product \u2013 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, \u201conce your software is a certain size, you’ll be completely dominated by complexity\u201d<\/a>.Defining complexity<\/h2>\n
\n