Willemers Informatik Ecke: Interface-Design User centred design

Die Ursache für "menschliches Versagen" (Human Error) hatte oft mit einem schlechtem Interface zu tun.

Im Zentrum stehen die Bedürfnisse der Benutzers, die das Produkt benutzen. Diese müssen zunächst ermittelt werden. Der zentrale Gedanke ist: Der Benutzer weiß am besten, was er braucht.

Die Menschen in den Vordergrund stellen

Das Interface-Design ist erst etwa 1980 in die Software-Entwicklung eingeflossen, da zuvor die Benutzer oft die Programmierer waren. Nur Experten haben Computer bedient. Heutzutage muss der Experte für den normalen Anwender programmieren, der einen Computer nicht programmieren kann.

Der Designer muss herausfinden, was die Benutzer brauchen. Der Designer ist niemals der Benutzer. Er wird niemals so naiv auf das Problem einstellen können, wenn er erst einmal gestaltet hat.

Anwender wissen es am besten, welche Bedürfnisse sie haben, welche Ziele und welche Vorlieben.
Es ist Sache des Designers, diese Dinge herauszufinden.
Designer, wie wohlmeinend sie auch sein mögen, sind keine Anwender.
Die Rolle des Designers besteht darin, die Ziele des Anwenders zu erreichen.
Dazu muss er den Anwender partizipieren lassen.

Ein neuer Begriff ist die UX, die User Experience, schlecht übersetzt auch die „Benutzererfahrung“ oder „Benutzererlebnis“.

Kreislauf

Der Einstieg besteht in der Erkennung des eigentlichen Problems (oder wie man neudeutsch sagt: Herausforderung).

Problem führt zu 2.Kontext
Kontext führt zu 3.Anforderungen
Anforderungen (Requirements) führt zu 4.Design
Design führt zu 5.Evaluation
Evaluation führt idealerweise zu 6.Lösung,
kann aber auch zu 3.neuen Anforderungen oder
4.verbessertem Design führen.
Lösung

Stakeholder

Wer hat einen Anteil an dem Produkt.

Regelmäßige Benutzer
Selten benutzen:
Wird durch die Nutzung beeinflusst: Der Einkäufer des Produkts

Aber: Sie müssen den Einkäufer überzeugen, nicht den Benutzer.

Der Vorgang

Im Zyklus:
- Concept
- Design
- Implementation
- Diese drei Schritte müssen im Dialog mit dem Anwender laufen.
- Im Zentrum des Zyklus die Evaluation
Abgang: Der Launch

Der Kontext

Der Kontext beschreibt die Umgebung, in der die Anwendung ihren Einsatz findet. Dazu gehört:

Time: Gibt es zeitliche Randbedinungen?
Sourrounding: Wird die Anwendung in Ruhe auf dem Sofa oder in der lauten und hektischen Umgebung einer Bahn verwendet.
Location: An welchem Ort?
Mood: Welche Stimmung hat der Benutzer? Ist er beispielsweise entspannt oder in Eile?
Tasks

Es ist nahezu unmöglich, eine Anwendung zu entwickeln, die auf jeden Kontext passt. Darum ist es wichtig, den Kontext zu ermitteln bzw. festzustellen. Das Produkt muss aber in den Gesamtkontext um die Anwendung herum eingebettet werden.

Analyse

Die Ziele sind am Anfang vage und führen zu einer Prototyp-basierten Entwicklung. Auf die Frage nach der Anwendungsumgebung, dem Kontext, erhält man unterschiedliche Antworten, je nachdem, wen man fragt.

Das liegt daran, dass der Kontext nicht immer sachlich exakt zu erfassen ist. So beschreibt beispielsweise beim Essen gehen die Funktionalität nicht die Erfahrung von Essen gehen.

Dieses Erfahrungserlebnis wird im Zusammenhang mit Anwendungen als User Experience (UX) bezeichnet.

Betroffene

Der Begriff Stakeholder bezeichnet diejenigen, die einen Anteil an dem Produkt haben. Einfluss haben und müssen im Einzelnen betrachtet werden:

Regelmäßige Benutzer
Leute, die das System eher selten benutzen.
Der Einkäufer des Produkts

Das Produkt richtet sich zwar in erster Linie an den regelmäßigen Benutzer, aber Sie müssen den Einkäufer überzeugen, um das Produkt erstellen zu können.

Anforderungen (Requirements)

Die Anforderungen müssen genau bestimmt werden. Dabei darf es keine Schwammigkeiten geben.
Im Team werden die Nutzerziele bestimmt. Die klare Definition und Verfolgung der eigentlich Anforderungen ist wichtig, da zu viel Featuritis den Anwender oft mehr verwirrt als im hilft.
Auch wenn der Anwender im Zentrum steht, muss man berücksichtigen, dass der Anwender vielleicht nicht alle Möglichkeiten kennt. Henry Ford sagt, dass die Anwender nicht unbedingt darauf gekommen wären, dass sie ein Auto brauchen: „They would demand a faster horse“.

Discover (why)
Envision (what)
Elaborate (how)
Develop (do)
Evolve (improve)

Design

Die Hauptaufgabe des Designs ist die Erstellung eines Prototyps, idealerweise im Dialog mit dem Benutzer.

Man beginnt damit, Fragen zu stellen:

Was ist die Hauptaufgabe (main task)?
In welche Unteraufgaben zerfällt die Hauptaufgabe (sub tasks)?
Welche anderen Fähigkeiten sollte die Lösung haben (other features)?
Mit welcher Art von Informationen arbeitet die Lösung (types of information)?
In welcher Art interagiert der Anwender mit diesen Informationen (user interact with information)?

Um zu einem Ergebnis zu kommen, wird iterativ entworfen. Das Design sollte möglichst konkret werden, um nicht ewig Meinungen zu diskutieren. Dabei helfen folgende Tools:

Flow-Chart
Papier-Interface-Prototypen (Rapid Prototyping)
Wireframes für Anordnung und Entwurf.

Es gibt das bekannte 80/20 Prinzip. Danach kann man mit 20% Aufwand 80% des Ergebnisses erzielen.

Dennoch gilt: The first draft of everything is shit.

Evaluation

Der Designer beherrscht seine Software. Aber der Benutzer sieht das anders, weil er dieses Problem bisher nie hatte. Darum muss sich die typische Richtung umdrehen: Experten fragen - Benutzer antworten.

Literatur: Henry Dreyfuss: Designing for People 1955