GUI-Redesign nach Continuous-Delivery-Prinzipien

Vier Stufen

1. Stufe: Das Facelift

Das Facelift ist der erste Schritt im GUI-Redesign und beschränkt sich auf die im wahrsten Sinne des Wortes oberflächliche Änderungen wie das Layout (Flächen, Formen, Farben und Positionen), die verwendeten Bilder, Grafiken, Icons und Fonts sowie auf sonstige Effekte wie Schatten. Idealerweise beeinflusst es nicht die Funktionen der Software. Die Stufe ist übrigens die einzige, in der tatsächlich alle Änderungen auf einmal durchzuführen sind: Entscheidet sich das Team beispielsweise für einen Umstieg auf ein Flat Design, das das Bootstrap-Framework und einen CSS-Präprozessor benötigt, lässt sich die entsprechende Änderung nur schwer inkrementell vollziehen. Allerdings gibt es die Option, das Facelift zuerst nur für das MVP-Feature-Set umzusetzen und es den Basiskunden freizuschalten. Anschließend lässt sich das Umstellen der Funktionen für die Standard- und Premiumversion in Angriff nehmen.

2. Stufe: Die Quick-wins

In der Quick-win-Stufe nehmen Entwickler kleine Usability-Verbesserungen vor, die nur wenig Aufwand verursachen. Denkbar ist beispielsweise ein Vereinheitlichen von Bezeichnungen in Menüs, Labels und Tool Tips, das Verschieben von Bedienelementen, um Mauswege zu verkürzen, das Anpassen der Reihenfolge von Feldern in Formularen, das Ändern von Spaltenbreiten oder Zeilenhöhen in Tabellen oder der Austausch von Widgets wie Date Picker oder Auswahlboxen.

Der Übergang von der Facelift- zur Quick-win-Stufe ist fließend. Die Entscheidung, welche Änderungen in welcher Stufe erfolgen sollten, ist mit Blick auf den MVP-Ansatz zu fällen. In der Facelift-Stufe etwa muss gerade so viel Mehrwert stecken, dass die Kunden freiwillig zur neuen GUI wechseln. Auf jeden Fall ist es wichtig, bei der Beurteilung, welche Änderungen tatsächlich Quick-wins sind, streng zu bleiben. Ein Quick-win, der in Wirklichkeit eine größere Usability-Optimierung oder gar eine UX-Verbesserung ist, kann den Abschlusstermin der Stufe erheblich verzögern.

3. Stufe: Usability-Optimierungen

In der dritten Stufe sind die Änderungen der Anwendungsoberfläche tiefgehender und erfordern unter Umständen weiterreichende Arbeiten am Code. Typische Beispiele sind geänderte Menüstrukturen, die Klickwege verkürzen sollen, der Ausbau des Dashboards, um den Nutzern Klicks in die Programmtiefe zu ersparen, die Überarbeitung von Formularstrukturen zur besseren Übersichtlichkeit oder der Austausch eines integrierten Editors gegen eine neue Version mit ergänzenden Funktionen.

Auch der Übergang von der Quick-wins-Stufe zu den Usability-Optimierungen ist fließend. Erneut gilt das Argument, dass eine Änderung im Zweifelsfall in die höhere Stufe verschoben werden sollte, damit sich Änderungen in der Stufe davor schneller veröffentlichen lassen und die Entwickler vom Kundenfeedback profitieren können.

4. Stufe: UX-Verbesserungen

In Stufe 4 befassen sich die Arbeiten nicht länger mit der Oberfläche, da UX-Verbesserungen oft in die Tiefe gehen und entsprechend zeitaufwändiger sind. Sie sollten daher erst angegangen werden, wenn das eigentliche Redesign abgeschlossen ist. Bei den Verbesserungen der User Experience geht es oft um Änderungen im Workflow, die sich durch das Umgestalten bestehender Features, ihrer Aufteilung oder Zusammenlegung manifestieren. Außer neuen Assistenten und Wizards sind in dem Zusammenhang völlig neue Funktionen denkbar, die erst das Redesign ermöglicht. Darunter fällt etwa das Speichern von Daten lokal im Browser.

Genau genommen ist die Stufe der UX-Verbesserungen nie abgeschlossen, da es immer etwas zu tun gibt. Inkrementelle Änderungen in ihr sind an der Benutzeroberfläche unauffällig, denn in der Regel sind nur einzelne Features betroffen und nicht die gesamte Software.

Die Aufteilung eines GUI-Redesigns in die vier beschriebenen Stufen erscheint rückblickend logisch, kann jedoch zu Beginn internen Widerstand hervorrufen. Oft ist beispielsweise zu hören, dass ein Facelift den Kunden zu wenig Mehrwert bringt. Das ist zwar korrekt, allerdings stellt es nur den ersten Schritt des Redesigns dar und irgendwo müssen die Arbeiten anfangen. Mit der Umsetzung betraute Entwickler können anmerken, dass die Aufteilung in die vier Schritte den Umfang ihrer Arbeit erhöht, weil der gleiche Code zum Teil mehrfach anzufassen ist. Auch dieser Einwand ist richtig, allerdings reduziert sich durch das Stufenmodell die Komplexität der Umstellung, es treten weniger Fehler auf und das Kundenfeedback steht schneller zur Verfügung. Das reduziert wiederum den Aufwand für Änderungen, weil es sich in einem frühen Umsetzungsstadium berücksichtigen lässt.

Die vier Stufen können sich – je nachdem, wie das Entwicklerteam organisiert ist – in Verbindung mit dem Funktionsumfang zeitlich überschneiden. Das heißt, während Premium-Kunden erst die Facelift-Stufe angeboten bekommen, profitieren Standard-Kunden bereits von der Umsetzung der Quick-wins-Stufe und Basic-Kunden können Usability-Optimierungen nutzen (siehe Markierungen in der Abbildung).

Elemente eines GUI-Redesigns lassen sich parallel umsetzen.

Für die Priorisierung der Umsetzungsreihenfolge lohnt es sich, die Ertragskraft der unterschiedlichen Kundengruppen heranzuziehen. Es bietet sich etwa an, die Neugestaltung zunächst nur für die Basic-Funktionen durchzuführen, sollte der Großteil des Umsatzes von Nutzern des Basic-Angebots stammen. Sind dagegen Premium-Kunden die Hauptumsatzquelle, ist ein horizontales Vorgehen sinnvoll, in dem das Team jede Stufe jeweils für den kompletten Funktionsumfang umsetzt, bevor es zur nächsten wechselt.

Parallelbetrieb dank Feature Toggle

Während des GUI-Redesigns bietet es sich an, die alte und neue GUI parallel anzubieten und ein Umschalten per Feature Toggle zu erlauben. Das bedeutet, dass der Anbieter die alte GUI nach Implementierung der Facelift-Stufe nicht abschaltet, sondern sie weiterhin parallel zur neuen zur Verfügung stellt ("Rival Feature") und so eine Option zum An- und Ausschalten der Neuerungen hat. Solch ein Vorgehen birgt zahlreiche weitere Vorteile, auf die im Folgenden noch eingegangen wird. Zumindest bis zur Umsetzung der Stufe mit den Usability-Optimierungen sollten beide GUI-Varianten parallel betrieben werden.

Bei einer Webapplikation lässt sich der Betrieb der beiden Anwendungsoberflächen in der Praxis beispielsweise so umsetzen, dass das Team zum Start der Facelift-Phase im Codeverwaltungssystem außer dem Dateiordner der alten GUI (Ordner A) einen zweiten Ordner für die Dateien der neuen Bedienoberfläche anlegt (Ordner N). Im Ordner N legt es sukzessive die Dateien des Redesigns ab. Dabei sollten die Namen der Dateien identisch mit denen sein, die sie in der alten GUI ersetzen. Im Deploy-Prozess werden später (gegebenenfalls für den gleichen Webcontainer) zwei Versionen der Software erzeugt: eine mit dem Ordner A der alten GUI und eine zweite, die eine Kopie des Ordners A zur Grundlage nimmt, aber alle Dateien aus dem Ordner N dort hineinkopiert und so alte Dateien durch neue überschreibt.

Natürlich ist das Redesign der zweiten Version vor dem Abschluss der Facelift-Phase noch unfertig und es liegen sowohl Features im alten als auch im neuen Design vor. Eine derartige Version lässt sich allerdings intern zum Testen verwenden und dort in der Regel zudem produktiv nutzen.

Eine wichtige Ergänzung für den Parallelbetrieb von alter und neuer GUI ist ein Feature Toggle. Eine entsprechende Umschaltmöglichkeit sollte prominent in der Benutzeroberfläche positioniert sein und dem Nutzer den Wechsel des verwendeten GUI-Ordners erlauben, damit er im Betrieb nahtlos zwischen beiden Designs wechseln kann. Mit den entsprechenden Übergabeparametern lässt sich zusätzlich sicherstellen, dass der Nutzer beim Umschalten im gleichen Menü bleibt und sich nicht bei jedem Wechsel auf der Startseite der Software wiederfindet.

Beim Gestalten des Feature Toggle ist zu beachten, dass es sich pro Kundengruppe konfigurieren lassen sollte, sodass das Team den GUI-Schalter je nach Fortschritt der Facelift-Phase erst nur für interne Nutzer, dann für die Basic-Kunden und später für die Standard- und Premium-Anwender freischalten kann. Außerdem sollte die Voreinstellung des Feature Toggles konfigurierbar sein, damit sich entscheiden lässt, ob der Nutzer direkt nach dem Log-in standardmäßig die alte oder neue GUI sieht.

Während das Feature Toggle den Entwicklern das Testen der neuen GUI erleichtert, bietet es den Kunden den Vorteil, bei Verständnisproblemen oder Bugs jederzeit auf die alte GUI wechseln zu können, ohne Daten zu verlieren. Speziell Lizenznehmer, deren Software im Gegensatz zu den SaaS-Nutzern seltener aktualisiert wird, müssen im Rahmen des GUI-Redesigns viele Änderungen auf einmal verkraften. Eventuelle Berührungsängste lassen sich durch die Option nehmen, jederzeit zur alten, vertrauten Bedienoberfläche wechseln zu können. Aus Sicht des Autors wiegen die Vorteile den zusätzlichen Aufwand, den die Entwicklung des Feature Toggles und der Parallelbetrieb von zwei GUIs verursacht, mehr als auf.