ESE Fachwissen
Hübsch zu sein reicht nicht!
Autor: Johannes Bergsmann, Software Quality Lab
Beitrag - Embedded Software Engineering Kongress 2015
In der heutigen, von hübschen Smartphone-Apps geprägten Zeit verkauft sich Software, die zwar gut ist, jedoch kein modernes ansprechendes User-Interface (UI) hat, kaum mehr. Jedoch reicht eine hübsche Oberfläche alleine auch nicht aus, um Benutzer nachhaltig zu beeindrucken. Worauf muss man achten, wenn man UI-Design durchführt? Welche Techniken und Methoden kann man anwenden, um benutzertaugliche UIs zu erstellen? Wo soll das UI-Design im Requirements-Prozess positioniert werden? Welche Spezifikationstechniken sind von der ersten Idee bis zum fertigen UI-Design hilfreich? Diese Fragen werden im folgenden Beitrag behandelt.
User-Interfaces im Kontext des Requirements Engineerings
Wenn man die Ebenen des Requirements Engineering betrachtet (Abb. 1, PDF), wird ersichtlich, dass die Spezifikation des UI (Masken und Ausgeben des Systems wie z.B. Reports) primär in der Detailspezifikation auf unterster Ebene erfolgen soll.
Dies ist deswegen sinnvoll, weil im Vorfeld andere, das UI teilweise stark beeinflussende Aspekte geklärt und definiert werden sollten, wie z.B. die Ziele, Systemgrenzen, Prozesse und Abläufe sowie die groben Anforderungen. Wenn diese Punkte nicht vorab geklärt sind, besteht die Gefahr, dass man sich zu schnell in Details der Benutzer-Schnittstellen verliert und wichtige Aspekte, die auch die UI-Architektur betreffen, übersieht und nachfolgend dann große Aufwände bei der Umgestaltung des UIs entstehen.
Das Thema User Experience (UX) bzw. Usability des Systems sollte jedoch sinnvollerweise schon weiter oben bei der Stakeholderanalyse und den Prozessen beginnen, da hier allgemeine Anforderungen an die "Begeisterungsfaktoren" des Systems und die Ablaufgestaltung festgelegt werden.
User Interfaces im Kontext des Requirements Engineerings
User-Interface-Spezifikation ist das (ein) Bindeglied zwischen den Benutzer-Anforderungen und den technischen Lösungen (Abb.2, PDF).
Leider wird dies bei der Spezifikation und Umsetzung oft vernachlässigt. Dabei ließe sich bei guter Nutzung dieser Schlüsselstellung im Rahnen der Systemdefinition eventuell auch ein Perspektivenwechsel für Entwickler erreichen. Die Fokussierung sollte mehr auf dem Benutzer und seinen Aufgaben liegen, anstatt sich zu früh und intensiv mit der Analyse und Definition der technischen Lösung zu befassen. Die für den Benutzer nach außen sichtbaren Themen, die durch Usability bzw. User Interface Engineering adressiert werden, müssen auch passend in den Software-Entwicklungsprozess eingebettet sein.
Das Kano-Modell definiert 3 Faktoren, die aus Sicht des Anwenders unterschiedliche Bedeutungen haben (Abb.3, PDF).
Basisfaktoren muss das System jedenfalls erfüllen, ohne dass der Anwender diese vorher explizit anfordern muss. Die Nichterfüllung führt meist zu massiver Unzufriedenheit. Die Erfüllung führt jedoch nicht automatisch zu einer positiven Stimmung. Häufig sind dies unbewusste Anforderungen, die nicht explizit gefordert werden bzw. eventuell auch durch ein bereits bestehendes System geprägt sind (implizite Anforderungen). Ein Beispiel ist, dass man mit einem Handy auch telefonieren kann.
Leistungsfaktoren sollte das System erfüllen. Die Erfüllung erzeugt grundsätzlich Zufriedenheit, jedoch noch keine Begeisterung. Fehlen (wenige) Leistungsfaktoren, akzeptieren die Stakeholder das System meist trotzdem. Die Zufriedenheit sinkt jedoch auch mit jedem fehlenden Leistungsfaktor. Leistungsfaktoren werden vom Stakeholder bewusst und explizit gefordert (bewusste Anforderungen). Ein Aspekt, der auch in der Planung und Roadmap von Systemen berücksichtigt werden muss, ist die Tatsache, dass Basisfaktoren im Laufe der Zeit und Benutzung durch den Anwender zu Basisfaktoren werden. Ein Beispiel für Leistungsfaktoren ist, dass man mit dem Handy auch Internetsurfen und ganz gut fotografieren kann.
Begeisterungsfaktoren kann das System erfüllen, und die Erfüllung erzeugt große Zufriedenheit bzw. Begeisterung. Die Anwender rechnen meist nicht damit und fordern diese Faktoren daher auch nicht explizit an (nicht bekannte Anforderungen). Sie müssen diese vorgeschlagen bekommen bzw. ausprobieren können. Die Zufriedenheit steigt relativ stark mit jedem Begeisterungsfaktor. Auch hier ist ein Veränderungsaspekt zu berücksichtigen: Begeisterungsfaktoren werden im Laufe der Zeit und Benutzung durch den Anwender zu Leistungsfaktoren. Ein Beispiel für Begeisterungsfaktoren ist, dass das Handy auch den Blutdruck und Temperatur und meinen täglichen Kalorienverbrauch messen kann. Begeisterungsfaktoren sind diejenigen Eigenschaften eines Systems, welche die größten Auswirkungen auf Usability und positives Erleben des Systems durch den Benutzer haben.
User Interface Spezifikationsebenen
Der grundlegende Ablauf bei der Spezifikation von UIs ist in Abb.4 (siehe PDF) dargestellt. Um das UI benutzerorientiert und systematisch zu erstellen, sollte man nicht sofort mit dem Design starten, sondern vorher noch andere Überlegungen und Analysen durchführen. Das Ziel dabei soll die "benutzerzentrierte Schnittstelle" sein.
Vom System-Verhalten zum UI
Bevor mit dem Prototyping oder der Detailgestaltung der Benutzeroberfläche begonnen wird, sollte eine systematische Aufgaben-/Prozessanalyse durchgeführt werden. Dazu bieten sich z.B. Ablauf-/Prozessdiagramme an. Strukturbäume helfen, einen hierarchischen Überblick zu bekommen und schrittweise vom Groben ins Detail zu gelangen. (Geschäfts-)Prozesse sind die Basis für fast alle Features eines Systems. Daher soll die Prozess-Übersicht möglichst bald erstellt werden; die Detailspezifikationen können dann davon abgeleitet werden bzw. sich daran orientieren.
Diese Spezifikationsschritte sind kein sequenzieller Vorgang, sondern sollten bzw. können iterativ durchlaufen werden.
UI-Entwurf und -Spezifikation
Für den ersten grafischen Entwurf genügt meist eine (schnelle) Handskizze (Abb.5, PDF). Auf dieser Basis können schon erste Diskussionen, Änderungen und Klärungen erfolgen. Auf Basis der ersten groben Skizzen und Diskussionen kann man dann systematisch das detaillierte UI entwickeln. Der nächste Schritt sollte dann die klare Strukturierung und Definition des Aufbaus des UIs sein (Abb.6, PDF).
Sketches und Wireframes sind das Kernstück jedes Produktionsprozesses von Benutzeroberflächen. Sie sollten auf den vorab definierten Use Cases und Prozessen basieren und halten fest, welche Screen-Elemente in den einzelnen Interaktionsschritten des Ablaufs vorhanden sein müssen. In der Regel werden sie schwarz/weiß ausgeführt mit dem Fokus auf funktionaler Umsetzung und nicht auf visueller Gestaltung. Anmerkungen zu den einzelnen Screenelementen liefern den Entwicklern Hinweise für die Umsetzung.
Im letzten Schritt wird das fertige Design in Form von Detailskizzen oder Prototypen erstellt (Abb.7, PDF).
Sketches und Wireframes versus Visual Design
Der Auftraggeber möchte möglichst meist schon früh visuelle Designs sehen. Dies birgt die Gefahr einer zu frühen Detaillierung und schränkt die Designer später bei der eigentlichen Ausgestaltung des UI unnötig ein. Eine zu frühe Festlegung der Details kostet außerdem Geld und Zeit durch unnötige Diskussionen über Details, die dann in weiteren Iterationen sowieso noch x-mal geändert werden.
Wichtig bei der Konzeption des UI ist die Konzentration auf das Wesentliche. Das Grundprinzip "vom Groben ins Detail" sollte eingehalten werden. Sketches bzw. Wireframes sind ein gutes Mittel in frühen Gestaltungsschritten, weil sie den Eindruck des Unfertigen vermitteln und nicht (so sehr) dazu verleiten, Details zu früh zu diskutieren. Sie helfen dabei, die visuellen Präferenzen des Anwenders explorativ herauszufinden.
Weitere UI-Spezifikationstechniken
User Journeys fokussieren auf den Anwender und seine Arbeitsweise. Sie sind eine High-Level-Beschreibung von Aufgaben bzw. Prozessen, die der Anwender mit der Software durchführt. Also eine Darstellung der Interaktion des Anwenders mit der Software. Typischerweise werden für die Visualisierung der User-Journeys Prozessdarstellungen verwendet (Abb.8, PDF).
Story Board ist eine weitere Möglichkeit der Darstellung des Interaktionsprozesses eines Nutzers mit einem System. Grundsätzlich ist dies ähnlich zur User Journey, jedoch mit weniger Fokus auf den exakten Workflow, sondern mehr auf die grobe Visualisierung des User´Interface im Kontext der gewünschten Funktion. Typischerweise wird hier eine Folge von Wireframes mit erklärendem Text dargestellt (Abb.9, PDF).
Story Boards sind eine gute Technik und visuelle Stütze für die Diskussion und Spezifikation der Systeminteraktionen gemeinsam mit dem Anwender. Hier zeigt sich früh die Funktionalität der Elemente und des Navigationsschemas. Die Anforderungen werden visualisiert, ohne diese bereits umzusetzen.
Einige Schlüsselfaktoren für den Erfolg bei der UI-Spezifikation
- Unbedingt zuerst das Verhalten spezifizieren und dann das UI darauf aufbauend definieren
- UI-Grobentwürfe als Basis für die Stakeholder-Diskussionen verwenden
- Ablaufsicht des UI berücksichtigen (z.B. durch Story Boards oder User Journeys)
- Passende Tools und Techniken verwenden
- UI iterativ entwickeln und verfeinern
- Nicht zu früh in UI-Details vertiefen
Resümee
Die User Interface Spezifikation ist wichtiger Teil des Requirements Engineerings. UI-Themen ziehen sich durch die gesamten Requirements-Ebenen. Das gewünschte und definierte Systemverhalten hat einen starken Einfluss auf die Gestaltung des UI. Daher ist eine systematische Konzeption und Strukturierung im Vorfeld sehr wichtig.
Das UI ist eine wichtige Grundlage für die Diskussion mit den Stakeholdern. Sketching & Wireframes unterstützen die frühe Spezifikation und Diskussion. Darüber hinaus gibt es noch eine Reihe verschiedener Tools für die UI-Spezifikation.
Die endgültige Festlegung des UI sollte möglichst spät erfolgen, um sich nicht zu bald in Details zu verlieren und Aufwände für Detailausarbeitungen zu vermeiden, die in späteren Iterationen meist noch geändert werden.
Implementierung - unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Implementierung /Embedded- und Echtzeit-Softwareentwicklung.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Implementierung - Fachwissen
Wertvolles Fachwissen zum Thema Implementierung/ Embedded- und Echtzeit-Softwareentwicklung steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.