Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03656.jsonl.gz/2114

Bevor Du diesen Artikel liest, solltest du auch den Teil 1: Der Zauber hinter gutem Design, lesen, und danach zu diesem Artikel zurück kehren.
Human-Centered Design
Human-Centered Designer stellen den Menschen in den Mittelpunkt: Was will der Anwender, wie benutzt er das System, wie kommuniziert er mit ihm, welche Funktionen wünscht er sich. Sie fokussieren sich auf Momente, in denen etwas schief läuft: Die grösste Genugtun kommt dem Benutzer dann, wenn der Benutzer den Fehler der Software versteht und eine gute Lösungsmethode vorgeschlagen bekommt.
Human-Centered Designer nehmen ihre Kenntnisse hauptsächlich durch Beobachtungen, schnelltest von Ideen und stetige Verbesserung des Designs sowie Überdenkung des Userproblems.
Discoverability
Wie findet man heraus, wie man etwas handhaben und benutzen muss, dass man noch nie zuvor gesehen hat? Auf der Basis von Erfahrungen und dem Wissen über die Welt zieht man Schlüsse und wendet sie auf das Objekt an. Hinweise darüber, in welche Richtung die Gedanken gehen müssen liefert das Objekt selber via den 6 Physischen Konzepten.
Discoverability beruht auf Affordances, Signifiers, Constraints, Mappings, Feedback und Conceptual mode.
Affordances
Eine Affordane bezieht sich auf die Beziehung zwischen dem Objekt und dem Benutzer, genauer auf die Beschaffenheit des Objektes und die Möglichkeiten des Benutzers, herauszufinden wie das Objekt genutzt werden sollte. Affordance hängt also sowohl vom Objekt wie auch vom Nutzer ab. Gute Objekte haben klare Affordances, optimale Benutzer klare Interaktionsvorstellungen. Affordances müssen wahrgenommen werden können um effektiv zu sein, sie brauchen also Signifiers um zu bestimmen, wo eine Affordance anzutreffen ist. Hat ein Produkt klare Affordances ist es Usefull, denn die Affordances geben Informationen darüber, was man tun kann, nicht was man tun sollte!
Signifiers
Signifier sind die Teile des Objektes, die dem Benutzer sagen, was er tun kann. Signifier sind also Komponenten der Affordances. Signifier sind physisch wahrnehmbar und kommunizieren, wie das Objekt verwendet werden kann. Sie können vom Objekt selber designt sein oder indirekt auftreten wie z.B. Menschen die auf den Zug warten. Simple Affordances sollten keine Signifier brauchen und selbsterklärend sein. Signifiers können Problem verursachen, wenn sie falsche Affordances implizieren.
Sound
Sound kann Informationen kompakt und unstörend übermitteln. Viele Geräte nutzen Sound nur beschränkt als Signifier wie Beep Sounds bei faschen Aktionen. Sounds könnten aber auch tiefer gehen und dem Nutzer stetige Rückmeldung über Vorgänge und Aktionen geben. Der Vorteil von Sound ist, dass er den Nutzer nicht vom Display ablenkt und als weitere Informationsquelle parallel dienen kann. Jedoch kann künstlich erzeugter Sound auch sehr leicht nerven und stören. Gute Verwendung für Sound in Design macht das Telefon das Rückmeldungen darüber gibt, ob die Verbindung bereits zustande gekommen ist.
Constraints
Constraints limitieren die möglichen Aktionen und sagen so, welche Aktionen richtig und welche falsch sind. Es gibt verschiedene Constraints die alle zur Folge haben, dass der Benutzer schnell merkt, was für Aktionen nicht Vorteilhaft oder erlaubt sind. Es gibt physikalische, kulturelle, semantische, logische und normierte Constraints.
Meistens sind Constraints störend und limitierend für den Nutzer, weswegen sie oft entfernt werden. Gutes Design schafft unbewusste constraints ohne den Nutzen zu stören oder zu verärgern.
Physical Constraints
Physical Constraints machen falsche Aktionen einfach unmöglich, wie z.B. einen USB-Stick falsch herum einzustecken. Physikalische Constraints sind nur nützlich wenn sie klar zu erkennen sind und der Benutzer sie bemerkt, bevor er in sie hinein läuft.
Physical constraints sollten wenn immer vermieden werden, da sie den Benutzer in ein System zwengen, welches vom Design vorgegeben ist. Das Produkt sollte um designt werden, sodass falsche Aktionen gar nicht erst möglich sind.
Forcing Functions
Forcing functions sind physikalische Einschränkungen bei welchen ein Fehler weitere Folgefehler verhindert. Dadurch können Forcing-Functions unerwünschte Aktionen und falsches Handeln verhindern. Die wichtigsten Forcing-Functions sind Interlocks, Lock-Ins und Lock-Outs.
Lock-In / Lock-Outs
Lock-Ins wollen, dass der Nutzer mit seiner Handlung fortfährt ohne sie zu unterbrechen. Lock-outs machen genau das Gegenteil: Sie wollen den Nutzer von einer bestimmten Aktion ausschliessen. Lockouts werden meist aus Sicherheitsgründe eingebaut um Nutzer von ungewollten oder gefährlichen Handlungen abzuhalten.
Interlocks / Dead man Switches
Interlocks stellen sicher, dass eine Sequenz von Aktionen in der richtigen Reihenfolge ausgeführt wird. Der Dead-Man Switch ist ein typisches Beispiel dafür: Solange eine Operation ausgeführt wird, muss ein Switch bedient werden der die Ausführung erlaubt. Verliert der Benutzer die Kontrolle und lässt den Switch los, wird das System den ganzen Prozess sofort unterbrechen.
Cultural
Cultural Constraints sind nicht erlaubte Handlungen und Situationen in einer Kultur. In der eigenen Kultur weiss man, wie man sich verhalten soll, auch wenn die Situation neu ist. In fremden Kulturen ist das schwierig, weshalb das Design in Betracht ziehen, dass unterschiedliche Kulturen Symbole und Aktionen anders interpretieren können. Typisch dafür sind Verkehrsschilder, die vor der Standardisierung in jedem Land anders ausgesehen haben.
Semantic
Semantic Constraints beruhen auf dem gesunden Menschenverstand: Wenn etwas einfach unlogisch oder dumm ist, darf man davon ausgehen dass der wahre Sinn des Produktes erkannt wird und eine adäquate Handlung getroffen wird.
Logical
Wenn einfach keine andere Möglichkeit existiert, etwas zu handhaben, spricht man von logical constraints. Wenn man ein Gestell zusammenbaut und ein grosses Stück Holz übrigbleibt, hat man offensichtlich etwas falsch gemacht.
Mapping
Mapping möchte folgendes Problem lösen: Welche Schalter / Switches / Controller steuern welche Teile des Produktes? Was gehört zu was?
Activity-Centered Controll
Mit einer genauen Analyse des Produktes und des Benutzers kann festgestellt werden, welche Mappings von Kontrolleinheiten effektiv sind. So kann man entweder die zusammen benutzten Kontrolleinheiten nahe zusammen fügen (Fitt’s Law) oder sie bündeln: Für den einen Zweck werden automatisch diese Einstellungen vorgenommen, für den anderen Zweck automatisch andere. So passt sich die Aktion des Systems automatisch an den Benutzerwunsch an.
Standardisierung
Standardisierung macht das Leben für alle einfacher: Wenn alle das gleich simple Design haben, lernt man die Funktionen einmal und wendet sie auf alle anderen ebenfalls an.
Fehleranalyse
Merkt man, das ein Design nicht funktioniert, muss man der Ursache des Designfehlers auf die Sprünge gehen.
Root-Cause Analysis
Man untersucht den Fehler solange, bis das ursprüngliche Problem gefunden ist. Erstens gibt es meistens mehrere Auslöser die zusammen spielten, wieso ein Fehler auftrat. Zweitens sollte eine Fehleranalyse nicht stoppen, wenn auf ein Human-Error gestossen wurde, sondern noch tiefer nach dem Error suchen: Was führte zu dem Fehler?
Five-Why Analyse
Man stoppt nicht, wenn man den Fehler gefunden hat, man sucht weiter nach entweder anderen Fehlern oder tieferen Ursachen für den Fehler. Man stellt sich fortgehend die Frage, wieso etwas passierte, bis man dem basischen Problem auf den Grund gegangen ist. Man sollte versuchen, mindestens fünf Mal hintereinander „Why“ zu fragen um das Problem tief zu verstehen.
Das System sollte so verändert werden, dass der Error limitiert oder eliminiert wird. Ist das nicht möglich sollte man das Design so anpassen, dass der Error hervorgehoben oder verhindert wird.
Zuerst ist es aber wichtig, den Mitarbeiter klar zu machen, dass sie nicht für alle Fehler verantwortlich sind. Wenn man sozialen Druck nimmt und das Problem anspricht, kann es besser und effizienter gelöst werden.