I think you can capture almost everything you need to capture in a pretty detailed sketch. Not a high fidelity sketch by any means. Not the ones where you use five different kinds of markers and you shade everything or whatever. The purpose of sketching is to communicate the major ideas, like, “What’s going to be on the page? What are the objects on the page? What are the things you can do to those objects?” […]

On the other hand if you want to actually test something, you need a prototype that someone can test. So, I would actually say that the role of the product designer is working with stakeholders to come up with those sketches, and then going right from that sketch all the way through to prototyping. That usually means high fidelity mockups that can be clickable or lightweight HTML prototypes that are clickable and usable.

This is the workflow we’ve adopted at Flow as well. We sketch different interface ideas (variation), and then move to prototyping in Axure when it’s time to test and improve a specific idea (iteration). There’s not much room for static wireframes in that workflow. But it is an ideal workflow, and not every project is ideal. As I’ve mentioned before:

Lacking budget, flat wireframes for quick iteration is better than doing no iteration at all. We can’t be so idealistic that we’re not willing to scale down our processes when we need to.

So as long as we’re willing to admit that one size doesn’t fit all, I’m all for advocating an ideal approach that degrades gracefully under non-ideal circumstances.

Also see Wireframes: A good communication tool, a poor design tool by Dan Ritzenthaler.