Webinar Summary | Avoid Dashboard Fatigue | RStudio (2020)

One of the challenges that we've seen time and time again is that there's often a gap between data scientists and those stakeholders they're hoping to inform. And that gap a lot of times is the result of different mediums. And so that creates a problem for us is that if we just wait for decision makers to proactively go visit our work, we're not actually closing that gap.

But that's one problem. We also see something else kind of interesting happen as data science teams try to close this gap. And so one thing, as we said, is that maybe the dashboards fall by the wayside. Another thing that can often happen is that stakeholders will get excited. They'll say, great, this insight makes sense. Can you bring it to my medium? Can you copy and paste those predictions into my spreadsheet? Or can you send me a screenshot of that plot so I can put it in my presentation? And that leads to a lot of painful, labor-intensive work.

The solution: proactive email notifications

But I'd like to propose for you today an alternative, a solution that we've found a lot of success using ourselves here at RStudio. And so what does this solution entail? Instead of creating a dashboard, what we like to do is create a proactive notifier or something that is going to alert me to the information that I need to know. And in our case, we spend most of our time inside of our inboxes. So that's where our alerts go is through email. And so that's what we're going to talk about today is how you can use a rich set of R packages to allow you to create these proactive notifications.

Oftentimes these notifications need to meet the expectations of our stakeholders for how they're formatted. So we'll look at some new packages that are available to help you precisely format these results. And then finally, we don't want to solve this dashboard fatigue problem by introducing another type of fatigue, which would be email fatigue. And so we're going to talk about how you can only send these alerts on conditions so that instead of sending emails every day, you can send emails more specifically when there's a problem at hand. We also don't want to introduce data science fatigue. So we're going to talk about how we can achieve these proactive notifications in an automated way.

We don't want to solve this dashboard fatigue problem by introducing another type of fatigue, which would be email fatigue.

The picture that you're seeing here is one of my favorite examples of this workflow. One of my roles at RStudio is to keep track of all the different R packages that we build and maintain. For some of you on the line, R packages might be a newer thing. So briefly, they're sort of the bread and butter of how data science gets done in R. They're also one of the main things that we're responsible for at RStudio is creating these different R packages. And so every day, we go and we build all of these packages. And we want to know if any of those builds fail, especially if it's a really popular package. We don't want to get a whole bunch of emails from users saying, hey, this package isn't available or doesn't work. We kind of want to stay ahead of those types of problems.

And so what a data scientist named Greg and I came up with is this workflow where every day we run these builds. And then if there's a problem, and critically, only if there's a problem, do we get these types of targeted emails that tell me exactly what the problem was and allow me to then take further action.

Real life success stories

We're not the only ones who are kind of using this pattern successfully. So I just want to tell you a few quick stories before we get into the weeds of writing the code. One of my favorite stories is from a large infrastructure as a service provider, so a company that maintains thousands, if not hundreds of thousands of servers. And what they use this workflow to do was track their hardware uptime. And then if they saw a problem arising, they could send a proactive alert out to their vendors in the context of their support level agreement or SLA. And what this team was really excited about is before adopting this workflow, they had done this type of task in JIRA. And any time they onboarded a new vendor or they modified their SLA, they had to manually click through a whole bunch of steps in JIRA to accomplish this task. The great thing about this workflow is that it's all based on code. So it's really easy to reuse these different rules and different R Markdown documents that you're going to write. And so this allowed the team to easily cut down their onboarding time.

Another really awesome story of this type of technology applied was in a high-tech manufacturer called People Ops Department, so kind of an HR group. And they had this challenging task where they needed to notify division managers about employee overtime problems. So say an employee worked more overtime than they were allowed, they wanted to send out an alert. And before, they had a dashboard. And what they found was there are 30 different division managers were not reliably going to that dashboard every day to check if there was problems. And so they adopted this workflow to instead send out an email to a manager only if there was actually a problem with a specific employee's overtime submission. And they actually won an award of excellence for adopting this workflow, which I think is really exciting because it's ultimately a pretty simple concept that we're talking about here. And so if they're able to win excellence awards, I think that's going to be accessible to a lot of teams as well.

It's ultimately a pretty simple concept that we're talking about here. And so if they're able to win excellence awards, I think that's going to be accessible to a lot of teams as well.

Demo

So this is our main document, our main report in Kinect. So it looks great. We actually have a history of these documents. They'll be published every day. But to do that, you actually have to set it up. You actually have to go to Schedule and then schedule this output to be run every day. So it'll take all your code, it'll run it every day, maybe on different data. That's kind of the hope because what happens is it'll be connected to a different data source, well, the same data source, but it'll be updated every single day. So we'll get different data and possibly different alerts. So in this day, we did have a few problems that are aligned here in red.

So that's great, but we have to check this every day to see that there's a problem, right? When we send email, we can send it when there's a problem and we don't have to be checking. This is almost the same problem as the dashboard having a report here, but the email sort of like solves that problem. So to schedule that, we schedule it every day. And the key thing is to send an email after update. And then we set some recipients. It could be Sean, for instance, here. Oh, sorry. We have to go here first and have him be on the list. Sean. Great. Now we can save that. And now we have this master list of people that can view or change this document and we can schedule Connect to send email to those recipients through here.

So I'll just do this one more time. This is kind of cool. Great. And we'll save this. Brilliant. So every day it's going to be run and we can change this, of course, but this is daily data. So it makes sense to send it every day and it will send an email only if the thresholds were exceeded. And we can actually preview the email, send one to us yourself just to sort of like debug the email and make sure it looks good before it actually goes out for Legos production. So I can send this. And I actually happen to have one open. So it shows it to me right here. This is my email client. So we can see that the subject here is one of our KPIs and parentheses three. That's the blue work that we did here to look seed broke thresholds and we have the list of things here, which is great, because if you look at this in your list of messages, you see this right away before even opening up the email and the body looks really good. This actually looks really wonderful on a small device because the text is quite large. We have just the important things which are the table, a little bit of text just to sort of show what's being shown. And importantly, here's the attachment.