User Centered Design Archives - Digital Innovation Blog

SAP Fiori: Eigentümerwechsel einer Verbrauchsstelle mit SAP IS-U, ODATA und SAPUI5 (Teil 3)

Fiori Apps sind aus der modernen SAP-Entwicklung nicht mehr wegzudenken! Sie dienen der Umsetzung anwenderfreundlicher SAP-Oberflächen und bieten mehr Möglichkeiten bzgl. moderner Usability. Die dahinter liegenden Technologien OData und SAPUI5 sollen im Folgenden näher betrachtet werden.
Im ersten Teil der Blogreihe wurde der Use Case eines Eigentümerwechsels im SAP IS-U System vorgestellt. Davon ausgehend wurde in einem ersten Schritt die Erstellung des OData-Services beschrieben, welcher die zur Anforderung passenden Informationen bereitstellt. Darauf aufbauend konnte im zweiten Teil der Blogreihe die umgesetzte UI5-Anwendung vorgestellt werden. Diese nutzte den im ersten Teil beschriebenen OData-Service, um bestimmte Daten aus dem SAP-System zu lesen, zu aktualisieren und neue Datensätze zu erstellen.

Vorbetrachtung des dritten Parts

Im dritten und letzten Teil der Blogbeitragsreihe werden die alte und die neue Welt auf Prozessebene gegenübergestellt und es wird auf das User Centered Design (UCD) mit Hilfe von Fiori eingegangen, welches den Anwender für die Erstellung effizienter Software in den Vordergrund rückt. Doch zuvor soll in einem ersten Schritt auf das SAP-Bypassing eingegangen werden, welches die Art und Weise der Anwendungsentwicklung für SAP-Systeme neu charakterisiert.

SAP-Bypassing mit OData

In der heutigen Zeit besitzen Unternehmen eine Vielzahl verschiedener Systeme zur Bewältigung unterschiedlichster Aufgaben. Im Kontext einer SAP-Systemlandschaft gibt es also Unternehmen, welche verschiedene SAP-Systeme, z.B. für die Ressourcenplanung oder für B2B-, B2C- und B2E-Szenarien, betreiben. Dies bringt verschiedene individuelle oder gesetzliche Anforderungen mit sich, die in einem System oder über eine Systemlandschaft hinweg umzusetzen sind.

*Abbildung 1: Arten von Anforderungen an ein System*

Im Laufe der Zeit entstehen somit viele verschiedene Anforderungen an ein System. Mit der Umsetzung nehmen die Komplexität und die Verzahnung mit anderen Komponenten im System sowie mit Kommunikationspartnersystemen stetig zu.

Die Anpassungen und Eigenentwicklungen verkomplizieren die Systemabläufe und sind teilweise extreme Performancekiller.

Die Ergebnisse sind unter anderem:

Immer längere Ladezeiten
Hoher und komplexer Wartungsaufwand und
Unzufriedene Nutzer

*Abbildung 2: Nachteile vieler umgesetzter Anforderungen*

Hier kommt das Bypassing ins Spiel. Dessen Kernziel ist es, das System möglichst nahe am Standard zu belassen und die Umsetzung verschiedener Anforderungen aus dem SAP-System herauszulösen.

Um dies zu realisieren, bietet das SAP-System das Werkzeug der OData-Service-Entwicklung, welches bereits im ersten Teil der Blogreihe gezeigt wurde. Mit Hilfe des Open Data Protokoll (OData) ist es also möglich, eine standardisierte Schnittstelle zum SAP-System bereitzustellen. Die Umsetzung der gestellten Anforderungen kann somit nun vom System getrennt werden und es entsteht eine modulare Architektur, welche kombiniert, ausgetauscht, erweitert oder verändert werden kann.

*Abbildung 3: Auslagerung der Anforderungen aus dem System*

Damit entstehen für das System und die Anwendungsentwicklung weitere Vorteile, wie in Abbildung 4 „Vorteile der Komponententrennung“ zu sehen ist.

Der Eigentümerwechsel in der alten Welt

Im SAP-System werden Funktionalitäten in Transaktionen abgebildet, welche über sogenannte Transaktionscodes aufgerufen werden. Das Problem ist jedoch, dass viele Transaktionen mit Funktionalitäten überladen sind. So kann es vorkommen, dass es in einer Transaktion vielleicht zehn Reiter für verschiedene Anforderungen gibt, der Nutzer jedoch nur einen oder zwei Reiter für seine spezielle Aufgabe benötigt und der Rest ungenutzter Ballast ist. Dies führt, gerade bei neuen Mitarbeitern, zu einem Mehraufwand in der Einarbeitung oder schreckt diese auf Grund der Komplexität direkt ab.

Beim Vergleich des Showcases aus dem ersten und zweiten Teil der Blogreihe wurden die einzelnen Schritte zum Ändern eines vorhandenen Geschäftspartners im SAP-System in der folgenden Abbildung dokumentiert. Dabei fällt auf, dass neben der bereits erwähnten Überladung mancher Transaktionen, drei verschiedene Modi erzeugt werden mussten, um die Anforderung umzusetzen.

Abbildung 5: Prozessschritte Eigentümerwechsel in der alten Welt

Wenn der Nutzer also in seiner Transaktion jedes Mal von vorn beginnen möchte, ist er gezwungen in mehreren Fenstern zu arbeiten und sich lange, nichtssagende Nummern zu merken oder in den Zwischenspeicher zu legen. Dies ist wenig intuitiv und bietet neben einer schlechten User Experience eine große Angriffsfläche für Fehler.

Fortfolgend wird der gleiche Prozess noch einmal betrachtet, jedoch dieses Mal unter Nutzung des SAP-Frontend-Frameworks SAPUI5.

Schöne neue Welt

Mit ihrer neuen Frontend-Technologie legt die SAP ihre eingestaubten Transaktionen für die Nutzer ab und verschlankt diese. So werden die ehemals funktional aufgeblähten Transaktionen in kleinere Anwendungen (UI5-Apps) aufgeteilt. Dabei übernehmen diese Anwendungen verschiedene Teilaufgaben eines ganzheitlichen Szenarios und ermöglichen dem Nutzer eine intuitive und effiziente Arbeit ohne unnötigen Ballast.

*Abbildung 6: Prozessschritte Eigentümerwechsel in der neuen Welt*

Der Nutzer im Vordergrund der Anwendungsentwicklung

Neben der Einführung in die Neuerung der Anwendungsentwicklung auf dem SAP-Stack gibt es noch einen weiteren Teil, den es zu beleuchten gibt. Die User-Experience-Strategie „SAP Fiori“.

Was ist Fiori?

Während SAPUI5 als Web-Framework Entwickler bei der Umsetzung moderner Enterprise-Anwendungen auf dem SAP-Stack unterstützt, legt Fiori die Design-Prinzipien fest.

Abbildung 7: SAP Fiori Design Guidelines – Bildquelle: Fiori Design Guidelines

Anhand der Fiori Design Guidelines erhalten Entwickler ein Nachschlagewerk für die visuelle Umsetzung der Anwendung, um die höchstmögliche, von der SAP vorgesehene Anzahl an Vorteilsmerkmalen für die Anwendung zu erreichen.

*Abbildung 8: Fiori Merkmale – Bildquelle: Fiori Design Guidelines*

Fazit

Mit der Kombination aus OData, SAPUI5 und Fiori geht die SAP einen neuen Weg und verabschiedet sich vom Grau ihrer monolithischen ERP-Lösungen. Durch die Eigenschaften von OData können Anwender nun (z.B. anhand von im Unternehmen verfügbarem Know-how) freier entscheiden, welche Frontend-Technologie sie einsetzen möchten. Gleichzeitig ermöglicht diese Komponententrennung und die Auslagerung von Funktionalitäten aus dem SAP-System eine besser wartbare und austauschbare Systemlandschaft.

Frontend-seitig rückt der eigentliche Anwender in den zentralen Blick der Anwendungsentwicklung. Musste sich ein Anwender vorher in überladene Transaktionen einarbeiten, werden diese Funktionalitäten jetzt in viele kleinere Anwendungen aufgeteilt und für eine bestmögliche Effizienz und Effektivität für den Nutzer entworfen.

Die Entwickler erhalten mit dem SAPUI5 Demo Kit, den Community-Foren und den Fiori Design Guidelines eine umfangreiche und ausführliche Dokumentation an die Hand, welche die Entwicklung moderner Webanwendungen auf dem SAP-Stack deutlich verbessert.

Der Nutzer im Mittelpunkt der Softwareentwicklung

Usability

Im Mittelpunkt dieses Blogbeitrags steht die Integration von User Centered Design (UCD) in unseren agilen Softwareentwicklungsprozess bei der Saxonia Systems AG (seit 03/2020 ZEISS Digital Innovation). Dabei wird vor allem auf die Artefakte und Methoden eingegangen, welche dafür sorgen, dass die Software auf den tatsächlichen Nutzer maßgeschneidert wird.

Die Wurzel schlechter Usability

Warum benutzt niemand die neue Software? Wenn diese Frage aufkommt, ist es meist schon viel zu spät. Die Entwicklung ist bereits abgeschlossen und die Nutzer bleiben aus bzw. halten an der alten Lösung fest. Dann ist es wahrscheinlich wieder einmal passiert, dass bei der Aufnahme der Anforderungen Annahmen getroffen wurden, welche an den tatsächlichen Bedürfnissen der Nutzer vorbei gehen. Dies ist ein in der Praxis leider häufig vorkommendes Phänomen, welches sich in schlechter Benutzbarkeit und niedriger Akzeptanz der finalen Software ausdrückt. Ein Lösungsansatz hierfür bietet das User Centered Design (UCD). Dieses stellt die Aufgaben, Eigenschaften und Ziele der zukünftigen Nutzergruppen in den Mittelpunkt des Softwareentwicklungsprozesses, um eine hohe Usability des Endproduktes zu gewährleisten.

User Centered Design

Durch unser agiles Vorgehensmodell sind wir in der Lage, schnell auf Änderungen und neue Anforderungen zu reagieren. Frühes Feedback von zukünftigen Nutzern ist essenziell für eine hohe Benutzbarkeit. Durch Artefakte und Methoden des Usability Engineerings wird unser an Scrum angelehntes Vorgehen so erweitert, dass der Nutzer von Anfang an regelmäßig eingebunden wird.

*Abbildung 1: UCD-Artefakte unseres agilen Vorgehensmodells*

Bereits zu Beginn des Projekts werden UCD-Elemente innerhalb der Product Vision verankert. Neben klassischen Bestandteilen, wie beispielsweise dem Projektziel oder der Systemgrenze, sind die Beschreibung der Nutzergruppen und des Nutzungskontexts sinnvolle UCD-Ergänzungen.

Im Product Backlog gibt es neben User Stories und technischen Spikes explizit Platz für Design Spikes, welche es dem Team erlauben, sich intensiv mit komplexen Usability-Themen zu befassen. Hierbei werden beispielsweise verschiedene Prototypen als Entscheidungsgrundlage entworfen oder Nutzerstudien konzipiert und durchgeführt.

In den beiden Scrum-Artefakten Definition of Ready und Definition of Done sind zusätzliche Qualitätsschranken integriert, um zu garantieren, dass die Software die zukünftigen Nutzungsanforderungen erfüllt. Durch vorgelagertes Prototyping ermitteln unsere Usability-Experten schon vor der Umsetzung, ob die Anforderungen zu den Bedürfnissen der Nutzer passen.

Bevor User Stories für ihre Umsetzung bereit sind, werden sie mit Skizzen, Mockups oder Designs (als Output aus dem Prototyp) erweitert. Diese verdeutlichen die zu implementierenden Funktionen für das Entwicklungsteam visuell. Sofern sie angewendet werden können, sind auch Prozessmodelle enthalten, um komplexe Abläufe zu veranschaulichen.

User Stories gelten aus UCD-Sicht als abgeschlossen, wenn die Usability-Prinzipien eingehalten wurden. Dies kann durch eine Experten-Evaluation überprüft werden. Dabei untersucht der Usability Engineer die neue Funktion heuristisch auf die Einhaltung von Richtlinien. Zusätzlich wird geprüft, ob der Styleguide eingehalten wurde und so die Konsistenz der Anwendung sichergestellt ist.

Zur Ablage von Usability-relevantem Hintergrundwissen empfiehlt sich ein zentraler Sammelort (Project Knowledge Base), z. B. in Form eines Team-Wikis.

Somit kann sich das Team jederzeit über das ermittelte Nutzerfeedback und den aktuellen Stand aus UCD-Sicht informieren. Empfehlenswerte Inhalte sind:

Informationsarchitektur
Domänenmodell
Systemdokumentation
Studien- und Testergebnisse, z. B. Nutzerstudien und CUI-Tracking
Personas

Wie in den obigen Abschnitten deutlich wird, beziehen wir den Nutzer an zahlreichen Stellen bei der Entwicklung von Individualsoftware ein. Unserer Erfahrung nach ist dies für eine hohe Nutzbarkeit und die Akzeptanz des Endprodukts essenziell. Durch das frühzeitige Einholen von Nutzerfeedback mit agilen und leichtgewichtigen Methoden können Sie die anfängliche Frage „Warum benutzt niemand die neue Software?“ aus ihrem Wortschatz streichen, denn der Nutzer ist der Schlüssel zum Erfolg.

Design-Prinzipien Reloaded: 13 wichtige Usability-Prinzipien

Usability

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.

Uhr mit unterschiedlichen Ausprägungen — *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:

ELSTER Online Web-Oberfläche — *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.

Weiterführende Literatur

J. Nielsen‘s 10 Usability Heuristiken (Web)
B. Shneiderman: 8 Golden Rules of Interface Design, In: „Designing the User Interface: Strategies for Effective Human-Computer Interaction“ (Web)
DIN-Norm EN ISO 9241-110: Grundsätze der Dialoggestaltung (Web)
B. Tognazzini, Principles of Interaction Design (Web)
J. Johnson, GUI Bloopers 2.0: Common User Interface Design Don‘ts and DOs, 2007
D. Norman, The Design of Everyday Things: Revised and Expanded Edition, 2013
Web Content Accessibility Guidelines 2.0 (Web)