The Perils of High-Fidelity Wireframes

By Deane Barker on January 21, 2013

When your Axure prototypes are too good: Molly talks about a problem I’ve seen more than once: is what I’m looking at a high-fidelity wireframe, or a really crappy design?

I’ve built or helped to build very high-fidelity prototypes, both from a visual and interactive perspective. They could easily be mistaken for actual web sites, and therein lies the problem. I’ve been asked more times than I can count whether the prototype is working code, and despite clear communication I’ve had developers try to use the code to develop from (and then complain to me that it’s hard to work with).

What’s morbidly funny here is that it becomes awkward to ask: “Is this just a wireframe, or do you just suck at design?”  I mean, if you treat it as a wireframe and ask when the actual design is going to be ready…whoops.

Molly talks about it in the context of Axure, which produces HTML walk-though wireframes, which causes another problem when developers pull that code and start trying to work with it.

In Code Complete, Steve McConnell says that prototyping is great, but the biggest danger is that the prototype with sorta kinda end up being the actual thing. This happens with wireframes too, apparently.



  1. Axure is a very nice wireframe tool, but I’ve faced the same issue with things looking too good. It would be very nice if it had themes that would allow you to produce a “hand-drawn” look like Simplediagrams or Denim, while retaining all the nice UI object inheritance that makes it such a nice tool.

    But the HTML under the hood is only marginally better than Word’s – I honestly can’t imagine a developer with even a modicum of ability spending more than 5 minutes looking at reusing that garbage.

Comments are closed. If you have something you really want to say, tweet @gadgetopia.