Wireframe? Prototype? - ja was denn nun?

Der Freelancer profitiert sehr von Erfahrungswerten und Best Practices der Großen. Manchmal jedoch steht man dem Ganzen dann doch etwas fragend gegenüber. Sieht man sich beispielsweise diese hervorragende Zustammenstellung an von Peter Morville an, so stößt man auf mindestens zwei Konzepte, die sich eigentlich ziemlich ähnlich sind: Wireframes und Prototypes.

Warum diese Redundanz? Ist das wirklich redundant? Wieder einmal zwei Begriffe für annähernd ein und dasselbe? Ein Blick nach rechts und links plus der Überlegung, was man denn nun wirklich braucht und wann - im ganz normalen Projekt und als Freelancer. Zwei Konzepte unter der Lupe.

Die UX Treasure Map (ein nicht notwendig aufs Web zugeschnittenes, aber durchaus auch aufs Web anwendbare Konzept) hatte ich schon vor einigen Monaten kurz als Link vorgestellt - seither lässt sie mich nicht mehr so recht los, denn für mich ist genau diese Art von Information eine, die dazu beitragen kann, meinen Service zu verbessern. Übrigens sieht man vielleicht an jenem Artikel, dass ich damals noch etwas ratlos war, was die Frage nach dem User Experience Entwicklungsprozess betrifft.

Skizzieren

Der Wireframe. Ich muss gestehen, dass es noch nicht so lange her ist, dass Wireframes als Begrifflichkeit Einzug in mein berufliches Leben gefunden haben und ich muss außerdem gestehen, dass mir nicht so recht klar war, ob alle Welt längst Wireframes nutzt nur ich nicht. Wireframes - eine Frage der Professionalität im Webdesign?

Wireframes - das sind, so habe ich  gelernt, diese kleinen Sketches, die man ganz zu Beginn eines Projekts und noch vor dem Designentwurf macht, um einfach grob zu skizzieren, wie der Seitenaufbau einzelner Seiten einer Website werden könnte, welche Seitenelemente zum Einsatz kommen und wo man sie positionieren möchte. Ein konzeptioneller Prototyp.
Wie man vorgeht, bleibt einem eigentlich selbst überlassen. Erlaubt ist, was gefällt: Papier und Bleistift, spezialisierte Software oder auch ein Graphikprogramm. Wichtig ist: Wireframes kommen ohne irgendetwas aus, das mit Design zu tun haben könnte. Ein allererster Schritt bei der Ideenfindung.

Ich mache sowas natürlich auch. Jeder macht dise kleinen Skizzen. Schön! - möchte man also etwas provokant sagen, schön, dass wir dafür jetzt auch einen Begriff haben. Ich überlege mir, ob ich das irgendwie meinem Kunden verkaufen könnte oder überhaupt möchte und komme zu einem klaren Nein. Bei mir heißt das Skizze, wird auf Papier und neuerdings mit Balsamique gemacht und gewinnt vor allem dadurch, dass darin auch “rumgekritzelt” werden darf.  Ich bin trotz des tollen Programms Balsamique eher ein Fan der Papier und Bleistift Variante - das hat irgendwie dann schon wieder etwas Künstlerisches.

Detaillierter skizzieren?

Der Prototyp. Tja, für mich grundsätzlich eher ein Begriff aus der Softwareentwicklung. Der “Dummy”, der mit einfachsten Mitteln die rudimentären Features eines Programms zeigt. Und doch ist auch ein Wireframe ein Prototyp, wenn auch ganz anderer Art als eine funktionale oder optisch gut aufgemachte Demo einer Software. Im Webdesign - gibt es da Prototypen, die mehr sind als ein Wireframe? Und wo bringt man dann noch das innerhalb der UX Deliverables auch genannte “Design Concept” unter?

Die Antwort gibt auch Peter Morville -allerdings lässt das Ganze dann doch Fragen offen: Zwei Prototypen stellt er in seinem Artikel per Link vor. Den Papier Prototypen und den HTML Prototypen - einmal also die eher visuell, konzeptuelle Ebene, einmal die technische.  Der Papierprototyp erweitert den Wireframes, indem nun einzelne Seitenelemente aus Papier ausgeschnitten auf einem Blatt (= dem Screen) hin und hergeschoben und damit auch verschiedene Zustände des Systems Website dargestellt werden können. Gerade der Papier Prototyp erfüllt damit auch eine weitere interessante Funktion: die als . Womit ich mich eigentlich weniger anfreunden kann, ist der , das Mapping von Seitenstruktur als Draft und dem XHTML-Analogon, das einer passenden Benennung folgt.  Ist das wirklich wichtig? Macht das nicht der “gute Webentwickler” sowieso ganz selbstverständlich genau so?

Ob es weitere gibt? Ich weiß es nicht. Sobald ich an Prototyping im Webdesign bin, denke ich fälschlicherweise an Kundenkommunikation und schon bin ich da, wo mir ein Kunde ein wenig fragend gegenübersteht und nicht recht weiß, was er mit diesem halbfertigen Gebilde zwischen Rohbau und Designentwurf anfangen soll.

Interdisziplinäres Arbeiten im Team und der Allrounder

Etwas anderes wird sofort deutlich. Morvilles Deliverables, deren Abfolge und Detailtreue ich gedanklich schon des Öfteren in Frage gestellt habe, sind teilweise ein Konzept, das  im Team aus Spezialisten seine Stärke zeigt und genau dort sinnvoll ist, nämlich genau an den Schnittstellen dieser einzelnen Disziplinen. Nicht jeder dieser Schritte ist einer, der der Kommunikation mit dem Kunden dient. Vieles davon dient auch dem internen Austausch. Im One Man/One Woman Projekt werden daher einige Deliverables nicht nur zusammenfallen - sie werden verschwinden, weil eben jener interdisziplinäre Austausch zwischen Informationsarchitekt, Usability Spezialisten, Designer und Webentwickler nicht stattfindet. Den Prototyp halte ich für einen solchen Schritt.

Heißt das nun, es könne dem Freelancer vollkommen egal sein? Ein klares Nein. Jeder dieser Schritte (ja übrigens auch nur ein Vorschlag) beinhaltet wesentliche Aufgaben, die auch im Einmannprojekt zwangsläufig  irgendwann anstehen.  Es ist nicht so einfach, die Erfahrungswerte und Best Practices aus großen Unternehmen mit vielen Spezialisten und Manpower auf das Einmannszenario zu mappen - im Gegenteil halte ich es für eine große Herausforderung. Hat man sich aber man durch den Dschungel gewühlt, ist das ein Benefit. Und wenn es nur darum geht, im Eifer des Gefechts nicht an einzelnen Anforderungen vorbeizuschauen.

Ich übrigens als inzwischen eingefleischte Freelancerin, die auch im Team vor Jahren dann doch irgendwie recht eigenständig arbeiten konnte, kann mir unterdessen gar nicht vorstellen, an was es alles zu denken gibt, wenn man diesen interdisziplinären Ansatz in einem Team mit sehr abgegrenzten Verantwortlichkeiten wirklich in dieser Form strikt durchziehen möchte und muss.

 

Auch was dazu sagen?