Wireframes und Prototypen – quo vadis?


    Artikel als Podcast (Download als MP3)
     
    Der Begriff “Wireframe” kommt aus dem Englischen und bedeutet “Drahtgitter”. Das sind Modelle, die aus dem Automobilbau bekannt sind. Aufgrund der hohen Kosten einer Fehlentwicklung wurden dort immer schon Prototypen gebaut. Aber auch die Prototypen zu bauen, verschlingt in der Autoindustrie erhebliche Kosten und ist meist ein millionenschwerer Vorgang. Also baut man die Protypen zuerst als Drahtgittermodell im Computer.

    In der Web-Entwicklung liegt Nutzen darin, dem Kunden schon vor Beginn der Entwicklung die Funktionsweise einer Applikation verständlich zu machen.

    • Die Briefings der Kunden sind sehr oft äußerst ungenau formuliert und meist unvollständig.
    • Ausführliche Lastenhefte sind zwar vollständiger, verstellen aber aufgrund ihrer Tiefe oft schon den Blick auf die Gesamtanmutung der Applikation,
    • Designentwürfe zeigen meist nur ein paar ausgewählte Seiten und vernachlässigen, wie die Elemente auf der Website funktionieren. Außerdem können auch die Designer den Kunden schön vernebeln – schöne Bilder lenken oft davon ab, dass die Applikation eigentlich nicht richtig funktioniert.

    Die Grundidee eines Wireframes ist daher einfach zu verstehen. Die Grundidee des Produkts bzw. der Website soll auf einen Blick sichtbar werden und die Bedienung erlebbar werden (das sogenannte “User Experience”)
    Wie geht man dabei vor? Man skizziert einfach die wesentlichen Elemente ohne tiefergehende Gestaltung zu verwenden (also keine Bilder, keine Farben, etc.). Das ganze sieht dann in etwa so aus wie eine Architekturskizze.
    Wireframes sind etwa seit zehn Jahren im Einsatz in der Webentwicklung. Davor wurde meistens allein mit Designentwürfen gearbeitet, um dem Kunden eine Vorstellung vom Endprodukt zu geben. Zu Beginn hat man einfach Elemente in Powerpoint oder – besser noch – in Visio gesetzt. Diese Wireframes waren noch reine 2D-Modelle – gut zum Ausdrucken und An-die-Wand-Kleben, aber schlecht, um wirklich das “User Experience” nachzuempfinden. Ein weiterer Nachteil bestand darin, dass keine unmittelbare Nutzerkollaboration möglich war – die Wireframes wurden meist in einer Kundenpräsentation “vorgeführt” – konnten aber nicht über das Web von den späteren Kunden angesehen und getestet werden.
    Bis heute wird die Möglichkeit des Online-Konzepttests übrigens selten genutzt. In einer Vorführung wagen viele in der Runde keine Kritik zu nennen – geschieht das Feedback aber anonym und online so kommen doch die meisten Argumente auf den Tisch. Letztlich profitiert das Projekt immer davon, wenn ernste Bedenken früh bekannt werden. Spätes Feedback bedeutet dagegen immer höhere Kosten.
    Seit etwa 5 Jahren haben sich zunehmend 3D-Wireframes durchgesetzt. Dabei werden die Elemente wie bei einer echten Website funktional verbunden. Das Ergebnis ist ein echter Clickdummy – oft auch schon als HTML-Prototyp. Im letzten Fall – wie etwa vom Marktführer Axure angeboten – lässt sich das Ergebnis schon im Browser ansehen.
    Wireframes sind jedoch immer Vereinfachungen. Sie sind ein Abbild eines bestimmten Status, etwa einer Website für iPads. Daher hat man eine Zeit lang verschiedene Wireframes für unterschiedliche Bildschirmgrößen entwickelt. Mit der wachsenden Zahl an Endgeräten und Bildschirmgrößen wurde dieses Unterfangen jedoch  zunehmend komplex. Daher befinden sich Wireframes seit etwa 2010 selbst in der Komplexitätsfalle. Axure und auch andere Anbieter von Wireframing-Werkzeugen haben darauf reagiert. So lassen sich in Axure mittlerweile auch responsive Websites und mobile Apps simulieren. Die Erstellung solcher “Drahtgittermodelle” ist jedoch kein Kinderspiel mehr und wird nur noch von echten Experten beherrscht.

    Building_wireframe
    Foto: “Building wireframe”. ברישיון CC BY-SA 2.5 דרך ויקישיתוף.

    Ein Ausweg aus der Komplexitätsfalle bei Web- und App-Projekten ist es, agile Entwicklungsmethoden anzuwenden. Nun werden bei einer agilen Methodik ja qua defintionem nicht alle Planungen zu Beginn ausgeführt, sondern die Anforderungen werden iterativ entwickelt. Vielleicht gibt es eine ganz grobe Vorstellung vom Funktionsumfang des Endprodukts, aber es gibt sicherlich keine detaillierte Ausarbeitung davon wie es die Wireframes anstreben. Wenn sich die Vorstellung vom Endprodukt also von Sprint zu Sprint verändert, müssten auch die Wireframes jedesmal angepasst werden. Ein nicht zu unterschätzender Aufwand, dessen Nutzen fraglich ist, weil ja schon die Einteilung in Sprints eine ausreichende Reduzierung von Komplexität darstellen sollte.
    Wozu also überhaupt noch Wireframes? Steckt das Web-Prototyping mit Wireframes also in einer Sackgasse?
    Tatsächlich fordern schon erste Entwickler, man solle ganz auf Wireframes verzichten und direkt Live-Prototypes bauen. Wie ich oben dargelegt habe, ist es tatsächlich nicht ganz abwegig, dass Wireframes einem agilen Entwicklungsansatz zuwider laufen. Wireframes müssen sich also abermals weiterentwickeln – vielleicht indem sie direkt Teil der Codebasis und damit des eigentlichen Entwicklungsspints werden, damit sie einen dauerhaften Nutzen stiften.
    Noch ist es zu früh, sich eine feste Meinung zu bilden. Daher verweise ich noch einmal explizit auf den Artikel, der mich so nachdenklich hat werden lassen:

    Wireframes are dead, long live rapid prototyping


    Titelfoto: Wireframe housewares 1, Bovey Tracey Craft Fair, Bovey Tracey, Devon, England, UK by Cory Doctorow, on Flickr

    Was machen wir daraus? Was sind Ihre Gedanken dazu?

    Ihr

    unterschrift_180-180x100

    Thomas Vehmeier

    Thomas Vehmeier ist Diplom-Volkswirt, Digital-Stratege und Plattformökonom. Online bereits seit 1993, berät er heute Konzerne und mittelständische Unternehmen bei ihrer Internet-Strategie und unterstützt im Interim-Management – zuletzt im ThinkTank des Telekom-CEO, zuvor vor allem für Franchise-Zentralen und Handelsunternehmen.
    Nach oben scrollen