Paper Prototyping braucht kein Mensch – Mensch braucht Paper Prototyping

Mit dieser Zuspitzung habe ich vor einiger Zeit einen viel diskutierten Beitrag geschrieben, und die Reaktionen waren aufschlussreich. Ein Teil der Leserschaft fand die Idee einleuchtend. Ein anderer Teil verstand sie als Rückschritt: Zurück zu Zettel und Stift? Wir haben moderne Werkzeuge, warum sollten wir malen?

Das Missverständnis ist verständlich, und es lohnt sich, es auszuräumen. Es geht nicht um Papier. Es geht darum, an welcher Stelle das Denken stattfindet.

Was in der Realität passiert

Der übliche Ablauf sieht so aus: Die Erstellenden nehmen die Anforderung entgegen und beginnen zu bauen. Direkt im Werkzeug, ohne Plan, und — das ist der eigentliche Punkt — ohne die Anforderungen, die Kennzahlen und ihre Steuerungsrelevanz kritisch zu hinterfragen.

Das passiert nicht aus Nachlässigkeit. Es passiert, weil die nötige Kompetenz vorhanden ist und moderne Werkzeuge viele Möglichkeiten der Visualisierung bieten. Bauen fühlt sich nach Fortschritt an. Fragen stellen fühlt sich nach Verzögerung an.

Am Ende stellen die Erstellenden das Ergebnis zur Verfügung und erwarten eine Begeisterung, die nur allzu oft ausbleibt. Auf allen Seiten herrscht Unzufriedenheit, weil die Anforderungen nicht erfüllt wurden — und niemand kann genau sagen, an welcher Stelle es schiefgelaufen ist.

Es lief an der Stelle schief, an der jemand angefangen hat zu bauen, bevor verstanden war, worum es geht.

Warum das Werkzeug im Weg steht

Wer direkt im BI-Tool prototypt, beschäftigt sich unweigerlich mehr mit dem Werkzeug als mit dem Inhalt. Die Aufmerksamkeit wandert zu Fragen, die im Moment des Verstehens völlig irrelevant sind: Warum sortiert die Achse so? Wie bekomme ich die Beschriftung an die richtige Stelle? Warum lädt das so langsam?

Jede dieser Fragen ist berechtigt — später. In der Anforderungsphase kosten sie genau die Aufmerksamkeit, die dem eigentlichen Gespräch fehlt.

Dazu kommt ein psychologischer Effekt, den man in Terminen gut beobachten kann: Was im Werkzeug gebaut ist, wirkt fertig. Und was fertig wirkt, wird nicht mehr in Frage gestellt, sondern höchstens noch kommentiert. Eine Skizze lädt zum Widerspruch ein. Ein gebautes Dashboard lädt zum Abnicken ein — und der Widerspruch kommt dann später, wenn die Änderung teuer ist.

Was ich stattdessen empfehle

Keine Angst, ich rate nicht zur Rückkehr zu Zettel und Stift. Ich rate zu einer PowerPoint-Präsentation — am besten zu einer, die die vorhandenen Diagramme und Dashboard-Elemente bereits als Vorlagen enthält.

Das klingt banal und ist erstaunlich wirkungsvoll. Man arbeitet mit einem Prototyping-Workbook, in dem Kacheln, Diagrammtypen und Layoutbausteine als Bausteine vorliegen. Im Termin lässt sich damit gemeinsam abstimmen, welche Kachel es sein soll, wie sich eine Kennzahl zusammensetzt, was zuerst sichtbar ist.

Wo skizziert wird, ist dabei zweitrangig — PowerPoint, Whiteboard, was auch immer verfügbar ist. Wichtig ist nur eines: zusammen mit den Empfangenden.

Die Fragen, die dabei helfen, sind einfach:

• Was wollt ihr zuerst sehen?
• Wie setzt sich die Kennzahl zusammen?
• Gibt es Strukturen, die interessant sein könnten?
• Wollt ihr sehen, ob sich etwas verändert hat?
• Ist ein Zeitverlauf relevant?
• Wäre es nicht interessant, dieses oder jenes zu sehen?

Damit wird skizziert, gemalt, gestrichen, verworfen, neu gedacht und wieder hinterfragt.

Was dabei wirklich entsteht

Das Ergebnis ist nicht in erster Linie ein Entwurf. Das Ergebnis ist Verständnis — und zwar in beide Richtungen.

Die Erstellenden verstehen die Fachabteilung: das Tagesgeschäft, die Steuerung, wonach entschieden wird und ob überhaupt entschieden wird. Sie können anschließend beurteilen, welche Kennzahl relevant ist und welche nur historisch mitläuft.

Die Fachabteilung versteht ihrerseits, dass man den Erstellenden nicht einfach sagen kann: „Bau mir mal ein Dashboard." Sie erlebt im Termin, wie viele Entscheidungen zwischen dem Wunsch und dem fertigen Artefakt liegen.

Und ein Satz gehört an dieser Stelle unbedingt dazu, auch wenn er unhöflich klingt: „Nein, wir schauen jetzt nicht auf deine Excel." Nichts ist langweiliger und wirkungsloser, als ein bestehendes Excel-Reporting eins zu eins in ein Dashboard zu kippen. Man übernimmt damit alle Altlasten, ohne eine einzige davon geprüft zu haben.

Praktische Hinweise

Für das Prototyping braucht es einen kleinen Werkzeugkoffer: Methodik, Zeitmanagement, Templates, Ideen und die richtigen, auch kritischen Fragen. Und außerdem Kommunikation, Kommunikation und Kommunikation.

Zwei Dinge aus der Praxis, die den Unterschied machen:

Klein besetzen. Drei bis fünf Anfordernde, nicht mehr. Weniger Stimmen sind besser. Bei zu vielen Teilnehmenden ist Chaos garantiert, und es wird über alles Mögliche geredet, nur nicht über das zu entwickelnde Dashboard. Wer sich übergangen fühlt, kann bei der ersten Vorstellung abgeholt werden — Anpassungen sind dann immer noch möglich.

Nicht versprechen, was man nicht halten kann. Wenn im Prototyping mit den vorhandenen Standarddiagrammen gearbeitet wird, gibt es in der Umsetzung keine bösen Überraschungen. Das ist der unterschätzte Nebeneffekt: Ein Prototyp aus dem eigenen Baukasten ist per Definition umsetzbar.

Der Punkt

Im Paper Prototyping liegt ein unterschätztes Potenzial. Ein agiler Ansatz, Flexibilität, die passenden Werkzeuge und der übergreifende Austausch sorgen für bessere Ergebnisse, für schnellere Ergebnisse und für eine deutlich höhere Akzeptanz.

Das Werkzeug kommt danach. Es ist ein hervorragendes Werkzeug — für die Umsetzung. Für das Verstehen ist es das falsche.

Reflexionsfrage: Wann habt ihr zuletzt ein Dashboard skizziert, bevor ihr es gebaut habt? Und wenn nie: Woran hat es gelegen — an der Zeit oder daran, dass es niemand vorgeschlagen hat?

Quellen und weiterführende Hinweise

• Prototyping ist der vierte Schritt im Dashboard Requirement Process. Die ausführliche Darstellung samt Beispielen aus einem Prototyping-Workbook findet sich im TDWI-E-Book *Self-Service Analytics*: zum E-Book

Aus meiner eigenen Arbeit

• Mini-Guide: 100 Fragen über Dashboards — Kapitel 7 behandelt, warum Nutzerinnen ein Dashboard anders verstehen als die Menschen, die es gebaut haben.

Wenn ihr Prototyping bei euch etablieren wollt oder ein bestehendes Dashboard kritisch prüfen möchtet: Beim Reporting-Check schauen wir gemeinsam drauf.