Conducting a survey about your website dashboard’s effectiveness will help you quantify its most useful information or shine a light on its biggest flaws, but the “why” will still be elusive…
Why co-workers need certain data. Why they ignore other information.
Just like the website itself—the deepest, most revealing insights will come from talking to real customers. In sticking with our UX approach to a dashboard redesign, interview each of your dashboard stakeholders separately.
This is the third post in a blog series about redesigning your analytics dashboard. Start from the beginning.
Why interview stakeholders
You will have your own ideas for how you’d like to see the new dashboard look, but it’s important to first understand how your co-workers make decisions about the website and what information they use to help them make those decisions.
Don’t skimp on this step. This is where the gold lives.
Who to interview
To get clear insights, it’s important to interview each key stakeholder separately. A focus group will yield watered down information, and you will find you won’t be able to get into each topic deep enough to extract a lot of real value.
Keep interviews short: 30-60 minutes each. Schedule a follow-up interview if you don’t get everything you need the first time.
You will want to interview 2 types of stakeholders:
While your organization’s leaders may not be able to get into the mechanics of website behaviors and metrics, it’s critical to include them for buy-in. Without their support, your shiny new dashboard will slowly evolve back to the way it was.
- President / CEO
- Marketing leadership
- Analytics leadership
- IT leadership
Practitioners are the hands-on digital marketers and/or product owners who oversee the day-to-day site experience, traffic, engagement, and conversions.
- Website manager
- Digital product owner
- SEO manager
- Content marketing manager + content strategist
- UX strategist
- Digital marketing manager
- Web analytics manager
Obviously, you don’t want to conduct dozens of interviews — so include only key decision-makers at this point. Others will have an opportunity to have their voice heard when you survey them and test dashboard prototypes later.
What to ask
Keep the interview structure to a strict question / answer format — that is, try to limit tangents and soap-boxing.
If the person leading the interviews isn’t a trained UX researcher, aim for the 80 / 20 rule. The interviewee should talk 80% of the time, the interviewer only 20%.
Ideally, conduct the interview in person or by video chat.
The goal of the interviews is to identify information needs, not brainstorm solutions. The “how” will come in a later step.
Here are example questions of what to ask each stakeholder:
- Which aspects of the website do you officially manage or oversee?
- For each aspect, how do you currently measure or track the performance of this?
- What other information do you use to make decisions about the site or to improve performance?
- What types of information do you wish you had about the site?
- What are your biggest questions about the site?
- What are your biggest pain points or concerns? What keeps you up at night or do you worry about the most?
- Are there aspects of the site that you unofficially manage or oversee?
- How do you use the dashboard today?
- What information do you wish the dashboard included?
Don’t be afraid to ask follow-up questions, clarify answers, ask for examples, and validate definitions. I find having them tell me a few stories or anecdotes helps me better visualize the user’s needs.
Keep an open mind
During the interview process, do your best to avoid talking about solutions. You will want to gather and synthesize all your interview notes first. You might be surprised by what you find when you put it all together.
You might discover the need for multiple dashboards, one for each internal audience. Or you might create one universal dashboard plus several smaller reports.
Whatever the solution, there are a few more steps I recommend first.
Identify and categorize all findings by theme. Don’t discard requirements that fall outside of traditional “data,” such as communication and process.