Wie so ziemlich alle Artefakte in der Softwareentwicklung befindet sich auch der Styleguide in einem stetigen Wandel. Dennoch werden heutzutage häufig noch klassische Varianten eingesetzt, obwohl sich mit dem technischen Fortschritt längst neue Möglichkeiten eröffnet haben, um klassische Dokumente zum Leben zu erwecken. Dieser Blogbeitrag greift diese Thematik auf und soll am Beispiel Styleguide zeigen, wie durch dessen Weiterentwicklung die Zusammenarbeit zwischen Designer und Entwickler verbessert werden kann: Sind Living Styleguides die Zukunft im UI-Design?
Es war einmal … der dokumentenbasierte Styleguide
Lange Zeit herrschte ein Artefakt über die Zusammenarbeit zwischen UX-Designer und Frontend-Entwickler: der dokumentenbasierte Styleguide. Dieser entsteht klassischerweise wie folgt:
Als Erstes wird eine Anforderungsanalyse durchgeführt.
Auf Basis der Anforderungen erstellt der Designer Mockups.
Die Mockups werden mit dem Kunden diskutiert (x-Iterationen) und final abgenommen.
Danach erstellt der Designer die abgestimmten Grafiken im Design-Tool.
Aus den Grafiken inkl. beschreibendem Text entsteht dann das Dokument „Styleguide“.
Bei Anpassungen müssen alle Schritte wiederholt werden.
Abbildung 1: Der dokumentenbasierte Styleguide
Als Kommunikationsgrundlage sollte ein guter Styleguide folgende Punkte beinhalten:
Konzept (Anwendung aus Projektsicht, Produktvision, UX-Ziele)
Struktur (Aufbau der Anwendung)
Interaktionsdesign (Gestaltung des Dialogs zwischen Nutzer und System)
Farbgestaltung (Verwendungsregeln für Farben)
Typografie (Schriftarten und -größen)
Icons und Grafiken (Übersicht aller Icons und Grafiken der Anwendung)
Spezialansichten (nicht dem Standard entsprechende UI-Ansichten und Steuerelemente)
Sprache (Kommunikationsstil und Wortwahl)
Multimedia (Einsatz von Bildern, Audio und Video)
Doch vor allem die Auflistung der Standard-Interaktionselemente ist in einem starren, dokumentenbasierten Styleguide nicht optimal. Diese kann bei der Menge verschiedener UI-States wie hover, active, selected, … pro Element schnell etliche Seiten lang werden. Die wenigsten Entwickler wühlen sich gerne durch seitenlange Dokumente und so besteht die Gefahr, dass der Styleguide nicht beachtet wird.
Die klassische Variante des Styleguides beinhaltet weiterhin folgende zwei Probleme: Die starre Sicht auf ein meist sehr langes Dokument erfordert viel Vorstellungsvermögen und es besteht keine Interaktionsmöglichkeit mit den verschiedenen Elementen.
Status Quo & Zukunft im UI-Design … es wird lebendig
Um die oben beschriebenen Kritikpunkte zu verbessern, bieten sich mehrere Ansätze an. Beispielsweise können mit Hilfe eines parallel gepflegten UI-Prototypen die Inhalte des Styleguide zum Leben erweckt werden. So wird ermöglicht, verschiedenen States der Standard-Interaktionselemente im Anwendungskontext auszuprobieren oder aber auch Spezialansichten im Detail abzubilden. Mit dieser „Hands-on“-Mentalität wird schneller klar, was die Designanforderungen sind und das lange Blättern in Styleguide-Dokumenten fällt weg.
Dieser Lösungsansatz beseitigt jedoch noch nicht folgende Probleme: Oft ist es im Projektalltag der Fall, dass der Designer Vorlagen entwirft, welche zu außergewöhnlich sind und mit dem eingesetzten UI-Framework nicht ohne erheblichen Mehraufwand umsetzbar sind. Ein weiteres Problem besteht im eingeschränkten Funktionsumfang des Prototyping-Tools. Denn nicht immer ist es möglich, das Endverhalten eins zu eins nachzubilden, wodurch falsche Annahmen entstehen können.
Der aktuelle Trend geht daher in die Richtung, den kompletten Styleguide „lebendig“ als eigene Webanwendung umzusetzen. Die Elemente werden also vor ihrer Verwendung in der eigentlichen Anwendung implementiert und die Entwickler müssen sich nur noch den Quellcode kopieren.
Abbildung 2: Beispiel aus dem IBM Styleguide (www.ibm.com)
Die Vorteile einer solchen Umsetzung liegen auf der Hand: Neben einer guten Strukturierung der benötigten Informationen und Elemente wird vor allem die Wartbarkeit erheblich verbessert. Denn falls eine Farbe geändert werden muss, ist dies im „Living Styleguide“ meist nur eine Farbcode-Änderung im Stylesheet, während im traditionellen, dokumentenbasierten Styleguide unzählige Abschnitte und Designs angepasst werden müssen. Darüber hinaus kann die QA-Abteilung schon vor der eigentlichen Entwicklung das angeforderte Verhalten testen. Es besteht sogar die Möglichkeit, Änderungen am Styleguide direkt in die Anwendung fließen zu lassen, wenn beide Anwendungen auf das gleiche Stylesheet referenzieren. Dadurch können Redundanzen und Inkonsistenzen von vornherein ausgeschlossen werden. Wie sehr der Styleguide in den Entwicklungsprozess integriert wird, ist sicherlich projektabhängig, jedoch sind den Möglichkeiten der Optimierung hierbei keine Grenzen gesetzt.
Der „Living Styleguide“ ist mittlerweile in aller Munde und wird von zahlreichen Top IT-Unternehmen wie beispielsweise Google oder IBM verwendet. Er lässt die Lücke zwischen Design und Entwicklung immer kleiner werden und am Ende lacht vor allem einer: der Nutzer :-)!
Vor längerer Zeit habe ich in einem Blogartikel unsere Design Prinzipien vorgestellt, nach welchen wir bei der Saxonia Systems (seit 03/2020 ZEISS Digital Innovation) nutzerfreundliche Software konzipieren und entwickeln. Im Rahmen der Entstehung unseres Custom Usability Index, mit dem der Erreichungsgrad der Usability eines Softwareprojekts gemessen werden kann, haben wir im Usability-Team diese Prinzipien noch einmal genau unter die Lupe genommen und auf 13 Oberkategorien erweitert, welche jeweils mehrere Usability-Aspekte umfassen. In diesem Artikel werden diese Kategorien und Aspekte genauer erläutert und durch Beispiele veranschaulicht.
Effektivität: Das Ziel erreichen. (Prinzip 1)
Die erste und somit wichtigste Regel ist die Einhaltung von Effektivität. Eine Anwendung soll dem Nutzer eine effektive Arbeitsweise ermöglichen, indem eine geeignete Funktionalität zur Erledigung seiner Aufgabe zur Verfügung gestellt wird. Der Nutzer wird nicht mit Informationen und Funktionen belastet, die für seinen Anwendungsfall unnötig sind. Entsprechend sollten Dialoge nur relevante oder häufiger benötigte Informationen enthalten. Jede zusätzliche Information lenkt den Nutzer von den wichtigen Inhalten ab, und es besteht die Gefahr einer Reduktion der relativen Sichtbarkeit.
Es gilt daher die zentrale Frage zu beantworten: Was ist wirklich die Aufgabe, die unterstützt werden soll? Eine gründliche Analyse der Arbeitsabläufe und deren Verständnis ist der Schlüssel, um die Aufgaben und Ziele der Nutzer zu verstehen und die Effektivität ihrer Umsetzung beurteilen zu können.
Abbildung 1: Wie viel Information ist notwendig, um die Uhrzeit anzuzeigen?
Effizienz: Schnell zum Ziel kommen. (Prinzip 2)
Ebenfalls besondere Beachtung verdient die Optimierung von Effizienz. Dem Nutzer soll es ermöglicht werden, eine Aufgabe in minimaler Zeit zu erledigen. Zugleich benötigt die Anwendung nur minimale Zeit zur Reaktion und zur Ausführung einer Aktion. Dieses Prinzip bezieht sich also auf die Arbeitsgeschwindigkeit von Nutzer und System. Anhaltspunkte dafür, dass der Nutzer nicht effizient arbeiten kann, sind beispielsweise für ihren Zweck unpassend eingesetzte Interface-Widgets, fehlende Default-Werte, unzutreffende Suchergebnisse und hochauflösende Bilder, welche eine schnelle Internetverbindung voraussetzen.
Hinweise auf eine geringe System-Effizienz sind hingegen verzögerte Reaktionen auf Eingaben in Form von „ruckelnden“ Mauszeigern, langsamen Interface-Widgets und fehlendem Feedback.
Steuerbarkeit: Der Nutzer hat die Macht! (Prinzip 3)
Der Nutzer hat, unter Beachtung seiner Berechtigungen im System, die Kontrolle über alle Aktionen. Er kann Vorgänge abbrechen, pausieren und zu einem späteren Zeitpunkt fortsetzen. Er hat die Möglichkeit, eine Aktion rückgängig zu machen und ggf. einen neuen Anlauf zu starten, falls das Ergebnis nicht zufriedenstellend war. Für die Steuerung der Anwendung hat der Nutzer weiterhin die Möglichkeit, entsprechend seinen persönlichen Anforderungen zur Maus alternative Eingabegeräte wie Tastatur, Screenreader und Braillezeile zu nutzen. Werden diese Punkte nicht eingehalten, führt das zu einer gesteigerten Frustration des Nutzers.
Individualisierbarkeit: Alles passt zum Nutzer. (Prinzip 4)
Die Anwendung soll flexibel genug sein, um verschiedene Herangehensweisen zur Erledigung einer Aufgabe zu unterstützen. Der Nutzer kann das System zudem an seine Vorerfahrungen, Kultur und Bedürfnisse anpassen, z.B. durch Änderung der Schriftgröße, Änderung von Default-Einstellungen und die Festlegung eigener Shortcuts. Ein gutes Beispiel für die Berücksichtigung von Individualisierbarkeit ist das Online-Portal http://www.elster.de/, über das man Steuererklärungen webbasiert erfassen und abgeben kann. Nach dem Login wird der Nutzer gefragt, welcher Benutzergruppe er angehört, um die Anwendung anschließend auf dessen Bedürfnisse anzupassen:
Abbildung 2: Individualisierbarkeit bei ELSTER Online
Konsistenz: Alles passt zusammen. (Prinzip 5)
Die Bedienung der Anwendung soll in jedem Aspekt den Erwartungen des Nutzers entsprechen und allgemeine Konventionen (Plattformen, Styleguides etc.) befolgen. Einen Beitrag dazu leistet die einheitliche Verwendung von Begriffen, Icons und Layouts innerhalb der Anwendung und zwischen Produkt-Familien. Auch Prozessstrukturen folgen einem einheitlichen Prinzip. Durch die Einhaltung von Konsistenz kann vom Nutzer ein einmal erlerntes Verhaltensmuster wiederverwendet werden. Zum Beispiel weiß (und erwartet) der Nutzer im Verlauf der Benutzung der Anwendung(en), dass sich der Button zum Schließen eines Dialogfensters immer oben rechts in der Ecke befindet. Wechselt er jedoch auf das Betriebssystem Mac OS X, muss er sich gänzlich neu eingewöhnen. Anhaltspunkte dafür, dass sich eine Anwendung nicht erwartungskonform und konsistent verhält, sind überraschte bis verwirrte Nutzer und z.B. die Verwendung verschiedener Begriffe für ein und dieselbe Funktion.
Design und Layout: Auf den ersten Blick verständlich. (Prinzip 6)
Dieses Prinzip umfasst alle Aspekte der visuellen Gestaltung einer Anwendung. Demnach sollen die Art der Gruppierung und Anordnung der GUI-Elemente sowie der bewusste Einsatz von Farbe den Nutzer bei der Erkennung von Zusammenhängen unterstützen. Informationen und Komponenten werden dem Nutzer generell so präsentiert, dass er sie wahrnehmen und Textinhalte gut lesen kann. Gegenanzeigen hierfür sind z.B. unklare Zuordnungen von Labels zu Datenfeldern, winzige Schriftarten und ein schwacher Farbkontrast zwischen Vorder- und Hintergrund.
Sprache: Die Sprache des Nutzers sprechen. (Prinzip 7)
Die Anwendung sollte grundsätzlich die Sprache des Nutzers widerspiegeln und dessen Denkweise entsprechen. Textelemente sollten daher eindeutig formuliert sein und einen für die Zielgruppe verständlichen Wortschatz gebrauchen. Dennoch werden Dinge oft systemtechnisch formuliert statt in der Sprache der Anwender. „Bestes“ Beispiel dafür sind Fehlermeldungen mit einem Detailgrad, in dem sie zwar für den Systementwickler von Wert sind, dem Nutzer aber nicht weiterhelfen. Um dies zu vermeiden, sollte der fachliche Sprachschatz der Endnutzer genau analysiert werden.
Sichtbarkeit: Der Nutzer erkennt seine Möglichkeiten. (Prinzip 8)
Damit der Nutzer seine Aufgabe erledigen kann und nicht die Orientierung verliert, muss er jederzeit wissen, wo in der Anwendung er sich befindet und welche Aktionen wie ausgeführt werden können. Auch weiß er jederzeit, in welchem Status sich das System gerade befindet. Das Hauptmenü sollte dem Nutzer daher dessen aktuelle Position anzeigen und bspw. über eine Breadcrumb-Navigation den Weg dorthin nachvollziehbar machen. Relevante Objekte, Funktionen und Optionen sollten sichtbar sein und den Nutzer das Gesuchte direkt finden lassen. Er soll beurteilen können, welche Folgen eine Aktion haben wird.
Feedback: Der Nutzer erfährt, was los ist. (Prinzip 9)
Das System sollte jederzeit auf Eingaben des Nutzers reagieren und ihn aktiv über Ereignisse informieren. Bei einem aufgetretenen Fehler sollte eine entsprechende Meldung dem Nutzer die Ursache des Fehlers aufzeigen und ihm, sofern möglich, einen Lösungsvorschlag unterbreiten. Weist die Anwendung in Sachen Feedback Defizite vor, ist dies beispielsweise bei einer komplexeren Operation an einem fehlenden Spinner-Icon ersichtlich und Nutzer-Eingaben werden gefühlt vom System ignoriert. Der Nutzer nimmt wahr, dass die Anwendung „hängt“.
Lernförderlichkeit: Leicht zu lernen. (Prinzip 10)
Das System sollte den Nutzer beim Kennenlernen der Benutzungsoberfläche unterstützen und ihn zum Ausprobieren von ihm unbekannten Funktionen ermutigen, ohne dass dies negative Auswirkungen für den Nutzer mit sich bringt. Vor allem in der ersten Phase der Benutzung sollte der Nutzer bei komplizierten Aktionen unterstützt und so mögliche Fehlschritte eingeschränkt werden. Hier helfen kurze Tutorials und beschreibende Texte. Eine Möglichkeit zum experimentellen Lernen bietet weiterhin ein Probemodus, d.h. ein gesonderter Testbereich in der Anwendung, in dem alle Funktionen ohne Konsequenzen ausprobiert werden können. Durch den Probemodus wird der Nutzer am System geschult und lernt den Umgang mit dem System, ohne einen Prozess vollständig durchführen zu müssen.
Hilfe und Dokumentation: Hilfe, die hilft. (Prinzip 11)
Hilfesysteme sollen leicht auffindbar bzw. möglichst in die Interaktion eingebettet sein. Zu eingebetteten Hilfen zählen Tooltipps, Platzhalter, kurze Hilfetexte und Assistenten. Ist dies nicht hinreichend, sollte die Wahl auf kontextuelle Hilfen wie einem Hilfe-Panel, Einstiegsseiten und Suchfunktion fallen. Zu beachten ist, dass die Hilfesysteme dem Nutzer nur dann eine Unterstützung sind, wenn sie sich auf die Aufgabe des Nutzers beziehen und konkret auszuführende Schritte zur Lösung des Problems auflisten.
Fehlertoleranz: Nutzerfehler verzeihen und vermeiden. (Prinzip 12)
Das System sollte von vornherein so gestaltet sein, dass der Nutzer aktiv vor Fehlern bewahrt wird, beispielsweise indem unzulässige Funktionen deaktiviert werden und die Einschränkung zusätzlich begründet wird. Passiert es doch einmal, sollten fehlerhafte Eingaben oder Aktionen vom System erkannt werden. Im Falle von Eindeutigkeit behebt das System den Fehler dann, wenn möglich, selbstständig. Gibt es mehrere Möglichkeiten, werden alternative Korrekturvorschläge aufgezeigt. Niemals hingegen darf der Fehler zum Datenverlust oder gar Systemabsturz führen.
Nutzungsgefühl (UX): Die Software fühlt sich gut an. (Prinzip 13)
Ein Aspekt, den wir bisher nicht berücksichtigt haben, ist die User Experience (abgekürzt UX). Das sogenannte Nutzungsgefühl resultiert aus dem Gesamterlebnis des Nutzers mit der Anwendung und setzt sich zusammen aus der tatsächlichen Nutzung, der Erwartung des Nutzers und der Vorerfahrung mit anderen Systemen. Die Anwendung vermittelt dem Nutzer ein Gefühl von Sicherheit und Zuverlässigkeit, macht Spaß und ist zweckdienlich. Das System begeistert den Nutzer, indem bestimmte Erwartungen nicht nur befriedigt, sondern auch übertroffen werden. Prinzip 13 wird also zum Großteil dadurch erfüllt, dass die zuvor genannten Prinzipien eingehalten werden. Eine langsame, inkonsistente Anwendung mit vielen Fehlermeldungen und Abstürzen wird hingegen nicht zur Zufriedenheit des Nutzers beitragen. Entsprechend sollte sich die Software immer auf dem aktuellen Stand der Technik befinden und aktuelle Steuerparadigmen unterstützen.
Abschluss
In diesem Blogbeitrag wurden 13 wichtige Prinzipien zur Erreichung einer nutzerfreundlichen, zufriedenstellenden Software vorgestellt. Zu beachten ist dabei, dass es keine einzig wahre, benutzungsfreundliche Lösung gibt. Wie gut eine Anwendung bedienbar ist, hängt immer von dem konkreten Anwendungsfall und der Nutzergruppe ab. Es ist daher zu empfehlen, die Bedürfnisse der Nutzer genau zu analysieren und sie durch Nutzertests einzubeziehen.
In zwei früheren Blogbeiträgen habe ich einerseits das Konzept des Custom Usability Index vorgestellt, sowie die Vorbereitungsphase genauer erläutert, in welcher Usability-Kategorien individualisiert und gewichtet werden. Mit diesem Blogbeitrag möchte ich tiefer auf die tatsächliche Anwendung eingehen und erklären, welche Schritte notwendig sind, um am Ende eine valide CUI-Bewertung zu erhalten.
Folgender Stand soll als Startpunkt unseres Anwendungsbeispiels dienen. Wir befinden uns in der Entwicklung einer neuen Web-Applikation für einen Business-Kunden. Der verantwortliche Product Owner hatte zu Projektstart die Usability-Kategorien durch einen UX-Experten erklärt bekommen und seine Zielzustände definiert. Diese hat er im Anschluss entsprechend seiner Anforderungen priorisiert und so den Grundstein zur regelmäßigen Messung der zukünftigen Anwendung mit dem CUI gelegt. Nach einiger Entwicklungszeit ist nun ein erster Release Kandidat auf das QA-System deployt worden und steht zum Test bereit.
Der Custom Usability Index (CUI) in Action – Jetzt geht es Ihrer Software an den Kragen!
Wie geht es jetzt weiter? Für den Test der 13 Usability-Kategorien sind mehrere, verschiedene Testmethoden möglich. Die Auswahl der Testmethodik orientiert sich neben der Eignung für die jeweilige Usability-Kategorie auch an zahlreichen weiteren Faktoren. Die Verfügbarkeit der Endnutzer, das Wissen des Usability-Testers sowie zeitliche und monetäre Ressourcen spielen eine wichtige Rolle. Das Wunschszenario, mit mehreren Usability-Testern inklusive Protokollanten zahlreiche Endnutzer einem ausgiebigen und zeitlich intensiven Test zu unterziehen, ist in der Praxis selten der Fall.
Was verlieren wir durch das Eindämmen der Ressourcen? Hauptsächlich Genauigkeit und Unabhängigkeit in der Messung. Jedoch ist dies nicht das primäre Ziel des CUI. Durch die Tests, egal in welchem Ausmaß, sollen hauptsächlich Probleme und Verbesserungspotentiale aufgezeigt werden. Das heißt, selbst wenn das Ergebnis von Test A zu Test B abweicht sind die Schmerzpunkte klar und ermöglichen so Ansätze für eine besser nutzbare Software zu schaffen. Eine ressourcenschonende Variante des Testens ist die heuristische Evaluation. Die heuristische Evaluation ist eine Inspektionsmethode, bei der eine Gruppe von Usability-Experten eine Anwendung auf die Einhaltung von ausgewählten Richtlinien und Heuristiken (in diesem Fall die dem Nutzungskontext angepassten Usability-Kategorien des CUI) untersucht. Nach Nielsen finden ca. 7 Tester 80% der gesamten Usability-Fehler, Folge-Tests sind weniger ergiebig, da kaum noch weitere Fehler gefunden werden.
In der Praxis von agilen Softwareentwicklungsprojekten ist es jedoch Luxus überhaupt mehrere Usability-Experten für den Test zu bekommen, so dass üblicher Weise 1-2 Experten die Evaluation durchführen. Ein mit der Anwendung vertrauter Usability-Experte sollte je nach Komplexität der Anwendung und dem Dokumentationsumfang in der Lage sein, innerhalb von 1-2 Tagen ein brauchbares Messergebnis zu erzielen. Das heißt Sie können auch schon mit mehreren „kleineren“ Usability-Tests die Qualität Ihrer Software steigern und erste Verbesserungen erzielen.
Ein Beispiel – Die Messung von 13 Kategorien, 31 Kriterien „in a nutshell“. Starten wir mit der ersten Kategorie Effektivität. Der Product Owner hat für diese Kategorie folgenden Zielzustand definiert: „Der Nutzer hat jederzeit Zugriff auf die zur Aufgabenerledigung notwendigen Funktionalität und erreicht diese in höchstens 2 Schritten. Er wird dabei nur mit den für ihn im Moment notwendigen Informationen belastet (Daten sollen im Vordergrund stehen).“
Zusätzlich wurde Effektivität mit der Fibonacci-Zahl 3 gewichtet. Die Kategorie Effektivität besteht aus den zwei Kriterien Funktionsumfang und Angemessenheit. Für das Kriterium Funktionsumfang müssen nun die verschiedenen Use-Cases der Webanwendung überprüft und zusätzlich geschaut werden, ob die dazu benötigten Funktionen in höchstens 2 Schritten erreichbar sind.
Der Zielzustand für dieses Kriterium ist für den aktuellen Release Kandidaten vollständig erfüllt und es wird somit die Maximalbewertung von 5 Punkten erteilt. Weiter geht es mit dem zweiten Kriterium Angemessenheit. Es fordert, dass der Nutzer nur mit den für ihn im Moment notwendigen Informationen belastet wird und die Daten im Vordergrund stehen.
Durch mehrere kleinere Auffälligkeiten gibt es 2 Punkte Abzug und somit eine Bewertung von 3 Punkten. Zusammengerechnet mit der Bewertung des Kriteriums Funktionsumfang bedeutet dies eine durchschnittliche Bewertung von 4 Punkten für die übergeordnete Kategorie Effektivität. Die Messung der übrigen 12 Kategorien und 29 Kriterien sollte analog zum obigen Beispiel erfolgen. Da die vollständige Dokumentation eines CUI-Tests jedoch den Rahmen dieses Blogbeitrages sprengen würde, springen wir einen Schritt weiter und schauen uns die Endberechnung einmal genauer an.
Beispiel einer fertiggestellten CUI-Berechnung
Obige Tabelle zeigt eine vollständig ausgefüllte CUI-Berechnungsmatrix nach Testbeendigung. Der finale CUI-Wert setzt sich wie folgt zusammen:
Berechnung des Durchschnittswertes einer Kategorie (Summe der Bewertung / Anzahl der Kriterien)
Berechnung der relativen Gewichtung (Gewichtungswert der Kategorie / Summe aller Gewichtungswerte)
Berechnung des finalen Kategorienwertes (Durchschnittswert der Kategorie * relative Gewichtung)
CUI-Wert = Summe der finalen Kategorienwerte
CUI-Erreichungsgrad = ((CUI-Wert – 1) / 4)
Rechnen wir dies einmal anhand unseres Beispiels nach:
Bewertung der Kategorie Effektivität (Funktionsumfang 5 Punkte + Angemessenheit 3 Punkte) / 2 Kriterien = 4 Punkte
Summe der Gewichtungen aller Kategorien = 24
Relative Gewichtung der Kategorie Effektivität = 3/24 = 0,125
Einzelwert der Kategorie Effektivität = Bewertung von 4 * relative Gewichtung 0,125 = 0,50
Juhu geschafft – Und nun?
Erst einmal herzlichen Glückwünsch, dass Sie sich um das Wohl Ihrer Nutzer gekümmert haben. Doch nun gilt es weitere Schritte einzuleiten:
Entwickeln Sie Lösungsvarianten für die aufgezeigten Probleme in Form von Wireframes und Prototypen
Zeigen Sie den Einfluss kommender User Stories in Bezug auf die verschiedenen Usability Kategorien auf
Hinterfragen Sie die Anforderungen Ihres Product Owners … Sie sind der Experte!
Zeigen Sie aktiv Alternativen auf und setzen Sie die vorgesetzten Anforderungen nicht einfach stillschweigend um
Führen Sie in regelmäßigen Abständen einen erneuten CUI-Test durch und tracken Sie so den Einfluss der Verbesserungen bzw. neuer Anforderungen auf die Nutzbarkeit Ihrer Software
Durch den Custom Usability Index ist es möglich mit geringem Ressourcenverbrauch hilfreiche Ergebnisse zu erzielen. Das leichtgewichtige Vorgehen bettet sich nahtlos in den agilen Softwareentwicklungsprozess ein und zeigt Schwachstellen Ihrer Software auf. Durch regelmäßige Tests wird ein langfristiges Tracking möglich und Usability tatsächlich greifbar gemacht. Trauen Sie sich, Ihre Nutzer werden es Ihnen danken!
Ein Einblick in Usability Tests in der agilen Softwareentwicklung!
Das Konferenzjahr 2017 startete im Januar – wieder mit der OOP. Auch diesmal befand sich eine Umfrage im Gepäck nach München. Wie im vorangegangenen Blogbeitrag zur WJax bereits beschrieben, wollten wir uns erneut dem Arbeitsumfeld der Befragten widmen. Dadurch ergibt sich die Möglichkeit, Rückschlüsse auf die zielgruppenabhängige Sichtweise auf eingespielte Teams zu ziehen, da die Rahmenbedingungen z.B. mit Fragen und Konferenzort im Vergleich zur WJax gleichbleibend sind. Einziger wesentlicher Unterschied ist bei den Funktionen der Umfrageteilnehmern festzustellen, da wir bei der OOP vorrangig Softwarearchitekten, Entscheider und Berater vorfinden, während die WJax überwiegend von Softwareentwicklern aufgesucht wird.
Durch den gleichen Aufbau der Fragebögen startet auch dieser mit der Frage, wie die Teilnehmer ihren Arbeitsweg zurücklegen. Die Aussagen weichen hier nur bedingt von denen der WJax ab. Das am stärksten genutzte Mittel ist weiterhin der PkW, auch wenn die S-Bahn ebenfalls weit mehr frequentiert ist, als andere öffentliche Verkehrsmittel.
Abbildung 1: Mit welchem Verkehrsmittel legen Sie Ihren Arbeitsweg zurück?
Der darauffolgenden Frage „Wie beschäftigen Sie sich auf dem Weg zur Arbeit?“ lagen weiterhin zwei Gedanken zu Grunde. Erstens ist es üblich, dass heutzutage immer wieder bereits auf dem Arbeitsweg erste Mails bearbeitet, neueste Nachrichten aufgeschnappt oder Fachartikel gelesen werden. Doch wie viele Personen beschäftigen sich tatsächlich mit geschäftlichen Dingen? Zweitens stellte sich die Frage, ob im Zeitalter der Digitalisierung Smartphone und Laptop die klassischen Medien gänzlich verdrängt haben. Daher ist unser Interesse darauf gerichtet, welches Medium vorrangig zum Informationskonsum genutzt wird.
Abbildung 2: Beschäftigung auf dem Arbeitsweg
Geht es um die Nutzungszwecke, sieht man auch in dieser Umfrage den deutlichen Vorsprung der digitalen Medien gegenüber den klassischen, wie Print und Fernsehen in Straßenbahnen. Auch nur vereinzelt werden Radio oder Hörbuch angegeben. Damit wird deutlich, dass das Smartphone immer mehr zur „Allzweckwaffe“ wird, da es die verschiedenen Kanäle auf Grund der vielfältigen Nutzungsoptionen miteinander vereint.
Auffällig ist jedoch, dass im Vergleich zur WJax die geschäftliche Nutzung einen Aufschwung verzeichnet. Mit gut 1/3 zu 2/3 liegen geschäftliche und private Nutzung hier nicht so weit von einander entfernt. Dies bestätigt unsere Erfahrungen, dass mit zunehmendem Entscheiderlevel der Arbeitsweg bereits durch Vorgänge im Arbeitsalltag bestimmt wird.
Zusammenarbeit – eingespielte Teams als Erfolgsgarant?
Abbildung 3: Stimmen Sie der These „Stabile Teams sind ein Garant für Projekterfolge“ zu?
Beim Einstieg in den inhaltlichen Bereich wird deutlich, dass sich die Meinungen auf den Konferenzen nicht so stark voneinander differenzieren. Der These Stabile Teams sind ein Garant für Projekterfolge stimmen in Summe 78 % zu, damit liegt dieser Wert nur 3 Prozentpunkte unter dem der WJax. Ebenso die „unentschlossenen“ Antworten, die sowohl Vor- als auch Nachteile in stabilen Teams sehen und sich nicht festlegen können, ähneln sich auf den Konferenzen (14 % zu 16 %).
Abbildung 4: Wie oft ändert sich Ihr Kollegenkreis in Ihrer Arbeitsumgebung?
Betrachtet man die kollegialen Veränderungen durch Mitarbeiterfluktuation, findet sich auch hier ein ähnliches Bild. Nur gut 1/5 gibt an, dass sich ihr Kollegenkreis kaum bis gar nicht ändert. Damit zeigt sich eine noch stärkere Tendenz zu instabilen Teams. Es ist ebenfalls keine Abhängigkeit von dem Kollegenumkreis bzgl. ihrer Angestelltensituation erkennbar, beispielsweise ob ausschließlich mit internen Kollegen gearbeitet wird.
Abbildung 5: Ihre Kollegen sind …
Ein weiterer Faktor, den wir erhoben haben, um besser das Arbeitsumfeld der Befragten verstehen zu können, ist das Wo gearbeitet wird. Dabei lässt sich auch ein entscheidender Unterschied zur WJax-Umfrage feststellen. Während dort gut doppelt so viele im Großraumbüro vergleichend zum Einzelbüro saßen, unterscheiden sich hier die Zahlen kaum voneinander.
Auf Grund dessen, dass diese Frage Mehrfachantworten zulässt, steht Home Office als weitere Antwort zur Verfügung. Da das Home Office aber ebenso wie auf der WJax bei keiner Befragung eigenständig angegeben worden ist, sondern nur in Verbindung mit den anderen beiden Optionen, lässt sich hier nur der Unterschied in der Verteilung auf die beiden anderen Optionen wahrnehmen: zwei Drittel ergänzen damit das Großraumbüro, ein Drittel das Einzelbüro.
Abbildung 6: Wie ist Ihr Arbeitsort beschaffen?
Ebenfalls als Einfluss auf die Stabilität von Teams, z.B. in Hinblick auf Aufgabenfokussierung, Kommunikationswege und Termine, stellt sich die Frage nach der Anzahl der Projekte, die zu absolvieren sind. Identische Werte zur WJax Umfrage (siehe Abbildung 7) zeigen, dass die stabilen Teams mit Barrieren, wie hohen Koordinationsaufwänden für jeden Einzelnen, die sich aus Deadlines, unterschiedlichen Anforderungen und Kommunikation mit den entsprechenden Teams, zu kämpfen haben. Diese (Konferenz-)zielgruppenübergreifenden Probleme lassen sich dadurch erklären, dass die Teams erst durch die Zusammensetzung verschiedenster Personenkreise zu Stande kommen und dadurch für alle Beteiligten die gleiche Situation vorhanden ist.
Abbildung 7: Arbeiten Sie an einem oder an mehreren Projekten?
Das Problem: Usability greifbar und nachvollziehbar machen
Wie steht es um die Usability meiner Software? Diese Frage stellt sich spätestens, wenn die tatsächlichen Nutzer die Anwendung das erste Mal zu Gesicht bekommen. Oft wird dann festgestellt, dass die geplante Software gar nicht optimal auf die Endnutzer abgestimmt ist. Zu diesem Zeitpunkt ist es meist zu spät größere Änderungen einzupflegen. Folgeprobleme wie die mangelnde Akzeptanz oder gar das Scheitern des Softwareprojektes sind mittlerweile durch zahlreiche Studien bestätigt. Ansätze wie das „User Centered Design“, welche den Nutzer in den Mittelpunkt des Entwicklungsprozesses stellen, zeigen wie erfolgreich diese Einbindung und die frühzeitige Betrachtung von Usability sein kann. Die Kernproblematik, welche jedoch bestehen bleibt, ist die Schwierigkeit Usability greifbar zu machen. Ein Lösungsansatz dazu soll mit diesem Beitrag vorgestellt werden.
Die Idee: Der Custom Usability Index
Der Custom Usability Index (CUI) stellt eine Kennzahl dar, welche zum aktuellen Projektzeitpunkt den Erreichungsgrad der Usability einer Software misst.
Die Basis: 13 Designprinzipien
Die Kennzahl repräsentiert dabei die aggregierte Bewertung von 31 Kriterien, welche 13 übergeordneten Kategorien zugeordnet sind. Die Kategorien basieren auf selbstentwickelten Designprinzipien, welche ihren Ursprung in ISO-Normen und der State-of-the-Art Literatur zu Usability haben.
Zu Beginn eines Projektes können Stakeholder die oben dargestellten Kategorien individuell nach ihren Anforderungen gewichten und so Schwerpunkte festlegen.
Die Bewertung: Where the magic happens
Da jedes Projekt einzigartig ist, muss zu Projektstart zusätzlich definiert werden, wann ein Kriterium die jeweils beste Usability erreicht hat. Um ein einheitliches Verständnis zu bekommen, welchen gewünschten Zielzustand die Anwendung in den jeweiligen Kriterien haben soll, ist es von Vorteil das komplette Team inklusive der beteiligten Stakeholder bei der Festlegung einzubeziehen. Ein positiver Nebeneffekt ist, dass beide Seite für das Thema Usability sensibilisiert werden.
Die eigentliche Bewertung der Kriterien erfolgt mit speziellen Usability-Testmethoden. Die Tests sind im Verlaufe eines Projektes regelmäßig am Teilprodukt durchzuführen. Die Maximalbewertung eines Kriteriums ist nur erreicht, wenn der vorher definierte Zielzustand zu 100% erfüllt ist. Der finale CUI-Wert spiegelt dann die gewichteten Durchschnittsbewertungen der 13 Kategorien wieder.
Das Ergebnis: Usability macht glücklich
Durch regelmäßiges Messen des CUI wird Usability für das Team sowie alle Stakeholder nachvollziehbar. Es ist jederzeit sichtbar, in welchem Zustand sich die Software in den einzelnen Kategorien befindet und an welchen Stellen eventuell noch nachgebessert werden muss.
Im obigen Beispiel ist eine stetige Verbesserung der Usability bis Release 2 erkennbar. Mit Release 3 wurde jedoch ein Rückgang festgestellt. Durch das Erkennen der betroffenen Kategorien konnte direkt in der Entwicklung nachgebessert werden. Das Ergebnis wird mit einem großen Usability Zuwachs mit Release 4 deutlich.
Mit dem in diesem Blogbeitrag vorgestellten CUI wurde eine Möglichkeit aufgezeigt, um die Usability einer Software über ihren Entwicklungsprozess hinweg zu messen und für alle Projektbeteiligten nachvollziehbar zu machen. Durch die hohe Transparenz und Sensibilisierung der Stakeholder für Usability allgemein erhält die Software ein unverkennbares Qualitätsmerkmal.
