User Experience und Requirements-Engineering für Software-Projekte

von Matthias Müller-Prove in IM Information Management & Consulting (3)2005

Zur Gestaltung von Software benötigt man eine genaue Analyse der Nutzungsanforderungen. Ausgebildete User Experience Fachleute übernehmen diese Aufgabe, die weder von Marketing noch Entwicklungsabteilung angemessen ausgefüllt werden kann. Es werden die Methoden vorgestellt, die beim Requirements-Engineering zum Einsatz kommen.

1 Worte und Taten

Halten Sie Autofahren für umweltschädlich? – Fahren Sie täglich mit dem eigenen Wagen zur Arbeit? Wenn Sie beide Fragen mit ja beantworten, ist das zwar nicht gut für die Umwelt, aber ein typisches Antwortmuster.

Der Mensch an sich ist ein schizophrenes Wesen. Worte und Taten stehen oft im Widerspruch zueinander. Das zu erkennen und die Konsequenzen daraus zu ziehen ist für manche Firmen ein harter Lernprozess.

Ein Motorradhersteller entwickelte ein neues Instrument fürs Cockpit, um die Sicherheit beim Fahren zu erhöhen. Neben dem Tacho sollte ein verkleinerter Umriss eines Motorradfahrers sich entsprechend der Straßenlage des Motorrades nach rechts oder links neigen, um dem Fahrer bedrohliche Schieflagen anzuzeigen. Nach erfolgreicher Entwicklung des Instruments wurde das Projekt allerdings eingestellt. Was war geschehen? Bei Testfahrten hatte sich herausgestellt, dass die Fahrer nicht mehr in der Lage waren einfache Kurven zu nehmen. Regelmäßig verloren sie die Kontrolle über das Motorrad und fanden sich neben ihrer Maschine wieder.

Das Instrument arbeitete korrekt. Aber das Selbstbild und das angezeigte Realbild wichen drastisch voneinander ab. Der Fahrer steuerte gegen und sich damit in den Graben. Es verhält sich nämlich so, dass zum Einlenken in eine Linkskurve der Motorradfahrer einen Lenkimpuls nach rechts geben muss. Das Motorrad fällt dadurch nach links und die Lenkbewegung folgt dem Fallen in die Linkskurve hinein. Was sich hier so kompliziert anhört ist für Motorradfahrer selbstverständlich; ja sogar so selbstverständlich, dass es ihnen nicht bewusst ist, und sie durch das Anzeigeinstrument verwirrt werden und falsch reagieren.

Die Unterschiede zwischen Selbsteinschätzung und Realität sind mitunter sehr subtil. Sie können aber, wie das Beispiel zeigt, fatale Auswirkungen haben. Der Software-Bereich bildet da leider keine Ausnahme. So fällt denn die Selbsterkenntnis eines Kunden auch besonders angenehm auf, der da sagte, „Geben Sie mir nicht was ich will, sondern das was ich brauche.“

2 User Experience

Damit die Produktentwicklung optimal auf die Bedürfnisse der Anwender ausgerichtet werden kann, bedarf es einer Umorganisation der Firmenstruktur. Gleichberechtigt zu der Entwicklungs- und Marketingabteilung sorgt die neue User Experience Abteilung für den notwendigen Anwender-Fokus [1]. Die User Experience Experten sammeln die Requirements ein – dazu später mehr – und vertreten diese gegenüber den Kollegen aus Marketing und Entwicklung. Sie agieren quasi als Anwälte der Benutzer.

Das erklärte Ziel der User Experience ist die Schaffung eines Computer-Systems oder Programms, das in allen Aspekten, mit denen ein Anwender in Berührung kommt, aufeinander abgestimmt ist und so ein harmonisches Ganzes bildet. Don Norman, der den Begriff in den späten achtziger Jahren bei Apple Computer einführte, verstand darunter insbesondere auch die Bereiche Verpackung beziehungsweise Produkt-Website und Download-Experience, sowie die Installation und Inbetriebnahme des Produkts. In »Emotional Design« [2] ergänzt Norman später, dass User Experience die drei Bereiche Grafikdesign, Usability und Branding umfasst.

Auf diese Weise kann eine einheitliche und vertraute Umgebung geschaffen werden, die es dem Anwender erlaubt sich ganz und gar auf seine Tätigkeit zu konzentrieren ohne von technischen Details abgelenkt zu werden. Ein gutes System zeichnet sich also unter anderem dadurch aus, dass es gut benutzbar ist. Usability – zu deutsch Gebrauchstauglichkeit – ist die entsprechende Produkteigenschaft. Sie ist definiert als das Zusammenspiel von Effektivität, Effizienz und Zufriedenheit im Umgang mit einem Produkt. Effektivität meint, dass das Werkzeug den Anwender in die Lage versetzen muss eine bestimmte Aufgabe zu erfüllen. Der Aufwand dafür sollte möglichst gering sein, die Handhabung des Werkzeugs also möglichst effizient. Drittens muss der Anwender mit dem Werkzeug zufrieden sein. Unzufriedene Anwender fühlen sich nämlich bald gestresst und überfordert und können dadurch ihre eigentliche Tätigkeit nicht mehr mit der gebotenen Sorgfalt ausfüllen.

Woher weiß nun aber ein Produktgestalter, welche Anforderungen ein Benutzer an eine Software hat, wenn der prinzipiell nicht in der Lage ist diese angemessen und detailgenau zu formulieren? Die Antwort liegt im Requirements- und Usability-Engineering. Das ist ein vielschichtiger, iterativer Prozess, in dem sowohl die Erwartungen der künftigen Anwender, als auch ihre (menschlichen) Verhaltensweisen berücksichtigt werden.

Dieser Prozess wird von vielen Experten getragen, deren Aufgabenbereiche im folgenden Abschnitt vorgestellt werden.

2.1 Aufgaben der User Experience

Damit ein User Experience Projekt Erfolg hat, müssen Spezialisten aus zwei unterschiedlichen Lagern vertreten sein. Zum einen benötigt man Fachleute, die sich auf das Erheben von Usability-Daten verstehen, wie zum Beispiel den Usability-Requirements-Engineer und den Usability-Testing-Engineer. Ihre Aufgabe ist das objektive Beobachten der Arbeitssituation der Anwender, bzw. die Durchführung von Tests in Usability-Laboren. Die Methoden, die dabei zur Anwendung kommen, werden im Abschnitt Requirements-Engineering vorgestellt.

Die zweite Kategorie sind die kreativen Gestalter, die Interaktionsdesigner und Visual-Designer. Ihre Aufgabe ist das Entwerfen und Konstruieren neuer Lösungen für ein Produkt. Dabei dürfen sie auch gerne mal über das Ziel hinausschießen, da ihre Vorschläge wiederum von den Usability-Testern validiert werden bevor sie letztlich fürs Produkt umgesetzt werden.

Es gibt User Experience Fachleute, die mehr als eine Teildisziplin beherrschen. Eine Kombination über die Grenzen der Kategorien ist aber eher selten anzutreffen. Zu groß sind die Mentalitätsunterschiede, die einen Usability-Analytiker von einem kreativen Designer unterscheiden [3]. Das wird klarer, wenn nachfolgend die einzelnen Gebiete etwas genauer erläutert werden.

Ein Requirements-Engineer ist für die Ermittlung der Kundenbedürfnisse zuständig. Die konkreten Eindrücke von Arbeitssituationen beim Kunden, die er durch Site-Visits gewinnt, werden von ihm zu Benutzerprofilen oder Personas abstrahiert [4][5]. Es entstehen Szenarien typischer Arbeitsabläufe. Das Ausformulieren hilft dabei, sich den Kontext zu verdeutlichen, in dem die Software eingesetzt werden soll. Dadurch wird für das Projektteam transparent, für welche Art von Benutzern in welchem Arbeitsumfeld die Software eigentlich entwickelt wird. Hier gilt es den Unterschied zwischen dem, was die Kunden wollen und dem, was sie wirklich brauchen herauszuarbeiten. Ein häufig gemachter Fehler ist nämlich, dass die Wünsche der Kunden direkt in Produktanforderungen übersetzt werden, anstatt den gesamten Nutzungskontext zu betrachten.

Anhand der Ergebnisse der Requirements-Analyse entwickeln die Interaktionsdesigner ein Gesamtkonzept, das die Anforderungen der Kunden erfüllt und das in sich stimmig ist. Dabei müssen sie zusätzlich darauf achten, dass ihre Ideen mit den jeweiligen Styleguides und software-ergonomischen Prinzipien in Einklang stehen. Ihre Entwürfe verfeinern sie dann zu den so genannten User Interface Spezifikationen (kurz „UI-Specs“), nach denen die Entwickler die Software implementieren und die Mitarbeiter der Qualitätsabteilung die Zwischenversionen testen.

Parallel zu den Interaktionsdesignern arbeiten die Visual-Designer an den grafischen Elementen der Software. Das Layout der Kontrollelemente in Dialogfenstern, die Gestaltung von Programm-Icons und von Icons in Werkzeugleisten sind nur einige Aufgaben. Für die Gestaltung dieser Elemente bedarf es eines besonderen Könnens in Grafikdesign und visueller Kommunikation. Als Beispiel sei hier das Icon für das Absenden einer E-Mail angeführt. Ein Briefkasten scheint dafür eine gute Metapher zu sein. Wer jetzt an eine gelbe Metallbox mit Schlitzen denkt, hat für deutsche Kunden eine gute Idee zur grafischen Umsetzung. Außerhalb Deutschlands trifft man damit aber nur auf Unverständnis. In England sind Briefkästen rot – in den Vereinigten Staaten hingegen sind sie blau und haben ein gewölbtes Kopfteil.

In anderen Teilen der Welt gibt es auch andere kulturelle Normen. So hatte General Magic Mitte der neunziger Jahre gegen soziale Konventionen Südostasiens verstoßen, als sie für das PDA-System Magic Cap die Suchfunktion mit einer Animation versahen. Zur Überbrückung der Wartezeit erschien ein Hund auf dem Computer-Desktop des Benutzers und schnüffelte in Dokumenten nach dem Suchbegriff. – In Südostasien gehört ein Hund nicht auf den Tisch! So etwas wird als unkultiviert wahrgenommen. Ein professioneller Visual-Designer ist für solche interkulturellen Fragestellungen sensibilisiert und kann damit Probleme vermeiden, ehe das Produkt im internationalen Markt scheitert. Es ist ein Design anzustreben, das unbedenklich in allen Ländern und Kulturen eingesetzt werden kann. General Magic hatte übrigens rechtzeitig vor der Markteinführung der asiatischen Version den Hund durch eine unbedenkliche Eule ersetzt.

Abschließend der Usability-Testing-Engineer. Er untersucht wiederholt die aktuellen Prototypen auf Probleme in der Bedienbarkeit. Dazu führt er im Usability-Lab Studien durch, in denen eine Auswahl von echten Benutzern die neuen Konzepte der Software erproben. Werden hier akute Probleme aufgedeckt, können sie mit vertretbarem Aufwand in den Spezifikationsdokumenten nachgebessert werden, ohne den gesamten Terminplan in Gefahr zu bringen.

Es sei an dieser Stelle angemerkt, dass der Usability-Testing-Engineer vor allem eine beobachtende Tätigkeit hat. Unvoreingenommen führt er die Tests durch und berichtet objektiv die Ergebnisse an die Interaktionsdesigner. Es ist nicht seine primäre Aufgabe Verbesserungsvorschläge zu machen – dafür sind die Interaktions- und Visual-Designer besser geeignet.

3 Arten von Software

Es lassen sich drei Arten von Anwendungssoftware unterscheiden: Individualsoftware, Standardsoftware und Open Source Software. Der Entwicklungsprozess kann dabei sehr unterschiedlich aussehen, da es jeweils ein eigenes Verhältnis zum zukünftigen Nutzer der Software gibt.

Individualsoftware basiert auf einem Auftrag, den ein einzelner Kunde an ein Softwarehaus vergibt. Die Ausgangslage ist günstig und es bietet sich an, mit allen Beteiligten einen partizipativen Softwareentwicklungsprozess aufzusetzen. Dazu wird ein Projektteam etabliert, in dem Vertreter von Kunden- und Herstellerseite gemeinsam den Leistungsumfang der Software in iterativen Schritten definieren. Das Projektteam steuert und begleitet die Entwicklung der Software über Entwürfe, Prototypen, bis hin zum fertigen System und dessen Einführung [6]. Dieses Vorgehensmodell ist auch sehr gut mit dem User Centered Design vereinbar, da die zukünftigen Anwender wahrscheinlich Mitarbeiter im Unternehmen des Kunden, in jedem Fall aber bekannt sind.

In Abbildung 1 sind die iterativen Entwurfsphasen gut zu erkennen.

Abbildung 1: Spiralmodell der Software-Entwicklung nach Barry W. Boehm 1988; Quelle [7]

Iterative, beziehungsweise evolutionäre Systementwicklung bietet eine Reihe von Vorteilen:

Standardsoftware, wie zum Beispiel die Bürosoftware StarOffice von Sun, muss sich am Markt bewähren. Es gibt keinen Auftraggeber, sondern tausende von Käufern und Anwendern, die dem Entwicklungsteam per se unbekannt sind. Partizipative Softwaregestaltung kann also nicht mehr stattfinden. Um trotzdem auf die Interessen der Anwender eingehen zu können, kommt der User Experience Abteilung die wichtige Aufgabe zu, den Ansatz des User Centered Design im Product Life Cycle zu etablieren. Sie führen Site Visits durch und benutzen weitere Methoden, um sich über typische Nutzer und deren Anwendungskontext zu informieren. Außerdem ist Kundenfeedback eine wichtige Quelle für Verbesserungen, wenn ein neuer PLC Prozess für die nächste Produktversion ansteht.

Eine neue Kategorie bildet Open Source Software. Hier ist weder das Produktteam, noch der Anwenderkreis fest umrissen.

Die Entwicklung eines Programms geht häufig auf das Eigeninteresse eines Entwicklers zurück. Eric Raymond [9]: „Every good work of software starts by scratching a developer’s personal itch.“ Ist die Idee gut, so wird eine Entwickler-Community die Software voran tragen. Die Anwender werden als Co-Entwickler betrachtet und sorgen mit Fehlermeldungen und Vorschlägen für die stetige Verbesserung. Professionelle User Experience Fachleute können ebenfalls in diesen anarchisch anmutenden Prozess einwirken und für ein Usability Niveau sorgen, das mit den anderen Software-Arten vergleichbar ist [10].

Abbildung 2 zeigt die wichtige Rolle der Designer (und Usability Experten), die zwischen den Usern und den Codern vermitteln.

Abbildung 2: Verschiedene Gruppen haben Einfluss auf den Code; Quelle: [11]

Für die Erstellung von Web-Angeboten lässt sich sagen, dass Intranet-Anwendungen am besten mit Individualsoftware vergleichbar sind. Öffentlich zugängliche Websites ähneln am ehesten Standardsoftware – obwohl es einen Auftraggeber gibt, sind die zahlreichen Besucher der Site per se unbekannt. Ein Aquivalent zu Open Source Software kann man im World Wide Web in den Bereichen Wikis und Blogs identifizieren. Wikipedia ist das prominenteste Beispiel für ein Web-Projekt, das von einer Community getragen wird.

4 Requirements-Engineering

Anforderungen an eine neue Version einer Standardsoftware kommen aus den verschiedensten Richtungen. Es werden allgemeinere Marktanforderungen gesammelt, wie beispielsweise Accessibility – eine Bedingung zum Einsatz von Software bei US-Behörden – oder auch die Kompatibilität mit existierenden Systemen und Dateiformaten. Weitere Requirements können von Großkunden und OEM-Partnern kommen, die mitunter sehr genaue Vorstellungen von der Software haben. Ob eine direkte Umsetzung dieser Wünsche zu einem gut benutzbaren und sinnvoll einsetzbaren Produkt führt sei dahingestellt.

Genau so wenig wie eine Einkaufsliste mit Zucker, Milch, Mehl und Eiern einem Kuchen gleicht, sind Feature-Listen hinreichend für ein Software-Produkt [1][4]. Erst mit Wissen über die zukünftigen Anwender, ihre Aufgaben und Ziele und den zugehörigen Nutzungskontext kann man ein Gesamtkonzept für das Produkt entwickeln.

Auf die Bedeutung von Benutzerprofilen und Personas ist in diesem Artikel bereits hingewiesen worden. Zwischen Aufgaben und Zielen ist zu unterscheiden, da die aktuell beobachteten Arbeitsschritte nicht unbedingt identisch in der Software nachgebildet werden müssen, um dasselbe Ziel zu erreichen. Es kann sich nämlich in der Konzeptphase herausstellen, dass man mit einer anderen Aufgaben(ein)teilung wesentlich effizienter arbeitet.

Desweiteren werden Benutzungsprobleme gesammelt. Dabei wird zu jedem konkret ermittelten Problem ein Requirement formuliert, für das später eine Lösung gefunden werden muss. Im Falle von OpenOffice.org kommen derartige Anforderungen auch direkt aus der Open Source Community. In jedem Fall ist es aber wichtig, dass die Lösung nicht vorweggenommen wird, da man an dieser Stelle im Prozess noch keinen Überblick über die neue Version besitzt. Außerdem liegt die Kernkompetenz der Requirements-Engineers nicht in der Gestaltung von Software.

Die Methoden zum Aufspüren individueller Produktanforderungen und Usability-Problemen können in zwei Gruppen eingeteilt werden. Die Ergebnisse der subjektiven und objektive Herangehensweisen ergänzen einander dann zu einem Gesamtbild der Produkt-Requirements.

Ein nicht ganz fiktives Beispiel

Ein Requirements-Engineer fasst mehrere beobachtete Begebenheiten mit folgender Geschichte zusammen:

Szenario: Carla muss ein längeres Gutachten über einen Immobilienfonds anfertigen. Bevor sie um 11 Uhr in ein Meeting gerufen wird, schließt sie das Dokument. Am Nachmittag setzt sie sich erneut an das Gutachten. Ein Doppelklick auf das Datei-Icon öffnet das Dokument an der Stelle, an der sie es am Vormittag verlassen hatte. Sie liest die letzten Zeilen und arbeitet dort weiter. Bevor sie Feierabend macht, schickt sie den aktuellen Stand des Gutachtens per E-Mail an Marc. Als Marc am nächsten Morgen das Dokument öffnet, findet er sich zunächst nicht zurecht. Er stellt fest, dass Seite 17 angezeit wird. Er scrollt zum Anfang, um den Titel des Dokuments zu lesen.

Desweiteren formuliert er Problem und Anforderung und versieht das Requirement mit einer Priorität:

Problem: Dokumente, die nicht auf Seite 1 geöffnet werden, verwirren den Leser.
Anforderung: Fremde Dokumente sollten auf Seite 1 geöffnet werden – eigene Dokumente dort, wo sie geschlossen wurden, da die zuletzt sichtbare Passage eine wichtige Information für den Autor darstellen könnte.
Wichtigkeit: medium

Für eine Anforderung, die in dieser Art und Weise vorliegt, ist es relativ einfach eine Lösung zu erarbeiten. StarOffice 8 (und OpenOffice.org 2.0) wird im Dokument vorhandene Informationen über den letzten Autor benutzen, um beim Öffnen entweder den Erwartungen des Autor oder denen eines neuen Lesers zu entsprechen.

4.1 Subjektive Methoden

Subjektive Methoden beziehen sich unmittelbar auf die Beurteilungen und Einschätzungen der Benutzer. Bei Sun nennt sich dieser Teil des Requirements-Engineering „Voice of the Customer“. Mittels Online-Fragebögen werden mehrere hundert Kunden gebeten die aktuelle Software zu bewerten und Wünsche für neue Funktionen zu äußern. Durch den Open Source Ansatz von StarOffice werden Fragebögen auch auf der Community-Website von OpenOffice.org eingesetzt. Die Zahl der Antworten ist dabei ungleich größer und beträgt bei der letzten Umfrage mehr als 200.000.

Man muss sich bei solchen Aktionen immer die Frage stellen, ob die Antworten für die Anwendergruppe der Software repräsentativ sind. Bei gezielten Fragebogenaktionen hat man dieses Problem ganz gut unter Kontrolle; aus einem Adresspool werden bestimmte Kunden ausgewählt und um Mithilfe gebeten. Bei öffentlichen Web-Formularen ist dagegen nie klar, wer diese ausfüllt. Es steht immer zu befürchten, dass eine aktive Minderheit eine schweigende Mehrheit überstimmen könnte. Positiv ist aber anzumerken, dass Fragebögen gut skalieren, sowohl im Stichprobenumfang, als auch in geografischer Hinsicht.

Typisch sind auch vom Marketing durchgeführte Interviews beim Kunden und Diskussionen in Fokusgruppen, die zusätzlich dabei helfen sollen, die Erwartungen des Kunden zu ermitteln. Wichtig ist die Unterscheidung zwischen Kunden und echten Anwendern. Der Blickwinkel eines Administrators, der in seinem Unternehmen für Software-Käufe verantwortlich ist, ist sehr verschieden von dem Mitarbeiter, der tagtäglich mit der Software arbeitet.

Es bieten sich bei Diskussionen sinnvolle Möglichkeiten der Requirements-Analyse, insbesondere wenn man seinen Gesprächspartnern im wortwörtlichen Sinne zuhört. Mark Federman führt das sehr schön in einer Keynote anlässlich der »Customer Relationship Management Conference 2001« aus [15]. Das natürliche Gespräch zwischen Anwender und Requirements-Engineer birgt in seinen Nuancen wichtige Einsichten für die Gestaltung der Software, die in einer rein textlichen Fragebogenaktion verloren gegangen wären.

4.2 Objektive Methoden

Wir Menschen sind uns nicht immer – oder sogar nur selten – darüber bewusst, was und warum wir etwas tun. Um so schwerer fällt es uns auch, uns von emotionalen Einflüssen frei zu machen und eine Situation richtig bzw. neutral einzuschätzen [12]. Objektive Methoden setzen nun anstelle der benutzereigenen Bewertungen die Beobachtung durch Usability Experten. Kundenbesuche (Site Visits) haben das Potential bis dato unbekannte Arbeitsabläufe und Interaktionsfacetten zu entdecken, da die User Experience Fachleute den Benutzer im Kontext seiner alltäglichen Arbeitsumgebung studieren. Dazu zwei Beispiele.

Über einen Zeitraum von vier Monaten haben Victor González und Gloria Mark zehn Mitarbeiter einer Investment-Firma begleitet und deren Aktivitäten protokolliert und zeitlich gemessen [13]. Die Studie hatte das überraschende Ergebnis, dass die Zeitspanne, die ein Bildschirmarbeiter ungestört an einer Aufgabe verbringt, in etwa 11 Minuten beträgt. Erkenntnisse dieser Art sind höchst interessant, wenn man Software für dieses Nutzungsumfeld konzipieren möchte. Computergestützte Arbeitsabläufe müssen unterbrechbar und nach der „Störung“ wieder leicht fortsetzbar sein.

Vor einigen Jahren bekamen wir im Projektteam eines Web-Editors recht häufig von Anwendern den Fehler gemeldet, dass sich der Farbwahldialog nach dem Öffnen sofort wieder schloss, ohne dass man die Chance gehabt hätte eine Farbe zu wählen. Leider war der Fehler von uns nicht zu reproduzieren. Was sollten wir also fixen? Der Zufall wollte es, dass ich bei einem Kundenbesuch neben einem Benutzer saß, dem genau dieses Phänomen wiederfuhr. Er klickte doppelt auf das Icon zum Öffnen des Farbwählers (obwohl doch ein Einfachklick gereicht hätte). Der zweite Klick des Doppelklicks hatte nun den ungünstigen Effekt genau über der Schaltfläche zum Abbrechen des gerade eben geöffneten Dialogs herniederzurauschen und so den Dialog wieder zu schließen. Merke: Anwender halten sich nicht immer an die User Interface Guidelines. Dem ist seitens der Software vorzubeugen indem man – in diesem Beispiel – den zweiten Klick geflissentlich ignoriert oder indem man sicher stellt, dass der zweite Klick im Dialog keinen Schaden anrichtet.

Eine weitere wichtige objektive Methode ist das Usability-Testing. In einer Laborsituation werden Testpersonen an das eigene Produkt, das der Konkurrenz oder an einen Prototypen gesetzt, um damit eine Reihe von Aufgaben zu bearbeiten. Ein Prototyp muss dabei nicht immer ein funktionales Computerprogramm sein. Mit Papier-Prototypen lassen sich sehr kostengünstig verschiedene Designalternativen ausprobieren [14]. Die Handlungen der Testpersonen werden beobachtet und aufgezeichnet. Um etwas von ihren Überlegungen für die spätere Auswertung zu erfahren, werden sie gebeten, während sie die Aufgabe bearbeiten, laut zu denken. Durch die so gewonnenen Daten lassen sich dann Rückschlüsse auf das »Mentale Modell« des Benutzers ziehen, das er sich von der Applikation gemacht hat. Wenn das Mentale Modell des Benutzers nicht dem Systemzustand entspricht, kommt es zu Verwirrung und „Bedienfehlern“. Im einleitenden Beispiel führte genau so eine Situation zum Sturz des Motorradfahrers. Da in Usability-Tests aber das Produkt und nicht der Proband getestet wird, deuten solche Fehler immer auf Usability-Probleme des Produkts.

5 Zusammenfassung

Der Beitrag professioneller User Experience Fachleute ist wesentlich für eine auf die Anwender ausgerichtete Produktentwicklung. Erst wenn man ein klares Bild der zukünftigen Anwender, ihrer Ziele und des Nutzungskontexts hat, können Anforderungen so formuliert und priorisiert werden, dass das neue oder weiterentwickelte Produkt eine Lösung für die tatsächlichen Probleme der Kunden darstellt.

In Bezug auf die Anwender fungieren User Experience Fachleute als Analytiker. Aus den gewonnenen Erkenntnissen gestalten sie ein Gesamtkonzept für das Produkt, das sie zusammen mit der Entwicklungsabteilung realisieren. Dabei haben sie die vornehme Aufgabe als „User-Anwalt“ die Interessen und Bedürfnisse der Anwender zu vertreten.

Literaturangaben

à propos