Back to the Drawing (Dash)board

If you’ve been following my blog, you’ll know that I’ve been writing about how I created my HIPAA breaches dashboard. I recently completed my reviz of it—finished reviziting it—by going Once More Unto the Breach, so now I’m going to start blogging about the reviz as well, by going Back to the Drawing (Dash)board after initially Dash(board)ing Through the Snow! 🥁 (And I’ll be back to go through how I made everything in my revizit as well, of course.)

I’ve learned a lot in the months since I made that dashboard, so I’m back with some more tips for creating a(n informational) dashboard, but before I get into those, let me just talk about the changes I made, as well as my goals with the revizit.

We were asked relatively early on in training to remake our application vizzes, and I received a lot of valuable feedback that I finally had the time to implement after training. While it was great to come back to this project, it was a bit of a challenge as well; on one hand, familiarity with the dataset meant I needed to do less data investigation before analyzing it, but on the other, I was also quite attached to the elements of my original dashboard and spent a lot of time trying to figure out how to retain those elements, when I didn’t really need them due to my data story changing (a bit), in retrospect.

I started making changes to how I went about creating this dashboard from the very beginning, with the data preparation, as well as when I was gathering the data, as I got more updated data about HIPAA breaches and added in more years’ worth of Census data. I originally joined my two datasets (HIPAA breaches and U.S. Census) in Excel, but I wanted to recreate the process in Alteryx, not just because I wanted additional Alteryx practice, but also because I like how Alteryx workflows are self-documenting (and okay, maybe I forgot what I did when I was prepping the data in Excel all those months ago).

I had two primary goals with remaking the original dashboard—I wanted to include more interactivity, as figuring out how to do that has always made me nervous, and follow best/better visualization best practices. To that end, I worked on not hiding important information in tooltips (including only supplementary information in them instead), created clearer sections that also dedicated space for instructions, and creating a strip dot plot for the third section (“Breaching for Impact”), which replaced my original dashboard’s map in the second section (“Breaching for America”).

Note that I didn’t mention changing anything about the insights; that hadn’t been part of my original plan because I was just thinking about how to convey the same information more effectively. However, because I ended up adding more data to the reviz (mostly U.S. population estimates for different years—I’d only had 2021 Census data originally), my data story also changed a bit. Unfortunately, because I was still quite attached to my original data story, I tried for the longest time to figure out how to make the “Breaching for America” section fit with the rest, before finally accepting that while it served its purpose in the original dashboard, it was no longer as useful (or needed, really) for my updated data story/dashboard, especially because I wanted to rank states according to certain metrics, and the original map section wasn’t conducive to conveying the new information I wanted to include.

Anyway, moving on to…

Tips

  • Plan, plan, plan. I’ve already talked about this ad nauseam in the original Dash(board)ing Through the Snow blog entry—after all, that was what the whole entry was about—but I find that I can’t stress this enough.

    In addition to planning out the dashboard as previously discussed, I want to add that it’s important to plan out your interactivity as well. This can be as simple as jotting down a note about what you want to happen when a user clicks on a bar or a point on a line, for instance, but map out that user story early on, as it’ll help you keep your goal (your ‘why’ for doing something) in sight. I feel like had I done that, it would’ve been easier for me to let go of the original “Breaching for America” map section in my revizit.
  • Start simple. Reiterating another point from my original blog entry, I can’t stress this enough, either. This means starting off with building a static visualization before adding in parameters, before creating parameter actions. Starting off with that static visualization before making it dynamic helps you figure out what kinds of pills you need in the view, before figuring out what the calculated fields you’ll need look like. Then, when you add in your parameters, you can check that they’re behaving the way they need to be, before you translate them into parameter actions.

    Layering in the complexity one step at a time allows you to make sure you’ve built the intermediate stages correctly, as it’s of course easier to figure out what went wrong when there are fewer/simpler elements in consideration. Not only that, it’ll save you headaches later; if you’ve built everything without checking that the foundation works, it’s harder to go back and retrace your steps.
  • That being said, don’t be afraid to troubleshoot. It will be more difficult to troubleshoot more complex functionality/calculations/etc., but you can and should still do it! I find that the most effective way for me to troubleshoot something is to right-click on the sheet I’m working on and Duplicate as Crosstab, which will give you the viz you’ve been building, but in table form. You can check the values in the rows and columns to pinpoint the exact spot where things aren’t working as expected.
  • Set aside time for formatting. You need time to make your dashboard follow visualization best practices, so give yourself that time. As I mentioned earlier, one of my goals in remaking this dashboard was to visually convey insights more effectively, and it took some trial and error for me to figure out how I wanted to make clearer sections, how I wanted to make clear the interactivity built into each section, etc.

    For me, some of this time was devoted to that kind of experimentation (especially when playing with padding and things like that), revising/updating my Excalidraw sketch so that I could just reference it to know where all my containers were, and noting font sizes and colors for certain things.
  • Important information should not be hidden in tooltips. You don’t want your dashboard to be too wordy (a visualization is worth a thousand words, and all that), but you don’t want to leave your users/audience with too little context, either. For example, in my original dashboard, I’d hidden the daily rate of HIPAA breaches in tooltips, when that’s actually really important for contextualizing just how often the U.S. is affected by these breaches. Information that’s just “nice to have” is okay for tooltips, but things that are critical to know should not be there (I also learned during training that people often don’t look at tooltips or even know that they’re there).
  • Don’t be afraid to make changes. Going back to my struggle with trying to make one of my original dashboard’s sections work with my updated version, recognize when something isn’t working anymore, and take it out. You’ll find that whatever wasn’t working didn’t need to be included anyway, at least in its original form (while the map didn’t stay in the final version, the dot strip plot conveys a similar insight that was built upon the original one, so I did “keep” it to some extent).

    It’s important to remember that just because you built something doesn’t mean it has to be included in the final iteration because it may have been useful to you while you were conducting your analysis, but it may not be the best way to convey the information to your audience. As mentioned in my original entry, how you understand the data =/= how the audience understands the data. Add in the functionality that would best fit the objectives, and always keep in mind how your users will be using the dashboard.

That’s it from me (for now)! I will be back to talk more about how I created the reviz soon!

Author:
Vivian Ng
Powered by The Information Lab
1st Floor, 25 Watling Street, London, EC4M 9BR
Subscribe
to our Newsletter
Get the lastest news about The Data School and application tips
Subscribe now
© 2025 The Information Lab