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:
- Die Entwicklung ist flexibler als beim sogenannten Wasserfallmodell [8].
- Kunden und Anwender werden in den Entwicklungsprozess einbezogen.
- Prototyping wird unterstützt.
- Das Produkt ist aufgabenangemessen; Stichwort Effektivität.
- Die Bedienbarkeit der Software kann während der Entwicklung verbessert werden; Stichwort Effizienz.
- Die Akzeptanz bei den Benutzern wird gesteigert; Stichwort Zufriedenheit.
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.
