Wichtiges Puzzleteil: Konzept für den Empty-Data-Status

Der Empty Data-Status wird viel zu häufig stiefmütterlich behandelt. Wie geht man aus Nutzersicht am Besten damit um, wenn in einem View keine Daten enthalten sind?

17. Januar 2015

Egal, ob Webapp oder Mobile App: Der Empty Data-Status von Apps ist eine häufig unterschätzte Situation in der Konzeption. Empty Data bedeutet, dass der User in eine Nutzungssituation gerät, in der in einem View keine Daten enthalten sind – obwohl das Konzept und insbesondere das Design dieses Views darauf ausgelegt sind, dass hier entsprechende Daten angezeigt werden. Nicht selten sogar eine Vielzahl von Daten (z.B in Liste, Tabelle, Grid etc.).

Während sich Designer und Entwickler meist auf den späteren Nutzungsstatus mit (vielen) Daten konzentrieren, wird der Empty Data-Status viel zu häufig stiefmütterlich behandelt. Dabei ist diese Nutzungssituation nicht nur vorhersehbar, sondern vielmehr auch immens wichtig, weil man sie sich konzeptionell zu Nutze machen kann sollte. Die User Experience kann in diesem Zusammenhang nachhaltig verbessert werden und der Erfolg einer App kann maßgeblich beeinflusst werden.

Typische Empty Data-Situation

Die typischen Situationen, in denen der Empty-Data-Status auftritt, sind:

  • die initiale Nutzung (z.B. ohne vorherige Aktionen),
  • bestimmte Filter-Einstellungen liefern keine Ergebnisse, und
  • keine Datenbank-/Internet-Verbindung.

Diese Zustände sollten nicht einfach nur mit der eigentlich geplanten Listenansicht in einer Art „Leerstand“ aufgefangen werden. Vielmehr sollten diese Zustände mit eigenen Designs, Views oder konzeptionellen Fallbacks auf die jeweilige Situation berücksichtigt und durchdacht werden. Der letzte Punkt betrifft insbesondere native Mobile Apps, in denen in einem View Daten nachgeladen und angezeigt werden sollen, die z.B. aufgrund fehlender Datenverbindung dann aber nicht angezeigt werden können.

Konzeptionelle Lösungen

Die leider viel zu häufig Art mit diesen Fällen umzugehen: anstelle der Übersicht (z.B. Tabelle oder Grid View) wird eine Flash-Meldung mit einem Hinweis wie „Für diese Ansicht liegen keine Daten vor“ eingeblendet. Häufig geschieht dies sogar noch in der optischen Form einer Fehlermeldung – der Nutzer hat jedoch keinen Fehler gemacht, sondern er beginnt vielleicht einfach nur die App zu nutzen. Gerade bei der initialen Nutzung ist genau das also absolut zu vermeiden. Das Konzept sollte vielmehr vorsehen, dem User zu zeigen, was hier möglich ist. Und je nach Service und Nutzungssituation ggf. eine eindeutig Aufforderung zur Aktion beinhalten.

Wie die User Experience für den Empty-Data-Status konkret verbessert werden kann und wie dabei der User-Onboarding-Prozess nahtlos integriert werden kann, hängt stark vom Einzelfall ab. Es gibt keine pauschalen Lösungen, da insbesondere die Art des Service, die Nutzungssituation, die Zielgruppe und der Umfang der Daten entscheidenden Einfluss auf eine konzeptionelle Lösung haben.

Folgende Punkte sollten jedoch generell bei der Konzeption für den Empty-Data-Status beachtet werden:

Den User in keinem Fall mit Fehlermeldungen erschrecken

Empty-Data-Views, die auch nur annäherungsweise so aussehen wie eine Fehlermeldung, treffen in allen Fällen eine komplett falsche Aussage. Entweder gibt es noch keine Daten (keine Fehler des Users, sondern im Onboarding-Konzept), der User hat die Daten so gefiltert, dass keine Daten mehr vorliegen (kein Fehler des Users, sondern ein „erfolgreiches“ Resultat seiner Aktion) oder das Laden der Daten nicht funktioniert (kein Fehler des Users, sondern die Technik hakt).

Zeigen, wie der Webservice funktioniert, wenn Daten vorhanden wären

Ist es vielleicht möglich und sinnvoll, durch plakative, beispielhafte Daten zu zeigen, wie der View eigentlich aussehen würde? Es ist dafür sinnvoll, sich dabei in die Nutzungssituation des Users zu versetzen. Manchmal sind hier in mobilen Szenarien ggf. auch zu anderen Lösungen sinnvoll als in stationären Anwendungsfällen. Nicht selten sind mobile Szenarien eher auf Konsumieren und Schnelligkeit ausgelegt, während Desktop-Situationen eher konkrete Handlungsaufforderungen zulassen.

Den User auffordern und dabei unterstützen, den Empty-Data-Status aufzuheben

Wenn die Nutzungssituation es zulässt, können durchaus klare Handlungsaufforderungen implementiert werden, die dem Nutzer einen klaren, kurzen Weg zum ersten Dateneintrag ermöglichen. Schnelle, automatisierte Prozesse bei denen der Nutzer nahezu keine Eingaben machen muss, sondern lediglich durch Klicken auswählt und ergänzt, sind hier der richtige Weg zum ersten Dateneintrag.

Aktionen vermeiden, die einen Empty-Data-Status herbeiführen

Wenn zum Beispiel Listenansichten über Filter durch den Nutzer individualisiert werden können, kann man technisch ausschließen, dass der Nutzer zu einem Null-Ergebnis kommt. Es werden immer nur die Filter-Optionen angeboten, die mindestens einen Eintrag zur Anzeige bringen. Wenn diese Prozesse in komplexen Filterumgebungen „on click“ ins Interface integriert werden, liegt die Hauptaufgabe darin, die manipulierten Filteroptionen für den Nutzer transparent zu halten.

Mit einem Augenzwinkern reagieren – wenn die Situation es zulässt

Wenn die Anzeige aufgrund fehlender Datenbankverbindung scheitert, kann in bestimmten Fällen eine selbstironische Fehlermeldung in Frage kommen. Aber auch hier vorher genau über die Nutzungssituation nachdenken – unter Umständen ist Humor hier aus Nutzersicht fehl am Platze.