This year, I have a goal to walk or run 1000 miles. It’s part of the #Walk1000Miles community run by Country Walking magazine. Tracking my progress with Strava and Tableau is a vital part of the fun for me.
[Before we continue, a quick note on distance units. As a proud European I measure my exercise in km, so that’s why everything’s calibrated to the number 1609km, the metric equivalent of 1000miles. It might not be a round number, but 1609 is a prime number, so it’s inherently a cool number, right?]
I needed a dashboard to track things and I developed the mobile version in parallel with the desktop version. All design decisions was made with mobile and desktop in mind simultaneously. My end result is now working just how I want it to on Tableau Online, and looks great in the Tableau Mobile app. I’ve also uploaded the workbook to Tableau Public, which you can download.
During the design the process, I asked myself several key questions, which you should also consider when developing your next dashboards. Don’t leave mobile design until the end: build for mobile as you build for desktop.
Do you need a mobile version of your dashboard?
This one is simple. Yes, you do need a mobile version.
You need to get the data to where people are. Our job as analysts is to engage all users and that means giving them a good experience where they are, not where you want them to be.
Designing for mobile gives you a creative constraint. In my recent Data Viz Debate with Andy Kirk, he raised the excellent point that when you have a constraint, such as a small screen, or static charts, it forces you to think more clearly about your purpose. When you are constrained to a mobile screen, the clarity of purpose it mandates creates a better desktop version, too.
Do you need all the KPIs on your mobile dashboard?
I have 4 KPIs on my desktop dashboard (total distance, % of goal, average distance and number of activities (highlighted above). They are all useful, but only the first three are directly related to my goal. In the mobile version, I only show the first 3 KPIs. Number of Activities is useful secondary information, but my mobile version focuses on the primary dashboard question, which is purely about my 1609km target.
Should it be portrait or landscape?
I believe mobile dashboards should be designed for portrait mode. Most phone usage is in portrait mode (92% according to some sources). Mobile video has already begun to switch to vertical, and I think mobile dashboards should go the same way. You should design to make the user’s life easier, not harder. Which leads me on to the next question…
Should it fit on one screen?
The classic definition of a dashboard states that they should fit on a single screen. If you can get all your info on one screen, and maintain readability, that’s great. However, using our thumb to scroll is so fluid and fast, we no longer need the single screen constraint: it is fine to make the dashboard scrollable.
In my dashboard, I made a couple of choices:
- The line chart showing how average distance has changed over time deliberately overlaps the bottom of the screen. This suggests to the user that there is something further to discover by scrolling
- The lower half of the dashboard focuses on the historical data. This is secondary information, needed only to delve a bit deeper into my data, after the first look at progress to my goal. This layout creates a sense of two “pages”. The first is focused on my 1000m goal, the second is deeper contextual analysis.
Which text can you remove?
In moving to mobile, I had to pare down the amount of text on display. Below are two areas I could safely remove/hide:
- I removed the contextual text beneath the KPIs. It’s good to see the targets on the desktop, but space is too tight on the mobile version. I make an assumption that the mobile audience are familiar with what the goals should be (of course, for this dashboard, the audience is me!).
- The text on the right hand side is really important. The top section is a written summary of the primary goal: am I on target, and by how much? It also contains a description of the dashboard. Where should this go on mobile? I chose to hide this behind a Collapsible Layout Container. The info is there, but on demand.
Those are the five main considerations I followed when designing the mobile version of this dashboard. When you design your next dashboard consider how you get the data to where your audience is, which primary questions you will answer on your dashboard, what you can remove on the mobile version, and how you can limit the text on display.
What other tips do you have for mobile designs? Let me know in the comments, or on Twitter (I’m @acotgreave).
And finally – you can follow my progress, or download the workbook, by clicking here.