At what point does interactive wireframing become redundant? How much of the site do you really need to create (using tools such as Axure), before you can call it a working prototype?

Working on a really large site, to tight deadlines, and I'm starting to consider that the requirement to create a complete wireframe prototype could be causing an unnecessary delay to the project.

Once the interaction models and standards have been set, and key pages/flow completed, is it necessary to provide every page?

  • 1
    Update: I also realised that the nature of the interactive wireframes made sign-off a nightmare. Client getting stuck on little technical glitches, which is pointless as it's irrelevant code causing it. They were great for user testing but not for sign-off I think.
    – Ali
    Commented Aug 17, 2010 at 9:30

5 Answers 5


It's a good question and one I ask myself before every prototyping session.

A few thoughts:

  • Don't try to include every page but do include every template.
  • Although most prototyping tools have capacity to demonstrate rich interactions if you can annotate a static tool with a link to an example, you'll save yourself hours.
  • Use/adapt widget libraries where possible — there are numerous libraries out there for Axure for example.
  • Let the key user stories drive the level of detail — if a key story requires use of a special tool, it might be worth adding more interactions.
  • Get the static, annotated pages drafted before working on interactions - this reduces the risk of arriving at the deadline with major omissions.

Ultimately, interactive wireframing becomes redundant if the downstream team won't/doesn't need to interact.


A few have already suggested that unique page types/templates/layouts should be the main focus. In my work, I've recently tried to change our attitude towards mock-ups. Previously, design meant one or two sample screens, but this still left developers making design decisions.

For me, that's the driver of how far you need to go with wireframes (interactive or otherwise). When development starts, developers shouldn't be making design decisions — they should have all the artefacts they need to construct the screens in accordance with the output from the design phase. If doing wireframes and/or prototypes, you have not covered all the potential components needed for your site or system, the process is incomplete.

All that said, the commercial drivers of how much clients are willing to pay and wait will usually trump any "ideal-world" scenario of having enough time and flexibility to do design to the level we really want.


To answer the question asked - "interactive" wireframes are redundant as soon as you start doing them. As soon as you make your design artifacts (wireframes, mockups, anything else like that), you are wasting time on something that you're going to have to build again when the actual system is built.

The only exception I see to this is if you are going to be doing actual user testing with the wireframes (NOT just showing the wireframes to the business people). And even when doing this, it isn't necessary to provide wireframes for EVERY page in the system. Most often, you will find out that your site really only has a small number of unique TYPES of pages, and those are all you really need to wireframe.

  • I think the other exception is a site that allows personalization and designers are creating theme choices. If the wire-frames are an accurate representation of the elements and flow(interactive) then they are good for generating to theme concepts with vendors.
    – Susan R
    Commented Aug 15, 2010 at 0:19

There's a fine line where documentation crosses over from being a solid foundation to being a burden on the project. Where that line is tends to vary dependent on the specifics of the project and the team members. IMHO, more often than not, it's better to err on the side of getting stuff into working code sooner rather than on the side of making sure each and every element is fully documented in some form of wireframe.

  • I consult on large projects, so the line is in a harder spot since the wire-frames, working prototypes with accurate code, sometimes UI libraries and Best Practices documents are deliverables. But I agree, that it's always a moving target.
    – Susan R
    Commented Aug 15, 2010 at 0:24

The big benefits of wireframing are to make it easier for customers / users to understand how the site will function (easier than reading written documentation anyway) and to reduce risk by resolving how grey areas of the application will work as quickly and cheaply as possible (quicker and cheaper than building it for real and then doing usability testing at the end).

Having said that, you could try reducing wastage by wireframing directly in HTML / JS so that your wireframes become your final HTML files once you add in the final visual design elements. It's a bit slower wireframing this way but it's something that becomes faster / easier with practise.

  • Using HTML/JS is NOT wireframing. That is prototyping. There's a big difference.
    – Charles Boyung
    Commented Aug 13, 2010 at 14:18
  • 4
    Flip sake, Charles - what's the difference between an "interactive wireframe" and a "prototype"?
    – Sam K
    Commented Aug 13, 2010 at 14:26
  • 2
    There's nothing wrong with using HTML / JS for wireframing. I'm not suggesting high fidelity, final screen design, pixel perfect HTML wireframes. I'm suggesting quick and simple, clean, black and white wireframes. Besides, as I said, the goal is to produce something that can be used for usability testing, thus suggesting improvements and resolving grey areas. The route to that goal is less important.
    – Tej
    Commented Aug 13, 2010 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.