UX für Startups: wie viel in welcher Phase?

Kurz gesagt: UX nach Phase

In der frühen Phase besteht die eigentliche Aufgabe von UX darin, zu entscheiden, was Sie nicht bauen. Eine Papierskizze mit der richtigen Aufgabe lehrt mehr als zehn polierte Screens.

Die Tabelle unten fasst diesen Ratgeber zusammen. Jede Zeile beschreibe ich in einem eigenen Abschnitt.

Phase	Die eigentliche Frage	Die Aufgabe von UX
Idee	Gibt es das Problem wirklich?	Gespräche und Papierskizzen.
MVP	Funktioniert unsere Lösung?	Ein Ablauf, kleine Tests.
Erste Kunden	Warum hören sie auf?	Erste Sitzung und Support-Nachrichten.
Wachstum	Wie halten wir das Tempo?	Designsystem und regelmäßige Forschung.

Ideenphase: zuerst dem Problem zuhören

In dieser Phase müssen Sie keine Screens gestalten. Sprechen Sie mit Menschen, die das Problem haben. Statt ihnen Ihr Produkt zu erklären, fragen Sie, wie sie die Aufgabe heute lösen.

Paul Graham beschreibt in seinem Essay „Do Things that Don't Scale“ von 2013, dass die ersten Nutzer von Hand gewonnen werden müssen. Gründer warten nicht auf sie, sondern gehen los und finden sie. Diese Gespräche sind zugleich Ihre erste UX-Forschung.

Zeichnet sich eine Lösung ab, zeichnen Sie sie auf Papier. Laut Jakob Nielsens Artikel über Papierprototypen von 2003 bringen früh gesammelte Usability-Daten mindestens zehnmal so viel wie spät gesammelte. Nach der häufigsten Schätzung im selben Artikel ist eine Änderung vor dem ersten Code 100-mal günstiger.

Was fragt man im Gespräch?

Versuchen Sie im Gespräch nicht, Ihre Idee bestätigen zu lassen, sondern hören Sie, was die Person in der Vergangenheit getan hat. Auf die Frage „Würden Sie so eine App nutzen?“ sagt man aus Höflichkeit leicht ja, und diese Antwort lehrt Sie nichts.

Stellen Sie stattdessen konkrete Fragen zur Vergangenheit:

• Wann haben Sie diese Aufgabe zuletzt erledigt? Können Sie es Schritt für Schritt erzählen?
• Wo war es am schwierigsten? Was haben Sie in dem Moment getan?
• Welches Tool nutzen Sie heute dafür, und wie viel zahlen Sie?
• Haben Sie schon einmal etwas versucht, um das Problem zu lösen?

Schreiben Sie die Notizen am selben Tag und behalten Sie die Worte der Person bei. Diese Worte werden später Buttontexte und Menünamen.

Testen mit Papierskizzen

Legen Sie die Papierskizze ein paar Menschen vor und geben Sie eine Aufgabe, etwa „Wie würden Sie hier Ihre Rechnung bezahlen?“. Notieren Sie, wo sie tippen und wo sie stocken.

Die Papierskizze kommt vor den Stufen Wireframe, Mockup und Prototyp und ist günstiger als alle. Logo und detaillierte Screens können warten, weil beide die Frage „Gibt es das Problem wirklich?“ nicht beantworten.

MVP: ein Ablauf, kleine Tests

Die Antwort auf „Wo fängt MVP-Design an?“ ist der eine Kernablauf des Produkts. Dieser Ablauf ist die Aufgabe, für die der Nutzer das Produkt öffnet. Profilscreen oder Benachrichtigungseinstellungen können warten.

Eric Ries definiert das MVP in seinem Text von 2009 als die Version, mit der Sie mit dem geringsten Aufwand das meiste validierte Wissen über Kunden sammeln. Nach Ries heißt MVP nicht, ein kleines Produkt zu bauen. Das Ziel ist Lernen. Den Begriff selbst erkläre ich auf der Glossarseite zum MVP.

Ries warnt außerdem: Aus der ersten Version zu lernen, kostet oft Aufwand. Sie müssen ernsthaft Zeit für Gespräche mit Kunden oder für die Zahlen einplanen. Das MVP zu veröffentlichen und zu warten, reicht deshalb nicht.

Testen Sie den Ablauf vor dem Start. Laut Nielsens Artikel von 2000 finden fünf Nutzer etwa 85 % der Usability-Probleme eines Designs.

Nielsen empfiehlt statt eines großen Tests so viele kleine Tests, wie das Budget erlaubt. Sie beheben die Probleme und sehen im nächsten Test, ob die Korrektur funktioniert. Mit wie vielen Personen Sie wann testen, beschreibe ich im Ratgeber Mit wie vielen Nutzern testen.

Beispiel: Buchhaltungs-App für kleine Betriebe

Angenommen, Sie bauen eine Buchhaltungs-App für Handwerksbetriebe und Selbstständige. Sie haben viele Funktionen im Kopf: Ausgaben, Lager, Berichte, Bankanbindung. Alle wirken vernünftig.

Um den Kernablauf zu finden, stellen Sie eine einzige Frage: Warum öffnet der Nutzer die App? Die Antwort: um seinem Kunden eine Rechnung zu schreiben.

Das MVP lässt diesen Ablauf von Anfang bis Ende funktionieren. Der Nutzer wählt den Kunden, gibt die Positionen ein und verschickt die Rechnung. Alles andere kommt auf die Liste für die zweite Version.

Geben Sie im Test fünf Personen die Aufgabe „Schreiben Sie Ihrem Kunden eine Rechnung für die Arbeit von gestern“. Schauen Sie, wie viele fertig werden und wo sie stocken. Bleibt auch nur eine Person beim Umsatzsteuersatz hängen, korrigieren Sie das vor den Berichten.

Beginnen Sie im visuellen Design mit einer fertigen UI-Bibliothek. Ein eigenes Komponentenset zu zeichnen, ist in dieser Phase Zeitverschwendung. Testen Sie nicht die Farbe des Buttons, sondern seine Position.

Erste Kunden: herausfinden, warum sie aufhören

Das Produkt ist live, und Sie haben ein paar Kunden. Jetzt lautet die Frage: Warum hören manche Nutzer auf? Suchen Sie die Antwort zuerst in der ersten Sitzung.

Zählen Sie die Schritte, die ein neuer Nutzer von der Registrierung bis zum ersten Wert durchläuft. Bei welchem Schritt stocken die meisten? Onboarding-Screens und leere Zustände sind die eigentliche Arbeit dieser Phase.

Sammeln Sie Support-Nachrichten in einer Liste und gruppieren Sie sie nach Screen. Beschweren sich drei verschiedene Kunden über denselben Screen, gibt es dort sehr wahrscheinlich ein Designproblem. Eine der ersten Stellen, die Sie sich in dieser Liste ansehen, sind die Fehlermeldungen.

Graham erzählt im selben Essay, dass Wufoo neuen Nutzern handgeschriebene Dankeskarten schickte. Ein Vorteil des Kleinseins ist nach ihm, einen Service bieten zu können, den kein großes Unternehmen bieten kann.

Richten Sie auch selbst bei einigen Kunden das Produkt per Bildschirmfreigabe gemeinsam ein. So sehen Sie mit eigenen Augen, wo sie zögern.

Wählen Sie in dieser Phase eine einzige Zahl, die Sie beobachten. Zum Beispiel: Wie viele der Registrierten haben ihre erste Rechnung geschrieben? Vergleichen Sie diese Zahl vor und nach jeder Änderung.

Halten Sie Änderungen klein. Ändern Sie fünf Dinge gleichzeitig, können Sie nicht unterscheiden, welches gewirkt hat.

Ist Ihr Produkt ein SaaS, ist die Time to Value ein eigenes Thema. Das beschreibe ich im Ratgeber zur SaaS-UX.

Wachstum: Wiederkehrendes in ein System bringen

Wächst das Team, wird derselbe Button auf verschiedenen Screens verschieden gezeichnet. An diesem Punkt löst ein Designsystem ein echtes Problem. Ein früher gebautes System löst meist ein Problem, das es noch nicht gibt.

Legen Sie in dieser Phase auch die Forschung in den Kalender. Sprechen Sie etwa jeden Monat mit einigen Nutzern und lassen Sie in Abständen eine Expertenbewertung machen. Gründer können nicht mehr mit jedem Kunden sprechen, es braucht eine Ordnung, die das Wissen sammelt.

Machen Sie in dieser Phase auch die Barrierefreiheit zum Teil des Prozesses. Nachträglich eingebaute Barrierefreiheit heißt, fertige Screens wieder zu öffnen. Die Grundkriterien beschreibe ich im WCAG-Ratgeber.

Führen Sie im wachsenden Team auch ein Entscheidungsprotokoll: Warum wurde ein Screen so gestaltet, was kam bei welchem Test heraus? So stellen Neue nicht dieselbe Frage noch einmal. Und wenn Sie eine alte Entscheidung ändern, wissen Sie, was Sie dabei kaputt machen könnten.

Was kommt in Ihrer Lage zuerst?

Selbst in derselben Phase verschiebt die Zusammensetzung des Teams die Prioritäten. Ein Team mit Designerin startet anders als ein Team aus zwei Gründern. Wählen Sie unten Ihre Lage.

Phase wählen

Die Liste unten gilt für ein Team nur aus Gründern in der MVP-Phase. Die anderen Phasen beschreibt der Text in eigenen Abschnitten.

MVP · Nur Gründer

Zuerst diese drei Aufgaben

1. Wählen Sie den einen Kernablauf des Produkts. In der ersten Version funktioniert nur dieser Ablauf vollständig.
2. Testen Sie diesen Ablauf vor dem Start mit fünf Personen. Beheben Sie die Stelle, an der sie am häufigsten hängen bleiben.
3. Starten Sie mit einer fertigen UI-Bibliothek oder einer Vorlage. Zeichnen Sie keine eigenen Komponenten.

Kann warten

• Einstellungs- und Profilscreens
• Dark Mode
• Animationen
• Vollständiges Designsystem

Wählen Sie Phase und Team. Die Liste zeigt die drei UX-Aufgaben, die in dieser Lage zuerst kommen, und was vorerst warten kann. Das ist keine Regel, sondern mein Vorschlag für den Anfang.

Was Sie selbst tun können

Für die meisten UX-Aufgaben in der frühen Phase braucht es keine Designerin, sondern die Zeit und Aufmerksamkeit der Gründer. Das können Sie selbst:

• Mit Menschen sprechen, die das Problem haben, und die Notizen am selben Tag schreiben.
• Die Lösung auf Papier zeichnen und sie ein paar Menschen mit einer Aufgabe zeigen.
• Kleine Tests mit fünf Personen machen. Bitten Sie die Person, laut zu denken, und schauen Sie nur zu.
• Ihr eigenes Produkt Screen für Screen anhand von Nielsens 10 Heuristiken durchgehen.
• Support-Nachrichten nach Screen gruppieren.
• Button- und Fehlertexte mit den Worten der Nutzer neu schreiben.

Wie macht man einen Test mit fünf Personen?

1. Finden Sie fünf Personen aus der Zielgruppe Ihres Produkts. Keine Freunde, sonst sind sie zu nett.
2. Geben Sie jeder eine einzige realistische Aufgabe. Teilen Sie Ihren Bildschirm oder geben Sie der Person das Handy in die Hand.
3. Bitten Sie sie, laut zu denken. Helfen Sie nicht, machen Sie nur Notizen.
4. Wählen Sie nach fünf Sitzungen die zwei Probleme, die am häufigsten vorkamen, und beheben Sie sie.
5. Probieren Sie es in der nächsten Woche mit derselben Aufgabe noch einmal.

Eine Sitzung kann etwa eine halbe Stunde dauern. Wenn Sie aufzeichnen, fragen Sie die Person ausdrücklich um Erlaubnis.

Nielsen teilt den Ansatz der „Discount Usability“ 2009 in drei Teile: einfache Tests mit lautem Denken, Papierprototypen, die einen einzigen Weg unterstützen, und eine Prüfung anhand von Heuristiken. Sein Merksatz gilt auch für Gründer: „Bad user testing beats no user testing.“ Ein fehlerhafter Test ist besser als gar keiner.

Wenn Sie Ihre eigene Liste aufbauen möchten, ist die UX-Audit-Checkliste ein guter Anfang.

Wann lohnt sich externe Hilfe?

Externe Hilfe lohnt sich, wenn es eine Aufgabe gibt, die Sie nicht selbst erledigen können oder für die Ihnen die Zeit fehlt. Nutzt noch niemand das Produkt, führen Sie die Gespräche, bevor Sie Geld ausgeben. Dann ist die ehrliche Antwort auf „Brauche ich externe Hilfe?“ meiner Meinung nach: „Noch nicht.“

Bei diesen Anzeichen hilft ein Blick von außen:

• Sie wissen, dass Nutzer in einem Ablauf aufhören, finden aber den Grund nicht.
• Das Team ist so an das Produkt gewöhnt, dass es nicht mehr sieht, wo Neue hängen bleiben.
• Vor einer Finanzierungsrunde oder einem Gespräch mit einem großen Kunden zählt der erste Eindruck des Produkts.
• Sie haben einen Entwickler, aber es ist unklar, wer die Screens gestaltet.

Meine Angebote richten sich nach diesen Anzeichen. Ist das Problem bekannt, der Grund aber nicht, beginnen Sie mit dem UX Audit (79 €, ein Ablauf, geliefert innerhalb von 48 Stunden). Steht fest, was korrigiert werden soll, bringt der Design & Ship Sprint Design und Code in zwei Wochen in Ihr Repository. Der Sprint kostet 1.999 €, und haben Sie innerhalb von 30 Tagen ein Audit gebucht, wird die Audit-Gebühr abgezogen.

Wollen Sie das MVP von Grund auf bauen lassen, passt das Festpreisprojekt vielleicht besser. Sie beschreiben, was Sie vorhaben, und innerhalb von 24 Stunden bekommen Sie einen Preis und einen Liefertermin. Welches Modell zu Ihnen passt, vergleiche ich im Ratgeber Designabo oder Festpreis.

Häufige UX-Fehler von Gründern

Die erste Version polieren. Dark Mode und Animationen sind fertig, aber niemand hat den Kernablauf getestet. Politur macht einen falschen Ablauf nur teurer.

Das Designsystem zu früh bauen. Eine Komponentenbibliothek für ein Produkt mit drei Screens friert Entscheidungen ein, die sich noch ändern werden.

Den Test zur großen Veranstaltung machen. Nielsen empfiehlt statt einer Studie mit 15 Nutzern drei Studien mit je fünf. Korrigieren Sie nach jeder Runde.

Den Screen der Konkurrenz kopieren. Der Ablauf eines anderen Produkts ist für dessen Nutzer und dessen Geschäftsmodell gebaut. Zeigen Sie ihn Ihren eigenen Nutzern, bevor Sie kopieren.

Sich selbst für den Nutzer halten. Gründer kennen das Produkt am besten. Deshalb sehen sie auch am schwersten, wo neue Nutzer hängen bleiben.

Meine Notiz

Der Satz „Wir brauchen eine schöne Oberfläche“ ist für ein Startup ein schwacher Ausgangspunkt. Meist ist der eigentliche Bedarf ein anderer: zu sehen, was Nutzer in den ersten zehn Minuten erleben.

Deshalb lautet meine erste Frage: Wann haben Sie zuletzt mit den fünf Personen gesprochen, die Ihr Produkt zuletzt genutzt haben? Lautet die Antwort „nie“, empfehle ich die Gespräche vor dem Design.

Nehmen Sie sich einen Nachmittag, bevor Sie eine Designerin bezahlen. Lassen Sie fünf Personen Ihr Produkt nutzen und schweigen Sie. Die Notizen, die Sie mir dann mitbringen, sind auch der wertvollste Input für ein Audit.