Es ist nicht gerade intuitiv, aber eine Tatsache: Die Chancen stehen gut, dass alle Features, die Sie Ihrer Anwendung hinzufügen, für das Nutzererlebnis schmerzhaft sind. Jede Funktion, die im Namen der Konkurrenzfähigkeit hineingepresst wird, macht die Applikation weniger wettbewerbstauglich.
Willkommen zu den Auswirkungen der Nutzererlebnisfäule. Wenn Sie Features hinzufügen, fügen Sie auch Komplexität hinzu und verringern die Qualität des Nutzererlebnisses.
Nehmen Sie eine beliebige moderne TV-Fernbedienung und Sie sehen das Problem der Nutzererlebnisfäule sofort. Ein/Aus, Lautstärke und Senderauswahl reichen nicht mehr. Wir müssen zwischen Geräten wechseln können, wir brauchen eine Untertitelauswahl und eine Textfunktion fürs On-Screen-Editieren, Daumen hoch und Daumen runter für Ratings, Aufnehmen, Slow Motion, Rücklauf, 30-Sekunden-Rücklauf und, na ja, Sie sehen, was dabei herauskommt. Die Komplexität hört nie auf, es wird nie einfacher, und es ist nie angenehm.
Fäulnis fängt mit Version 2 an (manchmal früher)
Von Natur aus sind die meisten Anwendungen in der ersten Version wirklich einfach – eine kleine Ansammlung gut durchdachter Features. Alles passt perfekt und ist sinnvoll. Zu diesem Zeitpunkt hat die Fäulnis noch nicht eingesetzt. Alles ist neu und frisch.
Allerdings bleibt das nicht lange so. In dem Moment, in dem ein neues Feature hinzugefügt wird – eines, das im initialen Design nicht vorgesehen war –, bilden sich erste Schimmelstellen. Das ist der Moment, in dem das Design neu durchdacht werden muss und die Samen der Komplexität gesät werden.
Wenn dieses neue Feature sich in Sachen Stil und Funktion nah am Original-Set bewegt, mag die Nutzererlebnisfäule nicht sichtbar sein. Doch weil das ursprüngliche Design nachgerüstet werden muss, biegt die Anwendung zwangsläufig auf diese Straße ab.
Sobald weitere Features hinzukommen, wird es schwieriger, das Gesamtdesign kohärent und ausgewogen zu machen. Bald werden Features in Ecken gestopft, wo sie überhaupt keinen Sinn ergeben.
Das Nutzererlebnisfäule-Nutzererlebnis
Nutzer, die seit den frühen Versionen der Anwendung dabei sind, können ein paar neue Features in jedem Release in Ruhe adaptieren. Doch je mehr Features hinzukommen, desto geringer werden die Chancen, dass die User sie wollen oder brauchen. Sie geben ihr Bestes, alles zu ignorieren, für das sie keine Verwendung haben. Es sind die Features, die sie mögen, aber nur gelegentlich nutzen, die ihnen den meisten Ärger bereiten, da diese oft an unerwarteten Stellen versteckt sind. Der Frust wächst.
Das Leiden neuer Nutzer ist dramatischer. Sie kommen erst in einem fortgeschrittenen Evolutionsstadium der Anwendung hinzu und finden sich mitten in einer logischen und organisatorischen Nebelbank wieder. Sobald sie anfangen, ein konsistentes mentales Modell zusammenzutragen, geraten sie an ein Feature, das sich anscheinend aus keinem logischen Grund an dieser Stelle befindet. Es ist, als wandert man durch eine Villa und stößt in der Mitte des Bankettsaals auf ein Klo.
Organisationen und Einzelpersonen stehen Upgrades auf die neuesten Versionen immer widerwilliger gegenüber. Der Mehrwert eines neuen Releases wird durch die vergeudeten Stunden verringert, in denen wir den Umgang mit der neuen Oberfläche erlernen müssen. Womöglich lohnt es sich gar nicht, Zeit und Energie zu investieren, um dafür Features zu bekommen, die man nie nutzt.
Von innen verfaulen
Es ist nicht nur das externe Nutzererlebnis, das unter Fäulnis durch das langsame Hinzufügen von Features leidet. Der interne Code ist ebenfalls betroffen.
Jedes neue Feature stellt Anforderungen an die Architektur, die eigentlich nicht antizipiert waren. Anfangs hält ein pfiffiges Team die nötige Refaktorierung durch. Die Steigerungsrate im Hinblick auf neue Features erhöht aber den Druck auf das Team und binnen kurzer Zeit steigt auch die Belastung der Architektur.
Häufig wird ein zentrales Stück Kernfunktionalität am stärksten in Mitleidenschaft gezogen. Die Logik und die Threads werden so knorrig, dass bald niemand mehr Änderungen riskieren kann, ohne etwas Wichtiges kaputtzumachen.
All das bremst die Geschwindigkeit der künftigen Weiterentwicklung und macht selbst minimale Anpassungen zu substanziellen Herausforderungen. Die Zeiträume zwischen den Iterationen können sich von Wochen über Monate auf Jahre ausdehnen.
Herein kommt die Konkurrenz
Oft sind es die Marktführer, die am stärksten unter Nutzererlebnisfäule leiden. Sie haben das meiste Geld, um es in neue Entwicklungen zu stecken, und sie haben den größten Druck, ihre Marktposition durch neue Investitionen zu sichern.
Es ist diese Fäulnis, die Marktverschiebungen einläutet. Der Marktführer, heruntergebremst und übermäßig komplex, eröffnet einem neuen Unternehmen die Chance zum Vorpreschen. Wenn man die kleine Anzahl der Features studiert, für die sich die meisten Nutzer interessieren, und nicht auf einer riesigen Code-Basis sitzt, kann man eine vereinfachte Version implementieren, die für neue User viel einfacher ist und die der erfahreneren Nutzerschaft einen gradlinigen Übergang bietet.
Wir konnten dutzendfach beobachten, wie sich dieses Muster wiederholt hat. Microsoft Word für DOS mit gerade mal 70 Features beim Launch hat WordPerfect mit seinen 1.700 Features niedergestreckt. Nun sehen wir, wie Google Docs sich anschickt, dasselbe mit Microsoft Office zu machen. Bei den Suchmaschinen hat Google das Ruder von AltaVista übernommen. In der Welt der CRM-Systeme hat Salesforce Siebel ersetzt, die ihrerseits Oracle von den Beinen geholt hatten, die wiederum SAP am Markt letztlich eine Länge voraus gewesen waren.
Nutzererlebnisfäule erschwert nicht nur Design und Entwicklung, sie ist ein Risiko für das gesamte Unternehmen. Ohne frühzeitige und häufige Kontrolle wächst sie zu einer tickenden Zeitbombe heran, bereit hochzugehen.
Nein sagen bekämpft Fäulnis
Der beste Weg, um Nutzererlebnisfäule zu bekämpfen, besteht darin, zu allem außer den allerwichtigsten Features Nein zu sagen. Bremst man absichtlich die Produkt-Roadmap ab, um nur wirklich gut durchdachte und integrierte Erweiterungen einzubauen, hält man die Fäulnis in Schach.
Das Nein-Sagen ist immer im Werkzeugkasten eines Entwicklungsteams, aber in der Aufregung, etwas Neues zu produzieren, das Presse und Aufmerksamkeit bekommt, wird es oft übersehen. Es braucht eine Menge organisatorische Willensstärke, die Anwendung simpel zu halten.
Oft erkennt man auf Entscheidungsebene erst dann, dass man hätte Nein sagen müssen, wenn die Fäulnis über das ganze System hinweg grauenvoll sichtbar ist. Erst wenn die User über die Komplexität lamentieren und die Entwickler wichtige Änderungen nicht mehr schnell genug umsetzen können, realisieren alle das ganze Ausmaß des Problems.
Tausend Neins für jedes Ja
Organisatorische Führungsstärke ist nötig, um das Team darauf zu fokussieren, Nutzererlebnisfäule von Anfang an zu bekämpfen. In der heutigen Welt ist das nicht die Norm, aber wir erhaschen durchaus flüchtige Blicke auf Teams, die es durchziehen.
Steve Jobs sagte mal: "Man muss sorgfältig auswählen. Tatsächlich bin ich stolzer auf die Dinge, die wir nicht getan haben, als auf die, die gemacht wurden. Innovation heißt, zu tausend Dingen Nein zu sagen."
Es ist eine hohe Kunst, die richtigen Dinge zu wählen, zu denen man Ja sagt. Ein Trick ist der, die Wahl unter wirklich vielen Dingen zu haben. Zu tausend Dingen Nein zu sagen, wie Steve es fordert, bedeutet, dass Sie auch tausend Dinge haben müssen, zu denen Sie Nein sagen können.
Kluge Unternehmen verbringen jede Menge Zeit damit, Ideen auszuprobieren, wohlwissend, dass sie zu den meisten Nein sagen werden. Doch das ständige Experimentieren hilft ihnen zu verstehen, was möglich ist und was sie näher an das begehrte Ja führt, das das Nutzererlebnis dramatisch verbessern wird, ohne Fäulnis zu produzieren.
Führungsstärke, kontinuierliches Experimentieren und gewissenhafte Aufmerksamkeit auf das, was die Anwendung wirklich voranbringt, sind die Waffen, mit denen sich Nutzererlebnisfäule bekämpfen lässt.
Dieser Artikel wurde im Original am 29. Mai 2013 unter dem Titel Experience Rot
