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.

Arten von Anforderungen an ein System
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
Nachteile vieler umgesetzter Anforderungen
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.

Auslagerung der Anforderungen aus dem System
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.

Vorteile der Komponententrennung
Abbildung 4: Vorteile der Komponententrennung

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.

Prozessschritte Eigentümerwechsel in der alten Welt
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.

Prozessschritte Eigentümerwechsel in der neuen Welt
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.

SAP Fiori Design Guidelines
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.

Fiori Merkmale
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

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.

UCD-Artefakte unseres agilen Vorgehensmodells
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.

Personas – wenn der Nutzer nicht gerade nebenan sitzt…

Personas in a nutshell – Was sind Personas und wozu brauche ich diese?

Im Umfeld der agilen, verteilten Softwareentwicklung kommt es gerade im B2B-Kontext häufig zu dem Szenario, dass der Auftraggeber der einzige Ansprechpartner für den Entwicklungsdienstleister ist. Oft begründet sich dies durch die mangelnde Verfügbarkeit der Endnutzer, welche entweder örtlich vom Entwicklungsteam getrennt sind oder keine Zeit haben. Wenn der Nutzer nicht gerade nebenan sitzt, können Personas Abhilfe schaffen und den fehlenden Nutzerkontakt kompensieren.

Personas stellen prototypische Benutzer in Vertretung einer Benutzergruppe dar und verkörpern deren wichtige Eigenschaften und Bedürfnisse in Hinblick auf das geplante Produkt. Sie verdichten die Ergebnisse aus der Kontextanalyse, ersetzen jedoch die Nutzerforschung nicht. Die Ausgestaltung erfolgt in Poster-Form, möglichst „lebendig“ und realistisch, denn sonst ist die Persona nicht brauchbar. Generell entstehen Personas in frühen Projektphasen (Analyse und Planung) und werden dann über den gesamten Entwicklungszyklus hinweg als Soll-Ist-Vergleich verwendet. So wird es dem Design- und Entwicklungsteam ermöglicht, sich auf Nutzerbedürfnisse zu fokussieren. Bei Diskussionen dienen sie als Entscheidungsreferenz und stellen mit einer Frage wie „Würde Person x das verstehen?“ den Nutzer in den Vordergrund. Vor allem dem Product Owner helfen Personas bei der Bewertung von Ideen für neue Features.

Oft braucht es nicht nur eine Persona, sondern mehrere Personas, um die potentiellen Benutzer der Software abzudecken. Falls zu viele, eventuell auch im Widerspruch zueinander stehende Personas existieren, ist es hilfreich, diese in primäre und sekundäre Personas zu unterteilen. Das hilft, den Fokus auf die Zielnutzergruppe zu behalten und Entscheidungsalternativen zu gewichten.

Und welche Bestandteile werden nun für eine gute Persona benötigt?

  • Name: Ein realistischer Name, anhand dessen man die Persona identifizieren kann
  • Alter: Lässt Rückschlüsse auf die Einstellung der Persona zu
  • Bild: Ein Bild, egal ob fotografiert oder gezeichnet, damit die Persona realistischer wird
  • Persönliche Informationen: Alter, Geschlecht, fachliche Ausbildung, Wissen und Fähigkeiten, Familienstand, Kinder, …
  • Persona-Typ: Die zugehörige Nutzergruppe / der Archetyp (z. B. Teenager, Hausfrau, Rentner)
  • Beruf: Funktion, Verantwortlichkeiten und Aufgaben
  • Technische Expertise: Allgemeine Computerkenntnisse, Technikaffinität, Kenntnisse über verwandte Produkte, Vorgängersysteme oder Konkurrenzprodukte
  • Charakter: Die persönlichen Einstellungen und Werte der Persona – Ist sie z. B. aufgeschlossen gegenüber Neuem?
  • Verhaltensmuster und Vorgehensweisen: Werte, Ängste, Sehnsüchte und Vorlieben
  • Ziele: Die wesentlichen Aufgaben, welche mit der neuen Anwendung zu bearbeiten sind
  • Bedürfnisse & Erwartungen: Anforderungen an den Umgang mit dem Produkt
  • Frustration: Typische Ärgernisse an Produkten generell, was also unbedingt zu vermeiden ist

Persona Template

Das Usability Team der Saxonia Systems AG (seit 03/2020 ZEISS Digital Innovation) hat auf Basis der Best Practices und eigener Erfahrungen ein Template zur Erstellung einer Persona entwickelt. Das Template ist kostenlos als PDF erhältlich: DOWNLOAD

Template Personas
Template zur Erstellung einer Persona

Mit dem Persona Template haben Sie die Möglichkeit, Ihre Software noch besser an Ihre potentiellen Nutzer anzupassen und verlieren nie den Blick auf das Wichtigste … denn wir wissen ja alle: „The user is always right.“

Living Styleguides – die Zukunft im UI-Design?

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:

  1. Als Erstes wird eine Anforderungsanalyse durchgeführt.
  2. Auf Basis der Anforderungen erstellt der Designer Mockups.
  3. Die Mockups werden mit dem Kunden diskutiert (x-Iterationen) und final abgenommen.
  4. Danach erstellt der Designer die abgestimmten Grafiken im Design-Tool.
  5. Aus den Grafiken inkl. beschreibendem Text entsteht dann das Dokument „Styleguide“.
  6. Bei Anpassungen müssen alle Schritte wiederholt werden.
Grafik zum dokumentenbasierten Styleguide
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)
  • Standard-Interaktionselemente (wiederholt benutzte User-Interface-Elemente)
  • 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.

Folgend ein paar gute Referenzen:

Beispiel aus dem IBM Styleguide
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 :-)!

Usability in Softwareentwicklungsprojekten

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.