This chapter is from the book
This chapter is from the book
This chapter is from the book
Get the Goods
OK, you know what information you want to learn. Now what? The two main ways to get that information are stakeholder interviews and documentation review.
Interviewing Stakeholders
Use your stakeholder matrix and start setting up 30-minute to one-hour meetings with each of your stakeholders. You may be tempted to interview some people in groups to save time. I usually recommend against that approach because you may not get the most straightforward answers. Use your best judgment. You can always follow up with people later if you think they held back.
Planning the Interviews
If you filled out your stakeholder matrix, you’ve made some good notes concerning what topics to talk about with each stakeholder. With those notes as a reference, send each stakeholder an email detailing what you hope to learn (at a high level) and what they should do to prepare (which is usually nothing).
The stakeholder matrix is also a great starting point for putting together a stakeholder discussion guide or checklist. I usually create a master interview guide with questions on all the topics and then chop it up for each stakeholder, depending on what makes the most sense to ask them. Content Strategy Tool 6.3 is an example discussion guide from Kim Goodwin, author of Designing for the Digital Age (Wiley, 2009).
Before you jump in, consider how you want to structure the interview. The order in which you ask your questions can make a huge difference.
Structuring the Interview
In its facilitation course, “Technology of Participation (ToP) Facilitation Methods,” the Institute of Cultural Affairs recommends a technique known as the focused conversation. The approach helps people facilitate group conversations.
I’ve also found the approach helpful in planning stakeholder interviews. It’s composed of four types of questions: objective, reflective, interpretive, and decisional. The first three apply more directly to stakeholder interviews. I won’t cover the decisional type.
Objective questions
Objective questions are about revealing the facts and warming people up. They should be questions that are easy to answer. Examples include:
What’s your role at company?
What do you know about this project?
What are your team’s top goals and objectives for this year?
Reflective questions
Reflective questions are meant to elicit a more personal or emotional response from the stakeholder. They add meaning and context to the facts. Examples include:
What’s the hardest part of your job?
What is the most important thing this project can do related to your work and the work of your team?
What do you like and dislike about the content on the current website?
Interpretive questions
Use interpretive questions that reveal the stakeholder’s view of issues outside their role or team, such as the company at large, the industry, or the customers. Examples include:
What do you think your customers expect from your website?
What will this project’s success mean for the company?
What do you think will be the biggest challenges for the company related to this project?
Conducting the Interviews
I won’t spend a ton of time here, but there are a few items I keep in mind or do as part of the stakeholder interview process.
First, focus on listening. Avoid trying to fill silences. Resist the urge to jump in with your own insight because you think it will make you sound smart. (I do that. Don’t do that.) And avoid scurrying past a topic because at first it seems the stakeholder doesn’t have much to say. Let the interviewee think. Some of the best insights come after a long silence.
Second, whenever possible, have someone along who can take fairly verbatim notes for you. Or record the conversation with a tool that provides transcripts. That’s not to say you shouldn’t take any of your own notes. I almost always jot down a few things that stood out to me. But it’s easier to have an authentic conversation if you’re not trying to write down every word and facilitate the discussion.
And finally, pay close attention when stakeholders mention something or someone you have not heard of before. I’ll often hear a name mentioned repeatedly, and I immediately think hidden stakeholder! Or someone mentions a project that I don’t think my client has any idea is happening and has a direct impact on the work I’m doing. And sometimes, someone will mention something like the 2015 digital roadmap that I have not seen or heard about.
Reviewing Documentation
Reviewing documentation, such as strategy presentations, site analytics data, creative briefs, organizational charts, brand guidelines, or user research reports, often can seem quite aimless. Following the two-step process I’ve outlined can help add some structure and order to your documentation review. Content Strategy Tool 6.4 is an Airtable database (and spreadsheet) dubbed “Insights Engine” that you can use to inventory the documents and record your insights.
Inventory the documents
I usually start by making a list of the documents I’ve received from my client and categorizing them by type. The types may vary by project but usually include these standard ones:
Strategy—Often these are presentations that outline what the company or a department within the company is trying to achieve and the actions or projects it’s pursuing to do so.
User information—This includes items such as user or market research reports, usability testing data, personas, and customer demographic information.
Analytics—Mostly, analytics relate to conversion rates, site visits, page views, user paths on a website or application, and so on. Additional examples include call center data and data around cost per sale.
People and process—Documents I might review in this category include organizational charts and process maps for content planning, sourcing, creating, and publishing.
With those categories in mind, I have a better idea of what kind of information I can expect to glean from each document. It’s also a good way to validate with your client or business partner that you have all the relevant information; seeing the spreadsheet might spark additional ideas for things you should review.
Review and record
You can complete this process any way that works for you, such as creating printouts and highlighting key information. Maybe even color-code your highlights. A method I’ve started using is one I learned from my former colleague Emily Schmittler.
I create a spreadsheet (now usually an Airtable) with the following columns:
Insight—What did I learn that was important?
Topic—What is the note about? (I tend to use the categories of information described earlier in the “Define the Inquest” section.)
Source—What document did I get this insight from in the inventory?
Source category—What category (strategy, user information, analytics, people, or process) is the source document from?
Then, I start going through my documents, usually a category at a time, and record my insights as I go. I like this approach for a few reasons.
First, I don’t have to go back to a stack of scribbled, highlighted papers to find that one bit of information I think I remember seeing. Second, I can share this document in a way that’s easy for others working on the project to understand. And third, if I make an assertion in a deliverable and my client asks me where I got that information, I can find it on my spreadsheet.
Trust me, the Insights Engine will come in super handy when you’re putting all you’ve learned and analyzed together to set up for strategic alignment. You’ll be able to filter your insights to discover patterns. It’ll be awesome.