User - Interface - Design E-Book

Alexander Florin

• Herausgeber: Books on Demand
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2015

Seitenzahl: 549

Beschreibung

Projekte für Webseiten oder Software fordern heute neben dem bloßen Funktionieren auch eine einfache Bedienung. Was „einfach“ oder „intuitiv“ ist, hängt dabei von der Nutzungssituation und der Zielgruppe ab. Usability wird nicht am Ende eines Projektes auf eine Webseite oder Software aufgetragen – Usability kann nur gelingen, wenn sie in allen Projektphasen und von allen Beteiligten ernstgenommen wird. Das Buch „User – Interface – Design“ beschreibt nicht nur die Ansprüche an eine gute Nutzer-Schnittstelle, sondern bietet einen Überblick und Einstieg in alle Aspekte des Interface-Design: von Geschichte über Design-Grundlagen und Standard-Elemente bis zu ISO- und DIN-Normen. Ein umfangreiches Glossar erläutert die Fachbegriffe, und zahlreiche Checklisten unterstützen bei der Umsetzung im Alltag.

Leseprobe

Technisches

Dieser Text wurde mit LATEX (www.tug.org/mactex) unter Verwendung eines Koma-Scripts (www.komascript.de) (mit eigenen Anpassungen) gesetzt.

Verwendete Firmen- und Produktbezeichnungen sind zugunsten der Inhaber als (eingetragene) Warenzeichen geschützt. Durch die Verwendung mache ich sie mir nicht zu eigen. Ich stehe zu keiner der genannten Firmen in einer wirtschaftlichen Verbindung – lediglich als Kunde von Produkten.

Danke

Dieses Buch hat für mich kompilatorischen Charakter. Viele Themen werden angerissen und vorgestellt, um die Breite des Themas zu veranschaulichen und Anregungen für die vertiefende Beschäftigung zu geben. Etwas tiefer und anschaulicher sind die Passagen zu praktischen Aspekten der Umsetzung in HTML oder zur Integration in den Projekt- und Arbeitsalltag geraten.

Dass mir dieses Buch gelingen konnte, ist zahlreichen Personen zu verdanken.

Hartmut und Kosta gaben mir ihr Vertrauen und den Freiraum, die Themen zu erkunden und praktisch anzuwenden. Unbewusst verschafften sie mir (indirekt) sehr viel Anschauungs- und Lernmaterial.

Kevin, Thomas, Sven und Dirk erhellten in zahlreichen Debatten vor allem Umsetzungsfragen und haben sich auf das eine oder andere Experiment eingelassen. Zahlreiche Kolleginnen und Kollegen der vergangenen Jahre haben durch Widerspruch, Anregungen und gemeinsame Projekte Gedanken mitentwickelt oder deren Entstehen maßgeblich befördert. Deren wohlmeinende Reibefläche und Kooperation ist ein nie versiegender Quell.

Martin weckte vor über zehn Jahren durch eine unbedachte Äußerung mein Interesse am Gebiet der Usability. Volkmar und sein Team ebneten mir in zahlreichen Projekten und kreativen Diskussionen den Einstieg und legten wichtige Grundlagen. Florian und Sebastian gaben mir die Möglichkeit, vor allem im Printbereich meine Projekterfahrungen zu vertiefen und zu erweitern und mit meinem damaligen Kollaborateur Stephan das Thema Usability auf Papier auszuleben – auch wenn wir uns alle dessen oft nicht bewusst waren. Gemeinsame Online-Ausflüge ließen uns weiter reifen.

Zahlreiche Menschen teilen ihr Wissen freigiebig mit anderen: in Büchern, Web-Artikeln oder Forenbeiträgen. Als Autoren sind – zusätzlich zu den an den jeweiligen Stellen benannten – vor allem Steven Johnson (beginnend mit seinem Buch „Interface Culture“) und Daniel Eran Dilger (und seine Analysen auf RoughlyDrafted.com und AppleInsider.com) eine stete Inspiration. Auch Jakob Nielsen und sein Team liefern kontinuierlich wertvolle Hinweise zum weiten Feld der Usability.

Christiane wühlte sich als Fachfremde durch die vielen Seiten, und ihre konstruktiven Hinweise taten dem Text insgesamt sehr gut.

Sascha ermöglichte durch enormes Verständnis und mitunter argen Zeitverzicht es überhaupt erst, dass ich dieses Buchprojekt trotz ungewissen Ausgangs angehen und über viele Monate betreiben konnte.

All diesen und den vielen ungenannten Menschen gebührt mein Dank.

Alexander Florin. Berlin, Mai 2015

Inhaltsverzeichnis

1Häufige Fragen

2Einstimmung

Usability

Der Nutzer im Zentrum

3Unsere Nutzer

Eine nützliche Software

User-Steckbriefe

Novizen und Experten

Weitere Nutzergruppen

Erfassen, was Nutzer wollen

Checkliste: Erfassen, was Nutzer wollen

Checkliste: Für die Nutzer

4Unsere Computer

Eine kurze Geschichte des User-Interface

Drei Phasen der Entwicklung

Checkliste: Computer

5Ziele und Aktionen

Die Sieben Stufen der Aktion

Meine Ziele

Vereinfachtes Aktionsmodell

Klarheit in der Darstellung

Vier-Ebenen-Modell

GOMS-Modell

Widget-Level

Object/Action-Interface

Checkliste: Ein Modell für mein Projekt

6Ordnung auf dem Bildschirm

Die Grenzen des Bildschirms

Die Mitte im Zentrum

Der menschliche Blick

Präsentation der Informationen

Funktionale und optische Strukturen

Checkliste: Ordnung schaffen

7Design-Nussschale

Visuelle Variablen

Position und Größe

Farbe, Helligkeit und Textur

Neigung, Form und Gestalt

Schrift

Icons und Symbole

Technische Design-Hinweise

8Standardelemente

Funktionselemente

Checkliste: Funktionselemente

Strukturelemente

Checkliste: Strukturelemente

Informationselemente

Suchen und Finden

9Das eigene Interface

Start-up-Modell

Qualitätsanspruch

Checkliste für die Anforderungsaufnahme

Mein Recht auf Usability

Usability testen

10Ganzheitlicher Ansatz

11Glossar &Index

1Häufige Fragen

Wer die Antworten bereits meint zu kennen, findet in diesem Buch unterstützende Argumente oder Hinweise. Was er oder sie jedoch kaum finden wird, sind endgültige Weisheiten, wie in einer bestimmten Situation die perfekte Lösung aussieht. Erstens gibt es keine perfekte Lösung, nur besser oder weniger geeignete. Zweitens handelt es sich bei Usability nicht um eine Rezeptsammlung, der man nur zu folgen braucht. Usability ist vielmehr das Verständnis, wie der Geschmacksapparat funktioniert, welche Servier- und Speise-Konventionen bestehen, welche Zutaten und Küchenwerkzeuge zur Verfügung stehen – aus diesen wird ein dem Anlass entsprechendes Mahl zubereitet und würdig serviert.

Die häufigen Fragen werden meist von denen gestellt, die sich bislang nicht eingehender mit Usability beschäftigt haben. Für diese ist Usability meist entweder ein Kostenfaktor oder ein Teil der Umsatzoptimierungsstrategie. Wie alle gern verwendeten Schlagwörter verliert der Begriff „Usability“ zunehmend an Schärfe und Präzision – er wird schlichtweg für alles verwendet, was irgendwie mit der Bedienung von Webseiten oder Software zu tun hat. Für unsere Zwecke verstehen wir das Kunstwort „Usability“ als Mischung aus Gebrauchstauglichkeit, Anwenderfreundlichkeit und einfacher Bedienung.

Wer sollte dieses Buch lesen?

Alle Personen, die Webseiten oder Software betreiben, verantworten, entwickeln, planen, bewerben, konzipieren, umsetzen, testen oder einfach nur einige Zusammenhänge besser verstehen wollen:

Unternehmer, Leiter: die tatsächlichen Nutzer-Interessen verstehen

Projektmanagement: Usability in Planung und Projektalltag integrieren

Anforderungserfassung: Nutzer verstehen und geeignete Dokumente erstellen

Umsetzung: technische Anforderungen berücksichtigen, Design-Grundlagen und Bedienkonzepte kennen, verfügbare Elemente und Werkzeuge anwenden

Marketing: als Schnittstelle zwischen Entwicklern und Nutzern passendes Erwartungsmanagement betreiben

Gelegentlich erweiteren theoretische oder historische Ausflüge die Perspektive und inspirieren zu anderen Denkbahnen. Als Schnelleinstieg oder zum Nachschlagen dient das Glossar am Buchende, das die häufigsten Begriffe und Konzepte kurz erläutert. Viele Kapitel bzw. Unterkapitel werden durch Checklisten beschlossen. Diese unterstützen bei Entscheidungen und fassen die für die Praxis wichtigsten Punkte zusammen.

Wie beim Lernen eines Instruments benötigt es jedoch mehr als nur die richtige Lektüre. Für gutes Spielen sind mindestens 2.000 Übungsstunden nötig; wer auf Profi-Niveau spielen will, benötigt etwa 10.000 Stunden. Gleichermaßen ist für Usability-Experten die praktische Erfahrung entscheidend, Bücher (wie dieses) können allenfalls Anregegungen und Hilfestellung bieten.

Entscheidend ist vor allem, dass Usability nicht als Einzeldisziplin begriffen wird, sondern gut in alle Prozesse integriert ist. Wie beim Qualitätsmanagement oder Controlling kann der Erfolg nur interdisziplinär entstehen. Oft bedarf es einer Person oder kleinen Personengruppe, bei der die Fäden koordiniert zusammenlaufen – aber ohne die gute und kontinuierliche Zusammenarbeit mit anderen Unternehmensbereichen oder Projektbeteiligten verpufft der Effekt oder bleibt kosmetische Fassade. Für solche Usability-Verantwortlichen und alle Personen, die mit diesen zusammenarbeiten, ist dieses Buch gedacht und soll eine gemeinsame Grundlage bilden. Auf dieser aufbauend entwickeln die Personen dann gemeinsam ihre Lösungen für ihre Nutzer.

Wann mit Usability anfangen?

So früh wie möglich. Usability ist nicht der Zuckerguss, der am Ende drübergegossen wird, sondern das Mehl, das alles gut zusammenhält. Auch alle Funktionen und technischen Aspekte haben Auswirkungen auf die Bedienbarkeit. Die Belange der Nutzer bereits am Anfang zu berücksichtigen, zahlt sich insgesamt aus, denn diese bezahlen mit ihrem Geld, ihrer Aufmerksamkeit oder ihrer Anerkennung.

So wie zu einem erfolgreichen Auftritt mehr gehört als die richtige Kleidung – eben auch die korrekten Umgangsformen, Körperhaltung und sprachlichen Codes –, so gehört zu einer guten Software die Usability essenziell dazu. Sonst erhält man den „Proll im Anzug“ oder den „Ritter im Penner-Look“, und beide bieten keinen guten Gesamteindruck.

Was kostet Usability?

Usability kostet nichts extra, wenn sie von Anfang an einbezogen wird. Gute Usability kann die Summe aller entstehenden Kosten über den gesamten Life-Cycle einer Software oder Webseite verringern. Vor allem nachgelagerte Aufwände – oft versteckte und gern ignorierte Kostenverursacher – sinken beträchtlich. Mittel- und langfristig entstehen Einsparungen:

Der interne Schulungs- und externe Beratungsaufwand sinken. Wissen kann von einer Software oder Webseite auf eine andere übertragen werden und muss nicht für jede Anwendung separat erlernt werden.

Die Performanz der Anwender steigt. Sie werden rascher zu Experten, können schneller arbeiten und dadurch mehr schaffen.

Die Nutzer machen weniger Fehler, und es werden weniger Ressourcen für die Fehlerbehandlung benötigt.

Außerdem steigt die Nutzerzufriedenheit. Das Produkt bietet wenig Frustanlässe und hat eine hohe Empfehlungswahrscheinlichkeit.

Die praktische Erfahrung bestätigt, dass eine gute Planungsstunde zehn schlechte Reparatur-, Schulungs- oder Entwicklungsstunden spart. Das Thema Usability kann einen guten „Vorwand“ bieten, um bereits in der Konzeptionsoder Planungsphase kostenintensive Nutzerprobleme zu identifizieren und zu vermeiden.

Jede realistische Projektkalkulation berücksichtigt die voraussichtlichen direkten und indirekten Gesamtkosten für die gesamte Lebensdauer: Schulung, Wartung, Nachbesserung, Pflege, Erweiterung, Änderungen, verbaute Wege. Als Richtwert können drei Jahre dienen.

Was sind die schlimmsten Ressourcenfresser?

Häufig entstehen sogenannte technische Schulden in diesen Bereichen:

Vernachlässigen von Dokumentation

Verzicht auf Versionsverwaltung, Datensicherung, Kontinuierliche Integration

Nachlässiges Testen

Keine Coding-Standards

Folgen von Anti-Mustern, Anti-Pattern

Missachtung von Warnungen der Werkzeuge (Compiler, Code-Analyse)

Furcht vor der Korrektur von zu großem oder zu komplexem Code

Was in dem jeweiligen Moment Zeit und Ressourcen spart, muss durch zusätzliche Ressourcen in der Zukunft ausgeglichen werden. Ständig muss eigentlich fertige Software korrigiert, angepasst oder erweitert werden. Änderungen sind aufwändig, weil die ursprüngliche Lösung nur auf einen unflexibel-konkreten Fall zugeschnitten wurde. Fehler werden erst im Produktivbetrieb erkannt. Jede Nachbesserung beinhaltet die Folgekosten des erneuten Bereitstellens und Aktualisierens; auch wenn diese Prozesse stark automatisiert ablaufen können, so sind sie dennoch nicht umsonst zu haben. Der Entwickler selber versteht seinen Code nach einigen Monaten bereits selbst kaum noch und benötigt lange, um dessen Funktionsweise nachzuvollziehen und eine Änderung vorzunehmen. Die Auswirkungen auf andere Code-Teile errät er dabei. Ist es nicht sein eigener Code, ist die Wartung ohne Coding-Standards für ihn unanständig aufwändig.

Die Problemliste, die Wikipedia bei „Anti-Pattern“ auflistet, bietet viele Anregungen, was es zu vermeiden gilt.

So lassen sich durch besseres Arbeiten an aktuellen Projekten deren technische Schulden in der Zukunft reduzieren, was Ressourcen freisetzt.

Wieso genügen Hilfe, Anleitung nicht?

Weil niemand liest. Vor allem die Nutzer nicht. Hand aufs Herz: Wie viele ungelesene Bedienungsanleitungen liegen bei Ihnen zuhause? Bei Ihren Kollegen? Dennoch ist eine gute Anleitung bzw. Dokumentation unverzichtbar; denn einige Nutzer benötigen diese. Die Nutzerdokumentation muss dem aktuellen Stand der Software oder Webseite entsprechen. Wird sie parallel erstellt, hat das oft positive Auswirkungen auf die Konzeption, da durch die Textform einige Aspekte auffallen, die sonst übersehen werden.

Für die Dokumentation ist eine geeignete Struktur zu wählen, und auch für die Dokumentation gilt der Usability-Anspruch: gut verständlich, leicht zu nutzen, passend zu den Nutzerzielen strukturiert. Für Webseiten bieten sich häufig die sogenannten FAQ an. Diese „Frequently Asked Questions“ (Häufigen Fragen) beantworten Fragen, die sich die Nutzer stellen oder stellen könnten. Das Format ist etabliert, und wenn es gut angewendet wird, stellt es einen wirklichen Mehrwert dar. Ein Webshop sollte sich beispielsweise folgende Fragen stellen:

Wie finde ich das geeignete Produkt?

Wie bestelle ich? Wie läuft eine Bestellung ab?

Welche Zahlungsoptionen gibt es?

Wie kann ich reklamieren oder umtauschen?

Über solche und ähnliche Fragen lässt sich auch ein komplexer Webshop gut dokumentieren. Die Antworten beschränken sich dabei jeweils auf die konkrete Frage, unterstützend sind sie untereinander verlinkt. Die ideale Antwort besteht aus einem Satz, der die Frage kurz und bündig beantwortet. Dies ist oft nicht möglich, daher gibt der erste Absatz eine allgemeine Antwort, und weitere Absätze beschreiben Details oder geben ergänzende Hinweise.

Für Software ist der sehr ähnliche „Wie tue ich“-Ansatz geeignet. Dabei werden die Aufgaben aus Nutzerperspektive benannt und anschließend die nötigen Schritte in der korrekten Reihenfolge beschrieben (und durch Screenshots illustriert): „Bild einfügen“ [die Aufgabe des Nutzers]

Auf diese Weise wird jede Funktion (ausgehend von der Nutzeraufgabe) auf ein bis maximal zwei Seiten beschrieben.

Zur Software-Dokumentation gehört noch mindestens ein Kapitel, das die Elemente und deren Grundbedienung sowie das Bedienparadigma vorstellt. Auch wenn viele Nutzer die Dokumentation nicht lesen, wissen sie doch, dass sie da ist. Bereits ihr Vorhandensein und die Möglichkeit, im Bedarfsfall auf sie zugreifen zu können, erhöhen das Sicherheitsgefühl erheblich. Dazu wird sie an geeigneten Stellen im Programm integriert und der Aufruf sowie die Recherche darin sind einfach möglich. Ergänzend ist an möglichst vielen Stellen die entsprechende Hilfe-Seite aufrufbar (oft als „?“-Icon). Auch Kurztexte in der Oberfläche verlinken für detaillierte Informationen auf entsprechende Hilfe-Seiten.

Wie unterscheiden sich Design und Usability?

Die beiden Begriffe werden gern synonym verwendet, wie auch von Steve Jobs: „Design ist nicht nur, wie es aussieht oder sich anfühlt. Design ist, wie es funktioniert.“ Im praktischen Alltag bietet sich eine Trennung an: Design ist das konkrete Aussehen, Usability umfasst alle Aspekte der Bedienung, auch die abstrakten, esoterischen, metaphorischen oder prozessuralen.

Das Design beschreibt bei Software und Webseiten „lediglich“ die Optik. Die Usability dagegen gibt an, wie gut etwas benutzbar ist, damit ist sie ein funktionales Kriterium, das nicht von persönlichem Geschmack abhängig ist. Die Usability lässt sich messen (z.B. als benötigte Zeit, die für eine Aufgabe benötigt wird).

Das Design ist der sichtbarste Aspekt der Usability, doch besitzen auch viele Programme und Webseiten ohne aufwändige Gestaltung eine hohe Usability. Zugespitzt lässt sich formulieren: „Je schicker, desto schlechter benutzbar“. Nutzern fällt es in Designexzessen schwer, das gewünschte Bedienelement schnell zu finden, oder die Gestaltung verstellt den Blick auf die Funktionalität. Der Umkehrschluss gilt übrigens nicht, eine hässliche Webseite oder Software besitzt nur selten eine gute Usability – dieser Eindruck entsteht auch dadurch, dass schlecht bedienbare Webseiten und Programme schneller als hässlich wahrgenommen werden als gut bedienbare.

Wenn sich der Designer an das FFF-Credo („Form follows function“) hält, dann unterstützt das Design die Usability.

Wieso gibt es Probleme, obwohl alle Standards befolgt werden?

Standards sind lediglich „Denkhilfen“, Guidelines, Orientierungen. Sie wecken Erwartungen bzw. entsprechen diesen nur. Explizite Standards wie Normen beschreiben die Funktion, implizite Standards wie das Corporate Design beziehen sich auf die Optik.

Jeder Fall ist individuell und von zahlreichen Faktoren abhängig:

Ist der gewählte Standard überhaupt für die Aufgabe geeignet? Für Industrie und kommerzielle Anwendungen (z.B. Banken, Versicherungen) gelten andere Standards als für Büro, Heim und Entertainment (z.B. E-Mail, Textverarbeitung, Suchmaschinen).

Passen Nutzermenge und -spektrum sowie Nutzungsfrequenz und -intensität zum gewählten Standard?

Benötigen die Nutzer eine andere Motivation, als sie der Standard ermöglicht?

Profitieren Erlernbarkeit und Schulungsaufwand vom Standard?

Hilft der gewählte Standard, Fehler-Risiken zu mindern und die Sicherheit zu erhöhen? Für lebenskritische Systeme (z.B. Reaktorsteuerung, Flugsicherheit) sind teilweise Standardabweichungen nötig, um realweltliche Risiken zu vermeiden.

Unterstützt der gewählte Standard die subjektive Zufriedenheit und das Vertrauen der Nutzer?

Kann der Standard die Erwartungen in Effektivität, Effizienz und Performance erfüllen?

Passt der Standard zum Preis des Produkts und den verfügbaren Entwicklungsressourcen?

Wie erreiche ich eine gute Usability?

Indem von Anfang an mindestens eine Person, die sich mit deren Anforderungen und Umsetzung auskennt, in das Projekt einbezogen wird. Diese hat bei allen Usability-Aspekten die Entscheidungsbefugnis und kann in den anderen Feldern als Moderator fungieren. Eine offene, konstruktive und sachlich-kritikfähige Arbeitsumgebung lässt Usability fast von allein entstehen. Bedingung dafür ist ein fachlich buntes Team. Dieses umfasst mindestens Entwickler, Marketingmitarbeiter, Nutzer-Vertreter, Usability-Erfahrene.

Praktisch ist es von Vorteil, wenn die Beteiligten außerhalb ihrer fachlichen Kompetenz fordernde Hobbys betreiben, beispielsweise ein Instrument spielen, Modelleisenbahnen bauen, Autos reparieren oder kunstgewerbliche Stücke anfertigen. Ein breites Interessenspektrum erweitert den Kompetenzhorizont und befruchtet die Arbeit aufgrund des größeren Erfahrungsraumes.

Wieso ist gute Usability nicht der Normalfall?

Analog lässt sich auch fragen: Warum essen wir ungesund, obwohl wir wissen, wie wichtig eine gesunde Ernährung ist? Wer Hunger oder Appetit hat, konsultiert nicht die Ernährungspyramide und Nährstofftabellen, sondern das umgebende Nahrungsangebot, seine Brieftasche und die Umstände.

Essen ist situativ und sinnlich. Die Portion Pommes, das Glas Cola, der Burger, das zerkochte Gemüse, das Weißbrot, die Extra-Portion Fleisch, der Fertigpudding, die süßen Corn Flakes – darauf habe ich gerade Appetit, die werden mich schon nicht umbringen, außerdem sind sie günstig, gerade in Reichweite und günstig.

Jeden Tag ein halbes Kilo frisches Obst und Gemüse vorzuhalten und zuzubereiten, ist viel zu aufwändig. Fast nur Wasser und ungesüßten Früchtetee trinken macht ebenfalls keinen Spaß. Gesundes Essen zeigt seine Effekte langfristig. Ungesundes Essen bringt uns nicht um, verringert nur unsere Chancen auf gute und beständige Gesundheit; der Zyniker stirbt sowieso nicht an Ungesundheit, sondern an einem Unfall oder einer neuen Krebsart.

Jeden Tag gesund zu essen erfordert genauso wie das Erreichen guter Usability:

(anfangs) stetige Selbstdisziplin – bevor es zur Selbstverständlichkeit und Normalität wird

Blick auf mittel- und langfristige statt kurzfristige Effekte – taugt allenfalls als rationales, aber nicht als sinnliches oder situatives Argument

Umdeuten der Prioritätsverschiebung nicht als Verzicht, sondern als etwas Positives

Im Gegensatz zu ungesundem Essen äußern sich die Effekte guter Usability eher, unmittelbarer und besser erkennbar. Sie haben betriebswirtschaftliche Auswirkungen, während potenzielle Gesundheitsprobleme eine Hypothek für die eigene Zukunft und die gesellschaftlich finanzierten Gesundheitssysteme aufnehmen.

Wer den Wechsel zu bewusster und gesunder Ernährung geschafft hat, weiß um die Vorteile und das verbesserte Körpergefühl. Genauso wissen jene Teams, die Usability fest in ihre Projekte integriert haben, um die positiven Auswirkungen. Alle anderen leben auch (irgendwie) und verzichten auf gute Chancen für ein besseres Leben oder erfolgreicheres Projektergebnis.

Was ist die User Experience?

Die User Experience (abgekürzt UX) beschreibt das Gesamt-Nutzererlebnis. Dabei geraten auch Faktoren außerhalb der Software oder Webseite in die Betrachtung. Zur UX eines Webshops gehören beispielsweise auch das Verhalten bei einer telefonischen Support-Hotline, die Verpackung der Lieferung, der Umgang mit Retouren, die Präsentation in Katalogen, Broschüren oder Anzeigen. Bei Software gehören beispielsweise die Verpackung, Präsentation auf der Internetseite oder im Katalog, die Produktbeschreibung und Nutzerdokumentation, der Support, der Installations- und Aktualisierungsprozess zum Gesamterlebnis.

Ergänzend wirken sich die Leistungsfähigkeit des eigenen Geräts sowie die Internetgeschwindigkeit auf die UX aus. Bei der Konzeption sind daher die realen Verhältnisse zu berücksichtigen, die auf Nutzerseite herrschen. Insbesondere bei Mobilgeräten ist das technische Spektrum sehr breit, daher ist die Geräteverteilung unter den Nutzern bei der Entwicklung zu berücksichtigen.

Historisch hat sich die User Experience aus den Ansprüchen des Architekten und Designers Vitruv (1. Jh.v.u.Z.) entwickelt: Firmitat (Festigkeit), Utilitas (Nützlichkeit, Usability) und Venustas (Schönheit). Je nach Objekt (Gebäude, Kleidung, Software, etc.) fällt die Gewichtung der Aspekte unterschiedlich aus. Die ISO 9241-210 (Seite →) definiert User Experience über die Wahrnehmungen und Reaktionen einer Person, die sich bei der Benutzung oder der erwarteten Verwendung eines Produkts ergeben. Das umfasst die psychologischen und physiologischen Aspekte, die Emotionen, die Erwartungen und das Verhalten.

Um die emotionale Wirkung zu steigern, ist es gelegentlich angebracht, mit Konventionen oder Regeln (und dadurch mit den Erwartungen) zu brechen. So lassen sich gezielt Akzente setzen oder Reibeflächen erzeugen, die das Verhältnis zum Produkt intensivieren.

Was unterscheidet Web-Usability von Software-Usability?

Die Grenzen zwischen Webseiten, Web-Applikationen und Software werden immer weicher. Der Hauptunterschied liegt nicht im Medium „Web oder Software“, sondern in der Nutzung und Funktionalität. Daher illustrieren die Beispiele in diesem Buch jeweils prototypische Anwendungsfälle und stellen keine Dogmen für Web oder Software dar. Tendenziell gilt folgende Orientierung:

Tab. 1.1: Unterschiede zwischen Webseiten und Software

 Prototypische WebseitePragmatische SoftwareNutzunggelegentlichintensiv, dauerhaftKontextFreizeitArbeitMotivationeigene, selbstbestimmtzielgerichtet, fremdbestimmtZielUnterhaltung, InformationFunktionalität, Aufgaben erledigenDesigneigenständig, ein wenig verspieltfunktional, zurückhaltendFarbigkeitmeist deutliche FarbigkeitFarbigkeit nur zur AkzentuierungInhalteWebseiten-Inhalte (vorwiegend Konsum)Nutzerinhalte (vorwiegend Kreation, Bearbeitung)

Web-Apps wie Dokumentbearbeitung im Browser oder Webmailer-Oberflächen übertragen die Ansprüche von Software in das Web. Spiele oder kleine Softwaretools erfüllen teilweise mehr Web-Ansprüche. In vielen Fällen stellt sich bei neuer Software die Frage, ob sie als Web-App umgesetzt wird. Mobile Apps bilden oft optimierte Oberflächen für den Zugriff auf Webseiten-Funktionen. Daher gibt es kaum Regeln, die software- oder web-exklusiv sind. Es gelten stets die Regeln, die für die Nutzungsituation und Zielgruppe angemessen sind.

Jede Webseite und jede Software sollte in irgendeiner Form Nützlichkeit besitzen; diese kann sich in erfolgreicher Maschinensteuerung, guter Aufgabenbewältigung, effektiver sozialer Interaktion, aber auch in Spielspaß äußern. Diese Nützlichkeit spiegelt sich in der Präsentation wider, daher lohnt sich im ersten Schritt die Orientierung an pragmatischer Software. Im zweiten Schritt erhöhen soziale, ästhetische oder Gamification-Aspekte die Nutzfreude und steigern ergänzend die Motivation.

2Einstimmung

Das Ganze ist mehr als die Summe seiner Teil. (Aristoteles)

Usability stellt den Nutzer in das Zentrum – eine Software oder Webseite dient dessen Zielen. Was heute wie ein Allgemeinplatz klingt, ist für viele Entwickler noch keine Selbstverständlichkeit. Projekte werden meist aus der technischen Perspektive vorangetrieben und dabei der Nutzen für die späteren Anwender aus dem Blick verloren.

Gute Usability befriedigt die fünf Grundbedürfnisse der Nutzer:

Respekt

Vertrauen

Unterstützung

Verständnis

Kommunikation

Bei jedem Element, bei jeder Funktion, bei jeder Entscheidung über die Bedienung werden diese fünf Faktoren erfüllt, mitunter sind diese gegeneinander abzuwägen. Einige historische Beispiele illustrieren, wie unterschiedlich sich diese in der Praxis ausprägen.

Drei große Bereiche geraten in den Blick, wenn man über User-Interface-Design spricht:

Projekt: Alles ist heute ein Projekt, von der ersten Idee bis zum fertigen Ergebnis. Ein Projekt beginnt mit seiner Definition: Mit gegebenen Ressourcen (Zeit, Personal, Geld) soll zu einem bestimmten Zeitpunkt das Projektziel erreicht sein. Daraus lassen sich die Anforderungen an Projektmanagement ableiten:

Definition des Projektziels in messbaren Einheiten nach validierbaren Kriterien

Verwaltung der Ressourcen und Planung des Ressourceneinsatzes

Prioritätensetzung bzgl. Teilzielen, Ressourcen, Anspruchsaspekten

Koordination und Gewährleistung der Arbeitsabläufe

Steuerung des Fortschritts und Kontrolle der Zwischenergebnisse

Einige Kurzausflüge in Bereiche des Projektmanagement zeigen, wie User-Interface-Design in der Praxis integriert werden kann. Im Sinne eines ganzheitlichen Ansatzes wäre die Abspaltung dieses Aspekts eine Degradierung. In allen Projektphasen und Teilprojekten sind die Anforderungen an das User-Interface-Design zu berücksichtigen.

Software: Programme und Apps stellen Nutzern bestimmte Funktionalitäten oder Erlebnismöglichkeiten (beispielsweise Spiele) bereit. Die Software läuft auf dem Computer bzw. Smartphone oder Tablet des Nutzers und kommuniziert so direkt mit der Hardware. Die Definition einer Software umfasst mindestens:

Systemische Voraussetzungen: Plattform bzw. Betriebssystem, nutzbare Hardware, Ein- und Ausgabemöglichkeiten

Funktionale Anforderungen: Was tut die App oder das Programm? Wie werden Daten verarbeitet (Algorithmen)? Die funktionalen Anforderungen sind im Projektziel definiert.

Nicht-funktionale Anforderungen: Gestaltung, Benutzerführung

Auch wenn gelegentlich Spiele zur Illustrierung eines Aspekts herangezogen werden, so richten sich die Ausführungen bewusst nicht an Spiele-Designer. Ziel ist vielmehr die Entwicklung von produktiver Software, die mit einem Nutzen beispielsweise in der Arbeit eingesetzt wird.

Webseite: Eine Webseite repräsentiert in gewisser Weise das Ergebnis einer Software, die auf dem Webserver läuft; die Eingaben und Ausgaben der Software erfolgen über den Browser auf dem Nutzer-Gerät. Die funktionalen Möglichkeiten sind durch die Browser und deren Zugriff auf die Geräte-Ressourcen begrenzt. Die Definition einer Webseite umfasst mindestens:

Systemische Voraussetzungen: Server (Version, Fähigkeiten, Ressourcen), Programmiersprache, Datenbanken, unterstützte Browser

Funktionale Anforderungen: Welche Interaktionen bietet die Webseite dem Nutzer? Wie werden Daten verarbeitet (Algorithmen)? Die funktionalen Anforderungen sind im Projektziel definiert.

Nicht-funktionale Anforderungen: Gestaltung, Benutzerführung

Software und Webseiten teilen sich zwar die gestalterischen Grundlagen, doch die Nutzungsszenarien unterscheiden sich. Dadurch weichen die Ansprüche an Benutzerführung und Gestaltung zum Teil erheblich voneinander ab. Bei Webseiten sind häufig gestalterische Fragen wichtiger als die Funktionalitäten im Hintergrund. Etwas vereinfacht gelten die Software-Regeln vor allem für produktive Systeme, die im Arbeitsalltag eingesetzt werden (ob nun als Software oder Webseiten-Backend). Die Webseiten-Regeln dagegen gelten vorwiegend für Webseiten, die sich an Endverbraucher richten, die Nutzung erfolgt häufig aus privatem Interesse oder in privatem Umfeld.

Mit den sogenannten Web-Applikationen rücken Software und Webseiten zusammen. Google-Docs beispielsweise bieten komplexe Möglichkeiten für Textverarbeitung und Tabellenkalkulation innerhalb einer Webseite. Die meisten E-Mail-Dienste bieten ebenfalls eine Web-Oberfläche, die sich wie ein Programm bedient. Zahlreiche Dienste stehen gleichermaßen als Software und Webseite bereit, beispielsweise der Cloud-Speicherdienst Dropbox oder die E-Mail- und Termin-Verwaltung Outlook. In diesen Fällen verdient die technische Infrastruktur besondere Aufmerksamkeit, um die benötigte Robustheit, Skalierbarkeit und Zuverlässigkeit zu gewährleisten. Wie gut ein System tatsächlich ist, zeigt sich immer dann, wenn etwas nicht wie erwartet funktioniert.

Absehbar ist, dass sich die Vielfalt der Nutzer-Schnittstellen weiter erhöht. Vom Computer über Tablet und Smartphone bis zu Smart-Watches, Smart-Brillen und anderen Wearables. Dazu gesellen sich sprachgesteuerte Systeme wie Siri, Google Talk oder Cortana, Gestensteuerung und auch ganz neue Nutzungsszenarien wie Smart-Cars oder Head-On-Displays, um die Hände im Operationssaal oder bei anderen Einsätzen frei zu haben.

Der konkrete Fokus des Buchs liegt zwar auf Software und Webseiten, die mit Computer, Tablet oder Smartphone genutzt werden. Doch die Regeln zu Projektmanagement, Design und anderen Aspekten gelten für alle Nutzer-Schnittstellen. Auf dem abstrakten Level gehorchen alle Interfaces den gleichen Ansprüchen und Regeln, erst in der konkreten Umsetzung prägen sich diese unterschiedlich aus. Je etablierter eine Schnittstelle ist, desto stärker sind Standards und Erwartungen gefestigt, neue Interface-Konzepte probieren noch zahlreiche Varianten aus.

Über funktionale Anforderungen besteht meist große Einigkeit bzw. diese lassen sich als Projektziel gut definieren:

Die Software erfasst kontinuierlich Daten des Sensors X und stellt diese für den vom Nutzer gewählten Zeitraum als Balkendiagramm dar. Wird ein eingestellter Grenzwert der Sensorwerte überschritten, erhält der Nutzer einen Hinweis.

Die Software ermöglicht das Ansteuern eines Scanners. Dabei kann der Nutzer verschiedene Einstellungen vornehmen und das gescannte Bild als Datei in den Formaten X, Y und Z abspeichern.

Die Software unterstützt bei der Belegerfassung und ermöglicht das Ausdrucken von Listen sowie den Export sowie Import der Daten in den Formaten X, Y und Z.

Die Software bietet das Erlebnis eines Rätselspiels, bei dem der Nutzer nach jeder Runde eine neue Aufgabe präsentiert bekommt. Zwischen den Runden ist der Spielstand abspeicherbar und das Spiel kann an dieser Stelle später fortgesetzt werden. Die Spielregeln sind: [. . .].

Die Webseite ermöglicht den Nutzern das Anlegen eines Kundenkontos, das Hochladen von Daten (vom Typ X, bis zur Größe Y) sowie das Versenden eines Download-Links an andere Nutzer mit Kundenkonto.

Die Webseite bietet zahlreiche Artikel zum Themengebiet X. Diese werden von mehreren Autoren erstellt und gepflegt. Der Webseitenbesucher kann über die Suche rasch gewünschte Beiträge auffinden. Jeder Artikel ist erst nach Freigabe durch einen Nutzer der Nutzergruppe Y für die Webseitenbesucher sichtbar.

Die Webseite bietet mehrere Zugriffsarten, je nach Kundenart (kostenlose, Abonnenten und Premium-Nutzer). Davon sind die Menge der möglichen Zugriffe, die Größe der hoch- und runterladbaren Dateien sowie Support-Angebote durch Mitarbeiter betroffen.

Die Webseite bildet einen Katalog von X Produkten ab. Diese variieren in Größe, Farbe und Textur. Für jede Kombination wird die tatsächliche Lagerverfügbarkeit angegeben. Der Webseitennutzer wählt Produkte in der gewünschten Ausprägung und kann diese online bestellen.

Die Liste ließe sich beliebig fortsetzen und verfeinern. So fehlt bereits beim ersten Beispiel eine Regelung, wie der Nutzer den Hinweis erhält. Auch die Frage, ob der Nutzer bei jedem Sensorwert jenseits des Grenzwerts den Hinweis erhält oder nur beim ersten, bleibt unbeantwortet. Handelt es sich um einen Temperatursensor, wäre folgende Logik eventuell sinnvoll:

Ist der Grenzwert erstmals überschritten, wird der Nutzer auf seinem Bildschirm und/oder via E-Mail darüber informiert.

Die „erstmals“-Zählung wird bei jeder Nutzerinteraktion mit der Software auf Null gesetzt. Während der aktiven Nutzung der Software (weniger als 20 Sekunden zwischen zwei Nutzereingaben) wird der Hinweis sichtbar, aber nicht behindernd integriert.

Ist der „erstmals“-Zähler größer als Null und fällt der Sensorwert wieder unter den Grenzwert, erhält der Nutzer eine Information mit der Angabe des Zeitraums zwischen der ersten Grenzwertüberschreitung und dem Zeitpunkt der Normalisierung.

Mit solchen Überlegungen befinden wir uns bereits mitten im User-Interface-Design. Es ist nicht nur zu definieren, wie der Hinweis erfolgen und gestaltet sein soll. Ebenso spielen die Interaktionsprozesse eine große Rolle: Wann werden dem Nutzer welche Informationen gegeben und wie wird auf Nutzeraktionen reagiert?

Der im letzten Beispiel skizzierte Webshop wirft zahllose Fragen auf: Wer pflegt die Produkte und wie? Wie erfolgt die Kundenkommunikation? Welche Aufgaben hat die Suche? Wie wird mit nicht erfüllbaren Bestellungen verfahren? Welche Auswirkungen hat die Preispolitik: Gibt es Angebote? Wie werden diese gekennzeichnet? Werden Preise durch Automatismen oder durch Zeitsetzungen gesteuert oder nur manuell gesetzt? Welche Preissuchmaschinen oder externen Dienste werden wie eingebunden? Welche Liefer- und Zahlmöglichkeiten hat der Kunde?

Bei Webseiten sind zwei Nutzergruppen zu berücksichtigen: Die Nutzer des Backends (Autoren, Produktpfleger, Manager, Controller, etc.) sowie die Nutzer der Webseite (Leser, Kunden, Webseitenbesucher und -nutzer). Beide Nutzergruppen stellen unterschiedliche Anforderungen an die Bedienung der Webseite. Was für die Backend-Nutzer gut und effektiv ist, kann für die Webseitennutzer störend und nervig sein – und andersherum. Eine pragmatische, schnörkellose Gestaltung im Backend ist oft zielführend, aber die Webseite darf und sollte den einen oder anderen Schnörkel aufweisen.

Während die funktionalen Anforderungen gut zu erfassen sind, entziehen sich die nicht-funktionalen Anforderungen der klaren Definition. Man weiß meist erst, was gut ist und gut funktioniert, wenn man es sieht oder ausprobiert. Daher steht in Anforderungen dann der Allgemeinplatz: „Die Software, die App, die Webseite weist eine gute Usability auf.“

Usability

Usability ist das Modewort, wenn über die Schnittstellen zwischen Mensch und Maschine gesprochen wird. Das betrifft Software, Webseiten, Maschinensteuerung, selbst Möbel mit Einstellungsfunktionen oder Unterhaltungselektronik. „Usability“ bezeichnet – vereinfacht gesagt – ein Konglomerat aus den deutschen Begriffen „Gebrauchstauglichkeit“, „Anwenderfreundlichkeit“ und „einfache Bedienung“. „Intuitive Bedienung“, „Fehlertoleranz“ oder „modernes Design“ begleiten oft die Vorstellungen von Usability.

„Usability“ ist kein Wert an sich, sondern zunächst nichts anderes als „Qualität“ oder „Wetter“ – jedes Produkt besitzt eine Qualität, manche eine hohe, andere eine geringe. Jeder Tag hat Wetter, manche gutes, andere schlechtes. Auch die am kompliziertesten zu bedienende Software besitzt Usability – nur vermutlich keine gute. Die Erfahrungen mit schlechter Usability leiten oft, was man bei eigenen Projekten vermeiden oder anders machen möchte. Doch bekanntes Schlechtes einfach nur zu vermeiden, führt nicht notwendigerweise zu einem guten Ergebnis.

Gute Usability schafft eine Verbindung zwischen Mensch und Maschine bzw. Computer, die „sich gut anfühlt“. Zu diesem Wohlfühlen tragen verschiedene Faktoren bei. Es sind die gleichen Faktoren, die auch für die Beziehungen zwischen Menschen gelten – ob nun Liebesbeziehung oder freundschaftliche Verbundenheit. Für negativ aufgeladene Beziehungen würden wir über die Faktoren „Frust, Unzuverlässigkeit, Vernachlässigung, Desinteresse oder Misstrauen“ sprechen. Doch diesen widmen wir uns höchstens als Negativbeispiele, denn schließlich wollen wir den Anwendern ein gutes Gefühl vermitteln – mittels einer guten Usability.

Faktor 1: Respekt

Respekt entsteht durch fachliche Kompetenz, durch angemessenes Verhalten, durch Wissen um die eigenen und fremden Stärken und Schwächen. Der respektvolle Umgang miteinander ist davon geprägt, andere Menschen nicht durch Worte oder Taten zu erniedrigen bzw. sich selbst nicht über andere zu erheben. Dazu gehört ebenso, gezogene Grenzen zu achten, Fähigkeiten zu fördern und Unfähigkeiten nicht bloßzustellen.

All das erwarten wir von unserem Computer bzw. der Art, wie dessen Software oder eine Webseite uns behandeln. Wir erwarten Aussagen über die fachliche Kompetenz (und dass wir uns auf die Korrektheit dieser Aussagen verlassen können). Wir erwarten, mit unseren Anliegen ernstgenommen zu werden, ohne uns als Bittsteller zu fühlen oder mit einer sich untertänig andienenden Software klarkommen zu müssen. Wir erwarten, dass die Software nicht mehr von uns verlangt, als wir in der Lage sind zu leisten.

Werden diese Erwartungen erfüllt, fühlen wir uns bestärkt und nutzen die Software oder Webseite gern.

Faktor 2: Vertrauen

Vertrauen ist leicht zu erschüttern und schwer zu verdienen. Besteht es jedoch erst einmal, steigen die Toleranz und die Nachsicht bei Kleinigkeiten. Vertrauen entsteht durch Zuverlässigkeit, durch gemeinsames Verständnis von der Welt und den Abläufen in der Welt, durch Offenheit, durch die Kongruenz von Worten und Taten. Jeder kennt aus seinem persönlichen Umfeld genügend Beispiele von Personen, die das eigene Vertrauen verdienen, und anderen, die das einst entgegengebrachte Vertrauen verwirkt haben. Natürlich genießen verschiedene Personen auch unterschiedliche Grade von Vertrauen. Einigen vertrauen wir in bestimmten Fachbereichen, anderen charakterlich wegen ihrer Integrität, wieder anderen nur in Bezug auf unsere emotionalen Befindlichkeiten.

Software hat den Vorteil, dass sie vorwiegend auf einer fachlichen Ebene Vertrauen erlangen muss. Das bedeutet zuvorderst, dass sie zuverlässig funktioniert und alle versprochenen Funktionen korrekt ausführt. Im Alltag bedeutet Vertrauen auch, dass man einer Software seine Daten anvertrauen möchte, da es keine Anzeichen für eine missbräuchliche Nutzung gibt. In der Bedienung kann man Vertrauen durch Konsistenz erheblich fördern. Konsistenz unterstützt den Lerneffekt, denn ein einheitliches Erscheinungsbild sorgt dafür, dass Nutzer sich schnell zurechtfinden und die Auswirkungen ihres Tuns abschätzen können. Damit entfallen überraschende oder verstörende Situationen, die Skepsis und Misstrauen säen.

Wie in einer Ehe kennt der Mensch die Geschichten, Antworten und Reaktionen des anderen bereits im Vorfeld und liegt damit meist richtig. Idealerweise dauert es bei der Beziehung zwischen Mensch und Maschine nicht viele Ehejahre, bis dieses Vertrauen aufgebaut ist, sondern dieses entsteht in den ersten Nutzungsstunden.

Faktor 3: Unterstützung

„Quid pro quo“ lautet der stille Subtext vieler menschlichen Interaktionen, ich helfe dir heute, du mir morgen. Heute die Antwort auf eine Fachfrage, morgen Hilfe bei der Kinderbetreuung, übermorgen gemeinsamer Theaterbesuch und am Tag darauf kocht der eine für den anderen. Die Kette solcher gegenseitigen Gefälligkeiten kann sich über Lebensjahre hinziehen. Um manche Gefallen muss man bitten, andere ergeben sich von ganz allein, wieder andere wirken, als hätte der andere meine Gedanken gelesen und bietet genau im richtigen Moment die benötigte Hilfe.

Gegenüber dem Computer ist meine Palette an Hilfeleistungen überschaubar: einschalten, für genügend Strom während des Betriebs sorgen, die korrekte Software starten oder Webseite aufrufen, benötigte Daten bereitstellen. Als Gegenleistung erhalte ich Unterstützung bei einer Vielzahl von Aufgaben: Steuererklärungen und andere Berechnungen, Bildbearbeitung und Video-Schneiden, E-Mail-Kommunikation und Rechtschreibkontrolle, Online-Shopping und Budgetkalkulation. Viele dieser Unterstützungen sind direkte Hilfeleistungen, die sich konkret aus der Aufgabe ableiten. Wie zwischen Menschen unterscheiden sich auch die Möglichkeiten, wie wir in der Computerwelt Unterstützung erhalten.

Die Steuererklärung beispielsweise kann im Ergebnis identisch sein, doch von dem einen Steuerberater wurde ich herablassend und besserwisserischlehrerhaft zur Einreichung der Unterlagen aufgefordert, während ein anderer mit mir die benötigten Angaben durchging und gemeinsam eine Liste der noch vorzulegenden Unterlagen erstellte. Der zweite Fall bot eine gute „menschliche Usability“, und ich würde ihn lieber benutzen als den ersten. Ebenso ist bei Software nicht nur entscheidend, die tatsächlich benötigte Unterstützung funktional anzubieten, sondern dies auch in angenehmer Weise zu tun – sodass der Nutzer sie annehmen möchte, weil er oder sie sich unterstützt fühlt. Dadurch wird er die Software häufiger (und motivierter) nutzen, und durch den begleitenden Lerneffekt steigen die Qualität der Eingaben sowie die Nutzungsgeschwindigkeit.

Der Grat zwischen dem Gefühl der Unterstützung und dem der Bevormundung ist schmal. Das weiß jede Mutter, die ihrem Kind versucht, die korrekte Kleidung für das Spielen im Freien anzuziehen. „Ich meine es doch nur gut mit dir“, lässt das Kind nicht als Argument der Mutter gelten, und die User nicht als Ausrede des Computers.

Faktor 4: Verständnis

Tagaus tagein wird Verständnis erwartet: für Baustellen, für Warteschlangen, für Bearbeitungszeiten, für Probleme, für Hindernisse, für falsches Verhalten. Verständnis braucht es immer dann, wenn etwas nicht so läuft, wie es gemäß unserer Vorstellung oder Erwartung laufen sollte. Für viele Dinge fehlt uns aber das Verständnis, vor allem dann, wenn es offensiv eingefordert wird: „Wir danken für Ihr Verständnis wegen der entstehenden Unannehmlichkeiten.“ Verständnisbereit sind wir dann, wenn die andere Person oder die Institution unser Vertrauen erworben haben, und es sich um Ausnahmen handelt. Ein Verständnis, das aus dem Gefühl der Hilflosigkeit oder Ohnmacht erwächst, ist keines, sondern lediglich Resignation.

Verständnis setzt Verstehen voraus. Ich habe Verständnis, wenn ich verstanden habe, worin das Problem besteht und wenn es mir einsichtig ist. Eine Fehlermeldung wie „Diese Funktion steht nicht zur Verfügung“ ist nicht geeignet, für Verständnis zu werben. Dagegen erhöht „Um diese Funktion zu nutzen, sind weitere Angaben nötig“ meine Fähigkeit, das Problem zu verstehen: Ich muss noch weitere Daten zur Verfügung stellen. Wenn die Fehlermeldung um einen Link zu einem geeigneten Eintrag in der Software- oder Online-Hilfe ergänzt wird, werde ich befähigt, das Problem auch gleich zu lösen.

Das ist das fundamentale Verständnis der Software bzw. Webseite für mein Anliegen: Ich möchte weder die Software noch die Entwickler ärgern, sondern eine Aufgabe erledigen. Hilf mir, dies mit möglichst wenig Aufwand zu tun, und du bist mein Freund.

Verständnis funktioniert in beide Richtungen. Behandelt der Computer seine Nutzer fair, so wird ihm auch Verständnis entgegengebracht. Zur fairen Behandlung gehört, dass der Computer seine Funktionen für den Nutzer verständlich anbietet und bei Eingaben nicht nur sagt, welche er benötigt, sondern vor allem auch warum. Auf einer Shopping-Webseite ist die Angabe einer Lieferadresse selbstverständlich, da genügt die indirekte Grund-Angabe durch eine Überschrift wie „Geben Sie die Lieferadresse an“ oder „An welche Adresse soll die Bestellung geliefert werde?“ oder schlicht „Lieferadresse“. Aber warum ist beispielsweise die Angabe einer Telefonnummer, des Geburtsdatums oder des akademischen Grades nötig? Manche Warum-Fragen beantwortet der Kontext eindeutig, andere müssen im vorauseilenden Verständnis begründet werden.

Wenn der Computer alle Eingaben so verarbeitet, wie er sie nach Nutzerverständnis verarbeiten sollte (eben die Lieferung an die angegebene Adresse veranlasst), dann steigt auch das Verständnis auf der Nutzerseite. Zu diesem Verständnis gehört auch das Wissen, dass keine anderen als die angebotenen Funktionen zur Verfügung stehen. Dass Angaben in einer bestimmten Form oder Reihenfolge benötigt werden. Dass der Computer kein Mensch ist, der zwischen den Zeilen lesen kann, sondern nur seinen vorgegebenen Bahnen folgt.

Faktor 5: Kommunikation

Verständnis wird vor allem über die Kommunikation erzeugt. Es gibt die offene Kommunikation („Das finde ich nicht gut von dir“) und die indirekte (Blicke des Missfallens). Wirkungsvolle Kommunikation funktioniert nur, wenn direkte und indirekte das Gleiche erzählen. Eine Person, die gequält zwischen den Zähnen hervorpresst, dass sie sich gern mit anderen unterhält, wirkt nicht glaubwürdig. Ebenso wirkt eine Webseite in technizistischem Design wenig geeignet, um Gedichte zu präsentieren. Eine verschnörkelte, pompöse Webseite, die schwafelig die Vorteile eines günstigen Produkts anpreist, funktioniert nicht. Inhalt und Form müssen miteinander harmonieren und kongruent sein.

Dabei besteht keine Software und keine Webseite im luftleeren Raum. Design-Konventionen und Gewohnheiten verleihen dem Design eine Inhaltsebene. Bestimmte Gestaltungen treffen oder evozieren inhaltliche Aussagen. Auch wenig geübte Anwender sehen einer Software oder Webseite an, was ihr Zweck ist bzw. was sie anbieten – ohne ein Wort zu lesen.

„Man kann nicht, nicht kommunzieren‘ “, hat Paul Watzlawick einstens formuliert. Umso wichtiger ist es, sich der zahlreichen Ebenen und deren gegenseitigen Beeinflussungen und den Abhängigkeiten der Kommunikation bewusst zu sein und diese zu einem einheitlichen Ganzen zu fügen.

Jeder Mensch hat seine eigenen kommunikativen Fähigkeiten. Der eine formuliert nüchtern karg auf den Punkt, der andere weitschweifig detailverliebt und wortspielbegeistert. Inhaltlich sagen beide das gleiche, und in manchen Situationen schätzen wir die knappe Präzision des einen, in anderen die eloquenten Fabulierungen des anderen. Weder können die Extreme noch ein ausgewogener Mittelweg alle Bedürfnisse befriedigen.

Wichtig ist daher, überhaupt zu kommunizieren, lieber zu häufig als zu selten. Bewährt hat sich die Kombination aus knapper Präzision mit Verweis auf eine detaillierte Langfassung, beispielsweise bei Fehlermeldungen mit Link zu einem Hilfe-Beitrag. Aber selbst diese Lösung hat ihre Grenzen. Nämlich dann, wenn der Nutzer sie nicht als konstruktive Kommunikation wahrnimmt, die ihm hilft, sein Anliegen zu erfüllen.

Kondensierungsversuch

Software und die meisten Webseiten existieren nicht zum Selbstzweck und nur wenige aus dem Geltungsdrang eines Programmierers heraus – sie sollen Nutzer dazu befähigen, etwas Bestimmtes zu tun. Auf einem abstrakten Niveau gelten die fünf Faktoren (oder Prinzipien) daher gleichermaßen für Beziehungen zwischen Menschen und zwischen Mensch und Maschine:

Respekt: Von mir werden nur Angaben erwartet, die für die Aufgabe nötig sind und die ich zu leisten in der Lage bin. Dafür wird mir der geringstmögliche Aufwand abverlangt.

Vertrauen: Meine Daten werden nicht missbraucht, sondern ich erhalte am Ende das versprochene Ergebnis. Gleiche Daten ergeben das gleiche Ergebnis, das Sprechen über die Vorgänge bzw. deren Darstellung entspricht dem tatsächlichen Umgang mit den Daten, und gleichartige Darstellung bedeutet gleichartige Funktionalität.

Unterstützung: Ich erhalte Hilfe dabei, eine bestimmte Aufgabe zu lösen oder ein Anliegen zu erledigen. Nicht mehr, aber auch nicht weniger. Ich werde weder gegängelt noch bevormundet oder zu Aktionen gezwungen, die nicht meiner Aufgabe oder meinem Anliegen entsprechen.

Verständnis: Mein Helfer kennt mein Anliegen und den Weg, wie ich es erledige bzw. den Weg zur Lösung meiner Aufgabe. Gibt es keine vorgefertigten Wege, werden mir verschiedene Möglichkeiten so bereitgestellt, dass ich mir selber einen Weg erarbeiten kann.

Kommunikation: Ich erhalte Feedback, wenn etwas nicht wie beabsichtigt läuft oder über den erfolgreichen Abschluss einer Aktion. Ich werde in angemessenem Tonfall und geeigneter Darstellung geführt. Direkte und indirekte Kommunikation widersprechen sich dabei nicht.

Zweiter Kondensierungsversuch

Erstens: Reden und Handeln bzw. Darstellung und Funktion sind widerspruchsfrei. Immer.

Zweitens: Mein Anliegen und meine Aufgaben sind das Maß aller Dinge.

Drittens: Meine Zeit und Ressourcen sind kostbar.

Gerade mit dem zweiten Punkt haben manche Entwickler große Probleme, da sie ihre Leistung nicht gewürdigt sehen. Daraus resultieren häufig Probleme mit dem ersten Punkt: Die Marketing-Abteilung verspricht etwas, was die Software nicht leistet, Funktionen sind missverständlich betitelt, Hilfe-Seiten erklären technische Vorgänge, aber nicht, wie ich mein Ziel erreiche, ein Fortschrittsbalken entspricht nicht dem tatsächlichen Fortschritt, die „Zurück“- oder „Undo“-Taste funktioniert nicht, es gibt keine Fehlermeldung, obwohl ein Fehler auftrat, oder es gibt eine Fehlermeldung, obwohl alles in Ordnung ist.

Das Wertvollste, was ich dir geben kann, ist ein Stück meiner Lebenszeit. Zeige mir, dass du meine Zeit wertschätzt und sie nicht verschwendest.

Behandle andere so, wie du selbst behandelt werden möchtest.

„Du“ bist in dem Fall der Schnittstellen-Verantwortliche, der die Struktur und das Design, die Texte und die Funktionen sowie deren Zusammenspiel definiert und vielleicht auch teilweise umsetzt. „Der andere“ ist der Nutzer. Gestalte also deine Schnittstelle zwischen Computer und Mensch so, dass der Mensch anständig behandelt wird. Aber wie möchten er oder sie behandelt werden? So wie du behandelt werden möchtest? Als Entwickler möchtest du von einem Computer anders behandelt werden als ein Gelegenheitsnutzer. Daher sind Entwickler schlechte Usability-Experten – und Gelegenheitsnutzer deutlich bessere (aber sehr selten in dem Bereich aktiv).

Um zu erfahren, wie „der andere“ behandelt werden möchte, musst du ihn oder sie erst einmal kennen. Deine künftige Nutzerschar wird über andere Kenntnisse, Erwartungen, Fähigkeiten und sprachliche Gepflogenheiten verfügen als du. Wenn du dir bewusst wirst, dass du es letztlich – über den Umweg einer Computerschnittstelle – mit Menschen zu tun hast, bist du auf dem richtigen Weg. Denn Menschen wollen nicht unbedingt auf eine bestimmte Weise behandelt werden, sondern sie wollen Respekt, Vertrauen, Unterstützung, Verständnis und angemessene Kommunikation erfahren.

Kein Faktor allein bewirkt eine gute Usability, sondern erst das Zusammenspiel zahlreicher Faktoren kann diese erreichen. Die fünf genannten Prinzipien geben das „Framework“ oder „Mindset“ oder Gedankenmodell vor, in dem eine Software oder Webseite mit Wohlfühlbedienung entstehen kann. Diese fünf Prinzipien verdeutlichen, dass Usability eine komplexe Angelegenheit ist, in deren Zentrum die anvisierte Nutzergruppe steht. Wer seine Nutzer nicht kennt, kann schwerlich eine Software oder Webseite entwickeln, deren Bedienung „sich gut anfühlt“. Das bedeutet aber auch, dass sich einige Personen wohler damit fühlen als andere. Wer es allen recht machen will, wird niemanden wirklich zufriedenstellen.

Aufgrund der Vielschichtigkeit, mit der eine gute Usability erzeugt wird, sind zahlreiche verschiedene Kenntnisse und Fähigkeiten nötig. Je größer und interdisziplinärer ein Team aufgestellt ist, desto besser sind die Chancen, eine gute Usability zu erreichen. Je besser dieses Team die fünf Prinzipien in der eigenen Zusammenarbeit lebt, desto besser ist das erzielte Ergebnis. Dabei belegt sich eine altbekannte Phrase: Das Ganze ist mehr als die Summe seiner Teile.

Gute Usability zeigt sich in geringem Frust der Nutzer, in guter Konversionsrate, in motivierter und häufiger Nutzung, in der Selbstverständlichkeit, die Nutzung in den eigenen Alltag zu integrieren. Damit ist Usability für alle Software- und Webseiten-Entwickler ein vordringliches Thema, das nicht erst als Sahnehäubchen am Ende mit den Budgetresten umgesetzt wird, sondern die gesamte Entwicklung begleitet. Bereits in der Planung muss sie berücksichtigt werden und kann relevante Ziele für ein Software- oder Web-Projekt beisteuern:

Eine Software steigert die Arbeitsproduktivität. Die gleiche Menge Mitarbeiter schafft mehr in der gleichen Zeit, ohne dass es sich nach einer frustrierenden Mehrbelastung anfühlt.

Eine Software oder Webseite vereinfacht Vorgänge so, dass mehr Menschen diese ausführen können, ohne dass ein Qualitätsverlust entsteht. Das setzt personelle Ressourcen frei bzw. reduziert den Schulungsaufwand.

Ein Webshop motiviert mehr Menschen, etwas zu kaufen. Neben den verfügbaren Funktionen (Warenangebot, Zahlungs- und Lieferoptionen) sorgt die Usability für eine höhere Konversion (als prozentuale Relation zwischen den Anzahlen der Käufe und Webshop-Besucher).

Eine News-Webseite erhöht die Verweildauer der Leser, verleitet diese zum Stöbern und fördert Klicks auf Werbebanner.

Eine Webseite, die Produkte oder Leistungen vorstellt, motiviert mehr Besucher zu einem Anruf, zu einer E-Mail oder zum Bestellen (in einem Geschäft oder Online-Shop).

Ein guter Online-Support entlastet den persönlichen Support durch Call-Center oder Vor-Ort-Service, steigert die Zufriedenheit mit erworbenen Produkten und erhöht die Markenbindung, die langfristig weitere Bestellungen auslöst.

Die Kapitel stellen die wichtigsten Aspekte guter Usability vor:

3. Unsere Nutzer:

Ansätze, um Nutzertypen zu erfassen und zu verstehen

4. Unsere Computer:

Geschichte der Usability

5. Ziele und Aktionen:

Interaktionsmodelle und deren Eignung für verschiedene Projekte

6. Ordnung auf dem Bildschirm:

Ausrichtung, Dominanz, Hierarchien, Weißraum und Visuelles Gewicht

7. Design-Nussschale:

Visuelle Variablen, Optische Achsen, Raster &Gitter, Farbe und Schrift

8. Standardelemente:

Eingabefelder, Checkboxen, Radio-Buttons, Menüs, Tabs, etc. sowie Ansprüche an die Suche

9. Das eigene Interface:

Vorgehen, Normen &Richtlinien, Testen

10. Ganzheitlicher Ansatz:

27 Elemente, die es zu berücksichtigen gilt

Der Nutzer im Zentrum

Bevor man sich an ein eigenes Interface wagt, sind drei Dinge zu klären:

Welche Funktionen will oder soll ich abbilden?

Wer ist meine Zielgruppe/künftige Nutzerschar?

Welche Lösungen existieren bereits?

Schließlich musste das Rad nur einmal erfunden werden und kann heute für die verschiedensten Einsatzzwecke beispielsweise optimiert als Mountainbike-, als Rennrad- oder Kinderfahrradreifen existieren. Oftmals ist die evolutionäre Anpassung des Bestehenden effektiver als eine Revolution. Fünf historische Nutzerschnittstellen illustrieren, wie (retrospektiv) die Zielgruppe definiert wird und wie sich die fünf Prinzipien auswirken.

Kommandozeile

Abb. 1.2: Windows Powershell (2008) [Abbildung: Wikipedia]

Zielgruppe: „Power-User“, die schnell tippen können.

Respekt: Ich kann nur Tastatureingaben vornehmen, und muss selber wissen, was ich will – und was die Software bzw. das Gerät kann.

Vertrauen: Jede Eingabe bewirkt eine Reaktion, entweder Fehlermeldung oder Ergebnisbzw. Erfolgsmeldung.

Unterstützung: Ich muss selber wissen, was ich will und den Weg dahin kennen. Autovervollständigungen und andere Hilfen vereinfachen die Eingabe und reduzieren Fehler.

Verständnis: Die Software kennt meine Ziele oder Anliegen nicht, sondern ich muss diese selbst anhand der software-eigenen Sprache und in deren Grammatik vorbringen.

Kommunikation: Oft sind Befehle oder Ausgaben auf das Nötigste reduziert; Expertenwissen oder eine sehr gute Kenntnis der Software werden vorausgesetzt.

Fazit: Eine sehr flexible, wirkmächtige und funktionsreiche Möglichkeit, den Computer arbeiten zu lassen – sofern man sich auf dessen Niveau begibt.

Lektion: Manchmal kann sich hinter der unscheinbarsten Darstellung das mächtigste Werkzeug verbergen.

Norton Commander

Abb. 1.2: Norton Commander (für MS-DOS) [Abbildung: Wikipedia]

Zielgruppe: „Power-User“ oder User mit guten Computerkenntnissen

Respekt: Reduktion auf das Nötigste: Auflistung der vorhanden Dateien und Verzeichnisse und der Befehle zur Manipulation dieser (Kopieren, Löschen, etc.). Wird mit Tastatur gesteuert und optional ergänzend mit der Maus.

Vertrauen: Jede Aktion führt zu einem sichtbaren Ergebnis (Datei erscheint kopiert im Zielverzeichnis, Datei verschwindet nach Löschen aus der Liste, etc.)

Unterstützung: Die wichtigsten Informationen und Funktionen sind sofort sichtbar, die Bedienung folgt Konventionen (Scrollen, Auswählen, Befehl durch Sondertaste oder Mausklick aktivieren).

Verständnis: Mein Bedürfnis, zwei Verzeichnisse (ggf. auf zwei Datenträgern) miteinander zu vergleichen, den direkten Zugriff auf Dateien zu haben (statt ihre Namen in einer Kommandozeilenliste herauszulesen und anschließend einzutippen), eine direkt bearbeitbare Verzeichnisliste zu haben, wird erfüllt. So gut, dass dieses Programmmodell unter Windows noch jahrelang unter verschiedenen Namen für viele Benutzer die erste Anlaufstelle für Dateiaktionen bildete.

Kommunikation: Alle wichtigen Informationen sind sichtbar, die Präsentation der Befehle erfordert allerdings Lernaufwand für Laien. Das Ergebnis von Aktionen wird sofort kommuniziert (durch Sichtbarkeit des Ergebnisses) bzw. knappe Meldungen.

Fazit: Klarer Fokus, klare Bedienung. Nicht nur für Nerds ein Klassiker. Durch die gewachsenen Ansprüche an Dateiverwaltung jedoch in den meisten Fällen obsolet geworden.

Lektion: Eine gute Bedienungsidee hat die Produktivität der Dateiverwaltung enorm erhöht und das Vertrauen in die virtuellen Güter gestärkt.

Microsoft Bob

Abb. 1.3: Microsoft Bob (1995) [Abbildung und mehr Geschichten, Bilder und Wissenswertes über Bob: Winhistory.de]

Zielgruppe: Kinder? Comic-Fans? Computer-Neulinge? Was geschieht mit den Neulingen, wenn sie das System besser kennen?

Respekt: Theoretisch viel Respekt für mich. Ich kann mir ein Design nach meinem Geschmack aussuchen (von der klassischen Bibliothek bis zur Raumstation), ein virtueller Assistent hilft, meine (unterstellte) Furcht vor der Technik zu überwinden.

Vertrauen: Die Programme sind in die Umgebung integriert und wollen entdeckt werden (z.B. durch Klick auf den Kalender). Andere Objekte kann ich nicht anklicken (z.B. die Vase auf das Boot im Hintergrund werfen). Kann ich einem Cartoon-Kalender in einer Spielwelt tatsächlich meine wichtigen Termine anvertrauen?

Unterstützung: Der Assistent (von denen der Hund der populärste ist) gibt vor, mich zu unterstützen, doch seine Hilfsangebote entsprechen nicht meiner Lernkurve. Bald brauche ich ihn nicht mehr, und er wird lästig und bremst mich.

Verständnis: Der Computer gibt vor, meine Ziele, Aufgaben und Anliegen zu kennen. Praktisch renne ich ständig gegen Grenzen und beschränkte Funktionalitäten.

Kommunikation: Optisch kommuniziert es mir, es sei ein Spiel. Die geschäftsartigseriöse Schriftart „Times New Roman“ passt nicht in die bunte Welt (die vorgesehene „Comic Sans“ kam zu spät, die Designs waren bereits fertig).

Fazit: Immerhin überlebten die Figuren lange als Microsoft-Office-Assistenten. Diesen Assistenten widerfuhr das gleiche Schicksal wie Bob: Die Nutzer spielten ein wenig mit ihnen herum, freuten sich über absurde Vorschläge und launige Kommentare, zum tatsächlichen Arbeiten wurden sie deaktiviert. Tschüs, Bob.

Lektion: Arbeit am Computer muss nicht Spaß machen; sie soll sich effektiv, produktiv, ergebnisorientiert anfühlen.

Remote Surface Inspection

Abb. 1.4: NASA (1990er) [Abbildung: https://www-robotics.jpl.nasa.gov/roboticImages/img1016-334-browse.jpg]

Zielgruppe: Leute, die von irgendetwas Kompliziertem viele Dinge auf einmal im Blick haben müssen, evtl. um es zu steuern oder Funktionen auszulösen.

Respekt: Keinen für mich. Bunt, zu viele Informationen, keine erkennbare Struktur oder Hierarchie der Informationen erkennbar.

Vertrauen: Unterstellt sehr hoch. Klick auf Bildschirm löst die Funktion an der Maschine aus. Beziehung zwischen virtueller Darstellung und realer Aktion besteht direkt.

Unterstützung: Schnörkellose direkte Steuerung einer bestimmten Maschine.

Verständnis: Der Nutzer muss die zu steuernde Maschine und deren Funktionsweise sehr gut kennen, um dieses Programm verwenden zu können.

Kommunikation: Ich weiß gar nicht, was die Software von mir will. Will sie mich informieren, erwartet sie eine Eingabe, was kann ich überhaupt tun?

Fazit: Ganz sicher nicht für normale Anwender oder Computer-Nutzer entwickelt, sondern nur für diesen speziellen Einsatzzweck.

Lektion: Es ist okay, für komplizierte Vorgänge eine komplizierte Software zu entwickeln – vorausgesetzt, dass die Nutzer umfangreich geschult werden. Bei NASA-Mitarbeitern oder Piloten kann man davon beispielsweise ausgehen. Da ist es „billiger“, die Software so funktionsmächtig wie möglich zu machen und die wenigen Nutzer gründlich zu schulen, als die Bedienbarkeit so zu vereinfachen, dass „jeder“ das Programm bedienen könnte.

Pages for iPad

Abb. 1.5: Pages for iPad (2015) [Abbildung: Screenshot]

Zielgruppe: Menschen, die (auf ihrem iPad) etwas schreiben wollen

Respekt: Meine Inhalte erhalten den größten Teil meines wertvollen Bildschirmplatzes.

Vertrauen: Jede Änderung wird unmittelbar sichtbar umgesetzt. Die direkte Bedienung über Fingerberührung (Befehle, Optionen auswählen, Wörter markieren, Bilder verschieben) wird wörtlich genommen: Das Ergebnis ist unmittelbar sichtbar.

Unterstützung: Icons (gemäß Konventionen) präsentieren die häufigsten Format-Optionen, weitere Optionen sind durch Fingertipp direkt zu erreichen.

Verständnis: Das Programm weiß, dass ich Texte schreiben und diese formatieren will. Dafür stellt es mir Platz und die nötigsten Funktionen zur Verfügung. Ich habe Verständnis dafür, dass die Funktionspalette begrenzt ist, da die Leistungsfähigkeit des Gerätes und der Bildschirmplatz begrenzt sind.

Kommunikation: Die helle Gesamtgestaltung orientiert sich am weißen Schreibblock. Bei Berühren oder Markieren eines Bereichs werden die geeigneten Funktionen eingeblendet. Insgesamt gibt sich das Programm wortkarg und verlässt sich auf die intuitive Bedienung durch direkte Fingerberührung.

Fazit: Das Vertrauen besteht nur, wenn die direkte Bedienung tatsächlich möglich ist; sobald ich auf Reaktionen warten muss oder unbeabsichtigte Reaktionen folgen, schwindet es. Die direkte Bedienung reduziert die direkte Kommunikation. Der beschränkte Funktionsumfang (im Vergleich zur Textverarbeitung auf einem Computer) ist Teil des „Paktes“ zwischen mir und dem Programm.

Lektion: Beschränkung auf das Wesentliche funktioniert nur als Gesamtpaket.

Die fünf Beispiele illustrieren, dass es nicht das eine Interface geben kann. Je nach Zielgruppe, Einsatzzweck, Funktionsumfang und anderen Parametern gelten andere Maßstäbe, wann eine gute Usability erreicht wird. Mitunter genügt bereits eine Usability, die „gut genug“ ist, oder ein Zuviel an gutgemeinter Usability verkehrt etwas in sein Gegenteil.

Jedes Projekt muss den kalkulatorischen Regeln gehorchen: Aus der erwarteten Nutzermenge ergeben sich die erwarteten Einnahmen X für einen Zeitraum. Die Erstellung einer Software oder einer Webseite kostet Summe Y. X sollte immer größer als Y sein. Ist dies nicht gegeben, kann man versuchen, an Y solange herumzuschrauben, bis es niedrig genug ist. Mitunter ergibt sich daraus eine veränderte Nutzermenge oder Einnahmerechnung, sodass X und Y solange gegeneinander ausgespielt werden, bis ein akzeptables Ergebnis für alle Seiten erreicht ist.

Usability ist kein hehrer Selbstzweck, sondern muss sich in der harten Realität auch lohnen. Diese Erkenntnis kann schnell zur Ernüchterung führen, denn gute Usability hat ihren Preis. Grafiken und Animationen müssen erstellt und integriert werden. Bestimmte Funktionen werden ausschließlich für die Usability benötigt (beispielsweise die Ausgabe in einer Statuszeile des Programms statt in einer kryptischen Log-Datei oder ein Fortschrittsbalken). Das Design muss harmonisch abgestimmt werden und ästhetisch hohen Ansprüchen genügen – gute Designer sind nicht billig. Technische Grenzen sind zu überwinden oder Umwege zu erforschen. Ergebnisse von User-Tests oder das Feedback zum Alpha-Release können die ganze Arbeit zunichte machen. Der unternehmerisch gewollte Wechsel zu einem anderen Bedienparadigma oder anderen Konventionen hat unkalkulierbare Mehraufwände zur Folge.

Je eher sich das Entwicklerteam untereinander und mit den Auftraggebern auf Grundregeln und Konventionen zur Bedienung (und damit zur Usability) verständigt, desto geringer der Aufwand in der Umsetzung. Dadurch sinken die Kosten, und mit Mock-ups und Prototypen sind frühzeitig User-Tests möglich, sodass teure Überraschungen am Ende ausbleiben.

3Unsere Nutzer

Um die Nutzer ins Zentrum aller Web- und Software-Projekte zu stellen, muss man sie erst einmal kennen. Dabei helfen etablierte Persönlichkeitstypen und situative Verhaltensmuster. Vor allem die sehr unterschiedlichen Bedürfnisse von Novizen und Experten stellen die Interface-Designer vor große Herausforderungen. Die einen beispielsweise vertrauen auf Tastenkürzel, die die anderen noch nicht einmal kennen.

Für die weitere Arbeit werden die Nutzer und ihre Anforderungen erfasst:

Personas: prototypische Nutzer

Akteure und Rollen: abstrakte Nutzer

Use-Cases und Anwendungsfälle: (Teil-)Aufgaben

User-Storys: die Nutzung aus Anwendersicht

Auch innerhalb jedes Projekts werden unterschiedlichen Rollen von verschiedenen Personen besetzt, von der Projektleitung über Design und Entwicklung bis zum Marketing. Diese stellen in einigen Software- und Web-Projekten ebenfalls zu berücksichtigende Anwender für sogenannte Backend-Prozesse und -Aufgaben dar.

Niemand muss Psychologie studieren, um zu wissen, dass Menschen sehr unterschiedlich sein können. Katharine Briggs und Isabel Myers haben den sogenannten Myers-Briggs-Typindikator etabliert, der die Persönlichkeit nach vier Gegensatzpaaren bestimmt:

extrovertiert ./. introvertiert

empfindend ./. intuitiv

perzeptiv ./. bewertend

fühlend ./. denkend

Ausgehend davon lassen sich verschiedene Typen definieren. Je nach Veranlagung werden Aufgaben beispielsweise explorativ, kreativ, kollaborativ, sozio-technisch oder determiniert angegangen.

Für uns mag die Erkenntnis genügen, das zwei völlig gegensätzliche Menschen gleichermaßen mit unserer Software oder Webseite etwas erreichen wollen. Wir könnten zwei unterschiedliche Schnittstellen entwickeln, die den jeweiligen Charakteristiken gut entsprechen – oder wir entwickeln eine Schnittstelle, die für alle Nutzer geeignet ist. Denn abgesehen von der allgemeinen charakterlichen Prägung unterliegen alle Menschen auch situativen Schwankungen. Ein geduldiger Mann kann in bestimmten Situationen sehr ungehalten reagieren, eine nervöse Frau kann in bestimmten Situationen sehr fokussiert und konzentriert arbeiten.

Somit stellt sich die Frage weniger, welche Persönlichkeit vor dem Computer sitzt, sondern ob das Interface der Aufgabe angemessen ist. Wenn es also gelingt, eine Schnittstelle so zu gestalten, dass ein geduldiger Mann seine Geduld und Ruhe behält und eine nervöse Frau ihre Nervosität ablegt, dann ist allen geholfen. Den Menschen ist bewusst, dass sie vor einer Maschine sitzen und nicht mit anderen Menschen interagieren. Insofern braucht man sich lediglich an die fünf Prinzipien der Einleitung zu halten.

Unterstützt man dabei die explorative, kreative, kollaborative, sozio-technische oder determinierte Nutzung, kann sich jeder Nutzer den Weg suchen, der am besten zu seiner Arbeitsweise passt.

Der Explorative wird die Webseite oder Software erkunden und sich seine Wege suchen. Also sind alle Funktionen korrekt beschriftet, und es gibt keine Sackgassen.

Der Kreative wird versuchen, die Grenzen der Software zu überwinden oder deren Möglichkeiten für neue Zwecke zu nutzen. Daher gestattet die Software alles, was keinen direkten Schaden anrichtet.

Der Kollaborative will eine Aufgabe gemeinschaftlich bearbeiten. Also ermöglicht die Software oder Webseite, einen Zwischenstand zu speichern, um beispielsweise nach Klärung von Fragen dort wieder einzusetzen. Außerdem werden alle geeigneten Datenimport- und -export-Formate angeboten.

Die Sozio-Technischen wollen die Arbeitsteilung zwischen Mensch und Maschine optimal nutzen. Nur wenn soziale und technische Aspekte jeweils in sich und auch miteinander in Harmonie sind, kann ein gutes Ergebnis entstehen. Also lässt die Software so oft wie möglich die Wahl, ob eigene oder menschlich bereitgestellte Daten verwendet werden. Der Nutzer wird nie zu irgendetwas gezwungen, stets über seine Möglichkeiten informiert und kann die Software entweder bis ins Detail nutzen oder nur eine ausgesuchte Funktionen.

Die Determinierten arbeiten zielgerichtet auf ein bestimmtes Ziel hin, alles andere interessiert sie nicht. Also bietet die Software oder Webseite Assistenten an oder schildert klare Wege aus, um ein Ziel zu erreichen – und nur dieses Ziel, ohne Umweg, Zusatzfunktion oder sonstige gutgemeinte Mehrwerte. Online-Hilfe oder Handbuch stellen unterstützend die Wege für Standardaufgaben vor.

Ein Programm wie Microsoft Word bietet beispielsweise Vorlagen für die Determinierten, die somit nur noch die benötigten Angaben eintragen. Jederzeit kann eine Datei gespeichert, wieder neu aufgerufen und in verschiedene Dateiformate exportiert werden. Auch das Einlesen zahlreicher Dateiformate ist möglich. Das Verfolgen von Bearbeitungen und die Möglichkeiten zur Online-Zusammenarbeit unterstützen ebenfalls die Kollaboration. Der Explorative kann sich im Ribbon (früher im Menü) stets über alle verfügbaren Optionen informieren und diese bei Eignung anwenden. Für den Kreativen stehen alle Funktionen zur Verfügung, die gerade irgendwie möglich sind (unabhängig davon, ob sie sinnvoll sind), nur gerade unmögliche werden deaktiviert. Die Sozio-Technischen können selbst entscheiden, wie sie Ihre Schreiben verfassen, ob sie sich von Word mittels Vorlagen leiten lassen, mit einer leeren Seite beginnen, ob sie das Dokument im Layout-Modus gestalten oder im Text-Modus einfach nur den Inhalt schreiben wollen.

Dass Microsoft Word im Detail viele Probleme hat, sollte nicht darüber hinwegtäuschen, dass es ein mächtiges Werkzeug ist, das für alle Nutzergruppen geeignete Arbeitsmöglichkeiten bereitstellt. Jederzeit kann man seine Arbeitsweise ändern, ohne dass die Software dies mit einer Fehlermeldung quittiert. Das ist erst dann bemerkenswert, wenn man sich aus der Nutzerperspektive herausbegibt. Es gibt zahlreiche Textverarbeitungsprogramme, und jedes hat seine Stärken. Aber so flexibel und arbeitsweisenneutral wie Microsoft Word ist keines. Wer eine bestimmte Arbeitsweise – und nur diese – bevorzugt, kann mit anderen Programmen sehr glücklich und effektiv arbeiten. Kritisch wird es erst dann, wenn man vom kollaborativen in den explorativen Modus oder von der kreativen zur determinierten Arbeitsweise wechseln möchte.

Wieso gibt es dann Dutzende Textverarbeitungen, wenn Microsoft Word alles kann? Weil Word eben nicht in allen Bereichen perfekt ist. Beispielsweise beherrschen andere Programme das Konvertieren zwischen verschiedenen Textformaten besonders gut oder bilden das Layouten oder für Autoren das fokussierte Schreiben im Schreibmaschinenstil mit rudimentären Formaten effektiver ab.

Wie gelangen Entwickler zur Idee, eine weitere Textverarbeitung zu programmieren? Sie stellen einen Mangel oder ein Problem fest, oder haben eine Idee für eine Verbesserung – oder solche werden an sie herangetragen. Wenn sie wirtschaftlich entwickeln, kalkulieren sie nun, wie groß der Zielmarkt sein könnte. Da viele Software-Entwicklungen nicht wirtschaftlich kalkulierbar sind, entstehen häufig im Hobby-Bereich oder aus Enthusiasmus spannende neue Programm-Ideen, die erst in der nächsten Evolutionsstufe zu einem Produkt werden.

Eine nützliche Software

Wenn der (Hobby-)Entwickler eine neue Software entwickelt, um ein Problem zu lösen, das er selbst entdeckt hat, kennt er seine Zielgruppe: sich selbst. Dann kann er die Zielgruppe auch genau definieren: Paul, 27, studierter Biologe, benötigt ein Tool, um Ergebnisse von Versuchsreihen schnell zu erfassen und direkt als Diagramm mit Tendenzberechnung auszugeben. Das kann Paul programmieren. Die Usability vernachlässigt er dabei, denn er ist ja seine eigene Zielgruppe.

Das Programm besteht aus einem unbeschrifteten Eingabefeld, in dem er einen Zahlenwert einträgt, drückt, und in der unteren Monitorhälfte erscheint das aktualisierte Diagramm, eine graue Linie grenzt im Diagramm die Darstellung der Werte von der errechneten Tendenz ab. Für die Tendenzberechnung wechselt Paul mit den Tasten