Designing mobile data tools can be intimidating particularly because we think we don’t have a lot of space to tell the same story we would with other devices. The format of data tools – including dashboards – for phones can appear rather limiting, but that’s just a myth. While it would be nice to be device agnostic – where we ignore the different methods data is now consumed (phones, tablets, desktop, blah, blah, blah) – we just can’t. It’s not best practice. We consume information differently by device so we need to design around each experience. Given the shifting landscape of how we consume information (hint: it’s increasing mobile) we need to developing appropriate data tools now. With that, here are five device agnostic data tool development best practices I follow (but are prioritized because of a mobile design).
Tell a clear and direct, but guided story.
This is my number one rule for any dashboard or data tool. Remember that our tools should answer the initial question asked by our stakeholders. But as we answer the question we should also shine a light on a what is likely a deeper actionable issue. To get to the actionable issue we need to provide context – and this means allowing users to “explore” the data. I use the term explore loosely because we want to give them the feel that they are diving into the data and blazing their own trail, but in reality we have curated the data and we are guiding users through the story. This is approach is similar to the one followed by the authors of Data Fluency. Don’t be afraid to come up with a storyboard of how you want to guide stakeholders.
Use the least astonishing: Scroll first, then swipe or tap.
Consider the principle of least astonishment: if a necessary feature has a high astonishment factor, it may be necessary to redesign the feature. This means keep it simple and choose what audiences expect, which is usually scrolling down/swiping up. From a storytelling point-of-view when you scroll down/swipe up you keep the story on a single page. This makes going back and re-reading or re-interpreting something a lot easier than swiping or tapping.
When it comes to dropdown menus, use parsimony.
First, try to avoid dropdowns all together. But if you need a number: limit yourself to three dropdown menus. If you can get users to the exact source of data they need, do that. Dropdowns that apply filters or parameters make visualizations complicated. It’s not that dropdowns are bad, they just need to be customized for a mobile device. Affording each dropdown it’s necessary space takes away from the functionality of the data tool. Don’t forget that dropdown menus are going to have low discoverability – meaning you will have to touch the dropdown menu to know its there. One last thing, users like to see all of the options in a dropdown, so consider that space, as well.
Cursors don’t exist so skip hover functionality.
With desktop dashboards and other data tools we often hide additional data with tooltips (that extra stuff that shows up in a small box when we hover or click on something). Sometimes tooltips show up with a hover of a cursor – when you are using a desktop with a mouse, of course, and other times tooltips show up with a click or a tap. Once again, consider discoverability: Since it’s impossible to tell when a visualizations are going to have a tooltips – unless you explicitly state it – its best to avoid them.
Let the data and visualizations breathe.
Keep your visualization organized: Grids are good. Larger fonts are good. Consistent formatting is good. And don’t forget white space is good. Yes. White space. We don’t need to cram things in – but you already knew that. If we can give our audiences some space to process the findings then we don’t need to simplify our data tools to a few basic charts. More complexity should be accompanied with more whitespace!
Just one last thing: designing a mobile format is a blessing. We don’t feel the same obligation to fill an empty space on a dashboard – even if it doesn’t add value. Mobile tools force us to think about what’s important and actionable. This pressure allows us to make better visualizations and better tools, which should – if done right – lead to better outcomes for our stakeholders.