Leichtes Fremdeln

Inhaltsverzeichnis

Schon vor Jahren sagte Ben Shneiderman einen Paradigmenwechsel in der Softwareentwicklung voraus (in [1]): Bisher ging es um Technik, Geschwindigkeit und Funktionen; in Zukunft geht es in erheblich größerem Maße um menschliche Bedürfnisse, Herausforderungen und Wünsche. Dementsprechend haben Begriffe wie Kundenerfahrung, Nutzererlebnis oder, aus dem Englischen, User Experience (UX) seit einiger Zeit Konjunktur.

Selbstverständlich bleibt Funktion wichtig, aber sie ist nicht einziger Sinn. Das verändert die Arbeitsweise, wie Menschen in Teams zukünftig neue Software entwickeln, und erfordert neue Prozesse, die den Anwender während der Entwicklung im Blick behalten. Wer benutzt die Software, warum und wie? Was unterscheidet einen Anwender vom anderen? Die Beantwortung dieser Fragen erfordert eine andere Blickweise auf Software. Nur in Form eines sogenannten User Experience Engineers findet diese Perspektive in den Teams ausreichende Berücksichtigung. Diese Entwicklung soll langfristig zu mehr Nähe zum Anwender führen. Das erfordert neue Werkzeuge und Richtlinien. Ein UX-Experte kann diese Aufgaben übernehmen. Beispielsweise ist er für die Entwicklung von Prototypen und das Testen der UX verantwortlich.

Wie ein Start in das neue Computerzeitalter aussehen kann, hat Apple vor Jahrzehnten gezeigt. Mitarbeiter des Xerox PARC in Palo Alto hatten 1973 einen Rechner namens Xerox Alto entwickelt, der über die weltweit erste grafische Benutzerschnittstelle verfügte. Alle heute verbreiteten Betriebssysteme ähneln diesem Ansatz in vielen Aspekten. Dennoch hatte der Xerox Alto damals keinen Erfolg. Der Preis war zu hoch und das Management nicht begeistert. Erst Apple brachte ab 1984 mit dem Macintosh diese grafische Benutzerschnittstelle auf den Markt. Im Zentrum stand eben nicht die Technik, sondern vor allem der Mensch. In den letzten Jahren verhalf dieser Blickwinkel dem Unternehmen erneut zu Erfolgen; man denke nur an den iPod und seine Nachfahren.

Paradigmenwechsel in den Unternehmen

Viele Entwicklungsteams befinden sich heute noch im „alten Computerzeitalter“. Alles dreht sich um die technische Umsetzung, um Techniken und Features. Diese Dinge sind wichtig – keine Frage. Aber der Mensch vor dem Computer profitiert davon zunächst nicht. Denn wie Vinayak Hegde in den „97 Things ...“ [2] erkannt hat: „for the end-user, the interface is the system“. Effektiv ist in dieser Sichtweise am Ende nur das, was dem Anwender nützt. Die Beurteilung der Auswirkungen für Nutzer fällt Softwareentwicklern schwer. Denn diese Auswirkungen erscheinen ihnen schwammig und nicht greifbar, subjektiv und nicht messbar. Darum halten Entwickler gerne am alten Computerzeitalter fest. Sie achten auf das, was sie beherrschen, den Computer, und vernachlässigen den Menschen. Das mag überspitzt klingen, aber die Praxis zeigt, dass genau das regelmäßig passiert. Nach einer Untersuchung von Richter und Flückiger [3] haben 92 % der Entwickler keine oder wenige Kenntnisse der Mensch-Computer-Interaktion. Fast die Hälfte (47 %) der grafischen Benutzeroberflächen erstellen zudem Softwareentwickler ohne fremde Hilfe. Nur 27 % der Entwickler beziehen die späteren Anwender mit ein.

Unternehmen trennen in der Regel klar zwischen Vertrieb und Entwicklung. Für die Mehrzahl der Prozesse ergibt diese Unterscheidung Sinn. Im neuen Computerzeitalter entstehen jedoch dadurch einige neue Herausforderungen. Die Bedürfnisse der Anwender erreichen die Softwareentwicklung stets nur indirekt. Zusätzlich sind sie auf ihrem Weg zum Entwickler der Abstraktion ausgesetzt. Je mehr Zwischenstationen, umso dramatischer die Situation.

Eine weitere Zwischenstation außer dem Vertrieb ist häufig das Management – oder der Kunde selbst. Weitere Hürden sind die geografische Entfernung, Unternehmensgrenzen, methodische Lücken, kulturelle Hürden und die organisatorische Entfernung. Im neuen Computerzeitalter gilt es, diese Hürden zu überwinden und Software für die Realität zu entwickeln. Dazu kennt ein UX Engineer verschiedene Methoden: In Contextual Inquiries beobachtet er beispielsweise reale Benutzer in ihrem Arbeitsalltag. Durch Personas und Szenarien vermittelt er Softwareentwicklern den Anwendungskontext. Mit Storyboards erklärt er die tatsächliche Produktnutzung, und in Tests verwendet er realistische Szenarien. Diese Werkzeuge helfen, die Distanz zum Anwender zu reduzieren. Selbstverständlich muss der Einsatz dieser Werkzeuge maßvoll und zielgerichtet erfolgen. Wie der Enzyklopädist Denis Diderot feststellte: „Die einen, so scheint mir, haben viele Werkzeuge und wenig Ideen; die anderen haben viele Ideen und gar keine Werkzeuge.“

Drei Erfolgskriterien für Software

Durch die Werkzeuge wird die Erfüllung der Bedürfnisse greifbar. Ein UX Engineer macht Bedienbarkeit messbar. Damit entsteht neben Technik und Funktion ein neues Kriterium für Erfolg. Dieser Maßstab ist eine solide Grundlage für fundierte Entscheidungen, denn ein UX-Experte kann einem Team erklären, warum bestimmte Konzepte sinnvoll sind.

Nur durch einen Experten rücken subjektive Einschätzungen in den Hintergrund. Denn er ist in der Lage, Fakten zu schaffen und zu nutzen. Alle UX-Methoden erzeugen Fakten, und deren richtige Interpretation lässt sich überprüfen. Anhand der oben genannten Werkzeuge wird das besonders deutlich: Contextual Inquiry und Fragebögen dienen dem Engineer zum Sammeln und Auswerten von Daten. Personas und Szenarien erstellt er daraus. Aus den Ergebnissen der Analyse von Benutzern und Kontext resultieren Use Cases, und Prototypen prüft der Engineer in Tests objektiv.

Damit eine erfolgreiche UX entsteht, muss der Fachmann außer den richtigen Methoden die passenden Guidelines und Styleguides kennen. Er kennt die sieben in der DIN EN ISO 9241-10 definierten Grundsätze für User Experience: Aufgabenangemessenheit, Lernförderlichkeit, Fehlertoleranz, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität und Individualisierbarkeit. Und er weiß vor allem, wie sich diese Grundsätze in der Praxis realisieren lassen. Er nutzt Styleguides und kennt deren wichtige Inhalte:

• technische Rahmenbedingungen,
• visuelles Design,
• technische Umsetzbarkeit und
• Terminologie.

So muss man das Rad nicht für jede Benutzerschnittstelle neu erfinden. Styleguides und Richtlinien sind die Grundlagen für die individuelle Ausgestaltung der Konzepte. Wenn sie gebrochen werden, sollte das stets bewusst erfolgen und nicht aus Unkenntnis.

Das hört sich nach Mehraufwand fürs Team an. Aber durch einen UX Engineer entsteht keine zusätzliche Arbeit, sondern das Gegenteil ist der Fall: Er nimmt den Entwicklern sogar Arbeit ab. Denn er entwickelt mit den Werkzeugen Modelle, die der Vertrieb an die Kunden weiterleitet. Die Softwareentwicklung erhält so nur mit den Kunden abgestimmte Varianten. Entwürfe und Modelle sowie deren Optimierung und Überprüfung bilden die Grundlage für benutzbare Lösungen.

Ein UX Engineer übernimmt somit einen Teil der Entwickleraufgaben. Seine Contextual Inquiry basiert auf vorhandenen Systemen und schafft daher einen Bezug zur Erfahrungswelt der Benutzer, indem seine Personas und Szenarien die Bedürfnisse modellieren. Seine Storyboards zeigen Wege der Bedürfniserfüllung, und die Use Cases repräsentieren schon die geplanten Funktionen. Prototypen zeigen die Abläufe aus Benutzersicht; ein UX Engineer entwickelt sie, um das User-Interface-Konzept auf seine Tauglichkeit zu prüfen. Diese Prototypen stellen die Konzepte dabei besonders anschaulich dar.

Solche Prototypen berücksichtigen in der Regel folgende Aspekte: Auswahl geeigneter GUI-Elemente und ihre räumliche Anordnung, Aufteilen und Strukturieren der Informationen, Einsatz und Verbindung von Fenstern und Sichten, zentrale Navigations- und Interaktionselemente sowie Interaktionsmuster (wie Fehlerbearbeitung, Widerruf, Wiederholen, direkte Manipulation, Drag & Drop). Ein UX-Eperte nutzt häufig alltägliche Werkzeuge für die schnelle Entwicklung von Prototypen: Papier, Whiteboards, Präsentationen, Bildbearbeitungsprogramme, Grafikprogramme und Multimediaprogramme.

Zusätzlich kennt er die wichtigen Spezialwerkzeuge (wie die Drahtgittermodell-Software Axure RP und Balsamiq Mockups) für das Prototyping und einfache Programmierwerkzeuge (HTML-Editoren, Microsofts Expression Blend und Adobes Flex). Durch dieses Prototyping erhalten alle Projektmitarbeiter frühzeitig ein Mockup des Systems. Den Umfang des Prototyps stimmt der UX Engineer anhand folgender Kriterien mit den Beteiligten ab: Funktionsumfang (partiell vs. vollständig), Funktionstiefe (flach vs. tief), Darstellungstreue (schematisch vs. realistisch), Interaktivität (statisch vs. dynamisch), Datengehalt (fiktiv vs. real) und technische Reife (simuliert vs. realisiert). Bei der Detaillierung des Prototyps lassen sich so die konkreten Erfordernisse eines Projekts berücksichtigen. Den fertigen Prototyp testet der Fachmann mit den Anwendern.

Ein Bild von der Bedienbarkeit

Jeder kann sich jederzeit ein Bild von der Bedienbarkeit machen – so scheint es. Zunächst stellt sich die Frage, was das Ziel eines Tests ist. Steckt man mitten im Gestaltungsprozess oder kurz vor der Fertigstellung? Außerdem unterscheidet man formative und summative Tests. Erstere dienen der Verbesserung, Letztere der Qualitätsprüfung. Erstere kommen mit vier bis sechs Anwendern aus, Letztere benötigen mindestens zehn, häufig deutlich mehr. Der Engineer achtet unter anderem auf das Einhalten der wichtigen Rahmenbedingungen: Die Benutzer bearbeiten ein realistisches Szenario, das Ziel wird aus ihrer Sicht formuliert, sie erhalten angemessene Aufgaben, die die Terminologie der Anwendung vermeiden.

Ein UX-Experte legt zu diesen Tests Berichte an, die alle Ergebnisse enthalten und alle Schwachstellen mit einem Schweregrad versehen. Screenshots illustrieren Letztere, der Bericht enthält die Aufgabenstellung, beschreibt die Testpersonen und unterscheidet zwischen Beobachtungen und persönlicher Meinung. Die Aussagekraft der Ergebnisse hängt daher entscheidend von der konkreten Durchführung ab. Nur ein professionell durchgeführter Test liefert einen eindeutigen Nachweis von Schwachstellen. Gleichzeitig verdeutlicht er die Schwierigkeiten anschaulich. Der Testaufwand lohnt sich, wenn die Ergebnisse als Grundlage für spätere Entscheidungen dienen sollen.

Gute UX ist kompliziert, und das führt häufig zu Verwunderung. Im Internet findet sich eine Vielzahl an einfachen Ansätzen. Sie gehen meist in die richtige Richtung und schaffen ein Bewusstsein für diese Thematik. Eine vollständige Lösung setzt allerdings stets eine Analyse der konkreten Situation voraus. Beispielsweise ist das KISS-Prinzip (Keep it simple, stupid) im Grundsatz gut, aber nicht die ganze Wahrheit. Denn Menschen brauchen leistungsfähige und nutzbare Software. Gute UX kann nie durch Einfachheit allein entstehen. Ein UX Engineer analysiert daher zunächst, ob sich die Komplexität aus dem konkreten Kontext der Anwendung ergibt. Er lässt große Systeme einfach erscheinen, denn selbst ein komplexes System kann in der Wahrnehmung des Benutzers einfach erscheinen. Daher sollte man bei simplen Ratschlägen für die Verbesserung der UX stets skeptisch sein. Geht die Analyse nicht tief genug, bleiben die Lösungen oberflächlicher Natur.

Durch einen UX Engineer verändert sich etwas im Entwicklungsteam, denn der Experte wird als Erstes dessen Fokus verändern. Entwickler konzentrieren sich naturgemäß auf Teilaspekte, der UX Engineer hingegen auf das Gesamtkonzept. Er kennt die Implikationen der Anpassungen auf das Gesamtsystem. Aus seiner Perspektive enthält ein Produkt immer auch eine Dienstleistung. Scheitert die, scheitert das Produkt. Gleichzeitig sind diese Dienstleistungen soziale und komplexe Systeme. Er trägt dazu bei, dass Menschen am Ende in diesen Systemen interagieren und kommunizieren. Dazu fordert er vom Team immer wieder ganzheitliches Denken. Und er sorgt dafür, dass die verschiedenen Benutzungsmuster angemessen berücksichtigt werden.

Gleichzeitig hilft er, zwischen Symptomen und Ursachen zu differenzieren. Dazu lenkt er den Fokus von den Symptomen permanent auf das Gesamtproblem. Er begibt sich mit den Entwicklern auf die Suche nach dem tieferen Sinn und den Ursachen. Ein gutes Beispiel für diesen Ansatz ist Apples iPod: kein erfolgreiches Produkt, sondern ein erfolgreiches System, bedingt durch die Prozessperspektive. Der iPod ermöglicht das legale Suchen, Kaufen, Laden und Abspielen von Musik. Durch die veränderte Perspektive finden Entwicklungsteams innovative Ideen.

Fazit

Für den Start ins neue Computerzeitalter lautet die Empfehlung, einen UX Engineer einzustellen. In der Praxis ist es jedoch hilfreich, sich dem Thema schrittweise zu nähern. Zunächst sollte man in einem Team ein Grundverständnis für User Experience aufbauen. Erste Erfolge steigern die Bereitschaft für größere Investitionen. Experten wie Tobias Komischke sprechen von einem Return On Investment von 2 bis 100 Dollar pro in UX investiertem Dollar. Dazu kommen laut Vibor Cipan noch viele weiche Faktoren wie höhere Kundenzufriedenheit, mehr Begeisterung und längerfristige Loyalität.

Prof. Dr. Simon Nestler

ist Professor für Mensch-Computer-Interaktion an der Hochschule Hamm-Lippstadt. Sein Tätigkeitsschwerpunkt liegt auf der praktischen Umsetzung wissenschaftlicher Usability-Grundprinzipien.

Literatur

[1] Ben Shneiderman; Leonardo’s Laptop: Human Needs and the New Computing Technologies; Cambridge, MA (MIT Press) 2009

[2] Richard Monson-Haefel (Hrsg.); 97 Things Every Software Architect Should Know; Sebastopol (O’Reilly) 2009

[3] Michael Richter, Markus D. Flückiger; Usability Engineering kompakt: Benutzbare Software gezielt entwickeln; Berlin (Spektrum Akademischer Verlag) 2009

Alle Links: www.ix.de/ix1401104

(hb)