The missing persona you need for written presentations
By: Kai Wong
Tags: Design Thinking, Design, User Experience, Data Visualization, UX

The missing persona you need for written presentations

Target your stakeholder’s data needs even if you’re not presenting.

Photo by San Kaÿzn on Unsplash

There’s a small extra step that you can take to make written presentations much more effective.

Create a persona of your stakeholders based on their data needs.

This was an idea that I encountered while taking a course on Tableau: it came up unexpectedly when talking about creating visualizations for an audience.

But it made sense the more I thought about it.

Especially if your ideas, not you, are going to be at the meeting.

Live versus written presentations

Until now, I’ve talked with the assumption that you’d be giving your stakeholders a live presentation. However, that’s not always the case.

You may be asked to create infographics, written reports, or other e-mailed summaries for your stakeholders. Whether your team member was out sick or it’s another person that needs to be part of the team, you may just have to hand a presentation over. And that’s when it can get a little tricky.

In a live presentation, your slides are a summary that you can elaborate on as you talk with the stakeholders over the course of an hour-long meeting.

But a written presentation? That data has to summarize the key points and explain them in a manner that your audience can understand on their own. The document tends to have more details as well as directly addresses potential questions that the audience might have.

If something’s not clear, it’s often up to the audience to try and figure it out.

So it’s crucial that you need to have a strong grasp of the audience and what they can understand.

If you don’t, then that leads to problems.

So the first thing you have to ask yourself is this: Do they understand the chart that I’m creating?

Which visualization do I choose?

When you first look at this chart, do you understand what it’s supposed to represent?

If you couldn’t guess, it’s a hex-tile map of the United States.

It’s a way of standardizing state sizes so that states like Rhode Island and Alaska can both be seen on the map, even though they’re vastly different sizes.

But if you didn’t know what the chart was supposed to be, it immediately loses a lot of its impact.

Some people might be able to guess what it is, given the context clues (like state abbreviations), but if you’re not there to explain it as you would in a live presentation, then they would be left guessing.

So how can you understand what visualizations your audience will understand?

That’s where the personas come into play.

The need for a data-based persona

In case you need a reminder of what personas are, they are a fictional yet realistic description of a typical or target user.

Your stakeholders are people who are using the product too: they’re just not using it in the same way that your target users are going to be.

How are they using the product? They’re using the aggregated data that users provide (i.e., sales, KPIs, and other metrics) to make informed business decisions, create new tools, or create budgets for new projects.

So creating a persona based on them is not a wild idea. But what you need to express within the persona is a little different than your users.

A stakeholder persona

In this case, what you need to express in the goals, challenges, and needs is about that data, rather than the tool itself.

Before you start to panic about having to do a ton of extra work, remember that we first try to narrow our audience down to one person.

Often, that person is the decision-maker in the room, who we need to convince to take action.

Here’s a walkthrough of the different sections to consider for that persona.

Why do they care about the data? (Purpose and Goals)

This is likely the part you’ll know the least about, especially if you’re a new designer. There may be organizational things that you may know nothing about, but you may not need to go into such detail.

Instead, think about why the data might matter to them overall: for example, do they want to see our growth over the last 5 years?

Do they want to compare our products with our competitors?

The goal of this section is to help you choose a type of visualization or approach.

In this case, the bullet point “Anticipate next moves in market research based on trends” seems to suggest that he wants to use current data to try and predict future markets or competitive advantages. In that case, we can move on to the next section.

How should the data be organized? (Challenges and needs)

The user wanted to see a snapshot of data and trends at this specific moment, to try and see what might be the untapped markets for the future.

If we were to follow this chart path, we would use something called a sector chart.

I don’t know what that is, and it’s pretty likely that your user will not either.

Chart choosers, such as the one above, are a great way to narrow down which type of chart you should create.

But what they fail to mention is this: while the chart selected is usually the ideal chart, it’s not the only one that can be used.

If you wanted to highlight changes over time, you could use both a line chart and bar charts: the difference is that line charts are usually ideal for a user who understands that visualization type.

So what is your user likely to understand? Given your interactions with them, are they a technical user that can understand numbers and stats?

Are they visual person, that wants simple charts? Would more unusual types of charts work?

This will also help with the details of the chart: should we include specific values or percentages? How far back do we want to go with data? What categories should we include in the visualization?

This is where UX can shine: by understanding what your user can understand, you can create a visualization that is specifically targeted towards them.

If you don’t know some of this information? You can then ask others about it: doing user research by talking with colleagues or managers doesn’t just help understand the stakeholder you’re targeting.

It’s also a way of introducing user research (and design thinking) to your team members, promoting design thinking to your larger team.

Bridging the gap between Data and UX

Data has always been a tricky subject for many UX Designers.

Interviewing users, doing qualitative user research, and presenting findings to stakeholders is at the core of Design thinking.

But larger and wider-scale uses of data are viewed with a little bit of fear. It treads a little bit into Data Science or Business Analysis, and it’s usually thought of as out of the domain of most Designers.

But there’s a way to effectively use our findings by just bridging the gap a little bit.

By taking the Persona, a UX technique, and extending it towards the data portion, we can not only close that gap a little: we can create effective presentations for our stakeholders, even if we’re not in the same room as them.