Provozierend ruft „sacha“ aus: Stop using wireframes!
Ein Thema, das sich kontrovers diskutieren lässt. Wireframes sind in der Tat nicht immer das Architektur-Mittel der Wahl. Aber in sehr vielen Fällen sehr wohl.
Was mir immer aufstößt, sind Pauschalisierungen, ohne Kontext.
Hierzu mal zwei Äußerungen des Autors:
It doesn’t take a good designer long to whip up a Photoshop mockup, and a good coder can create a HTML prototype in a short time too. Both can be reused in the final product (which saves time), and both are much closer to the real experience than a wireframe (which helps make the right decisions).
Mag sein. Aber a) sind Wireframes immer noch schneller und b) können die richtigen Personen auch auf Basis von Wireframes die richtigen Entscheidungen treffen – zum richtigen Zeitpunkt im Prozess. Es gibt natürlich aber auch Fälle und kleinere Projekte, in denen der Wireframe schon zur Kanone gegen den Spatzen mutiert. Es kommt darauf an.
My problem with your point is that because wireframes are so easy to modify, people get obsessed with shuffling things around until they obtain a perfect wireframe, but this really doesn’t accomplish much: a perfect wireframe does not translate into a perfect site, there are just too many factors that are left aside at such an early stage.
Ein perfekter Wireframe ist natürlich keine Garantie für ein perfektes Endprodukt. Ein guter Wireframe trägt aber zu einem soliden Fundament bei. Die Angst vor Leuten, die einen Wireframe zum Anlass nehmen, Dinge immer wieder hin und her zu schubsen, liegt in einer fehlenden Prozess- und Methodenkenntniss begraben. Es kommt darauf an, wann und für wen die Wireframes in Frage kommen.
Hierzu kann ich ein Buch sehr empfehlen. Dan M. Browns „Konzeption und Dokumentation erfolgreicher Webprojekte“. Darin geht es v.a auch darum, wann, in welcher Form man Deliverables (so auch Wireframes) erstellt und wem und wann man sie präsentiert. Das Buch habe ich vor einiger Zeit hier mal vorgestellt.
Matthias Zellmer sagt:
HTML-Protypes, Designer-Mockups, etc. … hab ich alles schon ausprobiert und doch hat ein Wireframe ihnen gegenüber den entscheidenden Vorteil, dass man ihnen ansieht, dass sie nichts oder zumindest wenig mit dem späteren Layout der Website zu tun haben. Das erspart viel Zeit im Abstimmungsprozess mit dem Kunden, denn so ist es in aller Regel einfach möglich, sich auf die Inhalte und Funktionen der späteren Website-/anwendung zu konzentrieren.
7. Februar 2011 — 14:14
Anne-Kathrin sagt:
Hallo Björn,
schön wieder von dir zu lesen.
Zunächst mal gibt Matthias Kommentar den Ausschlag dafür, mal zu fragen, wo Ihr den Unterschied zwischen Mockup und Wireframe seht. Matthias fügt ein „Design-“ davor, ich habe aber den Eindruck, Mockup und Wireframe würden weitestgehend synonym verwendet.
Matthias generelles „Problem“ hätte ich auch angesprochen: Alles, was nicht allzu ausgefeilt ist, erleichtert es, in diesem Stadium eines Projekts beim Wesentlichen zu bleiben.
Allerdings sind Wireframes auch nichts für jeden Kunden. Hier wären wir dann beim Thema Service-Design innerhalb des gesamten Prozesses.
Es kann auch passieren, dass der Kunde mit einem ausgefeilten Wireframe nichts anfangen kann.
Es gibt viele Kunden, die müssen einfach von Beginn an etwas Greifbares vor Augen haben oder wissen den Aufwand hinter einer solchen „Skizze“ gar nicht zu würdigen.
Meiner Meinung nach sollte man dem auch gerecht werden.
Ich selbst habe (wie Ihr sicher auch) – und wenn nur für mich- verschiedene Skizzen in jedem Projekt, sie entstehen ja auch oft in gemeinsamer Arbeit bei Meetings (und gerade dann sind sie häufig ein richtig produktives Hilfsmittel!). Mal mehr, mal weniger ausführlich.
Die Frage ist, in wie weit eine Ausarbeitung (und damit der „Verkauf“ als „Wireframe“ innerhalb des Projekts nötig und sinnvoll ist. Ich halte das für eine individuelle Fragestellung – „es kommt halt drauf an“, wie du schon schreibst.
7. Februar 2011 — 18:33
Björn sagt:
Danke für Eure Meinungen und Ergänzungen!
Sehr wichtiger Punkt! Nicht alle Prozessergebnisse taugen auch zur Präsentation oder Besprechung mit dem Kunden. So z.B. interessieren sich auch nicht alle für Sitemaps, Content-Verzeichnisse und andere Dinge – die aber für den Prozess bzw. das Ergebnis insgesamt eine wichtige Dokumentations- und Qualitätssicherungsfunktion erfüllen.
Aber für einen selbst bzw. das Team kann der Wireframe (oder ein anderes Deliverable) wiederum ein wichtiger Schritt sein.
8. Februar 2011 — 9:54
Anne-Kathrin sagt:
Ich merk immer wieder: es ist wirklich ein Riesenunterscheid, ob man im Team oder als Freelancer arbeitet.
Im Team sind Wireframes sicher ein wertvolles Hilfsmittel, um die verschiedenen Leute und damit die verschiedenen Kompetenzen zusammenzubringen.
8. Februar 2011 — 15:42
weblarus sagt:
Eine schwierige Frage. Sind Wireframes sinnvoll oder nicht? Man sollte das sicherlich vom Projekt und vom Kunden abhängig machen. Denn nicht immer bringen Sie die erhofften Vorteile.
15. Februar 2011 — 15:44
Sascha sagt:
Eine Wireframe-Produktion kann tatsächlich sehr aufwändig werden. Sowie das Projekt etwas größer ist, lohen sich Wireframes, denke ich. Die Visualisierung einer Anwendung verhindert Missverständnisse und trägt bereits vor der eigentlichen Produktion zur Verbesserung bei. Programme wie Balsamiq Mockups erleichtern das Zeichnen.
11. März 2011 — 17:37
Torsten sagt:
Ich bin auch der Meinung, dass man bei dem Einsatz von Wireframes den Umfang des Projektes abwegen sollte.
Bei Kundenprojekten ist auch deren Maß an aktiver Mitarbeit ein wesentlicher Faktor für die Entscheidung Ja oder Nein
2. Mai 2011 — 17:19
Thomas sagt:
Ich arbeite überweigend mit Design-Mockups und überlege aktuell ob es manchmal nicht sinnvoller wäre Wireframes einzusetzen. Wenn ich weiß wo der Kunde hin will und seinen Geschmack gut treffe sind Mockups klasse, aber auch dann konzentriert man sich manchmal zu sehr auf das Optische, anstatt den Fokus auf die Inhalte zu richten. Noch schlimmer wird es, wenn ich nicht genau erkennen kann, wo der Kunde optisch hin will. Da wäre ein Wireframe in Kombination mit mehreren Moodboards vielleicht die bessere Alternative. Es kommt immer auf die Situation, aber ich werde mich definitiv wieder mal mehr dem Thema widmen.
25. Juni 2011 — 22:12
Webdesign sagt:
Sind Wireframes/Mockups nicht eher ein Hilfsmittel sich über die Struktur und den Inhalt der Website Gedanken zu machen.
Der Kunde kann sich aus meiner Erfahrung meist nur visuell orientieren er will oft erst das Design sehen, bevor er uns sagen kann, was auf der Website dargestellt werden soll.
Dabei können Mockups/Wireframes und die Begutachtung anderer Websites sehr hilfreich sein.
Als Grundlage für ein Design können diese aus meiner Erfahrung aber nur sehr grob dienen.
Als äußerst hilfreiche Grundlage für unsere Designs nutzen wir 960grid (in der Layout-Pghase, selten fürs Template), diese „Einschränkung“ bringt Struktur in den Design-Prozess und hilft schnell loszulegen.
28. Juli 2011 — 11:19