Die ursprünglich aus der ISO 9000 hervorgegangene ISO 25000 beschreibt die Qualität innerhalb der Softwareentwicklung. Hierbei ist für Softwareentwicklerinnen und Softwareentwickler insbesondere die ISO 25010 von Interesse, welche typische Qualitätsmerkmale von Softwareprodukten abbildet. Innerhalb der ZEISS Digital Innovation ist dieser Standard von besonderem Interesse, da er sich nicht nur auf die Produkte unserer Kunden, sondern auch auf unsere internen Abläufe auswirkt. Gerade in Verbindung mit den regelmäßig durchgeführten Health Checks stellt der Standard eine wichtige Richtschnur dar, weil er definiert auf welche Eigenschaften von Software besonderes Augenmerk gelegt werden sollte. Nach über zehn Jahren ist es nun so weit, dass dieser so wichtige Standard überarbeitet wird. Dieser Artikel behandelt die zu erwartenden Änderungen.
Die ISO 25010
Der Standard ISO 25010 wurde im Jahr 2011 abgesegnet und ersetzte damit den bis zu diesem Zeitpunkt geltenden Standard 9126. Er definiert acht Haupteigenschaften von Software, die sich in weitere Untereigenschaften aufteilen.
Abbildung 1: Qualitätskriterien für Software – definiert in der ISO 25010
Eine weithin bekannte Eigenschaft ist zum Beispiel die Usability, zu Deutsch auch Benutzbarkeit. Mit ihr wird beschrieben, inwiefern die Software ihre Nutzer bei der Umsetzung von deren Arbeitsabläufen unterstützt. Wichtige Unterkategorien sind dabei zum einen, wie leicht die Software zu erlernen ist, zum anderen aber auch inwiefern sie die Nutzer vor Eingabefehlern schützt. Außerdem relevant ist der Umgang der Software mit möglichen Bedienungseinschränkungen, im Sinne von Seh- und Hörbeeinträchtigungen der Nutzer.
Abbildung 2: Untermerkmale für das Qualitätskriterium Usability
Dank der detaillierten Beschreibung des Standards ist es damit unterschiedlichen Projektbeteiligten wie Softwarearchitekten, Softwaretestern oder Produkt Ownern möglich, entsprechende Qualitätseigenschaften zu priorisieren sowie diese mit entsprechenden Anforderungsbeschreibungen zu versehen.
Änderungen am Standard?
ISO-Standards unterliegen einem Reviewprozess, durch den sie aller fünf Jahre auf ihre Aktualität geprüft werden. Für die ISO 25010 geschah dies in den Jahren 2016 und 2021. Bei der letzten Prüfung wurden verschiedene Änderungspotentiale offensichtlich. Beispielsweise findet sich bisher die Eigenschaft der Skalierbarkeit nicht im Standard, obwohl sie ausschlaggebend dafür ist, ob eine Applikation tatsächlich in der Cloud oder On-Premise umgesetzt werden sollte. Auch die Frage, ob die Software als Monolith oder in Form von Micro-Services umgesetzt werden sollte, ist maßgeblich von der notwendigen Skalierbarkeit abhängig.
Änderungswünsche wie diese konnten von den Standardisierungseinheiten bis zum 15. November 2022 vorgeschlagen werden, wodurch nun ein Vorschlag vorliegt, über den in den nächsten drei Monaten abgestimmt wird. Folgt die 2. Edition auch weiterhin dem üblichen Prozess, ist damit zu rechnen, dass die neue Edition etwa Mitte 2023 als bindend gilt und breitflächig veröffentlicht wird. Aber welche Änderungen sind konkret zu erwarten?
Mögliche ISO 25010 – 2. Edition
Bezogen auf die Usability ergeben sich einige Änderungen, so haben sich Astethics und Accessbility in User Engagement, User Assistance und Self-Descriptiveness gewandelt. Damit wurden die zuvor vorhandenen Beschreibungen im Grunde nur näher erläutert bzw. deutlicher getrennt.
Abbildung 3: Untermerkmale der Usability – 1. Edition
Abbildung 4: Untermerkmale der Usability – 2. Edition
Eine weitere Änderung ergibt sich für die Portabilität. Sie wandelt sich in Flexibilität, was ihrem eigentlichen Charakter auch viel näherkommt und sie deutlicher von der Kompatibilität unterscheidet. Unter der Flexibilität findet sich dann auch die schon länger vermisste Skalierbarkeit.
Abbildung 5: Aspekte der Portability – 1. Edition
Abbildung 6: Aspekte der Portability – 2. Edition
Die größte Änderung betrifft eine neue Eigenschaft, die bisher noch gar nicht betrachtet wurde. Hierbei handelt es sich um Safety. Mit Safety ist dabei die Betriebssicherheit gemeint. Ihre Einführung als wichtiges Qualitätsmerkmal spiegelt daher auch die deutliche Verbreitung von Software im Kontext der Hardware wider. Denn nicht zuletzt steuert Software in vielen Fällen auch Hardware und kann daher auch in der realen Welt zu Schäden an Mensch und Material führen.
Abbildung 7: Neues Qualitätsmerkmal – Safety
Fazit
Änderungen an Standards sind zu einem gewissen Teil auch immer etwas kritisch, da der Standard damit etwas weniger gut zu verstehen ist. So ist beispielsweise damit zu rechnen, dass in der Übergangszeit, durch die Namensgleichheit der verschiedenen Editionen, zunächst etwas Verwirrung entlang der verschiedenen Begriffe herrschen wird. Andererseits sind die Änderungen nachvollziehbar und sinnvoll. Inwiefern es überhaupt zu den Änderungen kommt, steht darüber hinaus auch noch nicht ganz fest, da die Abstimmung über jene Änderungen aktuell noch nicht abgeschlossen ist.
Die „Tester-Tea-Time“ ist ein Beitragsformat auf diesem Blog, in dem Themen aufgegriffen werden, die Testerinnen und Tester tagtäglich beschäftigen. Gewisse Problemstellungen oder Themen kehren immer wieder, daher soll hier eine Basis geschaffen werden, solche Phänomene zu erläutern und Lösungen dafür zu finden. Zudem sollen Diskussionen und neue Denkweisen angeregt werden. Im Testing können wir viel voneinander lernen, indem wir unseren Alltag beobachten!
Moderator: Willkommen zur Tester-Tea-Time! Im Interview mit Testerinnen und Testern der ZEISS Digital Innovation (ZDI) werden wir erneut spannende Themen diskutieren.
Widmen wir uns nun dem heutigen Thema. Dazu sprechen wir mit Sandra Wolf (SW), Testerin bei ZDI. Warum beschäftigen wir uns dieses Mal mit dem Thema „Rechtschreibung“ und wo siehst du den Zusammenhang mit der Softwareentwicklung?
SW: Der Alltag eines Testers hält viele Herausforderungen bereit. Gerade während des Testprozesses ist große Konzentration gefragt, wenn jedes Detail auf Qualität überprüft werden muss. Eines dieser Details ist die Rechtschreibung und Grammatik. Oft wird es unterschätzt, wie wichtig die korrekte Orthografie sein kann. Im Arbeitsalltag passiert es oft, dass Rechtschreibfehler in der Software gefunden werden. Doch wenn diese zur Behebung an die Entwicklung gemeldet werden, kommt es nicht selten vor, dass der Tester dafür belächelt wird. Die vorherrschende Meinung ist, dass das nur sehr kleine und unwichtige Fehler wären. Im heutigen Gespräch soll mit dieser Meinung aufgeräumt werden. Rechtschreibung und Zeichensetzung sind nicht gerade die beliebtesten Themen und werden häufig als sehr trocken empfunden. Dabei sind gerade diese Regeln, die wir seit der Schulzeit lernen, eine Orientierungshilfe für uns und unser Gehirn. Ein Wort, das richtig geschrieben wird, wird auch leichter gelesen, im Satz zu einer Aussage kombiniert und somit im Gehirn verarbeitet. Aufmerksame Leser – oder im Fall der Softwareentwicklung – Nutzer werden zwangsläufig über falsche Rechtschreibung in der Software stolpern. Es wurde sogar nachgewiesen, dass bestimmte Persönlichkeitstypen unterschiedlich emotional auf falsche Orthografie reagieren (vgl. Weiß, 2016). Somit können Fehler in diesem Bereich im Gegensatz zu ihrem trockenen Ruf Emotionen auslösen, die dann als Konsequenz den Umgang mit der Software beeinflussen.
Abbildung:Stanislaw Traktovenko und Sandra Wolf in der virtuellen Tester-Tea-Time im Gespräch.
Moderator: Von welcher Art der Beeinflussung sprechen wir in diesem Fall?
SW: Korrekte Rechtschreibung strahlt zum Beispiel Seriosität aus. In Bewerbungen und amtlichen Anträgen wird eine fehlerfreie Rechtschreibung vorausgesetzt. Es ist sogar in Studien belegt worden, dass beispielsweise die Chancen auf Bewilligung eines Kreditantrags durch sprachliche Fehler vermindert werden (vgl. Weiß, 2016). Übertragen wir das nun auf die Software, die wir entwickeln, ist nur ein möglicher Schluss zu ziehen: Rechtschreibung ist essenziell für eine adäquate Nutzung und die Außenwirkung der Software beim Kunden. Und somit sollte dieses Thema innerhalb des Entwicklungsprozesses eindeutig ernster genommen werden und mehr Aufmerksamkeit bekommen als bisher. Schauen wir uns den Alltag von Testern und Entwicklern an, dann wissen wir, dass die Funktionalität der Software im Mittelpunkt steht. Natürlich ist nachvollziehbar, dass ein kosmetisch wirkendes Thema wie die Rechtschreibung hinter aufwendig programmierten Anwendungsteilen zurücktritt. Das sollte alle Beteiligten des Prozesses allerdings nicht über die Wichtigkeit hinwegtäuschen. Denn ganz klar ist, dass der Erfolg eines Produktes und somit auch einer Anwendung von der sprachlichen Qualität beeinflusst werden kann. Der erste Eindruck beim Lesen eines Textes oder beim Nutzen einer Software lässt uns automatisch auch auf den Bildungsgrad der Schöpfer schließen (vgl. Frost, 2020). Somit kann durch eine fehlerhafte Rechtschreibung ein schlechtes Licht auf eine gute Software geworfen werden.
Moderator: Wie muss ich mir dieses “schlechte Licht”, in dem die Software dann steht, im Detail vorstellen?
SW: Durch eine schlechte Rechtschreibung kann das Vertrauen in die Qualität der Software verloren gehen und die Akzeptanz für die Anwendung sinken. Der Nutzer könnte davon ausgehen, dass generell wenig Wert auf Qualität gelegt wird, wenn schon mit der Rechtschreibung nachlässig umgegangen wird. Schließlich drückt eine korrekte Orthografie nicht nur Professionalität, sondern auch einen gewissen Respekt gegenüber dem Leser/Nutzer aus. Es konnte sogar festgestellt werden, dass eine Textqualität beeinflusst, ob jemand vom Interessenten zum Käufer wird. Wird das auf die Softwareentwicklung bezogen, kann es auf jeden Fall Budget einsparen, wenn von Anfang an auf die Rechtschreibung geachtet wird und die Meldung solcher Fehler ernst genommen wird (vgl. Frost, 2020). Letztendlich präsentieren wir in unseren Projekten auch unser Unternehmen, weshalb das Thema der Orthografie weitreichendere Auswirkungen haben kann, als wir zunächst denken. Im besten Fall kann durch eine gute Rechtschreibung der Ruf unserer Softwareentwicklung verbessert werden bzw. erhalten bleiben. Dadurch können wiederum mehr Kunden und höhere Umsätze erzielt werden, weil die gleichbleibende Qualität unserer Softwareprodukte ein Argument für eine Zusammenarbeit mit der ZDI sein kann.
Moderator: Hier möchte ich gern anknüpfen und Stanislaw Traktovenko (ST) aus unserem Usability-Team zu Wort kommen lassen. Welche Bedeutung nimmt das Thema der Rechtschreibung aus deiner Sicht ein? Siehst du ebenfalls die Auswirkungen in dem von Sandra Wolf beschriebenen Maße?
ST: Aus meiner Sicht hat die Rechtschreibung einen Einfluss auf die Lesbarkeit und dadurch auf die Wahrnehmung der Informationen in der Anwendung. Wir ordnen das den Usability-Prinzipien Konsistenz und Sprache zu. Rechtschreibfehler haben also potenziell eine direkte Auswirkung auf die Usability einer Anwendung. Eine inkorrekte Orthografie stört zum Beispiel den Lesefluss und somit die Wahrnehmung der Software durch den Nutzer. Es entsteht ein negatives Gefühl und der Nutzer beschäftigt sich nicht mehr mit der Aufgabe, die er mit der Software eigentlich verfolgt hatte. Er wird durch eine falsche Rechtschreibung abgelenkt und das beeinflusst seine Effektivität und Effizienz. Auch wenn Rechtschreibung nur ein kleiner Bruchteil der Usability ist, kann sie somit größere Auswirkungen haben als gedacht, so wie Sandra bereits vorher erläutert hat.
Moderator: Vielen Dank, Sandra und Stanislaw für diese interessanten Einblicke. Die Auswirkungen sind tatsächlich weitreichender als erwartet, das ist sehr erstaunlich. Wir können somit zusammenfassen, dass das trocken wirkende Thema der Rechtschreibung in allen Softwareprojekten ernst genommen werden muss, um eine möglichst hohe Qualität zu liefern und sowohl die Produkte als auch uns als Unternehmen adäquat zu präsentieren. Das Thema der Rechtschreibung wirkt im ersten Moment vielleicht banal, hat aber im Endeffekt eine große Wirkung und somit Wichtigkeit für uns alle. Das Thema sollte daher unbedingt die Aufmerksamkeit bekommen, die es verdient hat.
In den folgenden Beiträgen werden wir weitere Problemstellungen aus dem Alltag von Testerinnen und Testern aufgreifen und besprechen, welche möglichen Lösungsansätze es dafür gibt.
Im Mai 2020 hat Microsoft eine neue, vereinheitlichte UI-Plattform für alle Systeme unter dem klangvollen Namen MAUI bzw. in voller Länge „.NET Multi-Platform App UI“ vorgestellt, die voraussichtlich im November 2021 auf den Markt kommen wird. Doch was genau verbirgt sich hinter diesem Namen? Diese Frage soll in diesem Artikel beantwortet werden. Dabei sollen die Plattform vorgestellt, die technischen Hintergründe erläutert und vor allem auch das Potential der Technologie herausgestellt werden.
Um MAUI als Plattform zu verstehen, muss man zunächst Xamarin kennen. Xamarin (und im speziellen Xamarin.Forms) ist eine Plattform zur Entwicklung von nativen Apps für iOS, Android und UWP mit C#, XAML und .NET. Man kann dabei aus einer Code-Basis für alle unterstützten Betriebssysteme eine App erzeugen. Somit ist der Aufwand für die Entwicklung für verschiedene Betriebssysteme im Vergleich zur nativen Codierung der Anwendungen deutlich geringer. Aktuell sind tatsächlich die diversen SPA-Frameworks für den Browser die einzige Technologie, welche vergleichbare Portabilität bei ähnlichem Gesamtaufwand bieten.
Abbildung 1: Mit Xamarin.Forms kann man aus einer Code-Basis native Apps für alle unterstützten Betriebssysteme erzeugen. MAUI wird der direkte Nachfolger von Xamarin.Forms.
Aber was ist nun dieses geheimnisvolle MAUI und was hat es mit Xamarin zu tun? Diese Frage lässt sich recht simpel beantworten: MAUI ist das neue Xamarin oder, präziser ausgedrückt, dessen direkter Nachfolger, der erstmals mit .NET 6 ausgeliefert wird.
Genau wie mit Xamarin.Forms lassen sich mit MAUI aus einem Projekt und mit derselben Code-Basis Apps für alle unterstützten Betriebssysteme erstellen. Aus dem Code werden Installationspakete generiert, die dann auf den verschiedenen Plattformen installiert werden können. Offiziell werden von Microsoft Android ab Version 10, iOS, macOS und natürlich Windows, sowohl nativ als auch als UWP-App, unterstützt. Zudem soll es eine Community-Implementierung für Linux-Betriebssysteme sowie eine von Samsung zur Verfügung gestellte Implementierung für deren Tizen-Plattform geben. Das Projekt- und Build-System wird für alle Plattformen vereinheitlicht und das Erzeugen der Apps wird sowohl über Visual Studio als auch das .NET CLI möglich sein.
Ein weiteres Feature wird die geteilte Nutzung von Ressourcen wie Bildern oder Übersetzungen sein. Diese sollen von MAUI automatisch in die entsprechenden nativen Formate umgewandelt und in die erstellten Pakete integriert werden können. Außerdem wird man jederzeit auf die APIs des jeweiligen Betriebssystems zugreifen können. Hierzu soll es im Projekt einen speziellen Ordner geben, unter dem man die nativen Code-Hooks ablegt und die dann beim Kompilieren automatisch ins Paket integriert werden.
Alle im .NET-Standard verfügbaren Funktionalitäten wie zum Beispiel Dependency Injection sollen dabei auch für eine MAUI-App genutzt werden können. Durch die Verwendung von C# und XAML wird auch die Nutzung entsprechender Entwurfsmuster wie dem viel genutzten MVVM-Pattern möglich sein. Neu ist zudem der Support für das Model-View-Update-Pattern, ein von Elm entliehenes Muster, mit dem man einen unidirektionalen Datenfluss analog zu Redux abbilden können soll. Auch Microsofts webbasierte Client-Technologie Blazor soll unterstützt werden.
Leider wird MAUI erst mit der Einführung von .NET 6 im November 2021 offiziell zur Verfügung stehen. Zudem wurden Teile des Frameworks nach .NET 7 und damit ins Jahr 2022 verschoben. Hier sind vor allem der offizielle Support für Blazor und das MVU-Pattern zu nennen. Da MAUI der offizielle Nachfolger von Xamarin ist, wird dieses auch mit dem Release von .NET 6 noch für ein Jahr unterstützt und dann eingestellt.
Damit scheint Microsofts Strategie für die Zukunft der UI-Entwicklung mit dem .Net-Framework klar zu sein: MAUI ist der neue „First Class Citizen“, wenn es um die Erstellung von nativen User Interfaces geht.
Das klingt zunächst alles danach, dass Microsoft eine native Cross Platform-Unterstützung ins .NET-Framework integrieren möchte. Dieser Plan wird jedoch nur aufgehen, wenn MAUI von den Entwicklerinnen und Entwicklern akzeptiert wird. Durch das sehr späte Release und einer Menge hervorragender Open Source-Alternativen wie Uno könnte sich MAUI am Ende eventuell nicht etablieren. Aktuell kann man deshalb nur abwarten und sehen, was die Zukunft bringt. Die Migration von bestehenden WPF-Anwendungen gestaltet sich beispielsweise schwierig, da der ersehnte XAML-Standard, der eine Vereinheitlichung der Elemente und Tags für alle XAML-Dialekte definieren sollte, scheinbar wieder verworfen wurde und sich MAUI und WPF wegen unterschiedlicher Elemente nicht übergangslos austauschen lassen werden.
Wenn die Technologie aber tatsächlich hält, was sie verspricht, die Entwicklerinnen und Entwickler sie breitflächig einsetzen und MAUI so hochklassig wird, wie Microsoft es in Aussicht stellt, könnte hier eine Cross Platform-Revolution unter .NET in den Startlöchern stehen.
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.
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
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 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
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 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.“
Wie so ziemlich alle Artefakte in der Softwareentwicklung befindet sich auch der Styleguide in einem stetigen Wandel. Dennoch werden heutzutage häufig noch klassische Varianten eingesetzt, obwohl sich mit dem technischen Fortschritt längst neue Möglichkeiten eröffnet haben, um klassische Dokumente zum Leben zu erwecken. Dieser Blogbeitrag greift diese Thematik auf und soll am Beispiel Styleguide zeigen, wie durch dessen Weiterentwicklung die Zusammenarbeit zwischen Designer und Entwickler verbessert werden kann: Sind Living Styleguides die Zukunft im UI-Design?
Es war einmal … der dokumentenbasierte Styleguide
Lange Zeit herrschte ein Artefakt über die Zusammenarbeit zwischen UX-Designer und Frontend-Entwickler: der dokumentenbasierte Styleguide. Dieser entsteht klassischerweise wie folgt:
Als Erstes wird eine Anforderungsanalyse durchgeführt.
Auf Basis der Anforderungen erstellt der Designer Mockups.
Die Mockups werden mit dem Kunden diskutiert (x-Iterationen) und final abgenommen.
Danach erstellt der Designer die abgestimmten Grafiken im Design-Tool.
Aus den Grafiken inkl. beschreibendem Text entsteht dann das Dokument „Styleguide“.
Bei Anpassungen müssen alle Schritte wiederholt werden.
Abbildung 1: Der dokumentenbasierte Styleguide
Als Kommunikationsgrundlage sollte ein guter Styleguide folgende Punkte beinhalten:
Konzept (Anwendung aus Projektsicht, Produktvision, UX-Ziele)
Struktur (Aufbau der Anwendung)
Interaktionsdesign (Gestaltung des Dialogs zwischen Nutzer und System)
Farbgestaltung (Verwendungsregeln für Farben)
Typografie (Schriftarten und -größen)
Icons und Grafiken (Übersicht aller Icons und Grafiken der Anwendung)
Spezialansichten (nicht dem Standard entsprechende UI-Ansichten und Steuerelemente)
Sprache (Kommunikationsstil und Wortwahl)
Multimedia (Einsatz von Bildern, Audio und Video)
Doch vor allem die Auflistung der Standard-Interaktionselemente ist in einem starren, dokumentenbasierten Styleguide nicht optimal. Diese kann bei der Menge verschiedener UI-States wie hover, active, selected, … pro Element schnell etliche Seiten lang werden. Die wenigsten Entwickler wühlen sich gerne durch seitenlange Dokumente und so besteht die Gefahr, dass der Styleguide nicht beachtet wird.
Die klassische Variante des Styleguides beinhaltet weiterhin folgende zwei Probleme: Die starre Sicht auf ein meist sehr langes Dokument erfordert viel Vorstellungsvermögen und es besteht keine Interaktionsmöglichkeit mit den verschiedenen Elementen.
Status Quo & Zukunft im UI-Design … es wird lebendig
Um die oben beschriebenen Kritikpunkte zu verbessern, bieten sich mehrere Ansätze an. Beispielsweise können mit Hilfe eines parallel gepflegten UI-Prototypen die Inhalte des Styleguide zum Leben erweckt werden. So wird ermöglicht, verschiedenen States der Standard-Interaktionselemente im Anwendungskontext auszuprobieren oder aber auch Spezialansichten im Detail abzubilden. Mit dieser „Hands-on“-Mentalität wird schneller klar, was die Designanforderungen sind und das lange Blättern in Styleguide-Dokumenten fällt weg.
Dieser Lösungsansatz beseitigt jedoch noch nicht folgende Probleme: Oft ist es im Projektalltag der Fall, dass der Designer Vorlagen entwirft, welche zu außergewöhnlich sind und mit dem eingesetzten UI-Framework nicht ohne erheblichen Mehraufwand umsetzbar sind. Ein weiteres Problem besteht im eingeschränkten Funktionsumfang des Prototyping-Tools. Denn nicht immer ist es möglich, das Endverhalten eins zu eins nachzubilden, wodurch falsche Annahmen entstehen können.
Der aktuelle Trend geht daher in die Richtung, den kompletten Styleguide „lebendig“ als eigene Webanwendung umzusetzen. Die Elemente werden also vor ihrer Verwendung in der eigentlichen Anwendung implementiert und die Entwickler müssen sich nur noch den Quellcode kopieren.
Abbildung 2: Beispiel aus dem IBM Styleguide (www.ibm.com)
Die Vorteile einer solchen Umsetzung liegen auf der Hand: Neben einer guten Strukturierung der benötigten Informationen und Elemente wird vor allem die Wartbarkeit erheblich verbessert. Denn falls eine Farbe geändert werden muss, ist dies im „Living Styleguide“ meist nur eine Farbcode-Änderung im Stylesheet, während im traditionellen, dokumentenbasierten Styleguide unzählige Abschnitte und Designs angepasst werden müssen. Darüber hinaus kann die QA-Abteilung schon vor der eigentlichen Entwicklung das angeforderte Verhalten testen. Es besteht sogar die Möglichkeit, Änderungen am Styleguide direkt in die Anwendung fließen zu lassen, wenn beide Anwendungen auf das gleiche Stylesheet referenzieren. Dadurch können Redundanzen und Inkonsistenzen von vornherein ausgeschlossen werden. Wie sehr der Styleguide in den Entwicklungsprozess integriert wird, ist sicherlich projektabhängig, jedoch sind den Möglichkeiten der Optimierung hierbei keine Grenzen gesetzt.
Der „Living Styleguide“ ist mittlerweile in aller Munde und wird von zahlreichen Top IT-Unternehmen wie beispielsweise Google oder IBM verwendet. Er lässt die Lücke zwischen Design und Entwicklung immer kleiner werden und am Ende lacht vor allem einer: der Nutzer :-)!
Vor längerer Zeit habe ich in einem Blogartikel unsere Design Prinzipien vorgestellt, nach welchen wir bei der Saxonia Systems (seit 03/2020 ZEISS Digital Innovation) nutzerfreundliche Software konzipieren und entwickeln. Im Rahmen der Entstehung unseres Custom Usability Index, mit dem der Erreichungsgrad der Usability eines Softwareprojekts gemessen werden kann, haben wir im Usability-Team diese Prinzipien noch einmal genau unter die Lupe genommen und auf 13 Oberkategorien erweitert, welche jeweils mehrere Usability-Aspekte umfassen. In diesem Artikel werden diese Kategorien und Aspekte genauer erläutert und durch Beispiele veranschaulicht.
Effektivität: Das Ziel erreichen. (Prinzip 1)
Die erste und somit wichtigste Regel ist die Einhaltung von Effektivität. Eine Anwendung soll dem Nutzer eine effektive Arbeitsweise ermöglichen, indem eine geeignete Funktionalität zur Erledigung seiner Aufgabe zur Verfügung gestellt wird. Der Nutzer wird nicht mit Informationen und Funktionen belastet, die für seinen Anwendungsfall unnötig sind. Entsprechend sollten Dialoge nur relevante oder häufiger benötigte Informationen enthalten. Jede zusätzliche Information lenkt den Nutzer von den wichtigen Inhalten ab, und es besteht die Gefahr einer Reduktion der relativen Sichtbarkeit.
Es gilt daher die zentrale Frage zu beantworten: Was ist wirklich die Aufgabe, die unterstützt werden soll? Eine gründliche Analyse der Arbeitsabläufe und deren Verständnis ist der Schlüssel, um die Aufgaben und Ziele der Nutzer zu verstehen und die Effektivität ihrer Umsetzung beurteilen zu können.
Abbildung 1: Wie viel Information ist notwendig, um die Uhrzeit anzuzeigen?
Effizienz: Schnell zum Ziel kommen. (Prinzip 2)
Ebenfalls besondere Beachtung verdient die Optimierung von Effizienz. Dem Nutzer soll es ermöglicht werden, eine Aufgabe in minimaler Zeit zu erledigen. Zugleich benötigt die Anwendung nur minimale Zeit zur Reaktion und zur Ausführung einer Aktion. Dieses Prinzip bezieht sich also auf die Arbeitsgeschwindigkeit von Nutzer und System. Anhaltspunkte dafür, dass der Nutzer nicht effizient arbeiten kann, sind beispielsweise für ihren Zweck unpassend eingesetzte Interface-Widgets, fehlende Default-Werte, unzutreffende Suchergebnisse und hochauflösende Bilder, welche eine schnelle Internetverbindung voraussetzen.
Hinweise auf eine geringe System-Effizienz sind hingegen verzögerte Reaktionen auf Eingaben in Form von „ruckelnden“ Mauszeigern, langsamen Interface-Widgets und fehlendem Feedback.
Steuerbarkeit: Der Nutzer hat die Macht! (Prinzip 3)
Der Nutzer hat, unter Beachtung seiner Berechtigungen im System, die Kontrolle über alle Aktionen. Er kann Vorgänge abbrechen, pausieren und zu einem späteren Zeitpunkt fortsetzen. Er hat die Möglichkeit, eine Aktion rückgängig zu machen und ggf. einen neuen Anlauf zu starten, falls das Ergebnis nicht zufriedenstellend war. Für die Steuerung der Anwendung hat der Nutzer weiterhin die Möglichkeit, entsprechend seinen persönlichen Anforderungen zur Maus alternative Eingabegeräte wie Tastatur, Screenreader und Braillezeile zu nutzen. Werden diese Punkte nicht eingehalten, führt das zu einer gesteigerten Frustration des Nutzers.
Individualisierbarkeit: Alles passt zum Nutzer. (Prinzip 4)
Die Anwendung soll flexibel genug sein, um verschiedene Herangehensweisen zur Erledigung einer Aufgabe zu unterstützen. Der Nutzer kann das System zudem an seine Vorerfahrungen, Kultur und Bedürfnisse anpassen, z.B. durch Änderung der Schriftgröße, Änderung von Default-Einstellungen und die Festlegung eigener Shortcuts. Ein gutes Beispiel für die Berücksichtigung von Individualisierbarkeit ist das Online-Portal http://www.elster.de/, über das man Steuererklärungen webbasiert erfassen und abgeben kann. Nach dem Login wird der Nutzer gefragt, welcher Benutzergruppe er angehört, um die Anwendung anschließend auf dessen Bedürfnisse anzupassen:
Abbildung 2: Individualisierbarkeit bei ELSTER Online
Konsistenz: Alles passt zusammen. (Prinzip 5)
Die Bedienung der Anwendung soll in jedem Aspekt den Erwartungen des Nutzers entsprechen und allgemeine Konventionen (Plattformen, Styleguides etc.) befolgen. Einen Beitrag dazu leistet die einheitliche Verwendung von Begriffen, Icons und Layouts innerhalb der Anwendung und zwischen Produkt-Familien. Auch Prozessstrukturen folgen einem einheitlichen Prinzip. Durch die Einhaltung von Konsistenz kann vom Nutzer ein einmal erlerntes Verhaltensmuster wiederverwendet werden. Zum Beispiel weiß (und erwartet) der Nutzer im Verlauf der Benutzung der Anwendung(en), dass sich der Button zum Schließen eines Dialogfensters immer oben rechts in der Ecke befindet. Wechselt er jedoch auf das Betriebssystem Mac OS X, muss er sich gänzlich neu eingewöhnen. Anhaltspunkte dafür, dass sich eine Anwendung nicht erwartungskonform und konsistent verhält, sind überraschte bis verwirrte Nutzer und z.B. die Verwendung verschiedener Begriffe für ein und dieselbe Funktion.
Design und Layout: Auf den ersten Blick verständlich. (Prinzip 6)
Dieses Prinzip umfasst alle Aspekte der visuellen Gestaltung einer Anwendung. Demnach sollen die Art der Gruppierung und Anordnung der GUI-Elemente sowie der bewusste Einsatz von Farbe den Nutzer bei der Erkennung von Zusammenhängen unterstützen. Informationen und Komponenten werden dem Nutzer generell so präsentiert, dass er sie wahrnehmen und Textinhalte gut lesen kann. Gegenanzeigen hierfür sind z.B. unklare Zuordnungen von Labels zu Datenfeldern, winzige Schriftarten und ein schwacher Farbkontrast zwischen Vorder- und Hintergrund.
Sprache: Die Sprache des Nutzers sprechen. (Prinzip 7)
Die Anwendung sollte grundsätzlich die Sprache des Nutzers widerspiegeln und dessen Denkweise entsprechen. Textelemente sollten daher eindeutig formuliert sein und einen für die Zielgruppe verständlichen Wortschatz gebrauchen. Dennoch werden Dinge oft systemtechnisch formuliert statt in der Sprache der Anwender. „Bestes“ Beispiel dafür sind Fehlermeldungen mit einem Detailgrad, in dem sie zwar für den Systementwickler von Wert sind, dem Nutzer aber nicht weiterhelfen. Um dies zu vermeiden, sollte der fachliche Sprachschatz der Endnutzer genau analysiert werden.
Sichtbarkeit: Der Nutzer erkennt seine Möglichkeiten. (Prinzip 8)
Damit der Nutzer seine Aufgabe erledigen kann und nicht die Orientierung verliert, muss er jederzeit wissen, wo in der Anwendung er sich befindet und welche Aktionen wie ausgeführt werden können. Auch weiß er jederzeit, in welchem Status sich das System gerade befindet. Das Hauptmenü sollte dem Nutzer daher dessen aktuelle Position anzeigen und bspw. über eine Breadcrumb-Navigation den Weg dorthin nachvollziehbar machen. Relevante Objekte, Funktionen und Optionen sollten sichtbar sein und den Nutzer das Gesuchte direkt finden lassen. Er soll beurteilen können, welche Folgen eine Aktion haben wird.
Feedback: Der Nutzer erfährt, was los ist. (Prinzip 9)
Das System sollte jederzeit auf Eingaben des Nutzers reagieren und ihn aktiv über Ereignisse informieren. Bei einem aufgetretenen Fehler sollte eine entsprechende Meldung dem Nutzer die Ursache des Fehlers aufzeigen und ihm, sofern möglich, einen Lösungsvorschlag unterbreiten. Weist die Anwendung in Sachen Feedback Defizite vor, ist dies beispielsweise bei einer komplexeren Operation an einem fehlenden Spinner-Icon ersichtlich und Nutzer-Eingaben werden gefühlt vom System ignoriert. Der Nutzer nimmt wahr, dass die Anwendung „hängt“.
Lernförderlichkeit: Leicht zu lernen. (Prinzip 10)
Das System sollte den Nutzer beim Kennenlernen der Benutzungsoberfläche unterstützen und ihn zum Ausprobieren von ihm unbekannten Funktionen ermutigen, ohne dass dies negative Auswirkungen für den Nutzer mit sich bringt. Vor allem in der ersten Phase der Benutzung sollte der Nutzer bei komplizierten Aktionen unterstützt und so mögliche Fehlschritte eingeschränkt werden. Hier helfen kurze Tutorials und beschreibende Texte. Eine Möglichkeit zum experimentellen Lernen bietet weiterhin ein Probemodus, d.h. ein gesonderter Testbereich in der Anwendung, in dem alle Funktionen ohne Konsequenzen ausprobiert werden können. Durch den Probemodus wird der Nutzer am System geschult und lernt den Umgang mit dem System, ohne einen Prozess vollständig durchführen zu müssen.
Hilfe und Dokumentation: Hilfe, die hilft. (Prinzip 11)
Hilfesysteme sollen leicht auffindbar bzw. möglichst in die Interaktion eingebettet sein. Zu eingebetteten Hilfen zählen Tooltipps, Platzhalter, kurze Hilfetexte und Assistenten. Ist dies nicht hinreichend, sollte die Wahl auf kontextuelle Hilfen wie einem Hilfe-Panel, Einstiegsseiten und Suchfunktion fallen. Zu beachten ist, dass die Hilfesysteme dem Nutzer nur dann eine Unterstützung sind, wenn sie sich auf die Aufgabe des Nutzers beziehen und konkret auszuführende Schritte zur Lösung des Problems auflisten.
Fehlertoleranz: Nutzerfehler verzeihen und vermeiden. (Prinzip 12)
Das System sollte von vornherein so gestaltet sein, dass der Nutzer aktiv vor Fehlern bewahrt wird, beispielsweise indem unzulässige Funktionen deaktiviert werden und die Einschränkung zusätzlich begründet wird. Passiert es doch einmal, sollten fehlerhafte Eingaben oder Aktionen vom System erkannt werden. Im Falle von Eindeutigkeit behebt das System den Fehler dann, wenn möglich, selbstständig. Gibt es mehrere Möglichkeiten, werden alternative Korrekturvorschläge aufgezeigt. Niemals hingegen darf der Fehler zum Datenverlust oder gar Systemabsturz führen.
Nutzungsgefühl (UX): Die Software fühlt sich gut an. (Prinzip 13)
Ein Aspekt, den wir bisher nicht berücksichtigt haben, ist die User Experience (abgekürzt UX). Das sogenannte Nutzungsgefühl resultiert aus dem Gesamterlebnis des Nutzers mit der Anwendung und setzt sich zusammen aus der tatsächlichen Nutzung, der Erwartung des Nutzers und der Vorerfahrung mit anderen Systemen. Die Anwendung vermittelt dem Nutzer ein Gefühl von Sicherheit und Zuverlässigkeit, macht Spaß und ist zweckdienlich. Das System begeistert den Nutzer, indem bestimmte Erwartungen nicht nur befriedigt, sondern auch übertroffen werden. Prinzip 13 wird also zum Großteil dadurch erfüllt, dass die zuvor genannten Prinzipien eingehalten werden. Eine langsame, inkonsistente Anwendung mit vielen Fehlermeldungen und Abstürzen wird hingegen nicht zur Zufriedenheit des Nutzers beitragen. Entsprechend sollte sich die Software immer auf dem aktuellen Stand der Technik befinden und aktuelle Steuerparadigmen unterstützen.
Abschluss
In diesem Blogbeitrag wurden 13 wichtige Prinzipien zur Erreichung einer nutzerfreundlichen, zufriedenstellenden Software vorgestellt. Zu beachten ist dabei, dass es keine einzig wahre, benutzungsfreundliche Lösung gibt. Wie gut eine Anwendung bedienbar ist, hängt immer von dem konkreten Anwendungsfall und der Nutzergruppe ab. Es ist daher zu empfehlen, die Bedürfnisse der Nutzer genau zu analysieren und sie durch Nutzertests einzubeziehen.
Dass nicht nur in Sachsen was geht, sondern vor allem auch an unserem Hauptsitz in München, zeigten Ende letzten Jahres die „International JavaScript Conference“ und die „W-JAX“. Beide Konferenzen fanden kurz nacheinander statt und lockten zahlreiche Besucher in die bayrische Landeshauptstadt.
Wie schon die S&S Media Group als Veranstalter der iJS (international JavaScript Conference) feststellt, ist „JavaScript [mittlerweile] überall: kaum ein digitales Business kann heute auf JavaScript und high-level Frameworks, wie Angular, React, oder NodeJS verzichten.“ Da wundert es kaum, dass diesem Thema auf der iJS vom 23.-27.10.2017 im Holiday Inn Munich City Centre eine eigene Konferenz mit zahlreichen Keynotes, Sessions und Power Workshops gewidmet wird. Auch die W-JAX beschäftigt sich zum Teil mit diesen Themenfeldern, bietet aber zusätzlich noch zahlreiche weitere Impulse im Bereich Enterprise-Technologie, Softwarearchitektur, Agilität & Java.
Abbildung 1: iJS & W-Jax
Wir nutzten bei beiden Konferenzen die Gelegenheit, uns intensiv mit der Community auszutauschen und hatten deswegen einige Fragen im Gepäck, die wir an die Teilnehmer der Konferenzen richteten. Insgesamt konnten wir fast 100 Umfragen durchführen, die sich in gleichen Teilen auf die beiden Veranstaltungen aufteilten. Wir danken an dieser Stelle noch einmal allen, die sich die Zeit genommen haben, sich an unserer Befragung zu beteiligen. Nur durch einen intensiven Austausch mit Partnern, Kunden und Community kann es gelingen, sich stets zu verbessern. Diesen Ansatz der kontinuierlichen Verbesserung, der auch im agilen Manifest verankert ist, verfolgen wir nicht nur in unseren Projekten, sondern leben wir auch unternehmensweit.
Während unsere Experten Manuel Mauky und Alexander Casall zu Themen wie „Angular-Anwendungen mit Redux“ und „Offlinefähige Desktopanwendungen mit Angular und Electron“ sprachen, wollten wir von unseren Interviewpartnern zuallererst wissen, welche Frameworks und Sprachen sie in ihren aktuellen Hauptprojekten einsetzen. Am häufigsten wurden Angular und JQuery genutzt, dicht gefolgt von JavaEE und Spring. React kam dagegen beispielsweise noch recht selten zum Einsatz. Dabei nutzten 72 von 88 Befragten JavaScript, 69 HTML und 51 Java als Programmiersprache. Ruby, Groovy und Coffeescript dagegen wurden kaum verwendet und bekamen jeweils maximal 5 Stimmen.
Abbildung 2: Welche Frameworks verwenden Sie in Ihrem aktuellen Hauptprojekt?
Natürlich interessierte uns nicht nur, mit welchen Technologien momentan gearbeitet wird, sondern vor allem in welche Richtung sich die Trends der Softwareentwicklung bewegen. Immer mehr Anwender von Geschäftsanwendungen erwarten moderne Webanwendungen anstelle bestehender Desktop-Software. Die Usability von Bestandssoftware trifft in Zeiten von modernen B2C-Applikationen oft nicht mehr die Erwartungshaltung der Nutzer und es werden immer mehr webbasierte Lösungen etabliert, die ihre Nutzer aktiv in der Arbeit unterstützen. Daher ist es auch nicht verwunderlich, dass 70 % der Befragten planen, in nächster Zeit mit Angular, React oder einer anderen reactiven Technologie (z.B. ReactiveX, RxJS, …) zu arbeiten. Vue.JS (14 Stimmen) und JavaFX (3 Stimmen) spielen dagegen bei den Umfrageteilnehmern nur untergeordnete Rollen.
Abbildung 3: Planen Sie in nächster Zeit mit einer der folgenden Technologien zu arbeiten?
Die Hälfte der Befragten konnte sich schon recht genau positionieren und hatte sich auf Angular, React oder zumindest eine reactive Technologie festgelegt. Rund 20 % dagegen waren noch indifferent und konnten sich noch nicht zwischen Angular oder einer reactiven Technologie entscheiden. Hilfestellung könnte hier die von uns evaluierte Entscheidungsmatrix bieten, die mithilfe eines Fragenkatalogs eine persönliche Technologieempfehlung gibt. Diese basiert auf den Erfahrungen unserer Webexperten.
Weiterhin entscheidend bei der Auswahl einer geeigneten Programmiersprache oder eines Frameworks ist selbstverständlich auch der Inhalt des eigentlichen Projektes. Wir fragten daher, was die Umfrageteilnehmer in ihrem Hauptprojekt tun. Der Großteil der Befragten beschäftigte sich hier mit Softwareevolutionsprojekten (61 Stimmen), dicht gefolgt von Neuentwicklungen (56 Stimmen). Rund ein Fünftel der Umfrageteilnehmer beschäftigte sich in ihrem Arbeitsalltag mit DevOps. Je nachdem, ob man eine bestehende Software wartet oder ein „grüne Wiese“-Projekt auf dem Tisch hat, sind die Spielräume bei der Auswahl der Programmiersprachen und verwendeten Tools natürlich sehr unterschiedlich breit.
Abbildung 4: Was tun Sie in Ihrem Projekt?
Nachdem wir nun etwas näher herausgefunden hatten, womit die Befragten, bei denen es sich zum Großteil um Softwareentwickler verschiedenster Nationalitäten und aus unterschiedlichsten Branchen und Unternehmensgrößen handelte, wollten wir auch wissen, was sie im aktuellen Projekt am meisten behindert. An dieser Stelle gaben wir bewusst eher offene Antwortmöglichkeiten, wie „schlechter Code“ oder „schlechte Architektur“ vor, die dem Interviewteilnehmer noch Spielraum für Interpretation gaben und somit die Befragten bewusst dazu auffordern sollten, näher auf die Probleme einzugehen und gegebenenfalls einen ersten Dialog zu Problemlösung zu fördern.
Die häufigsten genannten Probleme sind der folgenden Grafik zu entnehmen. Neben den hier auftauchenden Antworten, bei denen sich „unklare Anforderungen“ nach wie vor als eines der Hauptprobleme darstellte, gab es auch einige freie Antworten. Relativ häufig wurde hier „legacy code“, „Warten auf den Auftraggeber / den Kunden“ oder „stark gewachsene und unübersichtliche Softwarearchitektur“ genannt.
Abbildung 5: Was behindert Sie in Ihrem Hauptprojekt am meisten?
Schlussendlich wandten wir uns noch einigen Fragestellungen aus dem Bereich „Moderne Webentwicklung“ zu, um hier zu prüfen, welche Trends sich tatsächlich von der Community bestätigen lassen oder welche Themen zwar im Netz „gehypt“ werden, aber im tatsächlichen Entwickleralltag noch nicht angekommen sind. Einer dieser Trends in der IT ist beispielsweise GraphQL. Hier stellten wir erst einmal die grundsätzliche Frage, wie die Konferenzbesucher zu der Technologie standen. Lediglich ein Viertel der Befragten plante den Einsatz dieser REST-Alternative für die Zukunft oder hatte GraphQL bereits im Einsatz, während immerhin fast die Hälfte noch nie von der Technologie gehört hatten.
Abbildung 6: Wie stehen Sie zur Technologie „GraphQL“?
Wir wollten hier außerdem noch wissen, ob die Befragten in ihren Projekten Cloud-Technologien einsetzen. Hier war das Verhältnis der Antworten relativ ausgeglichen. 45 % der Umfrageteilnehmer bejahten hier, während die restlichen 55 % nicht, oder zumindest nicht in ihrem Hauptprojekt, mit Cloud-Technologien arbeiteten. Die zweite Frage aus diesem Themenblock war, welche Technologie die Befragten aktuell für das State-Management verwendeten. Zur Auswahl standen React/Angular (ohne Dritt-Framework für das State-Management), Redux oder MobX. Während letzteres lediglich eine Stimme bekam, setzte der Großteil der Umfrageteilnehmer (knapp 50 %) kein Drittframework ein und rund 25 % arbeiteten mit Redux, während wiederum ca. 20 % hier keine Antwort gaben, was das Ergebnis der Umfrage leider etwas verfälscht.
Sie interessieren sich für weitere Umfrageergebnisse? Dann stöbern Sie doch einfach noch ein wenig in unserem Blog, und lesen Sie, welche aktuelle Trends und Herausforderungen in der Softwareentwicklung wir auf der solutions.hamburg 2016, der OOP 2017, der WJAX 2016 oder der DWX 2017 erfragen konnten.
In einem früheren Blogbeitrag habe ich den Custom Usability Index vorgestellt. Mit dem Index hat man die Möglichkeit, die Usability in Softwareentwicklungsprojekten zu tracken. In diesem Blogbeitrag möchte ich tiefer ins Detail gehen und erklären, welche Schritte notwendig sind, um den CUI zu verwenden.
Die oben abgebildete Grafik zeigt die Verwendung des CUI im Projektverlauf und soll als Grundlage für die weitere Betrachtung dienen.
Zielzustand der Kategorien – Wünsch dir was!
Spätestens zum Projektstart sollten die gewünschten Zielzustände der CUI-Kategorien feststehen, d.h. die verantwortlichen Stakeholder müssen eine Aussage darüber treffen, was in ihren Augen der Optimalzustand ist. Dieser kann von Projekt zu Projekt unterschiedlich sein wie folgendes Beispiel zeigen soll. Nehmen wir uns die Kategorie Individualisierbarkeit. Diese sagt aus, dass das System flexibel genug ist, um verschiedene Herangehensweisen zur Erledigung einer Aufgabe zu unterstützen. Der Nutzer soll das System an seine Vorerfahrungen, Kultur und Bedürfnisse anpassen können. Die Beschreibung könnte dann wie folgt aussehen:
Projekt 1: Der Optimalzustand der Kategorie Individualisierbarkeit wäre, dass der Nutzer vom ersten Start der Anwendung an verschiedene Erfahrungslevel einstellen kann und sich das System automatisch danach anpasst.
Projekt 2: Der Optimalzustand der Kategorie Individualisierbarkeit wäre, dass der Nutzer einen Expertenmodus aktivieren kann, welcher weitere Einstellungsmöglichkeiten im System aktiviert.
Die unterschiedlichen Optimalzustände haben zur Folge, dass im obigen Beispiel in Projekt 2 leichter die Maximalbewertung vergeben werden kann als in Projekt 1. Bei den Beschreibungen der Zielzustände ist es von Vorteil die tatsächlichen Nutzer, beispielsweise den Fachbereich eines Unternehmens, für welchen die neue Anwendung erstellt werden soll, einzubeziehen. Dadurch wird gewährleistet, dass die Usability-Anforderungen nicht an den Haaren herbeigezogen sind und die tatsächliche Anwendung perfekt auf den Endnutzer abgestimmt wird. Ein allgemeiner Merksatz hierbei: Je konkreter die Formulierung des Wunschzustandes, desto besser die späterer Messergebnisse!
CUI-Priorisierung – Aber es ist doch alles wichtig?!
Wenn der Zielzustand für alle CUI-Kategorien feststeht kann es in der Praxis häufig zu dem Problem kommen, dass ein großer Wunschkatalog aufgebaut wurde und die verantwortlichen Auftraggeber Angst vor großen Kosten haben oder eventuell andere betriebswirtschaftliche Ziele mit der Systementwicklung verfolgen. Um dies zu berücksichtigen ist im nächsten Schritt eine Priorisierung der CUI-Kategorien notwendig. Dazu sollen folgende Fragen unterstützen:
Die in der obigen Tabelle dargestellten Fragen sollen dem Usability-Experten als Leitfaden für das Interview mit dem Kundenverantwortlichen dienen. Die Antworten des Kunden müssen dabei in Zahlen übersetzt werden. Für die CUI-Priorität wird die Fibonacci-Reihe verwendet (1, 2, 3, 5, 8, 13, …, soweit nötig). Je höher die Zahl, desto wichtiger ist die Kategorie für das Projekt.
Falls sich der Auftraggeber schwer tut eine direkte Aussage über die Wichtigkeit der Kategorien zu treffen bietet sich auch die aus dem agilen Umfeld kommende Magic Estimation Schätzungsmethode an. Hierbei werden die einzelnen Kategorien kurz vorgestellt und dann nach Wichtigkeit sortiert. Durch das Vergleichen fällt es oft leichter eine Priorisierung festzulegen.
<Vorbereitung> CUI </Vorbereitung> – Darf ich jetzt endlich loslegen?
Ja! Es ist nun einerseits die inhaltliche (Zielzustände der Kategorien) sowie die geschäftliche Voraussetzung (CUI-Priorisierung) geschaffen, um die ersten Usability-Tests durchzuführen. Alle beteiligten Stakeholder wurden automatisch für das Usability-Thema sensibilisiert und (hoffentlich) begeistert.
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.
