As I've been putting together Livetyping (my HTML prototyping course), I've been thinking about situations when you shouldn't prototype stuff (interface elements, interactions, whatever). This two-by-two chart sums up my thinking:
When something is hard to explain, but easy to code, you should code it. When the opposite it true, you should explain it instead (maybe using something like Polypage to add annotations directly to your prototype). These seem to be no-brainers.
But the interesting bits are the other two rectangles. If something is easy to explain and easy to code, what should you do? And what if it's hard to explain and to code? Well, it depends. And the “it depends” is similar for both cases.
It depends on why you want to prototype this particular bit of the interface. Is it just to communicate how it works to developers and stakeholders? If so, explaining is probably the best route.
But if it's so you can test your design with users, it may be worth putting in the extra effort to code it, especially if it is used in any important flows. Of course, if you're in the hard/hard rectangle, you may have to collaborate with your developer colleagues to bring it to fruition. (Thinking about it, this flavor of “it depends” applies to all four scenarios—if it has to be in there for testing, then it has to be in there.)
There are other axes to take into account, of course, such as the relative importance of the thing you're contemplating prototyping, and the novelty of the element/interaction, but I've found this to be a useful tool for thinking about this stuff.
What do you think? Ping me on Twitter and let me know.