Why we skip low-fidelity wireframes and get right to high-fidelity concepts

There was a time, not too long ago, that all of our website and application projects started off with research and wireframes.

We still do the research part - strategy and vision, stakeholder interviews, data analysis, observational reviews, brand guidelines and technical requirements, to name a few - but now we bypass the “typical” process of creating pages upon pages of basic, low-fidelity wireframes.

I’ve found that wireframes - grey and black, boxy illustrations on a white background - often only serve to confuse people. Through them, you’re attempting to describe intricate transitions and interactions alongside placement of system content and navigation. This is important stuff; the foundation of the very product you’ll later be building. If you don’t get the basement right, the whole house will be off-balance.

My issue with wireframes is that people invariably get caught up in details that don’t matter: font choice, colour (or lack thereof) and element sizing. This is sadly where discussions about wireframes usually end up. You can keep trying to get everyone back on track, but that’s a lot of extra time and effort. Time and effort that could be better spent elsewhere.

These days, we move from something I like to call “design architecture” - high-level documentation generated from the above research findings - right into high-fidelity, pixel-perfect visual concepts. I’m confident that we have enough real-world experience designing complex interfaces that we don’t need stacks of iterated wireframes to determine the optimal solution.

The key benefit of high-fidelity concepts is that the entire team can see the system come to life quickly and collectively. We’re able to gather feedback and validate our decisions early in the process. This approach also conserves the project budget as the concepts we deliver at this phase will be the same ones used in the final deliverables. There’s nothing lost in translation from wireframe to shipped product.

Another advantage of high-fidelity concepts is that programmers can more quickly get to work writing code and implementing solutions. Together, in parallel, we can use the same templates to create a functional prototype that people can touch, click, type and play with. You don’t end up with multiple versions of similar documents that need to be either maintained or thrown out. High-fidelity concepts are useful from beginning to end.

All of this said, there are some cases where low-fidelity wireframes work, and work well. Regardless of the process you choose, what’s most important is that you’re comfortable and efficient preparing the assets you need to make a great technical product and user experience. How you get there is up to you. If you’re willing to give high-fidelity concepts a shot, then I encourage you to go for it.

Hey,

Interesting post, I know a lot of website designers swear by the grey box method, which is almost going the opposite way and removing the fonts/text altogether. Obviously that doesn’t work for an application so this is an interesting idea.
What software tools do you use to generate the concepts and does this make it fairly easy to make any amends the client does require?

great post

Jay

We use Adobe Fireworks CS4 for most everything. If you utilize Pages and States within a document, there’s plenty of flexibility and room for future modifications.

This looks pretty cool actually. I’d love to try it out. Thanks for the info about Fireworks CS4, Geof.