Kenne deinen User!

Eine der ersten Erkenntnisse die ich bei meinen Projekten gesammelt habe war dass der Nutzer viel zu häufig unter den Tisch fällt (und dort am besten noch mit Füßen getreten wird).  Hier drängt sich dann natürlich gleich die erste Frage auf:

Warum werden die Nutzer zum Beginn eines Projektes so häufig vergessen?

Eine allgemeingültige Antwort auf diese Frage kann es natürlich nicht geben aber es gibt Faktoren die ich immer wieder vorfinde.

• Die Projektleitung ist von Technik xy durch den jeweiligen Vendor vertrieblich überzuckert womit der Fokus darauf liegt genau dieses Produkt mit all den wundervollen unnötigen „klickibunti“-Features an den Start zu bringen. Nutzer verbieg dich, das Tool ist DIE Lösung für alles Übel.
• (das Gegenteil) Die Projektleitung ist der Meinung: Was vor 20 Jahren funktioniert hat funktioniert heute immer noch genau so gut.  Userinterface? ich will meine Kommandozeile!
• Das Projekt wird um eine einzige Aufgabenstellung (also einen von vielen UseCases) aufgebaut und die Benutzung der Applikation für den Tagesbetrieb kaum beachtet. Wie du willst Daten Pflegen? Aber wir brauchen die Applikation doch hauptsächlich zum Exportieren!?

Aber nicht immer werden die Nutzer gar nicht mit ins Boot genommen. Es soll sogar vorkommen das Nutzer mit am Tisch sitzen wenn spezifiziert wird und dennoch geht die Bedienbarkeit des Systems ziemlich schnell den Bach runter.  Und hier komme ich auf meine eigentliche Kernfrage zu diesem Thema:

Wer ist dein Nutzer?

Und auch hier gibt es wieder nicht die eine Antwort. Genauer gesagt gibt es für diese Frage in den meisten Fällen mehrere Antworten, dazu aber gleich mehr.

Wenn wir uns nun Fragen was falsch laufen kann obwohl ein Nutzer am Tisch sitzt kommen wir früher oder später sicher zum Schluss, der Nutzer repräsentiert nicht alle Nutzer. Meistens sitzen in diesen Spezifikationsrunden die so genannten Keyaccount User – also Schlüsselnutzer die das System früher oder später in und auswendig kennen, tagtäglich damit Arbeiten und somit sehr spezielle Anforderungen haben. Was für Nutzer haben wir nun aber wenn wir uns den Standardnutzer suchen wollen?

1. Poweruser
   Generell der anspruchsvollste aber gleichzeitig auch dankbarste Nutzer. Dankbar in sofern als dass an eine initiale Schulung eine tagtägliche andauernde Tätigkeit mit der Applikation anschließt und somit Eigenheiten des Systems schnell ins Blut des Nutzers übergehen. Anspruchsvoll dennoch da es die Nutzergruppe mit dem intensivsten Kontakt ist, die natürlich auch die komplexesten Anforderungen hat. Der Hauptanspruch eines Powerusers ist die Optimierung des Workflows um die häufigsten Arbeitsschritte möglichst schnell bewältigen zu können.
2. Regular User
   Unter dem Regular User verstehe ich den Nutzer für den die Applikation zwar nicht zum Tagesgeschäft gehört, aber dennoch regelmässig mit der Applikation in Kontakt kommt, etwa einem CMS oder DMS um Wochenberichte einzupflegen. Da diese Gruppe von Nutzern eine überschaubare Anzahl an Aufgaben mit der Applikation erledigt ist für sie die Gleichförmigkeit der Bedienung ein entscheidendes Kriterium. Auch wenn ein Task eventuell einen Klick mehr benötigt um ihn abzuschließen helfen gleichförmig strukturierte Dialoge diesem Nutzer am stärksten um verschiedenartige Tasks in einer gewohnten Methodik zu erledigen.
3. Casual User
   Wesentlich schwieriger sind die Ansprüche des Casual Users zu definieren. Da der Nutzer nur ab und an mit der Applikation in Kontakt kommt hilft die Gleichförmigkeit der Bedienung nur beschränkt da die Grundmethodik jedes mal aufs Neue erlernt bzw. aufgefrischt werden muss. Optimal wäre hier natürlich das intuitive Nutzerinterface. Da Intuition auf den Gewohnheiten und Erfahrungen eines Menschen basiert gibt es „das“ intuitive Userinterface leider nicht. Berücksichtigt werden muss also der kleinste gemeinsame Nenner aller Nutzer. Sollten die Nutzer alle aus einem spezifischen Bereich kommen und somit alle Erfahrungen mit SAP-Interfaces haben, kann dies die Basis sein, in den meisten Fällen werden jedoch (leider) nur die gebräuchlichsten Programme wie MS Windows sowie MS Office als Grundlage dienen können. Orientiert sich das Userinterface an den aktuellen defacto-Standards kann man davon ausgehen das die Nutzer die vorgesehenden Bedienelemente schnell finden und somit flüssig mit der Applikation arbeiten können.

Mit der Diversifikation der Nutzer bin ich nun am Ziel dieses Artikels – wie man die Bedürfnisse dieser Nutzergruppen in Einklang bringen kann möchte ich in einem der nächsten Artikel etwas genauer beleuchten.

Worum gehts hier eigentlich?

Nachdem ich als Java Programmierer tagtäglich mit den verschiedensten Systemen und unterschiedlichsten Projekten in Berührung komme mache ich mir schon eine ganze Weile einige Gedanken darüber wer sich verdammt nochmal diese grausamen und unbedienbaren UIs überlegt hat und weswegen selbst ich (da beruflich sogar legitimer) IT-Junky immer und immer wieder gegen eine Wand laufe wenn ich mit einem neuen System in Berührung komme.

Da ich selbst häufig in die Verlegenheit komme Webapplikationen und deren Userinterfaces zu erweitern möchte ich mich mit den Themen Benutzerfreundlichkeit und dem übergeordneten Thema Mensch-Maschine-Kommunikation etwas genauer auseinander setzen. Hierzu zählen für mich sowohl Userinterfaces, aber auch (softwaregestützte) Prozesse und Datenmodelle. Das Spektrum meiner Einträge kann somit von Technologie bis Psychologie reichen und neben den harten Fakten natürlich auch einiges Philosophische beinhalten über das ich natürlich auch gerne bereit bin zu diskutieren.

In der optimistischen Hoffnung dass meine Gedanken, Erfahrungen und Erkenntnisse vielleicht auch noch jemand ausser mir interessieren könnte habe ich mir dieses Blog als Plattform ausgesucht. Über Kritik, Kommentare und Anregungen bin ich generell sehr dankbar .