Design für den Regelfall

Es gibt eine Regel, die ich bei der Arbeit so oft wiederhole, dass Kollegen den Satz für mich beenden könnten: Beim Software-Produktdesign entwirft man nicht für die exotischsten Fälle. Man entwirft für die häufigsten Fälle und fügt die exotischen nur hinzu, wenn sich genug Leute darüber beschweren, dass sie fehlen.

Laut ausgesprochen klingt das fast unhöflich. Irgendwo da draußen gibt es einen Nutzer mit einem wirklich ungewöhnlichen Bedürfnis, und meine Regel sagt ihm, er soll sich hinten anstellen und sich beschweren. Aber ich arbeite an HR- und Gehaltsabrechnungssoftware für Unternehmen in der gesamten Golfregion, und die Gehaltsabrechnung besteht durch und durch aus Randfällen: Mitarbeiter, die in mehreren Währungen bezahlt werden, unbezahlter Urlaub mitten im Abrechnungszeitraum, rückwirkende Gehaltsänderungen, Berechnungen zum Dienstende, die davon abhängen, wann ein Vertrag unterzeichnet wurde.

Die Falle ist, dass einen niemand jemals bittet, ein Produkt aufzublähen. Jeder exotische Fall kommt mit einem Menschen daher: ein Kunde mit einem echten Problem, ein Verkäufer mit einem Deal, der von einem fehlenden Kontrollkästchen abhängt, ein Berater mit einer starken Meinung. Jede Anfrage für sich genommen ist klein und vernünftig. Aufblähung (Bloat) entsteht, wenn man zu Hunderten von einzelnen, vernünftigen Anfragen „Ja“ sagt, ohne das Gesamtbild sorgfältig im Auge zu behalten.

Was die Nutzungsdaten sagen

Als Pendo die Feature-Nutzung bei 615 Softwareunternehmen für seinen 2019 Feature Adoption Report, analysierte, stellte es fest, dass 80% der Funktionen in einem durchschnittlichen Produkt selten oder nie genutzt werden. Pendo bezifferte diese Verschwendung auch: Schätzungsweise $29,5 Milliarden der Entwicklungsausgaben von Public-Cloud-Unternehmen fließen in Funktionen, die meistens nur ungenutzt bleiben. Vier von fünf Funktionen, entwickelt und bezahlt, warten auf Nutzer, die niemals kommen.

Microsoft hat aus seiner eigenen Telemetrie dasselbe gelernt. Vor der Entwicklung der Menüband-Oberfläche für Office 2007 maß das Team, was die Leute in Word 2003 tatsächlich taten. Von den Tausenden verfügbaren Befehlen machten die Top Fünf – Einfügen, Speichern, Kopieren, Rückgängig, Fett – rund 32% von allem aus, was die Nutzer taten. Allein das Einfügen machte über 11% der gesamten Befehlsnutzung aus, mehr als doppelt so viel wie das zweitplatzierte Speichern. Word konnte Serienbriefe, Makros und Zentraldokumente erstellen; was die Menschheit aber hauptsächlich wollte, war Strg+V.

Ich finde diese Zahlen eher klärend als deprimierend. Aus Nutzersicht ist der häufigste Fall im Grunde das Produkt, und jede Stunde, die man damit verbringt, den Long Tail zu polieren, ist eine Stunde, die man nicht damit verbringt, dafür zu sorgen, dass sich das Einfügen verzögerungsfrei anfühlt.

Beschwerden sind Daten

Die zweite Hälfte der Regel – füge die exotischen Fälle nur hinzu, wenn sich genug Leute beschweren – klingt passiv, möglicherweise arrogant. Aber wenn man über die grobe Formulierung hinwegsieht, steckt viel Wahrheit darin.

Eine Funktionsanfrage, die gestellt wird, bevor das Ding existiert, kostet den Anfragenden nichts. Eine Beschwerde bedeutet, dass jemand nach der Funktion gesucht hat, feststellte, dass sie fehlt, und es ihm wichtig genug war, es einem mitzuteilen. Beschwerden sind offenbarte Präferenzen.

Apple hat dieses Spiel öffentlich durchgespielt. Das ursprüngliche iPhone wurde 2007 ohne Kopieren und Einfügen ausgeliefert; einer der ursprünglichen Ingenieure gab später zu , dass dem Team schlichtweg die Zeit ausging, um es richtig zu machen. Die Nutzer beschwerten sich zwei Jahre lang lautstark. Als iPhone OS 3.0 es im Juni 2009 endlich lieferte, entschuldigte sich Apple nicht – sie packten Kopieren und Einfügen in einen Fernsehwerbespot. Zwei Jahre an Beschwerden hatten dem Unternehmen genau gezeigt, was die Funktion wert war und wie genau sie funktionieren musste.

Wo die Regel nicht greift

Einige Einschränkungen:

Erstens verdienen die Beweise dieselbe Skepsis wie eine Funktionsanfrage. Die berühmteste Statistik in diesem Genre – die Behauptung der Standish Group, dass 64% der Funktionen selten oder nie genutzt werden – geht auf einen Konferenzvortrag aus dem Jahr 2002 und eine Stichprobe von vier internen Anwendungen zurück, woran Mike Cohn die Leute seit Jahren erinnert. Die Pendo-Daten, die aus 615 Live-Produkten stammen, sind robuster. Aber die ehrliche Zusammenfassung ist, dass wir wissen, dass der Long Tail kaum genutzt wird, aber nicht genau, wie kaum.

Zweitens, und das ist noch wichtiger, deckt die Regel nur Annehmlichkeiten ab. Einige exotische Fälle sind Verpflichtungen: Sicherheit, Barrierefreiheit, gesetzliche Vorschriften – und bei der Gehaltsabrechnung die Richtigkeit selbst. Ein Randfall in einem Dokumenteneditor ist ein fehlender Menüpunkt; ein Randfall in einem Gehaltslauf ist ein falsch ankommendes Gehalt einer Person. Der Mitarbeiter am empfangenden Ende empfindet das nicht als exotisch. Beschwerden sind ein gutes Instrument für fehlende Annehmlichkeiten, aber nutzlos bei Schäden: Niemand sollte sich darüber beschweren müssen, dass sein Gehalt falsch berechnet wurde, bevor der Fall ernst genommen wird. Wenn ein Randfall Geld, Recht oder Sicherheit berührt, entwickelt man ihn, egal wie wenige Leute jemals darauf stoßen.

Es gibt auch eine sanftere Version desselben Punktes. Für den häufigsten Fall zu entwerfen bedeutet nicht, dass das Exotische fehlen muss, sondern nur, dass es nicht im Weg sein darf. Jakob Nielsen lehrt dies seit 1995 als schrittweise Offenlegung: Zeige die wenigen Dinge, die die meisten Leute brauchen, und lass den Rest auffindbar bleiben, ohne alle anderen zu belasten. Die erweiterten Einstellungen können existieren; sie sollten nur nicht zwischen einem Gehaltsabrechner und dem Gehaltslauf stehen.

Was ich tatsächlich tue

Hier ist also die Regel, wie ich sie lebe: Mach den häufigsten Fall schnell, offensichtlich und langweilig – langweilig so wie fließendes Wasser langweilig ist. Wenn eine exotische Anfrage eintrifft, lautet die Standardantwort „noch nicht“, aufgeschrieben statt vergessen. Wenn dieselbe Beschwerde zum dritten Mal von Leuten kommt, die uns bezahlen, ist es kein Randfall mehr; es ist alltäglich geworden und wird richtig gebaut. Und wenn es ausgeliefert wird, erzähle den Leuten davon, so wie Apple den Leuten vom Einfügen erzählt hat – denn eine Funktion, die als Reaktion auf echte Beschwerden gebaut wurde, ist die seltene Funktion, von der man bereits weiß, dass jemand sie haben will.