Vor kurzem besuchte ich einen Laden mit Babyartikeln. Sprachlos blieb ich vor einer Geh-hilfe stehen. Für alle nicht Eingeweihten: Dabei handelt es sich um ein kleines Gestell, an dem sich Kleinkinder, die Gehen lernen, festhalten können. Diese Gehhilfe – sie war mit «3-in-1 Babygeher!» angeschrieben – übertraf alles, was ich bisher gesehen habe. Sie sah einem Auto ähnlich und verfügte über ein kleines Steuerrad, hatte eine Hupe, einen Spiegel und kostete 175 Franken. Als zweifacher Vater weiss ich, dass Gehilfen meist kontraproduktiv sind: Sie erschweren die Entwicklung des Gleichgewichtssinns.
Leider beschränkt sich die Herstellung von wenig nützlichen Produkten mit vielen Features nicht nur auf Babyartikel. Auch die Webseiten bekannter Unternehmen halten Überraschungen bereit. Machen Sie doch mal einen Selbstversuch und wählen Sie eine Kaffeemaschine auf der Webseite von Nespresso. Wenn es Ihnen gleich geht wie mir, werden Sie verärgert abbrechen. Erstaunlich, wenn man bedenkt, dass Nespresso ihren Kaffee hauptsächlich über das Internet vertreibt.
Bei Software mit umfangreicher Funktionalität ist die richtige Gestaltung des Produktes eine grosse Herausforderung. Software ist ein virtuelles Produkt. Der Gestaltungsspielraum ist im Vergleich zu realen Produkten weniger beschränkt. Daher ist es kein Zufall, dass so viele Anwender ähnliche Geschichten wie die obigen erzählen können.
Mit der Benutzer-zentrierten Softwareentwicklung steht allerdings eine Methode zur Verfügung, welche – richtig angewandt – zu begeisterten Anwendern führt. Sie zwingt jedoch zum Umdenken. Obwohl oft erwähnt, wird sie selten wirklich angewandt. Dabei stützt sie sich eigentlich auf einige wenige Grundprinzipien, die eine ungeheure Dynamik in der Produktgestaltung auslösen.
Erwartungsgemäss spielen in der Benutzer-zentrierten Softwareentwicklung detaillierte Kenntnisse über die zukünftigen Anwender und ihre Arbeitsweise eine zentrale Rolle. Zukünftige Benutzer werden anhand von sehr konkreten Profilen (Persona) genau beschrieben. Das Projektteam soll sich in die Benutzer hineinversetzen können. Daher haben Personas konkrete Namen und werden mit Bildern repräsentiert. Das Projektteam verweist auf eine Persona, wenn über Aspekte der Lösung diskutiert wird: «Würde Hans dies erwarten?» Personas schaffen eine Grundlage, damit die zukünftigen Benutzer während des gesamten Entwicklungsprozesses präsent bleiben und hängen beispielsweise als grosse Poster im Projektraum. Darauf werden Merkmale, Ziele, Interessen und Verhalten, die einen Bezug zur Interaktion haben, beschrieben.
So wie die fiktiven, aber sehr konkreten Personas bestimmte Benutzergruppen repräsentieren, widerspiegeln Szenarios Abläufe. Szenarios beschreiben einen Ablauf anhand einer einfach lesbaren, sehr konkreten und realistischen Geschichte. Ein Szenario ist damit die erste Stufe eines Prototyps.
Eines der festen Grundelemente der Benutzer-zentrierten Softwareentwicklung stellt das Feedback der Benutzer dar. Laufend sollen die Erkenntnisse und das Verständnis des Projektteams mit den zukünftigen Benutzern verifiziert werden. Anhand von formalen Modellen, wie sie im traditionellen Requirements Engineering entwikkelt werden, ist es aber für zukünftige Benutzer und andere involvierte Interessenvertreter nicht möglich, sich eine zukünftige Softwarelösung konkret vorzustellen. Sie können somit auch nicht beurteilen, ob die skizzierten Anforderungen und geplanten Abläufe dem entsprechen, was sie benötigen.
Die in der Benutzer-zentrierten Softwareentwicklung verwendeten Modelle wie Szenarien und User-Interface-Prototypen machen die Anforderungen und Lösungsvorschläge erlebbar. Je mehr sich ein zukünftiger Benutzer die fertige Lösung konkret vorstellen kann, desto eher sind Benutzer in der Lage, ein aussagekräftiges Feedback zu geben. Daher ist es üblich, in Workshops Anforderungen direkt anhand von ersten Lösungsideen zu überprüfen. Bei der Umsetzung der Anforderungen in einen Produktvorschlag wird deutlich, was nicht verstanden wird, wo noch wichtige Aspekte fehlen oder wo die eigenen Vorstellungen ins Leere laufen.
Im traditionellen Requirements Engineering sollen zuerst die Anforderungen erhoben, dann analysiert und modelliert und schliesslich Lösungsvorschläge erarbeitet werden. Dies spiegelt sich in einem wasserfallartigen Vorgehen und in Organisationseinheiten, die nach Projektphasen oder Disziplinen unterteilt sind. In einem Projekt, in dem mit Benutzer-zentrierten Methoden gearbeitet wird, fallen diese Tätigkeiten
oft zusammen und werden quasi simultan ausgeführt. Die Erhebung der Anforderungen und die Gestaltung des Produktes sind nicht mehr getrennte Aktivitäten.
Die Produktentwicklung wird statt dessen zu einem iterativen Prozess, in dem sich das Projektteam der richtigen Lösung annähert und ständig eine Verifikation mittels Feedback sicherstellt. Nach dieser Methode kann eine gute Software nicht einfach logisch aus den Anforderungen abgeleitet werden; sie ist statt dessen das Ergebnis eines empirisch fundierten Vorgehens.
Die Anwendung einer solchen Benutzer-zentrierten Vorgehensweise beschränkt sich übrigens nicht nur auf die Herstellung von Software. So wird diese Vorgehensweise zunehmend auch bei der Entwicklung von Unternehmensprozessen und Dienstleistungen angewandt. Man spricht dann von Kunden-zentrierter Dienstleistungs- und Produktentwicklung. Es wäre nicht verwunderlich, wenn hier ein neuer Trend entsteht. Dann würden wohl viele wenig sinnvolle Produkte nicht produziert – auch bestimmte Babyartikel.
Die gemeinsam von der Uni Basel und der Hochschule für Technik Rapperswil angebotene Weiterbildung «MAS Human Computer Interaction Design» richtet sich an Personen, die sich mit Entwurf und Entwicklung von User Interfaces befassen. Im deutschsprachigen Raum gibt es kein vergleichbares Studium für Experten von User Interfaces, Interaction Design und Usability. Dieses neue, berufsbegleitende, interdisziplinäre Weiterbildungsstudium führt Spezialistinnen und Spezialisten aus den Gebieten Informatik, Design und Psychologie zusammen. Informationen dazu finden sich auf der Webseite: www.hcid.ch.
