Verbesserung der Gesundheitsversorgung durch User Experience Design in der Entwicklung medizinischer Software

In medizinischen Einrichtungen, wie Arztpraxen oder Krankenhäusern, findet man eine Vielzahl verschiedener medizinischer Systeme und Softwarelösungen, jeweils mit eigenen Arbeitsabläufen, Funktionen, und Benutzeroberflächen (User Interfaces, UIs). Im komplexen Bereich der Gesundheitstechnologie, wo medizinische Software zunehmend anspruchsvoller wird, ist die Integration von User Experience (UX) Design von entscheidender Bedeutung, um sowohl Patienten und Patientinnen als auch medizinischem Fachpersonal einen echten Mehrwert zu bieten. 

Der nutzerzentrierte Ansatz gemäß ISO 9241 schafft Lösungen, die nicht nur technisch ausgereift sind, sondern Anwender:innen auch in der realen medizinischen Praxis bestmöglich unterstützen. Er gewährleistet sowohl pragmatische Qualitäten wie Sicherheit und Nutzbarkeit (Usability) für eine effiziente und effektive Zielerfüllung, als auch hedonische Aspekte wie Zufriedenheit der Nutzenden. Besonders im Bereich der Medizintechnik ist der Sicherheitsaspekt von entscheidender Bedeutung und wird in regulatorischen Standards wie IEC 62366-1 oder den Medical Device Regulations (MDR) der EU präzise definiert. 

Dieser Artikel widmet sich der facettenreichen Disziplin des UX-Designs im medizinischen Bereich. Wir untersuchen, welche Bedeutung UX-Design in der Entwicklung medizinischer Software hat und wie der prozessorientierte Ansatz des menschzentrierten Designs erfolgreich umgesetzt werden kann. Wir zeigen auf, wie durch dessen Anwendung Behandlungsergebnissen und Versorgungsstandards nachhaltig verbessert werden können. 

Bedeutung von UX-Design in der Entwicklung medizinischer Software 

Die Rolle von UX-Design in der Entwicklung medizinischer Software ist entscheidend für die Realisierung durchdachter und benutzerfreundlicher Lösungen. Diese Lösungen bieten zahlreiche Vorteile, von optimierten Arbeitsabläufen für medizinisches Fachpersonal über verbesserte Sicherheit und mehr Komfort für Patienten und Patientinnen bis hin zu Kosteneinsparungen und gesteigerten Verkaufszahlen. UX-Design umfasst wesentlich mehr als nur das pixelgenaue Design grafischer UIs und konzentriert sich auf die Entwicklung von Systemen, die speziell auf die einzigartigen Anforderungen und Kontexte im Gesundheitswesen abgestimmt sind. Es ermöglicht Unternehmen, sich in einem wettbewerbsintensiven Markt zu positionieren und von Mitbewerbern zu differenzieren. 

Im Folgenden erläutern wir fünf zentrale Gründe, warum UX-Design bei der Entwicklung medizinischer Softwarelösungen von besonderer Bedeutung ist: 

  1. Steigerung der Effizienz 
    Ein gutes Interaktionsdesign fördert den natürlichen Dialog zwischen Software und Anwender:in. Interaktionselemente werden schnell zugänglich und verständlich gestaltet, um eine effiziente Bedienung zu ermöglichen. Dadurch bleibt dem medizinischen Fachpersonal mehr Zeit für wertschöpfende Aufgaben. Anders ausgedrückt: wenn Nutzer:innen sich nicht mit komplexen Bedienoberflächen oder unverständlichen Prozessen abmühen müssen, können sie sich besser auf die Betreuung der zu behandelnden Personen konzentrieren, was die Versorgungsqualität verbessert. 
     
  1. Vermeidung und Verminderung von Fehlern  
    Im medizinischen Bereich können Fehler schwerwiegende, mitunter sogar tödliche Folgen haben. Medizintechnikunternehmen sind gesetzlich verpflichtet Risiken zu eliminieren oder zumindest zu minimieren, um sicherzustellen, dass ihre Systeme sicher bedient werden können. Indem UX-Designer:innen die Bedürfnisse und Denkmuster der Nutzenden verstehen, können sie Funktionen in der Software integrieren, die die Fehlertoleranz erhöhen und die Wahrscheinlichkeit von Fehlern während der Bedienung reduzieren. Konzepte, die Nutzende intuitiv führen und mit Sicherheitsmechanismen ausgestattet sind, sind in diesem Bereich, in dem kein Raum für Fehler besteht, von entscheidender Bedeutung. Die Norm IEC 62366-1 beschreibt einen detaillierten Usability-Engineering-Prozess, der sicherstellt, dass Risiken bei der Nutzung medizinischer Systeme minimiert werden. 
     
  1. Reduktion kognitiver Belastung 
    Eine reduzierte kognitive Belastung ermöglicht es den Anwendern und Anwenderinnen, natürlicher zu arbeiten. Wichtige Informationen werden leicht zugänglich gemacht und so präsentiert, dass sie mit klinischen Arbeitsabläufen harmonieren. Im hektischen medizinischen Umfeld, das von hohem Belastungsniveau und Arbeitstempo geprägt ist, stellt der menschzentrierte Ansatz eine entscheidende Strategie dar, um das Risiko der kognitiven Überlastung zu mindern. Dies trägt nicht nur zur generellen Sicherheit während der Interaktion bei, sondern fördert auch das Vertrauen der Nutzenden in die Systeme. 
Reduzierte kognitive Belastung trägt dazu bei, Fehler im hektischen medizinischen Umfeld zu vermeiden.
  1. Verminderung von Schulungsaufwand 
    Menschzentrierte medizinische Software verringert den Schulungsaufwand, den Nutzende benötigen, um sich mit der Software vertraut zu machen. Intuitives Design entspricht den Erwartungen und Vorkenntnissen der Anwender:innen, wodurch der Lernprozess beschleunigt und die Integration in die Praxis erleichtert wird. Dieser Aspekt ist insbesondere im Gesundheitswesen von höchster Bedeutung, wo Zeit eine besonders knappe und wertvolle Ressource ist. 
  1. Verbesserung der Konsistenz 
    Effektives UX-Design berücksichtigt nicht nur einzelne Produkte und Arbeitsabläufe, sondern die gesamte bestehende klinische Infrastruktur. Ziel ist es, Informationen einheitlich über alle Produkte und Arbeitsabläufe hinweg zu erfassen und darzustellen. Ein Designsystem wie „Beyond“ von ZEISS, kombiniert mit beispielsweise der ZUi Webkomponenten-Bibliothek, die einsatzbereite Softwarekomponenten bereitstellt, gewährleisten einheitliche Interaktionsmuster und ein konsistentes Erscheinungsbild. Dies reduziert den Aufwand für Design, Implementierung und Wartung für die Hersteller medizinischer Systeme und führt zu geringerem Schulungsaufwand sowie verbesserter Effizienz für die Anwender:innen. 

Integration von UX-Design in die Entwicklung medizinischer Software 

In der Entwicklung medizinischer Software ist die Disziplin des UX-Designs untrennbar mit dem prozessorientierten Ansatz des menschzentrierten Designs (User-Centered Design, UCD) verknüpft. Dieser Ansatz zielt darauf ab, durch die Einbindung der Endanwender:innen in den Entwicklungsprozess, eine nahtlose Interaktion zwischen Nutzenden und der medizinischen Software zu ermöglichen. Dabei stehen die Bedürfnisse und Einschränkungen der Menschen sowie der Nutzungskontext im Mittelpunkt des Designprozesses. Im komplexen medizinischen Bereich, wo das Spektrum der Nutzenden von Pflegekräften und Ärzten/Ärztinnen über Servicemitarbeitende bis hin zu Patienten/Patientinnen reicht, stellt dies eine besondere Herausforderung dar. Letztendlich sollte sich die medizinische Software an die Anwender:innen anpassen, nicht umgekehrt – die Anwender:innen, die sich an die Software anpassen müssen.  

Das iterative Prinzip des UCDs, in Verbindung mit einem agilen Softwareentwicklungsansatz, erfordert mehrere Zyklen zur Verfeinerung der Softwarelösungen. In Anlehnung an ISO 9241-210 umfasst der UCD Prozess vier Schlüsselphasen: 

Der User-Centered Design (UCD) Prozess adaptiert nach ISO 9241-210.

  • Verstehen und Festlegen des Nutzungskontexts 
    In dieser Phase werden die zukünftigen Nutzenden sowie deren Aufgaben, Aktivitäten und Ziele analysiert. So soll sichergestellt werden, dass die finale medizinische Software den Erwartungen und Bedürfnissen der Anwender:innen entspricht und sie bei der Zielerfüllung unterstützt. Außerdem sollte eine Kontextanalyse durchgeführt werden, um die spezifische Arbeitsumgebung und Arbeitsbedingungen im Gesundheitswesen zu verstehen. Ergebnisse können Personae (Benutzergruppenprofile), Aufgabenbeschreibungen, oder Szenarios sein. Informationen werden durch direkten Austausch mit den späteren Nutzenden, wie Patienten/Patientinnen, Ärzten/Ärztinnen und anderen Gesundheitsdienstleistenden, gesammelt. Typischerweise kommen Methoden wie Umfragen, Interviews und Beobachtungen zum Einsatz.
  • Spezifizieren der Nutzungsanforderungen 
    In dieser Prozessphase werden aus den Erkenntnissen der vorausgegangenen Phase konkrete Anforderungen und Designempfehlungen abgeleitet. Dabei werden sowohl funktionale als auch nicht-funktionale Anforderungen erfasst, die auf die besonderen Bedürfnisse medizinischer Einrichtungen zugeschnitten sind. Das Ziel besteht darin, die Kluft zwischen den abstrakten Erkenntnissen aus der Datensammlung und der praktischen Umsetzung zu überbrücken und sicherzustellen, dass die Bedürfnisse und Erwartungen der Nutzenden effektiv in spezifische und handlungsorientierte Anforderungen und schließlich in die medizinische Softwarelösung einfließen. 
  • Erarbeiten von Gestaltungslösungen, die die Nutzungsanforderungen erfüllen 
    In diesem Schritt des Prozesses werden die identifizierten Anforderungen in konkrete Interaktions- und UI-Konzepte überführt, die schließlich in der Software implementiert werden. Dies umfasst die Erstellung von User Flows, Wireframes, Prototypen und detaillierten UI-Designs, sowie die Zusammenarbeit mit dem Entwicklungsteam. Die Arbeit mit Prototypen, von einfachen Low-Fidelity-Darstellungen bis hin zu ausgefeilten High-Fidelity-Versionen, ermöglicht es UX-Designern und UX-Designerinnen, effizient durch verschiedene Lösungsansätze und Designvarianten zu iterieren.
  • Evaluieren der Gestaltungslösungen anhand der Anforderungen 
    In dieser Phase werden die Funktionalität und Leistungsfähigkeit der konzipierten Wireframes, Prototypen oder Softwarelösungen bewertet, um sicherzustellen, dass sie den definierten Nutzungsanforderungen entsprechen. Kontinuierliches Feedback ermöglicht eine umfassende Bewertung und stellt sicher, dass die Benutzerbedürfnisse und -erwartungen erfüllt werden. Die formative Evaluation umfasst Bewertungen von Experten und Expertinnen unter Verwendung verschiedener qualitativer und quantitativer Methoden, wie beispielsweise heuristische Evaluationen, kognitive Walkthroughs, und Usability-Tests in realen medizinischen Umgebungen. Summative Akzeptanztests schließen den Evaluierungsprozess ab. 
Wireframes und Prototypen ermöglichen es UX-Designern und UX-Designerinnen, verschiedene Lösungsvarianten und Designkonzepte kontinuierlich zu evaluieren. 

Schlussgedanken 

UX-Design spielt eine entscheidende Rolle bei der Entwicklung medizinischer Software und bringt den technologischen Fortschritt mit Grundwerten des Gesundheitswesens in Einklang. Es geht darum Software für echte Menschen in realen Situationen zu entwickeln, um nicht nur pragmatische Anforderungen zu erfüllen, sondern letztendlich positive Nutzererfahrungen zu schaffen. Dies kann die Behandlungsergebnisse erheblich verbessern und den Versorgungsstandard erhöhen.  

Die Integration von UX-Design in die medizinische Softwareentwicklung ist eine Investition in die Qualität der Gesundheitsversorgung. Da in Zukunft medizinische Software zunehmend in alle Bereiche des Gesundheitswesens integriert sein wird, wird das Engagement für UX-Design über den Erfolg oder Misserfolg von medizinischen Systemen entscheiden. 

Kontaktieren Sie uns, um mehr über unsere End-to-End-Cloud-Lösungsentwicklung und Qualitätssicherungsservices zu erfahren und mehr über ZEISS Digital Innovation Health & Life Science Solutions zu erfahren. 

Möglicherweise interessieren Sie sich auch für: 

➡️ Referenz ZUi Design System

➡️ Weitere Beiträge zum Thema Health Solutions auf unserem Blog

➡️ Whitepaper „Vom Hype zum Wert“ – Die Rolle digitaler Gesundheits-Apps und DTx im Krankenhaus der Zukunft

➡️ Whitepaper „Threat Modeling“

Dieser Beitrag wurde verfasst von:

Dominik Tim Schlackl

Dominik Tim Schlackl hat einen Masterabschluss in User Experience Design und arbeitet als Consultant User Experience Design für ZEISS Digital Innovation im Bereich Medizintechnik mit Fokus auf Ophthalmologie. Er konzentriert sich auf Usability Engineering, Interaktionsdesign und die Anwendung des nutzerzentrierten Designprozesses (UCD), um Mensch-Maschine-Schnittstellen zu konzipieren, die sowohl pragmatische als auch hedonische Anforderungen einer bestimmten Benutzergruppe erfüllen. Zu seinen Kernkompetenzen zählen Wireframing- und Prototyping-Prozesse, User Interface Design, qualitative Benutzer- und Kontextanalysen, sowie quantitative UX-Evaluationen.

Alle Beiträge des Autors anzeigen

UI-Dev-Session (Teil 2) – Erfahrungsbericht aus dem Projektalltag

Im ersten Beitrag dieser Blogartikelreihe wird eine leichtgewichtige Methode beschrieben, um Abweichungen zwischen dem vorgegebenen User Interface Design und der implementierten Anwendung zu beseitigen. Dabei arbeiten Entwicklerinnen und Entwickler sowie Spezialistinnen und Spezialisten für User Interface (UI) / User Experience (UX) mittels Pair Programming eng zusammen, um die Usability und das Erscheinungsbild einer Anwendung unkompliziert zu optimieren. 

In unserem Projekt führen wir regelmäßig solche „UI-Dev-Sessions“ durch. In diesem Blogbeitrag möchte ich von unseren Erfahrungen berichten – weg von der Theorie, hin zur Praxis. 

Wieso sind die UI-Dev-Sessions für uns wichtig? 

Im Rahmen des Projektes wird eine Standalone-Software entwickelt, welche Fachleuten der Augenheilkunde als Unterstützungstool zur Erhebung von Patientendaten sowie zur Analyse der Ergebnisse von operativen Laser-Sehkorrekturen dient. Auch im medizinischen Umfeld entwickelt sich User Experience immer mehr zu einem wichtigen Kaufkriterium. Neben Sicherheit, dem wohl wichtigsten Kriterium für Medizinprodukte, gewinnen weiche Kriterien wie “Joy of Use” und das Erscheinungsbild an Bedeutung. Die UI-Dev-Sessions sind für uns eine Möglichkeit, unserer Anwendung den Feinschliff zu verleihen. 

„The details are not the details. They make the design.” 

Charles Eames, Designer
Screenshot der Software, die Fachleuten der Augenheilkunde als Unterstützungstool zur Erhebung von Patientendaten sowie zur Analyse der Ergebnisse von operativen Laser-Sehkorrekturen dient
Abbildung 1: Screenshot der Software

Wie laufen die UI-Dev-Sessions bei uns ab? 

Unser Projektteam arbeitet agil und nutzt Scrum als Rahmenwerk für sein Vorgehen. Wie ein Großteil der Teams bei ZEISS Digital Innovation (ZDI) arbeiten die Teammitglieder verteilt, das heißt sie befinden sich nicht am selben Standort und damit auch nicht im selben Büro. Unser Projektteam ist über vier Standorte in zwei Ländern verteilt. Dabei sind die Rollen Scrum Master, Entwickler, Tester, Business Analyst und UI-/UX-Spezialist vertreten. 

An einer UI-Dev-Session nehmen bei uns meist jeweils Personen aus den Bereichen UI/UX sowie Entwicklung teil. Die Spezialistinnen und Spezialisten für UI/UX haben ihren Fokus auf zwei verschiedenen Aspekten, wodurch sie sich optimal ergänzen: einerseits auf dem visuellen Design des UI sowie andererseits auf dem Verhalten der UI-Komponenten. Die teilnehmenden Entwicklerinnen und Entwickler besitzen eine hohe Affinität für Frontend-Entwicklung. Eine von diesen Personen nimmt an jeder UI-Dev-Session teil und hat den Überblick über die zu erledigenden Punkte. Einige Tage vorher erinnern die Spezialistinnen und Spezialisten für UI/UX im Daily daran, dass eine UI-Dev-Session stattfinden wird und dass noch eine Person aus dem Entwicklungsteam als Unterstützung benötigt wird. Je nach Verfügbarkeit wird dann abgestimmt, wer unterstützen kann. Es gilt damit das Vier-Augen-Prinzip auf beiden Seiten (Design und Entwicklung) wodurch Fehler und umfangreiche Review-Runden vermieden werden können. 

Die Liste mit den zu lösenden UI-Fehlern wird im Projekt-Wiki von den Expertinnen und Experten für UI/UX gepflegt, strukturiert und priorisiert und ist jedem Teammitglied zugänglich. Dazu wird Confluence von Atlassian als Tool eingesetzt. Ein Ausschnitt der Themen ist in Abbildung 2 dargestellt. 

Beispiel für eine Liste mit zu lösenden UI-Fehlern
Abbildung 2: Ausschnitt aus der Liste der UI-Fehler

Da unsere Liste mit möglichen Themen aktuell recht umfangreich ist, sind regelmäßige Sessions notwendig. Eine UI-Dev-Session findet einmal pro Sprint – das heißt einmal alle drei Wochen – für zwei Stunden statt. Haben andere Themen im Sprint Priorität, kann der Termin auch kurzfristig verschoben werden, bestenfalls jedoch innerhalb des gleichen Sprints. Der Termin wird remote mit Hilfe von Microsoft Teams durchgeführt, da die Teilnehmenden über die Standorte Dresden, Leipzig und Miskolc verteilt sind. 

Ein bis zwei Tage vor der UI-Dev-Session suchen sich die Entwicklerinnen und Entwickler aus der Liste im Projekt-Wiki einige Punkte heraus und beginnen, diese vorzubereiten. Dazu zählt beispielsweise, die entsprechenden Stellen im Code mit To-dos zu markieren, um die Zeit in der UI-Dev-Session effizient für die eigentlichen Anpassungen zu nutzen. 

Zu Beginn der UI-Dev-Session gehen alle Teilnehmenden gemeinsam kurz die ausgewählten UI-Fehler durch, welche im Termin verbessert werden sollen. Anschließend werden die Themen von oben nach unten erledigt. Eine Person aus dem Bereich Entwicklung überträgt den Bildschirm und hat die Entwicklungsumgebung sowie den Styleguide in Figma geöffnet. Die weiteren Teilnehmenden haben ebenfalls den Styleguide geöffnet. Einer der Vorteile von Figma besteht darin, dass die Anwesenden sehen können, wo die anderen Beteiligten sich gerade im Styleguide befinden. So können die relevanten Stellen von allen schnell gefunden werden. Die Spezialistinnen und Spezialisten für UI/UX helfen den Entwicklerinnen und Entwicklern dabei, sich schneller im Styleguide zu orientieren und die relevanten Informationen zu finden. Wichtig dabei ist, dass sich die Personen aus dem Entwicklungsteam die relevanten Stellen selbst ansehen können und z. B. Farbwerte nicht einfach nur “vorgesagt” werden. So wird auch der Umgang mit dem Styleguide trainiert. 

Die ausgewählten Punkte werden nach und nach erledigt. Werden die ausgewählten UI-Fehler schneller behoben als vermutet, werden innerhalb des Termins neue Themen nachgezogen. Bleiben ausgewählte Themen offen, werden diese zu Beginn des nächsten Termins erledigt. 

Während der Vorbereitung oder in der UI-Dev-Session stellt sich hin und wieder heraus, dass Themen aufwändiger sind als zunächst angenommen. Die Entwicklerinnen und Entwickler teilen das den Spezialistinnen und Spezialisten für UI/UX mit. Diese verschieben das Thema dann aus dem Projekt-Wiki in ein eigenes Backlog Item in Jira, beispielsweise als Improvement oder neue User Story. 

In einem Anschlusstermin, der meist ein bis zwei Tage nach der UI-Dev-Session stattfindet und maximal 30 Minuten dauert, werden die Ergebnisse den Testerinnen und Testern vorgestellt. Das ist wichtig, um festzustellen, ob Testfälle von den Änderungen betroffen sind. Anschließend wird die Themenliste im Projekt-Wiki von den Spezialistinnen und Spezialisten für UI/UX aktualisiert. Die erledigten Punkte werden in Tabellenform dokumentiert, um das Nachvollziehen der durchgeführten Änderungen zu ermöglichen. 

Ausschnitt aus der Liste der behobenen UI-Fehler
Abbildung 3: Ausschnitt aus der Liste der behobenen UI-Fehler

Es muss nicht überall einen Haken geben 

In unserem Projekt hat sich der Einsatz der UI-Dev-Sessions bewährt, um das Erscheinungsbild der Anwendung schnell und unkompliziert zu optimieren. Für uns bringen die Sessions primär folgende Vorteile mit sich: 

  • Es werden UI-Fehler beseitigt, welche schon lange bekannt sind, denen aber gegenüber der Entwicklung neuer Features nur eine geringe Priorität beigemessen wurde. 
  • Die leichtgewichtige Methode mit geringem Dokumentationsaufwand lässt sich unkompliziert in unsere Sprints integrieren. 
  • Wir erreichen eine hohe Compliance mit dem ZEISS Styleguide für User Interfaces. 

Darüber hinaus stärken die Sessions die Kollaboration und die Wissensverteilung im Team: 

  • Durch die Zusammenarbeit zwischen den Bereichen Entwicklung und UI/UX können UI-Fehler effizient behoben werden, da die Entwicklerinnen und Entwickler sich auf die Implementierung konzentrieren können und die UI-/UX-Spezialistinnen und -Spezialisten die designspezifischen Vorgaben (z. B. Schriftfarbe, Abstand) direkt mündlich weitergeben können. 
  • Die Expertinnen und Experten für UI/UX lernen Implementierungsprobleme der Entwicklerinnen und Entwickler kennen, welche beispielsweise aus den eingesetzten Technologien resultieren. 
  • Mit den gesammelten Erfahrungen aus den UI-Dev-Sessions können die UI-/UX-Spezialistinnen und -Spezialisten zukünftige Designentscheidungen noch besser anhand des Entwicklungsaufwandes treffen. 
  • Das Entwicklungsteam lernt das Design-Tool Figma inklusive des Styleguides besser kennen. 
  • Das Team aus in UI/UX spezialisierten Personen hat die Gelegenheit, Designentscheidungen zu erklären und den Entwicklerinnen und Entwicklern einen Einblick zu geben, worauf es bei den Designs ankommt.
  • Das Entwicklungsteam arbeitet ein besseres Bewusstsein für Feinheiten im Design aus und kann so zukünftig UI Defects eher vermeiden. 

Die Liste der Vorteile, welche die Methode für uns mit sich bringt, ist somit lang. Doch wo ist der Haken? Für uns gibt es aktuell keinen und wir sind von der Methode überzeugt. Wir empfehlen sie daher jedem Team, bei welchem sich über die Zeit eine Vielzahl kleinerer UI-Fehler im Projekt angesammelt haben. Das Vorgehen ist flexibel und lässt sich je nach Bedarf des Teams adaptieren. Beispielsweise kann der Teilnehmerkreis minimiert oder das Zeitfenster erweitert werden. 

Ausblick 

Unser Ziel ist es, mit Hilfe der UI-Dev-Sessions die Liste der bestehenden UI-Fehler kontinuierlich zu verkleinern. Um die Anzahl neu hinzukommender UI-Fehler möglichst gering zu halten, wollen wir zukünftig die UI-Dev-Sessions schon während der Implementierung einer User Story in den Sprint integrieren. So können neue Abweichungen vom Design von vornherein vermieden werden.

UI-Dev-Session (Teil 1) – UI-Fehler im Team effizient lösen

Das zentrale Ziel eines jeden Styleguides ist es, ein einheitliches Erscheinungsbild und eine konsistente User Experience (UX) über mehrere Anwendungen hinweg zu gewährleisten. Für Anwendungen der ZEISS Gruppe gibt es aus diesem Grund detaillierte Vorgaben, wie ein User Interface (UI) auszusehen und sich zu verhalten hat. Jede Anwendung, die veröffentlicht und kommerziell genutzt werden soll, muss diese Vorgaben erfüllen. 

Abbildung 1 verdeutlicht die Komplexität und die vielfältigen Zustände, die sich selbst hinter sehr einfachen UI-Elementen verbergen. Die Aufwände für die korrekte Umsetzung solcher Zustände sind meist versteckt und werden bei der Anwendungsentwicklung gerne übersehen bzw. gegenüber der Implementierung von Funktionen niedriger priorisiert.

Grafik, die die verschiedenen Zustände eines Buttons im ZEISS Styleguide zeigt
Abbildung 1: Verschiedene Zustände eines Buttons im ZEISS Styleguide

Mit fortgeschrittener Projektlaufzeit sammeln sich kleine Abweichungen vom Styleguide, die das Gesamtbild schnell trügen. Weitere klassische Beispiele für solche UI-Fehler sind: 

  • Fehlende Zustände von UI-Elementen (Hover, Focused, …) 
  • Falsche Verwendung von Schriftgrößen, Schriftschnitten und Schriftfarben 
  • Falsche Verwendung von Graustufen für Flächen, Umrandungen oder Trennlinien 
  • Falsche Abstände und Positionierungen von UI-Elementen 

Zwar können solche Abweichungen meist schnell behoben werden, aber häufig sorgen umfangreiche Erstellungs- und Abnahmeprozesse für einen unverhältnismäßig großen Aufwand bei solchen vergleichsweise kleinen Anpassungen. Kommt es zusätzlich zu Missverständnissen oder Missinterpretationen der Designvorgaben und werden dabei mehrere Feedback-Schleifen benötigt, ist das für alle Beteiligten eine negative Erfahrung. 

Um solche kleinen UI-Fehler effektiver und effizienter zu beheben und das Produkt damit stückweise zu verbessern und dem Styleguide anzupassen, haben wir im Team eine unkomplizierte Form der Kollaboration geschaffen und etabliert.

Pair Programming mit Spezialistinnen und Spezialisten für UI/UX   

Das Pair Programming wird innerhalb des Entwicklungsteams unseres Projektes schon längst erfolgreich genutzt. Es fördert die Zusammenarbeit und die Qualität des Codes durch das Vier-Augen-Prinzip. Dabei arbeiten zwei Personen aus dem Entwicklungsteam gleichzeitig und direkt am Programmcode. Durch Diskussion, Kritik und das Einbringen neuer Ideen sollen hochwertiger Code erzeugt und Entwicklungszeit eingespart werden.  

Dieses Prinzip haben wir uns im Projekt zunutze gemacht und den Kreis der Teilnehmenden um Spezialistinnen und Spezialisten für UI/UX erweitert, um den Entwicklerinnen und Entwicklern direktes Feedback auf ihre Anpassungen am User Interface geben zu können. Die Anforderungen und Änderungswünsche an das User Interface werden durch die Expertinnen und Experten für UI/UX so direkt im Termin kommuniziert und die Änderungen geprüft, statt sie im Backlog zu dokumentieren und darauf zu warten, dass sie irgendwann korrekt umgesetzt werden. Zu den in UI/UX spezialisierten Personen gehören die Verantwortlichen für die Vorgaben an das User Interface, welche maßgeblich an der Entwicklung des Figma-UI-Designs beteiligt sind.  

Dem regelmäßigen Austausch in diesem Kreis haben wir den Namen UI-Dev-Session oder kurz einfach nur Dev-Session gegeben. Das Ganze funktioniert sehr gut auch dezentral im mobilen Arbeiten, denn dank Microsoft Teams und seiner Screen-Sharing-Funktion sehen alle teilnehmenden Personen gleichzeitig die Änderungen am Code und dem User Interface.  

Um einen Rahmen für das Pair Programming zu schaffen, haben wir dafür folgende „Spielregeln“ aufgestellt: 

  1. Es nehmen sowohl Personen aus dem Bereich Entwicklung als auch aus dem Bereich UI/UX teil. Insgesamt besteht die Gruppe aus zwei bis maximal vier Personen. Gemeinsam wird fokussiert nach der Lösung für konkrete UI-Fehler gesucht und live am Code programmiert. 
  1. Eine UI-Dev-Session hat von vornherein keinen vordefinierten Umfang. Vielmehr werden die erreichten Ziele durch die zur Verfügung stehende Zeit beschränkt. 
  1. Je nach Erfordernis des Projektes soll eine UI-Dev-Session in regelmäßigen Abständen stattfinden und einen klaren zeitlichen Rahmen umfassen. Zum Beispiel können 2-3 Stunden je Sprint, Woche oder Monat für eine UI-Dev-Session vorgehalten werden. Damit soll der zeitliche Aufwand zur Lösung von UI-Fehlern verhältnismäßig und gleichbleibend sein. 
  1. Mögliche Themen werden in einer Liste von den Spezialistinnen und Spezialisten für UI/UX gepflegt und iterativ in mehreren UI-Dev-Sessions abgearbeitet. Die Grundlage dafür sind z. B. Abweichungen zwischen Implementierung und Styleguide oder das Feedback aus Usability-Tests. 
  1. Das Entwicklungsteam kann Themen aus der Liste frei wählen und ggf. vorab aufbereiten. Dies soll dazu beitragen, dass möglichst viele Themen in kurzer Zeit gelöst werden. Sofern erforderlich, kann dennoch eine Priorisierung der Themen nach größtmöglichem Nutzen erfolgen, damit insbesondere bei engen Zeitrahmen die wichtigsten Themen zuerst gelöst werden. 
  1. Die Aktivitäten an unerwartet aufwändigen Themen, deren Live-Implementierung den zeitlichen Rahmen einer UI-Dev-Session sprengen, werden nach Einvernehmen der teilnehmenden Personen gestoppt und in anderweitige Backlog Items (z. B. User Stories oder Spikes) ausgelagert und später bearbeitet. 

Die bearbeiteten und gelösten UI-Fehler sollten im Nachgang der UI-Dev-Session dokumentiert und dem Projektteam zugänglich gemacht werden. So kann im Nachhinein jedes Projektmitglied nachvollziehen, was für Änderungen in welcher UI-Dev-Session vorgenommen wurden. Außerdem bietet es sich im Sprint-Review an, dem gesamten Projektteam die bearbeiteten Themen kurz vorzustellen.  

Beispiel für Abweichungen von der Implementierung (links) und für Styleguide-konformes Figma-Design (rechts)
Abbildung 2: Beispiel für Abweichungen von der Implementierung (links)
und für Styleguide-konformes Figma-Design (rechts)

Fazit

Ob klare Abweichungen vom Styleguide, Optimierungen nach Usability-Tests oder anderweitige kleinere Anpassungen am User Interface: Das in diesem Artikel beschriebene Vorgehen zur Durchführung einer gemeinsamen UI-Dev-Session mit Entwicklerinnen und Entwicklern sowie Spezialistinnen und Spezialisten für UI/UX fördert die Zusammenarbeit im Team und kann UI-Fehler schnell und effizient lösen. Der Dokumentationsaufwand soll damit auf ein Minimum reduziert werden und der zeitliche Aufwand für die Durchführung klar definiert sein. Durch iterative Durchführungen der UI-Dev-Sessions wird stückweise die Liste von UI-Fehlern abgearbeitet, wobei im Projektteam ein gegenseitiges Bewusstsein für solche Themen geschärft wird. 

Die UI-Dev-Session ist mittlerweile ein bewährtes Mittel in unserem Projekt und fester Bestandteil eines jeden Sprints. Einen ausführlichen Erfahrungsbericht aus unserem Projekt wird meine Kollegin Franziska Kubitz im zweiten Teil dieser Blogartikelreihe beschreiben. 

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 :-)!

Design-Prinzipien Reloaded: 13 wichtige Usability-Prinzipien

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)

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.