In order to design a dashboard that people are actually going to use, you have to put some work in up front. In this article, we outline some of the key things you should keep in mind and take note of while working through the design process.
I can’t think of a better way to negatively impact dashboard adoption than by building a dashboard without talking to the end-users of the dashboard ahead of time. This process should feel very similar to designing a Service Portal.
Is this for executives, process owners, fulfillers, customers, or someone entirely different? We recommend meeting with the intended audience at the very beginning of this process to start gaining an understanding of what will be useful for them.
There are 3 main types of dashboards. First, try to define which type of dashboard you are building to help drive design decisions later in the process:
Find out how these dashboards are likely going to be viewed. Will it just be from a laptop browser? Displayed on a wall monitor? Tablets or other mobile devices? If you can narrow this down it will help you design the layout of the dashboards along with the types of charts that you select.
Further, will these dashboards be viewed within the standard ServiceNow frame, in the Service Portal, or somewhere completely custom?
All of these answers will help you get a feel for the dashboard real estate you have to work with.
We’re finally getting to the point where you can start designing your dashboard. The final thing to keep in mind is that less is usually more with dashboards. Dashboards are typically about making decisions of one sort or another, so we want to help our users get to those decisions as efficiently as possible. Building a dashboard with tons of cool charts and interactivity is fun and looks impressive, but usually doesn’t help the decision-making process.
If you find yourself with a dashboard that has \~20 charts or scores (you could really even say \~10), then you might be looking at too broad of a subject. This could be a good opportunity to look for ways to break this into smaller, more focused dashboards.
To wrap things up, just remember who you are building the dashboard for and why you are doing it. If you can keep those two things at the forefront of the design process, you are probably going to put out some quality dashboards that people actually use.