Universell, menschlich, sauber. Nützlich, schnell, einfach. Dies sind Usability- und Design-Prinzipien, die ersten drei hat sich das Facebook-Team auf die Fahnen geschrieben, die anderen drei Googles UX-Team. Sie sind gut. Diese Qualitäten sollte man zweifellos anstreben. Denn wer wäre nicht darauf aus, eine saubere und übersichtliche Anwendung zu schaffen?
Trotzdem bin ich nicht der Ansicht, dass es sich um wirklich großartige Prinzipien handelt. Großartige Prinzipien helfen Entwicklungsteams, mehr über ihre Anwendungen zu lernen und bei schwierigen Entscheidungen die richtigen Antworten zu finden.
Sehen wir uns im Gegensatz dazu dieses Prinzip des Desktop-Design-Teams von Windows 7 an: Reduce concepts to increase confidence. Wenn man diesem Prinzip folgt, kann sich das Team also eine Skizze vornehmen und fragen: „Führen wir irgendwelche neuen Konzepte ein? Wenn ja: Warum? Ist das notwendig?“ Falls zwei alternative Ansätze vorliegen, müssen die Beteiligten sich ansehen, wann weniger Neues nötig ist, damit der Nutzer seine gewünschte Aktion ausführen kann.
Kürzlich haben wir uns mit ein paar anderen Teams zusammengesetzt, um tolle Usability- und Design-Prinzipien für die Anwendungsentwicklung zusammenzutragen. Dabei herausgekommen ist eine Liste mit Leitsätzen, die den beteiligten Teams helfen können, wichtige Entscheidungen zu treffen. Diese Leitsätze kommen immer wieder auf die Tagesordnung: in Ideendiskussionen, in den Review-Meetings, in Kritikrunden.
Jedes Mal, wenn die Sprache wieder auf diese Leitsätze kommt, gibt es Diskussionen: "Was bezeichnen wir eigentlich als neues Konzept?" Die Suche nach der Antwort macht uns alle klüger. Auf diese Weise entsteht eine gemeinsame Basis, eine Grundlage, auf der das Team die Grenzen seiner Prinzipien auskundschaften kann.
Herausfinden, was tolle Usability- und Design-Prinzipien ausmacht
Im Rahmen unserer Forschung über die Entwicklung großartiger Nutzererlebnisse fanden wir heraus, dass solche Prinzipien eine wirklich wichtige Rolle spielen können. Jedoch fielen die meisten dieser Prinzipien schnell durch das Raster, weil sie zu sehr Friede, Freude, Eierkuchen waren, das Blaue vom Himmel versprachen.
Als wir mit den Teams sprachen, die am meisten aus ihren Prinzipien herausholen, stellten wir fest, dass diese ihre Prinzipien ausführlicher und spezifischer formuliert hatten, statt einfach ein Attribut wie innovativ in den Raum zu stellen.
Sie beschäftigten sich präzise mit den Dingen, die diesen Entwurf anders machen würden und besser als alles, was die Konkurrenz je produziert hatte. Sie sprachen von der Gesamtheit der Dinge, die das anstehende Release so anders und vor allem besser als alles machen würde, was die Konkurrenz je auf den Markt gebracht hat.
Auf den ersten Blick scheint diese Vorstellung von Grundprinzipien eine nicht intuitive zu sein, nicht diese allumfassende Idee vom richtigen Weg zu einem tollen Produkt. Doch davon abgesehen: Die Prinzipien erfolgreicher Teams beziehen sich darauf, woran hier und jetzt gearbeitet wird. Deshalb spielen sie auch eine so große Rolle bei der konkreten Formulierung des gewünschten Look & Feel und des angestrebten Nutzererlebnisses. Genau das sollen Prinzipien leisten.
Unseren Austausch mit anderen Teams können wir in Form sechs kleiner Tests zusammenfassen. Wenn ein Prinzip alle sechs Tests besteht, handelt es sich wirklich um ein großartiges, das uns dabei helfen wird, hervorragende Nutzererlebnisse zu schaffen.
Test #1: Basiert das Prinzip auf Nutzerforschung?
Das Desktop-Entwicklungsteam von Windows 7 hat eine Menge Zeit in nutzerbasierte Tests der Vorgängerversion Windows Vista investiert und so festgestellt, woher die Frustration der Nutzer kommt. Die Prinzipien des Windows-7-Teams basieren unmittelbar auf diesen Erkenntnissen.
Jedes Teammitglied sollte an jedem Finger nicht nur ein Beispiel, sondern einen ganzen Haufen Beispiele dafür aufzählen können, wie das eigene Design oder das der Konkurrenz gegen diese Prinzipien verstößt. Befolgen wir die Prinzipien dann konsequent, wird es uns gelingen, bessere Nutzererlebnisse zu schaffen.
Damit das funktioniert, muss jeder im Team den gleichen Background haben. Erfahrungen mit Nutzerforschung aus erster Hand sind am besten. Solange es noch Diskussionen darüber gibt, ob ein bestehendes Design den Kriterien, die sich aus den Prinzipien ergeben, entspricht oder nicht, sind die Prinzipien noch nicht klar genug umrissen.
Test #2: Hilft das Prinzip, meistens "Nein" zu sagen?
Es ist leicht, gute Designs von schlechten zu unterscheiden. Ein tolles Prinzip hilft dabei, ein großartiges von einem guten Design zu unterscheiden. Ein guter Entwurf kann okay sein, aber er ist nicht großartig, wenn er nicht diesem Prinzip folgt.
Nehmen wir noch ein Prinzip des Microsoft-7-Teams: UX before knobs and questions – die Usability soll schon gut sein, bevor dem Nutzer Fragen gestellt werden und er Konfigurationen vornimmt. Dieses Prinzip anwendend, könnte das Team ein neues Feature diskutieren und fragen: „Ist eine Konfiguration erforderlich, damit es seinen Nutzen entfalten kann?“ Oder: „Stellen wir Fragen, auf die wir bereits Antworten haben?“ Prototypen, bei denen die Konfiguration vor einem großartigen Nutzererlebnis steht, können wir verwerfen, auch wenn sie möglicherweise sauber, einfach und nützlich sind.
Als Faustregel sollte ein gutes Prinzip dazu führen, dass wir zwei Drittel unserer Entwürfe noch einmal überdenken. Sagen wir uns immer wieder: „Das ist noch nicht fertig gebacken. Arbeiten wir weiter dran.“ Das ist der schmale Grat zwischen gut und großartig.
Test #3: Führt das Prinzip zu einem Alleinstellungsmerkmal?
Das Windows-Phone-Team folgt in Sachen Usability und Design dem Prinzip Typografie zelebrieren. Mit seiner Metro Design Language will Microsoft zum Schlag gegen das Blackberry and sogar das iPhone ausholen und Themen ansprechen, die bei den Konkurrenten zu kurz kommen, weil sie anderen Prinzipien folgen.
Unser Team sollte ein Verständnis dafür entwickeln, wie Wettbewerber Prinzipien anwenden, die sich von unseren eigenen unterscheiden. Einfache Bedienung ist kein Merkmal, mit dem man aus der Masse hervorsticht. Konzentration auf Optimierung statt auf neue Features dagegen ist schon eher ein Unterscheidungsmerkmal zu einem Mitbewerber, der die Herzen und Köpfe der Kunden mithilfe neuer Funktionen erobern will, selbst wenn die bestehende Plattform verworren und voller Bugs ist.
Test #4: Ist es etwas, das in einem späteren Release vielleicht wieder rückgängig gemacht wird?
Wir sind einem Team begegnet, das herausgefunden hatte, dass die Komplexität der Navigation die Nutzer überforderte. Bei der Arbeit am nächsten Release verschrieb es sich dem Prinzip Auffindbarkeit vor Vollständigkeit. Sie wollten sicherstellen, dass ihre Nutzer die wichtigsten Funktionen leicht finden. Selten genutzte Funktionen sollten aus der Navigation entfernt werden.
Allerdings konnten sie sich ein zukünftiges Projekt vorstellen, in dem Vollständigkeit wiederum wichtiger sein würde als Auffindbarkeit. Bei einer Oberfläche für gut ausgebildete Administratoren könnte der einfache Zugang zu jeder Funktion der Schlüssel zum Erfolg sein.
Gute Prinzipien sind keine auf ewig geltenden Gebote. Sie sind nur hier und heute nützlich. Indem wir darüber nachdenken, was es bedeuten würde, bestimmte Dinge später wieder rückgängig zu machen, finden wir heraus, welchen Nutzen die Prinzipien aktuell haben.
Test #5: Passt das Prinzip zu diesem Projekt?
Wenn wir ein neues (Teil-)Projekt beginnen, sollten wir uns die Ergebnisse der Nutzerforschung, die Konkurrenten und den Markt anschauen, um zu sehen, ob das Prinzip noch Gültigkeit besitzt. Dies sollte das erste Gesprächsthema sein, wenn sich ein neues Vorhaben anbahnt.
Es ist sehr wahrscheinlich, dass verschiedene Teams, die gleichzeitig an unterschiedlichen Aspekten eines Release arbeiten, jeweils eigenen Prinzipien folgen. Bei der Entwicklung eines medizinischen Office-Management-Systems arbeitet beispielsweise das Team, das sich mit dem Kalender für die Terminvereinbarungen befasst, nach anderen Prinzipien als das Team, das die Abrechnungsfunktion umsetzt.
Diese Teams sollten ihre Prinzipien miteinander diskutieren, um diejenigen zu identifizieren, die von beiden angewendet werden können. Andererseits ist es hier auch nicht problematisch, teilweise unterschiedliche Prinzipien zu vertreten. Letztendlich müssen an die beiden gerade genannten Projekte wahrscheinlich ganz unterschiedliche Erfolgsmaßstäbe angelegt werden.
Im Projektverlauf werden neue Prinzipien hinzukommen und müssen andere eingemottet werden. Mit der Zeit kann das Team den eigenen Fortschritt auch daran messen, dass es die Änderungen an den Prinzipien analysiert.
Test #6: Wird das Prinzip ständig auf den Prüfstand gestellt?
Als Reaktion auf das überwältigende Feedback zur völlig verbugten aktuellen Version der Software hatte sich ein Team, das wir kennengelernt haben, das Kernprinzip Optimierungen vor neuen Features auf die Fahnen geschrieben. Bei den Arbeiten am nächsten Release kam es dann schnell zu Diskussionen darüber, was unter Optimierung eigentlich zu verstehen sei. Gehören auch Änderungen dazu, die keine Bugs betreffen? Farben? Fonts? Weißraum?
Prinzipien beginnen oft einfach mit einer Definition im Sinne von Wenn wir’s sehen, wissen wir’s. Wir können schnell erklären, ob etwas rundum oder überhaupt nicht optimiert wurde. Wir müssen beide Extreme verstehen und erkennen, wann wir dem Prinzip gefolgt sind und wann wir noch einmal Hand anlegen müssen.
Diese Diskussionen sind gesund für Teams, besonders dann, wenn sie über tatsächlich vorhandene Entwürfe und Skizzen sprechen. So entsteht im Team ein grundsätzliches Verständnis der angestrebten Ziele. Wenn alle sich zu diesen Zielen und den dahinter stehenden Prinzipien äußern und sie diskutieren, verstehen die Beteiligten auch, was gutes Design im anstehenden Release wirklich bedeutet.
Die meisten Prinzipien versagen in mehreren Tests
Wenn Ihr Team bereits versucht hat, eigene Prinzipien zusammenzustellen, stehen die Chancen gut, dass diese in einigen dieser Tests versagen. Wir selbst können wahrlich ein Lied davon singen! Aber verzweifeln Sie nicht, sondern tauschen Sie sich im Team aus. Prinzipien ändern sich mit dem Blick auf das Projekt. Haben Sie keine Angst, Ihre Prinzipien zu etwas werden zu lassen, das Ihr Team dahin bringt, Nutzererlebnisse zu schaffen, für die Ihre Kunden dankbar sein werden.
Dieser Artikel wurde im Original am 1. März 2011 unter dem Titel Creating Great Design Principles: 6 Counter-intuitive Tests von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.
