Human-centred Design

Human-centred Design

0:00 Im ersten Modul haben wir sortiert, worüber wir eigentlich reden. Jetzt kommt die Frage dahinter: Woher wissen wir überhaupt, für wen und wofür wir bauen? In vielen Projekten lautet die ehrliche Antwort: Wir nehmen es an. Und Annahmen haben eine unangenehme Eigenschaft — solange sie unausgesprochen bleiben, kann man sie nur verteidigen, nicht überprüfen.

0:21 Dieses Modul zeigt einen Prozess, der aus Vermutungen prüfbare Aussagen macht. Er ist in einer Norm beschrieben, klingt deshalb erst einmal trocken, ist aber im Kern erstaunlich pragmatisch. Und er liefert das Material, mit dem wir im nächsten Modul die KI arbeiten lassen.

Human-centred Design

0:37 Neun Kapitel liegen vor uns, und sie folgen dem Weg vom Nichtwissen zur belastbaren Aussage. Wir starten beim Prozessmodell, gehen über den Nutzungskontext zu den Forschungsmethoden, schauen uns die vier Quellen an, die praktisch jedes Projekt schon hat, und arbeiten uns dann zu Personas, Journeys und Hypothesen vor. Ein eigenes Kapitel gehört der Einbeziehung von Menschen mit Behinderungen — das ist für dieses Seminar zentral. Am Ende nehmen Sie selbst einen Nutzungskontext auf.

1:05 Behalten Sie dabei den Leitsatz im Kopf: Aufgeschriebene Vermutungen lassen sich widerlegen.

Human-centred Design nach ISO 9241-210

1:10 Beginnen wir mit dem Rahmen. Es gibt eine internationale Norm für nutzerzentrierte Gestaltung, und sie beschreibt keinen Geschmack, sondern einen Ablauf. Vier Tätigkeiten, die im Kreis laufen — und genau dieser Kreis ist der Punkt, an dem die meisten Projekte sparen. Die Norm ist 2019 erschienen und 2025 noch einmal bestätigt worden — sie ist also der aktuelle Referenzrahmen und kein historisches Dokument.

1:36 Was sie beschreibt, klingt fast banal: Kontext verstehen, Anforderungen festlegen, Lösungen entwickeln, evaluieren. Dann von vorn. Denken Sie an einen Arzt: erst untersuchen, dann Befund, dann Behandlung, dann Kontrolle — und wenn die Kontrolle etwas zeigt, geht es wieder von vorn. Kein Arzt würde die Kontrolle ans Ende der Behandlungsserie legen. In Softwareprojekten passiert genau das ständig.

2:01 Der entscheidende Satz der Norm ist deshalb: Die Evaluation gehört in jede Iteration, nicht ans Ende. Interessant an dieser Tabelle ist die rechte Spalte, denn sie beschreibt Ihren Projektalltag. Der Kontext wird übersprungen, sobald die Zielgruppe als bekannt gilt — und bekannt ist sie fast immer, jedenfalls gefühlt. Die Anforderungen fallen weg, wenn der Entwurf schon feststeht, weil dann niemand mehr eine Anforderung dagegen hören will. Die Evaluation entfällt, sobald der Termin näher rückt.

2:31 Nur bei der mittleren Zeile steht: wird nie übersprungen. Gebaut wird immer. Das ist die eigentliche Diagnose dieser Tabelle — wir kürzen zuverlässig das Verstehen und das Prüfen und lassen das Bauen unangetastet. Die Reihenfolge des Sparens ist genau verkehrt herum. Warum das nicht beliebig ist, zeigt eine Kette von Abhängigkeiten. Ohne Kontext sind Anforderungen nur Wünsche — sie sagen nichts über tatsächliche Nutzung aus.

2:56 Ohne prüfbare Anforderungen kann eine Evaluation gar nichts feststellen, weil ihr der Maßstab fehlt. Und eine Evaluation ganz am Ende findet zuverlässig nur noch das, was zu teuer zu ändern ist; sie erzeugt dann Frust statt Verbesserung. Der letzte Punkt ist der, den ich am wichtigsten finde: Ein einzelner Durchlauf ist noch kein Prozess. Die Schleife ist der Kern.

3:18 Ein Projekt, das den Kreis genau einmal dreht, hat nutzerzentrierte Gestaltung nicht angewendet, sondern nur zitiert. Der erste Stolperstein ist der elegante: Man hakt die Norm als Formalie ab, schreibt sie ins Angebot und arbeitet weiter nach Entwurfsvorlage. Der zweite ist inhaltlich der schwerwiegendste — Nutzungsanforderungen mit funktionalen Anforderungen zu verwechseln.

3:41 Eine funktionale Anforderung sagt, dass das System umbuchen können muss. Eine Nutzungsanforderung sagt, dass eine unterwegs befindliche Person das ohne Anruf schafft. Das ist ein gewaltiger Unterschied, und nur die zweite Fassung ist überhaupt prüfbar. Der dritte: die Iteration einsparen und stattdessen den ersten Entwurf verteidigen.

4:01 Das ist menschlich verständlich und trotzdem der teuerste Reflex im ganzen Prozess.

Nutzungskontext, Zielgruppen, Aufgaben und Umgebung

4:06 Der erste Prozessschritt verdient ein eigenes Kapitel, weil er über einen erstaunlich großen Teil der Gestaltung entscheidet. Wer den Nutzungskontext beschreibt, hat viele Designfragen schon halb beantwortet — und muss sie nicht mehr nach Geschmack entscheiden. Nutzungskontext heißt schlicht: Wer, wofür, womit und unter welchen Bedingungen. Und die Bedingungen sind der Teil, der am häufigsten fehlt.

4:29 Nehmen Sie die Fahrtwind-Buchung am Bahnsteig: pralle Sonne auf dem Display, Lärm, eine Hand frei, weil die andere den Koffer hält, und zwei Minuten bis zur Abfahrt. Dieselbe Buchung abends am Schreibtisch ist ein völlig anderer Fall — bei exakt derselben Oberfläche. Das Entscheidende: Es ist nicht einmal eine andere Zielgruppe.

4:48 Es ist dieselbe Person in einer anderen Situation. Wer nur Zielgruppen beschreibt, verpasst deshalb die Hälfte der relevanten Information. Lesen Sie diese Tabelle von unten nach oben, dann sehen Sie das Prinzip. Die letzte Zeile ist die Konsequenz, alles darüber die Begründung. Große Ziele und hoher Kontrast sind am Bahnsteig keine Vorliebe, sondern die logische Folge aus Sonnenlicht, Bewegung und einer freien Hand.

5:13 Am Schreibtisch ist dichte Information zumutbar, weil Ruhe, gleichmäßiges Licht und Zeit zum Vergleichen zur Verfügung stehen. Der Gewinn dieser Darstellung liegt in der Diskussion danach: Sobald jemand die Zielgröße kleiner haben möchte, diskutieren Sie nicht mehr über Geschmack, sondern über den Nutzungskontext. Und der ist erhebbar.

5:32 Was Sie hier sehen, ist bewusst spartanisch: ein Steckbrief je Hauptaufgabe, vier Zeilen zur Situation, darunter die Folgen für den Entwurf. Auf das Format kommt es nicht an — Sie können das in einer Textdatei, im Wiki oder im Ticket führen. Worauf es ankommt, ist der Block ganz unten. Die vier oberen Zeilen beschreiben, wie es ist. Die Folgen sagen, was daraus zu tun ist.

5:55 Genau diese Brücke fehlt in den meisten Kontextbeschreibungen: Sie werden erhoben, abgelegt und nie wieder angefasst, weil niemand sie in Anforderungen übersetzt hat. Der Steckbrief ist klein genug, dass diese Übersetzung tatsächlich passiert. Der eigentliche Wert zeigt sich im Streitfall, und deshalb lohnt der geringe Aufwand. Der Steckbrief begründet Zielgrößen und Kontraste, statt sie zur Geschmacksfrage zu machen.

6:20 Er macht sichtbar, für welchen Fall gerade entworfen wird — und das ist oft die Auflösung eines Konflikts, weil zwei Beteiligte über zwei verschiedene Situationen gesprochen haben. Er ist überprüfbar: Der beschriebene Fall trifft zu oder nicht. Und er verhindert die stille Annahme, alle säßen am Schreibtisch mit Maus, Tastatur und Zeit.

6:39 Diese Annahme steckt in erschreckend vielen Entwürfen — nicht aus Nachlässigkeit, sondern weil wir alle beim Entwerfen genau so sitzen. Der erste Stolperstein ist der begriffliche: Zielgruppe und Nutzungskontext werden verwechselt. Dieselbe Person, andere Situation, andere Anforderung — das ist der Kern des Kapitels. Der zweite: Nur der Idealfall wird beschrieben, die Ausnahme improvisiert man später.

7:03 Nur besteht der Alltag zu einem guten Teil aus Ausnahmen. Und der dritte ist psychologisch interessant: Umgebungsbedingungen werden weggelassen, weil sie sich unangenehm anfühlen. Niemand schreibt gern auf, dass die Anwendung unter Zeitdruck und schlechten Sichtverhältnissen bedient wird, weil das die eigene Arbeit erschwert.

7:22 Genau das ist aber die Realität, und wer sie nicht aufschreibt, entwirft an ihr vorbei.

Qualitative und quantitative Nutzerforschung

7:28 Jetzt zur Frage, wie man das alles herausfindet. Es gibt zwei große Methodenfamilien, sie beantworten unterschiedliche Fragen, und die meisten Fehlschlüsse in der Nutzerforschung entstehen daraus, dass man die eine für die andere hält. Der Unterschied lässt sich in zwei Wörtern fassen: wo und warum. Nehmen Sie eine typische Zahl aus der Webanalyse — 38 Prozent der Buchungen brechen im Schritt Reisendendaten ab.

7:53 Das ist ein wertvoller Befund, aber er erklärt gar nichts. Er sagt Ihnen den Ort, nicht die Ursache. Erst wenn jemand danebensitzt und zusieht, zeigt sich: Das Geburtsdatumsfeld erzwingt ein bestimmtes Format, nennt es aber nirgends. Das ist wie ein Rauchmelder — er sagt zuverlässig, in welchem Zimmer es brennt, aber nicht, warum. Beides brauchen Sie, und keines ersetzt das andere.

8:17 Die aufschlussreichste Zeile dieser Tabelle ist die letzte: Wo versagt die jeweilige Familie. Quantitative Daten versagen bei Ursachen und Absichten — sie können nicht wissen, was jemand vorhatte. Qualitative Daten versagen bei Aussagen über Häufigkeit — fünf beobachtete Personen sagen nichts über zehntausend. Beide Grenzen werden im Alltag ständig überschritten, meist in guter Absicht und unter Zeitdruck.

8:41 Wenn Sie sich eine Faustregel merken wollen: Sobald Sie aus qualitativen Daten eine Zahl machen oder aus quantitativen Daten eine Ursache, haben Sie die Grenze überschritten. Beides passiert schneller, als man denkt, und beides ist in Präsentationen fast unsichtbar. Warum das kein methodischer Luxus ist, sondern schlicht wirtschaftlich: Eine Abbruchquote ohne Erklärung führt zu Maßnahmen auf Verdacht, und Maßnahmen auf Verdacht wirken ungefähr so zuverlässig wie Raten.

9:08 Eine Beobachtung ohne Häufigkeit lässt sich nicht priorisieren — Sie wissen dann zwar, dass es ein Problem gibt, aber nicht, ob es das wichtigste ist. Zusammen ergeben beide eine Aussage, die man im Lenkungskreis verteidigen kann. Und der letzte Punkt ist der, der Budgetdiskussionen beendet: Beide Methoden zusammen kosten weniger als eine einzige Maßnahme, die nicht wirkt.

9:29 Fehlinvestitionen sind teurer als Forschung — sie fallen nur später auf. Drei Fehler, die jeder von uns schon gemacht hat. Aus fünf Beobachtungen eine Prozentzahl machen — vier von fünf klingt nach achtzig Prozent, ist aber nur vier von fünf. Aus einer Abbruchquote eine Ursache ableiten: Die Zahl steht da, die Erklärung entsteht im Kopf, und beide werden gemeinsam präsentiert.

9:51 Und der dritte Fehler ist ein Ressourcenfehler: die teurere Methode wählen, obwohl die vorhandenen Daten schon reichen. Das führt uns direkt zum nächsten Kapitel, denn erstaunlich viel liegt in Ihren Systemen bereits herum — man muss es nur ansehen.

Interviews, Beobachtung, Supportdaten und Webanalyse

10:06 Vier Quellen stehen praktisch jedem Projekt offen. Sie unterscheiden sich stark in Kosten und in Ehrlichkeit — und die günstigste ist erstaunlich oft die aufschlussreichste. Schauen wir uns an, welche sich wann lohnt. Interviews, Beobachtung, Supportanfragen und Webanalyse — diese vier haben Sie praktisch immer zur Verfügung.

10:25 Und sie unterscheiden sich enorm, sowohl im Aufwand als auch in dem, was sie tatsächlich aussagen. Meine Empfehlung für eine gute Discovery ist einfach: Kombinieren Sie mindestens zwei, und zwar am besten eine, die schon vorliegt, mit einer, die Verhalten zeigt. Damit haben Sie den günstigen Einstieg und die belastbare Beobachtung zusammen. Was Sie nicht brauchen, ist der große Rundumschlag.

10:48 Vier Quellen gleichzeitig zu erheben ist nicht gründlicher, sondern nur teurer — und meist ist das Projekt vorbei, bevor die Auswertung steht. Achten Sie auf die Kombination aus Schwäche und Aufwand. Interviews liefern Begründungen, aber Menschen legen sich ihre Gründe nachträglich zurecht — nicht aus Unehrlichkeit, sondern weil unser Gedächtnis so arbeitet.

11:10 Beobachtung zeigt echtes Verhalten, ist aber teuer und liefert wenige Fälle. Supportanfragen sind der eigentliche Schatz dieser Tabelle: Sie liegen schon vor, sie sind ungefiltert, und sie kosten fast nichts — nur melden sich eben nur die Lauten. Webanalyse liefert große Zahlen für kleines Geld, ist aber blind für Absichten. Kurz: Die beiden günstigen Quellen sind unvollständig, aber verfügbar.

11:33 Genau deshalb fängt man mit ihnen an. Diese vier Schritte sind eine Reihenfolge nach Kosten, und sie funktionieren erstaunlich zuverlässig. Sie sichten drei Monate Supportanfragen und bündeln grob — das ist eine Nachmittagsarbeit, kein Projekt. Die drei größten Bündel prüfen Sie in der Webanalyse gegen, damit Sie wissen, ob sie viele oder nur laute Fälle betreffen.

11:55 Zu den bestätigten Bündeln setzen Sie je zwei Beobachtungen an, und erst danach entscheiden Sie, ob Interviews überhaupt noch etwas beitragen. Sehr oft tun sie das nicht mehr. Wer umgekehrt mit Interviews beginnt, erhebt für viel Geld genau das, was im Ticketsystem seit Monaten steht. Der erste Stolperstein ist der teure Start: Die Discovery beginnt mit dem aufwendigsten Verfahren, weil das nach Gründlichkeit aussieht.

12:19 Der zweite ist ein Haltungsproblem — Supportdaten als Beschwerdesammlung abtun statt als Feldforschung. Dabei ist ein Support-Ticket nichts anderes als ein Protokoll einer gescheiterten Nutzung, geschrieben von der Person, die es erlebt hat. Der dritte betrifft die Webanalyse: Zahlen interpretieren, ohne die Messpunkte zu kennen.

12:38 Wenn Sie nicht wissen, wann genau ein Ereignis ausgelöst wird, wissen Sie auch nicht, was die Quote bedeutet. Das kostet keine Methodik, nur ein Gespräch mit den Leuten, die das Tracking eingebaut haben.

Personas, Proto-Personas und Jobs-to-be-Done

12:51 Kommen wir zu den bekanntesten Werkzeugen der Disziplin — und zu den am häufigsten falsch verwendeten. Personas, Proto-Personas und Jobs-to-be-Done sind drei verschiedene Dinge mit drei verschiedenen Zwecken. Wer sie verwechselt, produziert schöne Dokumente ohne Wirkung. Der wichtigste Satz zuerst: Eine Persona ist ein Kommunikationsmittel, kein Forschungsergebnis. Sie hilft einem Team, über dieselbe Person zu sprechen. Sie belegt nichts.

13:17 Eine Proto-Persona ist ehrlicher — sie sagt ausdrücklich, dass hier Annahmen stehen, und markiert sie als ungeprüft. Jobs-to-be-Done verschieben den Blick noch einmal grundlegend: weg von Eigenschaften, hin zu Absichten. Nicht das Alter einer Person ist die brauchbare Information, sondern was sie erreichen will und was sie dazu gebracht hat. Aus einer Absicht lässt sich etwas bauen.

13:40 Aus einem Geburtsjahr nicht. Die rechte Spalte ist hier die wichtige, denn sie beschreibt die typische Fehlnutzung. Eine Persona taugt zur Verständigung, aber nicht als Beleg für eine Entscheidung — und genau als Beleg wird sie in Meetings dauernd eingesetzt: „Anna würde das nicht verstehen." Anna existiert nicht, sie kann gar nichts nicht verstehen.

14:01 Eine Proto-Persona macht Annahmen sichtbar, ersetzt aber keine Erhebung; sie ist der Anfang der Arbeit, nicht ihr Ergebnis. Und Jobs-to-be-Done fassen Absichten und Auslöser, taugen aber nicht für demografische Aussagen. Jedes Format hat also eine Zone, in der es hilfreich ist — und eine, in der es Sicherheit vortäuscht.

14:21 Diese Gegenüberstellung ist mein Lieblingsbeispiel des Moduls, weil sie in fünf Sekunden erklärt, was sonst eine halbe Stunde dauert. Oben steht eine Persona: Studentin, vierundzwanzig, technikaffin, nutzt gern Apps. Fragen Sie sich ehrlich — was bauen Sie daraus? Nichts davon sagt Ihnen, welche Funktion gebraucht wird. Unten steht dieselbe Person als Job-to-be-Done, und der Satz hat drei Teile: die Situation, die Absicht, das Ziel dahinter.

14:49 Ausgefallene Fahrt, bereits unterwegs, umbuchen ohne Anruf, damit der Anschluss noch klappt. Daraus lässt sich unmittelbar ein Task Flow ableiten — und genau darum geht es im nächsten Kapitel. Der erste Stolperstein ist eine schleichende Statusveränderung: Personas werden erfunden, weil man schnell etwas brauchte, und ein halbes Jahr später gelten sie als Forschungsergebnis.

15:12 Niemand hat gelogen, es hat sich einfach niemand erinnert. Schreiben Sie die Herkunft dazu. Der zweite: Demografie als Anforderung lesen. Ein Alter beschreibt keine Aufgabe. Und der dritte ist ein Mengenproblem — zu viele Personas, bis niemand mehr weiß, für wen gerade entworfen wird. Zwei oder drei, die im Kopf bleiben, wirken mehr als acht, die im Wiki liegen. Und für die Priorisierung ist es ohnehin gesünder, über Aufgaben zu streiten als über Personennamen.

Customer Journey, User Journey und Task Flow

15:41 Jetzt zu den Darstellungen von Abläufen — und zu einer Verwechslung, die zuverlässig unbrauchbare Diagramme erzeugt. Es geht um Flughöhen. Drei Ebenen, drei Zwecke, und in ein Diagramm gehören sie nicht. Denken Sie an Kartenmaßstäbe. Die Customer Journey ist die Europakarte: Werbung, Kauf, Kundendienst, Erstattung — alles drauf, aber ohne Straßennamen.

16:04 Die User Journey ist die Stadtkarte: der Umgang mit dem Produkt selbst. Und der Task Flow ist der Straßenplan mit jeder Ampel: eine einzelne Aufgabe, Schritt für Schritt. Niemand navigiert mit der Europakarte durch eine Stadt, und niemand plant eine Fernreise mit dem Straßenplan. Für die Umsetzung brauchen Sie den Task Flow, für die Priorisierung die Ebene darüber. Beides ist legitim — nur eben nicht gleichzeitig und nicht im selben Bild.

16:31 Die rechte Spalte ist wieder die entscheidende, weil sie nach dem Zweck fragt und nicht nach dem Inhalt. Die Customer Journey brauchen Sie, wenn Sie Investitionen priorisieren — wo lohnt sich Geld überhaupt. Die User Journey brauchen Sie, um Brüche zwischen Bereichen zu finden, also die Übergänge, über die wir in Modul eins gesprochen haben.

16:51 Und den Task Flow brauchen Sie zum Entwerfen, Umsetzen und Testen. Machen Sie daraus eine Prüffrage für jedes Ablaufdiagramm, das Ihnen vorgelegt wird: Welche Entscheidung soll daraus folgen? Wenn niemand antworten kann, ist die Flughöhe falsch gewählt — oder das Diagramm entstand aus Fleiß statt aus Bedarf. Vier Warnzeichen, und sie sind angenehm leicht zu prüfen. Erstens: Das Diagramm passt nicht auf eine Seite und wird trotzdem weiter ergänzt.

17:17 Zweitens: Niemand kann sagen, welche Entscheidung daraus folgen soll. Drittens — mein liebstes Indiz — Werbung und Fehlermeldungen stehen nebeneinander in derselben Reihe. Das ist der sichere Beleg, dass zwei Flughöhen vermischt wurden. Und viertens: Es wird gepflegt, weil es existiert, nicht weil es genutzt wird. Dieses letzte Zeichen gilt übrigens für erstaunlich viele Artefakte in Projekten.

17:42 Ein Diagramm, das seit einem Jahr niemand für eine Entscheidung herangezogen hat, ist Dokumentation, nicht Werkzeug. Der erste Stolperstein ist der Vollständigkeitsreflex: alle drei Ebenen in ein Diagramm zwingen. Das Ergebnis ist beeindruckend und für keine Entscheidung brauchbar. Der zweite ist eine Reihenfolgefrage — den Task Flow erst nach dem Entwurf zeichnen, als Dokumentation.

18:05 Dann beschreibt er nur noch, was ohnehin gebaut wurde, und kann nichts mehr in Frage stellen. Und der dritte ist der folgenreichste: nur den Erfolgsweg zeichnen. Abbruch, Fehler und Rückkehr fehlen dann im Bild — und damit auch im Entwurf und im Code. Wir kommen darauf in Modul vier zurück, wenn es um die Zustände abseits des Normalfalls geht.

Hypothesen statt ungeprüfter Annahmen

18:27 Damit sind wir beim Leitsatz dieses Moduls. In jeder Gestaltungsentscheidung steckt eine Vermutung. Die Frage ist nur, ob sie aufgeschrieben wird — denn davon hängt ab, ob wir sie später prüfen oder bloß verteidigen. Jede Entscheidung an einer Oberfläche enthält eine Vermutung darüber, wie Menschen sie verstehen werden. Das ist unvermeidlich und völlig in Ordnung.

18:49 Problematisch wird es erst, wenn die Vermutung unausgesprochen bleibt. Denn dann hat sie eine unangenehme Eigenschaft: Man kann sie nicht widerlegen, sondern nur verteidigen — und im Zweifel gewinnt die Person mit der besseren Rhetorik oder dem höheren Rang. Schreiben Sie dieselbe Vermutung als prüfbaren Satz auf, dreht sich das Verhältnis um. Jetzt kann sie falsch sein, und das ist ein Fortschritt.

19:11 Wissenschaft funktioniert genau so, und Produktentwicklung profitiert enorm davon. Vergleichen Sie die beiden Fassungen. Oben steht: Das Datumsfeld ist verwirrend. Das kann man glauben oder bestreiten, mehr nicht. Unten steht dieselbe Sache in einer Form, die sich überprüfen lässt: die vermutete Maßnahme, die erwartete Wirkung, der Messpunkt und — entscheidend — die Schwelle.

19:34 Ohne den letzten Satz bleibt auch eine Hypothese Geschmackssache, denn dann diskutieren Sie hinterher darüber, ob die Verbesserung reicht. Legen Sie die Schwelle vorher fest, solange noch niemand weiß, wie die Zahlen ausfallen. Das ist unbequem und genau deshalb wirksam. Nachher findet sich immer eine Begründung, warum das Ergebnis eigentlich ein Erfolg war.

19:56 Fünf Schritte, und der erste ist der schwerste: die Annahme ohne Lösung aufschreiben. Wir denken in Lösungen, und eine Annahme, die schon eine Lösung enthält, kann nur noch bestätigt werden. Dann ergänzen Sie die vermutete Wirkung, legen fest, woran Sie sie erkennen, und benennen die Schwelle. Schritt fünf ist der, den fast alle weglassen, und der einzige, der Konsequenzen erzwingt: Was passiert, wenn die Schwelle nicht erreicht wird?

20:21 Ohne diese Vereinbarung wird jedes Ergebnis irgendwie positiv gedeutet. Mit ihr haben Sie vorher entschieden, was Sie tun — und das ist erheblich billiger als hinterher zu streiten. Drei Stolpersteine, die alle denselben Kern haben: Man will recht behalten. Erstens die Lösung schon in die Hypothese schreiben, sodass nur noch bestätigt werden kann.

20:42 Zweitens die Schwelle nachträglich festlegen, wenn die Zahlen vorliegen — das ist menschlich extrem verführerisch und methodisch wertlos. Und drittens: Hypothesen sammeln, ohne je eine zu prüfen. Das ist die höfliche Variante des Nichtstuns; es entsteht ein gepflegtes Dokument, das nach Methodik aussieht und nichts entscheidet.

21:01 Lieber zwei Hypothesen, die wirklich geprüft werden, als zwanzig im Wiki. Und beim Prüfen sind wir dann in Modul vierzehn, bei der systematischen Evaluation.

Einbeziehung von Menschen mit Behinderungen

21:12 Jetzt zu dem Kapitel, das für dieses Seminar den größten Unterschied macht. Alle Kriterienkataloge der Welt ersetzen nicht die Erfahrung, einmal zugesehen zu haben, wie jemand mit assistiver Technologie an Ihrer Oberfläche arbeitet. Sie können jede Prüfliste dieses Seminars auswendig lernen und trotzdem überrascht sein, wenn Sie zum ersten Mal beobachten, wie eine blinde Nutzerin die Sitzplatzauswahl bedient.

21:36 Das ist keine Kritik an Prüflisten — sie sind notwendig. Aber sie erzeugen Wissen, keine Vorstellung. Solche Sitzungen brauchen allerdings Sorgfalt: Vorlauf, eine faire Aufwandsentschädigung und einen Ablauf, der die Technik der Teilnehmenden respektiert. Eigener Rechner, eigene Einstellungen, eigenes Tempo. Wer jemanden an einen fremden Rechner mit fremder Konfiguration setzt, misst nicht die Anwendung, sondern die Umstellung — und bekommt Ergebnisse, die niemandem nützen.

22:03 Diese fünf Schritte sind organisatorisch, nicht methodisch — und genau daran scheitert es meistens. Verständliche Aufgaben ohne Vorwissen, Teilnehmende über eine Interessenvertretung oder ein Panel, Entschädigung und Ablauf vorab schriftlich geklärt. Schritt vier ist der, den ich Ihnen besonders ans Herz lege: Prüfen Sie den Testaufbau selbst auf Barrieren.

22:25 Das Terminwerkzeug, das Einverständnisformular, die Einladungsmail, die Videokonferenz. Ein unzugängliches Testwerkzeug misst am Ende sich selbst, und Sie haben eine Sitzung voller Befunde, die nichts mit Ihrem Produkt zu tun haben. Und Schritt fünf: eigene Technik der Teilnehmenden, nicht gestellte. Immer. Der Zeitpunkt entscheidet über den Nutzen. Grundsatzprobleme sitzen in der Struktur — in der Navigation, im Ablauf, in der Semantik.

22:51 Die findet man nicht im letzten Feinschliff, und wenn doch, ist die Änderung teuer und wird zur Ausnahmeregel erklärt. Interessant ist der dritte Punkt: Solche Befunde verändern die Haltung im Team stärker als jede Schulung. Ich habe mehrfach erlebt, dass eine einzige beobachtete Sitzung mehr bewirkt hat als ein zweitägiges Training.

23:10 Und der letzte Punkt ist der nüchterne: Wer erst zur Abnahme testet, bekommt Ergebnisse, die niemand mehr verwenden kann. Dann ist es keine Forschung mehr, sondern Dokumentation des Scheiterns. Der erste Stolperstein ist gut gemeint und trotzdem falsch: Kolleginnen mit verbundenen Augen testen lassen und das für Forschung halten.

23:30 Was Sie dabei beobachten, ist der Schock einer ungeübten Person, nicht die Nutzung durch jemanden, der seinen Screenreader seit Jahren beherrscht — oft in einer Geschwindigkeit, bei der Sie kaum folgen können. Als Sensibilisierung ist die Übung wertvoll, als Erhebung wertlos. Der zweite: ohne Aufwandsentschädigung anfragen und Freiwilligkeit voraussetzen.

23:50 Das ist Arbeit, und Arbeit wird bezahlt. Und der dritte: mit gestellter Technik arbeiten, auf die niemand eingerichtet ist. Dann testen Sie fremde Hardware, nicht Ihr Produkt.

Übung — Nutzungskontext und Task Flow aufnehmen

24:01 Damit zur Übung. Sie gehen den Weg dieses Moduls in klein: vom Nutzungskontext über den Ablauf bis zu den Annahmen, die darin stecken. Und Sie werden sehen — es sind mehr Annahmen, als Sie erwarten. Sie wählen einen Vorgang bei Fahrtwind und beschreiben ihn zweifach: erst als Kontext-Steckbrief mit vier Dimensionen, dann als Task Flow mit höchstens zehn Schritten.

24:23 Geübt wird dabei die Ableitung — aus einer Situation einen prüfbaren Ablauf machen und die darin verborgenen Annahmen benennen. Erfolgreich sind Sie, wenn jede Annahme markiert und mit einer Prüfidee versehen ist. Ein Hinweis aus der Erfahrung: Gruppen unterschätzen die Zahl der Annahmen fast immer. Zehn Schritte tragen erfahrungsgemäß acht bis zwölf. Wenn Sie nur drei finden, haben Sie wahrscheinlich noch nicht genau genug hingesehen.

24:48 Wer früh fertig ist, zeichnet zusätzlich den Abbruchweg. Der Ablauf hat eine wichtige Nebenbedingung, und die steht in der Fußzeile: nicht entwerfen. Sobald Bildschirme entstehen, hört eine Gruppe auf, den Ablauf zu prüfen, und beginnt zu gestalten — das ist ein starker Reflex und er kippt die Übung. Halten Sie sich deshalb an die Reihenfolge: Steckbrief, dann Ablauf ohne Oberflächenentwurf, dann jeden Schritt auf seine Annahme abklopfen, dann zu den drei riskantesten je eine Prüfidee.

25:16 Der fünfte Schritt ist der ehrlichste: Lesen Sie Ihren Ablauf einer anderen Gruppe vor und achten Sie auf die Rückfragen. Jede Rückfrage markiert eine Stelle, an der Sie stillschweigend etwas vorausgesetzt haben. Der erste Stolperstein ist die Rückwärtsarbeit: den Task Flow am fertigen Entwurf entlangzeichnen statt an der Aufgabe. Dann bestätigen Sie nur, was ohnehin da ist.

25:38 Der zweite ist subtil und weit verbreitet — Annahmen nur dort markieren, wo man ohnehin etwas ändern wollte. Das macht die Übung zu einer Begründungssuche für schon getroffene Entscheidungen. Und der dritte betrifft den Steckbrief: Wunschziele hineinschreiben statt beobachteter Bedingungen. „Die Nutzer nehmen sich Zeit" ist kein Kontext, das ist eine Hoffnung.

25:59 Kontext ist, was tatsächlich der Fall ist, auch wenn es unbequem ist. Vier Punkte für die Mitnahme. Die vier Tätigkeiten der Norm sind eine Schleife und kein einmaliger Durchlauf — wer nur einmal dreht, hat den Prozess nicht angewendet. Der Nutzungskontext ist kein Beiwerk, er begründet Zielgrößen und Kontraste und beendet damit Geschmacksdebatten.

26:21 Quantitativ sagt wo, qualitativ warum; einzeln führt beides zuverlässig in die Irre. Und der Leitsatz: Eine aufgeschriebene Hypothese ist widerlegbar, eine Annahme nur verteidigbar. Das Material, das Sie hier erheben, ist die Grundlage für das nächste Modul — dort lassen wir künstliche Intelligenz damit arbeiten. Wohlgemerkt: damit.

26:41 Ohne echte Erhebung clustert sie nur unsere eigenen Vermutungen.