User – Interface – Design
380 Seiten
erschienen Juni 2015
24,80 Euro (gedruckt)
17,99 Euro (eBook)
(bis Mitte August 2015 nur 11,99 €)
bei Amazon aufrufen (gedruckt und eBook)
im iTunes Book-Store aufrufen (eBook)
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.
PDF-Auszug von „User – Interface – Design: Usability in Web- und Software-Projekten“ laden (4MB)
Rezension in c’t 17/2015
auf Seite 190 der Ausgabe 17/2015 erschien die Rezension von Ulrich Schmitz
„[…] Der Webdesign-Praktiker Florin wendet sich an Betreiber von Online-Angeboten, an Entwickler – aber auch an Entscheider im Management. […] Der Schwerpunkt liegt auf konzeptionellen und designtechnischen Fragen. […] Prozessanalysen, Entwurfsmodelle von Anwendungsgesichtern sowie Planungs-Handouts bestimmen den Praxisratgeber.
[…] ist Florins Buch ein inspirierender Praxisbegleiter. Es wartet mit einer Fülle interessanter Ideen und Lösungsvorschläge auf, um neue oder bereits bestehende Websites nach Usability-Gesichtspunkten zu optimieren.“
Leseprobe:
Kapitel 1 „Hä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 Konzeptions- oder 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]
- Cursor an der Stelle platzieren, wo das Bild erscheinen soll. [„erscheinen“ = Ziel des Nutzers]
- Im Menü „Einfügen“ den Eintrag „Bild“ anklicken. [genaue Angabe des Ortes und der Aktion]
- Im erscheinenden Dateiauswahlfenster die gewünschte Datei wählen. (Die Dateiauswahl ist ausführlich in XY beschrieben) [ergänzender Hinweis für Novizen]
- Den Button „Einfügen“ anklicken. [Angabe, wie die Aktion ausgelöst wird – das hört sich schon nach fast fertig an.]
- Das Bild erscheint an der Cursor-Position. [das Ziel ist erreicht]
- Durch Rechtsklick auf das Bild erhalten Sie Möglichkeiten zur Formatierung des Bildes, diese sind in Kapitel XY beschrieben. [Hinweise zu wahrscheinlichen Folgeaktionen]
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 320) 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:
Prototypische Webseite | Pragmatische Software | |
---|---|---|
Nutzung | gelegentlich | intensiv, dauerhaft |
Kontext | Freizeit | Arbeit |
Motivation | eigene, selbstbestimmt | zielgerichtet, fremdbestimmt |
Ziel | Unterhaltung, Information | Funktionalität, Aufgaben erledigen |
Design | eigenständig, ein wenig verspielt | funktional, zurückhaltend |
Farbigkeit | meist deutliche Farbigkeit | Farbigkeit nur zur Akzentuierung |
Inhalte | Webseiten-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.
PDF-Auszug von „User – Interface – Design: Usability in Web- und Software-Projekten“ laden (4MB)