Es gibt jedoch viele Fälle, wo die Spezifikationsmuster allein nicht reichen. Dies kann daran liegen, dass die Situation einfach zu komplex ist, aber auch daran, dass ein Linienvorgesetzter, der das Vokabular und die Methodik natürlich nicht beherrschen kann, eine teure Entscheidung fällen muss. Oft sollen aber auch die gewählten Vertreter der Akteure sich vorab ein Bild von ihrer zukünftigen Software machen können, um noch Einwände oder Anregungen äußern zu können - und dies möglichst ohne lange Spezifikationen durcharbeiten zu müssen. Vielleicht will sogar der Vertreter des Kunden selbst gerne mit seinen Pilotanwendern Vorschläge erarbeiten. Auch dann ist es erforderlich, mit möglichst einfachen Mitteln einen möglichst realistischen Prototypen auf den Bildschirm zaubern zu können.

Im Essay 8 von [B26] schreibt Prof. Dr. Norbert Bolz: "Das ist das >Mittelglied<, das Kant vergeblich in der Urteilskraft des Menschen suchte: Zwischen Theorie und Praxis vermittelt das Spiel mit Prototypen. Und mit Prototypen spielen heißt: laut denken. Im ernsten Spiel konvergieren Designprozess und Innovationsprozess: Eine Idee wird in Szene gesetzt." Und so wird aus trockener Arbeit auf einmal ein echtes Erlebnis!

Dafür kann schon die Erstellung eines statischen Screenshot-Prototypen beispielsweise mit Microsoft PowerPoint oder Microsoft Visio ausreichen. Dies hat dann auch den Vorteil, dass man auf evtl. vorhandene "Photos" von ähnlichen Bildschirmen zurückgreifen kann, die man nur noch ergänzen muss. Das nebenstehende Bild zeigt einen Prototyp in Visio, der zunächst aus einem Screenshot bestand (oberer Teil) und dann um eine weitere Sicht zur Diskussion und Vorabpräsentation ergänzt wurde (unterer Teil).

Gerade Visio hat sich bei mir super bewährt, denn dort kann man sich eine eigene "Schablone" erstellen, die wie eine Toolbox Standardelemente aufnimmt, die man dann durch Anklicken auswählen und sofort verwenden kann. Per Maus kann man Logos, Texte, Windows-Elemente (sehen echt aus, aber können nichts), Pfeile, Beschriftungsschildchen und viele andere spannende Dinge einfach auf die Schablone ziehen und weiter verwenden. Damit sind Entwürfe für Fenster oder Seiten wirklich in Minuten gemeinsam mit dem Kunden gebaut und schaffen ein Bild der Lage. Ein weiteres Beispiel sehen Sie auf der Seite Analysemuster.

Dynamische ("funktionierende") Prototypen können natürlich mit einem einfachen System statt der geplanten Echtumgebung (beispielsweise Access statt VB/SQL-Server) realisiert werden. Der Aufwand ist aber auf jeden Fall größer als bei einem statischen Prototyp, und in Zeiten, wo eigentlich jeder den Umgang mit Software gewohnt ist, reichen die statischen Prototypen zur Vorstellung des endgültigen Programms eigentlich schon aus. Früher, als wir noch Software für Leute entwickelt habe, die noch nie in ihrem Leben vor einem PC gesessen haben, war ein dynamischer Prototyp zwingend erforderlich.

Ein Prototyp ist kein Umweg! Zwar weiß man nach einem Projekt nicht, wie viel Zeit man durch einen Prototypen insgesamt gespart hat, aber der Vergleich zwischen ähnlichen Projekten mit und ohne Prototyp hat gezeigt, dass sich der Aufwand für den Auftraggeber bezahlt macht, vor allem, wenn man viele nur mal eben zum gemeinsamen Verständnis ans Flipchart kritzelt! Einige meiner eigenen Projekte wären ohne Prototyp gnadenlos gescheitert, weil nach der Diskussion des Prototyps die Gestaltung der Software massiv geändert wurde. Einmal wurde sogar wegen Uneinigkeit der Beteiligten über den Prototyp das ganze Projekt verworfen! Aber vielleicht lag es ja auch daran, dass elf Leute darüber diskutiert haben! Doch wie wäre das Projekt wohl abgelaufen, wenn es diesen Prototyp nicht gegeben hätte? Dies zeigt, dass man als Anbieter den Prototyp nicht nur unter dem Aspekt der gewonnenen Zeit verkaufen sollte.