Clive Howard beschreibt in seinem Artikel Schritte, die in seinen Augen zu guten Wireframes führen:
- Be Clear About Your Objective
- Make it Functional, Not Pretty
- Draw on Your Experience
- Decide Who’s in Charge?
- Involve Everyone
- Set a Deadline for Completing the Wireframe
- Keep it clean
- Avoid Designing Your Wireframe Too Much
- Remember that UI is not UX
- Think About the User
- Don’t Get Lazy
- Organise Your Wireframe into Sections
- Number Your Pages
- Look for Repetition
- Check it all Makes Sense
- Ads are Functional
- It’s Not Just the Public Site
- Know When to Stop
- Choose the Right Tools
- Consider Dependencies
Neben dem Artikel selbst, sind auch die Kommentare sehr lesenswert.
Hier die interessantesten Kommentare und Anmerkungen..
Einige Kommentatoren kritisieren, dass Clive Wireframes sehr auf das Beschreiben von Funktionalität reduziert. UX und Design seien Faktoren, die sehr wohl beim Erstellen von Wireframes zu beachten sind – Punkte, die ich nur unterstreichen kann.
As a Designer, Developer, UI & UX guy, I am really having trouble either making the distinction you make in regard to design, or understanding how you can not include design during this phase. Good design can make or break the ease of use of a web form. Good design can take a three-page-long web form and turn it into a pleasing and non-overwhelming three step AJAX wizard. Would you not comp these things up as part of the wireframe?
I’m not sure I entirely agree with the point about leaving out the UX. In these days of more advanced web apps that utilise Ajax or other rich interface technologies, I think it would be a mistake to completely leave out the UX side of things. This can often be the difference between something that’s really compelling and something that’s not.
Hier noch ein Kommentar, der den Zusammenhang zwischen Wireframes und einer funktionalen Spezifikation betrachtet:
What I miss in your article is the relation with a functional design: you identify the functionality and place it in context in the wireframes, but imho you have to describe it in detail in a functional design. This way you will come across a lot of ‘minor’ details which might not be so minor after all.
Ausserdem schlagen die Kommentatoren weitere Schritte vor:
- Try alternatives. One way to do that would be have two teams work independently, or doing a second screen resolution (for mobile) with different starting conditions.
- Test your wireframes for two or three different user paths: home page down, landing page sidewards and detail page up. They will have different requirements for navigation and content.
- Keep testing the integrity and flow as a part of the development cycle, and not just a one-time blueprint.
- Decide who the intended audience is for the wireframe – is it an internal workproduct to be handed off to design & dev, or a or a communication/sign-off specification to be presented to clients, etc.
- Consider what role the wireframe document has in your workflow. Some places use it as a convenient “bible”, making it the authoritative repository for final text copy too. Thus editorial and legal need to be included on the distribution list.
…und abschließend eine gute Zusammenfassung der Punkte:
Keep it simple but not too simple.
Make it functional but not too complicated.
Include only relevant information.
Don’t clutter with un-necessary stuff.
Do include some good, relevant images.
Check your spelling then get someone to proof read it.
→ 20 Steps to Better Wireframes
Similar Posts:
- What’s Wrong with Wireframes?
- Wie man Wireframes und Content zusammen dokumentiert
- Life Cycle of a Wireframe
- Nokia Wireframe Stencils