Alle Methoden der Checkliste für den Designprozess und wann sie sich lohnen.

Auf dieser Seite

1. Das Wichtigste
2. So lesen Sie diesen Leitfaden
3. Welche fünf Phasen hat der Designprozess?
4. Empathie: Was tun Menschen wirklich?
5. Definieren: Was genau ist das Problem?
6. Ideen entwickeln: Wie kommen Sie von vielen Ideen zu einer?
7. Prototyp: Wie viel bauen Sie, bevor Sie es wissen?
8. Testen: Woran erkennen Sie, ob es funktioniert?
9. Welche Vorlagen gehören zu welcher Phase?
10. Häufige Fragen
11. Quellen

2023 habe ich Wfrah gestaltet, eine App für Schaf- und Ziegenzüchter am Golf. Bevor es einen einzigen Screen gab, erklärte uns der Gründer Abdullatif, womit wir es zu tun hatten. Züchter führen ihr Geschäft so, wie ihre Väter es sie gelehrt haben, und sie glauben nicht, dass eine App ihre Tiere besser kennt als sie selbst.

Also haben wir zugehört. Zehn ausführliche Interviews mit Züchtern unterschiedlicher Erfahrung, dazu Zeit, in der wir beobachteten, mit welchen Werkzeugen sie bereits arbeiteten. Fragen Sie einen Züchter, warum der Betrieb Verlust macht, und Sie hören jedes Mal dasselbe: Futter ist teuer, und die Käufer zahlen zu wenig.

Die Interviews zeigten, was darunter lag. Viele Züchter konnten den täglichen Nährstoffbedarf ihrer Herde nicht aus den Formeln berechnen, und der Glaube, der Markt sei schuld, ließ sie Ernährung und Management übersehen. Das Nützlichste an der App wurde ein Nährstoffrechner, der für jedes Tier und jede Wachstumsphase rechnet. Danach hatte niemand gefragt. Die Interviews zeigten, wie viele ihn brauchten.

Drei Jahre später baute ich den Kassenbildschirm für Dot, meine Loyalty-App, und die erste Version war schlecht. Sie fragte zuerst nach dem Betrag, dann nach einem Land, dann nach der Telefonnummer, dann kam ein Button: sechs Taps plus Tippen, und beim Öffnen war kein Feld aktiv. Der Neubau begann bei der Person, in einem Satz in die Spezifikation geschrieben: ein müder Kassierer an einer vollen Theke, eine Hand am Telefon, die andere am Becher. Die Telefonnummer kommt zuerst, das Betragsfeld erhält den Fokus von selbst, und ein Stammkunde kostet jetzt zwei Taps.

Zweimal dieselbe Lektion. Der Screen wurde erst richtig, nachdem der Mensch an erster Stelle stand. Dafür ist ein Designprozess da, und deshalb gibt es Listen wie die Design-Process-Checkliste von Barbara Vam. Ihre umfasst 64 Methoden in den fünf Phasen des Design Thinking. Dieser Leitfaden geht jede einzelne durch, in ihrer Reihenfolge, mit dem, was ich beim Einsatz gelernt habe.

Das Wichtigste

• Design Thinking hat fünf Phasen: Empathie, Definieren, Ideen entwickeln, Prototyp, Testen. Der Prozess läuft in Schleifen. Ein gescheiterter Test führt meist zurück zum Definieren, nicht an den Anfang.
• Kein Projekt nutzt alle 64 Methoden. In jeder Phase tragen ein bis zwei den Rest. Lassen Sie diese aus, raten Sie nur.
• Empathie: Befragen Sie Menschen zum letzten Mal, als sie die Aufgabe erledigt haben, und sortieren Sie ihre Aussagen mit einer Affinitätskarte.
• Definieren: ein Problemstatement und eine Reihe von „Wie könnten wir“-Fragen, geschrieben, bevor jemand Figma öffnet.
• Ideen entwickeln: Zeichnen Sie den User Flow vor den Screens und streichen Sie Ideen dann mit einer Priorisierungsmatrix zusammen.
• Prototyp: Bauen Sie das Wenigste, das die offene Frage beantwortet. Übergeben Sie Zustände, nicht nur Screens.
• Testen: Beobachten Sie fünf Personen bei der Nutzung. Messen Sie mit SUS. A/B-Tests lohnen sich nur mit genug Traffic.
• KI hilft beim Entwerfen, Sortieren und Prüfen. Den Menschen, für den Sie gestalten, ersetzt sie nicht.

So lesen Sie diesen Leitfaden

Lesen Sie zuerst die fünf Kapitelanfänge: wofür die jeweilige Phase da ist und was kaputtgeht, wenn ein Team sie überspringt. Danach nutzen Sie die Methoden als Nachschlagewerk. Jede sagt, was sie ist, wann sie ihre Zeit wert ist, wie Sie sie durchführen, was Sie daraus mitnehmen und welcher Fehler am häufigsten vorkommt. Wo eine Methode gut mit KI funktioniert, zeigt ein kurzer Absatz, wie Sie mit Claude vorgehen und was Sie prüfen.

Die kostenlosen Vorlagen unterwegs teilen sich ein durchgängiges Beispiel: Bunn, eine fiktive Kaffee-App, und Rana, eine Produktdesignerin in Amman, die Kaffee für ihr Team bestellt.

Inhalt

1. Welche fünf Phasen hat der Designprozess?
2. Empathie: Was tun Menschen wirklich?
3. Definieren: Was genau ist das Problem?
4. Ideen entwickeln: Wie kommen Sie von vielen Ideen zu einer?
5. Prototyp: Wie viel bauen Sie, bevor Sie es wissen?
6. Testen: Woran erkennen Sie, ob es funktioniert?
7. Welche Vorlagen gehören zu welcher Phase?
8. Häufige Fragen

Welche fünf Phasen hat der Designprozess?

Die Interaction Design Foundation beschreibt Design Thinking als nicht linearen, iterativen Prozess, mit dem Teams Nutzer verstehen, Annahmen hinterfragen, Probleme neu fassen und Lösungen schaffen. Fünf Phasen, jede beantwortet eine Frage.

Ein Test, der an der Wortwahl scheitert, schickt Sie zurück zum Prototyp. Einer, der scheitert, weil niemand das Ding will, schickt Sie zurück zum Definieren.

Empathie: Was tun Menschen wirklich?

In der Empathie-Phase hören Sie auf zu raten: Wer sind die Menschen, was tun sie heute, was kostet sie das, und welche Worte benutzen sie dafür? Eine falsche Annahme, die hier auffällt, kostet ein Gespräch. Fällt sie erst nach dem Launch auf, kostet sie den Build.

Teams überspringen die Phase, weil sie glauben, sie wüssten es bereits. Bei Wfrah waren die Züchter selbst sicher, der Markt sei das Problem, und die Interviews zeigten trotzdem, was ihnen fehlte. Wird die Empathie-Phase übersprungen, steckt in der ersten Version die Meinung des Teams, und die zweite Version geht dafür drauf, das herauszufinden.

Das Ziel definieren

Ein Satz dazu, was das Projekt verändern muss und woran Sie merken, dass es gelungen ist. „Wiederkehrende Kunden sammeln Punkte in unter zehn Sekunden“ ist ein Ziel. „Die Kassenerfahrung verbessern“ ist ein Wunsch. Formulieren Sie es mit der Person, die für das Ergebnis verantwortlich ist, mit der einen Zahl, die es belegen würde, und vor jeder Recherche. Sie nehmen einen Filter mit: Jede Methode danach dient dem Ziel oder wartet. Der Fehler ist ein Ziel, das eine Lösung nennt, etwa „eine Loyalty-App bauen“. Der Design Sprint von GV ist ein Fünf-Tage-Prozess, um Geschäftsfragen durch Gestaltung, Prototyping und Tests zu beantworten, und er beginnt genauso: Das Team einigt sich auf ein langfristiges Ziel, bevor jemand skizziert.

Nutzerinterviews

Ein Nutzerinterview ist eine Person, ein Gespräch, darüber, was sie getan hat, in ihren Worten. Die Nielsen Norman Group definiert es in User Interviews 101 so: Sie stellen Fragen, hören zu und haken nach, um zu erfahren, wer die Nutzer sind, wie ihre Erfahrungen aussehen und was sie brauchen. Sie nennt auch die Grenze: Die Daten sind nur so gut wie der Interviewer, und Suggestivfragen ruinieren sie.

Es lohnt sich immer dann, wenn Sie nicht erklären können, warum Menschen sich so verhalten. Um zu erfahren, wie viele es tun, nutzen Sie eine Umfrage.

So gehen Sie vor

1. Schreiben Sie zuerst die Forschungsfrage: „Wie entscheiden Züchter, was sie füttern?“ Jede Frage im Skript muss ihr dienen.
2. Rekrutieren Sie fünf bis acht Personen aus der echten Zielgruppe. Keine Kollegen, keine Freunde, die nett sein werden.
3. Fragen Sie nach dem letzten Mal, nie nach der Zukunft. „Erzählen Sie mir vom letzten Mal, als Sie Kaffee für das Team bestellt haben“ liefert eine Geschichte. „Würden Sie eine Gruppenbestellung nutzen?“ liefert ein höfliches Ja.
4. Folgen Sie jeder Antwort mit Warum, Wie und Was geschah dann. Barbara Vams eigene Notiz zu dieser Methode sagt es in drei Wörtern: was, wie, warum.
5. Schweigen Sie nach jeder Antwort. Der nützliche Teil kommt nach der Pause.
6. Schreiben Sie Zitate wortwörtlich auf. Beim Paraphrasieren schleicht sich Ihre Meinung ein.

Was Sie mitnehmen: Geschichten, genaue Zitate, das Vokabular der Menschen und die Behelfslösungen, die sie gebaut haben, weil nichts sie bediente.

Der häufige Fehler: Pitchen. Sobald Sie die Idee zeigen, wird das Interview zum Verkaufsgespräch, und die Leute beginnen, Ihre Gefühle zu schonen.

Das kostenlose Interviewskript mit Notizen enthält 18 Fragen in fünf Abschnitten, vom Aufwärmen bis zu „Gibt es etwas, das ich hätte fragen sollen und nicht gefragt habe?“.

Mit Claude. Fügen Sie Ihre Forschungsfrage ein und bitten Sie: „Schreibe ein 30-minütiges Interviewskript über das letzte Mal, als diese Person die Aufgabe erledigt hat. Keine hypothetischen Fragen, keine Fragen, die eine Funktion nennen, und markiere jede Frage, die ihre eigene Antwort nahelegt.“ Streichen Sie danach jede „Würden Sie“-Frage, die trotzdem durchgerutscht ist. Lassen Sie ein Modell nie den Nutzer spielen; es liefert Ihnen den Durchschnitt dessen, was es gelesen hat.

Stakeholder-Interviews

Dasselbe Gespräch, geführt mit den Menschen, denen Budget, System oder Risiko gehören. Die Nielsen Norman Group argumentiert in Stakeholder Interviews 101, dass sie Kontext und Geschäftsziele liefern und die Unterstützung der Stakeholder für die Arbeit erhöhen.

Führen Sie sie zuerst, bevor das Briefing sich verhärtet. Fragen Sie, wie Erfolg aussieht, was früher gescheitert ist und wovor sie Angst haben. Bei Wfrah nannte der Gründer das eigentliche Hindernis, bevor wir einen einzigen Züchter getroffen hatten: das Misstrauen gegenüber Technologie. Sie nehmen die Rahmenbedingungen mit, die niemand aufgeschrieben hat. Der Fehler ist, die ranghöchste Stimme als Nutzerforschung zu behandeln.

Lean Canvas

Eine Seite, die das Problem, die Kundensegmente, die Lösung, den einzigartigen Wert, die Kanäle, den Umsatz, die Kosten, die Schlüsselmetriken und den unfairen Vorteil benennt. Barbara Vam beschreibt es als Weg, den Problemraum zu dokumentieren und als Katalysator für Hypothesen zu dienen, die es zu validieren gilt.

Nutzen Sie es, solange das Produkt noch eine Wette ist; bei einem Redesign eines Produkts, das bereits Geld verdient, lassen Sie es weg. Sie nehmen die riskanteste Annahme mit, benannt, und die sollte die Forschung zuerst testen. Markieren Sie die Felder, die Vermutungen sind. Das sind die nützlichen.

Umfragen

Feste Fragen an viele Menschen. Nutzen Sie sie, um zu messen, wie verbreitet etwas ist, nachdem Interviews Ihnen gesagt haben, was es ist. Führen Sie zuerst die Interviews, sonst schreiben Sie die Antwortoptionen aus dem Kopf und messen Ihre eigenen Annahmen sehr präzise.

Halten Sie sie unter zehn Fragen und testen Sie sie an zwei Personen. Sie nehmen Zahlen und ein paar Begründungen mit. Die 28 Tipps für qualitative Umfragen der Nielsen Norman Group sprechen sich für offene Fragen aus, wenn Sie mehr erfahren wollen, und dafür, jede Umfrage vor dem Versand zu testen, um die Probleme zu beseitigen.

Datenanalyse

Lesen, was bereits existiert: Support-Tickets, Verkaufsdaten, Suchprotokolle, App-Bewertungen, alte Studien. Das kostet am wenigsten und kommt deshalb vor allem Neuen. Sie nehmen mit, wo Sie hinschauen sollten, und die ersten Fragen für Ihre Interviews.

Für Taken apart, Nummer zwei haben wir der Reihe nach 179 finanzierte MENA-Startups geprüft und festgestellt, dass 44 Prozent keine arabische Website hatten. Kein Interview hätte diese Zahl geliefert; ein sorgfältiger Durchgang durch öffentliche Daten tat es. Der Fehler ist, bei der Zahl stehen zu bleiben. Daten sagen, wo Menschen abspringen. Warum, sagen sie nie.

Metriken

Die wenigen Zahlen, die zeigen, ob die Erfahrung besser wird: Aufgabenerfolg, Zeit pro Aufgabe, Conversion, Bindung, Zufriedenheit. Wählen Sie sie zu Beginn, halten Sie den heutigen Wert fest, und Sie haben eine Baseline, an der Sie den Launch messen. Der Benchmarking-Leitfaden der Nielsen Norman Group beschreibt genau das: die Erfahrung eines Produkts mit Metriken an einem sinnvollen Maßstab zu messen.

Am Dot-Counter war das Maß in der Spezifikation die Zahl der Taps pro wiederkehrendem Kunden: sechs vorher, zwei nachher. Wählen Sie Zahlen, die das Ergebnis des Nutzers abbilden, so wie Niemand will Ihr Produkt es vertritt. Eine Metrik, die nur Klicks zählt, belohnt das falsche Design.

Wettbewerber

Nutzen Sie die Produkte, auf die sich Ihre Nutzer heute verlassen, auch die Tabelle, das Notizbuch und die WhatsApp-Gruppe. Ein Nachmittag, früh im Projekt, mit Notizen dazu, was jedes gut macht und wo es scheitert. Die Nielsen Norman Group begründet wettbewerbsbezogene Usability-Bewertungen damit, dass Sie vor nutzlosen Funktionen bewahrt werden, wenn Sie sehen, was anderswo funktioniert und was nicht.

Sie nehmen die Muster mit, die Nutzer bereits erwarten, und die Lücken, die niemand schließt. Der Fehler ist, nur direkte Wettbewerber anzuschauen. Der wahre Wettbewerber eines Züchters ist das Notizbuch seines Vaters.

Fokusgruppen

Sechs bis neun Personen diskutieren etwa zwei Stunden lang mit einem Moderator über ein Thema. Jakob Nielsens Artikel über Fokusgruppen ist deutlich, was die Grenze angeht: Sie zeigen, was Menschen sagen, dass sie tun, nicht was sie tun, und ihre eigentliche Aufgabe ist es, herauszufinden, was Nutzer wollen, nicht die Usability zu beurteilen.

Nutzen Sie sie für Einstellungen, Vokabular und Gruppendynamik. Nutzen Sie nie eine, um ein Design zu beurteilen. Die lauteste Person im Raum bestimmt die Antwort, und die anderen stimmen zu.

Beobachtungen

Sehen Sie Menschen bei der Aufgabe zu, dort, wo sie sie normalerweise erledigen: an der Theke, im Pferch, auf dem eigenen Handy bei schlechtem Licht. Setzen Sie es ein, wann immer die Umgebung die Arbeit prägt. Der Artikel der Nielsen Norman Group über Feldstudien plädiert dafür, das Büro zu verlassen, um Unerwartetes zu lernen.

Bei Wfrah wurden Farbe und Schrift auf grelle Sonne und wenig Licht abgestimmt, denn Züchter öffnen die App im Pferch. Sie nehmen die Behelfslösungen mit, die Menschen nicht mehr bemerken und deshalb nie erwähnen. Der Fehler ist, zu helfen. Ihre Aufgabe ist es, dem Kampf zuzusehen.

Affinitätskarten

Eine Affinitätskarte nimmt alles, was die Forschung hervorgebracht hat, ein Befund pro Notiz, und gruppiert die Notizen nach Zusammengehörigem, bis Themen sichtbar werden. Der Leitfaden zum Affinity Diagramming der Nielsen Norman Group beschreibt sie als Bündelung verwandter Beobachtungen zu Themen und sagt, sie funktioniere für Forschungsbefunde ebenso wie für Ideen aus einem Workshop. Sie grenzt sie außerdem vom Card Sorting ab, das eine Forschungsmethode für Navigation ist und kein Weg, die eigenen Notizen zu sortieren.

Machen Sie es direkt nach der Forschung. Ohne sie gewinnt das einprägsamste Interview die Diskussion, und das einprägsamste ist meist das extremste.

So gehen Sie vor

1. Schreiben Sie pro Notiz eine Beobachtung, möglichst in den Worten des Teilnehmers, markiert mit dem Namen des Sprechers.
2. Breiten Sie alle Notizen aus. Beginnen Sie nicht mit Kategorien.
3. Schieben Sie die Notizen schweigend zu Gruppen. Schweigen verhindert, dass die ranghöchste Person die Themen laut vorgibt.
4. Benennen Sie jede Gruppe mit einem Satz, der den Befund ausdrückt, etwa „Die Liefergebühr taucht spät auf und fühlt sich wie ein Trick an“, statt mit einem Ein-Wort-Etikett wie „Preise“.
5. Zählen Sie die Teilnehmer unter jedem Thema. Ein Thema von einer einzigen Person ist eine Anekdote.

Was Sie mitnehmen: fünf oder sechs Themen, jedes von mehreren Menschen getragen.

Der häufige Fehler: Interpretationen auf die Notizen zu schreiben. „Nutzer wollen Transparenz“ ist Ihre Schlussfolgerung. „Die Gebühr erscheint an der Kasse, nachdem ich alles ausgewählt habe“ sind Daten.

Die kostenlose Affinitätskarte gibt es auf Arabisch und Englisch, hell und dunkel.

Mit Claude. Fügen Sie die Transkripte ein und bitten Sie: „Extrahiere jede Beobachtung als eine Zeile mit der Teilnehmer-ID und einem exakten Zitat. Schlage dann Gruppen vor. Fasse nichts, was nur ein Teilnehmer gesagt hat, zu einem Thema zusammen.“ Prüfen Sie danach, ob jede Notiz auf ein echtes Zitat zurückgeht und kein Thema etwas ist, das niemand gesagt hat. Sortieren können Modelle gut. Lücken mit plausiblen Befunden zu füllen ist das, was Sie abfangen müssen.

Kontextkartierung

Die Teilnehmer bereiten sich vor der Sitzung mit kleinen Übungen vor: ein Tagebuch, Fotos ihres Tages, eine Collage. Dann erklären sie Ihnen, was sie gemacht haben. Die Seite der Interaction Design Foundation zur Kontextkartierung stellt sie als Weg vor, Nutzerbedürfnisse offenzulegen und Designideen anzuregen.

Nutzen Sie sie für das, was Menschen schwer aussprechen können: Routinen, Gefühle, das Umfeld einer Aufgabe. Sie nehmen das Leben rund um die Aufgabe mit. Lassen Sie die Nachbesprechung nie aus; die Fotos bedeuten wenig, bis die Person sie erklärt.

Definieren: Was genau ist das Problem?

Das Definieren macht aus einer Wand von Befunden eine einzige Entscheidung: welches Problem, für wen und warum jetzt. Es ist die schmalste Phase und die, die Teams am meisten überstürzen, weil alle gern zeichnen wollen. Ein Team, das sie überspringt, liefert ein Produkt aus, das mehrere kleine Probleme nur halb löst.

Bei Wfrah ergab das Definieren eine Persona, Awad, und ein Problemstatement: Traditionelle Züchter zögern, neue Werkzeuge einzusetzen, selbst wenn der Gewinn real ist, und kämpfen zugleich mit Ernährung, Umgebung und Verwaltung. Jeder Screen danach musste sich Vertrauen verdienen, bevor er etwas verlangte. Ein Satz leistete diese Arbeit.

Personas

Eine Persona ist ein fiktives, realistisches Profil eines Nutzertyps, aufgebaut aus Forschung: Ziele, Kontext, Verhalten, Frustrationen und ein Satz in den eigenen Worten. Der Personas-Artikel der Nielsen Norman Group argumentiert, dass sie wirken, weil ein konkreter Mensch Menschen mehr fesselt als eine Spanne von Zahlen, und dass eine gute auf konkreter Forschung beruht.

Sie lohnt sich, wenn das Team „der Nutzer“ sagt und jeder jemand anderen meint. Bevor jemand mit einem Nutzer gesprochen hat, ist sie Fiktion mit einem Stockfoto.

So gehen Sie vor

1. Beginnen Sie bei der Affinitätskarte. Jede Persona sollte ein Cluster von Verhalten sein, das Sie tatsächlich gesehen haben, keine Demografie.
2. Schreiben Sie Ziele und Frustrationen so, wie die Teilnehmer sie gesagt haben.
3. Ergänzen Sie den Kontext, der das Design verändert: Gerät, Ort, Zeitdruck, Sprache.
4. Wählen Sie ein Zitat, das die Spannung trägt. Awad sagt, Technologie wirke zu kompliziert, und er probiere gern Neues aus, wenn es hilft. Diese Spannung war das Briefing.
5. Machen Sie eine Hauptpersona. Höchstens zwei. Fünf Personas bedeuten, dass keine Entscheidung gefallen ist.

Was Sie mitnehmen: einen Menschen, für den Sie gestalten, und einen Test für jede Review: Würde Awad diesen Screen verstehen?

Der häufige Fehler: die Persona einer Vorlage zu übernehmen. Eine aus einer englischen Vorlage übersetzte Persona hält fest, was der englische Autor erwartet hat. Die arabische Fassung der kostenlosen Persona-Vorlage wurde deshalb auf Arabisch geschrieben, mit einer Kurzbiografie, die klingt wie jemand aus Amman.

Mit Claude. Geben Sie ihm die Affinitätskarte und bitten Sie: „Entwirf eine Persona, die nur Fakten aus diesen Notizen verwendet. Markiere jede Zeile mit den Teilnehmer-IDs, aus denen sie stammt. Lasse ein Feld leer, wenn die Notizen es nicht stützen.“ Löschen Sie alles ohne ID. Ein Modell gibt Ihrer Persona bereitwillig ein Hobby und einen Hund.

Empathy Map

Vier Quadranten: was der Nutzer sagt, denkt, tut und fühlt. Füllen Sie sie als Team direkt nach den Interviews aus. Der Artikel zur Empathy Map der Nielsen Norman Group argumentiert, sie schaffe ein gemeinsames Bild des Nutzers und zeige die Lücken in dem, was Sie wissen. Das nützlichste Ergebnis liegt dort, wo Sagen und Tun aufeinandertreffen: Rana nennt die späte Gebühr einen Trick, und sie prüft sie zweimal, bevor sie zahlt. Kostenlose Empathy-Map-Vorlage. Der Fehler ist, „denkt“ und „fühlt“ mit Vermutungen zu füllen; lassen Sie sie leer, wo Sie keine Belege haben.

User Journey Map

Eine Journey Map ist die gesamte Erfahrung über die Zeit, vom ersten Hören vom Produkt bis zum Abschied oder zur Rückkehr, mit dem, was die Person in jeder Phase tut, denkt und fühlt. Journey Mapping 101 der Nielsen Norman Group definiert sie als Visualisierung des Prozesses, den eine Person durchläuft, um ein Ziel zu erreichen, aufgebaut aus einer Zeitachse von Handlungen, ergänzt um Gedanken und Emotionen.

Nutzen Sie sie, wenn das Problem Kanäle oder Teams überschreitet: ein Reel, eine App, ein Kurier, eine Benachrichtigung. Lassen Sie sie weg, wenn das Problem in einem einzigen Screen liegt.

So gehen Sie vor

1. Wählen Sie eine Persona und ein Ziel. Eine Journey für alle ist eine Journey für niemanden.
2. Legen Sie die Phasen so an, wie der Nutzer sie benennt, nicht wie Ihr Organigramm.
3. Füllen Sie Handlungen und Touchpoints aus der Forschung, dann die Gedanken in Zitaten.
4. Tragen Sie die Emotion Phase für Phase ein. Der tiefste Punkt ist der Ort, an dem Sie anfangen.
5. Ergänzen Sie pro Phase eine Chance und eine Metrik, damit die Map in Arbeit mündet.

Was Sie mitnehmen: den Moment, der am meisten schmerzt. Bei Bunn ist der Tiefpunkt der Bestellschritt: Der OTP kommt spät, und das Feld liest ihn nicht.

Der häufige Fehler: die Journey abzubilden, die Sie entworfen haben, statt der, die Menschen gehen. Kostenlose Customer Journey Map, auf Arabisch und Englisch, hell und dunkel.

User Stories

„Als [Nutzer] möchte ich [Handlung], damit [Ergebnis].“ Schreiben Sie sie, wenn Arbeit ins Backlog wandert, damit jeder Eintrag Nutzer und Grund behält. Der Leitfaden zum Schreiben von User Stories im GOV.UK Service Manual versteht sie als Aufzeichnung von allem, was ein Team tun muss, um einen Service zu bauen, der die Bedürfnisse der Nutzer erfüllt. Der Fehler sind Stories ohne „damit“. Ohne es kann niemand sagen, ob die Funktion gewirkt hat.

Problemstatement

Ein Problemstatement sagt in einem Satz, wer feststeckt, in welchem Moment und was es ihn kostet. Der Artikel zu Problemstatements der Nielsen Norman Group argumentiert, dass Teams, die ohne eines in die Discovery starten, herumirren und dass manche damit beginnen, Lösungen zu untersuchen, was mit Discovery nichts zu tun hat. Schreiben Sie in jedem Projekt eines. Es ist die billigste Versicherung in diesem Leitfaden.

So gehen Sie vor

1. Füllen Sie fünf Lücken aus der Forschung: Nutzer, braucht, weil, aber, wodurch er sich fühlt.
2. Lesen Sie den Satz laut. Klingt er wie ein Feature-Wunsch, fehlt das „weil“.
3. Prüfen Sie ihn gegen die Affinitätskarte. Jeder Teil sollte auf ein Thema zurückgehen.
4. Einigen Sie sich mit den Menschen, die bauen werden. Können sie ihn nicht wiederholen, ist er zu lang.

Was Sie mitnehmen: den Umfang. „Rana muss Kaffee für drei Personen in unter einer Minute bestellen, weil das Meeting um 10:00 pünktlich beginnt, aber die Liefergebühr erscheint erst an der Kasse, wodurch sie sich getäuscht fühlt.“ Alles, was diesem Satz nicht dient, wartet.

Der häufige Fehler: eine Lösung darin zu verstecken. „Nutzer brauchen ein besseres Dashboard“ nennt die Antwort und überspringt das Problem. Kostenlose Problemstatement-Vorlage.

Mit Claude. Fügen Sie die Themen der Affinitätskarte ein und bitten Sie um drei Kandidaten für Problemstatements im Fünf-Lücken-Format, jeder mit Angabe des Themas, aus dem er stammt. Wählen Sie dann selbst einen aus. Optionen zu entwerfen ist die Aufgabe des Modells. Das Problem zu wählen ist Ihre.

Hypothesenstatement

„Wir glauben, dass [Änderung] für [Nutzer] [Ergebnis] erreicht. Wir wissen es, wenn [Signal].“ Nutzen Sie es, wenn bereits eine Lösung auf dem Tisch liegt und getestet statt verteidigt werden muss. Schreiben Sie die Bestehensbedingung, bevor das Ergebnis vorliegt, damit niemand die Torpfosten verschiebt. Für den Dot-Counter würde es lauten: Wir glauben, dass die Telefonnummer an erster Stelle einen wiederkehrenden Kunden auf zwei Taps bringt, und wir wissen es, wenn ein Kassierer das am ausgelieferten Screen schafft.

Narrative

Eine kurze Geschichte in Prosa über den Tag einer Person, in dem das Produkt vorkommt. Nutzen Sie sie, um einem Stakeholder zu zeigen, wo das Produkt in eine echte Routine eintritt. Halten Sie sie an die Forschung gebunden. Der Artikel der Nielsen Norman Group über Narrative Biases warnt, dass UX-Praktiker erzählerischen Details und Ursache-Wirkung-Erklärungen zu sehr vertrauen. Eine gute Geschichte überzeugt, ob sie stimmt oder nicht, deshalb sollte jeder Satz auf etwas zurückgehen, das ein Nutzer getan hat.

HMW-Methode

„Wie könnten wir“ formuliert jedes Problem als Frage, die offen genug für mehrere Antworten und eng genug zum Handeln ist. Der Artikel zu „Wie könnten wir“-Fragen der Nielsen Norman Group argumentiert, das Format halte Menschen davon ab, Lieblingslösungen durchzudrücken, die mit den gefundenen Problemen wenig zu tun haben, und halte die Ideenfindung beim richtigen Problem.

Nutzen Sie es am Ende des Definierens, als Brücke in die Ideenfindung. Solange kein Problemstatement existiert, formuliert es nur Vermutungen als Fragen.

So gehen Sie vor

1. Nehmen Sie das Problemstatement und jedes starke Thema der Affinitätskarte.
2. Schreiben Sie pro Schmerz eine Frage: „Wie könnten wir die Liefergebühr zeigen, bevor Rana ein Getränk wählt?“
3. Prüfen Sie die Breite. „Wie könnten wir Kaffee besser machen?“ ist zu weit. „Wie könnten wir ein Gebührenlabel in den Header setzen?“ ist eine verkleidete Lösung.
4. Schreiben Sie unter jede Frage eine Zeile dazu, was sie öffnet, ohne ein Feature zu nennen.
5. Stimmen Sie über drei ab, die in die Ideenfindung gehen.

Was Sie mitnehmen: Briefings für die Ideenfindung, jedes auf einen echten Schmerz gerichtet. Der häufige Fehler sind zu viele. Zwanzig HMWs sind ein Backlog, kein Briefing. Die kostenlose Problemstatement-Vorlage enthält sechs. Mit Claude lassen Sie Ihre Liste so umschreiben, dass keine eine Lösung nennt und keine weiter ist als ein einzelner Moment der Journey; prüfen Sie dann, ob es das Problem nicht stillschweigend verändert hat.

Annahmen-Mapping

Listen Sie alles auf, was wahr sein muss, damit die Idee funktioniert, und ordnen Sie jeden Punkt auf zwei Achsen ein: wie wichtig er ist und wie viele Belege Sie haben. Führen Sie es durch, bevor Sie etwas Teures bauen. Die Ecke oben links, wichtig und unbelegt, ist die eine Annahme, die Sie zuerst testen. Bei einem Produkt wie Wfrah ist die riskanteste Annahme, dass Züchter einer Zahl aus einer App überhaupt vertrauen. Die Forschung sagte, das Vertrauen sei gering, deshalb zeigt die App Nutzen und Geschichten anderer Züchter, bevor sie etwas verlangt.

Aufgabenanalyse

Zerlegen Sie ein Ziel in jeden Schritt und jede Entscheidung, die ein Nutzer bis dahin trifft, einschließlich der Schritte außerhalb Ihres Produkts. Der Artikel zur Aufgabenanalyse der Nielsen Norman Group nennt sie die systematische Untersuchung, wie Nutzer Aufgaben erledigen, um ihre Ziele zu erreichen. Nutzen Sie sie für komplexe oder Expertenarbeit. Sie nehmen Schritte mit, die Sie streichen, zusammenlegen oder automatisieren. Der Tempo-Durchgang am Dot-Counter war eine Aufgabenanalyse in der Praxis: Jeder Tap wurde gezählt, und der Tap, der den Fokus von der Telefonnummer zum Betrag verschiebt, entfiel, weil das Feld automatisch weiterspringt, sobald die Nummer vollständig ist.

Jobs to be done

Jobs to be done beschreibt den Fortschritt, den eine Person in einer Situation machen will, welches Produkt sie auch dafür nutzt. Menschen „engagieren“ ein Produkt für eine Aufgabe und „kündigen“ es, wenn es nicht liefert. Ich habe darüber in Niemand will Ihr Produkt geschrieben, mit Christensens Milchshake-Geschichte: Neue Sorten brachten nichts, bis die Kette erfuhr, dass der Shake für einen langen, öden Arbeitsweg engagiert wurde.

Nutzen Sie es, wenn die Demografie nichts darüber sagt, wer kauft. Die Gegenüberstellung Personas vs. Jobs to be done der Nielsen Norman Group liefert den nützlichen Einwand: Jobs richten sich auf Bedürfnisse und Ergebnisse, schaffen aber nicht die Empathie, die eine gute Persona schafft, und beide arbeiten zusammen.

So gehen Sie vor

1. Finden Sie in den Interviews den Moment, in dem die Person beschließt zu handeln.
2. Schreiben Sie die Aufgabe in drei Zeilen: Wenn ich, will ich, damit ich.
3. Nutzen Sie die Worte der Person. „Wenn ich um 9:40 Bunn öffne und zwei Bestellungen quer über den Schreibtisch gerufen werden“ ist ein Job. „Wenn ich die Bestellfunktion nutze“ ist eine Produktbeschreibung.
4. Listen Sie auf, wen oder was sie heute für diese Aufgabe engagieren. Diese Liste ist Ihre Konkurrenz.

Was Sie mitnehmen: einen Job, der ein Redesign überlebt, und eine Wettbewerberliste, die die WhatsApp-Gruppe enthält.

Der häufige Fehler: den Job in der falschen Höhe zu schreiben. „Kaffee trinken“ ist zu hoch, um dafür zu gestalten; „Wiederbestellen tippen“ ist zu niedrig, um daraus zu lernen.

Wettbewerbsanalyse

Die strukturierte Fassung der Wettbewerberprüfung: Funktion für Funktion und Flow für Flow, gemessen an dem Problem, das Sie gerade definiert haben. Barbara Vams Notiz verweist auf die vielen Formen, von der visuellen Analyse bis zur SWOT. Führen Sie sie durch, sobald das Problem klar ist, damit Sie die richtigen Dinge vergleichen. Sie nehmen mit, wo Sie dem Markt folgen und wo Sie sich unterscheiden. Mit Claude geben Sie ihm Ihr Problemstatement und Screenshots von drei Wettbewerber-Flows und bitten um eine Tabelle, wie jeder diesen einen Moment löst; prüfen Sie jede Zelle gegen die Screenshots, denn Modelle beschreiben Funktionen, die Produkte nicht haben.

Ideen entwickeln: Wie kommen Sie von vielen Ideen zu einer?

Das Ideenentwickeln ist die breiteste Phase mit 19 Methoden, und sie hat zwei Hälften, die Teams zu trennen vergessen: erst in die Breite gehen, dann streichen. Die Checkliste kennt viele Wege, Ideen zu erzeugen, und keinen, sie auszuwählen. Deshalb füge ich am Ende einen hinzu.

Wer die breite Hälfte überspringt, baut die erste Idee des Teams, und die ist meist die naheliegende. Wer das Streichen überspringt, liefert zwölf halbfertige Funktionen aus.

Brainstorming-Sitzungen

Eine Gruppe erzeugt so viele Ideen wie möglich und hält das Urteil zurück. Die Brainstorming-Seite der Interaction Design Foundation beschreibt es als Weg, Ideen für ein klar definiertes Problem zu erzeugen; das „klar definiert“ leistet dabei die Arbeit. Bringen Sie die HMW-Fragen mit. Lassen Sie alle fünf Minuten allein schreiben, bevor jemand spricht, damit die lauteste Stimme die Richtung nicht vorgibt. Sie nehmen Menge mit. Der Fehler ist, Ideen schon während der Sitzung zu diskutieren.

Mindmaps

Ein Thema in der Mitte, verwandte Ideen verzweigen sich davon. Nutzen Sie sie allein oder zu zweit, um ein Feld schnell abzudecken. Die Mindmap-Seite der Interaction Design Foundation versteht sie als Weg, Ideen und die Verbindungen zwischen ihnen sichtbar zu machen. Sie nehmen Verbindungen mit, die Ihnen in einer Liste entgehen würden, und manchmal einen ersten Entwurf der Navigation.

Storyboards

Ein paar Comic-Bilder, in denen ein Nutzer dem Problem begegnet und dann der Lösung. Zeichnen Sie sie vor den Screens, um zu prüfen, ob die Idee eine reale Situation übersteht, etwa einen Züchter im Pferch mit schmutzigen Händen. Der Storyboard-Artikel der Nielsen Norman Group argumentiert, sie binden Aufmerksamkeit und schaffen Klarheit. Sie nehmen eine Geschichte mit, die ein Stakeholder in einer Minute versteht. Strichmännchen genügen.

Card Sorting

Beim Card Sorting gruppieren Teilnehmer Ihre Inhalte in Kategorien, die für sie Sinn ergeben. Beim offenen Sortieren benennen sie die Kategorien auch selbst. Der Card-Sorting-Artikel der Nielsen Norman Group sagt, es decke die mentalen Modelle der Nutzer zu Ihrer Informationsarchitektur auf, und nennt die Zahlen: mindestens 15 Teilnehmer für ein qualitatives Sortieren, 30 bis 50 für ein quantitatives. Er warnt auch, dass die Bezeichnungen, die Teilnehmer erfinden, selten Ihre endgültigen sind, und empfiehlt Tree-Tests statt geschlossener Sortierungen, um Navigation zu prüfen.

Führen Sie es durch, bevor Sie die Navigation für alles mit mehr als einem Dutzend Einträgen gestalten.

So gehen Sie vor

1. Schreiben Sie 30 bis 60 Karten, je ein Inhalt, in einfachen Worten. Vermeiden Sie die Bezeichnungen, die Sie verwenden wollen, sonst testen Sie nur diese.
2. Führen Sie ein offenes Sortieren durch: Die Teilnehmer gruppieren die Karten und benennen jede Gruppe. Bitten Sie sie, laut zu denken.
3. Achten Sie auf Karten, die bei den meisten Teilnehmern zusammenlanden, und auf die, die überall landen. Das sind Ihre härtesten Benennungsprobleme.
4. Entwerfen Sie die Struktur und prüfen Sie sie dann mit einem Tree-Test.

Was Sie mitnehmen: Gruppierungen, die Nutzer erwarten, und die Inhalte, die verwirren werden, egal wohin Sie sie legen.

Der häufige Fehler: die Karten selbst zu sortieren. Das mentale Modell des Teams hat die verwirrende Navigation überhaupt erst gebaut.

User Journey

Der Hauptweg, den ein Nutzer in Ihrem Produkt zu einem Ziel nimmt, auf höherer Ebene als ein Flow. User Journeys vs. User Flows der Nielsen Norman Group erklärt, dass beide Prozesse beschreiben, die Nutzer zu einem Ziel durchlaufen, sich aber in Umfang, Zweck und Format unterscheiden. Bei Wfrah begleitete die Journey Awad von der Entdeckung über den Zweifel bis zu einem Test und einer Entscheidung und setzte Belege genau dorthin, wo er zögern würde. Nutzen Sie sie, um sich vor den Details auf die Hauptrouten zu einigen.

User Flow

Ein User Flow ist jeder Screen, jede Entscheidung und jede Verzweigung, die ein Nutzer für eine Aufgabe durchläuft, gezeichnet als Kästchen und Pfeile. Er zeigt die Sackgassen und Fehlerpfade, die Screens verbergen. Ein Screen zeigt immer nur den Idealweg. Die meisten schlechten Produkte sind ein guter Screen in einem schlechten Flow.

Der Dot-Counter ist der klarste Fall, den ich kenne. Der Flow der ersten Version lautete: Betrag, Länderauswahl, Land, Telefon, erzeugen. Jedes Kästchen ergab für sich Sinn. Als Flow gezeichnet, ist der Preis offensichtlich: Eine Telefontastatur hat keine Weiter-Taste, also ist jeder Wechsel zwischen Feldern ein Tap. Der Tempo-Durchgang zeichnete ihn neu als Telefon, Betrag, Punkte hinzufügen, und die Screens folgten.

Zeichnen Sie ihn vor den Screens, für jede Aufgabe mit einer Entscheidung darin.

So gehen Sie vor

1. Wählen Sie eine Aufgabe und eine Persona. Schreiben Sie Start und Ende auf.
2. Zeichnen Sie den Idealweg in Kästchen, ein Screen oder Schritt pro Kästchen.
3. Fragen Sie bei jedem Schritt, was passiert, wenn er scheitert: falsche Eingabe, keine Verbindung, nicht angemeldet, leeres Ergebnis. Jede Antwort ist ein Zweig.
4. Markieren Sie Entscheidungen als Rauten mit Ja und Nein. Jedes Nein braucht ein Ziel.
5. Zählen Sie die Schritte auf dem Hauptpfad. Versuchen Sie dann, einen zu entfernen.

Was Sie mitnehmen: die vollständige Liste der Screens und Zustände. Sie ist immer länger als die erste Schätzung.

Der häufige Fehler: nur den Idealweg zu zeichnen, den einen Pfad, der kein Design braucht. Kostenlose User-Flow-Vorlage mit gezeichneten Ja- und Nein-Pfaden.

Mit Claude. Beschreiben Sie die Aufgabe, fügen Sie Ihren Idealweg ein und bitten Sie: „Liste für jeden Schritt jeden Fehlerzustand auf: ungültige Eingabe, Timeout, offline, doppelter Tap, Berechtigung verweigert, leere Daten. Sage für jeden, was der Nutzer sieht und wohin er danach kommt.“ Prüfen Sie, dass jeder Zustand das Feld und die Lösung nennt, wie es der Dot-Counter tut: „Nichts hinzugefügt. Telefonnummer um 1 zu kurz.“

Informationsarchitektur

Informationsarchitektur ist die Art, wie Inhalte organisiert, benannt und verbunden werden. IA vs. Navigation der Nielsen Norman Group zieht die Linie klar: Die IA ist das Informationsgerüst, dokumentiert in Tabellen und Diagrammen, und die Navigation ist der Teil der Oberfläche, über den Menschen es erreichen.

Bei Wfrah umfasste die IA Herden, den Nährstoffrechner, Umweltrichtlinien, den Markt, eine Wissensdatenbank und das Konto, mit Progressive Disclosure, damit ein neuer Züchter das Wesentliche sieht und ein Experte tiefer gehen kann. Bei Zain Cash setzte der arabischzentrierte Information Scent die Hinweise dorthin, wo ein Leser von rechts nach links sie erwartet.

So gehen Sie vor

1. Inventarisieren Sie jeden Inhalt und jede Aufgabe.
2. Gruppieren Sie sie nach dem Card Sort, nicht nach Ihrem Organigramm.
3. Benennen Sie jede Gruppe mit den Worten, die Nutzer in den Interviews verwendet haben.
4. Entscheiden Sie die Tiefe: was einen Tap entfernt ist, was dahinter liegt.
5. Testen Sie die Struktur vor jedem visuellen Design mit einem Tree-Test.

Was Sie mitnehmen: eine Struktur, die die Navigation zeigen kann, und Worte, die der Text verwenden kann. Der häufige Fehler ist, nach Abteilungen zu strukturieren.

Sitemap

Ein Diagramm aller Seiten und ihrer Verschachtelung. Nutzen Sie es, um eine Website oder App einzugrenzen, verwaiste Seiten zu finden und zu zählen. Die Seitenzahl ist der Anfang der Aufwandsschätzung. Aktualisieren Sie es mit jedem Release.

Service Blueprints

Eine Journey Map, die unter die Oberfläche verlängert wird: was Mitarbeiter, Systeme und Partner hinter jedem Schritt tun, den der Nutzer sieht. Die Definition von Service Blueprints der Nielsen Norman Group stellt sie als Weg vor, die organisatorischen Prozesse hinter einer Erfahrung sichtbar zu machen. Nutzen Sie eines, wenn das Produkt vom Betrieb abhängt: Lieferung, Support, eine Theke. Am Dot-Counter wirken Kassierer, Betrugsprüfungen und das Hauptbuch auf einen einzigen Tap. Sie nehmen den Fehler hinter der Bühne mit, der der Beschwerde auf der Bühne zugrunde liegt.

Business Model Canvas

Neun Blöcke auf einer Seite: Kunden, Wert, Kanäle, Beziehungen, Umsatz, Ressourcen, Aktivitäten, Partner, Kosten. Strategyzer veröffentlicht das Canvas als kostenlose Vorlage. Nutzen Sie es, wenn eine Designentscheidung verändert, wie das Unternehmen Geld verdient, etwa ein kostenloser Tarif oder eine Partnergebühr. Sie nehmen jede Designentscheidung mit, verknüpft mit dem Block, den sie verschiebt.

Worst Idea

Das Team schlägt absichtlich schreckliche Lösungen vor und dreht dann jede um. Die Worst Possible Idea der Interaction Design Foundation beschreibt die umgekehrte Suche als Weg, das Team zu lockern. Nutzen Sie sie, wenn eine Sitzung stockt oder Menschen Angst haben, sich zu blamieren. „Die Gebühr bis nach der Zahlung verstecken“ kippt zu „die Gebühr vor der Anmeldung zeigen“.

Crazy 8

Falten Sie ein Blatt zu acht Feldern und skizzieren Sie acht Ideen in acht Minuten, eine Minute pro Idee. Das Design Sprint Kit von Google ordnet es der Skizzenphase eines Sprints zu. Das Zeitlimit ist die Methode: In einer Minute kann niemand polieren, also hängt niemand an seiner Idee.

Führen Sie es direkt nach der HMW-Abstimmung durch, bevor jemand ein Designwerkzeug öffnet. Ohne eine konkrete Frage sind acht Skizzen von „der App“ acht Logos.

So gehen Sie vor

1. Nehmen Sie eine HMW-Frage und einen Screen oder Moment.
2. Falten Sie ein A4-Blatt dreimal, sodass acht Felder entstehen.
3. Stellen Sie einen Timer auf acht Minuten. Eine Idee pro Feld. Stille.
4. Jede Person stellt ihr Blatt in zwei Minuten vor. Noch keine Kritik.
5. Alle vergeben Klebepunkte auf die Felder, die sie bauen würden, dann entscheidet der Entscheider.

Was Sie mitnehmen: acht grobe Optionen pro Person.

Der häufige Fehler: Felder auslassen zu lassen. Die naheliegende Idee ist etwa bei der fünften Skizze aufgebraucht, und dann beginnen die nützlichen.

Annahmen hinterfragen

Listen Sie auf, was alle über das Problem für selbstverständlich halten, und fragen Sie dann, was sich ändert, wenn jede Überzeugung falsch ist. Barbara Vams Notiz beschreibt es so, dass man umdreht, was das Team über das Problem glaubt, um es frisch zu sehen. Der erste Dot-Counter nahm als selbstverständlich hin, dass der Betrag zuerst kommt. Diese Reihenfolge in Frage zu stellen, machte zwei Taps möglich. Nutzen Sie es, wenn jede Idee gleich ausfällt.

Skizzieren und Sketch-Storming

Grobe Zeichnungen auf Papier, schnell und wegwerfbar, allein oder in Zeitrunden mit dem Team. Die Seite der Interaction Design Foundation zu Skizzen beschreibt sie als vorläufige, handgezeichnete Darstellungen von Forschungsergebnissen, Oberflächen und Interaktionen. Tun Sie es vor jedem Designwerkzeug, denn ein Werkzeug lässt alles fertig aussehen.

Produktdesign-Prinzipien

Ein paar Aussagen, die wiederkehrende Zielkonflikte entscheiden. Der Artikel zu Designprinzipien der Nielsen Norman Group nennt sie Wertaussagen, die Entscheidungen rahmen und über Teams hinweg konsistent halten. Wfrah hatte fünf: rücksichtsvoll, befähigend, vertrauenswürdig, effizient, vertraut. „Effizient“ hieß, Schritte zu entfernen und Reibung nur vor Entscheidungen einzubauen, die zählen. Schreiben Sie sie auf, sobald das Team immer wieder denselben Streit führt. Ein Prinzip, mit dem niemand eine Idee ablehnen kann, ist Dekoration.

Moodboard

Bilder, Schrift, Farbe und Textur, gesammelt, um eine visuelle Richtung zu setzen. Der Mood-Boards-Artikel der Nielsen Norman Group versteht sie als Weg, Inspiration zu sammeln und die visuelle Richtung zu bestimmen. Schöpfen Sie von außerhalb Ihrer Kategorie. Als wir 150 shadcn/ui-Repos gelesen haben, liefen die meisten mit einer von zwei Schriften und einem grauen Primärton. Ein Moodboard, das nur aus Ihren Wettbewerbern besteht, ergibt dasselbe Produkt.

Style Tiles

Ein Board mit angewandten Schriften, Farben und Oberflächenelementen, ohne Layout. Samantha Warrens Style Tiles führten sie als Schritt zwischen Moodboard und vollständigem Mock-up ein. Zeigen Sie zwei oder drei, nie eines; eine einzelne Kachel ist eine Ja-Nein-Frage.

Style Guidelines

Die schriftlichen Regeln für Schrift, Farbe, Abstände, Bildsprache und Tonalität. Schreiben Sie den Grund neben jede Regel, damit der nächste Designer sie erweitern kann, statt sie zu brechen. Eine Regel wie kein reines Schwarz im Dark Mode hält länger, wenn sie sagt, warum: Es belastet die Augen und flacht die Tiefe ab.

Design-System

Der Styleguide, überführt in gemeinsame Komponenten, Tokens und Dokumentation, die Design und Code beide nutzen. Design Systems 101 der Nielsen Norman Group definiert es als Satz von Standards, um Design im großen Maßstab zu steuern, Redundanz zu senken und eine gemeinsame Sprache zu schaffen. Das GOV.UK Design System ist ein öffentliches, das sich zu lesen lohnt. Es rechnet sich, sobald mehr als ein Team oder Produkt auf derselben Oberfläche aufbaut.

Das ist die Idee hinter ux-skill: ein Design-System, das aus dem Briefing kompiliert wird, statt einer Vorlage, die über alles gelegt wird. Warum, habe ich in Markenvorgaben sind Trainingsdaten erklärt. Der Dot-Counter läuft auf dem Dot-Design-System, und die Mockups des Tempo-Durchgangs erfanden auf Token-Ebene nichts: Jeder Wert stammte aus der Token-Datei, und alles, was dem System fehlte, wurde als Ergänzung aufgelistet. Sie nehmen Screens mit, die zusammengesetzt statt neu gezeichnet sind. Der Fehler ist, Komponenten zu bauen, bevor sich Muster wiederholen; ein zu früh gebautes System kodiert Ihre ersten Vermutungen. Das Design-System-Skill-Kit bringt Claude Code Ihre Tokens bei.

Priorisierungsmatrix

Nicht auf der ursprünglichen Checkliste, und die, die ich jedes Mal hinzufüge. Tragen Sie jede Idee nach Wirkung auf den Nutzer und Aufwand fürs Team ein. Die Ecke oben links, hohe Wirkung bei geringem Aufwand, wird zuerst ausgeliefert. Die Matrix zwingt das Team, laut zu sagen, warum der Rest wartet. Bewerten Sie die Wirkung anhand der Forschung, nie anhand von Begeisterung.

Kostenlose Priorisierungsmatrix.

Prototyp: Wie viel bauen Sie, bevor Sie es wissen?

Ein Prototyp ist eine Frage in einer Form, die Menschen anfassen können. Der Leitfaden der Nielsen Norman Group zu Prototypen mit niedriger und hoher Detailtreue nennt ihn eine Hypothese, eine Lösungskandidatin, die Sie testen, indem Sie Menschen bei der Nutzung zusehen, und fügt den Satz hinzu, den jedes Team an die Wand hängen sollte: Code wegzuwerfen ist sehr teuer, einen Prototyp wegzuwerfen nicht.

Die Regel lautet: Bauen Sie das Wenigste, das die offene Frage beantwortet. Eine Frage zur Wortwahl braucht Papier. Eine Frage zu einer Geste oder zum Tempo braucht Code. Detailtreue ist ein Kostenfaktor; geben Sie sie nur dort aus, wo der Test sie braucht.

Was schiefgeht, wenn Teams diese Phase überspringen: Der erste Prototyp ist das Produkt, und der erste Usability-Test findet nach dem Launch statt, mit echten Kunden.

Papierprototyp

Auf Papier gezeichnete Screens, die von Hand getauscht werden, während ein Nutzer mit dem Finger tippt. Der Artikel zu Paper Prototyping der Nielsen Norman Group argumentiert, damit ließen sich frühe Ideen zu sehr geringen Kosten testen und Usability-Probleme beheben, bevor Sie für etwas zahlen, das nicht funktioniert. Nutzen Sie ihn für den frühesten Test von Flow und Wortwahl. Menschen kritisieren Papier freimütig, weil es offensichtlich nichts gekostet hat. Sie nehmen Probleme mit, die gefunden wurden, bevor jemand ein Designwerkzeug öffnete.

Mikrointeraktionen

Die kleinen Momente der Rückmeldung: ein Schalter, Pull-to-Refresh, eine Fehlermeldung, die unter ihrem Feld erscheint. Der Artikel zu Mikrointeraktionen der Nielsen Norman Group sagt, sie zeigen den Systemstatus, helfen Fehler zu vermeiden und tragen die Marke, jede ausgelöst durch einen Trigger und für einen einzigen Zweck gebaut. Gestalten Sie sie, sobald der Flow funktioniert. Am Dot-Counter ist die wichtigste Mikrointeraktion unsichtbar: der Fokus, der von der Telefonnummer zum Betrag springt, sobald die letzte Ziffer landet. Die Spezifikation des Tempo-Durchgangs entfernte außerdem ein Fade-up von 600 Millisekunden, das bei jedem Besuch lief. Bewegung, die eine volle Theke verlangsamt, ist kein Feinschliff.

Detaillierte User Flows

Der Flow aus der Ideenphase, ergänzt um jeden Zustand: leer, lädt, Fehler, Erfolg, offline, Randfälle. Die Wireflows der Nielsen Norman Group verbinden Wireframes und Flussdiagramme genau dafür. Die Spezifikation des Dot-Tempo-Durchgangs listet acht Zustände für einen Screen auf, vom Leerlauf über die Betrugssperre bis offline, und sagt für jeden, was der Kassierer sieht, wohin der Fokus geht und was der Button tut. Zeichnen Sie sie vor der hohen Detailtreue. Sie nehmen die vollständige Liste der Screens mit, meist länger als die erste Schätzung.

Mock-ups

Statische, realistische Screens mit echtem Inhalt und visuellem Design, nichts klickbar. Nutzen Sie sie, um das Aussehen zu prüfen und die Textlänge in beiden Sprachen festzulegen, denn arabische und englische Zeilen brechen selten an derselben Stelle um. Sie nehmen die Freigabe für die Optik mit. Das Verhalten braucht weiterhin einen Prototyp; ein Mock-up, das als „das Design“ abgenommen wird, verbirgt jeden Zustand, den es nicht zeigt.

Interaktiver Prototyp

Verlinkte Screens, durch die ein Nutzer klicken oder tippen kann, nah genug am Original, dass Menschen vergessen, dass es unecht ist. Der Leitfaden des GOV.UK Service Manual zum Erstellen von Prototypen versteht Prototypen als Weg, Designideen mit Nutzern auszuprobieren, während man einen Service baut.

Nutzen Sie ihn, wenn die offene Frage Navigation, Reihenfolge oder Verhalten betrifft. Ob überhaupt jemand das Ding will, beantwortet ein Interview billiger.

So gehen Sie vor

1. Schreiben Sie die Frage auf, die der Prototyp beantworten muss. „Kann Rana eine Gruppenbestellung ohne Hilfe starten?“ ist eine Frage. „Funktioniert die App?“ nicht.
2. Bauen Sie nur die Screens auf dem getesteten Pfad, plus die Fehlerzustände, auf die Menschen stoßen werden.
3. Nutzen Sie echten Inhalt: echte Preise, echte Namen, echtes Arabisch. Lorem ipsum verbirgt jedes Layoutproblem.
4. Führen Sie ihn, wo möglich, auf dem eigenen Handy des Teilnehmers aus. Ein Prototyp auf dem großen Monitor eines Designers testet den Monitor.
5. Beheben Sie offensichtliche Probleme zwischen den Sitzungen.

Was Sie mitnehmen: Belege über Verhalten und eine Liste von Korrekturen, geordnet danach, wie viele Menschen sie aufgehalten haben.

Der häufige Fehler: alles zu prototypen. Ein Prototyp mit 60 Screens dauert so lange, dass das Team zu sehr an ihm hängt, um ihn zu ändern.

Wireframes

Wireframes sind Layouts mit niedriger Detailtreue: Struktur, Hierarchie und Inhalt, ohne visuellen Stil. Die Wireframing-Seite der Interaction Design Foundation beschreibt sie als grundlegende Darstellungen von Struktur und Layout einer Oberfläche. Ihr Wert liegt in dem, was sie weglassen. Ohne Farbe bleibt als einziger Streitpunkt, was wohin gehört und was am wichtigsten ist. Nutzen Sie sie für jeden Screen, dessen Hierarchie nicht offensichtlich ist.

So gehen Sie vor

1. Beginnen Sie beim detaillierten Flow. Ein Wireframe pro Screen und pro wichtigem Zustand.
2. Ordnen Sie den Inhalt nach Wichtigkeit für die Aufgabe. Am Dot-Counter: Telefon, Kunde, Betrag, dann der Button.
3. Markieren Sie die eine primäre Aktion pro Screen. Können Sie sich nicht für eine entscheiden, hat der Screen zwei Aufgaben.
4. Prüfen Sie die Reichweite. Der Hauptbutton des Dot-Counters sitzt in der Daumenzone, direkt über der Tastatur, und das ist das Fitts’sche Gesetz bei der Arbeit: das Wichtige größer und näher.
5. Ist das Produkt arabisch, zeichnen Sie jetzt die Version von rechts nach links. Spätes Spiegeln zerstört Layouts.

Was Sie mitnehmen: ein vereinbartes Gerüst für jeden Screen, bevor jemand über Farbe streitet.

Der häufige Fehler: Wireframes, die so poliert sind, dass Menschen sie als fertiges Design prüfen.

High-Fidelity-Designs

Das finale visuelle Design mit echtem Text, echten Daten und jedem Zustand. Erstellen Sie sie für die Screens, die ausgeliefert werden. Jeder Wert sollte aus den Tokens des Design-Systems stammen, damit die Entwicklung Regeln baut statt Pixel zu messen. Sie nehmen mit, was die Entwicklung baut. Der Fehler ist, nur den Erfolgszustand in hoher Detailtreue zu gestalten und Fehler als Notizen stehen zu lassen.

Übergabe

Eine Übergabe ist alles, was ein Entwickler braucht, um das Design ohne Raten zu bauen: Screens in Flow-Reihenfolge, die Verbindungen dazwischen, jeder Zustand, die Tokens und das Verhalten. Die ausführliche Fassung habe ich in Design-Übergabe geschrieben, und ihre Regel gilt auch hier: Die Übergabe ist ein Arbeitsergebnis, kein Export, und der Entwickler ist der wichtigste Nutzer Ihrer Datei.

Planen Sie sie ab dem ersten Screen, in jedem Projekt, das an die Entwicklung geht.

So gehen Sie vor

1. Ordnen und benennen Sie Screens nach Flow: „Kasse, ungültiges Telefon“, nicht „Screen 12 final v3“.
2. Übergeben Sie jeden Zustand mit derselben Sorgfalt wie den Idealweg. Die Dot-Spezifikation hat eine Tabelle: Zustand, was der Kassierer sieht, wohin der Fokus geht, was der Button sagt.
3. Schreiben Sie die Textregeln, nicht nur den Text. Bei Dot beginnt jede Fehlerzeile mit der Wahrheit aus dem Hauptbuch, „Nichts hinzugefügt.“, denn die erste Frage eines Kassierers nach einem Fehler ist, ob es durchgegangen ist.
4. Schreiben Sie die Regeln auf, die nicht sichtbar sind: Bei einem Fehler nie löschen, was der Kassierer getippt hat; nach 30 Sekunden in den Leerlauf zurückkehren, damit der nächste Kunde nicht das Guthaben des vorigen sieht.
5. Bleiben Sie während des Builds erreichbar und prüfen Sie den Staging-Link.

Was Sie mitnehmen: weniger Fragen mitten im Sprint.

Der häufige Fehler: Bilder zu übergeben. Ein Screen zeigt, was zu bauen ist, nie, wie es sich verhält.

Mit Claude. Fügen Sie Ihren detaillierten Flow ein und bitten Sie: „Schreibe für jeden Screen und Zustand die Übergabezeile: was der Nutzer sieht, wohin der Fokus geht, was jeder Button tut, was bei Timeout und bei doppeltem Tap passiert. Markiere jeden Zustand, den der Flow nicht definiert.“ Die Lücken, die es markiert, sind die Fragen, die ein Entwickler Ihnen am dritten Tag gestellt hätte.

Designdokumentation

Die Aufzeichnung des Warum: Entscheidungen, verworfene Optionen und die Forschung dahinter. Halten Sie sie kurz und schreiben Sie sie laufend. Die Spezifikation des Dot-Counters erklärt in einem Absatz, warum das Telefon zuerst kommt: iOS-Zahlentastaturen haben keine Weiter-Taste, und nur ein Feld bekannter Länge kann von selbst weiterspringen. Sechs Monate später muss niemand raten.

HTML/JS-Prototypen

Ein Prototyp, der im echten Medium programmiert ist. Nutzen Sie einen, wenn die Frage von echten Daten, Tempo, Animation, einer Tastatur oder einer Geste abhängt, die ein Designwerkzeug nicht vortäuschen kann. Automatisches Weiterspringen und Tastaturverhalten gibt es in einem statischen Frame nicht, deshalb ließ sich die Tap-Zahl bei Dot nur im Code belegen. Mit Claude Code und einem Design-System ist ein programmierter Prototyp oft schneller als ein klickbarer; der kostenlose Leitfaden zu Claude Code und Figma beschreibt die Einrichtung. Der Fehler ist, den Prototyp ohne die Tests auszuliefern.

Testen: Woran erkennen Sie, ob es funktioniert?

Im Test hört das Team auf, der Richter zu sein. Usability Testing 101 der Nielsen Norman Group sagt, selbst die besten Designer bekommen eine Oberfläche nicht richtig hin ohne iteratives Design, das davon getrieben ist, echten Nutzern zuzusehen.

Was schiefgeht, wenn Teams ihn überspringen: Sie finden die Probleme über Support-Tickets, ein verärgerter Kunde nach dem anderen, nachdem das Budget aufgebraucht ist.

Usability-Test

In einem Usability-Test gibt ein Moderator einem Teilnehmer eine realistische Aufgabe, sieht dann zu und bleibt still, während der Teilnehmer sie versucht.

Wie viele Personen? Nielsens Artikel Warum fünf Testnutzer reichen zeigt, dass die ersten fünf Nutzer etwa 85 Prozent der Usability-Probleme finden und dass es zwar mindestens 15 braucht, um alle zu finden, diese 15 aber besser auf drei Runden mit je fünf verteilt werden, mit Korrekturen am Design zwischen den Runden.

Führen Sie ihn in jeder Runde durch, vom Papier bis zum ausgelieferten Produkt. Fragen der Vorliebe beantwortet er nicht.

So gehen Sie vor

1. Schreiben Sie das Ziel, dann fünf Aufgaben als realistische Szenarien mit Erfolgsbedingung und Zeitlimit: „Sie sind im Büro und möchten einen Flat White. Finden Sie heraus, was die Lieferung kostet, bevor Sie etwas auswählen.“
2. Rekrutieren Sie fünf Personen, die zur Persona passen. Führen Sie zuerst eine Pilotsitzung durch, um kaputte Aufgaben zu finden.
3. Bitten Sie sie, laut zu denken. Helfen Sie nicht. Fragen sie „Was soll ich tun?“, antworten Sie „Was würden Sie tun, wenn ich nicht hier wäre?“
4. Markieren Sie jede Aufgabe als bestanden, teilweise oder nicht bestanden und notieren Sie die Zeit und das Zitat im Moment, in dem es schiefging.
5. Protokollieren Sie jeden Befund mit Schweregrad, Ort, Belegzitat und Korrektur. Kritische Befunde werden zuerst ausgeliefert.

Was Sie mitnehmen: wo Menschen steckenbleiben, warum, und das Zitat, das den Stakeholder überzeugt, der sicher war, dass alles in Ordnung ist.

Der häufige Fehler: mit Kollegen zu testen. Sie wissen, was der Button tun soll. Kostenlose Usability-Test-Vorlage mit Plan, Skript und Befundtabelle.

Mit Claude. Fügen Sie nach den Sitzungen Ihre Notizen ein und bitten Sie: „Gruppiere diese zu Befunden. Gib für jeden den Schweregrad an (kritisch blockiert die Aufgabe, ernst verlangsamt sie, gering stört), die betroffenen Teilnehmer und ein exaktes Zitat. Füge keinen Befund ohne Zitat hinzu.“ Legen Sie die Schweregrade dann selbst fest. Das Modell kann nicht wissen, welche Verzögerungen Geld kosten.

Shadowing

Folgen Sie einer Person durch einen echten Tag mit dem Produkt oder Service. Die Seite der Interaction Design Foundation zu Shadowing beschreibt es als lange etablierte Forschungstechnik, die erst seit Kurzem regelmäßig in der UX-Forschung eingesetzt wird. Nutzen Sie es für Arbeitswerkzeuge und Services, die sich über Stunden erstrecken, wie die Schicht eines Kassierers. Sie nehmen mit, wie das Produkt in die übrige Arbeit passt oder wo nicht. Vereinbaren Sie vorher, wann Sie Fragen stellen dürfen, damit Sie die Arbeit nicht unterbrechen, die Sie beobachten wollten.

A/B-Tests

Ein A/B-Test führt zwei Live-Versionen eines Designs aus, teilt echten Traffic zufällig auf und vergleicht eine Metrik. A/B Testing 101 der Nielsen Norman Group definiert ihn als quantitative Methode, um herauszufinden, welche Variante gegenüber einer vorab festgelegten Geschäftsmetrik am besten abschneidet, und sagt, die Variante solle sich idealerweise nur in einem Element vom Original unterscheiden.

Er lohnt sich, wenn Sie genug Traffic und ein messbares Ziel haben. Die nötige Stichprobengröße hängt von Ihrer Ausgangsrate und der kleinsten Änderung ab, die Sie erkennen wollen. Bei einem kleinen Produkt warten Sie also womöglich Monate auf eine Antwort, die ein Usability-Test in einer Woche liefert.

So gehen Sie vor

1. Beginnen Sie bei einer Hypothese, die in der Forschung gründet: „Die Gebühr im Menü-Header zu zeigen, erhöht die Rate von Menü zu Kasse.“
2. Ändern Sie eine Sache. Bei zwei Änderungen wissen Sie nicht, welche gewirkt hat.
3. Legen Sie Metrik und Stichprobengröße vor dem Start fest, und die Dauer gleich mit.
4. Beenden Sie den Test nicht vorzeitig, wenn die Linie gut aussieht. Frühe Blicke erzeugen falsche Gewinner.
5. Behalten Sie die Variante nur, wenn sie mit statistischer Signifikanz gewinnt.

Der häufige Fehler: den Gewinner als Erklärung zu behandeln. Ein A/B-Test sagt Ihnen, welche Version gewonnen hat. Ein Usability-Test sagt Ihnen, warum die andere verloren hat.

SUS-Test

Die System Usability Scale besteht aus zehn Aussagen mit je fünf Antwortmöglichkeiten, direkt nach einer Usability-Sitzung vorgelegt. Der SUS-Leitfaden von MeasuringU hält fest, dass John Brooke sie 1986 als „quick and dirty“-Skala veröffentlichte, dass sie seither an Hardware, Software, Websites und Telefonen getestet wurde und dass der Durchschnittswert über 500 Studien 68 beträgt.

Nutzen Sie sie, wenn Sie eine Zahl zum Vergleich zwischen Runden wollen. Sie sagt nicht, was falsch ist; das tut die Sitzung.

So gehen Sie vor

1. Verwenden Sie die zehn Standardaussagen unverändert. Übersetzen Sie sorgfältig, wenn Sie auf Arabisch testen, und behalten Sie die Reihenfolge.
2. Legen Sie sie nach den Aufgaben vor, vor jeder Diskussion.
3. Werten Sie aus: Ziehen Sie bei ungeraden Aussagen 1 von der Antwort ab, bei geraden Aussagen die Antwort von 5. Addieren Sie die zehn Ergebnisse und multiplizieren Sie mit 2,5. Die Summe reicht von 0 bis 100.
4. Vergleichen Sie mit 68 und mit Ihrer letzten Runde.

Der häufige Fehler: den Wert als Prozentzahl zu lesen. MeasuringU weist darauf hin, dass 68 der Durchschnitt ist, ein Wert von 70 also kaum darüber liegt und nicht „zu 70 Prozent benutzbar“ bedeutet.

Heuristische Evaluation

Bei einer heuristischen Evaluation prüfen einige Gutachter eine Oberfläche anhand von Prinzipien, meist anhand von Jakob Nielsens zehn Usability-Heuristiken, erstmals 1994 veröffentlicht. Der Leitfaden der Nielsen Norman Group dazu, wie man eine durchführt, sagt, sie finde offensichtliche Probleme gut, funktioniere an fast jeder Oberfläche einschließlich Prototypen und sei besonders früh nützlich.

Nutzen Sie sie als günstige Prüfung vor Tests mit Nutzern und für jeden Screen, den Sie geerbt haben. Experten finden, was Regeln verletzt. Nutzer finden, was ihren Tag verdirbt.

So gehen Sie vor

1. Legen Sie den Umfang fest: eine Persona, eine Aufgabe, ein Gerät.
2. Lassen Sie jeden Gutachter die Aufgabe allein durchgehen, wie ein Nutzer, und dann ein zweites Mal gegen jede Heuristik.
3. Halten Sie die Evaluationen getrennt, bis alle fertig sind, wie es der Leitfaden verlangt.
4. Führen Sie die Befunde zusammen, nennen Sie zu jedem die Heuristik und bewerten Sie den Schweregrad.
5. Beheben Sie die kritischen, testen Sie dann mit Nutzern.

Was Sie mitnehmen: eine Liste von Verstößen nach Schweregrad geordnet, zum Preis eines Nachmittags.

Der häufige Fehler: ein einzelner Gutachter. Getrennte Gutachter finden unterschiedliche Probleme. Mit Claude geben Sie ihm einen Screenshot und die zehn Heuristiken und bitten um Verstöße mit Heuristik, Element und Korrektur. Behandeln Sie das Ergebnis wie einen weiteren Gutachter. Es ist schwach bei allem, was den Flow rund um den Screen braucht.

Analytics

Verhaltensdaten aus dem Live-Produkt: wo Menschen abspringen, wonach sie suchen, welche Pfade sie nehmen. Lesen Sie sie laufend. Der Artikel zu Analytics in der UX der Nielsen Norman Group argumentiert, Analytics bringe den größten Nutzen, wenn es mit qualitativer Forschung verbunden wird, statt sie zu ersetzen. Analytics zeigt, wo das Problem liegt. Testen zeigt, was es ist.

Performance-Tests

Messen Sie, wie schnell das Produkt auf echten Geräten und echten Netzen lädt und reagiert. Der Artikel zu Antwortzeiten der Nielsen Norman Group nennt die drei Grenzen: 0,1 Sekunden fühlen sich sofortig an, 1 Sekunde erhält den Fluss des Nutzers, und 10 Sekunden sind die Grenze der Aufmerksamkeit. Das GOV.UK Service Manual hat einen praktischen Leitfaden zum Testen der Frontend-Performance. Tempo war eine von drei Ideen hinter dem Zain-Cash-Redesign, weil die meisten Besucher auf dem Handy sind. Die Spezifikation des Dot-Counters führt die Kundensuche aus, während der Kassierer den Betrag tippt, damit nichts auf das Netz wartet. Testen Sie auf einem Mittelklasse-Handy mit mobilen Daten, nicht im Glasfasernetz des Büros.

Beobachtung

Das ausgelieferte Produkt in echter Nutzung beobachten, in seinem echten Umfeld. Tun Sie es nach dem Launch, wenn sich das Verhalten zur Gewohnheit gesetzt hat. Die Contextual Inquiry der Nielsen Norman Group verbindet Beobachtung mit Befragung im Kontext, um aufzudecken, was andere Methoden übersehen. Sie nehmen die Lücke zwischen der gedachten und der tatsächlichen Nutzung mit. Ein Kassierer, der lernt, die Telefonnummer mit einem Daumen zu tippen, während er einen Becher hält, zeigt Ihnen, wo der nächste Tempo-Durchgang beginnt.

Desirability-Beobachtungen

Zeigen Sie das Design und bitten Sie Menschen, aus einer festen Wortliste die Wörter zu wählen, die es beschreiben, und jede Wahl zu erklären. Der Leitfaden der Nielsen Norman Group zum Microsoft Desirability Toolkit stellt es als Test mit kontrolliertem Vokabular für Einstellungen zu einem Design vor. Nutzen Sie es, um eine visuelle Richtung mit Belegen statt mit Geschmack zu testen. Sie nehmen mit, ob das Design so wirkt, wie die Marke es meint. Wollten Sie „ruhig“ und Menschen wählen „leer“, lag das Moodboard falsch, nicht die Nutzer.

Metriken

Die in der Empathie-Phase gewählten Zahlen, erneut gemessen. Prüfen Sie sie nach dem Launch und danach nach Plan. Der Leitfaden des GOV.UK Service Manual zum Messen von Erfolg behandelt Messen, Berichten und die Analytics dahinter. Sie nehmen mit, ob die Änderung gewirkt hat, gemessen an der Baseline. Eine Metrik, die sich ohne Baseline bewegt hat, ist eine Geschichte, kein Ergebnis.

Eye-Tracking

Hardware oder Webcam-Software zeichnet auf, wohin Menschen schauen und wie lange. Die Eye-Tracking-Seite der Interaction Design Foundation behandelt, wie es zur Untersuchung von Engagement und Usability eingesetzt wird. Nutzen Sie es für enge Fragen zur Aufmerksamkeit, etwa ob irgendjemand den Preis oder die Warnung sieht. Sie nehmen Heatmaps mit. Lesen Sie sie sorgfältig: Hinschauen ist nicht Verstehen, und ein langer Blick kann Verwirrung ebenso bedeuten wie Interesse.

Welche Vorlagen gehören zu welcher Phase?

Jede kostenlose Vorlage gibt es auf Arabisch und Englisch, hell und dunkel. Die arabischen Seiten sind auf Arabisch geschrieben und von rechts nach links gespiegelt. Forschung, die in der falschen Sprache beginnt, beginnt mit dem falschen Nutzer.

Die neun gibt es auch als ein kostenpflichtiges Paket, UX AI Kit Pro Max, mit Claude-Prompts, einem Moderationsleitfaden und einem zweiten durchgearbeiteten Beispiel für jede.

Häufige Fragen

Welche fünf Phasen hat der Designprozess?

Empathie, Definieren, Ideen entwickeln, Prototyp und Testen. Teams springen zwischen ihnen zurück; ein gescheiterter Test führt meist zurück zum Definieren, nicht an den Anfang.

Brauchen Sie jede Methode einer Checkliste für den Designprozess?

Nein. Wählen Sie pro Phase die ein oder zwei, die am meisten Raten beseitigen. Für die meisten Produkte sind das: Interviews und eine Affinitätskarte, ein Problemstatement und „Wie könnten wir“-Fragen, ein User Flow, ein kleiner Prototyp und ein Usability-Test.

Wie viele Nutzer brauchen Sie für einen Usability-Test?

Fünf pro Runde. Fünf Personen finden etwa 85 Prozent der Probleme. Führen Sie mehrere kleine Runden durch und korrigieren Sie das Design dazwischen.

Welche Designmethoden funktionieren ohne Budget?

Die meisten. Vorhandene Daten, fünf Interviews, eine Affinitätskarte an der Wand, ein Problemstatement, ein Papierprototyp und ein Usability-Test im Café kosten Zeit und kein Geld. Eye-Tracking, große Umfragen und A/B-Tests brauchen Werkzeuge oder Traffic.

Was ist der Unterschied zwischen einer User Journey und einem User Flow?

Eine Journey deckt die gesamte Erfahrung über Zeit und Kanäle ab, einschließlich der Teile außerhalb Ihres Produkts. Ein Flow deckt die Schritte im Produkt für eine Aufgabe ab, mit jeder Verzweigung. Kartieren Sie die Journey, um das Problem zu finden, und zeichnen Sie dann den Flow, um die Lösung zu gestalten.

Kann KI Nutzerforschung ersetzen?

Nein. Ein Modell entwirft Skripte, sortiert Transkripte und listet Fehlerzustände gut auf. Es kann Ihnen nicht sagen, was Awad in seinem Pferch tut oder warum Rana die Gebühr zweimal prüft. Bitten Sie es, Ihren Nutzer zu spielen, und Sie erhalten den Durchschnitt dessen, was es gelesen hat, also genau die Annahme, die Forschung testen soll.

Welche Methoden zählen am meisten für Vibe Coder, die mit KI bauen?

Die, die vor dem Prompt stattfinden. Ein Problemstatement und ein User Flow mit jedem Fehlerzustand geben dem Modell etwas Konkretes zum Bauen, und ein Usability-Test mit fünf Personen fängt ab, was es falsch gemacht hat. KI macht das Bauen billig, deshalb wandert der teure Fehler nach vorn: schnell das Falsche zu bauen.

Woher stammt Barbara Vams Checkliste?

Barbara Vam hat die Design-Process-Checkliste als Notion-Seite veröffentlicht, mit kurzen Notizen und Leselinks zu den meisten Methoden. Die Methodenliste und ihre Reihenfolge stammen von ihr. Die Erklärungen, die Geschichten und die Vorlagen hier sind meine.

Quellen

1. Design-Process-Checkliste coconut-baroness-035.notion.site
2. nicht linearen, iterativen Prozess interaction-design.org
3. Design Sprint gv.com
4. User Interviews 101 nngroup.com
5. Stakeholder Interviews 101 nngroup.com
6. 28 Tipps für qualitative Umfragen nngroup.com
7. Benchmarking-Leitfaden nngroup.com
8. wettbewerbsbezogene Usability-Bewertungen nngroup.com
9. Fokusgruppen nngroup.com
10. Feldstudien nngroup.com
11. Leitfaden zum Affinity Diagramming nngroup.com
12. Kontextkartierung ixdf.org
13. Personas-Artikel nngroup.com
14. Artikel zur Empathy Map nngroup.com
15. Journey Mapping 101 nngroup.com
16. Schreiben von User Stories gov.uk
17. Artikel zu Problemstatements nngroup.com
18. Narrative Biases nngroup.com
19. Artikel zu „Wie könnten wir“-Fragen nngroup.com
20. Artikel zur Aufgabenanalyse nngroup.com
21. Milchshake-Geschichte library.hbs.edu
22. Personas vs. Jobs to be done nngroup.com
23. Brainstorming-Seite ixdf.org
24. Mindmap-Seite ixdf.org
25. Storyboard-Artikel nngroup.com
26. Card-Sorting-Artikel nngroup.com
27. User Journeys vs. User Flows nngroup.com
28. IA vs. Navigation nngroup.com
29. Definition von Service Blueprints nngroup.com
30. Canvas strategyzer.com
31. Worst Possible Idea ixdf.org
32. Design Sprint Kit designsprintkit.withgoogle.com
33. Skizzen ixdf.org
34. Artikel zu Designprinzipien nngroup.com
35. Mood-Boards-Artikel nngroup.com
36. Style Tiles styletil.es
37. Design Systems 101 nngroup.com
38. GOV.UK Design System design-system.service.gov.uk
39. Prototypen mit niedriger und hoher Detailtreue nngroup.com
40. Artikel zu Paper Prototyping nngroup.com
41. Artikel zu Mikrointeraktionen nngroup.com
42. Wireflows nngroup.com
43. Erstellen von Prototypen gov.uk
44. Wireframing-Seite ixdf.org
45. Usability Testing 101 nngroup.com
46. Warum fünf Testnutzer reichen nngroup.com
47. Shadowing ixdf.org
48. A/B Testing 101 nngroup.com
49. SUS-Leitfaden measuringu.com
50. Jakob Nielsens zehn Usability-Heuristiken nngroup.com
51. wie man eine durchführt nngroup.com
52. Artikel zu Analytics in der UX nngroup.com
53. Artikel zu Antwortzeiten nngroup.com
54. Testen der Frontend-Performance gov.uk
55. Contextual Inquiry nngroup.com
56. Microsoft Desirability Toolkit nngroup.com
57. Messen von Erfolg gov.uk
58. Eye-Tracking-Seite ixdf.org