zurück zur Übersicht

Aus einem Piloten für den Roll-out lernen

Am Anfang unseres Talks an der Upfront Thinking haben wir kurz gefragt, welche Erfahrungen das Publikum mit Pilotierung hat. Erfreulich, dass die Mehrheit Piloten für sehr nützlich hält, und nur etwa ein Drittel das «So-la-la»-Gefühl ihnen gegenüber teilt. In der Tat werden Pilotierungen zwar häufig eingesetzt, aber nur selten systematisch aufgesetzt und durch geeignete Methoden begleitet, um den Erkenntnisgewinn möglichst hoch zu halten. «Ja, wir schaun dann mal, was so raus kommt, und ob die Nutzer das überhaupt benutzen.» Bitte nicht! Wenn die Ausreden für das Nichtnutzen aufkommen, muss dagegen etwas getan werden, Nutzer motiviert, Bedienung noch mal erklärt, Vorgesetzte sensibilisiert oder Feedback anderer Nutzer gespiegelt werden. Ein Pilot ist richtig Arbeit im Grossen und im Kleinen, aber er verhindert teure, missglückte Gesamteinführungen, die nur selten ohne Reputationsschaden der Sache an sich oder der Beteiligten vonstatten gehen.

Nun, nach der Upfront Thinking, möchte ich doch gern noch einmal die Gelegenheit nutzen, einige Fragen, die nach unserer Präsentation entstanden, zu beantworten. Und das sind die spannendsten:

  • Was ist denn nun wirklich anders an Pilotierung im Vergleich zu meinen Nutzertests. Finde ich das nicht sowieso alles raus?
  • Lohnt es den Vorbereitungsaufwand und dass du das ganze Team damit absorbierst?
  • Gibt es Literatur/Forschung hinter der Vorgehensweise?
  • Wie macht man einen Piloten auf ein Feature oder MVP und wann lohnt es sich oder noch nicht?

1. Was ist anders bei einer Pilotierung im Vergleich zum Nutzertest?

In den meisten Fällen, wenn wir so arbeiten durften, wie wir es uns als UXer vorstellen, führen wir Nutzertests auf Klick-Prototypen, unvollständigen Systemen oder mit Hilfe von Mock-ups durch. Dabei versetzen wir Tester in die Nutzungssituation. Das bringt uns immens Erkenntnisse für die Weiterentwicklung unseres Entwurfs. Genau aber wie wir auf andere Methoden zurückgreifen müssen, um vor dem Nutzertest zu evaluieren, sollten wir es danach tun. Die Erkenntnistiefe soll mit der Reife des Artefakts (=Prototyp usw.) zunehmen. Ohne Pilotierung verpasse ich Umgebungseinflüsse, die in einem immer noch eher artifiziellen Nutzertest nicht geprüft werden können: Zeitdruck der Mitarbeiter, Einfluss der realen Infrastruktur über die Zeit, konkurrierende Aktivitäten, Ausfälle von Umsystemen, Umgehungslösungen der Nutzer, kreativer Einsatz von Funktionalitäten durch den Lerneffekt sind nur Beispiele. Aber es gibt kein Entweder-Oder. Das Testen von Entwürfen gehört in den Methodenkoffer. Leider sind wir UXer oft nicht mehr dabei, wenn unsere Systeme zum Leben erwachen, aber gerade in der ersten Phase der echten Nutzung lässt sich noch so viel über die Nutzer und die Nutzung lernen, was den Piloten so wertvoll macht. Wann low-fidelity-Prototypen eingesetzt werden und wann high-fidelity-Prototypen, haben auch Norman und Nielsen einmal zusammen getragen. Wichtig dabei ist noch, dass aus der Sicht der Applikation unser UX-Prototyp ein sogenannter Horizontalprototyp ist. Er deckt die Interaktionen zum Nutzer hin weitgehend ab. Ein Pilot ist idealerweise ein Vertikalprototyp, da er sich durch mehr als eine Schicht der Applikation zieht. In der Praxis soll ein Pilot auch nicht verworfen werden, was unsere UX-Arbeit voraussetzt. Mehr zu Prototypen und Prototyping aus Applikationssicht gibt z.B. dieser Wikipedia-Artikel her.

2. Lohnt es den Vorbereitungsaufwand und dass du das ganze Team damit absorbierst?

Aus meiner Sicht lohnt sich das langfristig und wenn das Team nicht allzu sehr im Projektmodus (also halbwegs kurzfristig zusammen unterwegs) sondern im Produktmodus (längerfristig zusammengestelltes Team für das Produkt) arbeitet. Dann entwickelt das Team so gemeinsam den User-Scent, das Näschen für Nutzerbedürfnisse und den Drang, Suboptimales zu verbessern.

3. Gibt es Literatur/Forschung hinter der Vorgehensweise?

Kurz: Ja. Länger: Zum Prototyping habe ich bereits oben einige Anmerkungen gemacht. Pilotierung ist eine Action-Research-Methodik (siehe z.B. diesen Artikel über Pilotierung aus dem Jahr 2000). Ganz kurz formuliert sind das solche Methodiken, bei denen der Forscher nicht neutral zuschaut sondern Teil des Untersuchungsfeldes ist und damit Phasen der Immersion und durch Disziplin Phasen der Abstraktion durchlebt. An die Stelle des Forschers setzen wir jedes Projektmitglied. Die Immersion entsteht durch die direkte Konfrontation mit dem Arbeitsalltag der Nutzer und der Pflicht, diesen zu verbessern. Die Abstraktion entsteht durch das Auswerten, Gruppieren und Diskutieren der Erkenntnisse im Team. Idealerweise wird dieser Prozess moderiert durch jemanden, der die nutzerzentrierte Anforderungsentwicklung beherrscht (ob das ein BA, RE oder UXer ist, ist wirklich nebensächlich). Kombiniert mit aktivem Stakeholdermanagement wird daraus eine praktische Methode. Die Merkmale von Changemanagement-Aktivitäten (z.B. Nutzen von Vorbildwirkung, Dialogformate mit den Betroffenen, weiteres z.B. in dieser Übersicht von basis-wissen.de) sind ebenfalls zu berücksichtigen. Wir müssen uns dabei immer vor Augen halten, dass wir, wenn wir Software entwickeln, immer etwas Neues schaffen, wenn nicht global betrachtet, dann aber immer für das Unternehmen oder die Organisation. Befürchtungen, Ängste und Abwehrreaktionen müssen also einen Kanal finden, in dem sie proaktiv behandelt werden können.

4. Wie macht man einen Piloten auf einem Feature oder MVP und wann lohnt es sich oder noch nicht?

Pilotierungen lassen sich auf allen kleinen oder grossen Einheiten des Produkts durchführen. Ob sich das lohnt, ist eine Funktion des dafür notwendigen Aufwands, der Erkenntnisse, nach denen wir suchen (also des Nutzens) und der Menge an Funktionalität. Kleinere Anpassungen wie überarbeitete Usability passen besser ins Beta-Testing oder A-B-Testing. Das Hinzufügen eines Features in einem bestimmten Geschäftsprozess ist je nach Kritikalität bereits ein Kandidat für die Pilotierung. Da aber bei der Pilotierung das erste Mal etwas ausserhalb der Kontrollgrenzen des Projekts angewendet wird, muss viel getan werden, um den Kontrollverlust durch Feedback auszugleichen. Diesen Aufwand zu betreiben lohnt sich eben erst, wenn die Änderung bemerkbar gross ist für die Nutzer. Der Gesamtrahmen bei kleineren Untersuchungsgegenständen ist zudem auch geringer gestaltbar. Statt dass der wichtigste Vorgesetzte den Nutzern persönlich erklärt, wie wichtig ihm ist, dass sie den Piloten wirklich nutzen, kann ggf. nur eine E-Mail versendet werden. Statt dass Befragungen vor Ort stattfinden, können Remote-Tests durchgeführt werden. Augenmass und Erfahrung mit Pilotierungen helfen hier, die richtige Kleidergrösse für die Pilotierung zu wählen.

Wichtig für Pilotierungen sind letztlich in jeder Ausprägung:

  • Nutzer zur Nutzung motivieren,
  • aktiv Feedback holen,
  • «Ausreden» der Nutzer einfangen und aushebeln,
  • das ganze Team beteiligen,
  • klar für Nutzer, Team und Stakeholder starten und enden

Slideshare-Presentation von der UpfrontThinking 2017

 

Haben Sie Fragen zum Artikel?