Preview Mode Links will not work in preview mode

The Digital Analytics Power Hour


 

Please visit the show's site at analyticshour.io

Jan 20, 2015

Episode 002 finds Michael, Tim and Jim tackling one of the most important, powerful and sometimes frustrating deliverables to any business analyst: the dashboard. What exactly is a dashboard? What are they for? What should they accomplish? Why can't Tim and Jim agree on anything? Prepare for lots of strong opinions and stories from the trenches in this week's 40-minute power hour.


Justin Goodman
almost five years ago

Part 2:
Now that we have established a bit of what goes into a solid dashboard, lets talk about how to get there.

Discovery. Start with what’s important to the consumer(s). This is a really important piece. Nothing with a dashboard starts without know what needs to appear in the end result. This is also the time to get what type of context is needed.

Once you know what you need in the dashboard, now you need to know where it’s coming from. Sometimes this is an API, others its a database or flat file, and sometimes there are predefined elements that live in the dashboard (goal values for example). Understanding the source data and getting everyone in agreeance here is important. If you have different teams pulling the same "kpi" from different data sources, you have a problem.

Once you have the data requirements, and the data sources, confirm with all involved any calculations that are performed. While there are "standards" for most KPIs, it is not uncommon for a team to use a non standard definition. If it isn’t confirmed early, you can end up in a mess if a formula is assumed and data is presented that doesn’t match what it should.

Get a prototype working. Its one thing to "sketch" what you want it to look like, and to know what you want in the dashboard, its a whole other thing to get the data connected, get the formulas working, and get the visuals par baked. For some consumers, this is a good time to get buy in and confirmation of all of the data in the dash. For others, it can cause more harm then good to show anything but a final product. Ty and learn your audience during the discovery phase.

Once you get a go-ahead on your draft, now its time to get everything cleaned up. Clean up the presentation, get those colors, in check, ensure visual priority is still working as expected, and follow brand guidelines as needed.

Got everything looking good, data is in place, lets ensure that data can be refreshed and automated. If you were working on a local dataset for the building process, now it's time to hook up to the real data (already agreed upon source).

Get feedback, but get it from the end consumer. It is often the case that the middleman has feedback that may or may not be relevant to the end user. Skip the middleman.

Revise, and send it off with confidence. You built it to defined needs, you made it look beautiful (see definition of beauty above), you iterated based on feedback. You are done, for now. Stand confident in your delivery, you provided what you needed to. Set that refresh interval based on the ability for the consumer to react, sit back and relax. Ok, you are done relaxing, rinse and repeat, you are going to have to make another dashboard for another consumer, the marvel that is your data visual work of art is being shared and demand is increasing!

Justin Goodman
almost five years ago

Ok, this is a long one, and was written on the plane after listening to the podcast. Its kinda like a diary to myself and or others I may have shared the podcast with. However, i wasn't sure what to do with it, so....here it is.

I was listening to the Analytics Power hour on "what is a dashboard" and felt it necessary to one, share the podcast, and two provide my feedback. The short takeaways from the podcast are, dashboards must be hyper-relevant, the must be organized for the consumer of the dashboard, delivered at the appropriate interval, they should be one page (possibly with supporting pages depending on the audience) and they should provide an at a glimpse view of the key performance indicators. There is nothing in these takeaways that I can disagree with, however there are perhaps some things that should be taken into consideration.

Starting with the KPI is a great first step. This ties heavily into the Hyper-relevance and the KPIs need to be determined through strategic planning with the person consuming the dashboard. Period. Through experience and practice, having a middleman, or middle team that is identifying these for someone else does not work. The cost of building the dashboard increases rapidly as you are inevitably going to be redoing the data extraction, reworking the cleaning and transformation rules, and possibly changing the data visualization depending on the severity of the change.

Key Performance indicators are points of indication and are NOT segmented. This is a critical distinction, and why hyper relevance is important. If you are the Marketing Project Manager for display advertising, your KPI is not going to be net revenue, but it may be display-influenced revenue. You are not looking at a KPI segment here; you are looking at a different KPI.

Dashboards give you that at a glimpse view, and to the right stakeholder (dashboard consumer) with the right KPI, minimal context goes a long way. However, minimal context is needed. Having a single fact (KPI) with no context doesn’t provide a kicking off point for future analysis. In the podcast, this is the distinction of a second layer of reporting per each KPI. Understand how to provide the context can be almost as important as defining the KPI, Context can come in many forms and needs to be well established and identified up front. For example, is it important to see progress vs. an established time based goal, do you want to compare to performance last period, or is a year over year comparison important. Understanding content up front will help reduce iteration in the dashboard design and save both the analyst and consumer a lot of time and frustration.

Organization is important and prioritization of the KPIs should also be understood and defined in advance. A solid dashboard will have a limited set of KPIs on display. They have been narrowed down from the plethora of data that is available. Once you have the best of the best on the page, what is the most important of these, if you could only read the first 1 or 2 before you ran into a meeting, what would they be?

Dashboards need to be flexible in their ability to adapt to future needs. This was a concept that was kind of tossed in at the end of the podcast. Adaptability is always important, while changes may be minimal; it’s nice to plan for the future. I think what stands out here is understanding that a dashboard today may not be the same next year, but most likely the business objectives (KPIS) wont really change that much, so while it should be considered from a technology perspective, changes wont be "quick", they will require changes in data, and changes in presentation.

A very important aspect that was not touched on in the podcast was the automation ability. To maintain consistent, clean data, the tools to manage the connected data and the dashboards should be capable of being automated, and that capability should be leveraged. Dashboards are intended to have a rapid consumption, with that they should also have rapid updates! Significant time and effort should go into building the first iteration, it should be built to be refreshed and to be automated with minimal to no effort.

"Beautiful" does not mean fun new ways to look at the data. Line charts, bar graphs, and highlighted metrics are perfectly acceptable means of delivering data. There is a reason they are "common", they do the job and can do it well. We don’t need bubble charts, doughnut gauges, multi dimensional area charts, etc. just because they look fun. A beautiful dashboard is beautiful because it conveys the data you need to see with ease, not because its fun colors and charts that nobody else is using. Now, I understand branding can be important, so despite some of the "best practices” around colors I do appreciate something that clearly resonates the brand. A dashboard for Coca-Cola that didn’t include their signature red would feel out of place, and with a signature red brand color, maybe negative trends shouldn’t all be red?

Dashboards are not action driving on their own. To the wrong person, they wont provide the context to drive action. However, to the right person, they inspire curiosity or answer questions. If additional context beyond the basics around the KPIs for the moment in time dashboard is required, it was designed for the wrong person.

Dashboards do not have insights and analysis on them. Remember, these should be automated; they should provide a glimpse into the KPIs. If someone is doing analysis and providing insight on a "dashboard" then it’s no longer a dashboard, or it is being used improperly. Reporting and Analysis in conjunction can provide insights and next step action items, but often even with analysis, conversation with the end report consumer is important pre, during and post analysis to ensure that everything is on track. Analysts, particularly in a consulting and agency situation are far removed from the interworking’s of the company, so analysis may be completely off pace without the conversation.

Now that we have established a bit of what goe