Vieles, was in Star Trek auf dem Bildschirm flimmerte, hat es irgendwann in unsere Hosentaschen geschafft. Die Klappkommunikatoren der Originalserie wurden 1996 als Motorola Klapphandys zum Kultobjekt. Die PADDs aus The Next Generation, jene flachen Touchgeräte, mit denen Counselor Troi in den späten 80er durch die Gänge der Enterprise lief, kamen 2010 als iPad in unsere Wohnzimmer.
Sprachgesteuerte Computer, lange ein dramaturgischer Trick, wurden mit Siri 2011 und Alexa 2014 eingeführt und sind heute mit Produkten wie ChatGPT Voice Mode besser als in der Serie. Universalübersetzer gibt es heute mit Google oder Apple Realtime Live-Übersetzung. Die Zukunft, die uns Gene Roddenberry versprochen hat, ist über die Jahre zur Konsumelektronik und Realität geworden.
Eine Sache aber, hat es nie wirklich aus der Serie heraus geschafft, obwohl sie es verdient hätte. Die Bildschirme Layout selbst.
LCARS, ausgeschrieben Library Computer Access and Retrieval System, ist die fiktive Bedienoberfläche der Sternenflotte. Sie tauchte 1987 mit dem Start von The Next Generation auf und blieb über mehr als zwanzig Jahre und vier Serien hinweg konsistent, was man von kaum einer realen Software behaupten kann, deren Designsprache sich nach jedem Quartalsbericht verändert. Verantwortlich war Michael Okuda, Scenic Art Supervisor der Produktion, ein Mann, der nie Designer Of The Year wurde und trotzdem mehr Disziplin an den Tag legte als die meisten Teams, die heute an einer Banking App arbeiten.
Der Ausgangspunkt war banal. Animierte Monitore waren in einer Fernsehproduktion der späten Achtziger schlicht unbezahlbar. Okuda klebte stattdessen farbige Folien auf hinterleuchtete Acrylplatten. Aus dieser Sparmassnahme entstand eine Bildsprache, die heutige Multimillionen Designteams nicht hinbekommen, obwohl sie in Figma sitzen und nicht im Requisitenkeller.
Die erste Lektion ist die Hierarchie. Jedes Panel folgt einer klaren Lesefolge. Grosse abgerundete Bögen, von Fans Elbows genannt, gliedern den Raum, bevor überhaupt ein Wort erscheint. Links oben Identität, rechts daneben aktive Daten, unten Steuerung. Wer das einmal verstanden hat, findet sich auf jedem Panel im Schiff zurecht. Wer schon einmal zwischen zwei modernen SaaS Tools gewechselt hat, weiss, dass das in der Realität nicht selbstverständlich ist.
Die Typografie hält sich an dieselbe Strenge. Eingesetzt wurde fast ausschliesslich Helvetica Ultra Compressed. Eine Schrift, eine Familie, fertig. Variation entstand durch Grösse, nicht durch das Mischen von drei Custom Fonts, weil das Marketing einen eigenen Webfont haben wollte und die Brand Designerin sich profilieren musste. Wichtiges ist dreimal so gross wie Sekundäres. Das ist trivial, und genau deshalb ist es unfassbar, wie konsequent moderne Anwendungen daran scheitern.
Auch die Farbpalette ist eng. Orange, Rot, Blau, Violett, Beige, Sand. Jede Farbe hat eine Funktion. Rot bedeutet Alarm. Orange ist Navigation. Blau ergänzt. Diese Kodierung ist über alle Bildschirme der Serie identisch. Im Gegensatz dazu kennt eine durchschnittliche Webanwendung von 2026 zwölf Grautöne und drei Akzentfarben, die nichts bedeuten, sondern aussehen sollen. Ein Klick auf Speichern ist blau, ein Klick auf Abbrechen ist auch blau, der Werbebanner ist ebenfalls blau, und niemand im Team kann erklären, warum.
Was LCARS funktionieren liess, war nicht die Idee. Ideen sind schnell da. Was es funktionieren liess, war die brutale Konsequenz der Anwendung. Okuda erstellte produktionsinterne Style Guides, die Eckradien, Abstände, Schriftgrade und Farbwerte verbindlich festlegten. Diese sogenannten Okudagrams definierten, wie Panels zu zeichnen waren. Wer abwich, durfte nochmal von vorne anfangen. Über mehrere Hundert Episoden hinweg blieben die Regeln stabil. Okuda hat damit ein funktionierendes Designsystem mit Tokens, Komponenten und Patterns gebaut, bevor unsere Branche diese Begriffe überhaupt erfunden hatte. Ohne Figma. Ohne Storybook. Ohne Designsystem Lead mit drei Untergebenen. Mit Klebefolie.
Die echte Welt versuchte es zur selben Zeit. Mit gemischten Resultaten.
Hier wird es interessant, und ein bisschen schmerzhaft, denn Okuda war mit seiner Idee nicht allein. 1987 ist nicht nur das Geburtsjahr von LCARS, sondern auch das Jahr, in dem unsere Branche zum ersten Mal ernsthaft versuchte, ihre Bildschirme zu zivilisieren.
Apple veröffentlichte im selben Jahr die Apple Human Interface Guidelines als gedrucktes Buch, 139 Seiten, Addison Wesley, blau gebunden.
IBM legte im Dezember 1987 mit Common User Access nach, satte 328 Seiten als Teil ihrer Systems Application Architecture. Drei Designsprachen, im selben Jahr, mit demselben Ehrgeiz. Es hätte eine Sternstunde der Disziplin werden können. Es wurde, je nach Akteur, eine Sternstunde, ein achtbarer Versuch oder eine Lachnummer.
Apple kam Okuda am nächsten, und das ist keine Übertreibung. Die Mac HIG waren nicht nur ein Buch. Sie waren Teil einer Strategie, die mit kultureller und technischer Gewalt durchgesetzt wurde. Apple hatte sogenannte Evangelisten, allen voran Bruce Tognazzini, deren einzige Aufgabe es war, Drittentwickler davon zu überzeugen, sich an die Regeln zu halten, auch wenn sie ihre eigene Idee schöner fanden. Wichtiger noch: Apple stellte die Macintosh Toolbox bereit, eine Sammlung von Systemroutinen, die Regelkonformität technisch zur Default Option machten. Wer den Standard Dialog wollte, schrieb drei Zeilen Code. Wer abweichen wollte, musste zusätzlich programmieren. Konsistenz war billiger als Eigensinn. Das Resultat war eine Plattform, die extrem konsistent war und man sich sofort zurechtfand. Nicht perfekt, aber näher am Okuda Prinzip als alles, was vorher und vieles, was nachher kam.
IBM dagegen verfolgte den ambitionierteren Plan und scheiterte daran. Common User Access sollte nicht eine Plattform vereinheitlichen, sondern alle. Vom Grossrechner über Minicomputer bis zum PC, vom Textmodus bis zur grafischen Oberfläche, von OS/2 über DOS bis Windows, alles sollte dieselben Tastaturkürzel, dieselbe Menüstruktur, dasselbe Verhalten haben. F1 für Hilfe, F10 für die Menüleiste, Alt F4 zum Schliessen. Diese Kürzel überleben bis heute, und das ist faktisch das einzige, was vom Projekt geblieben ist.
Denn IBM versuchte, einer existierenden, chaotischen Industrie nachträglich Ordnung zu verordnen, ohne die Mittel dafür zu haben. Es gab keine Toolbox, die Konformität billig gemacht hätte. Es gab keine Evangelisten, sondern dicke Bücher mit IBM Logo, die niemand las. Drittentwickler von WordPerfect, Lotus oder Borland hatten ihre eigenen, etablierten Bedienkonzepte, und IBM konnte ihnen nichts entgegensetzen ausser einer Spezifikation. Spezifikationen ohne Macht setzen sich nicht durch. Die Wikipedia formuliert das in der für sie typischen Sachlichkeit: das Projekt war nicht völlig erfolgreich. Aus Designersicht ist das eine sehr freundliche Umschreibung für gescheitert.
Microsoft schliesslich war die Lachnummer, und das ist keine Polemik, sondern Beobachtung. Bereits 1986 erschien der Microsoft Windows SDK Application Style Guide in Version 1.03, überraschend früh und überraschend brauchbar, was niemand erwartet hätte. 1992 folgte ein vollwertiges Guidelines Buch, 1995 mit dem Erscheinen von Windows 95 das umfangreiche The Windows Interface Guidelines for Software Design, 576 Seiten.
Auf dem Papier alles richtig gemacht. In der Praxis war Microsoft der Sünder, der den Sündern predigte. Microsoft Office hielt sich nie an die eigenen Vorgaben. Word hatte eigene Konventionen, Excel andere, der Internet Explorer wieder andere.
Mit Office 2007 wurde mit dem Ribbon ein UI Konzept eingeführt, das sich diametral gegen die eigenen Guidelines stellte und das den Drittentwicklern nahegelegt wurde, gefälligst zu kopieren. Dass die Microsoft Welt der Neunziger und Nullerjahre wie ein Flickenteppich aussah, lag nicht am Fehlen von Regeln. Es lag daran, dass nicht einmal der Hersteller selbst sich an seine Regeln hielt. Niemand wird ernst genommen, der von seinen Lieferanten Disziplin verlangt, die er bei sich selbst nicht durchsetzt.
Drei Hersteller, drei Versuche, dasselbe Jahr. Apple gelang Konsistenz, weil die Werkzeuge und die Kultur die Regeln durchsetzten. IBM scheiterte, weil der Anspruch grösser war als die Macht. Microsoft scheiterte, weil das Unternehmen seine eigenen Regeln nicht für sich selbst anwendete.
Okuda gelang das, woran alle drei in unterschiedlichem Mass scheiterten, weil seine Welt geschlossen war und weil er die alleinige Autorität über jedes Pixel hatte, das gesendet wurde. Das ist ein unfairer Vorteil, gewiss. Es ist aber auch der einzige Vorteil, der zählt. Wenn niemand das letzte Wort hat, wird das Designsystem zur Illustration der Beliebigkeit.
Die freie Welt versuchte es zwölf Jahre später. Mit dem Mut zur Disziplin und dem Mut zur Beliebigkeit, in dieser Reihenfolge.
In der Linux Welt dauerte es eine Weile, bis das Thema überhaupt anstand. Über die Neunziger hinweg sah ein durchschnittlicher Linux Desktop aus wie eine Kreuzung zwischen Bastlerkeller und Konferenzpräsentation. KDE 1.0 erschien 1998, GNOME 1.0 im März 1999. Beide funktionierten, aber von Konsistenz konnte keine Rede sein. Jede Anwendung hatte ihre eigenen Vorstellungen davon, wie ein Speichern Dialog auszusehen hatte, wo das Menü Datei beginnen und wo es enden sollte, und ob ein OK Button rechts oder links zu sitzen habe. Wer von Mac OS oder Windows herüberkam, fühlte sich, als hätte ihn jemand in einen Flohmarkt geschickt.
Der erste ernsthafte Versuch, das zu ändern, kam von GNOME. Im August 2002, fünfzehn Jahre nach Apple und IBM, veröffentlichte das GNOME Usability Project die GNOME Human Interface Guidelines in Version 1.0. Geleitet wurde die Arbeit vom Human Computer Interaction Team von Sun Microsystems unter Calum Benson, getragen von einer Schrift Havoc Penningtons mit dem Titel Free software and good user interfaces, die in der Community wirkte wie eine kleine Reformation. Der Anspruch war ernsthaft, das Buch substanziell, und vor allem hatte GNOME etwas, das IBM und Microsoft nie hatten: den Mut, die eigenen Regeln auch auf sich selbst anzuwenden.
Mit GNOME 2 verschwanden Dutzende von Konfigurationsoptionen, weil die Entwickler entschieden, dass vernünftige Defaults wichtiger sind als die Möglichkeit, jeden Pixelabstand zu justieren. Das war exakt die Apple Doktrin, übersetzt in die freie Welt. Wer abweichen wollte, durfte das, aber nicht mehr per Knopfdruck im Einstellungsdialog. Die Reaktion war erwartbar. Linus Torvalds, der die Diskussion gerne mit Sprengstoff beendet, nannte die GNOME Entwickler in einem berüchtigten Posting Interface Nazis und rief zur Migration nach KDE auf.
Es war einer dieser Momente, in denen Disziplin als Bevormundung umgedeutet wird, was Disziplin in unserer Branche fast immer einfängt. Die GNOME Leute hielten Kurs. GTK lieferte ihnen ihre Toolbox, später kam libadwaita dazu, und beide setzen heute Konformität technisch durch, ähnlich wie es die Macintosh Toolbox dreissig Jahre zuvor getan hatte. Wer eine GNOME Anwendung baut und sich an libadwaita hält, bekommt Konsistenz fast geschenkt. Wer abweichen will, muss arbeiten. Das ist genau das Prinzip, das Apple 1987 einführte, und es funktioniert in der freien Welt aus denselben Gründen.
Bemerkenswert ist auch eine Geste, die in der Branchengeschichte gerne übersehen wird. Die GNOME HIG luden 2002 das KDE Projekt explizit ein, gemeinsam einen freien Desktop Standard zu entwickeln, mit dem ausdrücklichen Hinweis, das Not Invented Here Syndrom zu überwinden, an dem grosse Projekte zuverlässig scheitern. KDE reagierte mit einer Mischung aus gekränkter Höflichkeit und technischen Einwänden, die im Effekt auf Ablehnung hinausliefen. Eine gemeinsame Spezifikation kam nie zustande. Aus heutiger Sicht eine der teureren Versäumnisse, die der freie Desktop-Welt je hatte.
KDE selbst kam mit eigenen Human Interface Guidelines erst gegen Ende des ersten Jahrzehnts der Zweitausender, also rund acht Jahre nach GNOME, und ironischerweise erst nach einem Anstoss von aussen. 2008 forderte Mark Shuttleworth auf der O'Reilly Open Source Convention die Linux Welt auf, beim Design über Apple hinauszuzielen statt hinter Apple herzuhecheln. Erst danach reagierte KDE und legte eigene Richtlinien vor. Sie wurden 2018 nach Akademy in Wien überarbeitet und 2024 unter Federführung von Nate Graham noch einmal grundlegend neu geschrieben. Inhaltlich solide, sauber dokumentiert, in einem Markdown Repository auf GitLab.
Und doch, und hier wird der Vergleich zu Okuda und Apple unbarmherzig, formulieren die heutigen KDE HIG explizit, dass sie nicht als unverrückbarer Kodex zu verstehen seien. Wer die Regeln verstanden habe, dürfe und solle abweichen, wenn das Ergebnis besser werde. Das ist eine philosophisch sympathische Haltung, die aber genau das verweigert, was Designsysteme funktionieren lässt. Okuda hätte einen Teamleiter, der so etwas in einen Style Guide schreibt, vermutlich am Aufzug abgefangen. Das praktische Resultat sieht man jeden Tag: Ein Plasma Desktop unter Kubuntu sieht anders aus als unter openSUSE, anders als unter Manjaro KDE, anders als unter Fedora KDE Spin, und alle vier sehen anders aus als ein KDE Neon, obwohl Letzteres die Referenzimplementierung ist. Selbst innerhalb der Plasma eigenen Anwendungen herrscht eine erstaunliche Bandbreite an Bedienkonzepten. Das ist nicht das Versagen der Entwickler. Das ist die direkte Konsequenz einer Designkultur, die Anpassbarkeit höher gewichtet als Wiedererkennung.
Damit hat die Linux Welt in einem einzigen Vergleich beide Lager der Achtziger nochmal aufgeführt. GNOME ist der Apple Weg, mit Toolbox, Defaults, Disziplin und einem Schuss Bevormundung, der von der Hälfte der Community als Beleidigung empfunden wird. KDE ist der Microsoft Weg, mit dicken Büchern, ausführlichen Regeln und einer Kultur, die im Zweifel jede Abweichung als Feature feiert. Die einen werden für ihre Konsequenz beschimpft, die anderen für ihre Beliebigkeit gelobt. Welche der beiden Welten besser aussieht, kann jeder selbst entscheiden, indem er sich nacheinander GNOME 47 und ein beliebiges KDE Plasma 6 Setup ansieht, und sich dann fragt, in welcher der beiden Anwendungen er sich nach drei Klicks zuhause fühlt.
Und dann kam das Web und vergass das alles wieder.
Die heutige Form des Designsystems, mit Tokens, öffentlichen Komponentenbibliotheken und ausführlicher Dokumentation, brauchte länger und kam mit weniger Disziplin. Brad Frost prägte 2013 mit Atomic Design das Vokabular, das viele Teams seither benutzen. Google veröffentlichte 2014 Material Design und gab damit Millionen von Apps eine gemeinsame Sprache, die anschliessend von jeder Marketingabteilung der Welt verbogen wurde, bis nichts mehr übrig war ausser einem Floating Action Button. Salesforce zog 2015 mit Lightning nach, IBM 2017 mit Carbon. Erst in dieser Welle wurde das, was Okuda 1987 für eine fiktive Welt erfand, zur Selbstverständlichkeit für reale Software. Mit dreissig Jahren Verspätung und einer beachtlichen Quote an Pfusch.
Aus Sicht der Disziplin lohnt sich der Blick zurück deshalb so sehr, weil LCARS keine Frage des Mediums ist. Webseiten, Mobile Apps, eingebettete Geräte und Industriesoftware folgen denselben Gesetzen, sobald viele Elemente auf engem Raum verständlich werden müssen. Hierarchie muss sitzen, Farben müssen etwas bedeuten, Komponenten müssen sich nach klaren Regeln wiederholen. Eine Buchhaltungssoftware kann von Okuda mehr lernen als von der nächsten Konferenz Keynote über Generative UI.
Die eigentliche Pointe ist deshalb keine ästhetische, sondern eine kulturelle. Ein Designsystem lebt nicht von Tools. Nicht von Figma Bibliotheken, nicht von Storybooks, nicht von der dritten Iteration der Komponentennamen. Es lebt von der Disziplin der Menschen, die es anwenden, und vom Mut, eine Abweichung als Fehler und nicht als Kreativität zu behandeln.
Apple wusste das. IBM wollte es. Microsoft predigte es. GNOME zog es in der freien Welt durch, KDE lieferte den Gegenbeweis. Okuda lebte es.
Vielleicht braucht jedes Produktteam einen Mike Okuda. Jemanden, der einmal pro Woche den Style Guide aufschlägt und einen Screen zurückweist, weil der Eckradius nicht stimmt. Den Job will heute keiner machen. Genau deshalb sehen unsere Apps aus, wie sie aussehen.
