The complexity epidemic: A guide to building elegant systems

Hayford Owusu Ansah

I would have written a shorter letter, but I did not have the time. - Blaise Pascal.

Everyone can solve a problem. Fewer people can create systems out of the solutions. And even fewer people can simplify a working system for end-users. The process of creating a functional system and simplifying it into something intuitive, something elegant, is a rare skill and art form.

Elegance. The phonetic sound of the word itself is music to the ears. Over time, its meaning has been distilled down into three terms: Grace, Beauty, and Simplicity. The first two tend to overshadow the third. Even in the dictionary, Simplicity is placed as the 2nd definition. But the truth is: there is no elegance without simplicity. Every elegant creature and system I know has simplicity wired into it.

Take the cat, for example. Known for its elegance in movement and posture. The cat employs 3 things in its movement: beauty, gracefulness, and simplicity - so much so that fashion models adopt their walking style (cat walk) on the runway.

Over the years, I sought to understand why simplicity is so rare among system builders. This pattern has proven to be consistent across every team I have worked with. That was when I realized: the ability to build elegant systems is a skill on its own and has nothing to do with the individual’s level of competence. In fact, the more skilled the person, the more unnecessarily complex their systems.

Elegance is not only for the socially elite; like any skill, it can be learned. Read on as we explore the cause of today's complexity epidemic and how to harness the skill to build elegant and functional systems.

ROOT CAUSE ANALYSIS AND RESOLUTION

To cure an epidemic, you must first understand its root cause. Only then can you take preventive and corrective measures.

Below are the main causes for system complexities from my research:

    1. Institutionalization - A fixed mindset on problem-solving
    2. Not being user-centered
    3. Over-engineering of already simple structures
    4. Lack of standardization - Don't reinvent the wheel
    5. Neglecting non-functional requirements
    6. Poor understanding of tradeoffs - Failure to balance pros and cons

Institutionalization - A fixed mindset on problem-solving

A long time ago, before modern cybersecurity laws were established. There was a series of online break-ins by a high school student in the Netherlands into a secure facility. The technical team tried several times to stop him, but to no avail. They eventually reported this issue to the Dutch police, but the police had no grounds to press charges. While the Experts debated technical countermeasures, a rookie cop heard the discussion and simply suggested, 

“Why don’t you talk to the boy's mom?” 

And that was it!! The mom gave the boy a good old-fashioned scolding, and the attacks were no more.

 This story has a powerful lesson: if you work in a system for a while, your mind naturally creates a fixed problem-solution map based on past experiences. Though this helps you solve similar future problems quickly, it prevents you from having a fresh perspective and original ideas when a new problem arises. You will see people creating a convoluted system just to solve a very simple problem, thereby creating technical and operational overhead in the process.

Solution:
  • Get a fresh perspective, especially from non-technical people.
  • Test with real users: Ask them to perform a task without your guidance, pay attention to where they expect things to be - that is where you should have placed them.

Not being user-centered: 

Another common pattern I observed is how often creators fail to consider their users when engineering systems. I always found this bizarre. After all, since your whole profession is to ‘engineer’ solutions for users, not yourself!

To delve deeper, I put on my investigative hat and magnifying glass to get to the root of this. I found the following interesting reasons:

  1. Prove mastery over their craft: 

This was the most common. People in this category intentionally choose the most advanced tool to do the work, not because it is the right fit, but to showcase their mastery over the tool. But they forget: mastery is in the outcome, not the process.

  1. Identity tied to profession: 

If someone asks you to “tell me about yourself,” and all you do is talk about your profession, then your identity is likely tied to your profession. There’s nothing wrong with loving your work, but having a life outside of work gives you a broader perspective and empathy for your end users. Which in turn helps you serve your end users better.

  1. Impressing peers, not End users: 

It is common to see creators and developers work in teams. In an effort to prove our smartness and impress our peers, we tend to come up with smart and complex solutions when we could have used a simple approach to solve the problem. As you mature, you see how childish this is, because a clever system that the average user cannot understand is just a liability

  1. Loyalty to tools, not the outcome: 

I have seen engineers belittle others for using different frameworks, idolize a single tech stack, and launch full-out online wars on which tool is better. I have done it too - I was a Java loyalist (not the coffee ) for years. But as you gain experience, you begin to understand that true engineering is about problem solving, and tools are just that, tools.  Your loyalty should be to your customer, not your tool. That’s it!

As you have probably noticed, none of the above is about the end user. They are about fulfilling our Egos. We focus so much on ourselves that we commit the ultimate sin in engineering - not solving the user’s problem.

Solution:
  • Test your system against your users’ requirements, deliverables and overall user experience
  • Continuously check to see if the user is satisfied. 
  • Be selfless, humble in your craft - Put the user first

Over-engineering of already simple structures

This one was a peculiar and ironic observation. This one is ironic because it comes from those who genuinely try to adhere to best practices but end up overdoing them.

Walk with me here:

Imagine your company has a department consisting of only 3 people. Will you further divide that department into three separate departments with one person each? Absolutely not! You may even consider merging them with another department.

Conversely, if you have a department of 1,000 people. Will you merge it with another department consisting of 300 people? Absolutely not! You will rather break them down into smaller, manageable sub-departments, each with a unique purpose.

There are no hard rules for breaking down structures. It is about discernment. 

In design, we often fall into the trap of applying "best practices" like modularization, abstraction, or separation of concerns—even when the structure is already simple and effective. This makes the best practices counterproductive and makes the system harder to read, harder to navigate, and harder to maintain.

To avoid this, I created a simple  litmus test to help engineers decide whether to break things down or not:

  • Is that logic reused across multiple modules or teams? If yes, then isolate that logic and make it reusable for the others.
  • Is that logic too complex and making your system hard to read? If yes, then isolate it. Give it a clear name that summarizes its purpose.
  • Does the logic satisfy any of the above?, If no, then don't break it up; leave it as it is
Solution:

Understand the reasoning behind that best practice and don’t use it blindly. Best practices are not laws but simply guides.  Know your system, what you want to accomplish, and employ that best practice. Use them with discernment.

Lack of standardization - Don't reinvent the wheel

There are times I have been forced to adopt standards. I always thought they were a bother till I found the wisdom behind it.

Consider this:

If I write 07/08/12, do I mean:

  • 7th August 2012  
  • July 8th 2012? 
  • Or even 12th August 2007? 

You see how confusing life can be without standards?

 Lack of standards brings confusion: Everyone creates their version, and no one knows what to use. Globalization, predictability, onboarding and collaboration also suffer because you get confused when jumping from one standard to the next. Wouldn't it be wonderful if we all agreed to use one version? This is how standards are born.

You should employ this philosophy in your system. You can adopt an existing standard, just make sure you make it known to your team. This makes your system predictable to its developers and also the end user, making everyone's lives easier

Solution:
  • Do your research before building. Check if a standard solution already exists
  • Adopt a standard early in your design, 
  • Communicate it clearly to your team.
  • Stick to it consistently across the system

Neglecting non-functional requirements

Among all the causes I discovered in my investigation, this one was the most elusive. When users tell you what they want or the problem they are facing, they rarely mention the non-functional requirements. Their focus is always on the functional -what the system should do. But as a designer, it is your job to identify the non-functional requirements, even if they don't tell you. 

From experience, non-functional requirements, more than the functional ones, have a huge effect on the user experience, and can even dictate how your system should be designed. 

Consider this:

You developed a social media app, complete with all the modern features: AI powered, live video streaming, real time chat. But you forgot one thing: speed.  A user downloads your app after being impressed with the features shown in your ad. The user opens the app, but has to wait 5 seconds after every tap. What will you do as a user?

Another example. Your app works fine; it’s super fast this time, but you didn’t factor in security. Hence, hackers found a way to get your users’ private posts? What will you do as a user?

Simplicity, speed, security, and scalability - all examples of non-functional requirements are vital for your user experience, even if they don't explicitly mention it. Amongst them, simplicity is the most universal non-functional requirement and should be at the heart of every design. 

I am yet to hear a user say: 

“Can you please make your product/software/hardware very complex to use? Thanks.” 

Every user, even power users, wants a simple, intuitive experience that helps them solve their problems

Being user-centered goes beyond solving the user’s problems, but providing a beautiful experience that will always make them come running back to you. Non-functional requirement is your secret ingredient to accomplish that.

Solution:
  • Know your users well to anticipate their non-functional needs
  • Always, and always, put yourself in the end-user's shoes as you test your system
  • By default, build for simplicity- all users want this

Poor understanding of tradeoffs - Failure to balance pros and cons

Some common non-functional requirements include:

  • Simplicity
  • Configurability
  • Security
  • Speed
  • Responsiveness
  • …and so on.

Knowing the functional requirement is just the first step; balancing the non-functional requirements against the functional requirements, without compromising simplicity. That is where the real challenge is.

Let me give you some real-world scenarios:

  • If a user wants the system to be configurable, chances are, you need to design an additional layer or subsystem to handle configuration. Thereby increasing system complexity.
  • If a user wants a fast system, chances are, you need to implement sophisticated caching strategies. Thereby increasing complexity.
  • If a user wants security, chances are,  you need to inconvenience them with periodic password resets. Or enforce the use of long, unique and strong passwords, compromising on user-friendliness.

Some companies have solved this challenge beautifully.

  • Google blends security with usability by subtly reminding you to verify your recovery info- without being annoying.
  • Apple introduced Passkeys, Face ID, and Touch ID to beautifully blend security with ease of use. Pure elegance.
  • Recently, I noticed WhatsApp occasionally prompts you to verify your 2-factor pin- Rightly timed to ensure you are still the account owner, or you have not forgotten your password

Most non-functional requirements compete with one another - improving one may weaken the other. This is what makes building elegant systems more of an art form than a science - there are no fixed rules. You need to find the right balance and trade-offs to meet the user’s needs. 

Solution:
  • Prioritize the non-functional requirements that matter most to your users
  •  For the non-functional requirements, you must compromise, take calculated risks and make trade-offs that minimize impact on your end users.
  • The goal is harmony, not perfection. Find the right balance and be OK with trade-offs.

CONCLUSION 

There is no glory in designing a complex system you take pride in if it is a pain for your users. -Hayford O.A

This is a unique domain of knowledge -  it has nothing to do with how experienced or skilled you are. You get paid the big bucks because you are solving a problem, whether the solution is simple or complex. However, to gain loyal and recurring clients, solving their problem isn't enough; you need to make your system easy and enjoyable for them to use.