Enterprise-Anwendungen in der Praxis: Wie User-Besuche zum Katalysator werden

Als die Product Ownerin die 20-minütige Demonstration beendet hatte, spannte sie sich an, atmete tief durch und fragte: „Okay, welche Fragen haben Sie?“

Diesen Moment hat sie sich jedes Mal gefürchtet. Die ungefähr 20 High-Profile-User bei diesem Call sind eine extrem meinungsfreudige und kritische Truppe. Egal, was ihr Team gebaut an, um sie zufriedenzustellen – sie haben immer eine Liste, warum es nicht funktioniert und inwiefern es ihnen das Leben noch schwerer macht.

Deshalb war es diesmal so sonderbar. Niemand sagte was. Sie hörte nur Stille.

Die Product Ownerin wusste, dass sie da waren. Sie hatten die Demo mit klärenden Fragen unterbrochen; sie waren also aufmerksam bei der Sache.

„Hallo? Jemand da?“

Aus dem Telefon erklang ein 20-faches „Jep“ und „Ich bin hier“.

„Also keine Fragen?“, sagte sie und starrte auf den Lautsprecher, als würde er sie gleich anspringen und beißen.

Eine Stimme antwortete: „Von meiner Seite nicht. Das ist genau das, was ich erwartet habe. Gute Arbeit. Ich bin begeistert davon, wohin Sie das gebracht haben.“ Andere stimmten zu.

Sie hatte die Kritiker zum Schweigen gebracht. Es brauchte ein paar Minuten, um das sacken zu lassen.

Die User arbeiten sehen, aus erster Hand

Was diese Demonstration so sehr von den vorangegangen unterschied, war nicht die Demo selbst. Es war nicht so, dass sie irgend etwas anders gebaut hätten. Anders war diesmal, wie gut das Team die Arbeitsprozesse und Aktivitäten der User verstanden hatte.

Ein paar Monate zuvor hatte die einzige Designerin im Team sich einen Ortstermin verschafft. Statt allein hinzugehen, überredete sie einen Produktmanager und ein paar Entwickler dazu, sie zu begleiten.

Sie schlugen in der Außenstelle auf, um ihren Nutzern – den Außenvertretern – bei der Arbeit zuzuschauen. Obwohl sie schon seit einer Weile an diesem Projekt arbeiteten – manche seit Jahren –, war es das erste Mal, dass sie beobachteten, wie die User ihre Arbeit machen.

Es war unglaublich anzusehen. Sie beobachteten, dass so viele Dinge anders waren als das, was sie erwartet hatten.

Außendienstler, die oft persönlich oder am Telefon mit den Kunden arbeiteten, schrieben sich wichtige Daten erst auf, ehe sie diese ins System eingaben. Das Team lernte, dass die Felder auf den Bildschirmen in einer ungünstige Reihenfolge erschienen. Den Kunden zu befragen, die Daten aufzuschreiben und sie anschließend in den Bildschirm zu transferieren, war ein viel natürlicherer Ablauf.

Das Team beobachtete die Außendienstler, wie sie ständig Informationen, die auf dem Bildschirm standen, aufschrieben, um dann einen anderen Teil der Anwendung aufzurufen und die Daten wieder einzugeben. „Old School Copy & Paste“, nannten sie das. Natürlich war das eine Menge Copy & Paste, da auf diese Weise immer nur eine Sache bewegt werden kann, und oft müssen die User mehrere Feldwerte so transferieren.

Das war nur ein Teil dessen, was das Team bei seinem Besuch sah. Sie wurden Zeugen, wie maßgeschneiderte Tabellen für Berechnungen genutzt wurden, bei denen die Anwendung davon ausging, dass die Nutzer sie im Kopf durchführen würden; sie sahen, wie User blindwütig auf dem Bildschirm hin und her sprangen, statt den vorgesehen Pfaden zu folgen; sie hörten jede Menge Flüche, wenn die Applikation etwas Unerwartetes tat.

Das Team kehrte voller Energie zurück, um seinen eigenen Prozess zu verändern.

Ein gemeinsames Verständnis entwickeln

Nach der Rückkehr stellte das Team etwas Interessantes fest. Entwickler und Produktmanager, die draußen in der Praxis gewesen waren, brachten bessere Design-Ideen hervor als die, die nicht mitgekommen waren.

Daraus wurde ein Programm etabliert, um jeden Entwickler und Produktmanager dazu zu bekommen, die Außendienstmitarbeiter bei der Arbeit zu beobachten. Als die Teams wiederkamen, begannen die UX-Designs sich zu verbessern.

Es war nicht einfach, all diese Leute in die Praxis zu kriegen. Es kostete etwas. Da viele der Entwickler externe Auftragnehmer waren, mussten ihre Verträge so angepasst werden, dass sie auch Zeit für andere Dinge als Coden hatten.

Hagan Rivers, die aufs Redesign komplexer Enterprise-Anwendungen spezialisiert ist (für uns ist sie so etwas wie eine Enterprise-App-Flüsterin), sagt, dass die Begegnung mit den Usern essenziell ist: „Wir müssen regelmäßig und kontinuierlich mit unseren Nutzern in Verbindung stehen, damit wir ihre Schmerzpunkte verstehen.“

Bessere Entwickler-User-Zusammenarbeit

Das Team passte seine Sprints so an, dass jede User-Story für Oberflächen-relevante Elemente reviewt wurde. Jede Story, die das Interface tangierte, wurde nun einem Review durch High-Profile-User unterzogen – die Leute, die bei jenem Demo-Call dabei sein würden und die nun die Fachexperten des Teams waren. Die Entwickler erstellten ein Mockup davon, wie das Design ihrer Auffassung nach sein könnte, kontaktierten ein paar Schlüssel-User und gingen die Story durch.

Da die Entwickler die Praxis gesehen hatten, wussten sie, wie sie ihre Fragen stellen mussten, und verstanden die Antworten, die sie erhielten. Die Schlüssel-User halfen dem Team kontinuierlich mit ihrem geteilten Verständnis davon, wie die Außendienstler arbeiteten.

Feedback und Lernen in das Projekt injizieren

Als die Zeit heran war, das Projekt in einem fast finalen Stadium zu präsentieren, gab es diesmal keine Überraschungen. Die Fachexperten hatten gesehen, wie das Projekt evolvierte.

Die meisten Projekte warten bis zum Ende (und manchmal bis nach der Auslieferung), um zu lernen, was die User wirklich brauchen. In diesem Projekt haben die Besuche bei den Außendienstlern eine Kette von Ereignissen angestoßen, die zu einem klügeren, besser informierten Design-Prozess geführt hat. Praxisbesuche wurden ein Katalysator für ein besseres UX-Design.

Dieser Artikel wurde im Original am 27. Januar 2016 unter dem Titel Enterprise Apps In The Field: How User Visits Become A Catalyst von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden User-Experience-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im UX-Special von //SEIBERT/MEDIA.