Tag: business

You’ve seen the memes. You’ve laughed at them. You’ve LIVED them. Because we all have.

You released your awesome dashboard that you put so much time and effort into, and then the users get their hands on it, and this happens:

Or, how about this one? You’ve got all the best data warehouse technology, your ETL game is tight, and yet… Spreadsheets.

We joke about this stuff ALL THE TIME. It’s funny because it’s true, and frustrating, and laughter is cathartic… it’s why they’re memes.

But, we don’t often stop to think about why this is the case and how we are complicit. 😳 Now, I’m not looking to blame the victim here, but maybe there are some things we can do to make our own lives a little easier in the future!

Because, at the core, these are both about unmet user needs. We can’t always solve them, and we definitely can’t always solve them alone. But, we can, occasionally, prevent some of this from happening.

How? Get curious. Roll your eyes and shake your head first if you need to. Then, ask a lot of questions.

Excel as a Data Source

Why does this live in a spreadsheet?

• Does this data have a place to live?
  • If so, why does it not live there?
• Does it have a place it should or could live?
  • If yes, how do we make that happen, and how quickly can it happen?
• Where does the data come from originally?
  • If it’s exported from a system, is the data accessible in another way, such as an API or back-end database?
  • Can we get access? Or is there an application owner that can help?

If we’ve gone through this line of inquiry, and still land on using a spreadsheet as a data source, how do we mitigate the risks inherent in manually maintained data sources?

How do we mitigate the risk?

Unstandardized and easily changeable data structures will inevitably break any automated process.

What can we do to mitigate the risk in the near term?

• Can we put this in a form so users don’t actually edit the spreadsheet directly?
• If not, can we use validated lists, or some other way to at least consolidate and standardize the data?
• Can the file at the very least be stored in a location with change tracking, version control, and shared access?

Once you’ve asked all the right questions, and you’re still going to have to use that spreadsheet in your dashboard, now we advise.

• Have we made the users and stakeholders aware of the risks inherent in using spreadsheets as data sources?
• Have we made it well known that they cannot, under any circumstances, change the field names, file location, or file names!? (No, <you know who>, the refresh didn’t fail… Tableau Server can’t refresh a file that is only updated on your personal downloaded version…)
• Is there a plan of action to move to a real solution, or will this inevitably become that fragile block in your data stack? This goes back to the questions we asked earlier.
• This is the time to kick off any medium to long-term changes that are needed to ‘officially’ house the data in the proper system. This doesn’t have to be you, but you can advise the business owners and help kick off the process.

Now you can go ahead and build the dashboard, knowing you’ve done your best.

But, how do I export it to Excel?

I know how frustrating this is. The dashboard meets all of the requirements, it’s been tested, and feedback has been taken. And yet, here we are.

So, what do we do? Get curious.

The request to export data, in my experience, typically comes back to the same few causes.

Trust

The user ‘needs’ to see the row-level data because, for some reason or another, they don’t trust the dashboard.

How can you build trust? Usually, transparency. Share things like data dictionaries, helper text, tooltips, source-to-target mapping, etc. This will often help alleviate the ‘unknown’ and ‘magic black box’ feeling the user has.

Change

Change is uncomfortable. They have a process that they are used to, and using a new tool to do their job is confusing them or slowing them down. Maybe they weren’t on board with the change in the first place.

How can you help make change easier?

• Involve the user in the process from the start
• Understand the user’s perspective, and how this tool fits into their job flow
• Include easily accessible documentation like overlays and helper text
• Do a training or a live demo – Not all users will just know to interact with your dashboard, even if it’s default functionality
• Show them how it makes their job easier

Fear

This one is closely related to change, but worth mentioning separately. If you’ve taken a report that took them 2 weeks to build every month and automated it, they might be afraid it’s taken half of their job. We can show this user how it can help them find more valuable insights they didn’t have time to identify before.

Lack of Alignment

When the direction and requirements come from only one persona the goals, metrics, or job flow will be insufficient for someone, no matter what you do.

• If we only listen to direction and requirements from leadership stakeholders, we will miss the needs and nuances relevant to the users ‘on the ground’.
• If we only listen to the end-user, we will miss the big picture, and leadership will not see the value. We also run the risk of ‘fixing a cog in a broken system’ instead of an opportunity to fix the system.
• We need to do our best to see the metaphorical forest AND the trees.

Unmet needs

If we don’t understand how the user actually interacts with the dashboard and how it fits in their job flow, we will miss something. Now, I’m not suggesting that we will be able to do a full UX project for every dashboard. That would be incredibly time-consuming, and not always valuable.

What we can do is learn from UX methods to ask the right questions, observe the users, and understand the audience(s) and their individual goals.

Often, you’ll find that the dashboard isn’t showing them what they need or want to know, or there is a piece of their workflow that doesn’t currently have a working solution. Sometimes it’s easily fixable with minor changes or some hands-on training.

Usability

We can sometimes meet all of the requirements and still produce something unusable. This usually happens when:

One Size Fits All = One Size Fits None

• It’s trying to be everything to everyone and is too difficult to use. These are often the product of ‘too many cooks in the kitchen’ when it comes to requirements.

But, What does it all MEAN!?

• There’s a lack of clarity on what the goal, metrics, and supporting metrics are. If you measure everything, you can’t tell what’s important.
  • What are the 3-5 measures that tell someone whether things are good, bad, or neutral? (These are the BANs)
  • How do they know it is good or bad? (These are the year-over-year comparisons, progress to a goal, etc.)
  • What are the supporting measures and dimensions that are needed for the immediate follow-up questions? (These are the first few charts on the dashboard)
  • What does someone need in order to ‘get into the weeds’ once they know what a problem is? (These are your drill-downs and supporting dashboards)

It takes too long to load!

• Your end users are probably expecting quick load times (I try my darndest to stay under 3-5 seconds). To address this, you will probably need to work with the stakeholders and users to inform them of the options and tradeoffs. Asking the questions, and letting the users decide what’s worth waiting for can help.
  • Do they really need to see individual days, or are 99% of the metrics monitored monthly? Aggregate that data source!
  • Do they really need 50 quick filters? Quick filters take time to compute, especially if they are long lists of values.
  • Is anyone really looking at all 20,000 customers? Or are they typically interested in the top or bottom 5, 10, 20, etc.?
  • Can any of the sheets be moved to a supporting dashboard or made available only on drill down?
  • Does it need to be live, or is an extract ok?
  • Do they need all of the fancy bells and whistles? LODs, Table Calcs, Parameters – these things take longer to compute and will slow it down. What, if any of this can be removed entirely, or pushed back to the data model so it isn’t computed while the user waits?
  • Can it be split up into separate dashboards?

We can’t completely satisfy everyone, and we can’t always ensure these things don’t happen, but we can take steps to avoid these pitfalls and save our users and ourselves time and frustration.

This guy will still want a download to Excel option.

Shrug your shoulders and let him have it in Excel, knowing you did your best.