UX Design für große Anwendungen
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ösungen 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:
Die Leuchttürme einer Anwendung
Jede Anwendung hat ihre einzigartigen USPs, die sie erfolgreich machen – sei es ein ausgeklügelter Algorithmus, exklusiver Marktzugang oder wertvolle Datenbestände. Diese USPs bilden die Grundlage der Produktvision und müssen in den UX-Konzepten besonders berücksichtigt werden. Hier muss Kreativität und Raffinesse zum Einsatz kommen, um den Marktvorteil voll auszuspielen, denn genau auf diese Stellen schauen potenzielle Kunden.
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. 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. 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! 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.
Unsere Empfehlungen im Umgang mit Stakeholdern
Klar definierte Dialog-Typen! Wir trennen strikt Anforderungsmanagement und UX Konzeption. Denn für Anforderungssteller ist es häufig komfortabel die Anforderungen an Hand von Lösungsansätzen zu justieren. Das führt und diskutieren entweder Datenmodel und -fluss oder generische Konzepte oder testen fertige Interaktion. Nicht alles gleichzeitig an Hand eines Konzepts.
Entscheidungshoheit! Natürlich ist jeder Input wichtig. Die Entscheidung über Generik und damit verbundene Kompromisse muss immer an übergreifender Stelle fallen – dort, wo ein möglichst vollständiges Bild der Anforderungslage vorliegt. Im Fall von SAFe ist es das Produktmanagement, bei dem wir natürlich auch gerne federführend mitwirken!
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.
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 🙂
Patterns im UX Design
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:
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.
UX Design wird systematisch angeleitet, Synergien zu suchen und die Arbeitsergebnisse zu strukturieren.
Es können direkt vorab technische Implikationen mit der Entwicklung geklärt werden – idealerweise bevor der Kunde den neuen kreativen Konzepte begeistert zugestimmt hat
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.