bank’s business strategy calls for addressing both kinds of customers, the design
team will need both personas.
Regardless of the number of personas you create, reference the raw data fre-
quently to make sure that everything you learned is captured in the personas.
One way to do this is to draw on quotes or other evidence from research activi-
ties to support the things you say about users.
Background stories, photos, and real names are nice, but they can distract from
the purpose of the personas. Stakeholders may focus instead on these details,
which don’t speak to need or motivation and which ultimately do not provide
any relevant information to the project team. Keep an eye on the time as you
ﬂesh out the demographic details of your users and decide how much time you
want to spend on this part of the persona.
Personas are people—abstract summaries of people, but people nonetheless. You
are hosting a party. These people are guests. Introduce them. Remind your
guests of honor (the stakeholders) how they might know them and what they
have in common—perhaps even why they invited them in the ﬁrst place.
The users of the system will have goals that support the goals of the stakehold-
ers. As host, your job is to show them how these apparently divergent interests
have something in common.
When collaborating with your project team on personas, there are three different
kinds of meetings. First, there’s the buy-in meeting, where you’re selling either
the personas themselves or the idea of doing personas. Then there’s the feed-
back meeting, where you’re soliciting input on a set of personas in some state of
completion. And ﬁnally, there’s the brainstorming meeting, where you’re starting
with a (mostly) blank slate and generating the content of the personas together
with your project team. Different meetings call for different kinds of presenta-
tions—here’s a rough guide to what to expect, and how to prepare.
The buy-in meeting should happen only at the very beginning, when you are
seeking approval on doing user research and building your personas, or at the
very end, as nominal approval for a product that you have developed with the
participation of the project team.
To get buy-in for the approach, devise lists of questions written in such a way as
to be difﬁcult for the internal stakeholders to answer. These questions may also
be answered differently by different groups within the organization. It’s a bit
of a dirty trick, but doing this can help show stakeholders that the institutional
conception of the audience is inconsistent or incomplete, and that we need to
go outside the organization to conduct user research. By further tying these
questions to speciﬁc design questions, you can show how user research directly
affects the design of the interface.
To introduce the notion of a persona, you might capture these questions in the
form of a persona. The goals section, therefore, would contain questions that
help pinpoint the user goals. The scenarios section would contain questions that
encourage users to spell out the situations they ﬁnd themselves in when they
attempt to use the system.
Getting buy-in for personas faces several difﬁcult obstacles: Either stakehold-
ers do not accept the premise that user research is a good thing, or they do
not think the segmentation model is appropriate. In either case, creating per-
sonas as a way of getting buy-in to do user research is a bit of a catch-22, and
requires some (if not substantial) investment in activities whose value is not
By now, however, you’ve identiﬁed the need. If the need is to get buy-in for
the process, you may create straw man personas just to demonstrate their func-
tion in the design process. These straw men can be deliberately and obviously
incomplete to demonstrate the need to do user research. They can also show
how personas provide the kinds of distinctions that will drive design.