Donnerstag, 9. November 2006
Thema: Methoden
Klassische textuelle Spezifikationen sind für viele Stakeholder nicht gut verständlich. Sie tun sich schwer, sie in ihre Problemstellung zu übersetzen.
Ein Papierprototyp mit Wireframes zeigt, wie die spätere Anwendung aussehen wird. Insbesondere für Kunden und Anwender bieten sie die Möglichkeit, die Anwendung durchzuspielen und ermöglichen ihnen, das Konzept zu prüfen.
In unseren Projekten setzten wir die Wireframes ursprünglich lediglich als Präzisierung einer vorhandenen funktionalen Spezifikation sowie zur Usability-Konzeption ein.
Inzwischen nutzen wir Wireframes in der frühen Konzeptionsphase um das Konzept von Stakeholdern prüfen zu lassen. Use-Cases werden durch Abfolgen von Wireframes beschrieben. Der Konzepter spielt Anwendungsfälle mit den Stakeholdern durch und beschreibt das Verhalten der Anwendung.
Die Wireframes können dabei so weit gehen, das nicht sichtbare Verhalten in Notizen zu dokumentieren und können so sogar die funktionale Spezifikation umfassen.
Ich nutze gerne textuell beschriebene Use-Case-Szenarien als strukturiertes Vorgehen, um ein Konzept zu entwerfen. Zur Kommunikation mit Kunden und Anwendern verwende ich dennoch fast ausschließlich die Wireframes. In einem Workshop lese ich Use-Cases und zeige dem Kunden die Wireframes.
Warum sind Use-Case-Szenarien so schwer verständlich? Sie beschreiben einen typischen Ablauf eines Anwenders in seiner Sprache. Von allen textuellen Spezifikationen finde ich Use-Cases am leichtesten verständlich (siehe Artikel).
Trotzdem tun sich Stakeholder schwer! Weil die Use-Cases eine Abstraktion beschreiben, die für Stakeholder ungewohnt ist.
In unseren typischen Projekten sind Stakeholder schließlich keine erfahrenen Software-Ingenieure, sondern Anwender. Marketing-Leiter, Geschäftsprozess-Experten oder Projektleiter, die nur selten RE-Hintergrund besitzen.
Wirklich vorstellen können sich Anwender eine Applikation nur anhand eines Prototypen. Wireframes sind nah genug an der Anwendung, um als (Papier-)Prototyp den Anwendern zu vermitteln, wie die Anwendung funktioniert. Sie können dann ihren Arbeitsablauf mit der neuen Anwendung verbildlichen und Stolpersteine und Erleichterungen erkennen.
Wireframes können in unterschiedlichen Abstraktionstiefen erstellt werden (siehe Abstraktionsebenen). Ich erstelle bereits in einer Grobkonzeption Wireframes, die einen Ablauf verdeutlichen. Mit den richtigen Werkzeugen geht das sehr schnell und ich bekomme sehr schnelles Feedback von den Stakeholdern.
Ein Papierprototyp mit Wireframes zeigt, wie die spätere Anwendung aussehen wird. Insbesondere für Kunden und Anwender bieten sie die Möglichkeit, die Anwendung durchzuspielen und ermöglichen ihnen, das Konzept zu prüfen.
In unseren Projekten setzten wir die Wireframes ursprünglich lediglich als Präzisierung einer vorhandenen funktionalen Spezifikation sowie zur Usability-Konzeption ein.
Inzwischen nutzen wir Wireframes in der frühen Konzeptionsphase um das Konzept von Stakeholdern prüfen zu lassen. Use-Cases werden durch Abfolgen von Wireframes beschrieben. Der Konzepter spielt Anwendungsfälle mit den Stakeholdern durch und beschreibt das Verhalten der Anwendung.
Die Wireframes können dabei so weit gehen, das nicht sichtbare Verhalten in Notizen zu dokumentieren und können so sogar die funktionale Spezifikation umfassen.
Ich nutze gerne textuell beschriebene Use-Case-Szenarien als strukturiertes Vorgehen, um ein Konzept zu entwerfen. Zur Kommunikation mit Kunden und Anwendern verwende ich dennoch fast ausschließlich die Wireframes. In einem Workshop lese ich Use-Cases und zeige dem Kunden die Wireframes.
Warum sind Use-Case-Szenarien so schwer verständlich? Sie beschreiben einen typischen Ablauf eines Anwenders in seiner Sprache. Von allen textuellen Spezifikationen finde ich Use-Cases am leichtesten verständlich (siehe Artikel).
Trotzdem tun sich Stakeholder schwer! Weil die Use-Cases eine Abstraktion beschreiben, die für Stakeholder ungewohnt ist.
In unseren typischen Projekten sind Stakeholder schließlich keine erfahrenen Software-Ingenieure, sondern Anwender. Marketing-Leiter, Geschäftsprozess-Experten oder Projektleiter, die nur selten RE-Hintergrund besitzen.
Wirklich vorstellen können sich Anwender eine Applikation nur anhand eines Prototypen. Wireframes sind nah genug an der Anwendung, um als (Papier-)Prototyp den Anwendern zu vermitteln, wie die Anwendung funktioniert. Sie können dann ihren Arbeitsablauf mit der neuen Anwendung verbildlichen und Stolpersteine und Erleichterungen erkennen.
Wireframes können in unterschiedlichen Abstraktionstiefen erstellt werden (siehe Abstraktionsebenen). Ich erstelle bereits in einer Grobkonzeption Wireframes, die einen Ablauf verdeutlichen. Mit den richtigen Werkzeugen geht das sehr schnell und ich bekomme sehr schnelles Feedback von den Stakeholdern.
... kommentieren