(UX-)Design muss funktionieren
Code-Testing vs. Design-Testing: eine Gegenüberstellung
UX-Design muss funktionieren – genau wie Code
Design muss funktionieren – genau wie Code. Schreibt man Quellcode, testet man ihn. Dafür lässt man zunächst den Compiler über den Code laufen. Der Compiler übersetzt den vom Programmierer entwickelten Programmcode in Maschinencode – Code, der vom Computer gelesen und ausgeführt werden kann. Die Stellen, die der Compiler nicht interpretieren kann, werden als Fehler ausgewiesen und müssen behoben werden. Sobald der Code kompiliert – also komplett und fehlerfrei übersetzt werden kann – werden im nächsten Schritt sogenannte Unit Tests durchgeführt. Hierbei werden einzelne Komponenten des Quellcodes automatisiert getestet. Automatisiert bedeutet in diesem Zusammenhang, dass die Tests selbst kleine Programme sind, die ohne Benutzerinteraktion auf Fehlersuche gehen. Softwareentwicklern steht also ein großer Werkzeugkasten zur Verfügung, um Fehler zu finden. Sind diese gefunden, können sie behoben und der Code nochmals geprüft werden. Das wird so lange wiederholt, bis der Code funktioniert.
Design muss funktionieren – genau wie Code. Gestaltet man Abläufe und Oberflächen, hat man konkrete Aufgaben vor Augen. Aufgaben, die ein bestimmter Typ von Anwender (die sogenannte Persona) zu bearbeiten hat. Das Design funktioniert, sobald eben diese Persona ihre Aufgaben mit der Lösung problemlos erledigen kann. Aber: Anders als beim Code, gibt es keinen Compiler oder automatische Tests, die man durchführen kann, um das Design zu testen. Oft wird der Entwurf lediglich dem entsprechenden Anwender gezeigt und dieser darf seine Meinung dazu sagen. Dabei wird jedoch auch genau das herauskommen: eine Meinung. Wie der Programmierer benötigt der Designer aber keine subjektiven Meinungen, sondern objektive Fakten, um das Design testen und optimieren zu können. Die Frage ist also: Wie findet man heraus, ob das Design wirklich funktioniert?
Wie kann man UX-Design testen?
Wie für Quellcode gibt es auch zur Validierung von UX-Design-Entwürfen einen vielseitigen Werkzeugkasten, um (nahezu) objektive Ergebnisse zu erzielen. Als eine der besten Methoden, hat sich dabei der Usability-Test herausgestellt. Dabei ist der „Prozessor“, der das Design „ausführt“ der Anwender – und damit ein menschliches Wesen. Allerdings nicht irgendein Anwender, sondern genau der, dessen Arbeit und Aufgaben der Designer vor Augen hatte, als er den Entwurf gestaltet hat: Geht es beispielsweise um ein Tool zur Konstruktion einer Rakete, benötigt man einen Raketenkonstrukteur als Proband. Beim Usability-Test gibt man eben diesem konkreten Anwender konkrete Aufgaben und beobachtet, wie er diese mithilfe des dafür entwickelten Design-Entwurfs löst. Am Ende ist es ein aktives „Über-die-Schulter-schauen“, durch das der Designer feststellen kann, an welchen Stellen das UX-Design versagt und an welchen Stellen es funktioniert. Wichtig ist hierbei das Wörtchen aktiv, denn es geht nicht nur darum stiller Beobachter zu sein. Vielmehr muss der Designer den Anwender laut denken lassen, indem er ihn mit Fragen löchert: Wo wurde etwas anderes erwartet, und was? Wie wird der Entwurf interpretiert? Welcher Teil ist schwer zu verstehen, und warum? Es zählt also nicht die einfache Meinung des Anwenders, sondern die Antworten auf die spezifischen Fragen, die der Designer während der Ausführung stellt.
Wie gut oder schlecht ein Computer Quellcode liest und verarbeitet, hängt neben dem eigentlichen Code auch vom allgemeinen Kontext ab – beispielsweise von der Laufzeit, der CPU oder dem Betriebssystem. Und die Frage nach dem Kontext muss man sich auch für die Validierung des Designs stellen. Denn genauso wichtig, wie der Anwender mit dem Design interagiert, ist die Frage in welchem Umfeld das Design genutzt wird. Kann der Anwender konzentriert arbeiten oder wird er immer wieder gestört? Wie sieht der Arbeitsplatz aus? Mit welchem Device wird hauptsächlich gearbeitet? Um diese Fragen zu beantworten, bieten sich On-Site Usability-Tests an – also Usability-Tests, die nicht unter Laborbedingungen stattfinden, sondern in der realen Arbeitswelt des Anwenders. Wie viel Kontext für einen Test nötig ist, hängt davon ab, was genau getestet wird.
Wie beim Testen von Quellcode ist Usability-Testing dabei keine einmalige Angelegenheit. Sobald das Design optimiert wurde, muss es wieder getestet werden – und wieder optimiert und wieder getestet. Dieser iterative Vorgang wird so lange wiederholt, bis keine Fehler mehr auftreten – das Design also funktioniert.
“There is no User Experience without Users”
Code ist absolut, Design ein Kompromiss
Es gibt einen elementaren Unterschied zwischen Code und Design: Die Logik im Code ist absolut. Grundsätzlich sind alle Hardware-Prozessoren standardisiert und gleich aufgebaut. Das bedeutet, dass auch der Code von jedem Computer in der gleichen Form interpretiert wird. Menschliche Anwender sind jedoch alle unterschiedlich. Selbst ihre Jobs sind nicht standardisiert – ein Raketenkonstrukteur bei der NASA arbeitet anders als einer bei der ESA. Das bedeutet, dass ganz gleich, wie gut die Entwurfsüberlegungen sind, die Interpretation immer individuell ist. Und sie wird, so lange Menschen involviert sind, auch immer individuell bleiben. Als Vergleich: Wenn ein Code in 9 von 10 Fällen funktioniert, ist es wirklich schlechter Code. Funktioniert aber das Design in 9 von 10 Fällen, ist es großartig. Programmierer müssen idealerweise jeden erdenklichen Grenzfall abdecken, Designer den riesigen Mittelbereich von 80 bis 90 %. Dabei wird es immer jemanden geben, der es nicht komplett versteht. Solange aber der Großteil der Anwender mit der Lösung gut arbeiten kann, funktioniert das Design.
Code kann perfekt sein. Design ist meist ein Kompromiss – denn Design wird von Menschen benutzt. Und ob Design in der Realität funktioniert, kann am Ende nur gemeinsam mit den Anwendern beantwortet werden.