Selbst-Test (Eigen-Erfahrung)

Ein Selbst-Test im Design Thinking heißt: Du erledigst die Aufgabe deiner Zielgruppe selbst, unter möglichst echten Bedingungen, und protokollierst dabei, was du tust, was du fühlst und wo du hängen bleibst. Er ist eine der einfachsten Methoden der Phase Verstehen. Du brauchst dafür weder Termine mit Fremden noch ein Budget. Gerade Teams, die einen Service seit Jahren betreiben, sehen dabei oft zum ersten Mal, was ihre Kundinnen erleben.

Wo der Selbst-Test im Prozess steht

Am besten passt er ganz am Anfang. Bevor das Team mit Menschen spricht, hat es den Ablauf einmal selbst durchlaufen und weiß, wo es hakt. Daraus entstehen gezielte Fragen für den Interview-Leitfaden. Im Gespräch kannst du dann nachhaken: Mir ist an dieser Stelle etwas aufgefallen, wie war das bei dir?

Danach kommen die Menschen selbst zu Wort. Was der Selbst-Test zeigt, prüfst du im Explorativen Interview oder beobachtest es bei Fly on the Wall. Wer die Befunde ordnen will, legt sie entlang des Ablaufs auf eine User Journey, die später mit den Aussagen aus den Gesprächen ergänzt wird. Auch später im Projekt hat der Selbst-Test seinen Platz: Bevor ein Prototyp an echte Testpersonen geht, probiert das Team ihn selbst aus und räumt die gröbsten Hürden weg.

Welche Aufgabe du dir vornimmst

Die Wahl der Aufgabe entscheidet, was du siehst. Diese Aufgabentypen eignen sich gut:

• Der erste Kontakt. Du kennst das Angebot nicht und findest es über eine Suchmaschine. Wie lange dauert es, bis du weißt, was du tun musst?
• Der Normalfall. Die häufigste Aufgabe, die Kundinnen erledigen, von Anfang bis Ende.
• Der Störfall. Etwas läuft schief: Ein Dokument fehlt, die Zahlung klappt nicht, du willst einen Termin verschieben.
• Das Ende. Du willst kündigen, dich abmelden oder etwas zurückgeben.

Der Störfall und das Ende zeigen oft mehr als der Normalfall, weil sich dort selten jemand aus dem Team hineinversetzt hat.

Varianten

In Paaren handelt eine Person, die andere protokolliert. Die handelnde Person spricht laut aus, was sie denkt. Danach tauscht ihr. So entstehen genaue Protokolle, und das laute Denken macht Annahmen hörbar, die sonst unbemerkt bleiben.

Mit verteilten Aufgaben bekommt jedes Paar einen anderen Aufgabentyp. In einer Stunde deckt ein Team von acht Leuten so den ganzen Lebenszyklus eines Angebots ab.

Vor Ort geht das Team selbst an den Schalter, ruft die Hotline an oder schickt eine Anfrage per Post. Diese Kanäle vergessen Teams leicht, wenn sie nur am Bildschirm testen.

Mit Einschränkungen probierst du den Ablauf am Smartphone mit langsamer Verbindung, mit großer Schrift oder nur mit der Tastatur. Das zeigt technische Barrieren. Wie Menschen mit Behinderung den Ablauf erleben, erfährst du im Gespräch mit ihnen.

Ein Beispiel

Angenommen, das Team einer Gemeindeverwaltung will die Anmeldung für einen Kita-Platz verbessern. Sechs Leute aus Verwaltung und IT nehmen sich eine Stunde Zeit. Drei Paare bekommen drei Aufgaben: einen Platz zum ersten Mal beantragen, die Anmeldung nach einem Umzug ändern und eine Anmeldung zurückziehen.

Das erste Paar startet bei einer Suchmaschine und landet zuerst auf einer veralteten Seite. Das zweite Paar findet keine Stelle, an der sich eine Adresse ändern lässt, und schreibt nach zwölf Minuten eine Mail. Das dritte Paar braucht für das Zurückziehen eine Unterschrift auf Papier. Im Vergleich zeigt sich, dass alle drei Paare an der Anmeldeseite mit dem Login hängen geblieben sind. Dieser Befund geht sofort in die Liste der Änderungen. Die Frage, ob Eltern eher per Mail oder per Telefon nachfragen, kommt in den Leitfaden für die Interviews.

Woran du einen ergiebigen Selbst-Test erkennst

Die Protokolle sind konkret. Sie enthalten Uhrzeiten, die Wörter, an denen du gestutzt hast, und Screenshots oder Fotos von der Stelle, an der es hakte. Neben den Handlungen stehen Gefühle: genervt, unsicher, erleichtert. Und mindestens ein Befund hat das Team überrascht, obwohl es den Ablauf zu kennen glaubte.

Was du danach mit den Befunden machst

Kleine Hürden wie eine unklare Beschriftung oder ein toter Link lassen sich oft sofort beheben. Größere Befunde wandern in die Synthese. Eine Empathy Map baust du daraus noch nicht, die entsteht aus Gesprächen mit echten Menschen. Wer den Ablauf hinter der Oberfläche verstehen will, zeichnet einen Service Blueprint und markiert dort die Stellen aus dem Selbst-Test. Wenn ein neuer Ablauf entworfen ist, kannst du ihn im Rollenspiel-Test durchspielen, bevor er gebaut wird.