Der User Centered Design Prozess in 4 eingängigen Schritten

Zusammenfassung

Der User Centered Design Prozess besteht im Wesentlichen aus 4 Schritten, die iterativ wiederholt werden bis euer Produkt oder eure Dienstleistung für den Kunden und dessen Nutzungserlebnis optimal ist. Dabei ist ein User Centered Design Prozess nicht ein Privileg der Softwareentwicklung. Er kann für alle möglichen Formen von Produkten und Dienstleistungen genutzt werden. Dies gilt auch für interne Anwendungen für eure Kollegen und Mitarbeiter.

User Centered Design – Eine Übersicht

 

Der User Centered Design Prozess ist im Vergleich zu SCRUM ein älteres agiles Framework, das wie alle anderen agilen Frameworks vor allem von der Iteration lebt. Nur wer genügend ‚Schleifen‘ in seiner Planung berücksichtigt, hat die Möglichkeit eine optimale UX für seine Nutzer zu schaffen. Der UCD – Prozess ist in der ISO Norm 9241 – 210 niedergeschrieben und dokumentiert.

Grundsätze

Die Gestaltung des UCD – Prozesses basiert vor allem auf dem Verständnis der folgenden 3 Aspekte:

• Dem Benutzer und dessen Bedürfnisse
• Den Arbeitsaufgaben (Ziele der Nutzer)
• Der Arbeitsumgebung (Nutzungskontext)

Das A und O des Prozesses ist die dauerhafte Einbeziehung des Nutzers während der kompletten Entwicklung und Gestaltung. Der User ist der zentrale Teil des User Centered Design (=UCD) Prozesses. Vor allem neue Web Projekte und Startups halten sich bereits an die Phasen des UCD. Die Qualität des Internets steigt.  Stell dir mal vor, du würdest das Web heute noch so bedienen müssen, wie früher MS-DOS und über müsstest via Konsolenbefehle interagieren. Das kann man sich heute gar nicht mehr vorstellen. Im Web spielt die Benutzerfreundlichkeit eine immer wichtigere Rolle.

Ein weiterer Grundstein des UCD – Prozesses ist die benutzerzentrierte Evaluation. Getestet wird nicht mehr nur der Code und die Technik, sondern vor allem auch die Benutzerfreundlichkeit bzw. Usability. Es geht zum einen darum, wie kommt mein User mit dem Angebot zurecht, zum anderen interessieren wir uns für seine Empfindungen, Emotionen und Erwartungen, um das gesamte Nutzungserlebnis zu erfassen. Über die Tragweite von UX und den Unterschied zu Usability, könnt ihr weitere Informationen hier nachlesen.

Diese Evaluation findet konstant und immer wieder statt. Als Beispiel: Jedes Mal, wenn es eine neue Version eures Produkts oder eurer Dienstleistung gibt. Ein Beispiel aus der Softwareentwicklung wäre: Version 1.0 wurde getestet, es wurden Fehler in der Bedienung und somit der Usability festgestellt, daraufhin wird eine Version 2.0 erstellt. Auch diese muss anschließend wieder getestet werden, denn es gibt keine Garantie, dass die neue Lösung, das Problem für den Nutzer wirklich beseitigt.

Vorteile der Iteration im UCD – Prozess

Die Iteration ist im User Centered Design Prozess zwingend notwendig. Keiner, wirklich niemand kann wissen, was genau der Nutzer denkt oder wie dieser sich verhalten wird. Jeder, der dieses Wissen für sich beansprucht, liegt automatisch falsch. Selbst die besten UX Engineers, Interaction Designer, Usability Konzepter, sowie UI Designer können aufgrund ihrer Erfahrung und ihres Wissens rein hypothetische Vorhersagen treffen. Sie sind damit oft besser in ihrer Prognose und machen weniger Fehler. Doch auch hier wird die erste Version nicht fehlerfrei sein. Für dieses Problem gibt es die benutzerzentrierte Evaluation wie zum Beispiel den Usability Test. Ihr lernt somit stetig hinzu, ob eure Lösungen für den User wirklich verständlich sind.

Ein weiterer Vorteil besteht vor allem im Vermeiden von möglichen Fehlentwicklungen. Wenn ihr eure Nutzer schon sehr früh in der Entwicklung mit einbezieht, dann wisst ihr wie ihr den Grundstein setzen müsst. Das böse (teure) Erwachen zu einem späteren Zeitpunkt bleibt somit aus.

Kostenreduktion

Iterationen klingen für viele Projektleiter, Controller und andere Manager erst einmal teuer. Monetär und kurzfristig gedacht, sind sie das auch. Problematisch ist, dass wir gerade in Deutschland oft mit dem Gedanken erzogen werden, dass wir keine Fehler machen dürfen.

In unserem beruflichen Alltag diskutieren wir Themen gerne so lange, bis wir keinen einzigen Fehler mehr erkennen können. Das wiederum ist nicht nur nervtötend, sondern vom Prinzip her auch teurer. Nur weil Fehler wegdiskutiert werden, verschwinden diese dadurch nicht. Irgendwann tritt er wieder zutage. Meistens ist der Zeitpunkt dann deutlich später. Umso grundlegender der Fehler, desto teurer ist die Korrektur. Man kann das mit dem Bau eines Hauses vergleichen. Wenn im Fundament zu Beginn Fehler gemacht worden sind, muss bei einer Korrektur jeder Stein, der über dem Fundament liegt, einzeln angefasst werden. Das kostet Zeit und Geld. Einfacher wäre eine direkte Korrektur das Fundaments gewesen, bevor man Stein für Stein das Häuschen erbaut.

Der UCD – Prozess vermeidet genau diese Kosten. Zusätzlich vermeidet er aufkommende Kosten, solltet ihr ein Produkt komplett an eurer potentiellen Nutzergruppe vorbei entwickeln. Je nach Firma und Firmengröße, könnte eine solche Entwicklung nämlich auch direkt den Ruin bzw. die Insolvenz bedeuten.

Der User Centered Design Prozess ist gerade wegen der iterativen Vorgehensweise ein wertvolles Werkzeug innerhalb der agilen Entwicklung und arbeitet wie andere agile Frameworks nach dem Leitsatz: „Fail frequently, fail fast“ (David Kelley, Professor an der Standford University). Diesen Satz kennen sicherlich viele von euch, die Berührungspunkte mit agiler Softwareentwicklung haben.

Teildisziplinen des UCD – Prozess

Der User Centered Design Prozess lässt sich im Prinzip in 3 Teildisziplinen zerlegen.

 

 

User Requirements Engineering

Das Erheben und Herausfinden des Nutzungskontextes, der Nutzergruppen und der damit verbunden Personas, als auch die notwendigen Erfordernisse oder Nutzerbedürfnisse und die abgeleiteten Nutzeranforderungen sind Teil des User Requirements Engineering. Oft kommen diese noch aus dem Marketing und werden zum Beispiel durch einen KANO – Fragebogen erhoben.

Konzept

Für das Konzept und dem dazugehörigen Produktentwurf oder der Dienstleistung sind unterschiedliche Fähigkeiten notwendig. Hier kommt die Usability, das Visual Design (User Interface Design), das Interaktionsdesign gemeinsam zum Tragen. Nur gemeinsam kann ein ganzheitliches, stimmiges Konzept entstehen. Daraus resultierend entsteht eine neue Programmversion, ein Facelift oder manchmal auch ein komplett neues Produkt. Wichtig ist es dabei immer eine ganzheitliceh UX zubetrachten und eine sehr gute Usability zum Beispiel durch die 7 Dialogprinzipien zu erlangen.

User Research

Beim User Research geht es vor allem um die Evaluation des Produkts oder der neuen Programmversion. Einige Methoden des User Research kommen auch schon beim User Requirements Engineering zum Einsatz. Diese Methoden haben an dieser Stelle allerdings eine andere Zielstellung. Die Ergebnisse der Evaluation offenbaren an welchen vorherigen Schritten des UCD lückenhaft gearbeitet wurde. An diesem Schritt muss angesetzt und das Produkt nachgeschärft werden. Damit beginnt eine neue Iteration des User Centered Design Prozesses.

User Requirements Engineering im UCD Prozess

Beim User Requirements Engineering geht es im 1. Schritt darum, den Nutzungskontext des Nutzers herauszufinden. Dazu gehören:

• Benutzer
• Aufgaben
• Ressourcen
• Physische und soziale Umgebung in der das System genutzt wird.

Nutzergruppen und Personas

Nutzergruppen

Auch der Benutzer lässt sich noch weiter in direkte und indirekte Nutzer unterteilen. Der direkte Nutzer interagiert direkt mit dem System. Der indirekte Nutzer arbeitet mit den Daten bzw. mit den Ergebnissen des Systems weiter. So könnte beispielsweise der direkte Nutzer bei einem Webshop ein Kunde sein, der etwas kaufen möchte. Der indirekte Nutzer ist dann der Mitarbeiter des Webshops, der den Auftrag entgegennimmt und den Versand sowie die Abrechnung anstößt. Es lassen sich noch weitere Nutzer unterscheiden. Der primäre Nutzer interagiert mit einem System, um ein Ziel zu erreichen. Der Sekundäre Nutzer, unterstützt diesen dabei. Ein gutes Beispiel für sekundäre Nutzer sind Support Mitarbeiter.

Um alle Nutzer und Nutzergruppen zu erfassen, macht man eine ausführliche Ziel- bzw. Nutzergruppenanalyse. Dabei gilt es vor allem heterogene und homogene Merkmale einer Nutzergruppe zu erfassen und diese trennscharf machen. Nutzergruppen in der UX sind nicht zwangsweise durch simple, demografische Daten zu erfassen (z.B. Geschlecht, Alter, Einkommen). Vielmehr kommt es auf andere drei Aspekte an, nach denen diese Nutzergrunppen in sich homogen sein sollten: welche Ziele/ Aufgaben hat ein User im Zusammenhang mit dem Produkt, welche Ressourcen werden für eine Nutzung benötigt und in welcher Umgebungen findet die Nutzung statt. Diese Variablen machen eine Nutzergruppe auch trennscharf gegenüber einer anderen Nutzergruppe. Die User Experience ist dabei der ausschlaggebende Punkt.

Personas

Aus den Nutzergruppen heraus können Personas erstellt werden. Personas sind stereotypische Abbildungen einer Nutzergruppen. Sie sind fiktiv, basieren aber auf empirischen Daten. Einige Lehrbücher empfehlen drei Personas pro Nutzergruppe zu erstellen. Jeweils eine Persona, die das jeweilige Ende einer Nutzergruppe darstellt und eine, die den Mittelwert empfiehlt. Ich möchte betonen, dass Personas ein Arbeitswerkzeug sind und kein Produktartefakt, das als Liefergegenstand dient. Euer Kunde wird diese nämlich normalerweise nicht zu Gesicht bekommen. Dabei können sich Personas fachlich unterscheiden. Zum Beispiel benötigt das Marketing oft andere Personas mit anderen Informationen als UX Engineers oder Testingenieure.

Wichtig: Eine Persona ist ein Werkzeug, mit dem ihr arbeiten können solltet. Es gibt keine normierte Form einer Persona und jeder Fachbereich benötigt unterschiedliche Informationen daraus. Erarbeitet Personas daher, wie ihr diese benötigt. Wichtig ist nur, dass die Daten innerhalb einer Persona empirisch erhoben und nicht eurer reinen Phantasie entsprungen sind. Der Charakter der Persona bleibt dabei fiktiv.

Aufgaben und Ziele des Benutzers

Eine Aufgabe ist eine Aktivität des Nutzers, um ein bestimmtes Ziel zu erreichen. Eine Aufgabe lässt sich in mehrere Teilaufgaben unterteilen. So kann zum Beispiel das Kaufen eines Produkts in mehrere, kleinere Aufgaben unterteilt werden, wie zum Beispiel:

• Aussuchen eines Produkts
• Produkt in den Warenkorb legen
• Checkout Prozess
  • Adressangabe
  • Rechnungsadresse
  • Bezahloption wählen

Diese Teilaufgaben lassen sich natürlich noch weiter verkleinern und manchmal ist dies auch notwendig, um eine zielgerichtete Evaluation durchzuführen.

Das Ziel und die Erfüllung dieser Ziele sind die Erfordernisse, die euer System mitbringen muss. Nur dann werden es die Nutzer akzeptieren oder sogar begeistert sein. Wenn ihr diese ‚User Needs‘ außer acht lasst, werdet ihr zwangsweise ein Produkt entwickeln, das sich im schlimmsten Fall nicht verkaufen lässt.

Ressourcen oder Restriktionen

Ressourcen sind im Nutzungskontext vor allem Zeit, Geld, physischer und mentaler Aufwand, benötigte Hardware und Software oder sonstige Materialien. Zum Beispiel benötigt man zum Bedienen einer iOS App ein Handy von Apple, damit man die App nutzen kann. Mit mentalem Aufwand ist im Web z.B. die Usability gemeint. Wenn man sich den Kopf darüber zerbrechen muss, wie ein Online-Shop funktioniert, wechselt der Nutzer schnell die Seite und wird kein Produkt dieses Shops kaufen. Es gibt im Internet eine ungeheure Auswahl. Wenn der mentale Aufwand das Aufsuchen einer anderen einfacheren Seite übersteigt, dann wird der Nutzer eure Seite schnell verlassen.

Die aufzubringenden Ressourcen sind in einer ganzheitlich betrachteten User Experience sehr wichtig. Man kann diese als Restriktionen verstehen, die ein Entwickler hat. Denn sollten sich Ressourcen dem Ende neigen, dann kommt es bei Benutzern fast automatisch zu einem Abbruchverhalten. Sei es aufgrund von Performance-Problemen (eine Website lädt z.B. sehr lange) oder einer schlechten Bedienführung eines Webshops.

Umgebung

Mit der Umgebung ist vor allem die physische-, soziale-, organisatorische- aber auch die technische- und psychische Umgebung gemeint. Die Umgebung ist zum Beispiel beim Bezahlvorgang mit der EC Karte sehr unterschiedlich. Je nachdem, ob man allein an einem Bankterminal steht oder an der Kasse am Supermarkt. Auch der Bezahlvorgang zu Hause am eigenen Rechner ist ein anderer, als über ein Handy. Diese Faktoren müssen allesamt bei der Entwicklung eines Systems berücksichtigt werden. Auch funktioniert das Bankomat – Prinzip zur Steuerung bei Bankautomaten einwandfrei. Das gleiche Prinzip wurde im Auto oder bei Waschmaschinen verwendet. Trotz gleichem Prinzip, kamen damit einige Nutzer überhaupt nicht zurecht und verzweifelten an der Bedienung. Das liegt daran, dass der Nutzungskontext ein anderer ist und dadurch Probleme in der Usability verursacht. Der Analyse des Nutzungskontextes sollte man also viel Aufmerksamkeit schenken.

 

 

Auch die User Needs können sich je nach Umgebung sehr unterscheiden.

Beispiel: Ich möchte mein Bahnticket am Handy kaufen. Mein Zug fährt in 5 Minuten am Bahngleis ab. Mein Erfordernis (= User Need) bezieht sich an dieser Stelle vor allem auf die Geschwindigkeit, mit der ich an mein Bahnticket komme. Wenn es zu lange dauert, fährt mein Zug am Ende ohne mich ab.

Wenn ich das Bahnticket auf meinem Rechner zuhause kaufen möchte, habe ich Zeit. Da möchte ich unterschiedliche Ticketpreise und Reisezeiten miteinander vergleichen, um das für mich beste Angebot zu finden.

Entsprechend der beiden Umgebungen muss die Anwendung darauf angepasst und anders gestaltet sein. Die Umgebung hat sehr hohen Einfluss auf die Erfordernisse des Users.

Nutzungsanforderungen im UCD – Prozess

Nutzungsanforderungen, sind Bedingungen und Fähigkeiten oder Funktionen, die ein System haben muss. Erst dann ist gewährleistet, dass die Bedürfnisse der Zielgruppe erfüllt sind. Es gibt mehrere Arten von Anforderungen:

• Gesetzliche Anforderungen
• Marktanforderungen
• Organisatorische Anforderungen
• Fachliche Anforderungen
• Nutzungsanforderungen

Diese Anforderungen, werden am Ende alle zu Systemanforderungen. An dieser Stelle des User Centered Design Prozess befasst sich der User Requirements Engineer ausschließlich mit den Nutzungsanforderungen. Für die Erhebung der anderen Anforderungen gibt es in einem Unternehmen oft diverse Verantwortliche. Im nächsten Schritt des UCDs (Gestaltung des UX Konzepts), spielen alle Anforderungen in ihrer Gesamtheit eine Rolle.

Die Syntax

Nutzungsanforderungen beschreiben, was ein Nutzer an Handlungen ausführen können muss. Dabei gibt es 3 Arten an Nutzungsanforderungen.

• erkennen
• eingeben
• auswählen

Die Syntax, in der man eine Nutzungsanforderung formuliert, ist laut ISO Norm wie folgt:

Der Nutzer muss am System <x> erkennen/eingeben/auswählen können.

Statt “Der Nutzer” kann man beispielsweise auch den Namen einer Persona einsetzen. Die Syntax ähnelt anderen Requirements Engineering Formulierungen. Gerade in Pflichten- und Lastenheften finden sich viele davon. Wichtig ist nur das Wort ‚muss‘. Denn bei anderen ‚weicheren‘ Formulierungen, wird eine solche Anforderung schnell als optional abgetan.

Wichtig: Die Anforderungen leitet ihr direkt aus den Erfordernissen ab! Dabei können mehrere Anforderungen auf das gleiche Erfordernis einzahlen.

Konzept

Beim Konzept kommen nun unterschiedliche Disziplinen zum Einsatz. Um eine hohe Benutzerfreundlichkeit zu gewährleisten, sollten mehrere unterschiedliche Fachrichtungen an der Erarbeitung des Konzeptes beteiligt sein. Zum einen gilt es Interaktionen und logische Abfolgen in der Oberfläche zu planen und zu platzieren. Um Usability zu garantieren, sollten die Dialogprinzipien und Gestaltgesetze dabei angewendet werden. Das User Interface muss außerdem übersichtlich und für die Zielgruppe ansprechend gestaltet sein. Weiter muss sich stimmiges Navigationskonzept (bspw. durch Card – Sorting), als Herz einer jedem Software, ausgedacht werden. Dabei basiert das UX Konzept zu jeder Zeit auf den erhobenen Nutzungsanforderungen im Schritt vorher. Andere Anforderungen (z.B. gesetzliche oder technische Anforderungen) wirken sich ebenfalls auf das User Interface aus.

Je nachdem, wie der Prototyp am Ende aussehen soll, werden verschiedene Disziplinen aus dem Entwicklungsteam benötigt. Oft arbeitet in diesem Prozessschritt bereits ein Frontend Entwickler oder ein Softwarearchitekt mit. Es gilt: stimmt euch viel ab und kommuniziert lieber zu viel. Manche Dinge sind beispielsweise technisch sehr aufwendig oder in der derzeitigen Entwicklungsumgebung fast unmöglich umsetzbar. Solche Dinge sollten frühzeitig geklärt und für alle transparent gemacht werden.

Der erste Prototyp

Bei Produkten, die vor allem aus Hardware bestehen, sollten die entsprechenden Ingenieure dem Konzeptteam vor Entwicklungsbeginn alle Restriktionen erklären. Das Konzept, oder die erste Programm- oder Produktversion muss nicht perfekt sein. Hier ist es vor allem wichtig, alle absolut notwendigen Anforderungen erst einmal komplett unterzubringen. Wichtig ist auch zu priorisieren, welche Anforderung welche Aufmerksamkeit erhalten soll.  Geht so früh wie möglich mit dem ersten Prototyp in einen Test, um euren ersten Ansatz direkt zu validieren.

An dieser Stelle können Low-Fidelity Prototypen, oder in der Hardware behelfsmäßige Produktversionen, weiterhelfen. Ein schönes Beispiel dafür ist der Hotelservice Roboter aus dem Buch “Sprint” von Jake Knapp und John Zeratsky*. Darin beschreiben die Autoren, wie sie einen Roboter aus Kartons auf einem Skateboard und einem Tablet nutzten, um eine erste Version ihres Serviceroboters für Hotels zu testen.

Konzept erstellen

Um ein tragbares Konzept zu gestalten, sollten die  7 Dialogprinzipien und für den Content das UX Writing berücksichtigt werden. Weitere Richtlinien sind  Gestaltgesetze oder allgemeine Empfehlungen sowie Best Practices (wie zum Beispiel der Umgang mit Dialogfenstern), die ihr in Büchern von Steve Krug*, Jacob Nielsen*, Don Norman* aber vor allem im Internet findet. Einige davon findet ihr auch in diesem Blog.

Um einen Ansatz zu finden, hilft es oft konkurrierende oder ähnliche Produkte zu betrachten. Hier ist vor allem der Input aus eurem Marketing sehr wertvoll. Das Marketing beschäftigt sich meist auch mit den Funktionen von direkten und indirekten Mitbewerbern.

Wenn ihr euer erstes Konzept erstellt habt, dann fangt an dieses zu evaluieren.

Anmerkung: Gerade in der ersten Version könnt ihr auf aufwendiges UI – Design verzichten. Viel wichtiger ist an dieser Stelle herauszufinden, ob ihr alle Erfordernisse und Anforderungen erfasst habt oder ob ihr diese nur rudimentär erfüllt.

User Research im UCD – Prozess

Evaluationen sind ein Teil des UCD – Prozess. In der Praxis wird dieser Teil fatalerweise oft ausgelassen. Nur wenige Projekte haben den Mehrwert aus dem stetigen Testen erkannt. Oft ist es so, dass Produkte erst am Ende der Entwicklung getestet werden. Leider ist es dann oft zu spät, um noch Änderungen am Produkt vornehmen zu können. Die Zeit oder das Budget fehlt. Zu einer kompletten Iteration gemäß dem User Centered Design Prozess und um eine optimale User Experience zu gewährleisten, ist das Testen unabdingbar. Dazu musst du wie im Marketing auch, KPIs definieren und diese messen.

Ziel der Evaluation

Das Ziel oder die Ziele von Evaluationen können sich je nach Projekt und Projektstatus unterscheiden. Eine Evaluation während der Entwicklung wird als formative Evaluation bezeichnet. Hier geht es meist um einen Erkenntnisgewinn oder um eine Entwicklungskontrolle. Dabei ist die Vorgehensweise die Gleiche. Der UX Experte stellt Hypothesen auf, gegen die er testet. Meist ist das Konzept schon eine abstrakte Form einer Hypothese. Eine Hypothese könnte folgendermaßen lauten:

„Der Prototyp unseres Produkts X erfüllt alle notwendigen Nutzungsanforderungen hinreichend.“

Diese Hypothese ist nicht sonderlich spezifisch, aber meist impliziert. Eine andere Hypothese (zum Beispiel bei einem A/B Test) könnte lauten:

„Die Variante A des Produkts führt zu einer höheren Conversion Rate, als die Variante B.“

Dabei ist das Ziel wesentlich spezifischer und kann besser, im Zweifel auch statistisch getestet werden. Macht euch vor dem Testen unbedingt Gedanken über euer Ziel. Nur zielgerichtetes Testen hat einen wirklichen Mehrwert. Exploratives Testen gehört in die Phase des User Requirements Engineering, nicht aber zur Evaluation.

Summative Evaluation

Der Unterschied zwischen einer formativen und einer summativen Evaluation liegt vor allem im Zeitpunkt, wann sie stattfindet. Eine summative Evaluation wird immer am Ende der Entwicklung gemacht. Als Entwicklung ist hierbei nicht zwangsweise das Projektende zu sehen. Es kann sich auch um eine Programmversion handeln, die über einen längeren Zeitraum vorbereitet wurde.

Summative Evaluationen dienen meist zur Genehmigung. Für medizinisch, technische Geräte gelten meist andere Usability Standards als für Web Anwendungen. Bei medizinischen Geräte stehen Usability Standards im Gesetz. Die TÜV Prüfung eures Autos, die alle paar Jahre ansteht, ist ebenfalls eine Form der summativen Evaluation. In der Software sind summative Tests oft Barrierefreiheitstests, wie die BITV Prüfung*.

Was kommt nach dem Test?

Jeder Test liefert für euch wertvolle Ergebnisse. Es kann sich herausstellen, dass die Nutzungskontextanalyse z.B. noch lückenhaft ist. Das macht sich genau dann bemerkbar, wenn Bedürfnisse der Nutzer im Test aufgetaucht sind, an die vorher noch nicht gedacht wurde. Als Beispiel: Der Kunde bestellt eine Jeans im Online-Shop. Er bekommt als Feedback vom System keine Bestätigung. Zwangsläufig taucht an dieser Stelle ein Bedürfnis auf. Der Kunde möchte ist unsicher und möchte, ob die Bestellung geklappt hat. Unter Umständen bestellt der Kunde aus seiner Unsicherheit heraus nochmal die gleiche Jeans. Um dies zu vermeiden sollte man in also Phase 1 des User Centered Design Prozesses nochmal näher beleuchten. Danach werden die nächsten Schritte des UCD wie gewohnt abgearbeitet, bis es mit einem neuen Konzeptvorschlag in den nächsten Test und die nächste Iteration geht.

Vielleicht habt ihr aber auch schon an alle Bedürfnisse gedacht und das Problem liegt an der Navigation auf der Seite. Die Kunden brechen ab und schließen den Browser. Dann müsst ihr in der Konzeptphase des UCDs einsteigen und euer Konzept überarbeiten. Auch hier folgt danach ein weitere Test und die nächste Iteration.

Ihr wiederholt die einzelnen notwendigen Schritte des UCD – Prozess so lange, bis ihr ein optimales Nutzererlebnis und somit eine bestmögliche User Experience geschaffen habt. Je mehr Iterationen ihr einplant, desto besser wird euer Produkt am Ende sein.

Fazit

Der User Centered Design Prozess ist iterativ. Er durchläuft insgesamt 4 Schritte die in 3 Teilbereiche der UX unterteilt werden können. Dem User Requirements Engineering, der Konzeptentwicklung und dem User Research. Jeder einzelne Schritt ist genauso wichtig, wie der vorherige und nachfolgende. Wer einzelne Schritte auslässt nimmt sich selbst die Möglichkeit ein optimales Nutzererlebnis zu schaffen. Je mehr Iterationen des UCD – Prozesses durchlaufen werden, desto besser wird euer Produkt und die damit einhergehende User Experience.

Quellen

• DIN EN ISO 9241-210 Ergonomie der Mensch-System-Interaktion – Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme (ISO 9241-210:2010); Deutsche Fassung EN ISO 9241-210:2010 Ausgabe 2011-01.
• Über den BITV Test: abgerufen am 24.01.2019
• Steve Krug: Don’t make me think: A Common Sense Approach to Web Usability, Revised Edition, New Riders, 2013.
• Jakob Nielsen: Usability Engineering, Revised Edition, Morgan Kaufmann,, 1994.
• Don Norman: The Design of Everyday Things: Revised and Expanded Edition, Basic Books, 2013.
• Jake Knapp, John Zeratsky, Braden Kowitz, Almuth Braun: Sprint: Wie man in nur fünf Tagen neue Ideen testet und Probleme löst, Redline Verlag, 2016