At what point does interactive wireframing become redundant?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.