UX Design für große Anwendungen

Das Problem: Ausufernde UX Design-Aufwände und explodierende Implementierungskosten

UX Design lebt vom Verständnis der Nutzer und dem befriedigen der Bedürfnissen in einzelnen Use Cases. Wenn die Konzeption mit dieser Perspektive ein großes Softwareprojekt angeht, dann ist das Ergebnis des UX Teams oft eine Ansammlung vieler Mockups und Designs. Jeder Use Case ist per Konzept behandelt und möglichst im Sinne des Nutzers ausgestaltet. Wer heute weit vorne ist, bekommt die ganzen kleinen Bauteile zusätzlich als „Design System“ definiert.

Das häufige Problem: Jeder Teilaspekt ist anders. Es lässt sich kaum ableiten, welchen grundsätzlichen Regeln die View-Aufbauten folgen und an welchen Stellen der Konzepte perspektivisch Erweiterungen zu erwarten sind. Bereits bestehende Komponenten sind mehr oder weniger verändert oder erweitert. Schlussendlich entstehen unzählige fast identische Konzepte und Komponenten die viel Zeit in Implementierung und Wartung kosten. Schauen Sie doch einfach mal in ihr aktuelles Projekt und zählen all unterschiedlichen Button-Typen!

Ein Großteil von umfangreichen Softwarelösung ist Standard

Hand aufs Herz: Der größte Teil einer umfangreichen Anwendung besteht aus Standards. Stammdaten müssen beispielsweise in Unmengen an Formularen und Listen gepflegt werden. Für „Suche und Filter“ gibt es wirklich viele bewährte Konzepte und sogar bereits implementierte Framework-Erweiterungen. Die ganzen Standard-Masken wie Anwendungskonfigurationen, Login-Views und Profile.

Die Magie – und aus unserer Erfahrung der einzige Weg – um umfangreichen Anwendungen Herr zu werden ist:

1. Bei den Standards durch Schematisierung und Generik einen möglichst hohen Wiederverwendungsgrad erreichen.
2. Gezielt an den strategisch relevanten Stellen der Anwendung Einzigartigkeit, Leidenschaft und Aufwand investieren.

Die Leuchttürme einer Anwendung

Jede Anwendung hat einzigartige Aspekte. Irgendwelche USPs („Unique Selling Points“), die die Anwendung erfolgreich machen. Bei der einen Anwendung ist es ein ausgeklügelter Algorithmus zur Routenberechnung, in der anderen ein konkurrenzloser Marktzugang über den Mutterkonzern, bei einer weiteren jahrelange Erfahrungen in Form von konkret gesammelten Datenbeständen. Mit diesen USPs verfolgt das Produktmanagement ein übergreifendes Ziel, eine Vision.

Randnotiz: Wenn Sie sich über Ihre Vision noch nicht im Klaren sind, empfehlen wir unser Workshop-Format „Design Sprint M“.

Und genau an diesen USP-relevanten Stellen der Anwendung, muss aller Augenmerk gelegt werden. Die UX-Konzepte müssen einzigartig sein, kreativ und pfiffig. Und vor allem Ihren Marktvorteil voll ausspielen. Denn potenzielle Kunden schauen genau auf diesen Teil ihrer Software.

Abseits der Leuchttürme: Standard-Lösungen für Standard-Anforderungen

Die Magie um die vielen Standard-Anforderungen umsetzbar zu halten, ist ein hohes Maß an Wiederverwendbarkeit von UX Designs und Komponenten. Es gilt Gleichheiten von Anforderungen und Lösungen zu suchen und identisch zu bearbeiten.

Jede Standard-Anforderung muss durch UX Design generisch betrachtet werden

Häufig sind solche Gleichheiten in technischen – und nicht fachlichen! – Aspekten zu finden und gehen weit über Trend-taugliche „Design Systeme“ hinaus. Beispiel: Die beiden Entitäten „Häftling“ und „Wärter“ mögen aus fachlicher Sicht eklatante Unterschiede aufweisen, je nach System könnten aber vielleicht beide technisch identisch als „Identität“ oder „Person“ konzipiert werden…inklusive gleichem UX Design für Views und einem einheitlichem zu Grunde liegenden Datenmodell samt API. Dies ist ehrlicherweise ein plakatives Beispiel, es mag wahrscheinlich sein, in einer Anwendung diese beiden Protagonisten sehr wohl auch visuell in der Anwendung zu unterscheiden.

Die Magie ist systematische Wiederverwendbarkeit

Es sollte stets über den Tellerrand geschaut werden und eine Einzelanforderung auf mögliche Gleichheit späterer Anforderungen geprüft werden. Aus dem Use Case „Ich als Umweltingenieur möchte meine Interpretation des Messdatensatzes als Kommentar hinterlassen.“ könnte sinnvollerweise die Anforderung werden: „Das System braucht eine Querschnittsfunktionalität, um Datensätze egal welchen Typs kommentieren zu können.“ Ein einziges konzipiertes und entwickeltes Microfrontend, dem egal ist, in welchem Kontext es sich befindet, könnte hunderte von Stunden an User Experience Design und Implementierung sparen!

Die besondere Herausforderung für Generik: Kommunikation mit Nutzern und Stakeholdern

Nutzer und Stakeholder betrachten Anforderungen meist spezifisch für einen Use Case. Mangels technischem Verständnis fehlt oft Abstraktionsfähigkeit und es kommt der Wunsch nach möglichst konkreter Lösungsvisualisierung in Form von UX Design auf. Lässt man sich auf ungesteuerten, spezifischen „Wunschkonzert“-Dialog ein, sind individuelle Views und Patterns kaum noch zu bändigen.

Chaos verhindern durch Verwaltung von Arbeitsergebnissen

Haben die Beteiligten eine generische Sicht verinnerlicht und spüren erste Effizienzschübe, wartet ganz nach dem Motto „Beim ersten Mal geht’s meistens schief“ die nächste Hürde. Denn das wachsende Material an Konzepten und Komponenten muss verwaltet werden, da Änderungen an bestehenden Konzepten und Komponenten massive Auswirkungen haben können! Wie viele Views einer Anwendungen funktionieren wohl noch, wenn der eine zentrale Button durch Veränderung eine gravierende Fehlfunktion mitbringt?

Auf der anderen Seite lassen sich natürlich zig Versionen einer Komponente vorhalten und damit den Bestand schützen. Auf der Rechnung stehen dann allerdings Inkonsistenz der Anwendung und Gefährdung der Wartbarkeit.

Wichtig No. 1: Transparenz über Bestand von UX Design und Komponenten

Alle UX Konzepte und entwickelten Komponenten müssen handfest dokumentiert sein. Und zwar nicht auf losen Confluence-Seiten, sondern inklusive Verschachtelungen, Versionierung und Status-Dokumentation. Nur so lässt sich auch für das UX Team konkret ablesen, welche Label-Version im aktuellen Form-Item steckt und welche anderen Komponenten beeinträchtigt werden könnten, wenn ein Label verändert wird. Wir verraten Ihnen gerne, wie wir diese Herausforderung konkret per System lösen. Aber nicht hier 🙂

Wichtig No. 2: Die Liste der einzusetzenden Patterns als Pflicht-Dokumentation für UX Design und Teil der UX DoD („Definition of Done“)

Eine der wichtigsten Informationen, die sich die Entwicklung aus einem UX Konzept ziehen können muss, sind alle zu verwendenden Patterns / Komponenten und in welcher Version! Für ein unscheinbares Formular in einer Großanwendung mag der Input aus UX nur ein Datenmodell und Hinweis auf Nutzung des Standard-Formulars sein. Alles weitere ist dann in der einmalig aufgesetzten Dokumentation dieses Standard-Formulars geklärt.

Wichtig für alle Beteiligten ist auch das explizite Hervorheben von neu zu entwickelnden Patterns in UX Konzepten. Aus folgenden Gründen:

1. Die Entwicklung spart Zeit für Rückfragen und muss sich nicht auf die Suche nach bestehenden oder ähnlichen Komponenten machen oder läuft Gefahr redundante Lösungen zu entwickeln.
2. UX Design wird systematisch angeleitet, Synergien zu suchen und die Arbeitsergebnisse zu strukturieren.
3. Es können direkt vorab technische Implikationen mit der Entwicklung geklärt werden – idealerweise bevor der Kunde den neuen kreativen Konzepte begeistert zugestimmt hat 😉
4. Die Sprintplanung kann sich auf neue Patterns einstellen. Da abhängige Arbeiten niemals in einen Sprint gelegt werden sollten, sind zunächst die neuen Patterns umzusetzen, und erst im Folgeschritt die konsumierenden Views.[/box]

Organisation der UX Kompetenzen in Multi-Team-Setups

Einen letzten wichtigen Faktor für UX Erfolg in umfangreichen Softwareprojekten ist die Verteilung der Kompetenz für UX Design in Multi-Team-Setups à la SAFe. Dazu aber mehr in einem späteren Beitrag! Stay tuned!

Kommen Sie gerne auf uns zu, wir teilen gerne unsere Erfahrungen.