In jedem Projekt gibt es einen Prozess für den Start einer neuen Funktion: Anforderung, Abstimmung, Umsetzung, Test, Freigabe. Für ihr Ende gibt es keinen. Funktionen werden geboren und altern, aber sie sterben nicht. Sie bleiben im Menü, im Bundle, in der Wartung und in der Dokumentation, auch wenn sie seit drei Jahren niemand mehr aufgerufen hat. Guideline 2.16 verlangt, Akzeptanz und Abwanderung pro Funktion zu beobachten. Sie sagt allerdings nicht, was aus dem Ergebnis folgen soll. Genau darin liegt die interessanteste Lücke.
Die zwei Erfolgskriterien von Guideline 2.16
Veränderungen in der Nutzung: Beobachte Nutzerfeedback, Akzeptanz und Abwanderung für jede einzelne Funktion. Nutze diese Erkenntnisse als Grundlage für Aktualisierungen und künftige Releases.
Usability-Tests: Setze Usability-Tests, Messwerte echter Nutzer und Nutzerinterviews über die gesamte Produktentwicklung hinweg ein. Miss die Wirkung der gewonnenen Erkenntnisse und prüfe, ob veröffentlichte Funktionen die Bedürfnisse der Nutzer und die internen Ziele erfüllen.
Meine Einordnung
Diese Guideline ist die Fortsetzung von 2.14 mit umgekehrtem Zeitpunkt. Dort ging es darum, vor dem Bauen zu testen. Hier geht es darum, nach dem Ausliefern zu prüfen, ob die Annahmen gestimmt haben. Beides zusammen ergibt einen Kreis, und die meisten Projekte schließen ihn nie: Sie testen vorher ein bisschen und schauen hinterher gar nicht mehr hin.
Bemerkenswert ist das Wort Abwanderung. Es stammt aus der Produktwelt und wird auf Websites selten angewendet, obwohl es dort genauso passt. Die Frage lautet nicht nur „wird die Funktion benutzt“, sondern „hört jemand auf, sie zu benutzen“. Ein Rückgang ist ein Signal, und zwar ein früheres als eine Beschwerde.
Und dann steht in der Interpretation von Sustainable Web Design ein Nutzen-Hinweis, den ich für den praktischsten der ganzen Regel halte: Wenn die am häufigsten genutzten Funktionen weiter oben in der visuellen Hierarchie stehen, sinkt der Aufwand, den Nutzer für ihr Ziel treiben müssen. Das klingt nach Gestaltung und ist Datenübertragung. Wer drei Klicks statt fünf braucht, lädt zwei Seiten weniger. Bei 1 MB pro Seite und 50.000 Zielerreichungen im Jahr sind das 100 GB, die allein daran hängen, in welcher Reihenfolge die Dinge stehen.
Zum Feedback: Ich nehme jede Rückmeldung ernst und freue mich darüber. Sie ist die einzige Form von Nutzerforschung, die von selbst kommt, nichts kostet und keine Daten erhebt. Jemand hat sich die Mühe gemacht, sein Erlebnis in Worte zu fassen und mir zu schicken. Das ist ein Geschenk, und zwar eines mit Begründung, denn im Gegensatz zu jeder Statistik erklärt Feedback das Warum.
Wo ich weiter gehe
Die Guideline endet bei „als Grundlage für künftige Releases nutzen“. Das ist mir zu weich, denn es beschreibt nur eine Richtung: mehr, besser, anders. Die naheliegende zweite Konsequenz aus einer Nutzungsmessung fehlt vollständig.
Der Rückbau ist die wirksamste Nachhaltigkeitsmaßnahme in diesem Zusammenhang, weil er den gesamten Lebenszyklus einer Funktion beendet: die Auslieferung des Codes an jeden Besucher, die Wartung, die Tests, die Sicherheitsupdates, die Datenbestände, die sie erzeugt hat. Eine Funktion abzuschalten spart nicht einmalig, sondern dauerhaft.
Und weil Feedback so wertvoll ist, gehört es entsprechend behandelt. Das heißt konkret: Der Weg dorthin muss kurz sein. Ein Kontaktformular mit acht Pflichtfeldern und einer Kategorienauswahl ist keine Einladung, sondern eine Hürde. Eine sichtbare Adresse und die Bereitschaft, jede Nachricht zu beantworten, bringen mehr als jedes Umfragewerkzeug. Meine Erfahrung dabei: Wer eine Antwort bekommt, schreibt beim nächsten Mal wieder.
Dein erster Schritt heute
Du brauchst keine Produktanalytik. Du brauchst eine Liste und eine Spalte.
Und prüfe im selben Durchgang, wie viele Klicks jemand braucht, um Dich zu erreichen. Wenn es mehr als zwei sind, verlierst Du Rückmeldungen, die Du gebrauchen könntest.
Eine Funktion, die niemand nutzt, ist kein neutraler Zustand. Sie ist Verbrauch ohne Gegenleistung.
Quelle: W3C-Fassung von Guideline 2.16