The complex development landscapes of big companies
The following scenario may look familiar to you: A larger company, say from the digital field, has a number of touchpoints with the customer, including very different applications and products used on different platforms and in different settings. The teams that support these products have correspondingly heterogeneous requirements and preferences according to which they now select their development tools. For example, some rely on frameworks like Angular or Vue.js, others on libraries like React.js. That’s not a bad thing; each team should choose exactly those technologies that have the best fit. Moreover, such frameworks are supposed to reduce the amount of work and lower the occurrence of mistakes through standardization. However, this becomes problematic when the designers come into play…
Now let’s imagine that the same company wants to roll out a new design across all its products, only its teams now use a variety of frameworks. This will mean for some of them (at the very least!) that adjustments in styling will lead to unpopular and tedious minute work because the design components aren’t based on the logic of the framework used. Developers then have more instead of less work since they need to write new code for each component. The effort required for each individual component grows exponentially with the number of teams, while the collaboration between designers and developers can no longer run smoothly. In an economy where constant technological change creates constant demand for better design, this extra work can quickly get out of hand.
Web Components: Framework-agnostic evolution of design systems
Why current design systems aren’t sufficient
Keeping the brand image consistent is a challenge that grows more complex with an increasing company size. Processes between designers and developers are usually staggered and linear, meaning that design specifications will be submitted that need to be implemented in a decentralized manner after the fact. This can mean a large amount of additional work that could be used for other purposes, and it is not surprising that design might be less accepted in the organization because of this. Moreover, Individual adjustments will frequently lead to mistakes and inconsistencies within the customer journey. Therefore, the basic idea of a design system is to simplify this inefficient process by providing design components as building blocks for an organization-wide ecosystem. These basics, which start with fundamentals such as typography, colors, spacing and the like, then form the basis for building applications. The use of these components should then make design reusable.
With this goal in mind, several tech companies with considerable design compentence have developed design systems in the past. However, even those are not able to sufficiently solve our problem. Either they are based on a specific framework (e.g. Airbnb’s Design Language System DLS, which works with React components and Sketch) or they were developed with a special focus on one (e.g. IBM’s Carbon, which is “React first,” but also provides components in vanilla JS, Angular and Vue.) This means, as soon as your company uses more than one framework, the process gap between design and development will not be solved by this.
Design system based on Web Components: advantages for developers and designers
Web Components are a (not entierly) new web standard driven by a number of notable tech companies (e.g. Apple, Goolge, Mozilla…) Frameworks like Vue, Angular or React already use component-based architectures. The difference, however, is that Web Compenents are based on a deeper level of abstraction. This measn that every framework and browser can interpret them and no further adaptation is necessary. Therefore, they are an ideal basis for evolving the logic of existing design systems. The main idea is a framework-agnostic system that trivializes the problems of brand consistency we discussed above.
Example: So far, when designers proposed even just a single input field (including visuals, agent states etc.) developers had to rebuilt it in each framework. However, as a Web Component, the design will be rooted in the code and becomes universally usable for everyone, no matter the tools. This means for developers that they don’t need to bother with Styling and CSS any longer, since issues like layout, style, or responsiveness will be already defined by the component itself. As a result, they will have much more time to focus on building great products, and a big source of mistakes will vanish in the process. And last but not least, all of reduces the need for coordination with design which means that everyone involved can now work more efficiently. All of this suggest that such a design system should be very interesting for bigger organizations with many teams, touchpoints and so forth.
So far, when designers proposed even just a single input field (including visuals, agent states etc.) developers had to rebuilt it in each framework. However, as a Web Component, the design will be rooted in the code and becomes universally usable for everyone. Tim Zeidler
Developing the Iconstorm design system: our process and experiences
Why aren’t all design systems using Web Components?
As plausible as the concept sounds, there are only a few companies that use a design system based on Web Components. In Germany, Porsche and Telekom, for example, are doing so successfully, while many names that we would expect on this list are missing. (If you know more, please let us know!) This is mainly because many tech companies were already working on design systems when Web Components were not yet widely used; as a result, their systems today are usually based on a specific framework. They were simply too early.
To develop a new design system, however, a lot of effort is required. In addition, if the goal is to built its components into the code, design and development must work closely together. Unfortunately, though, that is not so easy. Both have very different sets of skills, areas of competence, and often work according to different proceses. A lot of thought, work, and organizational effort was thus required to get our off the ground, and the resulting questions preoccupied us at Iconstorm for some time during the development of our design systems. It started with the recruitment of developers like me, and also included the design and testing of new processes with the company. Establishing a good cooperation between development and design was key.
Developing a design system based on web components: some of the questions we needed to anwer:
How might we expand the social brain of our team to build something like this in the first place? Which (types of) developers do we need to staff and how will we work with them?
Can we build a system that is able to meet the specific needs of sometimes very different organizations?
How much initial work will suffice? For example, how many components will we need to develop ourselves in order to provide an interesting offer for possible partners and clients?
Will the system actually be able to make design scale on the enterprise level? Will it actually reduce complexity in a way that is also financially interesting for its users?
Application in Practice
Status quo of Iconstorm’s design system
Despite (or maybe because of?) these challenges we were excited about this idea to the point that we actually started developing it; and, by now, we have developed a usable system. Of course, this is easily said in a sentence, but it was a huge undertaking including the expansion of our team, lots of research and focused development over a long timeframe. But in the end, the work was worth it. We now have a practice-ready toolchain including prefabricated components, which users of our system can adapt according to their needs. The current step is testing the system in the field with two DAX 30 companies, and we already see signs that it not only simplifies working with brands for everyone involved, but that it is also self-financing thanks to the increase in day-to-day efficiency. Accordingly, we think that the future of design systems belongs to Web Components.
Author and Contact
Tim Zeidler is Creative Technologist at Iconstorm and has significantly contributed to our design system.