Since composing my last post on wireframes I came across a couple of articles on the subject which reinforce the point of needing to keep wireframes simple - in terms of what they are for as well as how they look.
Sarah Harrison states the problem nicely:
"Standard wireframe documents look so much like a web page layout, we ask viewers to use immense amounts of imagination to divorce that which the wireframe is trying to communicate from what its visual representation is communicating....he main problem with wireframes is when they try to do too much, serving multiple purposes at the same time. The key, in my opinion, is to decide what the essential purpose is for your wireframe documents. Different purposes might require a different format."
Dan Brown (who goes on to suggest one possible solution) has had this problem:
"The conflict arose after clients had seen the wireframes. The layout, even explicitly caveated, would set their expectations, and they did not appreciate screen designs that strayed too far from them, no matter how carefully crafted. Clients also struggled to talk about information priorities, taxonomies, and functionality. Placing these concepts in a layout made them more accessible, but our conversations were too tactical, and their feedback had more to do with design than with structure."
Dan Brown: Where the wireframes are Special Deliverable #3
To me, these interesting articles reinforce the need to think ahead about the process within which the wireframing sits That should help to keep the wireframes as a quick, disposable tool to help with the next task in hand - I don't think the one wireframe can cover all the aspects of logic, layout, emphasis and so on without losing the quick-and-cheap benefits that wireframes ought to have.