Autor: Jonas Zimmermann, Mixed Mode GmbH<\/p>\n
Der UCDP hilft mit einer systematischen Vorgehensweise dabei, sich ben\u00f6tigtes Wissen anzueignen, es auf die essentiellen Punkte zu komprimieren und daraus ein Produkt mit bestm\u00f6glichem Kundennutzen zu erzeugen. Im Mittelpunkt des User Centered Design Process (UCDP) stehen der Benutzer und die m\u00f6glichst enge Zusammenarbeit mit ihm. Die vier Phasen sind durch den UCDP vorgegeben, das Team ist jedoch frei in der Wahl der Mittel.<\/strong><\/p>\n „Eine Software mit tollen Funktionen n\u00fctzt mir nichts, wenn ich diese Funktionen nicht finde oder verwenden kann.“ Die Meisten werden dieser Aussage wohl sofort zustimmen \u2013 und trotzdem gibt es immer noch zu oft Software, bei der man schnell bemerkt, dass die Usability bei der Entwicklung nicht im Fokus stand.<\/p>\n Eine hohe Usability ist \u2013 laut Definition in ISO 9241-210 \u2013 erreicht, wenn ein bestimmter Benutzer ein Produkt in einem bestimmten Nutzungskontext so nutzen kann, dass seine festgelegten Ziele effektiv, effizient und zufriedenstellend erreicht werden. Effektivit\u00e4t ergibt sich hierbei aus der Genauigkeit sowie Vollst\u00e4ndigkeit, mit der dieser Benutzer bestimmte Ziele erreicht. Das Verh\u00e4ltnis der auf dem Weg eingesetzten Ressourcen (z.B. Aufwand, Kosten, Materialien) zu den erreichten Ergebnissen beschreibt die Effizienz. Wahrnehmungen und Reaktionen, die durch die Benutzung des Produktes entstehen, bestimmen den Grad der Zufriedenstellung des Benutzers.<\/p>\n Die Gr\u00fcnde f\u00fcr die Probleme der User mit einem bestimmten Produkt k\u00f6nnen vielf\u00e4ltig sein. Die Palette reicht hierbei von schwer zu findenden Funktionalit\u00e4ten \u00fcber solche, die nicht alle Aufgaben erf\u00fcllen k\u00f6nnen bis hin zu komplett fehlenden. Jedem ist klar, dass dies nicht die Absicht des Entwicklungsteams gewesen ist, sondern dass nach bestem Wissen und Gewissen gearbeitet wurde. In den meisten F\u00e4llen liegt die wirkliche Ursache in einem (unbewussten) Mangel an Wissen begr\u00fcndet. Was liegt also n\u00e4her, als sich sein Wissen direkt an der Quelle – also beim Benutzer – anzueignen?<\/p>\n Schon Ende der 80er Jahre hat sich Don Norman (zusammen mit Jakob Nielsen einer der Urv\u00e4ter auf den Gebieten Usability und User Experience) mit User Centered Design besch\u00e4ftigt. Bereits damals hat er darauf hingewiesen, dass man bei der Entwicklung von Produkten viel mehr auf den Benutzer und seine Bed\u00fcrfnisse eingehen muss. Im Laufe der Jahre ist aus den ersten Empfehlungen eine eigenst\u00e4ndige Vorgehensweise entstanden: der User Centered Design Process (UCDP). Er hilft mit einer systematischen Vorgehensweise dabei, sich das \u00a0ben\u00f6tigte Wissen \u00fcber Benutzer und Aufgaben anzueignen, es auf die essentiellen Punkte zu komprimieren und daraus ein Produkt mit bestm\u00f6glichem Kundennutzen zu erzeugen. (Siehe Abbildung 1 im\u00a0PDF<\/a>, Der User Centered Design Process mit seinen vier Phasen).<\/p>\n Der UCDP schafft den Spagat zwischen Flexibilit\u00e4t auf der einen und klarer Struktur auf der anderen Seite. Obwohl es vier deutlich voneinander abgegrenzte Phasen mit klaren Zielen gibt, hat das Entwicklungsteam eine gro\u00dfe Freiheit sowohl in der Wahl des Softwareentwicklungsprozesses als auch in der Auswahl der Methoden innerhalb der einzelnen Phasen.<\/p>\n Im Mittelpunkt steht der Benutzer. Obwohl in jeder der vier Phasen andere Aufgaben zu l\u00f6sen sind, orientiert sich das Team jederzeit an den Benutzern und ihrer ganz spezifischen Situation.<\/p>\n Wichtig beim User Centered Design Process: Iteratives Vorgehen, d.h. die vier Phasen werden in der Regel nicht nur einmal durchlaufen. Nach der Evaluation wird je nach Ergebnis eine der drei anderen Phasen bearbeitet \u2013 abh\u00e4ngig von den M\u00e4ngeln, die festgestellt worden sind. Dieser Ablauf wird so oft wiederholt, bis die Evaluation zu einem befriedigenden Ergebnis kommt.<\/p>\n In der ersten Phase besch\u00e4ftigt sich das Team mit den verschiedenen Benutzergruppen seines zuk\u00fcnftigen Produktes. Mit Hilfe verschiedener Techniken (z.B. Beobachtung, kontextuelle Interviews, Sch\u00fcler-Meister-Modell, \u2026) sammelt das Team Erkenntnisse \u00fcber den Nutzungskontext, um mindestens die folgenden Fragen beantworten zu k\u00f6nnen:<\/p>\n Die Antworten auf diese Fragen sollten sich am Ende dieser Phase in einer Nutzungskontextbeschreibung sowie Sammlungen von Szenarien und Persona finden lassen.<\/p>\n Man k\u00f6nnte in Versuchung geraten, diese Phase ohne direkte Interaktion mit Benutzern zu durchlaufen, allerdings w\u00fcrde das den Verzicht auf einen Gro\u00dfteil der zu entdeckenden Informationen bewirken. Doch Vorsicht: Benutzer werden schnell betriebsblind und formulieren Bed\u00fcrfnisse oft als konkrete Erweiterungen der bestehenden L\u00f6sung. Die viel wertvollere Erkenntnis ist das Problem, das der Benutzer mit seinem Vorschlag l\u00f6sen m\u00f6chte. Sobald sich das Entwicklungsteam aller Probleme und Aufgaben bewusst ist, kann es passende L\u00f6sungen und Abl\u00e4ufe entwickeln, die oft weit \u00fcber die ge\u00e4u\u00dferten W\u00fcnsche der Benutzer hinausgehen.<\/p>\n Zwei hervorragende Varianten, die sich simplifiziert mit „\u00fcber die Schulter gucken“ beschreiben lassen, sind die Beobachtung oder das Meister-Sch\u00fcler-Modell. In beiden F\u00e4llen sollte das Sammeln der Informationen am Arbeitsplatz des Benutzers stattfinden und von einem Teammitglied durchgef\u00fchrt werden. Bei der Beobachtung ist die Hauptaufgabe des Teammitglieds das Aufnehmen der Aufgaben und Abl\u00e4ufe. Die Kommunikation mit dem Benutzer sollte auf ein Minimum beschr\u00e4nkt sein, so dass nur in seltenen F\u00e4llen eine kl\u00e4rende Frage gestellt wird, wenn das Verhalten des Benutzers nicht verstanden wird. Der gro\u00dfe Vorteil liegt darin, dass der Benutzer tats\u00e4chlich unbeeinflusst seinem t\u00e4glichen Workflow folgt und der Beobachter so einen sehr realit\u00e4tsgetreuen Eindruck der Arbeit bekommt. Das Meister-Sch\u00fcler-Modell geht noch einen Schritt weiter: Das Teammitglied versucht hierbei, wie in einem Crash-Kurs das Handwerk des Benutzers zu erlernen.<\/p>\n Das Ziel der zweiten Phase ist es, die bisherigen Erkenntnisse in Nutzungsanforderungen niederzuschreiben. Eine systematische Vorgehensweise sieht vor, den Nutzungskontext zuerst auf Erfordernisse („User Needs“) zu untersuchen und sie in einem weiteren Schritt in Nutzungsanforderungen zu konvertieren. Ein Erfordernis entspricht hierbei einer Voraussetzung, um ein Ziel innerhalb eines bestimmten Nutzungskontexts zu erreichen und l\u00e4sst sich aus den Szenarien ableiten, die in der ersten Phase herausgearbeitet wurden.<\/p>\n Das immer wieder genannte Paradebeispiel ist der Vortragende, der jederzeit wissen muss, wie viel Zeit er noch hat, um seinen Vortrag im festgelegten Zeitrahmen zu beenden. Eine Anforderung, die sich aus diesem Erfordernis ableiten l\u00e4sst, ist die st\u00e4ndige Sichtbarkeit der verbleibenden Zeit in der Referentenansicht einer Pr\u00e4sentationssoftware.<\/p>\n In der „kreativen Phase“ geht es schlie\u00dflich um die Umsetzung der Anforderungen in einen Prototypen. Hierbei ist nicht festgelegt, wie gut er ausgearbeitet werden muss. Gerade zu Beginn ist es in den meisten F\u00e4llen ratsam, mit simpleren Versionen zu arbeiten: einfache Skizzen, Wireframes oder auch Designs aus Haftnotizen sind schnell erzeugt und reichen f\u00fcr grundlegende Diskussionen vollkommen aus.<\/p>\n Es geht hierbei nicht nur darum, das Aussehen der Oberfl\u00e4che zu definieren, sondern vor allem um Struktur und Verhalten der Software. Im ersten Schritt sollte man sich also Gedanken dar\u00fcber machen, mit welchen Interaktionen die Aufgaben gel\u00f6st werden sollen und wie sie zusammenh\u00e4ngen. Eine einfache Technik zur Strukturierung (z.B. f\u00fcr eine Men\u00fcstruktur) ist das Card Sorting. Hierbei bekommt ein Testkandidat einen Stapel Karten mit den vorhandenen Begriffen und soll diese in f\u00fcr ihn sinnvolle Gruppen bringen.<\/p>\n Der User Centered Design Process hat nat\u00fcrlich auch keine Wunderwaffe in der Hinterhand, die zwangsl\u00e4ufig hervorragend aussehende und bestens bedienbare Oberfl\u00e4chen produziert. Es gibt aber durchaus einige Grunds\u00e4tze, die man bei der Gestaltung immer im Hinterkopf haben sollte. Hierbei sind vor allem die Grunds\u00e4tze der Dialoggestaltung nach ISO 9241-110 (Aufgabenangemessenheit, Selbstbeschreibungsf\u00e4higkeit, Erwartungskonformit\u00e4t, Lernf\u00f6rderlichkeit, Steuerbarkeit, Fehlertoleranz, Individualisierbarkeit) und die Nielsen-Heuristiken [1] zu nennen. Vereinfachte Beispiele f\u00fcr Heuristiken sind etwa „Beachte Konventionen der verwendeten Plattform“, „Hilf den Usern dabei Fehler zu erkennen, sie zu verstehen und schlage eine L\u00f6sung f\u00fcr das Problem vor“ oder auch „Informiere den User durch angemessenes Feedback \u00fcber den aktuellen Zustand“.<\/p>\n Je nach Situation gibt es unterschiedliche Techniken, um die erstellten Designs zu evaluieren. Dank der gro\u00dfen Unterschiede hinsichtlich Zeit, Aufwand und Kosten sollte sich entsprechend der Gegebenheiten immer eine passende Variante finden lassen: die Bandbreite reicht von einer Heuristischen Inspektion \u00fcber Benutzerbefragungen bis hin zum Usability Test.<\/p>\n Bei der Heuristischen Inspektion (auch Heuristisches Review genannt) wird der Designvorschlag mit einer Liste von Heuristiken verglichen. Die Inspektion wird idealerweise von einem oder mehreren Usability-Experten durchgef\u00fchrt und dient somit haupts\u00e4chlich zur \u00dcberpr\u00fcfung hinsichtlich der Usability (und nicht so sehr der N\u00fctzlichkeit). Die Vorz\u00fcge dieser Technik liegen sowohl in der leichten Durchf\u00fchrbarkeit als auch dem vergleichsweise geringen Aufwand \u2013 aber eben auf Kosten der Vielfalt m\u00f6glicher Erkenntnisse.<\/p>\n Benutzerbefragungen mit Hilfe von Frageb\u00f6gen sind sowohl in der Vorbereitung als auch in der Interpretation mit deutlich mehr Aufwand verbunden, versprechen daf\u00fcr aber auch einen deutlich gr\u00f6\u00dferen Informationsgewinn. Hierzu tr\u00e4gt neben der gr\u00f6\u00dferen Reichweite auch die konkrete Kommunikation mit dem Benutzer bei. In dieser Hinsicht ist \u00fcbrigens zu beachten, dass der Fragebogen selber auch auf seine Usability hin optimiert sein sollte. Wenn die Benutzer Schwierigkeiten beim Ausf\u00fcllen des Fragebogens haben und Fragen bzw. Antworten falsch interpretieren, so kann es leicht zu fehlerhaften Schl\u00fcssen bei der Auswertung kommen.<\/p>\n Die K\u00f6nigsdisziplin der Evaluation ist wohl der Usability Test. Bei jeder Testsitzung versucht ein Testteilnehmer, vorher definierte Aufgaben mit dem System (oder einem Prototypen) zu l\u00f6sen, w\u00e4hrend er im Optimalfall „laut denkt“, also seine \u00dcberlegungen ausspricht. Ein Moderator f\u00fchrt den Teilnehmer durch die Testsitzung, ohne jedoch bei der Bearbeitung der Aufgaben zu helfen. Im Hintergrund k\u00f6nnen Beobachter und Protokollant direkt erkennen, welche Aufgaben intuitiv l\u00f6sbar sind und welche nicht. Um den Testteilnehmer nicht unn\u00f6tig abzulenken, sollte au\u00dfer dem Moderator keine andere Person sichtbar sein. Die M\u00f6glichkeiten zur „heimlichen“ Beobachtung sind auch hier vielf\u00e4ltig: z.B. ein Beobachtungsraum, der \u00fcber einen halbdurchl\u00e4ssigen Spiegel vom Testraum getrennt ist oder eine Webcam in Verbindung mit einer Kopie dessen, was auf dem Monitor des Teilnehmers passiert. Ein zus\u00e4tzlicher Eye-Tracker kann sogar Informationen liefern, die dem Teilnehmer selbst gar nicht bewusst sind \u2013 n\u00e4mlich die Elemente, die dem Teilnehmer zuerst ins Auge fallen.<\/p>\n Der User Centered Design Process\u00a0 mag auf den ersten Blick so wirken, als w\u00e4re er nur in einem agilen Umfeld verwendbar \u2013 tats\u00e4chlich kann man ihn aber auch in ein klassisches Wasserfallmodell einbetten. Ein Beispiel hierf\u00fcr kann man sich auf der Website des U.S. Department of Health & Human Services [2] ansehen.<\/p>\n Auch die Entwicklungskosten explodieren nicht automatisch durch die Konzentration auf den User. Zum einen lassen sich durch die Wahl der verwendeten Techniken die Kosten skalieren und zum anderen bekommt man einen konkreten Mehrwert in vielerlei Form \u2013 von ansonsten unentdeckten Bed\u00fcrfnissen der Benutzer \u00fcber Bedienungsprobleme bis hin zu einem deutlich besseren Produkt und somit einer besseren Position im Wettbewerb.<\/p>\n [1]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Jakob Nielsen, Ten Usability Heuristics [2] \u00a0\u00a0\u00a0\u00a0\u00a0 User-Centered Design Process Map Herr Zimmermann (B.Sc Informatik und Multimedia) bringt Erfahrung in der Softwareentwicklung f\u00fcr grafische Benutzeroberfl\u00e4chen seit 2009 mit. Seit Beginn seiner Laufbahn besch\u00e4ftigt er sich intensiv mit den Themen Requirements-Engineering und Usability von Software Systemen. Herr Zimmermann ist sowohl \u201cIREB Certified Professional for Requirements-Engineering\u201d als auch \u201cCertified Professional Usability and UX\u201d.<\/p>\n E-mail: jonas.zimmermann@mixed-mode.de Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Software Engineering Management \/Prozess-, Projekt- und Produktmanagement.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Software Engineering Management \/Prozess-, Projekt- und Produktmanagement steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nPhase 1: Verstehen des Nutzungskontextes<\/h2>\n
\n
Phase 2: Spezifikation der Nutzungsanforderungen<\/h2>\n
Phase 3: Erarbeiten von Gestaltungsl\u00f6sungen<\/h2>\n
Phase 4: Evaluieren von Gestaltungsl\u00f6sungen<\/h2>\n
Missverst\u00e4ndnisse: Nur agil und viel zu teuer?<\/h2>\n
Weiterf\u00fchrende Links<\/h3>\n
\nhttps:\/\/www.nngroup.com\/articles\/ten-usability-heuristics\/<\/a><\/p>\n
\nhttps:\/\/www.usability.gov\/how-to-and-tools\/resources\/ucd-map.html<\/a><\/p>\nAutor<\/h3>\n
Kontakt<\/h3>\n
\nMixed Mode GmbH, Lochhamer Schlag 17, 82166 Gr\u00e4felfing bei M\u00fcnchen<\/p>\n
\nSoftware Engineering Management – unsere Trainings & Coachings<\/h2>\n
\nSoftware Engineering Management – Fachwissen<\/h2>\n