Entwicklung

Mit Design-Sprints agil entwickeln

Uhr
von Raffael Buff & Florian Nyffenegger, Business Consultants, Abraxas Informatik

Mehr denn je agieren Unternehmen heute in einem komplexen, sich schnell verändernden Umfeld. Dabei gilt es, Unsicherheiten bezüglich der Kundenbedürfnisse und der Lösungsentwicklung zu begegnen. Abraxas tut dies mit Design-Sprints gemäss der «Service Design Thinking»-Methodik.

«Service Design Thinking» ist eine Methodik und Denkhaltung, mit der die wahren Bedürfnisse, Anforderungen und Wünsche des Endkunden eines Produkts erfasst werden können. Ziel ist es, in der Schnittmenge von Machbarkeit, Wirtschaftlichkeit und effektivem Kundennutzen innovative Lösungen zu finden. Dabei werden die Anwenderinnen und Anwender von Anfang an involviert, um während der Entwicklung getätigte Annahmen zu validieren und die Aussenperspektive in die Entwicklung einflies­sen zu lassen.

Die Methodik wurde bei Abraxas etwa bei der Entwicklung eines Serviceportals für Strassenverkehrsämter angewendet. Dabei wurde ein «Design-Sprint» durchgeführt – ein systema­tisches Workshop-Format in fünf Blöcken (und im Idealfall in fünf Tagen).

Die fünf Schritte des Service Design Thinking:

  1. Am ersten Tag werden Voraussetzungen, Rahmenbedingungen, Interessen, Bedürfnisse und Umwelt der unterschiedlichen Kundengruppen zusammengetragen und validiert. Daraus wird eine User Experience Map erstellt.

  2. Auf dieser Basis werden am zweiten Tag aus den unterschiedlichen Blickwinkeln der einzelnen Workshop-Teilnehmer diverse Lösungsvarianten skizziert.

  3. In einem weiteren Workshop-Block werden die Schwerpunkte und Vorteile der individuellen Sketches zu einem Story Board zusammengetragen.

  4. Beim vierten Aufeinandertreffen wird ein einfacher Prototyp erstellt, der eine möglichst natürliche Interaktion mit der Lösung ermöglicht.

  5. Anschliessend wird der Prototyp beim Endkunden unter möglichst realen Bedingungen getestet und die Lösung im Team optimiert.

Im beschriebenen Fall sollten anwenderfreundliche Lösungsvorschläge erarbeitet werden. Dazu wurden zunächst die potenziellen Endanwender analysiert: Wer nutzt das Portal, mit welchen Erwartungen und zu welchem Zweck? Die Annahmen wurden gesammelt und nach Risiko und Wichtigkeit bewertet. Darauf aufbauend wurde ein möglicher Weg zum Ziel auf einer «Experience Map» festgehalten: Wann muss der Benutzer wo welche Schritte ausführen, um das Ziel zu erreichen?

Anhand der erarbeiteten Experience Map konnten am zweiten Tag in Gruppen die wichtigsten Seiten des Portals identifiziert und in verschiedenen Variationen skizziert werden. Daraus erarbeitete jedes Team ein eigenes Storyboard. Diese unterschieden sich trotz gleicher Ausgangslage erheblich.

Im dritten Block wurden die Storyboards diskutiert und bewertet. In jedem fanden sich dank der unterschiedlichen Expertisen der Teammitglieder gute Lösungsaspekte, die mit den anderen kombiniert, verdichtet und zu einem Solution Sketch ausgearbeitet wurden. Immer wieder ergaben sich so interessante, neue Ansätze.

Auf der Basis des zusammen erarbeiteten Solution Sketch wurde ein Prototyp erstellt. Der Umfang zur Erarbeitung des Prototyps kann dabei je nach Reifegrad des Projekts variieren. In jedem Fall geht jedoch Geschwindigkeit vor Genauigkeit: So einfach wie möglich, so umfangreich wie nötig.

In der letzten Phase wurde der Lösungsansatz mit fünf Testbenutzern getestet. Ihnen wurden Szenarien mit Aufgaben vorgelegt, die sie mit dem Prototyp lösen sollten. Dabei wurde ihr Verhalten genau beobachtet: Wie reagieren die Benutzer und wo suchen sie nach Lösungen? Was wurde verstanden und wo gab es Probleme?

Es zeigte sich: Prototyp und Services kamen generell gut an. Es machte jedoch einen grossen Unterschied, wie die Anwenderinnen und Anwender durch den Prozess geleitet wurden.

Webcode
DPF8_60587