What exactly is clarity & focus in the context of a Tableau dashboard?
It’s one of those concepts that’s probably easier to recognise than to describe without an example in front of you. The problem here is that when you set out to build a dashboard in Tableau you start with a blank canvas so how do you ensure you arrive at a solution that maintains clarity and focus on the information you’re trying to communicate? My approach and advice to others is to usually approach this problem backwards. Communications is the key goal here. The key aim is to make sure that once the user has engaged with your dashboard, they understand the content and that the design of the dashboard facilitated their understanding in a way that didn’t cause friction with the way they (consciously or subconsciously) expected to engage with that information. If you can do that then you’re on the right track. Doing that is easier said than done, and so I use the following techniques to help me synthesise, for each dashboard I build, the best way to achieve the above. They’re by no means exhaustive but I’ve found they’ve really helped me in situations where I’ve lost my way or a dashboard has gotten the better of me.
This is nearly always the starting point used in the digital and interactive design field, where the idea is that you sketch out the key components of your layout without having to worry about aesthetics and the details that go with that in relation to the project. The benefit is that your layout takes center stage and as a result it focuses your mind on the content that’s going to be part of that layout. No distraction from the tableau interface, no distraction from the viz in front of you with some data issue you’ve just noticed. Better yet, your wireframe doesn’t have to stop with just layout. It’s also partly about interaction so you can enhance and iterate your wireframe to start considering interaction elements like where filters and buttons go as well as how actions will work on the page. Here’s an example of a wireframe I made for a previous visualisation I created.
Notice how text in most cases is reduced to squiggly lines, sections and charts reduced to shapes and lines. It’s pretty much the only way you can isolate a fundamental part (layout) of your visualisation, story or dashboard and make sure that it stands up to scrutiny. If the backbone of your design is wrong from the start, you stand to make your job much harder further down the road. To find out more about wireframing check out this guidetargeted for web design but the principles still apply regardless of the platform or medium you’re designing for.
One of the most common bits of feedback I hear from first time users or organisations dipping their feet into it for the first time is that they achieved more in the first week of using Tableau than months of using another tool. This is a strong testament to Tableau and the well thought through feature set in the product, along with the fast pace of development that they continue to maintain and invest in. Downside? … over time it makes it even easier for feature creep to take over your dashboard. I’ve seen beautiful, minimal, fast dashboards turn into multi filter, parametrised, multi action monsters with features for every organisational unit under the sun. Occasionally stakeholders lead you the dashboard developer down this path but I have to be honest and argue that as “dashboard builders” we don’t always help ourselves in this case. In our excitement to showcase the tool, we can often raise the level of expectation to astronomical levels, a place where every dashboard user feels they have an input into the design and build and expectations are set beyond the realms of a visualisation tool and more into the realms of code heavy web development project. When building, achieve your MVP first. Eric Reys termed this as “a product which has just enough features to gather validated learning about the product and its continued development”. In short, build only what people asked for and carefully manage expectations for new features not previously scoped. This keeps you in control and your users marching to the beat of your drum, rather than theirs.
If we take a step back and look at visual best practice, it recognizes that through out our evolution, we’ve evolved an efficient way of categorizing visual information, grouping similar visual elements and organizing them into meaningful patterns, infact we’ve gotten so good at it that it’s part of conscious as well as subconscious cognition. This concept is known as visual hierarchy and we’re constantly using it as a way of digesting large amounts of disorganised information into something we can quickly process. Below is an example where I use scale, colour, positioning, symmetry and asymmetry to highlight how your eyes navigate the image.
In Tableau this concept applies more to dashboards where you might have multiple views, titles headings and filters in a single page. Without hierarchy, it’s difficult for the user to know where their journey should start and what they should do once that journey is complete. All in all you’re trying to reduce the cognitive load for the user, a concept outlined really well by Helen Kennedy and Andy Kirk (links 12 minutes into the segment of the show that covers this topic).
In conclusion these techniques help setup a framework that helps keep you focused on the communication goals for your dashboard. Maintaining clarity and focus doesn’t necessarily mean your visualisation can’t have advanced features, or take on new features in response to user feedback, instead we just seek to ensure that those features being added or considered contribute towards the main challenge of visual communication rather than take away from it. I’d love to know your thoughts on this, have you tried any of these techniques, do they work for you? let me know.
