Dashboard ingredients (webinar)

The Museum Computer Network (MCN)’s Data & Insights Special Interest Group (SIG) pulled together a panel to discuss dashboards in the cultural sector, together with Elena Villaespesa, the Metropolitan Museum of Art; Trilce Navarrete, Researcher;  Jeffrey Inscho, Carnegie; Joris Pekel, Europeana and Angie Judge, Dexibit. Watch the webinar or read Angie’s extended notes below.

Hello everyone! My name is Angie Judge, from Dexibit, where we do analytics for museums. Thank you to MCN for making today possible. Today I want to talk about three things, all in 10 minutes:  what goes into a dashboard, what makes a good dashboard and journey on how to get there. Add your commentary online with #musedata. 

What goes into a dashboard?

Let’s start with what goes into a dashboard. When we think about dashboards, we often preoccupy ourselves with what’s happening at an artificial level. That’s really important, and we want that user experience to be beautiful and seamless and insightful, but I think it’s important to see dashboards equally in terms of what happens behind the scenes as much as what appears in front. We often talk about dashboards a bit like a swimming duck – it all looks beautifully calm on the surface, but there’s a lot of hard work happening under the water that most of us don’t see.

Seeing a dashboard as an iceberg

There are three key tiers to achieve a dashboard, this is the systems architecture of the solution. The first is the user interface tier, the second is the application and the third is the database.

If we work bottom up, we begin with the database: here it’s about how we harvest data – the various sources where we get it from, and whether we’re streaming it or storing it. This could be as simple as an Excel spreadsheet, something mid market like SQL or Postgres, or for big data requirements we might look ahead to technologies like Hadoop.

The second set is the application tier. This is where the hard work happens, and if we skip this step we’re not really doing much in terms of helping our users glean insight from our data. Here, we’re looking for things like clustering analysis, blended data sets, that sort of thing. Again depending on the scale of our solution, this could be as simple as a formula in a spreadsheet or a fully built functional solution at the other end.

The third set is the user interface tier, which is what today is all about. This is where our visualisations happen. Our technologies here are most probably reference libraries of existing toolsets. We use a combination of toolsets like Vaadin and D3. But the user interface tier is about a lot more than just presentation, and I’ll get to that a bit later.

Approaches to integration 

To explore just a touch more on how we get data into the dashboard, there are some common approaches to integration: the magic or sometimes more the man behind the curtain for your dashboard. Again this is very important because without it, our dashboard will be blank.

When you’re setting out on implementing a dashboard, it’s important to go through each of the sources of where you’re getting your information from and determine what approach you’re going to use for each one. This will be purely a return on investment decision. There might be immense business value in having something happen automagically, or a clear business case from less copying and pasting.

The first approach is live integration, the holy grail. Like I mentioned before, this might be streaming, where we’re looking at a feed without tucking away our own copy, or it might be a data store, where we are indeed keeping a version for ourselves. Think of a Twitter feed for example. The other question here is how quickly we need that information. Often, we talk about things being ‘real time’. In very technical terms, real time comes down to a sub second. In reality, particularly for a museum, it’s likely that ‘live’ is a better term for what we need. We probably wouldn’t notice the difference between sub second and sub hourly. Getting to real time is a very expensive challenge, so it’s best to evaluate what we actually need.

The second approach is about syncing. This is most useful for where we need to write changes to our data in two places, avoiding the need for double entry. We will probably want to establish which system stores the master record, and which one is syncing changes to that. A classic example here is where we need to establish a single view of the visitor, but need to use that in multiple systems and keep all our data in check.

Another approach is traditional migration. It might be expensive to integrate your custom ticketing system to your dashboard, so you might want to upload extracts to your dashboard stack for a time instead, while you make that decision. You might hear a developer refer to this process as ‘ETL’ – Extract, Transform and Load. This could be done manually, or scripted. 

Considering the information architecture

All of this means behind your dashboard you’ll need to consider where your data is coming from and how everything hangs together. It’s useful, even if it is just a high level diagram, to look at this in terms of an enterprise architecture. I think it’s also a useful exercise to think about the scope of your dashboard. Is it just web? Is it just online? Is it just the visitor experience? Or are you wanting to pull together a complete view of visitation, collection and commercials?

This one here is our original systems framework which has been released as Creative Commons non commercial, so you’re welcome to use it in your museum. You might then drill down further into subsequent levels to reveal which data records are being drawn from these systems, and how they’re comprised.

What makes a good dashboard?

Ok. So now we know the context of where our dashboard sits in the world, we can go on to look at the bells and whistles of what makes an awesome front end.

The requirements hit list

For me, some of the most important requirements on my list are more about the delivery mechanism than the presentation itself.  

Looking top down, if we’re dealing with an institute that has several sites or venues, the first thing we’ll want is something multi tenant. For example, at the Smithsonian, with what – 19 different museums, you don’t want a separate implementation for each one. You’ll want a single account, with 19 different tenants. At the smaller end of the scale, it might be that as a single museum, we also want to manage an offsite experience or a touring exhibit, and similarly we have multi tenant needs.

The next thing that I’ll want is multiple users. I don’t necessarily want each person in my organization to have access to the same level of information, so I need something called user identity and access control, where as an admin, I can manage everyone’s access. And each person might want to see something slightly different. So I’ll want each user to be able to manage their own use, and personalize what they like to see on their dashboard. And I’ll probably want to instrument that too, and work out how often the staff are using the dashboard, as this will help me metric my own improvements around analytics implementation.

In terms of the data itself, I’ll want to be able to explore it by any time I’d like to see – it might be an hour, it might be by year, it might be the last 42 days, because I had a particular exhibition open then. For the visualisations themselves, I might like to think about whether they’ll be very rigid and static, or whether I’d like them to dance a little – to offer me animations like tool tips or the ability to zoom that help me explore the data from a high level rather than having to do extra analysis just to reveal say what a particular numeric is that relates to the bar on a chart.

Next, I want to think about how those people will be using their dashboards. If I’m designing for the 21st century, I’m going to assume that they’ll actually spend most of their time accessing their dashboard on a mobile device rather than necessarily their desktop. Presumably, given it’s 2016, we’re talking about a cloud implementation rather than on premise.

Then, I’ll want to know that the dashboard has a refresh rate every so often of it’s own accord, because I’d also like to use my dashboard as an independent display, say for example on a computer in the staff area, or maybe even a projection in a public area, and I don’t want to keep hitting a refresh button every hour or so.

Depending on what your answers are to these questions will give you an idea again of whether you sit in the spreadsheet or solution category. If you answered mainly on the left, you might get away with Excel. If your answers are on the right, you need something with a bit more bite.

What data do we want to display?

My next requirement is a question of what data I actually want displayed. If you think back to the data architecture we looked at earlier, this is largely a question of what my scope is – website, digital, visitation, whole museum. My dashboard might be strategic like this one, focused on a my key performance indicators, or allow drill down to an analytical level.

We’ve done a bit of research on this topic, interviewing lots of directors from various museums around the world. These are the top 30 data points that we’ve found senior management to require, which map to their key performance indicators and then the core strategic objectives. They might be a bit different for your museum, say if you don’t ticket any experience, or if you don’t offer public WiFi, but this is a great starting point.

This is of course a very basic way of looking at those, in terms of only a volumetric and a trend indicator, but we can always delve deeper into that further in our dashboard, or for different personalized views.  

Having a holistic scope like this also provides a good starting point for working through this list with different members of the museum, for example marketing versus curatorial, which is what we’re focusing now on in our research to understand a common practice for various parts of museum management and how they look at data. At some point, this will move from strategic data points like this down to operational and then analytical level data.

There’s a couple of really key points here that are quite subtle in how this information is presented:

  1. Despite the fact that this is a lot of information to digest, everything fits on one page. That’s really important say for example, if I have a dashboard on a TV screen projected in the staff administration area, because people won’t be able to necessarily scroll through – they’re just glancing up as they walk by.
  2. The information is categorized and grouped. I’ve seen a lot of dashboards that are beautiful to look at in terms of their graphic design, but they’re hard for the eye to navigate because everything looks like it was just thrown against the wall, there’s no logical business value in how it’s stitched together.
  3. Trending is really important. Saying, here, we got 53,450 visitors is great. But is that more than the last period? Or are things declining? And ideally, by how much? When we’re working in a more detailed view rather than this executive view, we might say show what’s called a spark line, or a trend line, to show history over time and degree of change.
  4. The data here is also quite visual, and I think that’s important. There’s lots of different ways to pretty this up, and we might end up using many different combinations of visual presentations together, but again because this is a high level view, we’ve got just one.
  5. But in saying that, there’s also a clear summarisation for the quick glance – everything tallies up into three takeaways. If we were just to glance at this, we’re not going to memorize 30 different points. But we can check the one or two that are important to us, and look at the headline.

In saying that, there is of course a big school of thought debating how data is presented alongside meaningful interpretation, analysis and context. I’m not going to get into that here, because that’s a whole other topic. But I will say that dashboards certainly have their place in terms of communicating a language of data across the organization, and I think that’s important. How that is messaged, and involved in decision making is beyond the dashboard. We have to remember what we’re trying to do with a glance versus with in depth access.

Approaches to data display

So what we just looked at was a very plain way of presenting data. There’s much more exciting ways to do that! These are actual widget examples of data from one of our beta site galleries.

We just looked at a volumetric – just a plain number. When we think about analytics, we normally think about statistical graphs too. And more commonly, we now think about illustration visualizations. I’m a big believer in offering options for individual choice, because how we prefer to digest data is quite a personal decision.

Visualizations

That last one, opens a whole world of opportunities to get creative. It might seem quite novel in the museum sense, but when you think about it, there’s lots of examples in every day life where we work with these sorts of illustrative visualizations. They can be of benefit both to how we visualize data for our internal purposes, say on visitor behavior, but can also be useful for how we visualize data on our collection, or for content that we’re producing for our visitors – which verges on the brink of embracing data journalism in the museum.

Take the top right here, the isopleth, we might be more familiar with this as the weather map we see on the news every night. These visualizations can be used for anything from visitor dwell time via indoor positioning to showing the concentration of our collection’s origin. Or to portray something about our topic of concern. This example is actually looking at H1N1 cases in California.

Ultimately, you want visualizing that are self organising, dynamic – that don’t need human hands to put them together every time. You’ll also want a degree of self service available, so that your users can pick their data source and how they want to see it and be presented with the results.

How do we get there?

How do we get there? I think this question deserves a whole hour rather than 3 minutes, because this is really a much bigger question of organizational change leadership in establishing a data driven culture, so instead I want to talk about the role a dashboard can play in this journey from ‘what’s analytics’ to daily insight, and that is as a tool for data communication.

These are the top tips I think are important.

  1. The first starts before you implement. As we’ve talked about, spend time analyzing who will be using the dashboard. What information do they need, how often, why and how will they best digest it? Your dashboard project should start with a lot of conversations with your team on this topic.
  2. As you’re implementing, focus on communication, education and training. Analytics can be a scary topic, especially for those who don’t like maths, and you need to take the fear factor out of it. You might also need to support downloadable or even printable reports for a time to match the current way of working while everyone adjusts to the solution, before switching to complete dependency on a live online dashboard.
  3. Champion change – have your board use the dashboard on tablets, have the director reference it live in meetings, put it up in lights on display in staff areas. Make sure your executive team are all well versed in communicating with the dashboard when in discussions with their own staff.
  4. Make life easier – don’t add to the workload of staff, like saying ‘every day you must now do X’; instead make their task load more convenient.
  5. Finally, given we’re in the business of analytics, instrument your dashboard’s performance. How often are people logging in? What staff members are exhibiting particularly high or low use? How can you incentivize usage?

Ultimately, the two scenarios you want to avoid are over or under use. In the latter, we’ve worked with some museums who might put a great deal of investment into procurement of a solution, but don’t communicate or champion the change, and the end result is nobody looks at the data, and it doesn’t get used. There’s also a flip side, of one client we had who used their data aggressively but were a little too hot off the mark and started letting their data make decisions for them, which is not what being data driven is all about. We need to emphasize that the dashboard is there to inform decisions, but equally it is there to be interpreted, questioned, put in to context, challenged.