Great post; I've worked independently & in interactive agencies and the biggest challenge I've seen in an agency setting is the cost, time, and effort expended into the evolution of a wireframe prototype from a raw, low-fidelity to a tantalizing, high-fidelity prototype. Problem in agencies is that UX folks are too focused on concrete information architecture-driven design (using legacy techniques) and not on exploring the solution space, and many times lack strategic foresight, rudimentary copywriting skills, and tech acumen. My thought: teach a coder, who thinks strategically, the basics of UX, competitive analysis, and pattern scoping and he will churn out a speedy & exploratory prototype more expeditiously than an agency.
This article pretty much sums up exactly the process I go through when wireframing a new web app. Personally, I use adobe fireworks to do this, and I've gotten fast enough with it that when I'm in the zone, I can express myself in it almost faster than writing it down or talking.<p>The most important point here, IMHO, is that wireframing should be done in a medium that you can change fast without much effort or fear.<p>This is why I don't like the whole HTML/CSS wireframing technique. That works great if you only have 1 or 2 directions to go in, but what if you're exploring 7? You end up having to manage 7 different html and css files. In fireworks, I just click "duplicate page" and nudge a few UI elements around.
Thanks so much for writing this. I've been a UX consultant for almost 20 years and it's always good to see these kinds of things as some of us forget the simple things over time.<p>Also, this is a great tool to share with project teams that think wireframing has no place in an Agile or "Lean" methodology. Wireframing can, as you have eloquently put, be very simple and FAST and is not considered a "deliverable", nor should it be. It's a means to the end result of a good solid set of requirements (both functional and UX).