Klickdummy: den Ablauf zeigen, bevor eine Zeile programmiert wird

Ein Klickdummy ist eine anklickbare Attrappe einer Anwendung: Bildschirme, die aufeinander verlinkt sind und sich wie das spätere Programm bedienen lassen, ohne dass dahinter Daten gespeichert oder verarbeitet werden. Er zeigt, ob ein Ablauf verständlich ist, bevor Geld in die Umsetzung fließt, und macht aus abstrakten Wünschen etwas, worüber alle Beteiligten konkret sprechen können.

Was ein Klickdummy ist

Der Begriff stammt aus der Produktentwicklung und beschreibt ein Modell, das nur so tut, als ob. Ein Knopf führt zum nächsten Bildschirm, ein Formular lässt sich ausfüllen, aber abgeschickt wird nichts. Genau diese Beschränkung ist der Nutzen: Änderungen kosten Minuten statt Tage, weil kein Code, keine Datenbank und keine Schnittstelle angepasst werden muss. Für einen Ablauf mit drei Rollen reicht oft ein Dutzend Bildschirme.

Gebaut wird er mit Entwurfswerkzeugen, in denen sich Bildschirme verknüpfen lassen. Die Detailtiefe richtet sich nach der Frage, die er beantworten soll. Geht es um den Ablauf, genügen graue Kästen und echte Beschriftungen. Geht es um die Akzeptanz bei Kunden, braucht er Farben, Schrift und realistische Inhalte.

Attrappe, Design-Entwurf und MVP

• Design-Entwurf. Einzelne Bildschirme ohne Verknüpfung. Er zeigt, wie etwas aussieht, aber nicht, wie man sich durch die Anwendung bewegt.
• Anklickbarer Prototyp. Verknüpfte Bildschirme ohne Logik. Er zeigt den Weg durch den Ablauf und deckt fehlende Schritte auf.
• MVP. Eine lauffähige erste Fassung mit echten Daten. Sie prüft, ob die Anwendung im Alltag genutzt wird, und ist bereits Teil der Umsetzung.

Die Reihenfolge ist kein Zwang. Bei einem kleinen internen Werkzeug kann dieser Schritt entfallen, bei einem Kundenportal mit mehreren Rollen spart er meist mehr, als er kostet.

So entsteht ein brauchbarer Klickdummy

1. Den Ablauf in Sätzen aufschreiben. Wer beginnt, was passiert danach, wann ist der Vorgang abgeschlossen. Ohne diese Beschreibung entsteht eine Sammlung schöner Bildschirme ohne roten Faden.
2. Echte Beispiele verwenden. Statt »Lorem ipsum« stehen Kundennamen, Artikelnummern und Mengen aus dem Alltag darin, als Beispieldaten und nicht als Kundendaten. Erst dann merkt der Sachbearbeiter, dass die Spalte für seine Nummer zu schmal ist.
3. Den Sonderfall mitnehmen. Neben dem Normalweg gehört mindestens ein Fehler hinein: fehlende Angabe, abgelehnte Freigabe, doppelter Eintrag.
4. Auf dem richtigen Gerät zeigen. Ein Ablauf für den Außendienst wird auf dem Telefon getestet, nicht auf dem großen Bildschirm im Besprechungsraum.

Der Test mit echten Nutzern

Ein Prototyp dieser Art entfaltet seinen Wert erst, wenn ihn die Menschen bedienen, die später mit der Anwendung arbeiten. Man gibt ihnen eine Aufgabe, etwa »Buchen Sie eine Entnahme von zwölf Kartons«, und schaut zu, ohne zu helfen. Wo jemand zögert, zurückklickt oder fragt, liegt ein Problem im Entwurf.

Schon wenige Durchläufe zeigen die größten Hürden. Die Erkenntnisse fließen in das Lastenheft und später in die Abnahmekriterien: Wenn der Test gezeigt hat, dass eine Entnahme in vier Schritten möglich sein muss, lässt sich das bei der Abnahme prüfen.

Festgehalten wird dabei nicht die Meinung, sondern das Verhalten: welche Aufgabe gelöst wurde, an welcher Stelle jemand hängen blieb und welche Begriffe missverstanden wurden. Eine einfache Tabelle mit Aufgabe, Beobachtung und Entscheidung genügt. Sie wird zur Grundlage der Überarbeitung und zeigt später, warum ein Bildschirm so aussieht, wie er aussieht, auch wenn die Beteiligten längst gewechselt haben.

Woran solche Prototypen scheitern

• Zu schön, zu früh. Ein ausgefeiltes Design lenkt die Diskussion auf Farben, bevor der Ablauf stimmt.
• Nur die Geschäftsführung klickt. Wer den Vorgang nicht selbst erledigt, übersieht die Stellen, an denen es im Alltag hakt.
• Zu viele Varianten. Wer drei Entwürfe gleichzeitig testen lässt, bekommt verwischte Antworten. Besser ist ein Entwurf pro Durchlauf, der danach gezielt verändert wird.
• Der Prototyp wird zum Versprechen. Was er zeigt, ist ein Entwurf. Welche Funktionen tatsächlich gebaut werden, steht im Angebot, nicht in der Attrappe.
• Keine Entscheidung am Ende. Ein Test ohne festgehaltene Ergebnisse produziert Eindrücke, aber keine Grundlage für die Umsetzung.

Wie wir ihn einsetzen

Bei Vorhaben mit mehreren Rollen oder Kundenkontakt steht der Prototyp vor dem Angebot für die Umsetzung. Wir bauen ihn mit echten Beschriftungen und Beispieldaten, testen ihn mit zwei oder drei künftigen Nutzern und halten die Ergebnisse schriftlich fest. Soll die Anwendung später unterwegs laufen, zeigen wir ihn als Progressive Web App auf dem Telefon. Wie es danach weitergeht, beschreibt die Seite App-Entwicklung.