Der Nutzer, das unbekannte Wesen

Wer sind "die Nutzer"?

So international die Open-Source-Community auch ist – von einigen wirklich großen Projekten wie dem Webserver Apache abgesehen, kannten die Entwickler bisher ihre Nutzer. Wenn nicht persönlich, dann aus Mailinglisten, aus dem IRC, von Bug-Reports etc. Es gab eine Kommunikation zwischen Gleichgesinnten.

Wenn nun große Verwaltungsapparate nicht nur in Deutschland, sondern weltweit ihre Mitarbeiter an Open-Source-Software setzen – und immer mehr Nutzer Linux auf dem heimischen PC ausprobieren – steht der Entwickler plötzlich einer Masse von Nutzern gegenüber, die er weder kennt noch versteht, und die keine der genannten Kommunikationswege nutzt.

Abbildung 3: Fehlermeldungen sollten verständlich darüber informieren, was schief gelaufen ist (Hier eine Gnome-2.2-Fehlermeldung auf SuSE Linux Desktop 1.0 beim Versuch, YaST2 zu starten).

Benutzerfreundliche Software kann aber nur produzieren, wer sich klar macht: Der Nutzer einer Software ist grundverschieden von ihrem Entwickler.

Die meisten Entwickler realisieren Funktionen, Interaktionsabläufe und Oberflächen so, dass die Software die eigene Begriffs- und Denkwelt widerspiegelt. Sie kennen ihre Software in- und auswendig, wissen Bescheid über ihre Funktionen und Grenzen, müssen nicht erst nachdenken, welche Schritte sie tun müssen.

Woher weiß aber die Entwicklerin, was unterschiedliche Nutzer mit welchen Begriffen assoziieren? Wie kommt sie an die notwendigen Informationen über "die Nutzer"?

Die Feedback-Schwelle niedrig halten

Setzt man auf der Seite des Anwenders an, so liegt es nahe, zunächst auf die bestehenden Kommunikationswege zurückzugreifen. Das heißt z. B., Mailinglisten einzurichten, die Usability-Probleme diskutieren – und zwar in einem moderierten Rahmen, so dass die Anliegen der Nutzer verstanden und in technische Aufgabenstellungen für die Entwickler umformuliert werden können. Oder: In Form eines Web-Angebots oder als Teil der Applikation eine Möglichkeit für die Benutzerinnen und Benutzer zu schaffen, den Softwareentwicklern in standardisierter Form von Problemen zu berichten, die sie mit der Anwendung hatten (Usability Bug Reporting).

Das Ziel wäre also, die große Masse der neuen Nutzer zu einem Teil der Community zu machen, sie durch niedrigschwellige Angebote einzubinden und die Möglichkeit der Kommunikation mit den Softwareentwicklern zu einem Teil einer positiven Nutzungserfahrung werden zu lassen. Wesentlich ist hier, dass die Angebote möglichst einfach verständlich und bedienbar sind – und andererseits der Nutzer-Input in für die Entwickler und Entwicklerinnen verwertbare Informationen umgewandelt werden kann.

Denn in der Praxis sind die Feedback-Kanäle immer noch stark auf Entwickler und technisch versierte Nutzer und Nutzerinnen beschränkt (Abbildung 4). Wer schon einmal einen Bugzilla-Report ausgefüllt hat, in der Datenbank versuchte, "seinen" Bug zu finden und schließlich das daraus resultierende Mail-Feedback zu verstehen, wird zustimmen, dass die Hürden doch eher hoch sind und viele ausschließen.

Wenn allerdings jeder Nutzer seine persönlichen Probleme mit der Software an den oder die Entwickler schickte, dann wäre zum einen keine Zeit mehr zum Programmieren, zum anderen müssten die Entwickler ihrerseits verstehen, was der Nutzer genau meint. Je größer und heterogener die Nutzergruppen werden, desto schwieriger und zeitaufwändiger wird es für Entwickler, die Übersicht über die oft widersprüchlichen Anforderungen zu behalten und das Softwareprojekt für möglichst viele Betroffene akzeptabel zu konzipieren.

Hier kommen Usability-Experten ins Spiel, deren Aufgabe darin besteht, als Mittler zu fungieren zwischen Anwendern und Entwicklern. Sie sind nicht in die Programmierung eingebunden und damit nicht "betriebsblind" gegenüber Usability-Problemen der Anwendung. Sie können aufgrund ihrer Erfahrung nicht nur Nutzergruppen dazu bringen, verwertbare Informationen über die Benutzbarkeit der Software zu formulieren, sondern diese Informationen auch soweit abstrahieren, zusammenfassen und bewerten, dass konkrete Handlungsempfehlungen für die Projektentwickler entstehen. Dies kann durch Moderation von Mailinglisten, durch die Teilnahme am Usability-Bug-Reporting-Prozess, durch Usability-Tests oder direkte Beratung und durch Unterstützung einzelner Projekte geschehen.

Bei der kommerziellen Softwareentwicklung spielt Usability-Expertise bereits eine große Rolle, da sich diese schon viel früher mit dem Problem einer großen, heterogenen Nutzerschicht auseinandersetzen musste. Usability-Experten (oder ganze Usability-Abteilungen) übernehmen dort die Aufgabe, Probleme in der Benutzbarkeit systematisch zu erkennen (in der Regel durch sogenannte Usability-Tests), zu filtern und für die Entwickler als klare, umsetzbare Empfehlungen aufzubereiten.

Abbildung 4: Hohe Eingangshürden: Die Eingabemaske für Issuezilla (hier bei OpenOffice.org) ist für "normale Nutzer" kaum verständlich.

Im kommerziellen Bereich lässt sich auch die Frage, wie man an diese Experten kommt, ganz einfach beantworten: Man bezahlt sie. Aber wie sollen Open-Source-Projekte dies regeln? Einerseits geht es natürlich auch auf kommerzielle Weise: Namhafte Firmen, die sich im Open-Source-Umfeld engagieren, stellen ihre Usability Labs zur Verfügung; der "Gnome Usability Report" der SUN Human Computer Interaction Group ist hier nur ein Beispiel.

Aber ließen sich die Experten nicht direkt in die Community einbinden, im Sinne einer echten "Open Usability"? Sobald sich Firmen, universitäre Gruppen und Einzelpersonen durch Förderung der Benutzerfreundlichkeit von OSS einen guten Namen und Reputation erwerben können, werden zumindest einige ihre Expertise der Community zur Verfügung stellen – wie die Softwareentwickler freiwillig und umsonst: "Just for fun". Da dieses Prinzip schon dabei geholfen hat, besseren Code zu produzieren, könnte dieselbe Logik auch im Bereich der Usability gelten – erste Ansätze [2,3] gibt es bereits.