Eine viel zitierte Untersuchung aus der Softwareentwicklung kommt zu dem Ergebnis, dass rund 45 Prozent aller gebauten Funktionen nie verwendet werden und weitere knapp 20 Prozent nur selten. Diese Zahl ist alt und methodisch angreifbar, aber jeder, der lange genug Projekte begleitet, erkennt die Größenordnung wieder. Und im Web hat sie eine physische Konsequenz: Eine nie genutzte Funktion verschwindet nicht. Sie liegt im JavaScript-Bundle, das bei jedem Seitenaufruf ausgeliefert, geparst und ausgeführt wird. Sie wird gewartet, getestet, migriert und gesichert. Wer 200 KB ungenutztes JavaScript an eine Million Besucher ausliefert, überträgt 200 GB für nichts. Deshalb steht eine Guideline über Nutzerforschung in einem Nachhaltigkeitsstandard.
Das einzige Erfolgskriterium von Guideline 2.2 (meine Übersetzung des Ori
Zielgruppen-Bewertung: Bestimme die primären und sekundären Nutzer sowie die betroffenen Gemeinschaften des Projekts. Nutze Recherche, Tests, Analytics und Auswertungen, um ihre Bedürfnisse und die Auswirkungen des Projekts auf sie zu verstehen. Beziehe die Nutzer während des gesamten Projekts ein.
Meine Einordnung
Der Leitsatz der Guideline ist knapp: Nutzer und betroffene Gemeinschaften identifizieren, beteiligen und ihre Bedürfnisse erforschen. Drei Wörter darin lohnen genaueres Hinsehen.
„Sekundäre Nutzer“ ist das erste. Bei den meisten Websites denkt man an die Kundschaft. Tatsächlich greifen auf jede öffentliche Seite auch Suchmaschinen-Crawler, KI-Bots, Screenreader, Preisvergleiche und Monitoring-Dienste zu. In meiner Beratung sehe ich regelmäßig Websites, bei denen der Anteil automatisierter Zugriffe den menschlichen übersteigt. Wer seine Zielgruppen definiert, ohne diese Gruppe zu berücksichtigen, plant an einem erheblichen Teil des tatsächlichen Datenverkehrs vorbei.
„Betroffene Gemeinschaften“ ist das zweite. Das klingt nach Sozialrhetorik, hat aber eine harte technische Seite. Betroffen ist auch, wer mit einem fünf Jahre alten Android-Telefon im Funkloch auf Deine Seite kommt. Entwickelt wird dagegen fast immer auf einem schnellen Rechner im Glasfasernetz. Diese Lücke ist der Hauptgrund, warum durchschnittliche Seiten heute mehrere Megabyte wiegen: Niemandem im Projektteam ist es aufgefallen, weil es bei niemandem im Projektteam langsam war.
„Während des gesamten Projekts“ ist das dritte. Nutzerforschung wird typischerweise einmal am Anfang gemacht, dann verschwindet sie in einer Persona-Präsentation. Die Guideline verlangt Beteiligung als laufenden Prozess. Das ist unbequem, aber es ist der einzige Weg, Funktionen wieder loszuwerden, statt immer nur welche hinzuzufügen.
Wo ich weiter gehe
Auffällig ist, dass die Guideline „Analytics“ als Forschungsmethode nennt. Hier widerspreche ich, oder besser: Ich präzisiere.
Analytics beantwortet die Frage „was ist passiert“. Es beantwortet nie die Frage „warum“. Ein Tracking-Werkzeug zeigt Dir, dass 70 Prozent der Besucher das Formular abbrechen. Es sagt Dir nicht, dass sie abbrechen, weil sie die Telefonnummer nicht angeben wollen. Fünf ehrliche Gespräche mit echten Nutzern liefern regelmäßig mehr verwertbare Erkenntnis als ein Jahr Klickdaten.
Und das ist der Punkt, an dem Datensparsamkeit und Erkenntnisgewinn zusammenfallen statt sich zu widersprechen.
Meine Reihenfolge sieht deshalb anders aus als die der Guideline: erst fragen, dann messen. Qualitative Forschung braucht kaum Daten und liefert Bedürfnisse. Quantitative Messung braucht viele Daten und liefert Bestätigung. Wer mit dem Messen anfängt, optimiert einen Prozess, den vielleicht niemand haben wollte.
Und die eigentliche Nachhaltigkeitswirkung liegt ohnehin nicht im Optimieren, sondern im Weglassen. Jede Funktion, die nach einem Gespräch nicht gebaut wird, spart nicht nur ihre Entwicklung, sondern ihren gesamten Lebenszyklus: Datenübertragung, Wartung, Tests, Backups, Migration. Effizienz optimiert das Vorhandene. Suffizienz verhindert, dass es entsteht.
Dein erster Schritt heute
Du brauchst kein Forschungsbudget. Du brauchst fünf Telefonate.
Ergänze das um einen Realitätstest: Ruf Deine Seite einmal auf einem alten Telefon mit gedrosselter Verbindung auf. Diese fünf Minuten verändern Prioritäten zuverlässiger als jede Roadmap-Diskussion.
Die nachhaltigste Funktion ist die, die nie gebaut wurde, weil vorher jemand gefragt hat.
Quelle: W3C-Fassung von Guideline 2.2