GUI-Redesign nach Continuous-Delivery-Prinzipien

Beim Redesign einer Benutzeroberfläche im Rahmen eines Continuous-Delivery-Prozesses ist auf vieles zu achten, um den Nutzer nicht zu verschrecken. Mit etwas Vorbereitung kann die Umgestaltung jedoch gelingen.

Know-how  –  12 Kommentare
GUI-Redesign nach Continuous-Delivery-Prinzipien

Die Entwicklung von Software nach den Continuous-Delivery-Prinzipien ist heutzutage nichts Besonderes mehr. Mit bewährten Entwicklungsmustern wie Gradual Feature Release, Feature Toggles oder Branch by Abstraction sowie automatisierten Build-, Test- und Deployment-Prozessen ist die Entwicklung von Software, die jederzeit bereit zur Veröffentlichung ist, mittlerweile vergleichsweise problemlos umsetzbar.

Anders gestaltet sich die Sache allerdings, wenn nicht die Entwicklung einzelner Features, sondern das komplette Redesign einer Anwendungsoberfläche ansteht. Eine GUI lässt sich nicht inkrementell Feature für Feature umstellen und dabei regelmäßig veröffentlichen, denn das Resultat wäre eine unansehnliche Bedienoberfläche mit inkonsistenter Bedienung.

Am Thema GUI-Redesign kommen Entwickler von Software mit grafischer Oberfläche jedoch nicht vorbei. Spätestens nach drei bis fünf Jahren haben sich erfahrungsgemäß die Sehgewohnheiten und die Erwartungen der Nutzer an eine Bedienoberfläche so stark geändert, dass eine Neugestaltung der GUI erforderlich wird. Der Grund dafür ist unter anderem in der ständigen Weiterentwicklung der GUI-Konzepte (Flat Design, Material Design und Card Layouts) und -Patterns (Expandable Inputs, Infinite Lists, Progress Steps, Slideouts und Walkthroughs) und ihrer schnellen Umsetzung durch die Entwickler von Social-Media-Apps und Consumer-Websites zu sehen. Durch das hohe Innovationstempo legen sie die Messlatte für eine moderne Benutzeroberfläche ständig höher.

Nicht nur die steigenden Anforderungen bezüglich Usability und User Experience (UX) sind es, die regelmäßig GUI-Redesigns anstoßen. Auch Trends wie das derzeit angesagte Flat und Material Design wollen berücksichtigt werden, möchten Entwickler mit ihren Projekten nicht einen – zumindest optisch – altbackenen und rückständigen Eindruck vermitteln. Besonders Entwickler von Webapplikationen sind in der Hinsicht gefordert, denn die Updatezyklen der Browserhersteller sind besonders kurz. So soll eine moderne Web-GUI mittlerweile ein responsive Layout mit verzerrungsfreier Skalierung und Icon Fonts bieten, die Bedienung per Touchscreen unterstützen, Daten lokal im Browser persistieren und möglichst auf das Neuladen von Webseiten verzichten. Die technischen Herausforderungen an ein GUI-Redesign sind dementsprechend hoch.

Außerdem bringt Continuous Delivery neue organisatorische und prozessuale Herausforderungen in die moderne Softwareentwicklung. All das darf die Erfahrung der zahlenden Kunden mit der Software jedoch nicht beeinträchtigen. Schließlich lässt sich ihnen schwer vermitteln, dass die Bedienoberfläche in den nächsten Monaten schrittweise umgebaut wird und es daher zu fehlerhaften Darstellungen kommen kann.

Eine Option wäre, das GUI-Redesign durch einen eigenen Entwicklungszweig (Feature Branch) im Rahmen der CD umzusetzen. In ihm können Entwickler in aller Ruhe die neue GUI erarbeiten und den Branch später mit dem Main Trunk zusammenführen. Dabei gibt es jedoch zwei Probleme: Zum einen wird der Feature Trunk mehrere Monate parallel zum Main Trunk laufen, sodass ständig Synchronisationen zwischen beiden Zweigen erforderlich sind, da die Entwicklung der Software während des Redesigns nicht stehen bleibt. Zum anderen werden die Änderungen des GUI-Redesigns so umfangreich sein, dass beim Zusammenführen von Feature Branch und Main Trunk mit jeder Menge Merge-Konflikten zu rechnen ist. Das wiederum kann dazu führen, dass der Main Trunk entgegen der CD-Philosophie über mehrere Wochen nicht für ein Release bereit ist.

Der vorliegende Beitrag behandelt daher ein alternatives Entwicklungsmodell für das GUI-Redesign in einer CD-Umgebung. Es basiert auf den Erfahrungen des Autors mit der Umgestaltung der Bedienoberfläche einer umfangreichen Webapplikation, die als Lizenz- und SaaS-Angebot vertrieben und in einem Continuous-Delivery-Prozess entwickelt wird.

Schlau zerlegt

Ziel muss es sein, das Redesign so weit aufzuteilen, dass der Umfang dessen, was tatsächlich an einem Stück umzustellen ist, so gering wie möglich ausfällt. So lassen sich Inkonsistenzen durch eine partielle Umstellung vermeiden und Entwickler haben die Chance, schnell zur inkrementellen Weiterentwicklung zurückkehren zu können. Bei der Umsetzung können aus der CD-Entwicklung bekannten Design Pattern wie Gradual Feature Release, Feature Toggle und Minimum Viable Product (MVP) helfen.

Ein GUI-Redesign lässt sich in der Regel in zwei voneinander unabhängigen Dimensionen zerlegen: Zum einen in der Breite, die durch den Funktionsumfang der Software bestimmt ist, und zum anderen in der Tiefe, die der Grad des Eingriffs in die bestehenden Schichten des Programmcodes (zum Beispiel View Layer, Business Layer, Data Access Layer und Datenbank) definiert. Für das Aufteilen in der Breite sollte der Zuständige im Sinne des MVP-Pattern zuerst den Mindestfunktionsumfang der Applikation definieren, für die das GUI-Redesign im ersten Schritt durchzuführen ist.

Existiert beispielsweise eine Basic- oder Light-Version der umzugestaltenden Software, bietet es sich an, das GUI-Redesign zuerst nur für deren reduzierten Funktionsumfang umzusetzen. Darauf sollte eine Neugestaltung der Features folgen, die zusätzlich im regulären Funktionsumfang (das heißt in der Standardversion) zu finden sind. Zuletzt können sich die mit dem Redesign betrauten Entwickler Funktionen widmen, die nur einigen Kunden zur Verfügung stehen (Premiumversion). Sollte es darüber hinaus Features geben, die ausschließlich intern für Administrations- oder Monitoringzwecke zum Einsatz kommen, kann man diese danach angehen – interne Nutzer sind in der Regel geduldiger als zahlende Kunden. Durch das Teilen einer Applikation in unterschiedliche Feature Sets lässt sich das GUI-Redesign in zeitlich getrennten Schritten umsetzen, ohne einer Kundengruppe inkonsistente Benutzeroberflächen zu zeigen.

Für die Gliederung in der Tiefendimension sollten sich Entwickler am "Gradual Feature Release"-Pattern orientieren. Dabei entstehen aufeinander aufbauende Stufen, die jeweils tiefer in den bestehenden Code eingreifen. Für ein Redesign wären etwa

  1. Facelift
  2. Quick-wins (schnelle Erfolge)
  3. Usability-Optimierungen
  4. UX-Verbesserungen

denkbar. In der Regel wächst die Komplexität der Entwicklung von Stufe zu Stufe. Während beispielsweise in der ersten nur Farben und Fonts geändert werden, lassen sich in der vierten Stufe komplette Workflows erneuern oder Features zerlegen und zusammenführen. Zur besseren Verdeutlichung folgen ein paar Beispiele dazu, welche Art von Überarbeitungen welcher Stufe zuzuordnen ist.

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.

Tipps für die Umsetzung

Um zu entscheiden, welche Änderungen in die Facelift-Stufe kommen und welche zu einem späteren Zeitpunkt umzusetzen sind, sollten Designer und Entwickler miteinander reden, da Designer häufig schwer abschätzen können, welchen Entwicklungsaufwand ihre Ideen nach sich ziehen.

Bei Webanwendungen sind die Anforderungen an die Browserversion nach dem GUI-Redesign in der Regel höher. Es ist daher wichtig, Nutzer so früh wie möglich auf die neuen Anforderungen hinzuweisen, damit sie sich darauf einstellen können. Dies gilt speziell für den Microsoft Internet Explorer. In manchen Unternehmen kann es leider mehrere Monate dauern, bis die Nutzer auf eine aktuellere Browserversion wechseln dürfen.

Steht ein Termin mit vielen Kundenkontakten wie eine Roadshow oder Messe an, kann es sich lohnen, vor dem Start des GUI-Redesigns einen Feature Branch der umzugestaltenden Software zu erstellen, in dem das neue Design bereits für zwei bis drei Funktionen umgesetzt ist. Präsentiert der Anbieter die überarbeiteten Features Besuchern und Gästen, ensteht die Gelegenheit, früh im Redesign-Prozess ein erstes, persönliches Feedback der Kunden zu bekommen. Das kann unter Umständen den einen oder anderen durch betriebliche Scheuklappen entstandenen Denkfehler aufdecken.

Generell ist es eine gute Idee, bereits im Vorfeld des GUI-Redesigns Beta-Tester unter interessierten Kunden zu akquirieren, sodass die Verantwortlichen schnell an echtes Kunden-Feedback gelangen. Dabei sollte negatives Feedback nicht beirren, sondern als Ansatzpunkt für ein Gespräch dienen. Nur so lässt sich der Grund für die Kritik erfahren, da sie eventuell in Teilen gar nicht im Redesign begründet ist.

Im Übrigen geben Nutzer Feedback erfahrungsgemäß primär in "Zwangssituationen" ab. Sie lassen sich etwa durch das Setzen der neuen Bedienoberfläche als Standard oder das Ankündigen eines Abschalttermins für die alte GUI provozieren. In dem Zusammenhang sollten sich Softwareanbieter zudem darauf einrichten, die alte GUI nach Abschluss der Überarbeitung noch mindestens ein halbes Jahr weiter anzubieten beziehungsweise zu betreiben. (jul)

Martin Aschoff
ist Gründer und Vorstand der AGNITAS AG, die eine webbasierte Marketingsoftware entwickelt und sie als Lizenz und per SaaS anbietet.