I just finished Dan Brown's excellent Communicating Design
. It's a very practical cookbook of design documentation: how and when to use ten different types of deliverables. Brown writes from a consulting background, which is different from mine, so it was interesting to contrast it with my methods of working with internal company stakeholders.
When presenting a design to coworkers, I try to remember the following guidelines:
Do outline your specific goals at the beginning. One mistake I used to make was presenting people with a mockup (whether in a meeting or over email) and simply asking for feedback without context. This laissez-faire approach tends to result in incorrect assumptions and irrelevant feedback.
Instead, introduce the mockup by explaining the rationale behind your design process, and ask for feedback on the specific aspects you need. If the conversation wanders, explain that parts of the visual aren't final enough to be ready for comments.
Don't show people many design alternates, even if you explored them yourself. As Brown points out, this often brings about the dreaded Franken-design, when the stakeholder says "I like the header component from mockup 1, but the content component from login 2." Research shows that comparing multiple choices can lead to greater dissatisfaction than if the stakeholder simply had one design to evaluate.
Moreover, stakeholders don't have time to look at your different directions and listen to you ruminate on the inevitable tradeoffs of design. So hang onto all your work, but don't introduce alternates unless they're needed to address a specific point that comes up.
Do tailor the process to individuals. On an internal team, you can learn what's aspects of design are important to each stakeholder and colleague. Ensure that your design addresses likely concerns and requirements and be ready to articulate how it does so.
Don't leave interactivity to a stakeholder's imagination. Web page mockups as a design deliverable are on the way out -- or, at least, they're no longer sufficient. The nuances of how screen elements respond to users' actions can be critical for your larger team to understand, particularly when you're defining a new behavior not reflected elsewhere in your product.
Low-impact ways to model interactivity include keyframing and annotation. For higher-fidelity prototyping, you can employ the interactive features of Visio or Powerpoint, or code a prototype using Axure or Flash.