In Boxes and Arrows, Stephen Turbek suggests making wireframes look as realistic as possible, and argues that the old idea of clearly distinguishing wireframes from design is actually counterproductive (Real Wireframes Get Real Results):
How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?
This question is almost a traditional part of being an information architect. Wireframes do not clearly define what they mean to convey, leading to confusion. This is most apparent in wireframe usability tests with users who don’t know anything about the project or process. Fortunately, there are a few simple steps that will make wireframes be understood by anyone. They don’t even have to be much more work. It’s simply a matter of choosing to “get real” from the start.
Now, here at Extractable we prefer to do usability tests with prototypes, so we don’t have that specific problem, but I have tended lately toward dropping in the client’s actual logo, using their brand colors and generally making the wireframes look more realistic and my anecdotal experience so far is that clients do prefer that to utterly abstracted grayscale featureless wireframes full of lorem ipsum and x-boxes indicating where the images should go.
Comments
One response to “The case for real-looking wireframes”
There’s two flaws I see in Stephen’s logic.
First, I don’t buy his one-liners that it took 10 minutes to add style and a logo to the Verizon wireframes and another 2 minutes to add imagery. It would realistically take over one hour for that effort…. certainly not too much time, but let’s be realistic.
Second, I think that that simple black and white wireframes are much simpler and quicker to iterate than “real-looking” ones.
Maybe this is yet another argument for the internal team and doesn’t need to affect what the client sees, but I’m a practical kinda guy.