„Meine Nutzenden sind seit Jahren die gleichen – ich kenne meine Nutzer:innen also und weiß genau was sie wollen. Wieso sollte ich also nicht einfach ein Pflichtenheft schreiben und dies dann beauftragen? Kostet es nicht viel Zeit und damit am Ende auch Geld das User Centered Design-Vorgehen zu durchlaufen?“

Leider sind Gedankengänge wie diese noch häufig an der Tagesordnung. Statt die Entwicklung von etwas Neuem, bspw. einer neuen Anwendung, in die strikt voneinander getrennten Phasen Anforderung, Entwurf, Umsetzung, Testen und Warten zu unterteilen, sollten wir den Prozess flexibler gestalten um agil handeln zu können, sobald sich Anforderungen geändert haben.

Sie fragen sich, wie Sie mitbekommen, dass sich die Anforderungen ändern? – Indem Sie die befragen, die die Anwendung tatsächlich nutzen sollen. Und zum Glück haben wir heutzutage die Möglichkeit so schnell und kostengünstig wie noch nie Feedback einholen zu können. Wieso das also nicht nutzen?

Wenn Sie sich diese Schleife sparen, erhalten Sie zwar ggf. früher eine nutzbare Anwendung, das erste Feedback der Nutzer:innen jedoch erst nachdem Sie Ihre neue Anwendung verwenden. Zu diesem Zeitpunkt führen Änderungen meist zu teuren Korrekturen oder Workarounds auf bestehende Architektur, Design und Abhängigkeiten – und am Ende zu schlechten Kompromissen. In diesem Fall haben Sie zwar kostengünstig eine technisch saubere Lösung erhalten, ob sie fachlich für die Nutzenden das Richtige ist, wissen Sie erst spät. Um die Lösung fachlich zu optimieren, müssen Sie nachträglich Zeit und Kosten einplanen und erhalten eine Lösung, die unter den späten Anpassungen aus technischer Sicht an Qualität verliert. Dies führt häufig zu einer schlechteren Wartbarkeit, was wiederum zu mehr Kosten führt.

All das spricht dafür, die neue Anwendung nicht auf Vermutungen, sondern auf echtes Feedback aufzubauen und das erhalten Sie von Ihren Nutzer:innen.