Für sein wunderbares Joint-Writing-Projekt mit Joshua Porter unter dem Motto „52 weeks of UX" hat Joshua Brewer einen netten, kleinen Blog-Artikel mit dem Titel You Are Not Your User geschrieben. Wie in allen bisherigen Artikeln, die im Rahmen dieses Projekts entstanden sind, fasst er eine gängige Meinung der Usability-Experten kurz und bündig zusammen: Daraus, dass man selbst etwas versteht und bedienen kann, darf man nicht schließen, dass es den Nutzern ebenso geht.

Unter uns Usability-Experten ist die Auffassung weit verbreitet, dass die Leute, die eine Software entwickeln, keine repräsentativen Nutzer sind. Wenn wir nicht aufdecken, was unsere Nutzer von uns unterscheidet, endet es damit, dass wir komplexe und komplizierte Systeme entwickeln, mit denen ausschließlich wir selbst arbeiten können.

Meiner Meinung nach haben Joshua und diese Usability-Profis nur teilweise recht. Meistens trifft diese Aussage zu. Aber wie immer im Leben gibt es Ausnahmen. Und diese Ausnahmen sind heutzutage fast gar keine mehr.

Nehmen wir die Arbeitsmethoden bei 37signals. Sie stellen eine große Bandbreite an Produkten her: Basecamp ist ein sehr beliebtes Projektmanagement-Werkzeug. Campfire ist ein tolles Tool für Online-Diskussionen (das meine Produktivität und die meiner Kollegen dramatisch erhöht hat). Highrise ist ein wunderbares CRM-Tracking-System.

Jason Fried, Ryan Singer und das Team von 37signals vertreten eine klare Position: Sie entwickeln für sich selbst. Sie erstellen Applikationen, die sie selbst nutzen würden. Und sie sollen so funktionieren, wie das Team sie am liebsten anwenden würde.

Das dürfte so eigentlich nicht funktionieren. Wenn Joshua und andere richtig liegen, sollte 37signals keine erfolgreiche Produktpalette haben. Aber Millionen Kunden lieben diese Produkte und schwärmen ihren Freunden davon vor. Obwohl 37signals gewiss unzufriedene Kunden hat, die die Anwendungen zu kompliziert finden oder die wichtige Funktionen vermissen, haben sie immer noch ausreichend begeisterte Nutzer, die die Software profitabel machen. Wie geht das?

In seinem Artikel empfiehlt Joshua, die eigenen Nutzer mithilfe der Kerninstrumente der Usability-Forschung kennenzulernen: Interviews, Kontextbefragungen, Umfragen, Card-Sorting und User-Tests. Diese Werkzeuge ermöglichen tiefe Einblicke, mit ihrer Hilfe verstehen wir die Nutzer und erfahren, woher sie kommen und wie gut sie mit einer Anwendung umgehen können.

37signals unternimmt nichts dergleichen. Sie entwickeln aus ihrer eigenen Perspektive. Wenn sie eine neue Funktion umsetzen wollen, fragen sie sich selbst, wie sie aussehen soll. Sie brauchen keine Usability-Forschung.

Stattdessen nutzen sie unkonventionelle Methoden, um Nutzer-Feedback zu sammeln – unkonventionell jedenfalls aus Sicht eines Usability-Experten. Beispielsweise müssen alle Entwickler und Designer abwechselnd auch im Kunden-Support arbeiten. Wenn ein neues Feature ausgerollt wurde, müssen die Leute hinter dieser Funktion all die auftretenden Probleme und Fragen direkt und persönlich mit den Kunden besprechen. Das gibt ihnen ein unmittelbares Gespür dafür, wie es ist, ein User zu sein, vor allem dann, wenn das Produkt nicht so funktioniert wie diese Nutzer es gerne hätten.

Das Unternehmen betreibt zudem ein sehr aktives Diskussionsforum und einen Blog. Die 37signals-Kunden sind nicht schüchtern. Wenn sie nicht glücklich sind und sich eine Produktänderung wünschen, lassen sie es alle Welt wissen. Das Team liest dort eifrig mit und bezieht aus diesen Diskussionen Inspiration und Ideen für spätere Entwicklungen.

Mit den so zusammengetragenen Informationen und dazu ihren sehr kollaborativen Entwicklungsprozessen erstellen sie die Anwendungen, die sie so erfolgreich gemacht haben. Sie haben bewiesen, dass man tolle Ergebnisse auch hinbekommt, ohne auf die etablierten Forschungsmethoden zurückzugreifen. Tatsächlich kann man eine Software entwickeln, deren Nutzer man selbst ist, und diese dann mithilfe direkten Feedbacks weiter vorantreiben.

37signals nicht das einzige Unternehmen, das so vorgeht. Bei Apples iPhone-Strategie war es grundsätzlich genauso. Auch Apple hat keine traditionelle User-Forschung durchgeführt. Stattdessen haben sie das iPhone so entwickelt, wie sie selbst es nutzen wollten. Auch sie beobachten genau, welches Feedback über ihre Shops und Hotlines hereinkommt. Und sie lesen die Diskussionen, in denen Leute sich über Frust und fehlende Features beschweren. Aber letztlich entwickeln sie für sich selbst.

Wir nennen das Self-Design und dieses Self-Design ist eine von fünf Formen der Entscheidungsfindung bei der Anwendungsentwicklung, die wir identifiziert haben. Es ist eine wichtige Form und kann richtig angewendet sehr erfolgreich sein.

Vorteile und Nachteile des Self-Designs

Die großen Vorteile des Self-Designs sind die Faktoren Geschwindigkeit und Kosten. Die traditionelle Nutzerforschung ist zeitaufwändig und teuer, sie dauert Wochen und kostet Tausende Dollar, wenn man sie professionell durchführt. Nun, fragen Sie sich einfach selbst: „Wie würde ich es gerne nutzen?” ist sicherlich eine deutlich schnellere und günstigere Alternative.

Der größte Nachteil des Self-Designs besteht darin, dass es nur funktioniert, wenn Sie einen großen Kundenstamm haben, der wie Sie denkt. 37signals hat Millionen Kunden, die ähnlich ticken wie das Team selbst und die den Markt attraktiv machen. Die Apple-Leute haben genügend Smartphone-Nutzer gefunden, die wie sie selbst sind, um eine anständige Kerbe am Markt zu hinterlassen, obwohl ihre Marktanteile hier in den USA nach wie vor geringer als die von RIM und Nokia sind. Wenn Sie einen Markt finden, der groß genug ist, dass sich auf ihm viele Leute wie Sie selbst tummeln, wird Self-Design Sie glücklich machen. Wenn nicht, werden Sie Schiffbruch mit etwas erleiden, das nur eine handvoll Leute bedienen kann.

Ein weiterer Nachteil: Self-Design funktioniert nur, wenn die Entwickler und Designer das Produkt selbst andauernd nutzen. 37signals hat Basecamp produziert, um die eigenen Projekte zu verwalten. Ihre Software Campfire ist ihre wichtigste Kommunikationsplattform, denn sie haben Team-Mitglieder in aller Welt. Die Apple-Leute nutzen ihre Telefone jeden Tag, rund um die Uhr.

Wenn sich bei der täglichen Nutzung etwas als frustrierend herausstellt, kommt das sehr schnell an die Oberfläche. Das Team erfährt den Frust am eigenen Leib, und weil sie das Produkt kontrollieren, können sie sich sofort darauf konzentrieren, das Problem aus der Welt zu schaffen. Auch sporadisch auftretende Frustrationsquellen, die zum Beispiel auftreten können, wenn man etwas zum ersten Mal nutzt, kommen rasch zutage, weil das Team gut mit dem Support vernetzt ist, der – wenn man so will – ständig sehr günstige User-Tests durchführt, indem er den Nutzern durch die Applikation hilft.

Die Teams von Apple und 37signals wären mit Produkten, die sie nicht selbst tagein, tagaus nutzen würden, nicht so erfolgreich. Fingen sie auf einmal an, Software für die Intensivmedizin oder für Grundschullehrer zu entwickeln, ginge das wahrscheinlich schief. Da sie nicht selbst mit den Anwendungen arbeiten würden, müssten ihnen zwangsläufig auch die Frustrationsquellen entgehen. Der natürliche Flow oder die kontextuellen Nuancen wären ihnen unbekannt, ihre Anwendungen Einheitsbrei und klobig.

Selbst wenn sie die Produkte nutzten, täten sie dies auf andere Weise als die anderen User und würden möglicherweise fehlschlagen. Ein Entwickler zum Beispiel, der in der IT-Abteilung an der Erstellung von Intranet-Anwendungen beteiligt ist, wird mit Self-Design nur dann erfolgreich sein, wenn er sie für andere Entwickler in IT-Abteilungen erstellt. Wenn die Software sich an Leute im Vertrieb oder in der Produktion richten soll, wird der Ansatz wohl scheitern. Entwickler und Vertriebsmitarbeiter nutzen zwar das gleiche Tool, aber sie machen ganz unterschiedliche Sachen damit.

Self-Design funktioniert nur in den Fällen, in denen Sie der Nutzer sind und jede Menge anderer User auf genau die gleiche Art und Weise mit der Software arbeiten wie Sie. Wenn diese Konstellation auf Sie nicht zutrifft, müssen Sie sich wohl nach einer alternativen Methode der Entscheidungsfindung umsehen. Wenn sie zutrifft, sind Sie vielleicht tatsächlich Ihr eigener Nutzer, und das ist eine gute Sache.

Dieser Artikel wurde im Original am 22. Juli 2010 unter dem Titel Actually, You Might Be Your User 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.