Über die Schwächen von Wireframes

Michael von Konigi ruft in seinem Blog dazu auf, Schwächen von Wireframes zu benennen. Er legt vor und beschreibt Schwierigkeiten, die er bei der Kommunikation des Designs sieht und Probleme, die bei der Erstellung von Wireframes anfallen:

• People have to learn to read low fidelity schematics
• People sometimes expect them to demonstrate final visual design
• Components are not reusable as updatable instances
• Common behaviors have to be represented multiple times–CRUD, design pattern
• Some people expect them to be updated constantly, which is hard given the re-use issues
• They’re time consuming and therefore costly to make, as opposed to sketching

Seine Leser benennen noch weitere Schwierigkeiten, aber ein Kommentar trifft den Nagel wirklich auf den Kopf: sind Wireframes zu detailliert, schränken sie das Visual Design ein. Sind sie zu allgemein gehalten, können sie unter Umständen die dargestellten Konzepte nicht klar kommunizieren.

They can limit vision, and there is a risk of them being taken too literally as a visual representation. If they are detailed and at a high enough level of visual fidelity to make them useful for communicating design, whoever is responsible for the visual design (even if it’s the same person who created the wireframes) may feel constrained by them and tempted to make the final design look like a color version of the wireframes. But if they’re not detailed enough, they may not communicate effectively. It can be hard to find the right balance.

Michael meldet sich in den Kommentaren noch einmal selbst zu Wort und spricht das Problem an, dass statische Beschreibungen die Interaktivität von Produkten nicht vollständig abbilden können.

I think wireframes serve a purpose with specific audiences and used at specific times in design communication. They are artifacts for communicating decisions in detail. But static wireframes and storyboards are simply not quite effective enough for demonstrating interaction, which you may have read me bemoaning in the prototying article I point to above. This is why we build prototypes.

Diesem Punkt kann ich nur zum Teil zustimmen.
Ja, es ist richtig, dass man mittels Prototypen näher an das “Gefühl” des echten Produkts heran kommt. Aber zur Dokumentation der Inhalte und der Funktionalität sind sie nicht geeignet, da Prototypen immer nur Teile der Gesamtlösung abbilden können.

Welche Erfahrungen habt ihr gemacht, liebe Zielgruppe, und welche Vor- und Nachteile seht ihr?

→ What’s broken about wireframes and how can we fix them?

Similar Posts:

• Bucherscheinung: Card Sorting
• What’s Wrong with Wireframes?
• Modeling the Mobile User Experience
• Wie kommt Apple zu seinem Design?

An Twitter senden Delicious