Von Manuel Ressel | Hintergründe | 1 Reaktion

Wireframes sind tot und Prototypen die Allzwecklösung, oder?!

Es ist zwar schon länger her, dass UX Designer Neil Turner die provokante Frage aufwarf „Is wireframing dead?„, aber an Brisanz hat diese Frage nicht verloren. Webseiten, Apps und Programme werden immer dynamischer und interaktiver. Die verschiedenen Zustände über statische Wireframes dem Kunden zu kommunizieren kann schon etwas schwierig werden. Mit Rapid Prototypes kann man dynamische Inhalte und Interaktionsmöglichkeiten direkt zeigen und benutzbar machen. Wieso also nicht die guten alten Wireframes endlich in den wohl verdienten Ruhestand schicken?

Wireframe vs. Rapid Prototyping

Wireframes bilden statische Konzepte von Webseiten ab und erläutern dynamische Elemente mit textlichen Anmerkungen.

Wireframe mit Anmerkungen
Wireframe mit Anmerkungen

Prototypen hingegen können schon dynamische Elemente enthalten, die vom Nutzer bedient werden können. Im Webumfeld liegen diese Prototypen meistens im HTML-Format vor und können entweder mit Hilfe von Prototyping-Tools wie Axure oder mit HTML per Hand oder mit Dreamweaver angefertigt werden. Tools wie Axure erlauben es dem Konzepter auch ohne HTML-Kenntnisse Elemente zu dynamisieren. Aus dem Tool heraus kann ein interaktiver Prototyp in HTML gerendert werden. Der Code ist dabei nebensächlich und für die weitere Entwicklung nicht zu gebrauchen. Mit etwas HTML-Kenntnissen ist es auch möglich Prototypen direkt per Hand zu coden. Hier sind allerdings HTML-Kenntnisse notwendig. Wird ein Gridsystem eingesetzt, erleichtert dieses das Anlegen der einzelnen Bereiche. Hierbei wird allerdings etwas die Flexibilität eingeschränkt, da man auf die Vorgaben des Gridsystems beschränkt ist. Mit Hilfe von Javascript können leicht Elemente dynamisiert werden. Bibliotheken wie jQuery können hier die Arbeit erleichtern und Elemente schnell animiert werden.

Die Anforderungen an ein Projekt entscheidet über die Methodik, nicht die Laune

Der Vorteil von Prototypen liegt auf der Hand. Eine aufwendige Dokumentation entfällt. Komplexe Interaktionen müssen nicht weiter erläutert werden, sondern können direkt im Prototyp ausprobiert werden. Eine Interpretation von Aussagen und statischen Bildern ist nicht mehr notwendig, da die Funktionalität schon mit abgebildet ist. Also wieso noch auf Wireframes zurückgreifen?
Hierfür erinnere ich mich gerne an die Zeit zurück, in der Axure gerade relativ neu auf dem Markt war und wir die erste Lizenz erworben haben. Die Funktionen des Tools wurden natürlich mit Begeisterung aufgenommen und wollten in vollem Umfang getestet werden. Zufällig ergab sich auch eine schöne Optimierung eines Bereichs auf einer Firmenwebseite – Abgabe der Wireframes als Prototyp. Jawoll! Ich durfte direkt als Erster für ein Projekt die volle Funktionalität von Axure ausschöpfen – Mega-Drop-Down mit Mouse-Over-Effekt im geöffneten Mega-Drop-Down, Kontaktbox mit drei unabhängig bedienbaren Collapsibles, Slider, Verlinkungen, Ausklappmechanismen, Einblendungen, Ausblendungen usw. – das komplette Programm halt eben. Das Endergebnis war richtig schick, das muss man schon sagen. Jedes Detail, jedes dynamische Element und jede Funktion konnte schon im Prototyp direkt ausprobiert werden. Nun hört sich das alles super an, objektiv im Nachhinein betrachtet, war der Aufwand allerdings übertrieben. Nimmt man zum Beispiel die Kontaktbox, so sieht man, dass diese aus zwei Tabs besteht, zwischen denen man hin- und herschalten kann. Im ersten Tab wird ein innerer Dialog abgefangen, der mit einem Mouse-Over beantwortet werden soll. Im zweiten Tab sind drei Collapsibles enthalten und darunter nochmals zwei innere Dialoge, die per Mouse-Over beantwortet werden sollen. Die Anordnung der dynamischen Panels in Axure wurde dabei schon etwas komplexer und verschachtelter.

Kontaktformular und dazugehörigen dynamischen Panels in Axure
Kontaktformular und dazugehörigen dynamischen Panels in Axure

Dies war natürlich nicht gerade mit wenig Aufwand verbunden. Die Frage ist doch, ob ein paar erklärende Worte hier nicht wesentlich effektiver zum Ziel geführt hätten.
Die Anforderungen an ein Projekt sollten also eigentlich über die Methodik entscheiden. Für Abstimmungen mit dem Kunden hätten erläuternde Beschreibungen durchaus ausgereicht. Wäre hingegen die Projektanforderung gewesen das Konzept mit Nutzern in einem Test zu überprüfen, wäre der Mehraufwand durchaus berechtigt gewesen. Im Nutzertest könnte so die Funktionalität schon überprüft werden, ohne dass der Nutzer Vermutungen anstellen muss, wie es funktionieren könnte. Hier entfaltet sich in meinen Augen auch erst der wahre Vorteil von Prototypen.

Der Ansatz der Niehaus-Wireframes

Wireframes sind also durchaus eine gute Methode, um ein Konzept abzustimmen. Die Erstellung geht wesentlich schneller und einfacher von der Hand als die Erstellung des fertigen Designs oder eines Prototypen und die Abstimmung mit dem Kunden ist fokussiert auf den Aufbau und die inhaltliche Ausrichtung. Um diese Fokussierung noch weiter zu stärken, hat sich die Niehaus-Wireframe-Technik bewährt.

Niehaus Wireframe
Niehaus Wireframe

Bei einer Portaloptimierung war unser Arbeitsergebnis ein Niehaus-Wireframe. Interne Designer des Kunden entwickelten auf Basis der Wireframes ein Design in der Anmutung des bisherigen Designs ohne größere Abstimmungsrunden.
Oder ein Präsentationstermin bei einem anderen Kunden inklusive Geschäftsführung, Entwickler und Portalmanager. Präsentiert haben wir nicht etwa das fertige Designergebnis, sondern „nur“ ein paar „Graustufenbildchen“ die Niehaus-Wireframes. Auf Basis dieser konnten letzte Abstimmungen vollzogen werden und die Entwickler kannten die Anforderungen und konnten eine Zeiteinschätzung abgeben. Die Designs erstellten wir erst nach dem Termin und schickten diese per Mail an den Kunden ohne größere Abstimmungen vornehmen zu müssen.

Fazit

Auch wenn Webseiten immer dynamischer werden und immer skalierbarer sein müssen, heißt es nicht, dass man als Arbeitsergebnis für Abstimmungen ebenfalls einen dynamischen Prototypen verwendet. Viel mehr sollte man für jedes Projekt und jeden Kunden abwägen, wie detailliert das Arbeitsergebnis sein kann bzw. sein sollte. Ein dynamischer Prototyp kann eventuell auch die Fokussierung auf den Inhalt wieder vermindern, wenn bestimmte Animationsverhalten zum Diskussionsmittelpunkt werden und der Inhalt zur Nebensache wird. Ein Prototyp kann also auch durchaus Nachteile mit sich bringen.
Im Prinzip sind Wireframe und Prototyp im Usability-Prozess zwei verschiedene Iterationsstufen. Dieses iterative Vorgehen hat durchaus seine Begründung. Somit sollte nicht eine spätere Iterationsstufe eine vorherige ablösen. Vielmehr sollten die Techniken für sich weiterentwickelt werden, so dass der Fokus auf den Ergebnissen liegt, die man mit der jeweiligen Iteration erreichen möchte. So schafft es die Weiterentwicklung der Wireframes mit dem Graustufenmodell von Sandra Niehaus einen wirklichen Mehrwert für die Arbeit mit Wireframes zur Abstimmung von Konzepten.

weitere Quellen:

Manuel Ressel

Manuel Ressel ist Head of UX Design bei konversionsKRAFT. Seine Leidenschaft gilt dem Thema der Emotionalisierung von Kauf-Prozessen in E-Commerce-Portalen. Manuel Ressel ist unentwegt auf der Suche nach einzigartigen Shop-Perlen und neuen Design Trends im E-Commerce und sammelt diese in dem E-Commerce Showcase conversiondesign.de. Folgen Sie ihm auf Twitter, Google+ oder Facebook.
Frage zum Artikel? Frag den Autor

1 Reaktion auf „Wireframes sind tot und Prototypen die Allzwecklösung, oder?!

  1. von Marcel Zimmermann

    Toller Artikel! Insbesondere den Punkt „Aufgabenangemessenheit“ finde ich beim Prototyping besonders wichtig. In der Tat verführen grade die neuen Möglichkeiten bei Axure6 auch in die letzte Interaktion zu gehen. Hier hat man schnell das Problem das jede Änderung wiederum sehr viel Aufwand bedeuten kann. Den eigentlichen Vorteil der Axure bringt (oder auch andere Software in der Richtung) – nämlich das man „schnell“ einen Prototypen baut – hat man so schnell zu nichte gemacht.
    Nichts desto trotz ist für mich die Arbeit mit dynamischen Wireframes unerläßlich geworden. Ich habe das mal auf einer Konferenz unter dem Namen „Wireflow“ kennengelernt. Das ist schlicht so als würdest du im Detailgrad deines Niehaus-Wireframes die Elemente in Axure mit Links versehen. Somit kann die Seite ab dem ersten Moment auf z.B. relevante Usecases geprüft werden.

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.