Dashboarding: Design Before Diving In
Date: 03/02/2017

By Ruban Lawrence

Back in my salad days, I used to be that guy. We all know that guy - he leans back in his chair confidently, cracks his knuckles, and then dives right into a project without any planning or preparation.

"Pffft. Planning is a waste of time. My time is best spent actually DOING work rather than PLANNING it," I thought.
And for many years, this worked just fine because my projects at the start of my career were relatively small in scope. But as the projects I worked on grew larger, this "diving in" methodology I'd used for so long no longer really worked. Especially when working on dashboarding projects, I found that after the initial build, I'd end up in a never-ending cycle of:

- user review
- receive user change requests
- complete change requests

I ended up taking Stephen Few's course "Information Dashboard Design" [www.perceptualedge.com],  where I learned about how to present information effectively, densely, and intuitively. One of the biggest takeaways for me was the importance of spending a fair bit of time DESIGNING something before actually BUILDING it.

How do you go about actually doing this, though?

First, you need to find the design tool that works for you. You can use whatever works best for you - and the tools can be surprisingly basic. Pencil and paper are excellent tools because they're very natural to use and they don't get in the way of designing. Computer design/drafting tools have their purpose, but when you want to do something simple like draw a 1 x 3 table, you can do it in a few seconds with pencil and paper where it might take a minute or two to do such a thing in a computer-based tool.

The exception is a tool like Apple's iPad Pro/Pencil combo. With the right app, the iPad Pro provides an electronic version of paper that is the best implementation I've ever seen [Except for maybe ReMARKable coming out next year (www.getremarkable.com)].

Next, you need to gather information. LOTS of information. You need to interview the people who will be using your dashboard and ask them about what they need. Good questions to ask are:

  1. What is the most important information you need to see?
  2. What type of presentation is most helpful? Visualisations? Tables of numbers? A combination of both?
  3. Do you need to be able to have the dashboard on-hand and usable whether you're online or offline?

Once you've gotten some basic information, you'll want to look through the types of information your users need to see and rank it from most-important to leastimportant. A way to do this is to apply Stephen Covey’s task priority matrix, and apply his matrix to the information in your users’ dashboard. Categorize the information to be displayed as:

  1. "urgent and important"
  2. "not urgent and important"
  3. "urgent and not important", or;
  4. "not urgent and not important"

You’ll want to make sure your users see information in category (1) first when they open the dashboard. Category (2) items can then be placed secondary to category (1) items. Category (3) items most often don’t need to be on a dashboard, and category (4) items should not be on a dashboard at all.

Now go through and think of effective ways to display the information. Maybe draw some sketches of charts, or tables. Perhaps a collection of micro-charts on the front page to provide an at-a-glance summary. Doing this will undoubtedly generate a plethora of ideas. I always find that coming up with the first couple of concepts is hardest - but once I've thought of the first couple of charts or tables, I start to get more and more ideas. Don't get too hung up on a specific idea - just write them down or sketch them so you've recorded them.

Once you have conceived a number of different types of charts, tables, and other visualizations, it's time to draw an initial framework for your dashboard.

Now comes the fun part - go CRAZY.

Draw up a mockup. Sketch in objects wherever you'd like. Rearrange them. Or don't. Draw in navigation controls if it makes sense to do so. Try putting things in different positions. Title objects, experiment with how large things should be relative to one another. It doesn’t have to be perfect, and you don’t have to be an artist. Just sketch as well as you can because the main reason you’re doing this
is to make building your dashboard easier. You don’t have to have an exhibit at the Louvre.

Once you've gotten your dashboard sketches to a point where it looks reasonably put-together, sit down with your users and show them the concept you've drawn up.

Inevitably, you'll receive lots of feedback. Your users will want this title over there, or they'll want that chart completely scrapped, or they'll want your navigation controls moved, or any other number of things.

And here's exactly where you will reap the benefits of DESIGNing your dashboard before BUILDing it in Cognos. Something that to an end-user seems very simple to change (eg. "Can you move this title from the left to the right side of the screen?") can require many steps and lots of time to do in Cognos. But to make such a change on a hand-drawn concept is as simple as erasing, blowing
off the dust, and re-sketching it as per your user's request.

If you go through a few iterations of drawing up concepts, getting user feedback, and making the requested updates, pretty soon you'll have an almost complete dashboard concept.

You'll have a design framework mapped out that you can build in Cognos that will closely match what your users would like. Once you've gotten your design mapped out in this way, I recommend you make a copy of it to continue onto the next stage.

Conclusion

If you'd like more information on how PMsquare and Cornerstone can help you develop effective and useful dashboards for your organisation, please reach out to us at:


Australia Singapore, Philippines, Thailand     United States
Cornerstone PMsquare | A Cornerstone Group Company     PMsquare

Call +61 1300 840 048 or
email Piers Wilson
Call +65 6635 1700 or
email Carsten Brandt
    Call +1 (630) 607 0570 or
    email Chris Loechel


Blog post shared courtesy of PMsquare US