KI-getriebene Design Systeme im Continuous UX Baukasten

Digitale Produkte werden mit jedem Jahr komplexer und interoperieren in systemischen Zusammenhängen. Unternehmen denken daher immer häufiger in Plattformen und digitalen Ökosystemen statt in monolithischen Großprodukten. Um Komplexität zu beherrschen, ist die Etablierung eines übergreifenden Design Systems, daher einer der wichtigsten strategischen Faktoren in der nutzer-zentrierten Ära.

Und diese Ära wird nun immer KI-getriebener: Seit ChatGPT und Midjourney schreitet die Entwicklung KI-basierter Werkzeugen in einem atemberaubenden Tempo voran und lässt gefühlt keinen Stein auf dem anderen. Auch an Design Systemen geht dieser Vormarsch sicherlich nicht spurlos vorüber. Doch Design System sind für jedes Unternehmen eine langfristige Investition und entwickeln sich evolutionär. Daher ist die Frage berechtigt: welche Konsequenzen ergeben sich für die Etablierung und Verbesserung von Design Systemen in einer KI-getriebenen Welt und wie stellt man sich als Unternehmen strategisch darauf ein?

Was ist ein Design System und was beinhaltet es?

Um eine Prognose zur zukünftigen Gestalt von KI-getriebenen Design Systemen abgeben zu können, lohnt es sich, zunächst den Begriff des „Systems“ in den Fokus zu nehmen. In der Domäne des System Engineering lautet die Definition folgendermaßen:

Ein System ist eine Menge interagierender Elemente, die einen oder mehrere Zwecke erfüllen.

Unter professionellen System Engineers gibt es daher die vorherrschende Meinung, dass beispielsweise ein Lego-Bausatz kein System darstellt:

„Was ist denn nun definitiv kein System? Meine Antwort: ein Lego-Bausatz! Das ist eine Menge von Elementen, die aber nicht interagieren. Diese Menge hat zwar auch Eigenschaften, sie ergeben sich aber durch einfache Aufsummierung (etwa das Gesamtgewicht).“ – Axel Scheithauer

Die Tatsache, dass die Elemente eines Lego-Bausatzes in beliebiger Art und Weise miteinander kombinierbar sind, scheint in dieser Betrachtung somit kein system-stiftendes Kriterium zu sein.

Diese Perspektive dürfte sowohl für Außenstehende als auch für den ein oder anderen UX Professional zunächst schwer nachvollziehbar sein, zumal in der UX-Community ein Design System vordergründig sehr häufig als eine Sammlung verschiedener UI Elemente und Patterns unterschiedlicher Komplexitätsstufen beschrieben wird und dem Grundprinzip eines Lego-Bausatzes somit sehr nah kommt. Tatsächlich beschränken sich UI-lastige Design Systeme in der Praxis leider sehr oft auf bloße Elementbeschreibungen und zielen weniger auf dynamische Wechselspiele oder eine tiefgründige Betrachtung der „Zweckerfüllung“ ab.

Um eine solide Basis für die Etablierung eines Design Systems in interdisziplinären, agilen Teams zu schaffen, definieren wir ein Experience Design System in unserem „Continuous UX“ Prozessbaukasten daher wie folgt:

„Ein Experience Design System ist die Gesamtheit von miteinander in Beziehung stehenden Nutzeranforderungen, Interaktionspatterns, Gestaltungskomponenten und Code Bausteinen, die multi-disziplinäre Teams dazu befähigen, konsistente User Interfaces über Abteilungs- und Produktgrenzen hinweg effizient und effektiv zu realisieren.“

Diese Definition orientiert sich stark an der originären Definition aus dem System Engineering und fokussiert daher nicht vordergründig auf UI Komponenten, sondern vor Allem auf das Wechselspiel zwischen Nutzer*innen, Anforderungen, Patterns und UI Komponenten, sowie auf den Zweck, der mit Hilfe des Design Systems erfüllt werden soll.

Investitions-Indikatoren für POs und Digital-Strategen

Um beispielsweise als Product Owner oder gar Chief Product Owner Sinn und Zweck eines Design Systems besser einschätzen zu können, gibt es eine Reihe von Indikatoren, die signalisieren, ob dessen Kosten und Nutzen in einem guten Verhältnis zueinanderstehen. An dieser Stelle seien daher die wichtigsten Investitions-Indikatoren aufgelistet, die für die Etablierung und Pflege eines Design Systems sprechen, sofern eine durchgehend gute User Experience eines strategisches Ziel des jeweiligen Unternehmens ist:

• Teamkonstellation (Teams größer als 16 Mitglieder, abteilungsübergreifende Teams, interdisziplinäre Teams)
• Plattform-Diversifizierung (z.B. Mobile, Desktop, Industrieanlage)
• Produkt-Linien bzw. Produkt-Suite Strategie (ähnlich Word, Excel, PowerPoint in Office365)
• Ineffiziente oder ineffektive Übergaben zwischen Designern und Engineers (häufig kopierter Code oder schlechte Qualität im Endergebnis)

Typische Elemente in Design Systemen

Unabhängig von der Definition sowie dem Sinn und Zweck eines Design Systems, stehen UX und Digital Designer regelmäßig vor der Aufgabe, Design System Elemente auf den einzelnen Komplexitätsstufen mit eindeutigen Begriffen zu belegen. Eine Betrachtungsweise, die sich in der UX Community recht gut durchgesetzt hat, entleiht dabei Begriffe aus der Chemie und teilt Elemente unter dem Oberbegriff „Atomic Design“ in folgende Kategorien ein:

• Atome
• Moleküle
• Organismen
• Templates
• Seiten
• Patterns

Diese Einteilung greift aus meiner Sicht an vielen Stellen zu kurz. Zum einen fallen „Templates“ und „Seiten“ aus der Begriffshemisphäre der Chemie ohne nachvollziehbare Begründung heraus. Dies erschwert es in komplexeren Projekten, die Evolution eines Design Systems entlang eines „roten Fadens“ zu Ende zu spinnen. Zum anderen beziehen sich diese Kategorien ausschließlich auf UI- und Gestaltungselemente. Auch der „Pattern“ Begriff avanciert beim Atomic Design in der Praxis oftmals ungewollt vom „Lösungsmuster“ zur „konkreten Lösung“ und damit eher zur „UI Komponente“ – der Pattern Begriff entfernt sich daher leider von Christopher Alexanders in seinem herausragenden Buch „A Pattern Language“ vorgestellten Idee.

Mehr als UI Elemente

Für einen smoothen „Continuous UX“ Prozess halte ich es für essenziell, dass ein Design System nicht nur UI- und Gestaltungs-Elemente enthält (also Elemente aus dem „Lösungsraum“), sondern auch Kontextelemente (also Elemente aus dem „Problemraum“). Es handelt sich also um jene Elemente, die eher der Anforderungsanalyse oder dem „Requirements Engineering“ entspringen. Diese Problemraum-Elemente unterstreichen die Natur eines „echten“ Systems, da erst mit ihrer Hilfe Sinn und Zweck anderer Elemente definiert werden können. In diesem Sinne empfiehlt unser Continuous UX Baukasten, folgende Artefakte aus dem Problemraum ebenfalls zu den Inhalten eines Design Systems zu zählen:

• Personas
• Nutzungsszenarien
• User Needs
• User Journeys

Mehr Aufwand? Dank KI nicht wirklich …

Nun klingt die Erweiterung eines Design Systems um Anforderungselemente aus dem Problemraum zunächst nach mehr statt weniger Arbeit und damit auch nach höheren Kosten. Umso besser, muss der Nutzen einer solchen Erweiterung begründet werden.

Hier ein Versuch: im Grunde können moderne KI-basierte Werkzeuge bereits überraschend viele UX und UI Aufgaben lösen und nehmen uns jeden Tag ein bisschen mehr Arbeit ab. Egal ob ChatGPT, Midjourney, Galileo.ai, uizard.ai, Figma AI Addons oder dergleichen: wenn wir der KI nur exakt genug schildern, was wir eigentlich wollen, dann bekommen wir auch überraschend gute Ergebnisse. Umgekehrt heißt das: solange wir nicht sagen können was wir konkret wollen, werden wir von den Lösungen enttäuscht sein. Folgendes Zitat fasst diesen Sachverhalt knackig und humorvoll zusammen:

„Um unseren Job durch KI zu ersetzen, müssten Kunden erst einmal ihre Anforderungen richtig beschreiben. Macht euch keine Sorgen.“

Die Arbeit, ein UX Design System zu etablieren und zu pflegen wird also in Zukunft vielleicht nicht weniger, sie verlagert sich aber immer mehr in Richtung einer guten Anforderungsanalyse und einem soliden Requirements Engineering. Wenn die Nutzungskontexte, sowie die Frustrationen und Motivationen der Zielgruppe konkret genug beschrieben sind, dann ist eine LLM-basierte KI durchaus in der Lage. damit überraschend effektive Lösungen zu liefern.

Hier ein kleiner Vorgeschmack aus einem Chat mit ChatGPT 4.0.

Wenn schon so wenig Kontextinformation, ein so passendes erstes Skelett für ein „UI Design System“ liefert, wie werden die Ergebnisse erst, wenn wir noch mehr und noch bessere Kontextinformationen liefern? Im zweiten Teil meines Artikels, werde ich mich genau dieser Frage widmen und den Weg hin zu einem echten „UX Design System“ schildern.