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.
–
AliAug 17 '10 at 9:30

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 RAug 15 '10 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 RAug 15 '10 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.

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.
–
TejAug 13 '10 at 15:15