Regelwerk

Für ganz normale Websiten oder PC-Anwendungen macht Usability immer regelmässiger als Thema die Runde. Der wachsende Erfolg gibt allen Verfechtern von Benutzerfreundlichkeiten recht.

Ich spreche sicher nicht nur für mich, wenn ich dennoch behaupte, das Thema Usability bzw. Interaction Design ist eine schwierige Angelegenheit für regelbasierte Lösungen. Vor allem vor dem Hintergrund, dass BRM-Anwendungen gerade von jenen bedient werden, die eben keine IT-Fachleute oder Programmierer sind. Die Anforderungen an Funktionalität und Arbeitsgeschwindigkeit einerseits und der hohe Grad an Komplexität andererseits liess oft nur halbherzige Usability-Ansätze für Backoffice-Applikationen zu. Solange auf der Benutzerseite gleichfalls Programmierer sassen, fiel das nicht allzu stark ins Gewicht. Doch mit den künftigen Anwendern, für die BRM-Applikationen entwickelt werden, wird das nur schwerlich durchzuhalten sein.

Kürzlich fand ich einen buchbesprechenden Artikel bei Tyner Blain, der mich auf der Heimfahrt wunderbar beschäftigte. Business Rules Management und Interaction Design. Der Autor Alan Cooper hat sich dazu in mehr als einem Buch Gedanken gemacht. Für ihn ist während der Entwicklung von Software ausschlaggebend, wer selbige künftig benutzen wird - bzw. um genau zu sein - mit welchen Zielen sie eingesetzt wird. Eine Art Stellvertreterbenutzer wird für den gesamten Entwicklungsprozess angenommen, für den in jeder Phase der Entwicklung Szenarien entworfen und umgesetzt werden. Die Kombination aus konkreten Zielen und (benutzerorientierten) Szenarien ist der Schlüssel zu einem effizienten Interaction Design - kurzum die richtige Mischung aus visueller Oberfläche und Funktionalität.

Der Autor des erwähnten Artikels fasst das von Cooper vorgeschlagene Vorgehen übersichtlich in drei Stufen zusammen:
1. Die Auswahl der repräsentativen Anwerder
2. Die Definition der Szenarien bzw. Use Cases und
3. Das Interaction Design bzw. die Lösung für die jeweiligen Anforderungen und Ziele.

Anwender wie aus Fleisch und Blut
Unter den möglichen Anwendern einer Applikation werden Benutzerklassen definiert. Aus jeder Klasse wird ein konkreter Anwender als eine imaginäre Person abgeleitet. Es scheint hilfreich zu sein, Namen und Rollen zu vergeben. Also Max Herrmann, ein Fondsmanager einer Privatbank, zum Beispiel. So ein Max hat Ziele: praktische (mit seinem Unternehmen vereinbarte) und persönliche.
Wenn alle möglichen “Personen” definiert sind, gilt es ein oder zwei wichtigste Person für die Anwendung zu definieren. Sie gelten als die Schlüsselanwender - key users.
Alle Anforderungen und Entwicklungen werden auf deren Bedürfnisse zurechtgeschnitten. Im Moment der Definition des Schlüsselanwenders werden die möglichen Bedürfnisse anderer Anwendergruppen irrelevant. - Das meint, dass keine Bedürfnisse von “irgendwem” als gewünschtes “das-wäre-doch-auch-gut”-Features umgesetzt werden. Mit aller Deutlichkeit wird das so formuliert und meint nichts anderes, als dass die Entwicklung dem Diktat der Disziplin unterworfen werden sollte.
(Kleine Anmerkung: Ist in der Praxis sicher nicht immer leicht zu kommunizieren - vor allem dann, wenn der Projektpartner auf der anderen Seite nicht zu dem illustren Kreis der Schlüsselanwender gehört.)

Mit dem nötigen Ernst wird betont, dass die Definition der Primäranwender eine für die weitere Entwicklung wichtige Entscheidung ist. Konsequent finde ich den Standpunkt, dass selbst Features, die den Verkauf der Software ankurbeln könnten, nicht berücksichtigt werden sollen, sobald sie der Anwendbarkeit bzw. Usability im Wege stehen.
Der Artikel liefert eine leicht handhabbare Regel für die Auswahl der primären Anwender gleich mit:
Primary persona sind jene, die wichtigste unternehmerische Ziele umsetzen müssen und dazu das zu entwickelnde System am häufigsten benutzen werden.

Szenarien wie aus dem richtigen Leben
Der Interaction-Designer identifiziert alle Aufgaben, die der Primäranwender mithilfe der Software lösen will bzw. muss. Jede dieser Aufgaben wird in ein Szenario oder Use Case übersetzt. Sie werden selbstverständlich priorisiert: in tägliche, notwendige und beiläufige Szenarien.

Tägliche Szenarien sind solche, die vom Schlüsselanwender häufig durchgeführt werden.
Laut Cooper sind es nicht mehr als ein oder zwei Aufgaben, die wir täglich durchführen müssen. Selten mehr. Diese Szenarien dafür müssen gründlich durchdacht werden. Hier wird der Löwenanteil für die Konzeption bzw. die Entwicklung des Interaction-Designs veranschlagt.

Notwendige Szenarien werden auf jeden Fall gebraucht, sind aber unregelmässig.
Ihre Anforderungsspezifikationen enthalten neben den eigentlichen Funktionen auch solche, die für die Unterstützung bei der Handhabung dieser Szenarien benötigt werden. Es geht nicht darum, diese Szenarien um jeden Preis zu entwickeln, ohne dass Missverständnisse für die Anwender auftauchen können. Für Szenarien, die nicht sehr regelmässig angewandt werden, haben Benutzer eine grössere Lernbereitschaft und eine höhrere Toleranzgrenze.

Beiläufige Szenarien sind so selten, dass ihre Umsetzung gar nicht erst in Erwägung gezogen wird.
Ihre Entwicklung würde den Nutzen gegenüber den verursachten Kosten nicht annähernd aufwiegen. Dabei werden die Kosten vorrangig nicht durch die Implementierung produziert, sondern durch den Support, den diese Zusatzfunktionen für ungeübte Anwender verursachen.

Lösungen mit Mass
Am stärksten weicht Cooper in seinem Buch an dieser Stelle von herkömmlichen Entwicklungsprozessen ab. Er plädiert für einen sofortigen Einstieg in die Suche nach Lösungen für das Interaktionsdesign. Anfoderungen oder Spezifikationen möchte er weitgehend aussen vor lassen. Im ersten Moment denke ich kopfschüttelnd an die Strafrunden bzw. Change requests. Doch seine Begründung für dieses Vorgehen ist interessant und scheint nicht mal aus der Luft gegriffen. Cooper unterscheidet zwei Komponenten der Entwicklung: program design und interaction design.

Program design is everything you don’t see. Interaction design is everything you do see.

Interaktionen werden allein dazu entwickelt, die täglichen und notwendigen Szenarien zu unterstützen (die wiederum in engem Zusammenhang mit den praktischen Zielen des Primäranwenders stehen). Nach dieser Anforderung richten sich alle Design-Entwürfe. Das heisst Usability bzw. erfolgreiches Interaction-Design verbindet die beiden Anforderungen an die Benutzung von Software: Funktioanlität und Bedienbarkeit.
Usability stellt sich immer zwischen die beiden Möglichkeiten - was ist machbar und was ist notwendig. Funktionen, die in ihrer Anwendung nicht mehr verständlich sind, werden nicht benutzt. Da beisst die Maus den berühmten Faden nicht ab.
Bevor auch nur ein Buchstabe Code geschrieben werden kann, ist das Interaction Design bis ins Detail entwickelt worden. Cooper benutzt ein eingängiges Bild, um seinen Standpunkt zu erklären: Du kannst die Glocke nicht ohne die Form giessen.

Zu diesem überaus spannenden Thema gibt es noch keinen weisen, letzten Schluss. Faszinierend ist der Ansatz allemal - sich auf priorisierte Anwender zu stützen und wenige, aber entscheidende Funktionen optimal umzusetzen. Da ist vielleicht auch beim Entwickeln - wie so oft im Leben - weniger mal wieder mehr?

Weiterführender Lesestoff:
Prioritizing software requirements - am I hot or not?
Prioritizing Software Requirements with Kano Analysis
Alan Cooper: The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity.