Task-orientiert und die liebevolle Gewohnheit

Was für Massenprodukte und im Internet längst Standard ist, nämlich die Sicht auf den User, sieht beim einzelnen, kleinen Projekt mit wenig Beteiligten oft anders aus. Hier ist Überzeugungsarbeit gefragt, manchmal auch vorsichtig ein wenig Eigeninitiative.

Ich bin bei der Softwareentwicklung ein ausgesprochener Fan der task-orientierten, also aufgabenorientierten Herangehensweise. Leider  stehen dabei gerade im kleinen Projekt gerne  ausschließlich die primären Aufgaben im Vordergrund, sekundäre Handlungen werden gerne stiefmütterlich behandelt. Aspekte der Usability ebenfalls.

Brauchen oder nicht brauchen…

Die Access Datenbank hat ausgedient.  “Wir brauchen da ….” heißt es da mal schnell und es folgt ein längerer Anforderungskatalog des Auftraggebers. Der reagiert gerne etwas verwundert auf die Bitte, er solle doch genauer erläutern, warum man diese und jene Funktionalität überhaupt benötigt, welche Personen beteiligt sind und wie diese Workflows denn eigentlich ablaufen. Noch überraschter mag er bei der Bitte sein, ob man dies denn in der Praxis denn mal einen Tag mitverfolgen könne.

Es ist unabdingbar, die am Prozess Beteiligten von Beginn an zu integrieren. Überzeugungsarbeit oder auch Durchsetzungsvermögen wird beispielsweise dann nötig, wenn die Entscheider, die weniger mit den Arbeitsabläufen vertraut sind, es dem Mitarbeiter nicht zutrauen, sich von liebgewonnenen Gewohnheiten zu verabschieden und sich aus diesem Grund dafür entscheiden, sie deshalb lieber aus dem Prozess auszuklammern. Oder aber auch wenn Usability vermeintlich einfach “nicht gebraucht” wird, weil ja nur ein paar Leute mit der neuen Software arbeiten und man die Benutzer gut genug zu kennen glaubt.

Schließlich geht es nicht nur um eine Modernisierung, um eine Veränderung, sondern auch um Effizienz. Und nicht zu vergessen auch um die Menschen, die genau diese Veränderung mittragen und später in neuer technischer Umgebung arbeiten sollen.

Die Aufgaben…

Die offensichtlichen Anforderungen sind meistens bekannt und können schnell identifiziert werden. Ein einfaches Beispiel wäre, die bisher über Papier oder eine einfache Datenbank/Tabellenlösung verwalteten Daten in intelligente Workflows zu gießen. Daten sollen erfasst, gespeichert und an anderer Stelle weiterverarbeitet werden.

Um welche Daten es sich handelt, wissen die Beteiligten, vielleicht gibt es bereits eine Spezifikation. Es gilt dann beispielsweise, ein Eingabeformular für eben jene Daten zu generieren. Auch die Usability der Formulare wird dabei im Idealfall nicht zu kurz kommen. Ein komplexes Unterfangen, ganz nebenbei. Im nächsten Schritt geht es um die Weiterverarbeitung. Auch hier ist bekannt, dass Daten gespeichert und Briefe ausgedruckt werden müssen.

Die Aufgaben heißen also beispielsweise etwas verkürzt: Daten eingeben, Briefe erstellen, Dateien speichern, Schreiben versenden (per Post oder Fax oder auch Email, gerne auch eine Kombination aus allem).

Und da wäre dann noch

Was da schnell vergessen wird, sobald nicht wirklich jeder der Beteiligten in diesen Prozess mit eingebunden wird, sind die realen Arbeitsabläufe, kurz der Praxisbezug. Wie organisieren die einzelnen Beteiligten die Aufgaben? Wie organisieren sie sich? Wie behalten sie den Überblick? Wie kommunizieren mehrere Beteiligte innerhalb dieses Prozesses miteinander?

Hier entwickeln sich zum Teil sehr persönliche Vorlieben. Der eine übersät beispielsweise seinen Schreibtisch und alle Aktendeckel mit Post-It Notes, der andere führt eine Excel Tabelle, andere nutzen Outlook. Nicht alles davon ist sinnvoll, einiges davon kann durchaus optimiert werden. Vielfach haben sich genau diese Gewohnheiten auch als Workaround ergeben.
Man hat sich lediglich daran gewöhnt, was aber nicht heißt, dass die Gewohnheiten befriedigend oder als Lösung gelungen wären.

Was passiert wenn…?

Was passiert, wenn eben diese langjährig etablierten, versteckten Arbeitsabläufe (als Positiv- oder Negativerfahrung) innerhalb des Konzeptionsprozesses nicht berücksichtigt werden, liegt auf der Hand:

Die Mitarbeiter gewöhnen sich nur widerwillig an die Neuerung. Die primären Aufgaben, die mit dem System erledigt werden sollen, gehen zwar locker von der Hand, die alteingesessenen Handgriffe integrieren sich aber nicht mehr und ein Ersatz ist nicht vorgesehen. Es müssen neue Workarounds gefunden werden.
Das, was eigentlich viel effektiver sein sollte, wirft zunächst mehr Fragen auf als es Antworten schafft. Das System ist zwar auf den ersten Blick das, was man “aufgabenangemessen” nennt, geht aber trotzdem am Benutzer vorbei.

Ebenso kann es passieren, dass die Benutzer  die vermeintlichen Verbesserungen nicht nutzen, weiterhin auf ihre alten Workarounds zurückgreifen, schlicht, weil das Neue nicht nur ungewohnt, sondern vor allem kompliziert scheint oder unverständlich ist.

Der nächste Schritt wird sein, Nachbesserungen vorzunehmen, neue Funktionalitäten zu planen. Meist mit Unzufriedenheit auf allen Seiten, sofern sich jener Integrationsprozess nicht so einfach umsetzen lässt oder neue Kosten entstehen.

Präventivmaßnahmen und ihre Folgen

Genau hinsehen.
Ein vielversprechender Ansatz ist es, die Benutzer bei ihrer Arbeit zu beobachten. Im nächsten Schritt muss geklärt werden, wo ihnen die Organisation leicht fällt und wo sie Schwierigkeiten macht. Man kann so die effizienten als auch die weniger effizienten Arbeitsschritte identifizieren und mit in die Planung integrieren. Wer diesen Schritt vergisst oder vernachlässigt, verpasst eine große Chance.

Mehr Augen sehen…
Allen von Beginn an miteinbezogenen Personen können Features und Lösungen vorgestellt werden. In der Diskussion ergeben sich, gerade durch die Menschen, die tagtäglich wirklich mit etwas arbeiten, ganz neue Aspekte der Nutzung. Dieser Aha-Effekt kann produktiv in den Konzeptionsprozess einfließen.

Neu und trotzdem gut
Werden die Benutzer von Beginn an integriert, wird auch die spätere Akzeptanz von Neuerungen höher sein als wenn dem Benutzer entgegen seiner Überzeugung neue Funktionalitäten aufoktroyiert werden. So nämlich kann er verstehen, warum eine Funktion sinnvoll ist und welche bisher eventuell unbefriedigenden Handgriffe ersetzt werden sollen.

Es rechnet sich
Klar steht auch die Kostenfrage im Raum. Wer hier mal schnell eine Lösung fürs eigene Business braucht, will sich mit Fragen der Benutzerfreundlichkeit kaum aufhalten, vor allem, weil die investierte Zeit zunächst nach erhöhten Kosten aussieht, die es natürlich zu vermeiden gilt. Wer Benutzer von Beginn an integriert, kommt sofort und ohne Umwege zu einer praktikablen Lösung.

Fazit?

Mit der Softwareentwicklung ist es wie mit dem Webdesign. Der Anwender steht mit im Mittelpunkt des gesamten Prozesses. Wird dieser nicht ausreichend berücksichtigt, kann das Ziel eines neuen Produkts, nämlich Steigerung der Effizienz, inklusive des Spaß an der Arbeit (nicht zu vergessen!) nicht erreicht werden. Bei Anwendungssoftware für die Massen wird dieser Aspekt immer immer Vordergrund stehen, ebenso wie sich Usability im Webdesign bereits weitestgehend herumgesprochen hat.

Gerade aber dann, wenn es um Anwendungen geht, die nur von einzelnen innerbetrieblich genutzt werden, fallen Überlegungen zur Usability gerne hinten durch, während im Vordergrund die Überzeugung bleibt “Jetzt machen wir es besser, die Anwender werden sich schon damit anfreunden”, gemischt mit “da überwiegen die Vorteile, das nehmen wir in Kauf”.
Die Folge dessen jedoch - nämlich die Unzufriedenheit beim Benutzer- bleibt die gleiche, wenn Anforderungen an Bedienbarkeit nicht ausreichend berücksichtigt wurden.

Was falsches Design an Folgekosten nach sich ziehen kann, ist bekannt. Irgendwo habe ich einmal gelesen, die Kosten für Redesign und neue Feature Requests könnten von Projektphase zu Projektphase mit dem Faktor 10 multipliziert werden. Das klingt zunächst völlig überzogen, ist aber je nach Wunsch bei genauerer Betrachtung durchaus realistisch…

 

Auch was dazu sagen?