We’ve seen a lot of dashboards, which means (inevitably) we’ve seen a lot of dashboard mistakes. There’s no shame in this (we’re all human, after all), but it doesn’t mean that those mistakes need to be repeated!
Sean Warren and Alex Stark are two of our sharpest dashboard experts, and spend a lot of time working with our clients to optimize their dashboards. They shared some of their key insights with customers at our 2017 User Conference in Austin, Texas.
Dashboard Designer Mistakes
The Dashboard Designer is where you build dashboards (simple enough). While the interface is designed to be very user-friendly and intuitive, there are a few things that can hiccup newer users.
- When in the builder, you’ll see two arrows – one on the left frame, and one on the right. The left frame arrow is (to borrow Sean’s wording) a DANGER ZONE! If you’re making changes that you actually want to keep, you always want to move forward and use the right arrow. Moving backwards will create a discrepancy in your dashboard and give you an ugly, incomplete view.
- When making changes, you’ll notice a little red flag on your charts, as well as the dashboard as a whole. This means that you need to save your changes, so don’t close your web browser!
- If you’re use the desktop application, you’ll get a warning when you’re attempting to close without saving your work. Just a little way to let you know that we care!
Preventing Headaches with Smart Naming
Organization is crucial, especially when it comes to dashboards. Sean shared some best practices on where to save your charts and how to name them. Turns out, simplicity is key. Save your charts in their final location whenever you can. It’s easy to move dashboards once they’re ready to “publish”, but charts need to be moved individually. Especially if your dashboard has numerous charts, this can be a huge pain, so save the heartache and save them where they’re going to end up.
Keeping a clean naming convention for your charts is also paramount. You don’t have to get too clever with it, as it’s really for your own organizational purposes. Sean recommends taking something from the dashboard, a descriptive word, and beginning every chart name with that term. This makes for easy searching and sorting, especially if you need to build new dashboards from those same charts.
Drill Down Drama
Drilling down in iDashboards is very intuitive, but when you’re building, you can get a little tripped up. If you saving your dashboards when you’re in drill down mode in one or more of the frames, then that drill down will be the first thing that the end user sees. Worse than that there’s no way to drill back!
Fortunately, there’s an easy fix. Simply open the chart in the dashboard builder and resave it on the correct frame. You don’t even need to resave the drill down, because it’s already hooked up with the chart.
Filters, Functions, and FASTER!
There are a lot of ways to slice and dice your data in a dashboard. However, just like any tool, if used improperly there can be complications. We’ve had customers throughout the years call us up and complain about slow load times on their dashboards. When we dig into their build, they’ve put individual picklists on each of their charts. This can drastically affect performance, because each picklist has a corresponding parameter that’s loading each time. An easy fix is to set a dashboard-level parameter, one and done.
The opposite problem is when your dashboard is showing too much data! If you’re building with large data sets, make sure to not forget your functions in the Axis list (Sum, Avg, etc.). Otherwise, you’ll be viewing raw data.
No matter what kind of data you’re displaying, you’ll want to help out your end user with some labels and legends. There is a default mouse-over legend that might be sufficient, so long as your users understand that’s a functionality that exists. Colors can also make a huge difference in the navigation of your dashboard. If your corresponding charts use the same colors, it’s naturally much easier for the end user to make the connection between the data points. You don’t’ want to confuse your users, or hve them conflate non-corresponding data points. Just use unique colors by metric!
Data Source Sore Spots
It’s easy to blend multiple data sources with iDashboards, but there are a few things you’ll want to keep in mind to avoid any hiccups. If you want excel files into iDashboards, use the Auto-uploader in the Data Hub or the Admin portal. There is technically the option to load an excel sheet into the chart directly, but then it only lives in that one chart! It’s also static, meaning that it doesn’t interact with other charts or update.
Another point about Excel – don’t change any of the names! File name, column name, named ranges, anything. You can always add more columns, but iDashboards will point towards the file with those names. If you change the data sources, you’ll break the chart. A good rule of thumb is to not have the data source named with a date or anything else that would have to change regularly.
And of course, like any machine, we are bound by the law of Garbage in, Garbage Out. If your data is bad in Excel, it’ll be bad in iDashboards. If people can manually edit the data, this can affect your data integrity and the trust in the dashboards, which undermines the dashboard project in general.Don't rollout expecting instant adoption without input! #focusgroup #dataviz Click To Tweet
Final Philosophical Thoughts
Like many of our presenters, Sean and Alex re-emphasized the importance of storyboarding. It’s so crucial to include end-users early and often in the development process, as well as throughout the lifecycle of the dashboard projects. You can’t rollout expecting everyone to adopt without input. This is especially true when your metrics are changing regularly, which could also lead to shifting priorities or KPIs. Remember, dashboards are not static objects and never truly done!
For more updates from our 2017 Users Conference, follow us on social media @iDashboards with the hashtag #iDashboards17!