Dashboards: A Force for Good, Great, or Greater Confusion?

In this era of big data and real-time data sharing, projects and organizations are increasingly trying to organize their analytics with dashboards that share key insights at a glance.

At the 2015 MERL Tech conference, we shared our experiences and learning from designing dashboards for development projects. Our panel presentation unpacked the process of designing dashboards thoughtfully and promoting their use for data-led decision making, including both what worked well and challenges we’ve faced as dashboard designers.

Based on our presentations and the discussion that followed, here are five key takeaways for anyone embarking on the process of designing a dashboard:

1.  Identify what questions your dashboard needs to answer. It is important to figure out what questions you need the dashboard to answer before you begin building your dashboard. This will impact how the data is captured, recorded, and visualized on the dashboard. Thinking about purpose and audience upfront will save you time and money throughout the design phase and ensure you have a product that meets your users’ needs. Does your dashboard mainly need to  inform program decisions or is it a reporting tool?
2. Work closely with your users and know your audience well. How will they interact with the tool? Do you want this interaction to be part of a larger strategy of delegating decision making to different teams of staff? What questions do they want to answer? What platforms are accessible to them? What is their connectivity: is Excel the best choice or would a more sophisticated tool like Tableau be a better fit? After you’ve done some initial intel gathering about your users’ needs, don’t forget to engage them throughout the design and testing process to ensure continued appropriateness and usability.
3. Keep your visualizations simple. At-a-glance dashboards used for monitoring tools and analyzing trends might not be the best place to try out fancy new ways of visualizing information; often, bar charts or other simple visuals are best. Remember that complex tools often lead to steeper learning curves and can impact the length of time it will take to fully integrate the dashboard into routine use. Keep in mind that converting information into understanding is not always an automatic process, and it may be necessary to build data analysis skills among users as well as to build up a culture of using data in day to day decision making.
4. Building the dashboard within an internal team can enable more iteration.  Each of us gave examples of dashboards we had designed among internal teams, which we agreed we preferred to hiring external vendors (unless you don’t have the necessary skills at your firm). Working with an internal team helps build internal capacity around sought after dashboard-design skills, and can support more routine collaboration between the data and program people. No matter which path you take, be sure to plan, plan, plan in order to stay on time and on budget.
5. Data in “real-time” sounds nice, but make sure you plan for quality control. Whether your data is available on a daily, weekly, or monthly basis, don’t forget to make time for quality control. In addition, while ‘adaptive management’ is fashionable, there are downsides to continual adaptation. Consider how often you want to or are able to make decisions and whether you need the very latest information. Develop specific roles and processes to ensure routine quality assurance. Otherwise, garbage in, garbage out: if the data you’re displaying on your dashboard is of poor quality, you won’t be enabling smart, data-led decisions.

You can check out the slidedecks on considerations when building a dashboard, building a dashboard to monitor use of an mHealth app, and managing beneficiary pathways on Slideshare.

This piece was written by Amanda Makulec and Barb Knittel from JSI and John Skelton from Mercy Corps.