The Hurdle of Visuals

You've worked your heart out on a project, coming up with a great site structure, smart placement of content on each page, and a solid outer shell of basic fonts and colors, and you present the work to your client. What's the first thing you hear? "I don't like the photos." Many of us have been there before. After all your hard work, the only thing the client can see are the images (which usually they have provided and you have no control over). How do you get people to look at the right things?

One of the biggest challenges facing anyone in the field of information architecture/interaction design/usability (etc.) is the careful line of visual fidelity. Human beings are naturally extremely visual people. Look at the stats for most product sites, and you'll probably find that the most visited portions are photo galleries and other high-visual/low-text areas.

Unfortunately, strictly speaking, much of the work in this field is not particularly visual. Yes, a good information architect lays out where things lay on the page, but in many (most?) situations they are not the ones creating the graphics files, choosing colors and fonts, writing copy, taking (and choosing) photographs, etc. One of my favorite sayings comes from the field of film, and basically states, "a good editor has done his job when nobody notices his work." The point being, a bad editing job is going to be obvious and annoying, but a good editing job is going to be completely overlooked as the viewer is immersed in the film itself rather than the editing. The same goes for many user experiences. People notice when it's frustrating, but a seamless, intuitive experience lets the user focus on the content, not the process.

I bring this topic up now because I am wrestling with the best way to present work, both at an internal wireframe level and at a client-facing presentation level. I remember a project at my last job where five members of my team were independently presenting wireframes to a client -- the idea was to treat it almost like a pitch meeting as if we were different firms rather than just members of the same team. It was a fun challenge as we all got along well, but the differences in our approaches were stark. Some of us made ultra-simple wireframes, just black and white boxes with Arial text. Others added a layer of polish with gradients, nicer fonts, and drop-shadows. Some used photographs, others used representative "silhouette" images, some just used placeholder boxes. Before our client presentation, our boss looked across our examples and decided we shouldn't be biasing the client toward or against any design based on the fidelity of the wireframes. Let the IA speak for itself.

This posed a problem for me -- my design was very sparse, and was intended to highlight the imagery of the product itself by minimizing navigation and text. Removing images meant that there were large areas of blank space now in my presentation. Would the client be able to "project" the imagery in their own mind and see how it looked? Would she end up preferring a presentation that was heavy on text and navigation because there was no imagery competing for visual attention?

It's a tricky question. My boss could have suggested the opposite -- everyone HAD to add photos and gloss up their wireframes. But then would the client focus on images chosen rather than the IA? How do you make a client look at the right things? And on that note, how do you get your co-workers to even look at the right things when presenting internally?

The answer all depends largely on who your audience is. You could have a super-savvy client who can envision the finished product just from a wireframe, or you could have a client who sees a wireframe and dismisses the work entirely because it doesn't look like the polished, finished sites they're used to seeing. And on an internal level, particularly in firms where different people work on different aspects of sites -- such as an IA building wireframes and a designer creating the actual visuals -- you can find yourself stepping on toes. Does a high-fidelity wireframe make the designer feel like you're dictating their job? Conversely, does a low-fidelity wireframe make you look sloppy? Can you make something that projects a polished, dynamic end product while still respecting that technically, the visual polish is someone else's job?

In general, I think I tend to over-design wireframes and under-design comps. Most of my wireframing is in an agency environment, where it helps to have nice fonts and clean lines, but inserting sample imagery and venturing into the land of colors and graphics are going too far. Meanwhile, as a freelance designer, clients often can't see the finished product if they don't have imagery in place as well, although I think it's best to use different imagery from what they might see on their live site today, just to underscore that the imagery may change frequently but the structure and visual design will be constant.