Hopp til innhold

Complexity Challenge in Design Systems

Sercan Leylek

2022.03.22

How much complexity can we tolerate in a design system architecture? Or what is the fine balance of granularity for a design system to control the complexity at an optimum level?

Architecture is the invisible blueprint of every IT system. As the DNA identifies the structure of an organism, the architecture clarifies the integrity of an IT system and its character makes impact on every level of the hierarchy. Therefore, specifying the architecture is a fundamental step to solve the complexity problem of platform ecosystems. Basically, architecture answers the question of what should be placed where in an IT system, whereas governance describes who decides what.

One of the reasons behind the need for design systems is surely to reduce the complexity. However, a design system without a proper architecture can contribute to the complexity problem and turn out to become a gridlock instead of solving the problem. Therefore, design systems consist of sub-systems to create granularity (modularization). So that, the architecture of a design system is the collection of those sub-systems and the applications that a design system is in interaction with. Certainly, such hierarchical settlement is not an end to the complexity problem, but maybe a new and manageable beginning.

An ecosystem’s complexity is a function of the number of unique subsystems present in it. The more numerous such subsystems, the greater its complexity. In a platform ecosystem, these subsystems are the platform and the apps that interoperate with it. Complex systems that were complex to begin with can become even more complex over time as they evolve. (A. Tiwana (2013: Ch.5))

Tiwana’s description of ecosystem complexity implies with the status of Jøkul Design System in several aspects. Firstly, the number of components (sub-systems) in a design system specifies the complexity of its core. In the example of Jøkul, the number of these components are surely increasing by time because the core team constantly looks for opportunities to provide reusable components for their client applications. Although the modularization of these components is well-partitioned, the same components have interdependencies as well. For instance, Jøkul’s DatePicker component utilizes jkl-icon-button and jkl-text-input components of the same core and Core Datepicker library of NRK is used as an external dependency. These components are needed to form the user interface of DatePicker and their functionalities are benefited at the same time.

The outcome in the example of DatePicker is the result of hierarchical modularization approach of design systems. Some teams separate granular elements from more complex ones. The levels of granularity vary in number and perceived complexity. Atomic design, pioneered by Brad Frost, is a popular example of hierarchical categorization. Atoms are the basic building blocks, which combine to create more complex standalone elements: molecules. For example, a form label, input and button combine into a search form. Molecules join together into organisms (such as a site header), and organisms into templates and pages. (A. Kholmatova (2017)) So that, jkl-icon-button and jkl-text-input components serve as the atoms of DatePicker molecule.

In addition to that, the number of client applications which benefit Jøkul Design System is also on the rise because different parties of Fremtind AS promotes the use of design system within its organization. This fact also contributes to the growing complexity. Moreover, unlike Jøkul, a highly evolved design system can be used by several organizations and hundreds of different client applications.

Growing complexity in two different dimensions

All in all, these two main points prove that a design system has growing complexity in two different dimensions. One, via the interdependencies of core components; two, via the number of client applications which use the design system.

In any platform, complexity can be of two types: structural complexity and behavioral complexity. An ecosystem can be both structurally complex where interconnections between its parts are difficult to describe and behaviorally complex where its aggregate behavior is difficult to predict or control. (A. Tiwana (2013: Ch.5)) Architecture handles the structural complexity meanwhile governance cures behavioral complexity. In this article, we continue to assess the structural complexity of Jøkul Design System.

So, how one should deal with the complexity of a platform?

The advice of Tiwana and reasoning by straight forward thinking say that complexity should be reduced. It cannot be totally avoided and complexity will always be present, but it should be reduced at an acceptable and manageable level.

In the example of Jøkul’s DatePicker, present complexity can be reduced by writing imported components specific to DatePicker component. So that, the changes in jkl-icon-button or jkl-text-input would have no impact on DatePicker and hence, the owners of Jøkul could avoid potential regressions. However, this approach would not be practical in several conditions. First, that would double the work of imported components. Second, it would be more difficult to control them because components will behave independently by time. Least to mention, the same approach would result in performance issues as well. Writing specific minor components for DatePicker would increase the volume of packages. So that, the client applications would serve larger files to their customers. As a result, freeing Jøkul’s DatePicker from jkl-icon-button and jkl-text-input component dependencies would increase the current complexity rather than reducing it. This is the internal dependency side of the complexity.

As mentioned earlier, Jøkul’s DatePicker utilizes NRK’s calendar library as well. This is actually one of the ways how Jøkul is connected to an external platform. However, controlling the changes of NRK’s library is not possible for Fremtind AS. Therefore, this dependency can create problems for Jøkul in the future. Removing this dependency and re-writing it for Jøkul can be beneficial and that would surely help them eliminate an external complexity, but core team is not eager to do so because of the cost of re-writing a calendar library. This decision was discussed within the core team in a design forum meeting in September 2020 and the team decided to keep on using NRK’s library.

The example of Jøkul’s DatePicker shows that core team accepts existing complexities and discusses these issues internally. However, freeing all dependencies just for the sake of reduced complexity is not a final solution to all structural problems. A design system team’s architecture should evaluate the options and choose suitable path to sustain manageable complexity with the help of architecture.

References

A. Kholmatova (2017), Design Systems: A practical guide to creating design languages for digital products, Smashing Media AG

A. Tiwana (2013: Ch.5), Platform Ecosystems: Aligning Architecture, Governance, and Strategy, Morgan Kaufmann Publishers