Tips for presenting screen mockups

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.

Comments

[Dr. Pete]

Good points, Joshua. I can't count how many headaches I've gotten from giving coworkers or management too many unconstrained options to consider. People start telling you about their color preferences, some cool website they found, or how they would write the copy, and completely miss the bigger picture.

[Lennaert]

Hi Joshua,
Sweet article!

Note* I am a internet project manager, not a designer. I usually manage the design proces with an art director and up to 3 designers.

In general I agree to your points. However, I do tend to sometimes present a bronze, silver, gold design, where silver is usually on par with the clients budget. They tend to go for gold.
Some additional points:
In case of large website design projects, also explain to the stakeholder which input was used, what the process was and who was consulted. This is especially important when presenting to a board of directors or similar level.

Another small tip, I usually bring the designs in digital and on foam boards. On the back of the foam boards I always glue a business card. Foam board designs tend to travel a lot; I have more than once done business from a foam board lead.

Lennaert

[James Breeze]

I find that actually doing the designs with as many of the stakeholders in the room at the time is the best way to get thongs through quickly!