Kontext
In meinem Masterstudium – Leadership in Digital Innovation an der Universität der Künste Berlin – kam ein Thema immer wieder auf: Transparenz. Transparenz in Organisationen, in Projekten, in Prozessen. Der kompromissloseste Ausdruck dieses Gedankens ist Open-Source-Software – also habe ich dort angesetzt.
Open Source ist eine bemerkenswerte Sache. Unzählige Menschen und Unternehmen weltweit stellen ihre Zeit und ihre Ideen unentgeltlich zur Verfügung, um das Ökosystem am Leben zu halten, und ein großer Teil der Back-End-Anwendungen und Infrastruktur des Internets läuft auf dem Ergebnis. Doch sobald Open Source auf Endnutzer:innen trifft, tut es sich seit jeher schwer. Verbraucherorientierte Open-Source-Projekte sind selten, und selbst wo es sie gibt, bieten sie kaum je ein Erlebnis, das man als gelungen bezeichnen würde – funktional ihren kommerziellen Pendants ebenbürtig, aber selten ebenso benutzerfreundlich.
Ich wollte praktische Ansatzpunkte finden, mit denen diese entwicklungsgetriebene Kultur benutzerfreundlichere Software bauen kann – und so dazu beitragen, dass Open Source lebendig und zukunftsfähig bleibt.
Die Fragestellung
Etwa zu dieser Zeit hatten sich Design-Systeme als Mittel etabliert, um die Zusammenarbeit zwischen Designer:innen und Entwickler:innen zu verbessern und das Niveau der Benutzerfreundlichkeit anzuheben. Für Open Source schienen sie wie geschaffen: eine geteilte, dokumentierte Grundlage, gegen die verteilte Mitwirkende ohne endlose Abstimmung arbeiten können.
Die Arbeit hatte zum Ziel zu verstehen, wie Design-Systeme heute in Open Source tatsächlich eingesetzt werden – und wo Spielraum für eine weitere Verbreitung besteht.
Vorgehen
Akademische Forschung zur Wirkung von Design-Systemen ist dünn gesät, und zu Design-Systemen speziell im Open-Source-Kontext noch dünner. Diese Lücke verlangte nach einem qualitativen, explorativen Ansatz.
Ich habe sechs Designer:innen, die in Open-Source-Projekten arbeiten – jede:r aus einem anderen Land –, in problemzentrierten Interviews (PCI) befragt; gewonnen habe ich sie über Twitter und die Open-Source-Design-Community. Das PCI-Format balanciert strukturierte Fragen und offene Erzählung aus und eignet sich für kaum erforschte Themen. Anschließend habe ich alle Interviews vollständig transkribiert und in MAXQDA detailliert codiert, um wiederkehrende Muster zwischen den Teilnehmenden und den von ihnen beschriebenen Projekten herauszuarbeiten.
Ergebnisse
Die entscheidende Erkenntnis war, dass das Hindernis weniger im Werkzeug liegt als in Kultur und Stellenwert.
Designer:innen in Open Source stoßen nach wie vor auf erhebliche Hürden. Sie werden oft nicht ernst genommen – als Ästhetiker:innen betrachtet statt als integraler Teil des Entwicklungsprozesses. Beizutragen ist für sie strukturell schwieriger als für Entwickler:innen: Die Community honoriert in erster Linie Code, und viele Designer:innen können ihre eigene Arbeit nicht selbst umsetzen, wodurch ihre Beiträge schwerer messbar werden und sie schwerer Reputation aufbauen können.
Design-Systeme könnten diese Einstiegshürde senken und Designer:innen wie Entwickler:innen eine gemeinsame Plattform geben. Doch ein solches System zu etablieren und zu pflegen, setzt starke Design-Führung voraus, die in Open-Source-Projekten nur selten vorhanden ist. Und es gibt überhaupt keinen standardisierten Weg, Design-Systeme in Open Source zu nutzen – weil es kein geteiltes Verständnis davon gibt, was ein Design-System eigentlich umfasst. Wie ein solches System gestaltet, gebaut und gepflegt werden sollte, um Open-Source-Software nachhaltig zu tragen, bleibt eine offene Frage.
Diagramm mit den zentralen Ergebnissen der Arbeit zu Designer:innen und Design-Systemen in Open Source
Was ich mitgenommen habe
Ich bin nach wie vor überzeugt, dass Design-Systeme der Open-Source-Community insgesamt helfen könnten. Aber wer je eines aufgebaut und gepflegt hat, weiß, wo die eigentliche Schwierigkeit liegt: nicht im Erstellen praktischer, schöner Komponenten, sondern in der Politik. Das ist schon innerhalb von Organisationen mit klaren Hierarchien und Befehlsketten schwer – und in einer ehrenamtlichen Community ohne beides erst recht.
Meine pragmatische Empfehlung lautet, zunächst ein bestehendes Design-System eines Drittanbieters zu übernehmen. Das nimmt früh viel Diskussionsbedarf heraus; sobald ein Projekt eine solide Basis hat, kann etwas Eigenes sinnvoll werden.
Aus rein akademischer Sicht war die Arbeit zeitweise wirklich schwer zu schreiben – und genau deshalb lohnend. Fundierte Forschung zur Wirkung und zum Wert von Design-Systemen ist noch immer rar, und die Verbindung zu Open Source war Neuland, das zu erschließen sich gelohnt hat.