Iterative Portalentwicklung mit kontinuierlichem Nutzendenfeedback

Werden Rückmeldungen von Nutzenden erst spät eingeholt, laufen digitale Portale Gefahr, an den Bedürfnissen der Zielgruppe vorbeientwickelt zu werden. Fehlannahmen werden dann oft erst erkannt, wenn Korrekturen bereits aufwändig sind. Das kann insbesondere für kleine Projektteams zu einer großen Herausforderung werden.

Es erwies sich als hilfreich, das Portal in klar abgegrenzten Reifegraden zu entwickeln (im Fall von DACHS: Prototyp, Alpha, Beta und finale Version). Nach jedem Meilenstein wird die jeweilige Version mit der Zielgruppe in strukturierten Testszenarien evaluiert. Die gesammelten Rückmeldungen werden priorisiert und gezielt in die Planung der nächsten Entwicklungsstufe integriert. Auf diese Weise entsteht ein iterativer Zyklus aus Entwickeln, Testen, Auswerten und Anpassen, der es ermöglicht, Fehlentwicklungen frühzeitig zu erkennen, Ressourcen gezielt einzusetzen und das Portal schrittweise an die tatsächlichen Bedürfnisse der Zielgruppe anzupassen. Dieses Vorgehen erweist sich als effizienter sowie ressourcenorientierter als das fertige Produkt erst am Ende der Entwicklung zu evaluieren.

Diese Vorgehensweise wurde im Rahmen der dreijährigen Entwicklung des DACHS-Portals angewendet. Das Projekt wurde von einem kleinen, interdisziplinären Team umgesetzt, welches Entwicklung, Projektmanagement und inhaltliche Konzeption gemeinsam verantwortete. Getestet wurde mit Lehrenden als Zielgruppe des fertigen Portals.

Für dieses Vorgehen braucht es

1. Kontinuierlichen Zugang zu Personen aus der Zielgruppe, die bereit sind, Zwischenversionen zu testen und Feedback zu geben;

2. ausreichend zeitlichen Puffer im Projektplan, um auf Feedback reagieren und Anpassungen vornehmen zu können – statt einem starren Entwicklungsplan zu folgen;

3. im Team die Bereitschaft, Zwischenergebnisse kritisch hinterfragen zu lassen und bereits Entwickeltes ggf. zu verwerfen oder anzupassen;

4. eine Möglichkeit, Feedback strukturiert zu erfassen und auszuwerten.

Dieses Vorgehen eignet sich besonders für Projekte, die

• ein digitales Produkt mit einer klar definierten, erreichbaren Nutzendengruppe entwickeln,

• ausreichend Projektlaufzeit für die geplanten Entwicklungs- und Testzyklen haben (bei DACHS z. B. drei Jahre), und

• wiederholten Zugang zu Testnutzenden haben.

Weniger geeignet ist der Ansatz bei sehr kurzer Projektlaufzeit oder fehlendem Zugang zu Testnutzenden.

• ein digitales Produkt mit einer klar definierten, erreichbaren Nutzendengruppe entwickeln,

• ausreichend Projektlaufzeit für die geplanten Entwicklungs- und Testzyklen haben (bei DACHS z. B. drei Jahre), und

• wiederholten Zugang zu Testnutzenden haben.

Erwartungsgemäß führte das kontinuierliche Feedback zu einer spürbar höheren Nutzendenfreundlichkeit und Passgenauigkeit des Portals für die Zielgruppe. Unerwartet war, wie unterschiedlich die Testpersonen die vier Portalbereiche bewerteten: Je nach persönlichem Bedarf empfanden sie jeweils andere Bereiche als besonders nützlich. Wiederum stellte sich heraus, dass der Portalbereich „Simulieren“ besonders positiv bei der Zielgruppe ankam.

Als Kehrseite zeigte sich, dass die wiederholten Testrunden mehr Organisations- und Zeitaufwand erforderten als ursprünglich eingeplant, insbesondere für Terminfindung, Auswertung und Kommunikation der Ergebnisse. Wichtig in diesem Zusammenhang ist die Eingrenzung des Testzeitraums auf kurze Perioden. Feedback kann somit zeitnah eingeholt und schnell umgesetzt werden.

Frühes, ehrliches Feedback erwies sich retrospektiv als wertvoller als ein möglichst perfekt wirkender erster Entwurf – auch unfertige Prototypen liefern wichtige Erkenntnisse. Zudem hat sich gezeigt, dass eine feste, jedoch nicht zu kleine Testgruppe hilfreich ist. Während zu wenige Personen kein belastbares Bild liefern, erschweren zu viele Proband*innen, speziell in Projekten mit geringen zeitlichen sowie personellen Ressourcen, die Auswertung. Wichtig war außerdem, Feedback nicht nur zu sammeln, sondern sichtbar in Entscheidungen einfließen zu lassen und dies auch an die Testenden zurückzuspiegeln – das erhöhte die Motivation, erneut mitzuwirken.

Tipp: Die Einbindung von Expert*innen zum jeweiligen projektbezogenen Fachgebiet wird ausdrücklich empfohlen. Somit wird Nutzendenerfahrung mit Expertenwissen kombiniert und ein umfassendes Ergebnis erzielt.

Rückblickend könnte man erwägen, statt vier festen Reifegraden (Prototyp, Alpha, Beta, Final) mit kürzeren, aber häufigeren Testzyklen zu arbeiten, etwa im Sinne agiler Sprints mit kleineren Nutzendentests alle paar Wochen. Das würde Feedback noch enger an die Entwicklung koppeln und Fehlentwicklungen noch früher sichtbar machen. Für Projekte mit weniger Ressourcen kann dies allerdings zu viel Koordinationsaufwand bedeuten – hier ist das beschriebene Vorgehen mit einer geringen Anzahl an klar abgegrenzten Reifegraden oft der praktikablere Kompromiss.

Beginnen Sie mit einem realistischen Zeitplan, der Test- und Auswertungsphasen fest einplant. Definieren Sie vorab klare Kriterien, wann eine Version fertig genug für die nächste Testrunde ist. Hierbei ist gute Planung zwar wichtig, jedoch sollten Sie sich nicht übermäßig lange mit perfektionistischen Ansprüchen aufhalten. Bauen Sie sich frühzeitig einen verlässlichen Pool an Testpersonen aus der Zielgruppe auf und pflegen Sie den Kontakt auch zwischen den Testrunden – tun sie dies möglichst niedrigschwellig. Dokumentieren Sie Feedback und daraus resultierende Entscheidungen zentral und nachvollziehbar, damit auch bei Teamwechseln nichts verloren geht.

Der iterative Ansatz hat sich für das Projekt DACHS bewährt und lässt sich unabhängig vom Thema auf viele digitale Toolentwicklungen übertragen – entscheidend ist weniger das konkrete Thema als die Bereitschaft, Nutzende von Anfang an aktiv einzubeziehen.