Digital products become more complex with each year and interoperate in systemic contexts. Companies are therefore increasingly thinking in terms of platforms and digital ecosystems instead of monolithic large-scale products. To master complexity, the establishment of an overarching design system is therefore one of the most important strategic factors in the user-centric era.
And this era is now becoming more and more AI-driven: since ChatGPT and Midjourney, the development of AI-based tools has progressed at a breathtaking pace, leaving no stone unturned. Design systems are certainly not immune to this advance. But design systems are a long-term investment for every company and develop evolutionarily. Therefore, the question is justified: what are the consequences for the establishment and improvement of design systems in an AI-driven world and how does a company strategically adapt to this?
What is a design system and what does it contain?
In order to be able to make a prognosis on the future shape of AI-driven design systems, it is worthwhile to first focus on the term “system”. In the domain of system engineering, the definition is as follows:
A system is a set of interacting elements that fulfil one or more purposes.
There is therefore a prevailing opinion among professional system engineers that, for example, a Lego construction set does not constitute a system:
“So what is definitely not a system? My answer: a Lego kit! It is a set of elements, but they do not interact. This set also has properties, but they result from simple summation (such as the total weight).” – Axel Scheithauer
The fact that the elements of a Lego construction set can be combined with each other in any way thus does not seem to be a system-founding criterion in this view.
This perspective might be difficult to understand for outsiders as well as for one or the other UX professional, especially since in the UX community a design system is very often described as a collection of different UI elements and patterns of different levels of complexity and thus comes very close to the basic principle of a Lego construction set. In reality, UI-heavy design systems are unfortunately very often limited in practice to mere element descriptions and aim less at dynamic interactions or a profound consideration of the “fulfilment of purpose”.
In order to create a solid basis for establishing a design system in interdisciplinary, agile teams, we therefore define an experience design system in our „Continuous UX“ process toolbox as follows:
“An Experience Design System is the set of interrelated user requirements, interaction patterns, design components and code building blocks that enable multi-disciplinary teams to efficiently and effectively realise consistent user interfaces across departmental and product boundaries.”
This definition is strongly oriented towards the original definition from system engineering and therefore does not focus primarily on UI components, but rather on the interplay between users, requirements, patterns and UI components, as well as on the purpose that is to be fulfilled with the help of the design system.
Investment indicators for POs and digital strategists
For example, in order for a product owner or even chief product owner to better assess the sense and purpose of a design system, there are a number of indicators that signal whether its costs and benefits are in a good relationship to each other. The most important investment indicators that speak for the establishment and maintenance of a design system are therefore listed here, provided that a consistently good user experience is a strategic goal of the respective company:
- Team constellation (teams larger than 16 members, cross-departmental teams, interdisciplinary teams).
- Platform diversification (e.g. mobile, desktop, industrial system)
- Product lines or product suite strategy (similar to Word, Excel, PowerPoint in Office365)
- Inefficient or ineffective handoffs between designers and engineers (often copied code or poor quality in the end result)
Typical elements in design systems
Regardless of the definition and the purpose of a design system, UX and digital designers are regularly faced with the task of assigning clear terms to design system elements at the individual levels of complexity. One approach that has become quite popular in the UX community borrows terms from chemistry and divides elements into the following categories under the umbrella term „Atomic Design“:
In my view, this classification falls short in many places. On the one hand, “templates” and “pages” fall outside the conceptual hemisphere of chemistry without comprehensible justification. This makes it difficult in more complex projects to complete the evolution of a design system along a “red thread”. Secondly, these categories refer exclusively to UI and design elements. In Atomic Design, the term “pattern” also often unintentionally advances from “solution pattern” to “concrete solution” and thus rather to “UI component” – the pattern term thus unfortunately departs from Christopher Alexander’s idea presented in his outstanding book „A Pattern Language“ .
More than UI Elements
For a smooth “Continuous UX” process, I consider it essential that a design system not only contains UI and design elements (i.e. elements from the “solution space”), but also context elements (i.e. elements from the “problem space”). These are therefore those elements that rather originate from requirements analysis or “requirements engineering”. These problem space elements underline the nature of a “real” system, as only with their help can the meaning and purpose of other elements be defined. In this sense, our Continuous UX toolkit recommends that the following artefacts from the problem space should also be counted among the contents of a design system:
- Usage scenarios
- User needs
- User Journeys
More effort? Thanks to AI, not really …
Now, the extension of a design system by requirement elements from the problem space sounds at first like more instead of less work and thus also higher costs. All the better, the benefit of such an extension must be justified.
Here’s an attempt: basically, modern AI-based tools can already solve surprisingly many UX and UI tasks and take a little more work off our shoulders every day. Whether it’s ChatGPT, Midjourney, Galileo.ai, uizard.ai, Figma AI Addons or the like: if we just tell the AI exactly enough what we actually want, we get surprisingly good results. Conversely, this means: as long as we can’t say what we specifically want, we will be disappointed by the solutions. The following quote summarises this fact crisply and humorously:
“To replace our job with AI, customers would first have to describe their requirements properly. Don’t worry about it.”
So the work of establishing and maintaining a UX design system may not become less in the future, but it is shifting more and more towards good requirements analysis and solid requirements engineering. If the contexts of use, as well as the frustrations and motivations of the target group, are described concretely enough, then an LLM-based AI is quite capable of delivering surprisingly effective solutions.
Here is a small foretaste from a chat with ChatGPT 4.0.
Imagine the following usage context: a machine plant where operator needs to load material into machines while shift leads are observing and monitoring the OEE of the production, trying to reduce human and technical errors as much as possible. some of the operators are frustrated though, because the do not understand the error messages of most machines. also they tend to forget to fetch new material early on, as they are in a rush with a lot of small manual tasks.
How could a UI design system help and which UI elements should be contained in that design system in order to cover that scenario? Use the Atomic Design framework for your answer and apply the needed elements to the given scenario.
“Atomic design is a methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner. The five stages are atoms, molecules, organisms, templates, and pages. Let’s apply these elements to the machine plant scenario:
Atoms are the basic building blocks of matter. Applied to web interfaces, atoms are our basic HTML elements, like a form label, an input, or a button.
- Buttons: Start/Stop, Submit Error, Request Material, etc.
- Input fields: Error messages, Operational data, etc.
- Labels: Machine Status, Efficiency Metrics, etc.
- Icons: Warning, Error, Operational, etc.
- Colors: System-wide color themes for statuses like normal (green), warning (yellow), error (red).
Molecules are groups of atoms bonded together and are the smallest fundamental units of a compound. These molecules take on their own properties and serve as the backbone of our design systems.
- Notification Molecule: Composed of an Icon Atom (error icon) + Text Atom (error message) + Button Atom (“Acknowledge”).
- Status Indicator Molecule: An Icon Atom (machine status) + Label Atom (machine name/number) + Color Atom (indicating status).
- Data Input Molecule: Composed of a Label Atom (for the data field) + Input Atom (for data entry).
Organisms are groups of molecules joined together to form a relatively complex, distinct section of an interface.
- Machine Dashboard Organism: Composed of multiple Status Indicator Molecules, a Notification Molecule, and possibly several Data Input Molecules.
- OEE Monitoring Organism: Composed of interactive charts made up of atomic elements and a collection of Data Input Molecules for adjusting parameters.
Templates consist of groups of organisms stitched together to form pages. It’s where we start to see the design coming together and start seeing things like layout in action.
- Operator Template: Contains Machine Dashboard Organisms specific to the machines they operate, quick access to relevant forms, and an area for real-time notifications and instructions.
- Shift Lead Template: Includes an overview of all Machine Dashboard Organisms, higher-level OEE Monitoring Organism, and an area for management controls and insights.
Pages are specific instances of templates. Here, placeholder content is replaced with real representative content to give an accurate depiction of what a user will ultimately see.
- Operator Page: Filled out Operator Template with real-time data from the machines the operator is responsible for, and real notifications or instructions.
- Shift Lead Page: A filled-out Shift Lead Template with current machine and operational data, as well as real-time notifications or insights.
Remember that atomic design is about creating a system that promotes consistency and cohesion while providing a clear methodology for crafting design systems. These are some of the ways it could be applied to the machine plant scenario, but the exact implementation would depend on the specific needs of the users and the requirements of the environment.”
If so little contextual information provides such a suitable first skeleton for a “UI design system”, what will the results be like if we provide even more and even better contextual information? In the second part of my article, I will address this very question and describe the path towards a true “UX Design System”.