Benutzerzentriertes Design

Siehe auch: Menschenzentriertes Design

Benutzerzentriertes Design (UCD) oder Benutzerorientierte Entwicklung (Udd) ist ein Prozessrahmen (nicht auf Schnittstellen oder Technologien beschränkt) Benutzerfreundlichkeit Ziele, Benutzermerkmale, Umgebung, Aufgaben und Workflow von a Produkt, Service oder Prozess werden in jeder Phase der Stufe von großer Aufmerksamkeit gewidmet Designprozess. Diese Tests werden in jeder Phase des Prozesses von/ohne tatsächliche Benutzer durchgeführt Bedarf, Vorproduktionsmodelle und Postproduktion, Abschluss eines Beweiskreises zurück und sicherstellen, dass "die Entwicklung mit dem Benutzer als Schwerpunkt des Fokus verläuft".[1][2] Solche Tests[3] ist notwendig, da es für die Designer eines Produkts oft sehr schwierig ist, die ersten Nutzer ihres Designs intuitiv zu verstehen Erfahrungen, und was der einzelnen Benutzer Lernkurve kann wie aussehen. Das benutzerzentrierte Design basiert auf dem Verständnis eines Benutzers, seiner Anforderungen, Prioritäten und Erfahrungen, die bei Verwendung zu einer erhöhten Produktnützlichkeit und Benutzerfreundlichkeit führen, da es dem Benutzer Zufriedenheit liefert.[4]

Der Hauptunterschied zu anderen Produktdesign-Philosophien besteht darin, dass benutzerzentriertes Design versucht, das Produkt darüber zu optimieren, wie Benutzer das Produkt können, wollen, wollen oder müssen, damit Benutzer nicht gezwungen sind, ihr Verhalten und ihre Erwartungen zur Aufnahme des Produkts zu ändern. Die Benutzer stehen somit in der Mitte von zwei konzentrischen Kreisen. Der innere Kreis enthält den Kontext des Produkts, die Entwicklung der Entwicklung und die Umgebung, in der er laufen würde. Der äußere Kreis beinhaltet körnigere Details zu Aufgabendetails, Aufgabenorganisation und Aufgabenfluss.[2]

Geschichte

Der Begriff "benutzerzentriertes Design" wurde 1977 von Rob Kling geprägt[5] und später adoptiert in Donald A. Norman's Forschungslabor bei der Universität von Kalifornien, San Diego. Das Konzept wurde aufgrund der Veröffentlichung des Buches weithin beliebt Benutzerzentriertes Systemdesign: Neue Perspektiven zur Interaktion zwischen Mensch und Komputer 1986.[6] Das Konzept erlangte weitere Aufmerksamkeit und Akzeptanz in Norans wegweisendem Buch Das Design alltäglicher Dinge (ursprünglich genannt Die Psychologie alltäglicher Dinge). In diesem Buch beschreibt Norman die Psychologie hinter dem, was er für "gut" und "schlecht" anhand von Beispielen hält. Er erhöht die Bedeutung des Designs in unserem Alltag und die Folgen von Fehlern, die durch schlechte Designs verursacht werden.

Die beiden Bücher enthalten Prinzipien zum Aufbau gut gestalteter Produkte. Seine Empfehlungen basieren auf den Bedürfnissen des Benutzers und lassen die sekundären Probleme wie Ästhetik beiseite. Die Haupthighlights von diesen sind:

  1. Vereinfachung der Struktur der Aufgaben so, dass die möglichen Handlungen jederzeit intuitiv sind.
  2. Machen Sie die Dinge sichtbar, einschließlich des konzeptionellen Modells des Systems, der Aktionen, der Ergebnisse von Aktionen und dem Feedback.
  3. Die Zuordnungen zwischen beabsichtigten Ergebnissen und den erforderlichen Maßnahmen bringen.
  4. Umarmung und Nutzung der Einschränkungen von Systemen.

In einem späteren Buch, Emotionales Design,[7]: S. 5 Norman kehrt zu einigen seiner früheren Ideen zurück, um das zu erläutern, was er als übermäßig reduktiv zu finden war.

Modelle und Ansätze

Zum Beispiel kann der benutzerzentrierte Designprozess Softwaredesigner helfen, das Ziel eines für ihre Benutzer entwickelten Produkts zu erfüllen. Benutzeranforderungen werden von Anfang an als richtig angesehen und in den gesamten Produktzyklus einbezogen. Diese Anforderungen werden durch Untersuchungsmethoden festgestellt und verfeinert, einschließlich: ethnografische Studie, Kontextanfrage, Prototyp -Test,, Usability-Tests und andere Methoden. Generative Methoden können auch verwendet werden, einschließlich: Kartensortierung, Affinitätsdiagrammung und partizipative Designsitzungen. Darüber hinaus können die Benutzeranforderungen durch sorgfältige Analyse von nutzbaren Produkten ähnlich wie das ausgelegte Produkt abgeleitet werden.

Benutzerzentriertes Design lässt sich von den folgenden Modellen inspirieren:

  • Kooperatives Design: Einbeziehung von Designern und Benutzern gleichberechtigt. Dies ist die skandinavische Tradition des Designs von IT -Artefakten, die sich seit 1970 weiterentwickelt.[8] Dies wird auch genannt Co-Design.
  • Partizipatives Design (PD), ein nordamerikanischer Begriff für dasselbe Konzept, inspiriert vom kooperativen Design, der sich auf die Teilnahme von Benutzern konzentriert. Seit 1990 gibt es eine zweijährige partizipative Designkonferenz.[9]
  • Kontextdesign, "kundenorientiertes Design" im tatsächlichen Kontext, einschließlich einiger Ideen aus partizipativem Design[10]

Hier sind die Prinzipien, die dazu beitragen, sicherzustellen, dass ein Design benutzerzentriert ist:[11]

  1. Das Design basiert auf einem expliziten Verständnis von Benutzern, Aufgaben und Umgebungen.
  2. Benutzer sind während des gesamten Designs und der Entwicklung beteiligt.[12]
  3. Das Design wird durch benutzerzentrierte Bewertung angetrieben und verfeinert.
  4. Prozess ist iterativ.
  5. Das Design befasst sich mit der gesamten Benutzererfahrung.
  6. Das Designteam umfasst multidisziplinäre Fähigkeiten und Perspektiven.

Benutzerzentrierter Entwurfsprozess

Das Ziel des benutzerzentrierten Designs ist es, Produkte mit sehr hoch zu erstellen Benutzerfreundlichkeit. Dies schließt ein, wie bequem das Produkt in Bezug auf die Verwendung, die Verwaltbarkeit, die Wirksamkeit und die Nutzung des Produkts den Benutzeranforderungen zugeordnet ist. Im Folgenden finden Sie die allgemeinen Phasen des benutzerzentrierten Entwurfsprozesses:[13][14]

  1. Geben Sie den Kontext der Verwendung an: Identifizieren Sie, wer die Hauptbenutzer des Produkts sind, warum sie das Produkt verwenden, welche Anforderungen sind und welche Umgebung sie es verwenden werden.
  2. Anforderungen angeben: Sobald der Kontext angegeben ist, ist es Zeit, die körnigen Anforderungen des Produkts zu ermitteln. Dies ist eine wichtige Phase, die die Designer weiter erleichtern kann, Storyboards zu erstellen und wichtige Ziele zu setzen, um das Produkt erfolgreich zu machen.
  3. Erstellen Sie Designlösungen und Entwicklung: Basierend auf Produktzielen und -anforderungen starten Sie eine iterativ Prozess des Produktdesigns und der Entwicklung.
  4. Produkt bewerten: Produktdesigner führen Usability-Tests durch, um das Feedback der Benutzer für das Produkt in jeder Phase des benutzerzentrierten Designs zu erhalten.

In den nächsten Schritten wird die obige Prozedur wiederholt, um das Produkt weiter zu beenden. Diese Phasen sind allgemeine Ansätze und Faktoren wie Designziele, Team und ihre Zeitleiste und Umgebung, in der das Produkt entwickelt wird, bestimmen die entsprechenden Phasen für ein Projekt und deren Auftrag. Sie können entweder a folgen Wasserfall-Modell, agil Modell oder irgendetwas anderes Softwareentwicklung trainieren.

Zweck

UCD stellt Fragen zu Fragen Benutzer und ihre Aufgaben und Ziele nutzen dann die Ergebnisse, um Entscheidungen über Entwicklung und Design zu treffen. UCD einer Website zum Beispiel versucht, die folgenden Fragen zu beantworten:

  • Wer sind die Benutzer der Website?
  • Was sind die Aufgaben und Ziele der Benutzer?
  • Was sind die Benutzer? Erfahrung Levels mit der Website und den ähnlichen Websites?
  • Welche Funktionen benötigen die Benutzer von der Website?
  • Was Information Könnten die Benutzer brauchen und in welcher Form brauchen sie es?
  • Wie denken Benutzer, dass die Website funktionieren sollte?
  • In welchen extremen Umgebungen, in denen die Website zugegriffen werden kann?
  • Ist der Benutzer Multitasking?
  • Verwendet die Schnittstelle verschiedene Eingabemodi wie Berührung, Sprache, Gesten oder Orientierung?

Elemente

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

Sichtweite

Sichtweite hilft dem Benutzer, a zu konstruieren mentales Modell des Dokuments. Modelle helfen dem Benutzer, die Auswirkungen seiner Aktionen bei der Verwendung des Dokuments vorherzusagen. Wichtige Elemente (wie diejenigen, die helfen Navigation) sollte nachdrücklich sein. Benutzer sollten in der Lage sein, auf einen Blick zu erkennen, was sie mit dem Dokument tun können und was nicht.

Barrierefreiheit

Benutzer sollten in der Lage sein, Informationen im gesamten Dokument schnell und einfach zu finden, unabhängig von ihrer Länge. Den Benutzer sollten verschiedene Möglichkeiten angeboten werden, Informationen zu finden (z. B. Navigationselemente, Suchfunktionen, Inhaltsverzeichnis,[15] klar beschriftete Abschnitte, Seitenzahlen, Farbkodierung, etc.). Navigationselemente sollten mit dem übereinstimmen Genre des Dokuments. "Chunking'ist eine nützliche Strategie, bei der Informationen in kleine Stücke zerlegt werden, die in irgendeine Art von sinnvoller Ordnung organisiert werden können oder Hierarchie. Die Fähigkeit zu überfliegen Mit dem Dokument können Benutzer ihre Informationen finden, indem sie eher scannen als lesen. Fett gedruckt und kursiv Wörter werden oft an dieses Ende verwendet.

Lesbarkeit

Der Text sollte leicht zu lesen sein: Durch Analyse der rhetorischen Situation sollte der Designer in der Lage sein, eine nützliche Schriftfamilie zu bestimmen und Schriftart Stil. Zierschriften, insgesamt Text Großbuchstaben, großer oder kleiner Körpertext kann schwer zu lesen sein und sollten vermieden werden. Textfarben und fett werden hilfreich sein, wenn sie in texthaarigen Szenarien verwendet werden. High Figur-Ground Kontrast Zwischen Text und Hintergrund erhöht die Lesbarkeit. Der dunkle Text vor einem hellen Hintergrund ist am lesbarsten.

Sprache

Abhängig von der rhetorischen Situation bestimmte Arten von Arten von Sprachen wird gebraucht. Kurze Sätze sind hilfreich und gut geschriebene Texte, die in Erklärungen und ähnlichen Massentextsituationen verwendet werden. Es sei denn, die Situation erfordert es, Jargon oder stark technische Begriffe sollten nicht verwendet werden. Viele Schriftsteller werden die verwenden, um die zu verwenden Aktive Stimme, Verben (Anstatt von Substantive oder Nominale) und eine einfache Satzstruktur.

Analysewerkzeuge

Es gibt eine Reihe von Tools, die bei der Analyse des benutzerzentrierten Designs hauptsächlich verwendet werden: Personas, Szenarien und wesentliche Anwendungsfälle.

Persona

Während des UCD -Prozesses a Persona Die Darstellung des Benutzers kann erstellt werden. EIN Persona ist ein Benutzerarchetyp, mit dem Entscheidungen über Produktfunktionen, Navigation, Interaktionen und sogar visuelles Design geleitet werden. In den meisten Fällen, Personas werden aus einer Reihe von synthetisiert ethnografisch Interviews mit echten Menschen, die dann in 1-2 Seitenbeschreibungen festgehalten werden, darunter Verhaltensmuster, Ziele, Fähigkeiten, Einstellungen und Umwelt, mit einigen fiktiven persönlichen Details, um die Persona zum Leben zu erwecken.[16]

Für jedes Produkt oder manchmal für jeden Satz von Werkzeugen innerhalb eines Produkts gibt es eine kleine Reihe von Personas, von denen einer der Hauptaugenmerk auf das Design steht. Es gibt auch eine sogenannte sekundäre Person, bei der der Charakter nicht das Hauptziel des Designs ist, aber ihre Bedürfnisse sollten erfüllt und nach Möglichkeit Probleme gelöst werden. Sie existieren, um weitere mögliche Probleme und Schwierigkeiten zu berücksichtigen, die auftreten können, obwohl die primäre Person mit ihrer Lösung zufrieden ist. Es gibt auch eine Anti-Person, die der Charakter ist, für den das Design spezifisch nicht hergestellt wird.

Personas sind nützlich in dem Sinne, dass sie ein gemeinsames gemeinsames Verständnis der Benutzergruppe schaffen, für die sich der Entwurfsprozess aufbaut. Außerdem helfen sie, die Entwurfsüberlegungen zu priorisieren, indem sie einen Kontext dessen bereitstellen, was der Benutzer benötigt und welche Funktionen einfach zu hinzufügen und haben. Sie können einer diversifizierten und verstreuten Benutzergruppe auch ein menschliches Gesicht und eine menschliche Existenz bieten und dazu beitragen, etwas Empathie zu schaffen und Emotionen hinzuzufügen, wenn sie sich auf die Benutzer beziehen. Da jedoch Personas eine generalisierte Wahrnehmung der primären Stakeholder -Gruppe aus gesammelten Daten darstellt, können die Merkmale zu breit und typisch oder zu viel von einem "durchschnittlichen Joe" sein. Manchmal können Personas auch stereotype Eigenschaften haben, was den gesamten Entwurfsprozess beeinträchtigen kann. Insgesamt können Personas ein nützliches Instrument sein, das von Designern verwendet werden kann, um fundierte Entwurfsentscheidungen zu treffen, die sich gegen eine Reihe von Daten oder eine breite Palette von Personen beziehen.

Personas kann auch über die UCD eines Produkts geändert werden, basierend auf Benutzertests und sich ändernden Umgebungen. Dies ist keine ideale Möglichkeit zu verwenden Personas sollte aber auch nicht ein Tabu sein, insbesondere wenn sich herausstellt, dass sich Variablen, die die Entwicklung eines Produkts umgeben Persona/s kann nicht gut auf die veränderten Bedingungen gerecht werden.

Szenario

A Szenario Erstellt im UCD -Prozess ist eine fiktive Geschichte über das "tägliche Leben" oder eine Folge von Ereignissen mit der primären Stakeholder -Gruppe als Hauptcharakter. Normalerweise wird eine Persona, die zuvor erstellt wurde, als Hauptfigur dieser Geschichte verwendet. Die Geschichte sollte spezifisch für die Ereignisse sein, die sich auf die Probleme der primären Stakeholder -Gruppe beziehen, und normalerweise die wichtigsten Forschungsfragen, auf denen der Entwurfsprozess aufgebaut ist. Diese mögen sich als einfache Geschichte über das tägliche Leben eines Einzelnen herausstellen, aber kleine Details aus den Ereignissen sollten Details über die Benutzer implizieren und möglicherweise emotionale oder physische Eigenschaften enthalten. Es kann das geben Best-Case-Szenario, wo alles für die Hauptfigur am besten funktioniert, die Worst-Case-Szenario, wo der Hauptcharakter alles erlebt, was um ihn oder sie um ihn herum schief geht, und eines Durchschnittliches Case-SzenarioDas ist das typische Leben des Individuums, wo nichts wirklich Besonderes oder wirklich deprimierendes auftritt und der Tag nur weitergeht.

Szenarien erzeugen einen sozialen Kontext, in dem die Personas existieren, und auch eine tatsächliche physische Welt, anstatt sich einen Charakter mit internen Eigenschaften aus gesammelten Daten und nichts anderes vorzustellen. Es gibt mehr Maßnahmen an der Existenz der Person. Ein Szenario wird auch von Menschen leichter verstanden, da es in Form einer Geschichte ist und leichter zu folgen ist. Wie bei den Personas sind diese Szenarien jedoch Annahmen des Forschers und Designers und werden auch aus einer Reihe 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 niedrige Aufgaben auftreten, zum Ausdruck des Denkprozesses einer Person vor dem Handeln.

Anwendungsfall

Kurz gesagt, a Anwendungsfall beschreibt die Wechselwirkung zwischen einem Individuum und dem Rest der Welt. Jeder Anwendungsfall beschreibt ein Ereignis, das für kurze Zeit im wirklichen Leben auftreten kann, aber aus komplizierten Details und Wechselwirkungen zwischen dem Schauspieler und der Welt bestehen kann. Es wird als eine Reihe einfacher Schritte dargestellt, damit der Charakter sein Ziel in Form eines Ursache und Effektschemas erreichen kann. Anwendungsfälle werden normalerweise in Form eines Diagramms mit zwei Spalten geschrieben: Erste Spalte mit der Bezeichnung Schauspieler, zweite Spalte mit der Bezeichnung Weltund die von jeder Seite aus ausgeführten Aktionen in den jeweiligen Spalten. Das Folgende ist ein Beispiel für einen Anwendungsfall, um einen Song auf einer Gitarre vor einem Publikum aufzuführen.

Schauspieler Welt
Wählen Sie Musik zum Spielen
Gitarre aufnehmen
Sodmusik anzeigen
Führen Sie jede Note auf Noten mit Gitarre durch
Übermitteln Sie die Notiz an das Publikum mit Ton
Das Publikum bietet Performer Feedback
Bewerten Sie die Leistung und passen Sie nach Bedarf anhand des Publikumsfeedbacks an
Komplette Lied mit erforderlichen Anpassungen
Applaus des Publikums

Die Interaktion zwischen Schauspieler und der Welt ist eine Handlung, die im Alltag gesehen werden kann, und wir nehmen sie als gewährt und denken nicht zu viel über die kleinen Details nach, die geschehen müssen, damit ein Handlung wie ein Musikstück auftritt existieren. Es ähnelt der Tatsache, dass wir beim Sprechen unserer Muttersprache nicht zu viel über Grammatik und darüber nachdenken, wie wir Wörter formulieren können; Sie kommen nur heraus, da 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 betrachtet werden, und daher werden Anwendungsfälle geschaffen, um zu verstehen, wie diese winzigen Interaktionen auftreten.

Ein wesentlicher Anwendungsfall ist eine spezielle Art von Anwendungsfall, auch als als bezeichnet abstrakter Anwendungsfall. Wesentliche Anwendungsfälle beschreiben die Essenz des Problems und befassen sich mit der Art des Problems selbst. Während des Schreibens wesentlicher Anwendungsfälle sollten keine Annahmen über nicht verwandte Details getroffen werden. Zusätzlich sollten die Ziele des Subjekts vom Prozess und der Umsetzung getrennt werden, um dieses bestimmte Ziel zu erreichen. Im Folgenden finden Sie ein Beispiel für einen wesentlichen Anwendungsfall mit dem gleichen Ziel wie das erstere Beispiel.

Schauspieler Welt
Wählen Sie Noten zum Aufführen
sammelt die notwendigen Ressourcen
Bietet Zugang zu Ressourcen
führt das Stück nacheinander aus
Leistung vermitteln und interpretieren
Bietet Feedback
Vervollständigt die Leistung

Anwendungsfälle sind nützlich, da sie dazu beitragen, nützliche Konstruktionsebene zu identifizieren. Sie ermöglichen den Designern, die tatsächlichen Prozesse mit niedriger Ebene zu sehen, die an einem bestimmten Problem beteiligt sind, was das Problem erleichtert, da bestimmte kleinere Schritte und Details, die der Benutzer ausführt, freigelegt werden. Die Aufgabe der Designer sollte darin bestehen, diese kleinen Probleme zu berücksichtigen, um zu einer endgültigen Lösung zu gelangen, die funktioniert. Eine andere Möglichkeit, dies zu sagen, ist, dass Anwendungsfälle komplizierte Aufgaben in kleinere Bits brechen, wo diese Bits nützliche Einheiten sind. Jedes Bit erledigt eine kleine Aufgabe, die sich dann bis zur endgültigen 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 zusammenzustellen, um den größeren komplizierteren Code zu beenden, anstatt den gesamten Code von Anfang an anzugehen.

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 das ist, das nicht funktioniert, während in der letzteren Lösung, die Der Programmierer muss möglicherweise den gesamten Code durchsuchen, um nach einem einzigen Fehler zu suchen, der 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 nun sehen kann, welche von höherer Bedeutung sind als andere. Einige Nachteile des Schreibens von Anwendungsfällen enthalten die Tatsache, dass jede Aktion vom Schauspieler oder der Welt aus wenig Details besteht und einfach eine kleine Aktion ist. Dies kann möglicherweise zu einer weiteren Vorstellungskraft und einer anderen Interpretation von Handlungen durch verschiedene Designer führen.

Außerdem ist es während des Prozesses sehr einfach, eine Aufgabe zu vereinfachen, da eine kleine Aufgabe, die aus einer größeren Aufgabe stammt, möglicherweise noch aus noch kleineren Aufgaben bestehen kann, die übersehen wurden. Wenn Sie eine Gitarre abholen, können Sie darüber nachdenken, welche Gitarre abholen soll, welche sie verwenden sollten, und überlegen Sie, wo sich die Gitarre zuerst befindet. Diese Aufgaben können dann in kleinere Aufgaben unterteilt werden, z. Aufgaben können weiter unten in noch winzigere Aufgaben aufgeteilt werden, und es liegt an dem Designer, zu bestimmen, an welchem ​​geeigneten Ort die Aufgabe der Aufgaben nicht mehr aufgeteilt werden müssen. Aufgaben dürfen nicht nur zu vereinfacht sind, sondern auch ganz weggelassen werden. Daher sollte der Designer alle Details und alle wichtigen Schritte bewusst sein, die an einem Ereignis oder einer Aktion beim Schreiben von Anwendungsfällen beteiligt sind.

Siehe auch

Verweise

  1. ^ "Cover - Fragen Sie einfach: Integration der Zugänglichkeit während des gesamten Designs". uiaccess.com.
  2. ^ a b "Anmerkungen zum benutzerzentrierten Designprozess (UCD)". www.w3.org.
  3. ^ Rubin, Jeffrey; Chisnell, Dana (10. März 2011). Handbuch für Usability -Tests: Planen, Entwerfen und Durchführung wirksamer Tests. John Wiley & Sons. ISBN 978-1-118-08040-5.
  4. ^ Vredenburg, Karel; Mao, ji-ye; Smith, Paul; Carey, Tom (2002). "Eine Umfrage zur benutzerzentrierten Designpraxis" (PDF).
  5. ^ Kling, Rob (1977). "Der organisatorische Kontext benutzerzentrierter Softwaredesigns". Mis vierteljährlich. 1 (4): 41–52. doi:10.2307/249021. ISSN 0276-7783. JStor 249021.
  6. ^ Norman, D. A. (1986). Benutzerzentriertes Systemdesign: Neue Perspektiven zur Human-Computer-Interaktion.
  7. ^ "Don Norman (2003) Emotionales Design, Prolog- drei Teekannen" (PDF). Jnd.org.
  8. ^ Greenbaum & Kyng (Hrsg.): Design bei der Arbeit - Kooperatives Design von Computersystemen, Lawrence Erlbaum 1991
  9. ^ Schuler & Namioka: Partizipatives Design, Lawrence Erlbaum 1993 und Kapitel 11 in Helanders Handbuch von HCI, Elsevier 1997
  10. ^ Beyer & Holtzblatt, Kontextdesign, Kaufmann 1998
  11. ^ "Benutzerzentrierte Design-Grundlagen". www.usability.gov.
  12. ^ Mathur, Sunita; Janaudis -Ferreira, Tania; Hemphill, Julia; Cafazzo, Joseph A.; Hart, Donna; Holdsworth, Sandra; Lovas, Mike; Wickerson, Lisa (23. September 2021). "Benutzernde Designmerkmale für digitale Gesundheitsanwendungen zur Unterstützung des Verhaltens der körperlichen Aktivität bei Empfängern mit festen Organtransplantaten: Eine qualitative Studie". Klinische Transplantation. doi:10.1111/ctr.14472. ISSN 0902-0063.
  13. ^ "Anmerkungen zum benutzerzentrierten Designprozess (UCD)". www.w3.org. Abgerufen 30. März, 2017.
  14. ^ "Benutzerzentrierte Design-Grundlagen". www.usability.gov. Abgerufen 30. März, 2017.
  15. ^ Aaron., Scharf (1976). Ein neuer Anfang: Primitivismus und Wissenschaft in der postimpressionistischen Kunst; [und] zur Natur zurückkehren. Offene Universität. ISBN 0-335-05151-0. OCLC 1086245904.
  16. ^ "Perfektionieren Sie Ihre OurFrankline | Cooper Journal". www.cooper.com. Abgerufen 6 Januar, 2016.

Weitere Lektüre

Video