Enter wireframes. If they’re done correctly, the wireframes will be an inventory
of every functional element and content container on the site. If you create a list
of all these elements and then select pages that have a mix of all these elements,
you can address all the design needs. In order to illustrate a comprehensive user
experience, however, you may need to mock up a few extra pages.
Treating screen designs as a deliverable means more than just putting together
a comprehensive document. It also means getting smart about how you present
the designs. Gone are the days when we could paste paper printouts of screen
designs to a board and go into a meeting like we’re ace advertising creative
types. That kind of show doesn’t cut it anymore. Web sites are becoming more
sophisticated, and so, too, are the working sessions where design teams present
the fruits of their labor.
Most meetings about screen designs fall into one of three types. If you’re not
asking for ﬁnal approval on a design, then you’re either seeking feedback or ask-
ing stakeholders to choose a direction.
Before presenting designs to stakeholders and clients, you can hold an internal
meeting to prepare for the discussion. Sounds like a lot of meetings, I know.
But think about it this way: A little preparation before showing designs to
stakeholders can avoid longer client meetings later down the road. By reﬁning
the designs and getting your stories straight, you prevent unnecessary back and
forth in client meetings.
Once you’ve gotten your stories straight, thought through the designs, and
reﬁned them within an inch of their lives, it’s time to get feedback from the
people footing the bill. Your stakeholders play a strange role in this process,
especially since nine times out of ten, they’re not the site’s target audience,
but they still need to approve the design. Even in this day when user-centered
design is so prevalent, it’s a rare client who asks, “How did the design perform
in testing?” Mostly, if they don’t like the background pattern, it doesn’t matter a
lick how well it tested.
There are two kinds of feedback, good and bad, and I’m not talking about posi-
tive and negative. Good feedback is meaningful, constructive, and actionable.
It clariﬁes the design problem or offers direction without compromising the
integrity of the overall vision. Bad feedback—well, that’s the kind we dread to
hear—entails stakeholders offering criticism based on personal taste, without
rationale or a nod to the system’s target audience.
As facilitator of this meeting, your job is to get all the feedback into that ﬁrst
group, even if it means taking meaningless critiques and reframing them into
something designers can sink their teeth into.
Table 11.2 offers examples of comments stakeholders might make about the
health insurance site from Figure 11.1.
5IBUDPMPSCMVFJTVHMZ 8IBUEPOµUZPVMJLFBCPVUJU )BWFZPVTFFOBCMVFUIBUZPV
Have someone at the meeting capture the feedback. If you can record the audio,
that’s even better. By having a good record of the meeting, you protect yourself
from scope creep—attempts to make the project bigger than its original param-
eters. Of course, such a careful record of the meeting requires you be clear
about how you will respond to their suggestions, because they will hold you to