Warum wir in Deutschland bei der Entwicklung von digitalen Produkten immer noch nicht auf den Nutzer hören. Eine Polemik.

Ja klar, einen Usabilitytest machen wir dann schon – plant den mal mit ein.

Das hören wir eigentlich in jedem Projekt. Ob der Test dann auch wirklich gemacht wird, steht wieder auf einem anderen Blatt. Macht ja auch nichts, wir sind ja alle Experten, wir wissen schon was dem Nutzer gefällt. Ausserdem wurde schon genug Geld für Marktforschung ausgegeben, die Kunden sind bekannt, man weiss ganz genau was sie wollen.
Und eigentlich ist es ja ganz einfach: lasst uns das machen, was der Wettbewerb macht, aber besser natürlich. Unser Design wird besser, unsere Inhalte sind besser, und dann erst die UX! Die UX!

Mhm, ja.

Was heisst denn UX? User Experience. Genau, Nutzer Erfahrung. Die Erfahrung des Nutzers bei der Nutzung. Es soll Spaß machen, das Produkt soll als wertvoll wahrgenommen werden. Positiv soll sie sein, diese Beurteilung der Nutzungsqualität. Damit die Nutzer zu Fans werden, sie loyal gegenüber dem eigenen Produkt werden, die Nutzungshäufigkeit steigt, der Umsatz steigt. So einfach könnte es sein.

Blöd nur, dass Nutzer bei der Erstellung des digitalen Produkts nur als Randerscheinung vorkommen. Als Abnehmer des fertigen Produkts, die sich dann mit den erdachten Funktionen herumschlagen, die sich auf eine erdachte Art und Weise präsentieren und diese Erfahrung dann hoffentlich als positiv beurteilen. Weil – siehe oben.

Man könnte Nutzer ja eigentlich auch von Anfang an mit einbinden, immerhin baut man die digitalen Produkte in der Regel ja für sie. Klar, nicht nur die Anforderungen der Nutzer sind relevant, auch geschäftliche, regulatorische oder fachliche Anforderungen spielen eine Rolle. Aber ohne den Nutzer ist das halt alles nix. Wenn er mit der Anwendung nicht das tun kann, was er erwartet, auf eine Art und Weise die er erwartet, dann wird er es nicht tun. Oder zumindest nicht so häufig wie man das als Anbieter gerne hätte. Er wird keine Freude daran haben, keine positiven Emotionen gegenüber dem Produkt entwickeln, seine Beurteilung bleibt bestenfalls neutral.

Also lasst ihn uns doch mit dazu nehmen, lasst uns rausfinden, was ihn antreibt, was ihm gefällt, was nicht und lasst uns verstehen warum. Und dann lasst uns die Featureliste, das Konzept und das Design machen. Und zwischendrin befragen wir ihn auch immer wieder, weil wir mit Freude experimentieren, Fehler machen und daraus lernen. Ja klar, es könnten Dinge herauskommen, die man gar nicht hören will, nämlich z.B. dass diese 10 Must-Have Features kein Mensch braucht, sie aber 30% der Entwicklungsressourcen binden. Oder dass das persönlich präferierte Design und die gewählte Farbwelt niemanden sonst ansprechen oder dass die Ästhetik für die Icons und die Formensprache zwar in der Theorie zielgruppenadäquat sind, in der Realität aber in diesem speziellen Kontext dieser speziellen Anwendung niemanden dazu bringt, sich zu freuen.

Oder wir sagen einfach wie es ist: wir bauen digitale Produkte mit einem marktadäquaten Funktionsumfang, sehr guter Usability in einem äusserst ansprechenden Design. Das eine gute UX ein ganz besonderes Differenzierungsmerkmal sein kann, diese Chance lassen wir dann bewusst verstreichen.

Dann müssten wir die UX relevanten Berührungspunkte mit dem Nutzer nämlich von Anfang an einplanen (siehe Grafik), die entsprechenden Kosten und Zeiträume mitdenken. Aber teuerer würde es dadurch nicht, insgesamt länger dauern würde es auch nicht. Wir müssten nämlich Fehler nicht erst im nächsten (vielleicht nie kommenden) Release beheben, was länger dauert und mehr kostet. Wir würden gar nicht erst Aufwand in Funktionen stecken, die niemanden interessieren, wir würden nach einem verpatzten Start nicht viel Geld in die erneute Überzeugung der Nutzer vom Produktnutzen stecken müssen. Wir würden Nutzer besser konvertieren, sie hätten mehr Freude bei der Nutzung. Unterm Strich wird das Projekt dadurch nicht teurer oder langwieriger, es wird nur ein anderes Projekt.

Also lasst uns keine Angst davor haben und den Nutzer endlich wirklich mit einbeziehen – und zwar mit mehr als nur einem nachgelagerten Usabilitytest.