5.0 Einführung in Teil 5: UI/UX-Design
Dieser Teil handelt davon, wo Software auf die Menschen trifft, die sie nutzen. Das deckt viel ab: die Forschung, die offenbart, was Nutzerinnen brauchen, die Benutzeroberfläche und das Designsystem, das sie präsentiert, die Worte, die Handlung leiten, die Barrierefreiheit und Sprachunterstützung, die sie für alle nutzbar machen, und die Frontend-Entwicklung, die sie in die unordentliche Realität echter Browser und Geräte ausliefert. Es ist verlockend, all das als Dekoration zu behandeln, die Sie am Ende anwenden. Bitte widerstehen Sie dem. Hier erreicht alle vorgelagerte Arbeit entweder die Nutzerin oder zerfällt, und es wird lange entschieden, bevor der letzte Bildschirm poliert ist.
Für große Teams ist Produktdesign wirklich ein Koordinationsproblem. Wenn Dutzende Squads in ein geteiltes Produkt ausliefern, häufen sich unabhängige Entscheidungen zu einem Durcheinander: duplizierte Abläufe, widersprüchliche Terminologie, inkonsistente Komponenten, und eine Sprachpipeline, die niemand besitzt. Die Lösung in jedem Kapitel hier hat dieselbe Form. Verwandeln Sie einmalige Entscheidungen in geteilte, verwaltete Vermögenswerte, wie Personas, ein Designsystem, eine Inhaltsstrategie, ein Internationalisierungs-(i18n)-Framework, Komponentenbibliotheken, und Performance-Budgets, damit viele separat arbeitende Teams sich trotzdem zu einer kohärenten Erfahrung summieren.
Unternehmen und Behörden erhöhen die Einsätze weiter. Unternehmenssoftware hat oft gefangene Nutzerinnen, und sie bezahlen für schlechtes Design in Training, Fehlern, und Support-Last statt durch Weggehen. Behördendienste erreichen die gesamte Öffentlichkeit (einschließlich Menschen in Krisen, auf alten Geräten, mit geringem digitalem Vertrauen, oder ohne alternative Anbieterin), Designqualität wird also eine Frage von Gerechtigkeit und bürgerlichem Vertrauen. Hier ist Barrierefreiheit kein Nice-to-have, sondern ein gesetzliches Mandat: öffentliche Stellen sind gesetzlich verpflichtet, Software zu bauen, die Menschen mit Behinderungen nutzen können, und einfache-Sprache- und Sprachzugangspflichten tragen häufig ebenfalls Gesetzeskraft.
Kapitel in diesem Teil
5.1 UX-Grundlagen: Die Forschungs-, Nutzermodellierungs-, und Design-Thinking-Praktiken, die einer Organisation erlauben, evidenzbasierte Produktentscheidungen zu treffen statt zu raten, und jedem Team dieselbe Karte der Nutzerin geben.
5.2 UI-Design und Designsysteme: Das Handwerk, zu formen, was Menschen sehen und berühren, und das geteilte, verwaltete System aus Tokens, Komponenten, und Mustern, das Tausende Bildschirme über viele Teams hinweg kohärent hält.
5.3 Barrierefreiheit: Software bauen, die Menschen mit Behinderungen wahrnehmen, bedienen, verstehen, und nutzen können, gleichzeitig behandelt als rechtliche Pflicht, ethische Pflicht, und einfach gutes Design.
5.4 Inhalts- und Kommunikationsdesign: Die Worte, Botschaften, und Kommunikationen formen, die ein Produkt nutzt, um Menschen beim Handeln zu helfen, in einfacher Sprache und konsistenter Stimme, weil Worte Interface sind.
5.5 Internationalisierung und Lokalisierung: Die Architektur, die Software erlaubt, sich an jede Sprache und Region anzupassen, und der Arbeitsablauf, der sie für jedes Gebietsschema übersetzt und kulturell anpasst.
5.6 Frontend-Entwicklung: Die kundenzugewandte Schicht für eine Umgebung bauen, die Sie nicht kontrollieren, mit Aufmerksamkeit auf Framework-Langlebigkeit, Rendering-Strategie, Performance, und Resilienz.
5.7 Mobile Anwendungsentwicklung: Für mobile Geräte bauen, native, plattformübergreifende, und progressive Web-Ansätze abdeckend; Plattform-Designrichtlinien; Offline-, Batterie-, und Fragmentierungsbeschränkungen; App-Store-Distribution; und mobile Sicherheit und Barrierefreiheit.
5.8 Designforschung und Usability-Testen: Das Risiko reduzieren, das Falsche zu bauen, durch generative und evaluative Forschung, die richtige Methode für jede Frage, gut gemachtes Usability-Testen, repräsentative Rekrutierung, und Synthese, die tatsächlich Entscheidungen ändert.
5.9 Service-Design: Den gesamten Dienst gestalten, den eine Person über Kanäle und Zeit hinweg erlebt, Front-Stage und Back-Stage, Service-Blueprints und Journey-Maps nutzend und die Organisation hinter dem Dienst ausrichtend, nicht nur einem einzelnen Bildschirm.
5.10 Datenvisualisierungsdesign: Das richtige Diagramm für die Frage wählen und Daten ehrlich kodieren, grafische Exzellenz anwendend, barrierefreie und farbenblind-sichere Paletten, und klare Beschriftung, damit ein Diagramm eine Entscheidung informiert statt sie irrezuführen.
Wie diese Kapitel zusammenhängen
Diese Kapitel bilden einen einzigen roten Faden vom Verstehen bis zur Lieferung. UX-Grundlagen (5.1) etablieren, wer die Nutzerin ist und welche Aufgabe sie zu erledigen versucht. UI und Designsysteme (5.2) geben diesem Verständnis eine konsistente visuelle Form. Inhaltsdesign (5.4) liefert die Worte, die es tragen. Frontend-Entwicklung (5.6) liefert das Ergebnis aus. Barrierefreiheit (5.3) und Internationalisierung (5.5) sind keine separaten Stufen, sondern Qualitäten, die durch alle anderen gewoben sind: eine barrierefreie, übersetzbare Erfahrung wird von Anfang an in geteilte Komponenten, Inhaltsmuster, und Code eingebaut, nie später angeschraubt. Kapitel 5.3 stützt sich insbesondere auf Kapitel 5.2, um Barrierefreiheit einmal in jeder Komponente zu lösen, und auf Kapitel 5.6, um sie in semantischem, standardbasiertem Markup zu bewahren.
Der Teil reicht auch über das Guidebook hinaus. Das “Vermögenswerte-über-Einmaligkeiten”-Muster hier spiegelt das geteilte-Plattform-Denken aus Kapitel 8.4 (Plattform-Engineering und Entwicklererfahrung), und die Werte und Arbeitsweisen aus den Kapiteln 1.1 und 1.4 setzen die organisatorischen Bedingungen, die Designkohärenz überhaupt möglich machen. Barrierefreiheits-, visuelle-Regressions-, und Performance-Budget-Prüfungen gehören in die Lieferpipelines aus Kapitel 8.1 (CI/CD und Lieferung), damit Qualität bei jeder Änderung durchgesetzt wird statt kurz vor dem Start geprüft zu werden. Und die Real-User-Monitoring-Daten (Performance-Daten, gesammelt von den Geräten und Netzwerken echter Nutzerinnen), auf die sich Frontend-Performance stützt, verbindet sich direkt mit den Beobachtbarkeitspraktiken aus Kapitel 9.2. Gut gemacht, ist die Arbeit hier, was die anderswo beschriebenen Systeme tatsächlich für die Menschen nutzbar macht, denen sie dienen sollen.