Benutzerzentriertes Design - User-centered design

User-Centered Design ( UCD ) oder User-Driven Development ( UDD ) ist ein Prozessrahmen (nicht beschränkt auf Schnittstellen oder Technologien), in dem Usability- Ziele, Benutzereigenschaften, Umgebung , Aufgaben und Workflow eines Produkts , einer Dienstleistung oder eines Prozesses vorgegeben sind umfassende Aufmerksamkeit in jeder Phase des Designprozesses . Diese Tests werden in jeder Phase des Prozesses mit/ohne tatsächlichen Benutzern durchgeführt, von Anforderungen , Vorserienmodellen und Postproduktion, um einen Beweiskreis zurück zu schließen und sicherzustellen, dass "die Entwicklung mit dem Benutzer als Mittelpunkt voranschreitet". Eine solche Prüfung ist notwendig , da es für die Designer eines Produkts oft sehr schwierig ist , intuitiv die Erstanwender ihrer Konstruktion zu verstehen , Erfahrungen und was jedes Benutzers Lernkurve kann aussehen. Benutzerzentriertes Design basiert auf dem Verständnis eines Benutzers, seinen Anforderungen, Prioritäten und Erfahrungen und führt bekanntermaßen zu einem erhöhten Produktnutzen und einer höheren Benutzerfreundlichkeit, da es den Benutzer zufrieden stellt.

Der Hauptunterschied zu anderen Produktdesign-Philosophien besteht darin, dass benutzerzentriertes Design versucht, das Produkt so zu optimieren, wie Benutzer das Produkt verwenden können, wollen oder müssen, damit Benutzer nicht gezwungen sind, ihr Verhalten und ihre Erwartungen an das Produkt anzupassen. Die Benutzer stehen somit im Zentrum von zwei konzentrischen Kreisen. Der innere Kreis umfasst den Kontext des Produkts, die Ziele seiner Entwicklung und die Umgebung, in der es laufen würde. Der äußere Kreis umfasst detailliertere Details zu Aufgabendetails, Aufgabenorganisation und Aufgabenfluss.

Geschichte

Der Begriff "User-Centered Design" wurde 1977 von Rob Kling geprägt und später in Donald A. Normans Forschungslabor an der University of California, San Diego, übernommen . Das Konzept wurde durch die Veröffentlichung des Buches User-Centered System Design: New Perspectives on Human-Computer Interaction im Jahr 1986 weit verbreitet. Weitere Aufmerksamkeit und Akzeptanz fand das Konzept in Normans bahnbrechendem Buch The Design of Everyday Things (ursprünglich The Psychologie der alltäglichen Dinge ). In diesem Buch beschreibt Norman anhand von Beispielen die Psychologie hinter dem, was er für „gutes“ und „schlechtes“ Design hält. Er betont die Bedeutung von Design in unserem täglichen Leben und die Folgen von Fehlern, die durch schlechte Designs verursacht werden.

Die beiden Bücher enthalten Grundsätze für den Bau gut gestalteter Produkte. Seine Empfehlungen orientieren sich an den Bedürfnissen des Nutzers, lassen aber die aus seiner Sicht untergeordneten Aspekte wie Ästhetik beiseite. Die wichtigsten Highlights davon sind:

Vereinfachung der Struktur der Aufgaben, sodass die möglichen Aktionen zu jedem Zeitpunkt intuitiv sind.
Machen Sie Dinge sichtbar, einschließlich des konzeptionellen Modells des Systems, Aktionen, Ergebnisse von Aktionen und Feedback.
Richtige Zuordnungen zwischen beabsichtigten Ergebnissen und erforderlichen Aktionen.
Die Zwänge von Systemen annehmen und ausnutzen

In einem späteren Buch, Emotional Design , kehrt Norman zu einigen seiner früheren Ideen zurück, um herauszuarbeiten, was er als übermäßig reduzierend empfunden hatte.

Modelle und Ansätze

Zum Beispiel kann der User-Centered Design-Prozess Software-Designern helfen, das Ziel eines für ihre Benutzer entwickelten Produkts zu erreichen. Anwenderwünsche werden von Anfang an berücksichtigt und in den gesamten Produktzyklus einbezogen. Diese Anforderungen werden durch Untersuchungsmethoden festgestellt und verfeinert, darunter: ethnografische Studien, kontextbezogene Untersuchungen , Prototypentests, Usability-Tests und andere Methoden. Generative Verfahren können ebenfalls verwendet werden, einschließlich: Kartensortierung , Affinitätsdiagrammerstellung und partizipative Designsitzungen. Darüber hinaus können Nutzeranforderungen durch eine sorgfältige Analyse von verwendbaren Produkten, die dem entworfenen Produkt ähnlich sind, abgeleitet werden.

User-Centered Design lässt sich von folgenden Modellen inspirieren:

Kooperatives Gestalten : Gestalter und Nutzer auf Augenhöhe einbeziehen. Dies ist die skandinavische Tradition des Designs von IT-Artefakten und sie hat sich seit 1970 weiterentwickelt. Dies wird auch als Co-Design bezeichnet .
Partizipatives Design (PD), ein nordamerikanischer Begriff für das gleiche Konzept, inspiriert von Cooperative Design, das sich auf die Beteiligung der Nutzer konzentriert. Seit 1990 findet halbjährlich eine partizipative Designkonferenz statt.
Kontextuelles Design , "kundenzentriertes Design" im tatsächlichen Kontext, einschließlich einiger Ideen aus dem partizipativen Design

Hier sind die Prinzipien, die dabei helfen, sicherzustellen, dass ein Design benutzerzentriert ist:

Design basiert auf einem expliziten Verständnis von Benutzern, Aufgaben und Umgebungen.
Die Benutzer werden während des gesamten Designs und der Entwicklung involviert.
Das Design wird durch nutzerzentrierte Bewertung angetrieben und verfeinert.
Der Prozess ist iterativ.
Design adressiert die gesamte Benutzererfahrung.
Das Designteam umfasst multidisziplinäre Fähigkeiten und Perspektiven.

Benutzerzentrierter Designprozess

Das Ziel des User-Centered Designs ist es, Produkte mit einer sehr hohen Benutzerfreundlichkeit herzustellen . Dazu gehört, wie komfortabel das Produkt in Bezug auf seine Verwendung, Handhabbarkeit, Effektivität ist und wie gut das Produkt auf die Benutzeranforderungen abgebildet wird. Im Folgenden sind die allgemeinen Phasen des benutzerzentrierten Designprozesses aufgeführt:

Nutzungskontext angeben: Identifizieren Sie, wer die Hauptbenutzer des Produkts sind, warum sie das Produkt verwenden, welche Anforderungen sie haben und in welcher Umgebung sie es verwenden werden.
Anforderungen spezifizieren: Sobald der Kontext spezifiziert ist, ist es an der Zeit, die granularen Anforderungen des Produkts zu identifizieren. Dies ist eine wichtige Phase, die es den Designern weiter erleichtern kann, Storyboards zu erstellen und wichtige Ziele zu setzen, um das Produkt erfolgreich zu machen.
Erstellen von Designlösungen und -entwicklung : Beginnen Sie basierend auf den Produktzielen und -anforderungen einen iterativen Prozess des Produktdesigns und der Produktentwicklung.
Produkt bewerten : Produktdesigner führen Usability-Tests durch, um in jeder Phase des benutzerzentrierten Designs das Feedback der Benutzer zum Produkt zu erhalten.

In den nächsten Schritten wird das obige Verfahren wiederholt, um das Produkt weiter zu veredeln. Diese Phasen sind allgemeine Ansätze und Faktoren wie Designziele, Team und deren Zeitplan und Umgebung, in der das Produkt entwickelt wird, bestimmen die geeigneten Phasen für ein Projekt und deren Reihenfolge. Sie können entweder einem Wasserfallmodell , einem agilen Modell oder einer anderen Softwareentwicklungspraxis folgen .

Zweck

UCD stellt Fragen zu Benutzern und deren Aufgaben und Zielen und verwendet die Erkenntnisse dann, um Entscheidungen über Entwicklung und Design zu treffen. UCD einer Website zum Beispiel versucht, die folgenden Fragen zu beantworten:

Wer sind die Nutzer der Website?
Was sind die Aufgaben und Ziele der Benutzer?
Wie sind die Erfahrungen der Benutzer mit der Website und ähnlichen Websites?
Welche Funktionen benötigen die Nutzer von der Website?
Welche Informationen könnten die Nutzer benötigen und in welcher Form benötigen sie diese?
Wie sollte die Website funktionieren?
In welchen extremen Umgebungen kann auf die Website zugegriffen werden?
Ist der Benutzer Multitasking?
Nutzt die Benutzeroberfläche verschiedene Eingabemodi wie Berührung, Sprache, Gesten oder Orientierung?

Elemente

Als Beispiel für UCD-Ansichten sind die wesentlichen Elemente von UCD einer Website normalerweise die Überlegungen zu Sichtbarkeit, Zugänglichkeit, Lesbarkeit und Sprache.

Sichtweite

Die Sichtbarkeit hilft dem Benutzer, ein mentales Modell des Dokuments zu erstellen. Modelle helfen dem Benutzer, die Auswirkungen seiner Aktionen während der Verwendung des Dokuments vorherzusagen. Wichtige Elemente (wie solche, die die Navigation erleichtern ) sollten betont werden. Benutzer sollen auf einen Blick erkennen können, was sie mit dem Dokument machen können und was nicht.

Barrierefreiheit

Benutzer sollten in der Lage sein, Informationen unabhängig von ihrer Länge schnell und einfach im gesamten Dokument zu finden. Den Nutzern sollen verschiedene Möglichkeiten geboten werden, Informationen zu finden (z. B. Navigationselemente, Suchfunktionen, Inhaltsverzeichnis, klar beschriftete Abschnitte, Seitenzahlen, Farbcodierung etc.). Navigationselemente sollten dem Genre des Dokuments entsprechen. „ Chunking “ ist eine nützliche Strategie, bei der Informationen in kleine Teile zerlegt werden, die in eine sinnvolle Reihenfolge oder Hierarchie organisiert werden können . Die Möglichkeit, das Dokument zu überfliegen , ermöglicht es Benutzern, ihre Informationen durch Scannen statt durch Lesen zu finden. Zu diesem Zweck werden oft fette und kursive Wörter verwendet.

Lesbarkeit

Text sollte leicht zu lesen: Durch die Analyse der rhetorischen Situation die Designer sollten in der Lage sein , einen nützlichen font-family und zu bestimmen , Schriftstil. Ornamentale Schriftarten, Text in Großbuchstaben , großer oder kleiner Fließtext können schwer zu lesen sein und sollten vermieden werden. Textfarben und Fettdruck können in textlastigen Szenarien hilfreich sein. Ein hoher Bild-Grund- Kontrast zwischen Text und Hintergrund erhöht die Lesbarkeit. Dunkler Text auf hellem Hintergrund ist am besten lesbar.

Sprache

Je nach rhetorischer Situation werden bestimmte Arten von Sprachen benötigt. Kurze Sätze sind hilfreich, ebenso gut geschriebene Texte, die in Erklärungen und ähnlichen Massentextsituationen verwendet werden. Es sei denn , die Situation es erfordert, Jargon oder stark technische Begriffe sollten nicht verwendet werden. Viele Autoren werden sich dafür entscheiden, die aktive Stimme , Verben (anstelle von Substantivketten oder Nominalen ) und eine einfache Satzstruktur zu verwenden.

Analysetools

Es gibt eine Reihe von Werkzeugen, die bei der Analyse von User-Centered Design verwendet werden, hauptsächlich: Personas, Szenarien und wesentliche Anwendungsfälle.

Persona

Während des UCD-Prozesses kann eine Persona erstellt werden, die den Benutzer repräsentiert. Eine Persona ist ein Benutzerarchetyp, der als Entscheidungshilfe für Produktfunktionen, Navigation, Interaktionen und sogar visuelles Design dient. In den meisten Fällen werden Personas aus einer Reihe ethnografischer Interviews mit echten Menschen synthetisiert und dann in 1-2-seitigen Beschreibungen festgehalten, die Verhaltensmuster, Ziele, Fähigkeiten, Einstellungen und Umgebung beinhalten, mit einigen fiktiven persönlichen Details, um die Persona zu vermitteln Leben.

Für jedes Produkt oder manchmal für jeden Werkzeugsatz innerhalb eines Produkts gibt es eine kleine Menge von Personas, von denen eine der Hauptfokus für das Design ist. Es gibt auch sogenannte sekundäre Persönlichkeiten , bei denen der Charakter nicht das Hauptziel des Designs ist, sondern seine Bedürfnisse erfüllt und Probleme nach Möglichkeit gelöst werden sollen. Sie existieren, um weitere mögliche Probleme und Schwierigkeiten zu erklären, die auftreten können, obwohl die primäre Person mit ihrer Lösung zufrieden ist. Es gibt auch eine Anti-Persona , für die das Design speziell nicht gemacht ist.

Personas sind in dem Sinne nützlich, dass sie ein gemeinsames Verständnis der Benutzergruppe schaffen, für die der Designprozess aufgebaut ist. Außerdem tragen sie dazu bei, die Designüberlegungen zu priorisieren, indem sie einen Kontext dafür bereitstellen, was der Benutzer braucht und welche Funktionen einfach hinzuzufügen und zu haben sind. Sie können auch einer diversifizierten und verstreuten Benutzergruppe ein menschliches Gesicht und eine menschliche Existenz verleihen und dazu beitragen, Empathie zu schaffen und Emotionen hinzuzufügen, wenn sie sich auf die Benutzer beziehen. Da Personas jedoch eine verallgemeinerte Wahrnehmung der primären Stakeholder-Gruppe aus gesammelten Daten sind, können die Merkmale zu breit und typisch oder zu sehr "durchschnittlicher Joe" sein. Manchmal können Personas auch stereotype Eigenschaften haben, die den gesamten Designprozess beeinträchtigen können. Insgesamt können Personas ein nützliches Werkzeug sein, das von Designern verwendet werden kann, um fundierte Designentscheidungen zu treffen, anstatt sich auf eine Reihe von Daten oder eine Vielzahl von Personen zu beziehen.

Personas können auch über die gesamte UCD eines Produkts geändert werden, basierend auf Benutzertests und sich ändernder Umgebung. Dies ist keine ideale Art und Weise zu verwenden , Personas , aber sollte kein Tabu entweder besonders, wenn es offensichtlich wird , dass Variablen eines Produkts Entwicklung umgebenden haben sich geändert , da das Design gestartet und aktuelle Persona / s kann sorgen nicht gut auf die veränderten Bedingungen.

Szenario

Ein im UCD-Prozess erstelltes Szenario ist eine fiktive Geschichte über den "Alltag von" oder eine Abfolge von Ereignissen mit der primären Anspruchsgruppe als Hauptfigur. Typischerweise wird eine früher erstellte Persona als Hauptfigur dieser Geschichte verwendet. Die Geschichte sollte spezifisch für die Ereignisse sein, die sich auf die Probleme der primären Interessengruppe beziehen, und normalerweise auf die Hauptforschungsfragen, auf denen der Entwurfsprozess aufbaut. Diese können sich als einfache Geschichte über das tägliche Leben einer Person herausstellen, aber kleine Details aus den Ereignissen sollten Details über die Benutzer implizieren und können emotionale oder körperliche Merkmale beinhalten. Es kann das Best-Case-Szenario geben , in dem alles für die Hauptfigur am besten funktioniert, das Worst-Case-Szenario , in dem die Hauptfigur erlebt, dass alles um sie herum schief läuft, und ein Durchschnitts-Szenario , das das typische Leben ist des Individuums, wo nichts wirklich Besonderes oder wirklich Deprimierendes passiert, und der Tag geht einfach weiter.

Szenarien schaffen einen sozialen Kontext, in dem die Personas existieren, und schaffen auch eine tatsächliche physische Welt, anstatt sich einen Charakter mit internen Eigenschaften aus gesammelten Daten und sonst nichts vorzustellen; die Existenz der Persona ist mit mehr Handlung verbunden. Ein Szenario wird auch von den Menschen leichter verstanden, da es in Form einer Geschichte vorliegt und leichter zu verfolgen ist. Wie die Personas sind diese Szenarien jedoch Annahmen des Forschers und Designers und werden ebenfalls aus einem Satz organisierter Daten erstellt. Es ist wichtig sicherzustellen, dass Szenarien so nah wie möglich an realen Szenarien erstellt werden. Trotzdem kann es manchmal schwierig sein, zu erklären und zu informieren, wie niedrigstufige Aufgaben auftreten, z. B. der Denkprozess einer Persona vor dem Handeln.

Anwendungsfall

Kurz gesagt, ein Anwendungsfall beschreibt die Interaktion zwischen einem Individuum und dem Rest der Welt. Jeder Anwendungsfall beschreibt ein Ereignis, das im wirklichen Leben für einen kurzen Zeitraum auftreten kann, aber aus komplizierten Details und Interaktionen zwischen dem Akteur und der Welt bestehen kann. Es wird als eine Reihe einfacher Schritte dargestellt, mit denen der Charakter sein Ziel erreicht, in Form eines Ursache-Wirkungs-Schemas. Anwendungsfälle werden normalerweise in Form eines Diagramms mit zwei Spalten geschrieben: erste Spalte mit der Bezeichnung Akteur , zweite Spalte mit der Bezeichnung Welt , und die von jeder Seite ausgeführten Aktionen werden der Reihe nach in die entsprechenden Spalten geschrieben. Im Folgenden finden Sie ein Beispiel für einen Anwendungsfall für die Darbietung eines Songs auf einer Gitarre vor einem Publikum.

Schauspieler	Welt
wähle Musik zum Abspielen
Gitarre abholen
	Noten anzeigen
spielen Sie jede Note auf Noten mit Gitarre
	Vermitteln Sie dem Publikum eine Note mit Ton
	Publikum gibt dem Darsteller Feedback
Bewerten Sie die Leistung und passen Sie sie bei Bedarf basierend auf dem Feedback des Publikums an.
komplettes Lied mit erforderlichen Anpassungen
	Applaus des Publikums

Die Interaktion zwischen Schauspieler und Welt ist ein Akt, der im Alltag zu sehen ist, und wir nehmen sie als selbstverständlich hin und denken nicht zu viel über die kleinen Details nach, die passieren müssen, damit eine Handlung wie die Aufführung eines Musikstücks stattfindet existieren. Es ist vergleichbar mit der Tatsache, dass wir beim Sprechen unserer Muttersprache nicht zu viel über die Grammatik und die Formulierung von Wörtern nachdenken; sie kommen einfach heraus, weil wir es so gewohnt sind, sie zu sagen. Die Handlungen zwischen einem Akteur und der Welt, insbesondere dem primären Stakeholder (Benutzer) und der Welt in diesem Fall, sollten im Detail durchdacht werden, und daher werden Anwendungsfälle erstellt, um zu verstehen, wie diese winzigen Interaktionen stattfinden.

Ein wesentlicher Anwendungsfall ist eine besondere Art von Anwendungsfall, auch abstrakter Anwendungsfall genannt . Wesentliche Anwendungsfälle beschreiben das Wesen des Problems und behandeln die Natur des Problems selbst. Beim Schreiben wesentlicher Anwendungsfälle sollten keine Annahmen über unzusammenhängende Details gemacht werden. Darüber hinaus sollten die Ziele des Themas vom Prozess und der Umsetzung getrennt werden, um dieses bestimmte Ziel zu erreichen. Unten ist ein Beispiel für einen wesentlichen Anwendungsfall mit dem gleichen Ziel wie das vorherige Beispiel.

Schauspieler	Welt
Wählen Sie Noten für die Aufführung aus
sammelt notwendige Ressourcen
	bietet Zugang zu Ressourcen
spielt Stück nacheinander
	Leistung vermitteln und interpretieren
	gibt Feedback
vervollständigt die Leistung

Anwendungsfälle sind nützlich, weil sie dabei helfen, nützliche Ebenen der Entwurfsarbeit zu identifizieren. Sie ermöglichen es den Designern, die tatsächlichen Prozesse auf niedriger Ebene zu sehen, die an einem bestimmten Problem beteiligt sind, was die Handhabung des Problems erleichtert, da bestimmte kleinere Schritte und Details, die der Benutzer macht, offengelegt werden. Die Aufgabe der Designer sollte es sein, diese kleinen Probleme zu berücksichtigen, um zu einer endgültigen, funktionierenden Lösung zu gelangen. Eine andere Möglichkeit, dies zu sagen, ist, dass Anwendungsfälle komplizierte Aufgaben in kleinere Bits aufteilen, wobei diese Bits nützliche Einheiten sind. Jedes Bit vervollständigt eine kleine Aufgabe, die sich dann zur letzten größeren Aufgabe aufbaut. Wie beim Schreiben von Code auf einem Computer ist es einfacher, die grundlegenden kleineren Teile zu schreiben und sie zuerst zum Laufen zu bringen und sie dann zusammenzusetzen, um den größeren, komplizierteren Code fertigzustellen, anstatt den gesamten Code von Anfang an in Angriff zu nehmen.

Die erste Lösung ist weniger riskant, denn wenn etwas mit dem Code schief geht, ist es einfacher, das Problem in den kleineren Bits zu suchen, da das Segment mit dem Problem dasjenige ist, das nicht funktioniert, während bei der letzteren Lösung die Programmierer müssen möglicherweise den gesamten Code durchsuchen, um nach einem einzelnen Fehler zu suchen, was sich als zeitaufwändig erweist. Die gleiche Argumentation gilt für das Schreiben von Anwendungsfällen in UCD. Schließlich vermitteln Anwendungsfälle nützliche und wichtige Aufgaben, bei denen der Designer jetzt sehen kann, welche wichtiger sind als andere. Zu den Nachteilen beim Schreiben von Anwendungsfällen gehört die Tatsache, dass jede Aktion des Schauspielers oder der Welt aus wenigen Details besteht und einfach nur eine kleine Aktion ist. Dies kann möglicherweise zu weiterer Fantasie und unterschiedlicher Interpretation der Handlung von verschiedenen Designern führen.

Außerdem ist es während des Prozesses sehr einfach, eine Aufgabe zu stark zu vereinfachen, da eine kleine Aufgabe, die von einer größeren Aufgabe abgeleitet wird, noch aus noch kleineren Aufgaben bestehen kann, die verpasst wurden. Wenn Sie eine Gitarre in die Hand nehmen, müssen Sie sich vielleicht überlegen, welche Gitarre Sie aufnehmen, welches Plektrum Sie verwenden und wo sich die Gitarre zuerst befindet. Diese Aufgaben können dann in kleinere Aufgaben unterteilt werden, z. B. zuerst darüber nachdenken, welche Farbe der Gitarre zum Aufführungsort des Stücks passt, und andere damit zusammenhängende Details. Aufgaben können in noch kleinere Aufgaben unterteilt werden, und es liegt am Designer, zu bestimmen, an welcher Stelle die Aufteilung der Aufgaben am besten aufgehoben wird. Aufgaben können nicht nur zu stark vereinfacht, sondern auch ganz weggelassen werden. Daher sollte der Designer beim Schreiben von Anwendungsfällen alle Details und alle wichtigen Schritte kennen, die mit einem Ereignis oder einer Aktion verbunden sind.

Siehe auch

Verweise

Weiterlesen

Video

Languages

In other projects