Benutzbarkeit von Sicherheitssoftware in der Kritik - Teil 4

Usability-Tests untersuchen, wie benutzbar ein Programm sich in der Praxis zeigt. Das läuft in zwei Phasen ab: Nummer eins beginnt bereits vor der Implementierung, die Tests finden heraus, wie die Software aussehen soll. Phase zwei folgt nach dem Programmieren. In ihr prüft der Tester das Entwicklungsresultat, das nur zu oft beträchtlich von den ursprünglichen Plänen abweicht.

Erst testen, dann programmieren

Tests während der Entwurfsphase stützen sich meist auf Papierskizzen [1] oder Prototypen, die mit GUI-Buildern (siehe Artikel in diesem Heft) recht schnell entstehen. Sie liefern eine gute Einschätzung, wie User auf das GUI reagieren, und treiben die weitere Entwicklung voran. Beim Paper Prototyping übernehmen Entwickler die Rolle des Computers. Sie interagieren mit dem Anwender und legen ihm jeweils die passende Interface-Skizze vor. Ohne von GUI-Experten zu stammen, eignen sich die Reaktionen der Anwender bestens für Vorhersagen, welche GUI-Entwürfe in der Praxis scheitern.

Ebenfalls nützlich ist es, sich einen oder mehrere typische Anwender vorzustellen und zu überlegen, wie sie vermutlich mit der Software umgehen. Dabei helfen einige Fragen: Was wollen die Anwender erledigen? Wie gut kommen sie mit den Sicherheitsmechanismen zurecht? Wie reagieren sie auf Sicherheitswarnungen? Die Idee dabei: Statt einfach viele vermeintlich nützliche Features anzuhäufen und sich nachträglich zu überlegen, wofür sie gut sein könnten, nimmt der Entwickler die Perspektive des Benutzers ein und konzentriert sich auf die Funktionen, die sein Anwender tatsächlich braucht und die er auch versteht.

Der imaginäre Benutzer darf aber nicht als Ersatz und Ausrede dienen, um auf echte Anwendertests zu verzichten. Viele Projekte verschwenden erstaunlich viel Zeit auf hypothetische Diskussionen, was denn die Anwender theoretisch tun würden, wenn sie am System säßen, statt einen von ihnen tatsächlich bei der Arbeit zu beobachten.

Nur zu oft widersprechen Interfaces den Erwartungen der Anwender, wie etwas funktionieren sollte. Eine Studie mit unterschiedlich ausgebildeten Benutzern untersuchte deren Erwartungen an öffentliche Schlüssel und das Zertifikatmanagement [2]. Die Resultate weichen stark von der X.509-Modellvorstellung ab. Das mag einer der Gründe sein, warum sich X.509-PKI (Public Key Infrastructure) nicht wirklich durchsetzt.

Schlüsselspeicher

Die Benutzer zu fragen, wie sie denken, dass etwas funktionieren sollte, ist eine überragend hilfreiche Entwurfstechnik. Etwa wenn es ums Speichern der privaten Schlüssel geht. Sollen sie in einem einzelnen großen File auf der Festplatte landen? In mehrere Dateien verstreut? In der Registry (falls das Programm unter Windows läuft)? Auf einem USB-Token? Im Homeverzeichnis? In einem versteckten Unterverzeichnis unter Home?

Immer mehr Fragen drängen sich auf: Was passiert, wenn der User auf eines der Files klickt? Was, wenn er einen bestimmten Schlüssel auf eine andere Maschine verlagern will? Wenn er alle kopieren möchte? Was passiert mit den Schlüsseln, wenn der Anwender diesen Rechner oder diesen Account nicht mehr verwendet? Wie sind die Schlüssel geschützt? Wie kommen sie ins Backup? Sollen sie überhaupt dort landen?

Über jede dieser Fragen lässt sich trefflich und endlos streiten. Viel einfacher und zielgerichteter ist es, den Usern selbst diese Fragen zu stellen. Viele werden sich nicht auskennen oder es wird ihnen egal sein, aber im Laufe der Zeit ergibt sich ein klares Bild vom typischen Umgang mit Schlüsseln. Dieses Modell passt auf die Erwartungen der Anwender und ist für sie daher verständlich und einfach zu benutzen.