Jedes Projekt beginnt mit dem Wie. Kaum eines beginnt mit dem Ob. Wenn eine Organisation beschließt, eine App zu bauen, wird über Plattformen, Budgets und Zeitpläne gesprochen, nicht darüber, ob dieselbe Aufgabe eine Webseite erledigen könnte, die niemand installieren, aktualisieren und auf hunderttausend Geräten vorhalten muss. Guideline 5.13 stellt genau diese Frage, und sie ist damit die einzige des ganzen Standards, deren richtige Antwort „gar nicht bauen“ lauten kann. Nicht ohne Grund trägt sie das Schlagwort Elektroschrott.
Die drei Erfolgskriterien von Guideline 5.13
Nachhaltigkeitsziele der Vereinten Nationen: Stelle fest, ob das Produkt oder der Dienst zu relevanten Nachhaltigkeitszielen (SDGs) der Vereinten Nationen passt, und nimm die entsprechenden Zielvorgaben, wo zutreffend, in eine Nachhaltigkeitserklärung auf.
Bewertung der Erstellung: Bewerte anhand von Wünschbarkeit, Machbarkeit und Wirtschaftlichkeit, ob ein Produkt oder ein Dienst überhaupt benötigt wird.
Berücksichtigung von Hindernissen: Beseitige oder verringere Hindernisse, die Menschen von der Nutzung eines Produkts oder Dienstes abhalten, darunter Barrieren der Zugänglichkeit, der Technik, der Geografie und der Fairness.
Meine Einordnung
Das zweite Kriterium greift auf ein bekanntes Dreieck aus der Produktentwicklung zurück: Wünschbarkeit, Machbarkeit, Wirtschaftlichkeit. Wollen es Menschen, können wir es bauen, rechnet es sich? Beim genauen Hinsehen fällt auf, was in diesem Dreieck fehlt. Keine der drei Fragen erkundigt sich nach den Folgen. Ein Produkt kann begehrt, machbar und profitabel sein und trotzdem eine schlechte Idee. Die Guideline stellt das Dreieck deshalb unter die Überschrift der Notwendigkeit und verschiebt damit den Maßstab.
Interessant finde ich, dass die Barrierefreiheit hier auftaucht und nicht nur in den technischen Kapiteln. Der Zusammenhang ist bei genauem Hinsehen zwingend: Ein Dienst, den ein Teil der Zielgruppe nicht nutzen kann, verbraucht seine Ressourcen trotzdem vollständig. Entwicklung, Betrieb, Wartung und Datenübertragung fallen an, der Nutzen aber nur für einen Teil. Ausschluss ist damit nicht nur ein Gerechtigkeitsproblem, sondern auch ein Effizienzproblem.
Beim ersten Kriterium bin ich zwiegespalten.
Wo ich weiter gehe
Der Bezug auf die Nachhaltigkeitsziele der Vereinten Nationen ist gut gemeint und wird in der Praxis am häufigsten missbraucht.
Wichtiger als jede Zuordnung ist mir die Frage selbst, und ich stelle sie schärfer als der Standard. Nicht „brauchen wir dieses Produkt“, sondern: Was ersetzt es, und was passiert, wenn wir es nicht bauen? Diese zweite Formulierung ist unbequemer, weil sie eine Antwort erzwingt, die man aufschreiben kann.
In meiner Beratung sehe ich regelmäßig Vorhaben, bei denen diese Antwort ernüchternd ausfällt. Eine App, die dieselben Informationen zeigt wie die Website, aber zusätzlich installiert, aktualisiert und für zwei Plattformen gepflegt werden muss. Ein Portal, das eine E-Mail ersetzt. Ein Chatbot, der eine gut geschriebene Seite mit Antworten ersetzt und dafür bei jeder Anfrage Rechenleistung verbraucht, die eine statische Seite nicht braucht. In allen drei Fällen ist die digitale Lösung nicht falsch, aber sie ist teurer als die Alternative, und zwar dauerhaft.
Der Grund, warum diese Frage trotzdem selten gestellt wird, ist struktureller Natur: Niemand wird für ein Projekt gelobt, das nicht gebaut wurde. Es gibt kein Budget, keine Präsentation und keinen Erfolgsbericht für die Sache, die man gelassen hat. Deshalb reicht guter Wille hier nicht. Die Frage muss vor dem Start schriftlich beantwortet und dokumentiert werden, sonst wird sie stillschweigend übersprungen.
Und das ist am Ende nichts anderes als das Suffizienzprinzip auf Projektebene: Die sparsamste Anwendung ist die, die es nicht gibt.
Dein erster Schritt heute
Du brauchst keine Machbarkeitsstudie. Du brauchst drei Sätze vor dem nächsten Projektstart.
Heb dieses Dokument auf. Bei der nächsten Überprüfung des Produkts ist es der einzige Maßstab, an dem sich messen lässt, ob das Vorhaben gehalten hat, was es versprochen hat.
Kein Projekt wird dafür gelobt, dass es nicht gebaut wurde. Genau deshalb muss die Frage vorher gestellt und die Antwort aufgeschrieben werden.
Quelle: W3C-Fassung von Guideline 5.13