Der Nutzer im Mittelpunkt: User Centered Design bei digitalen Anwendungen

Technik gemacht für den Anwender

Was ist einer der breitesten Gräben in der Digitaltechnik? Es ist die oftmals enorm steile Fähigkeitsschwelle zwischen denjenigen, die eine Anwendung erschaffen und denjenigen, die sie später benutzen müssen.

Auf der einen Seite stehen immer Profis ihres digitalen Schaffens: Programmierer beispielsweise oder Full-Stack-Entwickler. Sie sind jedoch nicht nur sehr fähig, sondern kennen die von ihnen entwickelte Anwendung überdies in- und auswendig und von der Pike auf. Außerdem arbeiten sie entweder nach einer vorgegebenen Design- und Funktionsvorgabe oder erstellen diese selbst, sodass sie auch hier höchstes Detailwissen besitzen.

Auf der anderen Seite hingegen stehen Menschen, die typischerweise (aber nicht zwangsläufig) deutlich geringere IT-Kenntnisse besitzen, dafür aber mitunter viel mehr Fachkenntnisse im Nutzungsgebiet der Anwendung. Das gilt sowohl generell wie speziell für ein konkretes Tool, sobald dieses nicht von IT-Entwicklern für IT-Entwickler konzipiert wurde – und selbst dann kann es noch zu Problemen kommen.

Hier kommt nun User Centered Design (UCD, auch nutzerorientierte Gestaltung) ins Spiel: Dabei handelt es sich, sinnbildlich gesprochen, um eine Brücke. Eine Design-Philosophie, wonach eine konkrete digitale Technik in jeder Hinsicht für denjenigen Teil der Zielgruppe konzipiert wird, der das geringste Wissen, die geringsten Fähigkeiten besitzt. Darüber gibt es vieles zu wissen – und auf den folgenden Zeilen verraten wir alles darüber.

1. Profis versus User: Der Grund hinter UCD

Wohl die meisten jungen IT-Talente, die diese Zeilen lesen, dürften Begriffe wie den des „DAU“ kennen – der dümmste anzunehmende User. Einmal völlig abgesehen von der Diskriminierung, die mit solchen Begrifflichkeiten einhergeht, ist es zwingend nötig, sich aus professioneller Sicht zweier Tatsachen bewusst zu sein:

• Derjenige, der eine digitale Anwendung erstellt, steht in Sachen Fähigkeiten und Wissen über das Digitale immer auf der obersten Stufe, ist aber wahrscheinlich, zumindest bei professionellen Nutzungszwecken seiner Arbeiten, demjenigen unterlegen, der täglich darin agiert.
• Derjenige, der eine digitale Anwendung nutzt, steht in Sachen Fähigkeiten und Wissen über das Digitale praktisch immer auf irgendeiner niedrigeren Stufe. Wie niedrig, hängt von der primären Zielgruppe ab, für die die eine Anwendung konzipiert wurde. Gleichsam hat er jedoch bei professionellen Nutzungszwecken ein sehr hohes Knowhow.

Diese Differenz stellt den bereits angesprochenen Graben dar. Und je breiter er ist, desto gefährlicher ist er – für den Erfolg einer Anwendung und nicht zuletzt der ganzen dahinterstehenden Firma.

Doch warum ist dieser Unterschied so gefährlich und wie entsteht er? Es ist die Tatsache, dass viele IT-Experten durch ihr Wissen und ihr Arbeitsumfeld in gewisser Hinsicht „betriebsblind“ sind. In der Praxis stellt sich dies so dar, dass sie eine Anwendung ausschließlich oder zumindest maßgeblich aus ihrer Sicht entwickeln. Das heißt, sie betrachten die Aufgabenstellung aus dem Blickwinkel einer Person, die in Sachen IT äußerst bewandert ist und das von ihr entwickelte Produkt wie die eigene Westentasche kennt, dafür aber vielleicht nur wenig Wissen hinsichtlich der Nutzungsrealität aufseiten des Users besitzt. In der Folge besteht die Gefahr, dass alles, was die Developer entwickeln, sich auf diesem – ihrem – Niveau befindet.

Die Folge: Der User wird zumindest in die Zwangslage gebracht, sich anpassen zu müssen. Er muss lernen, muss umdenken, kann eine Anwendung nicht auf Anhieb so nutzen, wie es für ihn natürlich wäre. Das muss er, weil die IT-Experten ein Programm, ein Tool et cetera kreiert haben, welches durch schlechtes User Centered Design eher für die Erschaffer gemacht wurde; zumindest aber aus deren Sicht. Manchmal geht das Problem sogar so weit, dass eine Anwendung dadurch regelrecht am User vorbei entwickelt wird – etwa das System „Pust Sibel“, welches für die Schwedische Polizei programmiert wurde, in der Praxis jedoch zahlreiche Probleme machte.

Wer sich an dieser Stelle fragt, warum jemand so vorgehen würde, der sei versichert, dass es sich hierbei nicht um eine seltene Ausnahme handelt. Ganz im Gegenteil, über weite Strecken der IT-Geschichte war es Usus, dass der Nutzer sich einer Anwendung anzupassen hatte, um sie richtig nutzen zu können. Und selbst dann gab es oft Probleme, weil die Entwickler die Nutzungsrealität nicht präzise genug ansprachen. Wer sich dies anhand eines simplen Beispiels jenseits der IT vorstellen möchte, kann sich folgendes visualisieren:

Schlechtes UCD wäre es, wenn kein Autoentwickler Fahrpraxis hätte, zudem Pedale, Blinkerhebel und Schalter an beliebigen Stellen und in beliebigen Reihenfolgen installieren würde. Überdies wäre die Kraftstoff-Einfüllöffnung dort, wo die Designer es sinnvoll fänden.

Wie sich dies in der Praxis gestalten würde, kann man sich ausmalen. Jeder Autofahrer müsste sich beim Wechsel auf ein anderes Fahrzeug neu einarbeiten. Ein Großteil seines bisherigen Wissens und Muskelgedächtnisses wäre wertlos und es würde sehr lange Zeit vergehen, bis er den Wagen mit der gewohnten Routine und Sicherheit nutzen könnte – wenn es überhaupt vollumfänglich ginge, weil das Fahrzeug von Menschen gestaltet wurde, die kein Auto fahren können.

Die Gründe, warum es sich über viele Jahre und teils bis heute in der IT so verhält, sind schnell aufgelistet:

1. Jeder Programmierer ist natürlich bestrebt, seinem Werk ein gewisses Alleinstellungsmerkmal zu geben – sowohl hinsichtlich des Looks wie den Funktionen und der Bedienbarkeit.
2. Es wird sich nicht umfassend genug mit der Zielgruppe der späteren User befasst. Dadurch tendieren viele Entwickler dazu, deren Fähigkeiten in der Breite als zu hoch einzuschätzen und gleichzeitig die Usability ihres Werks als optimal.

User Centered Design: Die Kernpunkte

Einer der ersten, die sich Gedanken um das Problem machten, war der US-Informatiker Rob Kling. Er prägte nicht nur schon 1977 den Begriff des User Centered Designs, sondern veröffentlichte in diesem Jahr eine Arbeit, die das Problem grundsätzlich beschrieb.

Es dauerte jedoch noch fast zehn Jahre, bis sich der Kognitions- und Informatikprofessor Don Norman umfassender mit dem Thema befasste. Dafür aber legte er mit seinem 1986 erschienenen Werk User-Centered System Design: New Perspectives on Human-Computer Interaction sowie dem Nachfolgebuch The Design of Everyday Things den Grundstein für eine Philosophie, die bis heute Gültigkeit besitzt – dazu sei angemerkt, dass Mister Norman als eine der wichtigsten Koryphäen auf dem Gebiet des Produktdesigns gilt, auch jenseits des Digitalen. Er ging dabei von folgendem Standpunkt aus:

Menschen sind größtenteils gegen Veränderungen und lehnen neue Methoden ab, die einer existierenden System- oder Produktpalette hinzugefügt werden. […] Die Vorteile des neuen Systems sind irrelevant: Es ist einzig und alleine der Wechsel, der stört.

Dabei votiert Don Norman dafür, vier elementare Punkte in den Vordergrund zu stellen – selbst, wenn dies zulasten rein optischer Gefälligkeit geht:

1. Eine Anwendung muss so einfach strukturiert werden, dass der Nutzer jederzeit intuitiv handeln kann.
2. Es darf nichts im Verborgenen bleiben. Aktionen, Reaktionen und alle Ergebnisse müssen erlebbar gemacht werden.
3. Die Zuordnungen (Mappings) zwischen erwünschten Ergebnissen und benötigten Handlungen müssen stimmen.
4. Die Zwänge und Limitierungen von Systemen dürfen nicht ignoriert, sondern müssen gezielt ausgenutzt werden.

Diese Punkte stellen die Grundlage dar, nach der sich auch in der IT UCD etablierte. Seit diesen Tagen wurde allerdings noch sehr viel Entwicklungsarbeit getätigt. In der Folge ist das Thema heute deutlich breiter aufgefächert.

Dabei zeigt sich der wichtigste Punkt von modernem User Centered Design darin, dass es sich dabei um einen ganzheitlichen Prozess handelt. Das bedeutet, UCD lässt sich nicht oder nur schlecht nachträglich implementieren. Es muss von Anfang an ein zentraler Bestandteil in der Entwicklung einer Anwendung sein. In der Praxis geht man angesichts dessen von einem mehrstufigen Prozess aus, der – für jedes Produkt und jede Anwendung – garantiert, dass der Nutzer die beste Erfahrung machen wird:

1. Das gesamte Design richtet sich konsequent an den User, seine Vorstellungen, Fähigkeiten und Erwartungen sowie das Umfeld der Benutzung.
2. Die Entwicklung erfolgt nicht abgeschottet, sondern User werden von Anfang an verstärkt in den gesamten Planungs- und Erstellungsprozess mit einbezogen – im Idealfall nicht nur temporär, sondern dauerhaft.
3. Nutzer werden herangezogen, um eine Anwendung im jeweiligen Stadium ihrer Entwicklung nach konkreten Vorgaben zu prüfen, zu bewerten und um Verbesserungsvorschläge zu machen. Diese Überprüfung erfolgt sich wiederholend. Das heißt, mehrfach und wiederkehrend. Nur so kann sichergestellt werden, dass es im weiteren Verlauf der Entwicklung keine verselbstständigenden Abweichungen gibt.
4. Zur Optimierung der Nutzererfahrung müssen zusätzlich andere Experten herangezogen werden; also beispielsweise nicht nur IT-Profis, sondern auch Psychologen. Dies dient dazu, eine ganzheitliche User Experience (UX) zu garantieren.

Im Klartext bedeutet dies, dass ein Entwicklerteam nicht beispielsweise auf eigene Faust eine App programmiert und dann kurz vor der Veröffentlichung einige Laien Betatests durchführen lässt. Es bedeutet viel mehr, dass der gesamte Entwicklungsprozess maßgeblich unter Beteiligung von Laien und nicht IT-spezifischen Experten erfolgt – dies ist heute wichtiger denn je, weil die Digitalisierung längst sämtliche Lebensbereiche inkludiert und sich deshalb in vielen Sparten nicht einmal mehr auf digitale Grundkenntnisse der Anwender stützen kann.

Ein sehr gutes Beispiel für diese Diskrepanz ist die Geschichte jenes scanbaren Grafikelements, das heute als QR-Code eine gigantische Verbreitung hat. Denn so fähig der Code im Vergleich mit regulären Barcodes auch ist, er hatte zunächst Anlaufschwierigkeiten. Der Grund: Es war zwingend nötig, eine Dritt-App herunterzuladen, um die Codes via Smartphone-Kamera scannen zu können – schlechtes UCD. Dann jedoch nahmen sich einige der vielleicht fähigsten IT-UCD-Experten der Welt der Sache an: Apple integrierte eine QR-Scan-Funktion einfach in die sowieso vorhandene Kamera-App des iPhones ab iOS 11. In der Folge wurde der Code – zumindest für Apple-Nutzer – so zugänglich wie nur möglich und konnte sich seitdem deutlich stärker etablieren.

Der UCD-Entwicklungsprozess: Keine leichte Aufgabe

„Produkt auf User maßschneidern, immer wieder User testen und kritisieren lassen“. Zugegeben, auf einen derartigen Einzeiler heruntergebrochen, wirkt es tatsächlich so, als sei UCD ein Kinderspiel. Tatsächlich jedoch ist es deutlich schwieriger. Wichtigste Maßgabe sind normierte Prozessmodelle, etwa die Normen der DIN EN ISO 9241  (Mensch-System-Interaktion). Daraus ergeht ein vierstufiger Entwicklungsprozess, der sich prinzipiell auch als Wasserfall darstellen lässt.

Stufe 1: Verstehen

Gutes UCD beginnt bereits, lange bevor nur eine einzige Zeile Code geschrieben wurde. In der ersten Phase geht es zunächst darum, sich umfassend mit den Nutzern und dem Kontext der Nutzung einer geplanten Anwendung zu befassen und so viele Informationen wie möglich zu sammeln. Die hierbei wichtigen Fragestellungen sind:

• Wer ist der anvisierte User?
• Auf welchem Fähigkeits- und Kenntnislevel steht der Nutzer?
• Welches Ziel hat der User; d.h. welche Erwartungen stellt er an die Anwendung?
• Welche zusätzlichen Anwendungen verwendet der User und wie muss sich die geplante Anwendung hier einfügen?
• In was für einem Umfeld (technisch, räumlich, soziokulturell…) wird die Anwendung genutzt?

Um all diese und ähnliche Fragen zu beantworten, gibt es verschiedene Herangehensweisen. Die einfachste, aber gleichsam weniger präzise, wäre es, die anvisierte Zielgruppe anhand von statistisch aussagekräftigen Mitgliedern zu interviewen. Deutlich besser wäre es, Beobachtungen in der Praxis vorzunehmen – also beispielsweise die künftigen Nutzer einer Büroorganisations-Software über einen längeren Zeitraum durch ihren Tag zu begleiten und dadurch deutlich mehr Informationen zu sammeln; auch solche, die sich nicht durch ein simples Frage-Antwort-Konzept herausfinden lassen.

Je nach Komplexität einer geplanten Anwendung kann allerdings selbst dies zu wenig sein. In solchen Fällen kann es sogar nötig werden, dass ein Teil der Entwickler in kurzen Intensivkursen selbst die Arbeit ihrer Zielgruppe erlernt. Der Erfolg: Wenn Mitglieder des Entwicklungsteams selbst den „Job“ beherrschen, können sie sich wie kein Zweiter in die Realität der Zielgruppe hineinversetzen. Ein unschätzbar wertvolles Wissen.

Stufe 2: Spezifizieren

Es ist nun bekannt, was der Nutzer kann, was er hat und was er braucht. Anhand dieser Informationen wird nun eine Art Lastenheft geschrieben: Eine exakte und erschöpfende Liste dessen, was die Anwendung können muss und wie der Weg dorthin auszusehen hat.

Dadurch beginnt das Entwicklerteam nun erstmalig, aus Sicht des Nutzers zu arbeiten – denn die Spezifikation liefert ihnen ein hochkonzentriertes Bild dieses Personenkreises. Das heißt aber, dass es von nun an keinerlei Alleingänge mehr geben darf. Jede Abweichung, ja sogar jede Fehlinterpretation kann dazu führen, dass im späteren Verlauf überflüssige Korrekturschleifen nötig werden, die das Projekt verlängern und verteuern.

Es ist deshalb nötig, dass die Erstellung der Spezifikation mit höchstem Grad an Details und mit maximaler Klarheit erfolgt. Nichts darf offenbleiben oder Interpretationsspielräume bieten.

Stufe 3: Entwerfen

Bis zu diesem Punkt besteht die geplante Anwendung nur in der Theorie. In Phase drei wird es jedoch (etwas) handfester: Es wird skizziert, wie die Anwendung später aussehen könnte. Dies muss nicht zwingend digital erfolgen, sondern kann je nach Anforderung nur auf dem Papier geschehen.

Wichtig ist hierbei, dass möglichst mehrere Konzepte parallel verfolgt werden: Welche Optionen gibt es für das Verhalten einer App? Auf welche sinnvollen Weisen könnte man die Icons einer Website ausgestalten? Sinn und Zweck der Phase ist es, den möglichen Gestaltungsspielraum maximal auszunutzen und dabei mitunter Theorien auszuloten, die auf den ersten Blick unkonventionell wirken.

Stufe 4: Überprüfen

Es liegen nun verschiedene mögliche Herangehensweisen auf dem Tisch. Für das Entwicklerteam werden alle mehr oder weniger schlüssig erscheinen; selbst wenn es in der Praxis sicherlich unterschiedliche Meinungen geben wird. Aber:

• In einem so frühen Stadium der Entwicklung ist es leicht, Fehler zu begehen, die sich durchschleifen.
• In einem so frühen Stadium der Entwicklung ist es ebenfalls leicht, Änderungen zu machen – noch wurde ja höchstens äußerst einfache, grobe Programmierarbeit geleistet.

In Phase vier kommen deshalb nun sowohl User wie Usability-Experten zu Wort. Sie analysieren die erarbeiteten Konzepte streng nach den Vorgaben eines User Centered Designs und aus ihrer Sicht – und ohne, dass das Entwicklerteam weitergehende Informationen bereitstellen darf. Je nach Aufwand und Umfang des späteren Programms kann für diese Phase schon ein oder mehrere Prototyp(en) erstellt werden, mit denen User bestimmte Aufgaben abarbeiten, während sie zeitgleich ihre Eindrücke schildern.

Hierbei ist es vor allem wichtig, alles herauszufiltern, was der angesprochenen Maßgabe von maximaler Intuition entgegenläuft. Lange bevor eine Anwendung in die Pre-Alpha-Phase eintritt, kann deshalb schon sichergestellt werden, dass es an keinem Punkt mehr zu derartigen Problemen kommen kann.

Mit den hieraus gewonnenen Daten beginnt nun die eigentliche Entwicklungsarbeit: Die Anwendung wird im Rahmen dessen programmiert, was hierfür als bestmögliches UCD-Szenario herausgefunden wurde. Und immer wieder werden auch bei den folgenden Schritten User und Usability-Experten hinzugezogen, die alles nochmals überprüfen – werden jedoch die vier Stufen der Vorarbeit sorgfältig durchgeführt, ist nicht zu befürchten, dass die Tester umfassende Änderungen einfordern.

Die maßgeblichen Vorteile des UCD und seiner Prozesse

Jeder IT-Profi hat wohl seine ganz eigene Vorstellung im Kopf, wie eine von ihm ausgedachte Anwendung aussehen und sich verhalten soll. Die genannten vier Stufen können sich selbstverständlich als enormer Dämpfer dessen entpuppen und einen Entwickler mitunter zwingen, bis auf einen groben Rahmen alles aufzugeben, was er in Sachen „Look, Feel and Behavior“ erschaffen wollte.

Frustrierend kann dies mit Sicherheit sein. Es sollte jedoch keinesfalls dazu führen, UCD zu ignorieren und sturköpfig seine eigenen Ziele zu verfolgen. Denn der Lohn der Mühen ist sehr kostbar:

1. Dadurch, dass User von Anfang an so stark involviert sind und der Fokus auf ihrer Vorstellung von Usability liegt, ist es im höchsten Maß wahrscheinlich, dass die Anwendung vom ersten Tag ein echter Erfolg wird – einfach, weil sie einen Großteil aller Zielgruppenmitglieder perfekt anspricht. Dementsprechend wird sich der Verkauf und somit Umsatz gestalten.
2. Es wird eine ganze Reihe von Problemen vermieden, bei denen der User die Quelle ist – zumindest gefühlt, wohingegen das Problem eigentlich bei schlechtem UCD zu suchen ist. Das macht eine Anwendung simpler und sicherer und hat für das dahinterstehende Unternehmen den Vorteil, das Thema Support zu deutlich geringeren Kosten betreiben zu können – weil es unwahrscheinlicher wird, dass Kunden Abhilfe für Probleme verlangen.
3. Das Entwicklerteam verlässt seinen abgeschotteten Bereich und das damit einhergehende Denken. Es wird somit ein empathischeres, fähigeres, besseres Team.

Natürlich bedeutet gutes User Centered Design nicht, dass ein digitales Produkt dadurch automatisch perfekt wird. Aber es bedeutet durchaus, dass es zumindest aufseiten der Usability niemals Probleme geben wird. Und wer an dieser „Front“ den Rücken frei hat, kann viel mehr Kraft darin investieren, die Anwendung an allen anderen Punkten zu optimieren – wodurch UCD zumindest einen enorm wichtigen Beitrag dazu leistet, eine echte digitale Erfolgsgeschichte zu schreiben.

Bildquelle für Beitragsbild/Titelbild: stock.adobe.com © Funtap #231770584