Making It Look Easy - Addressing Complexity

“Products have to be designed in a way that they are comprehensible. Good design makes a product understandable.” -  Dieter Rams

As architects and designers, our goal is to make these solutions work and to be used (nothing is more fulfilling than a system that is used). That means ensuring they are fit-for-purpose AND simple – simple for the stakeholders who sponsor, use, construct, manage and maintain the solutions. The challenge is how do you take something that is inherently complex and [often] constrained, such as integration with enterprise systems, and make it simple.

More so, complexity is often not the real issue. Either way, we still have work to do. Sometimes, the task may be one of design to factor away unnecessary parts of a system by reduction, but more often, a different task is required – creating understanding.

Defining Complexity

Complexity is normally expressed by the measure of the components and the relationships between them within a system. It is the goal of any design to rationalize the components and relationships to the fewest set possible to achieve the desired outcome – factoring for reduction - but there will always be a point of diminishing returns or even externally imposed constraints that require a number of components and relationships – necessary complexity. In the face of this dilemma how do we avoid complication? Isn’t it true that a large number of components and interrelationships in a system imply it will be complicated? Not if the solution using that that complex system of components is perceived as simple by the target stakeholders.


Defining Simplicity

Simplicity is difficult to define, but ultimately comes down to “ease of understanding.”  A colleague introduced me to this realization several years ago when we were challenged to make our enterprise systems “less complex and complicated” while also using best-of-breed, commercially available components AND retaining our core (and expensive) primary business components.  We knew we had a large necessary set of components with many interactions, so factoring for reduction would not be the only answer. He posed that we should not try to define complication or simplify, but rather measure understandability through testability.

He arrived at this conclusion through Karl Popper’s concept of the falsifiability of a solution and I have perhaps oversimplified this observation to testability, but none-the-less, it was an epiphany for me. The key is that lack of understanding is the real root cause of those cries to remove the complexity – they were really cries for understanding.

This is the core driver that we as architects and designers must focus to defeat complication in enterprise solutions.  We must ensure the solution is understandable via several dimensions including component design, testability and documentation. The component design must be well factored for both reduction and right-placement. It is not enough to simply reduce the number of components and expect simplification. It is important that we understand what must be exposed to the target audience at each layer and level as well as realizing there may be multiple audiences to address. We must consider shifting, not reducing complexity. The solution must be easy to demonstrate and test features. By making something easy to test, it becomes more understood.  The documentation and user support must be effective, succinct and preferably visual.  While consumer products may be self-intuiting, enterprise solutions require some form of additionally communication. It is very easy to create reams of documentation, but too much will overwhelm stakeholders while too little will leave stakeholders short of the knowledge required to engage the solution. We are looking for the Goldilocks zone of documentation (just right) to achieve understanding.

In future entries, I will explore a few of these dimensions to challenge how we make complexity look easy with an exploration of test-driven development (designing for testability), conservation of complexity as applied for both the user experience and for “developer experience” in APIs, and some of the techniques we employ at Benefitfocus to increase understanding through visualizations and client collaboration.