Wie gestaltet man SaaS-UX?

Kurz gesagt

Bei einem SaaS-Produkt geht der Verkauf weiter, nachdem der Nutzer angefangen hat. Er zahlt jeden Monat oder jedes Jahr neu, entscheidet also in jeder Periode neu. Deshalb schaue ich im SaaS-Design vor allem auf den Ablauf von der Registrierung bis zur Verlängerung.

In SaaS-Audits konzentriere ich mich auf sechs Stellen: Aktivierung, Onboarding, Testphase, Tarif- und Abrechnungsscreens, Rollen und Rechte, leere Zustände. Alle haben dieselbe Frage: Wann sieht der Nutzer, dass das Produkt ihm hilft?

Der Unterschied zwischen B2B- und B2C-SaaS ist groß. In einem Unternehmensprodukt ist die Person, die kauft, oft nicht dieselbe, die es täglich nutzt.

Aktivierung und Time to Value

Aktivierung ist der Moment, in dem ein neuer Nutzer zum ersten Mal die Aufgabe erledigt, die das Produkt verspricht. In einer Buchhaltungs-App ist das der Moment, in dem die erste Rechnung beim Kunden ankommt. In einem Projekttool kann es die erste Aufgabe sein, die einer Kollegin zugewiesen wird.

Time to Value ist die Zeit von der Registrierung bis zu diesem Moment. Ich messe sie in zwei Einheiten: Minuten und Schritte. Minuten zeigen das Tempo des Produkts, Schritte die Last des Designs.

1. RegistrierungDas Konto wird eröffnet.
2. EinrichtungDas Nötigste wird eingegeben.
3. Erster WertDas Produkt erledigt seine Aufgabe zum ersten Mal.
4. WiederkehrDer Nutzer kommt am nächsten Tag zurück.
5. BezahlungDie Testphase endet, ein Tarif wird gewählt.

Abbildung: Der Aktivierungspfad. Die Time to Value ist die Zeit vom ersten bis zum dritten Kasten.

Für diese Begriffe gibt es keine allgemein anerkannte Definition. Den Moment des Werts wählt jedes Produkt selbst. Meine Regel: Der Moment des Werts ist ein Ereignis, bei dem der Nutzer auf den Screen schaut und sagen kann „Das funktioniert“.

Bei der Wahl dieses Moments stelle ich zwei Fragen. Ist das Ereignis die eigentliche Aufgabe des Nutzers oder nur eine Vorbereitung? Kommen Nutzer, die das Ereignis erleben, zum Produkt zurück?

Vorbereitende Schritte sind kein Wert. Ein Logo hochzuladen oder eine Vorlieben-Umfrage auszufüllen richtet das Produkt ein, bringt dem Nutzer aber nichts. Ich nenne diese Schritte Hürden, weil sie zwischen dem Nutzer und dem ersten Wert stehen.

Zum Messen braucht es keine große Analytics-Einrichtung. Eröffnen Sie selbst ein neues Konto, starten Sie die Stoppuhr und notieren Sie bis zum Moment des Werts jeden Screen und jede Wartezeit. In den ersten Wochen sagt Ihnen diese Liste mehr als ein Dashboard.

SaaS-Onboarding: zuerst die Aufgabe, dann die Tour

SaaS-Onboarding hat eine einzige Aufgabe: den Nutzer zum ersten Wert zu bringen. Das Produkt zu erklären, ist so viel wert, wie es dabei hilft.

Page Laubheimer von NN/g beschreibt in seinem Artikel von 2023, dass Tutorials beim Start häufiger als nötig eingesetzt werden. Sie unterbrechen die Arbeit des Nutzers und geben Informationen ohne Kontext. Nutzer überspringen sie oft, und selbst wenn sie sie ansehen, vergessen sie sie schnell.

Laubheimer erklärt das mit dem Paradox des aktiven Nutzers. Der Nutzer will das Produkt sofort benutzen und wehrt sich dagegen, vorab zu lernen, auch wenn es ihm später helfen würde. Er empfiehlt, Hilfe im Moment des Bedarfs zu zeigen: als Tipp, als Hinweismarke oder als Schritt-für-Schritt-Assistent.

Diese Reihenfolge wende ich im SaaS-Onboarding an:

1. Verlangen Sie bei der Registrierung nur, was für das Konto reicht. Wird die Steuernummer für die erste Rechnung gebraucht, fragen Sie bei der ersten Rechnung.
2. Setzen Sie den Nutzer nicht vor ein leeres Dashboard, sondern an den ersten Schritt Richtung Wert.
3. Machen Sie die Produkttour nicht zur Pflicht. Auch Laubheimer empfiehlt, dass sich Hilfe leicht schließen und später leicht finden lässt.
4. Teameinladung, Integrationen und Vorlieben kommen nach dem ersten Wert.

Screen-Muster und Beispiele beschreibe ich im Muster Onboarding. Im Simulator unten sehen Sie, wie sich der Trichter verändert, wenn Sie Schritte vor oder nach dem ersten Wert verlangen.

Aktivierungstrichter

9Schritte6HürdenBis zum ersten Wert sind es 9 Schritte. 6 davon sind Hürden.

Trichter

1. Weg Konto eröffnen: E-Mail und Passwort
2. HürdeSpäter E-Mail bestätigen
3. HürdeSpäter Wir lernen Sie kennen: Umfrage mit 4 Fragen
4. HürdeSpäter Firmen- und Steuerdaten
5. HürdeSpäter Kartendaten
6. HürdeSpäter Produkttour: 6 Screens
7. HürdeSpäter Kollegin oder Kollegen einladen
8. Weg Ersten Kunden anlegen
9. Weg Erste Rechnung senden
10. Erster Wert: Die Rechnung ist beim Kunden angekommen

Eine erfundene Buchhaltungs-App. Schritte und Zahlen stammen aus keinem echten Produkt und zeigen keine Conversion-Rate. Dass die Balken schmaler werden, illustriert nur die Reihenfolge. Nehmen Sie bei einem Kästchen den Haken weg, wird der Schritt nicht gelöscht, sondern hinter den ersten Wert verschoben.

Im Simulator wird kein Schritt gelöscht, nur seine Position ändert sich. Auch in echten Produkten sind die meisten dieser Schritte nötig. Das Problem liegt meist in der Reihenfolge.

Für Einstellungen in komplexen Produkten nutze ich Jakob Nielsens Empfehlung der schrittweisen Offenlegung (progressive disclosure). Nielsen empfiehlt, häufig genutzte Optionen auf der ersten Ebene zu zeigen und fortgeschrittene erst auf Wunsch zu öffnen. Laut seinem Artikel von 2006 haben Designs mit mehr als zwei Ebenen meist eine schlechte Usability, weil Nutzer sich zwischen den Ebenen verlieren.

Der Leitfaden für komplexe Anwendungen von Kate Kaplan (NN/g, 2020) zeigt in dieselbe Richtung. Fortgeschrittene Optionen sollten nur erscheinen, wenn sie zur aktuellen Aufgabe passen. So wird der Screen schlichter, ohne dass das Produkt an Kraft verliert.

Die Testphase gestalten

Die Testphase ist die Zeit, in der der Nutzer vor dem Bezahlen den Moment des Werts erreichen soll. Sieht er in dieser Zeit keinen Wert, hat er nach dem Ende keinen Grund zu zahlen. Deshalb schaue ich vor der Länge der Testphase auf ihren ersten Tag.

Das prüfe ich auf den Screens der Testphase:

• Ist die Restzeit sichtbar? Im Dashboard sollte an einer ruhigen Stelle „Ihre Testphase endet am Freitag“ stehen. Ein blinkender Hinweis auf jedem Screen ist nicht nötig.
• Wird die erste Zahlung vorher genannt? Werden Kartendaten abgefragt, stehen Datum und Betrag der ersten Zahlung direkt neben dem Kartenformular.
• Was passiert am Ende? Wird das Konto gesperrt, werden Daten gelöscht, geht es in einen kostenlosen Tarif? Der Nutzer sollte das vor dem Ende wissen.
• Ist die Kündigung so leicht wie die Registrierung? Geht die Registrierung mit zwei Klicks, die Kündigung aber nur per E-Mail an den Support, steckt der Nutzer in einer Abo-Falle.

Der letzte Punkt ist eine Frage des Vertrauens. Solche Fallen beschreibe ich mit Beispielen im Ratgeber zu Dark Patterns, den Kündigungsablauf im Muster Abo kündigen.

Kartendaten zu Beginn der Testphase abzufragen, ist eine Geschäftsentscheidung, die das Design nicht allein trifft. Auf der Designseite habe ich nur eine Bedingung: Das Kartenformular sagt klar, wann und wie viel der Nutzer zahlen wird.

Tarif- und Abrechnungsscreens

Der Tarifscreen ist der Ort, an dem der Nutzer die Antwort auf „Welcher passt zu mir?“ sucht. Den häufigsten Fehler sehe ich darin, dass jeder Tarif mit einer langen Funktionsliste kommt. Um den Unterschied zu finden, muss der Nutzer Zeile für Zeile vergleichen.

Kate Moran und Taylor Dykes von NN/g empfehlen in ihrem Artikel über Vergleichstabellen von 2024:

• Halten Sie eine feste Vergleichstabelle bei höchstens fünf Optionen. Gibt es mehr, lassen Sie Nutzer selbst auswählen, was sie vergleichen.
• Bieten Sie an, Zeilen auszublenden, die bei allen Optionen gleich sind, damit nur die Unterschiede bleiben.
• Fixieren Sie bei langen Tabellen die Spaltenköpfe. Nutzer können sich nicht merken, welche Spalte zu welcher Option gehört.
• Bedenken Sie, dass es auf dem Handy schwer ist, mehr als zwei Optionen gleichzeitig zu zeigen.

Ich ergänze die Schreibweise des Preises. Ob monatlich oder jährlich, ob mit oder ohne Umsatzsteuer, steht direkt neben der Zahl. B2B-Käufer suchen diese Angabe auf den ersten Blick, weil die Rechnung in die Buchhaltung geht. Wie eine Preisseite insgesamt aufgebaut wird, beschreibe ich im Muster Preisseite.

Der Abrechnungsscreen

Den Abrechnungsscreen öffnet man selten, aber wenn, gibt es meist ein Problem. Die Karte wurde abgelehnt, oder die Buchhaltung will die Rechnung vom letzten Monat. Deshalb muss der Screen die gesuchte Information auf den ersten Blick liefern.

Auf einem guten Abrechnungsscreen sieht man sofort:

• den aktuellen Tarif und die Zahl der Nutzer,
• Datum und Betrag der nächsten Zahlung,
• die gespeicherte Zahlungsart und den Weg, sie zu ändern,
• frühere Rechnungen zum Herunterladen,
• den Weg, den Tarif hoch- oder herabzustufen und zu kündigen.

Zeigen Sie bei einem Tarifwechsel zuerst das Ergebnis. Eine Vorschau, die sagt, wie viel heute abgebucht wird und wie die nächste Zahlung aussieht, verhindert die Überraschungsrechnung. Das Support-Ticket, das darauf folgen würde, entsteht gar nicht erst.

Schlägt eine Zahlung fehl, nennt die Meldung Grund und Lösung. „Ihre Karte ist abgelaufen. Fügen Sie eine neue Karte hinzu.“ führt den Nutzer zum richtigen Button, „Vorgang fehlgeschlagen“ nicht.

Sperren Sie das Konto nicht sofort, wenn eine Zahlung abgelehnt wird. Geben Sie dem Nutzer einige Tage, um die Karte zu aktualisieren, und nennen Sie diese Frist klar auf dem Screen. Ein Team sollte nicht am Freitagabend wegen eines Kartenproblems den Zugang zu allen Daten verlieren.

Rollen und Rechte

In SaaS-Produkten, die Teams nutzen, sieht nicht jeder alles. Rechnung und Einstellungen pflegt die Administration, Teammitglieder erledigen ihre Arbeit. Rollen schaffen diese Trennung, lassen den Nutzer aber bei schlechtem Design ohne Erklärung vor einer Wand stehen.

Amy Schade von NN/g erwähnt in ihrem Artikel über Personalisierung von 2016 Intranet-Teams, die ihre Nutzer in so viele Gruppen aufgeteilt hatten, dass die Gruppen nicht mehr zu pflegen waren. Derselbe Artikel empfiehlt, personalisierte Bereiche regelmäßig zu überprüfen, weil sich Bedürfnisse mit der Zeit ändern.

Diese Lehre übertrage ich auf Rollen und halte ihre Zahl klein. Für die meisten Produkte reichen anfangs Inhaber, Admin und Mitglied. Eine eigene Rolle kommt dazu, wenn der Bedarf wirklich entsteht.

Was ein Nutzer ohne Berechtigung sieht, ist ebenfalls eine Designentscheidung. Maria Rosala von NN/g behandelt in ihrem Artikel über App-Berechtigungen von 2019 eine ähnliche Situation. Öffnet der Nutzer eine Funktion, die an eine abgelehnte Berechtigung gebunden ist, sollte statt eines allgemeinen Fehlers der Grund erklärt und ein einfacher Weg gezeigt werden, die Berechtigung zu erteilen.

Bei Rollen mache ich es genauso. Statt „Zugriff verweigert“ schreibe ich: „Rechnungen sehen nur Admins. Bitten Sie Ihren Konto-Admin um Zugriff.“ Daneben setze ich einen Button, der die Anfrage mit einem Klick sendet.

Button ausblenden oder deaktiviert zeigen? Wird der Nutzer diese Aufgabe nie erledigen, blende ich ihn aus. Kann er sie nach einem Rollenwechsel erledigen, zeige ich ihn deaktiviert und schreibe den Grund daneben.

Leere Zustände

In einem neuen SaaS-Konto sind die meisten Screens leer. Kundenliste, Berichte und Mitteilungen warten auf die ersten Daten des Nutzers. Nach meiner Erfahrung aus Audits ist der leere Zustand in den meisten Produkten der zuletzt gestaltete Screen.

Kate Kaplan von NN/g nennt in ihrem Artikel von 2021 drei Regeln für leere Zustände. Der leere Screen teilt den aktuellen Systemstatus mit, gibt einen Hinweis, was zu tun ist, und öffnet einen direkten Weg zur eigentlichen Aufgabe.

Kaplan hält es außerdem für irreführend, während des Ladens „keine Einträge“ anzuzeigen. Diese Meldung kann das Vertrauen des Nutzers in die Anwendung beschädigen.

Eines von Kaplans Beispielen ist für SaaS besonders nützlich. Auf dem leeren Screen stehen zwei Wege nebeneinander: eigene Daten hinzufügen oder mit Demodaten starten. So probiert der Nutzer das Produkt gefahrlos aus, ohne seine echten Daten anzubinden.

Ein Text für einen leeren Zustand kann so lauten: „Sie haben noch keine Kunden angelegt. Legen Sie Ihren ersten Kunden an oder importieren Sie Ihre Excel-Liste.“ Diese zwei Sätze sagen dem Nutzer, wo er ist und was er tun kann. Darunter reichen zwei Buttons.

Für das Formular zum Anlegen eines Kunden siehe das Muster Formulardesign.

Häufige Fehler im SaaS-Design

Onboarding gestalten, ohne den Moment des Werts zu definieren. Ist das Ziel nicht klar, wird der Ablauf zu einer Tour, die nacheinander alle Funktionen des Produkts erklärt.

Bei der Registrierung alles abfragen. Firmengröße und Telefonnummer werden schon auf dem ersten Screen gefragt. Der Nutzer ist vom Formular erschöpft, bevor er das Produkt sieht.

Die Tour zur Pflicht machen. Kann der Nutzer das Produkt erst nach der Tour benutzen, ist die Tour eine Hürde.

Tarifunterschiede verstecken. Muss man vierzig Zeilen lesen, um den Unterschied zu finden, wählt der Nutzer den günstigsten Tarif oder verlässt die Seite.

Die Kündigung verstecken. Eine versteckte Kündigung hält kurzfristig ein paar Abonnenten, kostet langfristig Vertrauen.

Das Produkt immer mit vollem Konto sehen. Das Team sieht das Produkt in einem Demokonto voller Daten, der neue Nutzer startet mit einem leeren Konto. Machen Sie Usability-Tests und Audits auch mit einem leeren Konto.

Meine Notiz

In SaaS-Audits eröffne ich als Erstes ein neues Konto und zähle die Schritte bis zum Moment des Werts. Mehr als die Gesamtzahl interessiert mich, wie viele dieser Schritte Hürden sind.

Teams setzen Hürden meist in guter Absicht. Die Finanzabteilung will die Kartendaten, das Marketing die Umfrageantworten. Jede Forderung ist für sich vernünftig, aber zusammen ermüden sie den neuen Nutzer, bevor er seine erste Rechnung verschickt.

Meine Empfehlung ist meist, zu verschieben. Fragen Sie eine Information dann, wenn sie wirklich gebraucht wird: die Steuernummer bei der ersten Rechnung, die Teameinladung nach der ersten erledigten Aufgabe. Wenn ich das ganze Produkt mit diesem Blick durchgehen soll: Das UX Audit Pro schaut sich bis zu 10 Abläufe an.