Umgang mit User Stories für visuelle Anforderungen

User Stories ([glossary id=’1577′ slug=’user-story’ /]) fokussieren vor allem darauf, wie der Nutzer mit dem System interagiert und welche Funktionalitäten das System dem Anwender zur Verfügung stellt. Die visuellen Anforderungen gehen dabei etwas verloren und sind schwerer in dieser Form zu erfassen und auch zu schätzen.

Daher ist es für Projekte mit einem Schwerpunkt im Design von Vorteil die visuellen und kommunikativen Anforderungen in einem separaten Konzept zu vereinbaren und das [glossary id=’1572′ slug=’product-backlog’ /] für die eigentliche Funktionalität zu nutzen. Das bedeutet aber nicht, dass das Design keinen wertvollen Input zum Product Backlog liefern kann. Für die Schätzungen und Detaillierungen der einzelnen Features spielen die Gewerke Konzeption und Design nach wie vor eine ebenso zentrale Rolle wie die Entwicklung selbst. Lediglich der übergeordnete Styleguide, das grobe Layout und die kommunikativen Ziele und Paradigmen des Projektes werden an separater Stelle festgehalten und gepflegt.

Nicht alle Multimedia-Projekte basieren auf Features

Vom Grundsatz müssen User Stories nicht nur reine Funktionalitäten beschreiben. Jedoch passt dieses Verfahren auf Features sehr gut, während es in abstrakteren Bereichen weniger geeignet ist. So lässt sich eine Video-Produktion sicher mit User Stories beschreiben, jedoch klingen „Als Betrachter möchte ich über das Unternehmen informiert werden“ und „Als Betrachter möchte ich die Credits im Abspann sehen“ doch etwas gestelzt. Ein klassisches Storyboard funktioniert hier wahrscheinlich besser.

Daher gilt auch hier wieder: Das richtige Tool für das richtige Projekt. Auf die meisten Webprojekte und gerade auf größere Plattformen und Applikationen passt die Anforderungsanalyse und – Verwaltung mit Hilfe von Product Backlog und User Stories sehr gut, aber für kleinere und andersartige Projekte müssen vielleicht Sonderformen und gänzliche andere Tools hinzugezogen werden.

Leave A Reply

Navigate