Dashboards are all the rage in public health and development, but how do you approach designing a tool that's user-friendly and helps key decision makers answer questions?
JSI's Barb Knittel and Emma Stewart share their insights from developing dashboards for multiple JSI projects and highlight key steps you should take before ever starting the actual dashboard build in order to create a great product.
Call Girls In Doddaballapur Road ☎ 7737669865 🥵 Book Your One night Stand
So You Think You Want a Dashboard
1. SO YOU THINK
YOU WANT A
DASHBOARD?
Considerations for
collaborating to create
data-based dashboards
July 21, 2014
Prepared by:
Barb Knittel
Emma Stewart
2. 2|
What is the purpose
of a dashboard?
Adashboardis ahandy
overviewfordata,butisnotthe
finaldestination.
Adashboardisthemap that
leadsustoadecision.
3. 3|
Who is involved in
dashboard
development?
Subject
matter expert
Knowledgeable about
the audience
Familiar with your data
Data and data
visualization expert
Familiar with various
dashboard tools (Excel,
Tableau, etc.)
Knowledgeable about
best practices in using
data for decisionmaking
6. 6|
Who is your
audience?
Audience considerations:
• What type of decisions are they
intended to make?
o Management
o Advocacy/ needs prioritization
o Project/ activity tracking
• How familiar are they with the data?
o Is this the first time they will be
seeing the information?
o Are they the data provider?
Knowing your audience is a critical
first step in designing an effective
dashboard.
7. 7|
No tool can be
everything to everyone
AUDIENCE: This dashboard is intended for use by district
level stakeholders in agriculture, WASH, and health
(nutrition, family planning, malaria).
PURPOSE: To raise awareness of the causes of anemia and
related interventions, in order to identify enter points and
support anemia prevention efforts at the district level.
Stating in writing the
intended audience will ensure
that all members of the
dashboard development
team remain on the same
page throughout the process.
It will also make it easier to
solicit feedback when you
share the dashboard with
others.
Dashboard User Profile
9. 9|
What data do you
have?
Data considerations:
• What is the source(s) of your data?
• Does the timing align across your
sources?
• How frequently is the data
updated?
• Do you have qualitative data,
quantitative data, or both?
Garbage in- Garbage out
Informed decision-making relies on good data. No matter how pretty the picture,
without quality data, your dashboard will suffer.
10. 10|
Determine your data
sources
Determine where the data for your
dashboard will come from.
Does it already exist?
Will it need to be collected?
By whom?
How often?
If you need to collect data, this is a separate activity to building the
dashboard, and should be planned out with the appropriate M&E staff
12. 12|
Consider update
frequency
How frequently the data
will be updated will:
Inform the dashboard
design-- particularly the
backend
Dictate how much
manipulation is feasible
for translating data into
images/graphics
Once a Year
Weekly
13. 13|
Identify the data
type(s)
Quantitative and qualitative data
are handled differently on a
dashboard.
Your data type will impact the
LOE required and influence your
design- particularly if you are
showing both types.
15. 15|
Content expert and
dashboard designer
meet to scope out
project
Audience
Dashboard type
Data
Medium
Printed
Online
Dynamic/static
Branding/marking requirements
Colors
Fonts
Disclaimers
16. 16|
Designer creates
dashboard mock up
The mock up will:
Help determine feasibility of design
with given data/ constraints
Layout general design elements
The mock up will not:
Be populated with all of the data
Have all of the final design elements
incorporated
17. 17|
Content expert
provides feedback
Dashboard design is an
iterative process. Keeping in
mind your audience and
purpose, provide feedback to
the designer on the usability of
the dashboard and if the key
data has been captured in a
way that improves
decisionmaking.
18. 18|
Seek an outside
opinion
DO
Ask someone unfamiliar with the tool and
project
Provide the audience and purpose of the tool
Ask the user to make a decision based on the
data
Allow both the subject matter expert and
designer to hear the feedback
DON’T
Provide additional assistance in navigating
the tool
Get defensive if the tool is not as intuitive as
you thought- better to know this now!
19. 19|
Repeat
There will likely be many rounds of
feedback to get both the
functionality and layout just right.
Build time into your project timeline
for this review process
21. 21|
thank you For more information
Visit
CHIME on the Intranet
Contact
CHIME@jsi.com
estewart@jsi.com
bknittel@jsi.com
Editor's Notes
While there are many tools that empower individuals to present their data visually, this presentation is intended to highlight the considerations for preparing for and working with data visualization experts to build dashboards. We’ve prepared some questions to consider when you begin on the journey of creating a dashboard, and some guidance on what to expect when you engage a dashboard designer.
Who are we to tell you?
Barb Knittel, Research Monitoring and Evaluation Officer within CHIME
Emma Stewart, Technical Advisor on the USAID | DELIVER PROJECT
We’ve build and consulted on dashboards for SPRING, DELIVER, IAP, LAUNCH among others
Dashboards are very popular right now among our clients and others in development and are seen as a quick way to discern important information.
A dashboard is a handy overview for data, but is not the final destination.
A dashboard is the map that leads us to a decision.
Decisionmaking will be a theme throughout presentation as it should be the central point of building a dashboard
While there are many tools that empower individuals to present their data visually, this presentation is intended to highlight the considerations for preparing for and working with data visualization experts to build dashboards.
From our experience in building dashboards, we’ve identified audience, data and design as three critical elements to building a successful dashboard. We will discuss the audience, data and design and how they relate to the underlying theme --decisionmaking as we move through this presentation.
There are various kinds of dashboards, and the type will depend on both the audience and the decision you’re hoping to arrive at. A management dashboard that is routinely used by a project team will require less text and can rely more heavily on graphics since the team is well-practiced in interpreting these graphs. Dashboards for advocacy or needs prioritization will likely need a bit more context, especially for a high level decisionmaker. When tracking an activity, it is likely that you will have more data points, and may want more detailed data (numbers in addition to graphs).
In addition to the type, it is important to consider your audience’s experience with and understanding of the data being presented. Your visuals and level detailed analysis will vary if it’s the first time someone is seeing the data as opposed to someone already very familiar with it.
In our experience, there will be a variety of people who participate in the dashboard building process– from various members of the team, to the client and perhaps a TAG etc. Development may also span a long time period, during which our memories can get a little hazy.
By stating the audience and purpose in writing, you will be able to revisit it throughout the process when making design and functionality decisions and it will allow you to share your tool more easily with others.
It is important to think about the type of data that will feed into your dashboard as it will inform the design and use of your dashboard
Does your data already exist or will you be collecting it specifically for the dashboard?
Where is the data coming from?
How many sources of data will you be pulling from?
Who will be landscaping and collecting this data?
Dashboards are used to make decisions so it is important that data be comparable and any differences in time period are clearly marked. Particularly if you are drawing your data from a variety of sources, you will want to be clear how the data relates, and if it covers the same time period.
For example:
CS indicators dashboards are updated annually by a team already familiar with the data and the dashboards. There are a number of more complicated formulas in the backend to show the data over time. This wouldn’t be feasible with more frequent updates.
The TOM table is updated nearly everyday by the TO Malaria team, and as a result, the visuals in the dashboard need to be responsive to those updates without requiring additional dashboard support.
The first 3 items you’ve thought through in advance (and we’ve already discussed).
Additional considerations you’ll want to talk through with the dashboard designer are:
Will this be printed? Online-only? Both? This will inform the page layout and functionality you include.
Dynamic or static? This goes in-hand with the question of printing. A dynamic dashboard has elements that the user can manipulate, a static dashboard is an image and there are not changeable elements on the page. A dynamic dashboard can be printed but if that is crucial to the decisionmaking , you’ll want to know that in advance.
Branding and marking requirements should be known up front as it will inform the design, especially since dashboards are often trying to make efficient use of limited real estate. Having the color palette from the start will help guide the designer’s choices.
We all see dashboards in our work and lives and some may really resonate with us, and in our mind we have a vision of the tool we want. The mock up is the place where your data, constraints, and vision as shared with the designer, come together and the designer is able to show you what is possible.
Like an outline for a report, the mock up will help you see where the dashboard is headed without the designer having to go through all of the backend work, as it is likely to change.
If what you see isn’t 100% what you expect, don’t panic. It is the beginning of the conversation, not the end.
Both the subject matter expert and the dashboard designer are now very familiar with the material, but they are likely not the intended audience.
Seek out an outside opinion to determine the usability of the tool. This person should be provided with the context (audience and purpose) and asked to make the type of decision the dashboard is geared toward, but little other assistance should be offered. This will provide a new perspective for potential changes before finalization.
While there are many tools that empower individuals to present their data visually, for some of our bigger project needs, and in our particular resource constrained environments, you’ll want to engage someone who has this as their expertise.
Thinking critically about your target audience and the data you have will help determine if a dashboard is appropriate for your project needs before you engage with a designer. Creating a dashboard is an iterative process so be sure to plan appropriately.