Reporting and analytics can be a difficult area in IT service management (ITSM). We live in a data deluge. According to research by DOMO, “… over 2.5 quintillion bytes of data (9 more zeroes than a billion, or 1 followed by 18 zeroes) are created every single day. Ninety percent of the world’s data has been created in the last two years. By 2020, it's estimated that 1.7MB of data will be created every second for each person on earth.” There’s definitely no shortage of data in the world and this extends to ITSM thanks to what’s held within ITSM tools.
In this blog, I discuss the 8Ws of ITSM tool dashboard design, and how the principles these represent help ensure the right information is presented to the right person, in the right format, at the right time, to ensure safety and success.
We’re often data rich, information poor (DRIP), in that the challenge has shifted from finding data, to presenting it in an informative way to support our decisions. The good news is, much of the groundwork for this conversion, has been done. The tools and methods exist.
Well, you might be looking at an example of one right now. Some time today you certainly will, and likely every day you have and will continue to unless you live “off the grid.” Your cooker (stove) has one. If you have a smartwatch it has many. If you own a car it's right in front of you, and if you work in an IT organization you might also have at least one. What I’m talking about is a “dashboard.”Read about the 8 Ws of ITSM tool dashboard design. Click To Tweet
It’s a brief diversion but, hopefully, you’ll find it interesting.
Originally, the word “dashboard” described a barrier of wood or leather fixed at the front of a horse-drawn carriage to protect the driver from mud or other debris “dashed up” (thrown up) by the horses' hooves. We would now call it a kind of mudguard. Strange name for such a commonly used concept most of us take for granted, and in many cases, rely on to get us through our day safely (and perhaps it defends us from mud of a different kind!).
As horses were exchanged for cars, the dashboard became a panel to protect vehicle occupants from the heat and oil of the engine. With gradually increasing mechanical complexity, this panel formed a convenient location for the placement of gauges and minor controls, and from this evolved the modern instrument panel, although retaining its archaic common name.
The dashboard has now stepped away from its origins and is borrowed to describe a computerized display that shows useful real-time data. It’s a long way from horse-drawn carriages on muddy roads to its use in the digital world.
However, some might say its purpose has remained unchanged, to provide one form of protection or another to its user. Modern-day protection comes in the form of information critical to the safety, health, or activities performed by the “driver,” the user.
Today’ dashboard presents critical information captured and reported by sensors in real-time, or in response to a user’s query or question. Sometimes the information is legally required, as is the case of a speedometer in a car. Sometimes it's pre-configured and based upon a pre-conceived industry set of assertions and assumptions.
One thing is clear in dashboard trends, as infrastructure becomes more reliable and less prone to failure, the bias shifts further along the “information continuum” from alert worthy, to decision supporting. From monitoring (reporting on the status of a performance indicator and alerting any “out of range” conditions), to analytical (providing users with the information needed to understand trends and why certain things are occurring by making comparisons across time and multiple variables).
Regardless of whether mandated by organizational policies or regulations, or propelled by professional or societal trends, what appears on a dashboard is driven by the same underlying principles:
These represent the “8Ws” of dashboard design. Each principle is used in the form of one or more questions the dashboard should answer in its operational design.
The first W prompt reminds us where we should start in our dashboard design thinking – the purpose of the dashboard. Who is the dashboard going to help? This question provides us with critical operational context, such as what role the person is performing and what common activities the role is responsible for completing. Another key question is what questions must the dashboard help answer?
The next W addresses the critical information that systems should “push” to the dashboard, and with what cadence. This might include mandated items such as organizational policies, regulatory compliance, or perhaps service level commitments. Some of the key questions the dashboard answers could include:
A speedometer is a good example of this type of dashboard information. It’s also required and regulated on a motorized vehicle. It’s the law. From a work perspective, we may have software applications occasionally inspected by government agency auditors, or contracts for services.. we need to police in real-time.Regardless of whether mandated by org policies or regulations, or propelled by professional or societal trends, what appears on a dashboard is driven by the same underlying principles. Here @Joe_the_IT_Guy explains. Click To Tweet
Another of our 8Ws reminds us we may need to consider key information a person can request, or “pull” from a data source. This type of information is solicited on demand, current, generated in real-time, and may be pulled because of information already presented (such as in W2), and like all information, subject to role-based policies and rules that govern disclosure and use.
The fourth W is for historical information. This type of information is typically used for planning purposes but can be used to detect a trend, perhaps as part of identifying a risk, or a problem. Sometimes the entire dashboard is reserved for historical reporting. What historical information, if any, should be readily accessible to support real-time dashboard information?
The fifth W helps us decide how best to present the information, making sure it’s easily found, read, and understood. What format works best for the audience? A widget determines how data is presented on dashboards. Many variations are possible. For example, as a chart (line, area, bar, pie, doughnut, funnel), card (single or multiple counters), gauges, maps, scatter or bubble charts, tables, heat maps, or plain lists.
Where should the widget containing the information be placed? Research has shown there are several ways or “patterns” a viewer’s eye moves across a website or dashboard design. They include “Z” and “F” patterns, long associated with the natural path the eye will take through any design based upon how we have been taught to read.
There’s plenty of help on the web on how to organize content in general, to follow natural eye movements (“visual hierarchy”). Remember, position content based upon the priorities of the viewer.
Is any information managed and presented by other dashboards? The seventh W reminds us to check and relate or link dashboards, perhaps in a layered design, allowing the viewer to jump to, or “zoom down” to, other dashboards.
Finally, given the constrained space a dashboard typically offers, we need to consider what information is a must, and what’s optional. It’s important to note that optional information implies that which a viewer can re-configure, perhaps suppress, or move to another place within the dashboard without impacting or changing the priority and placement of information that is required. This is our eighth and final W principle.
The most useful and valuable dashboards are designed around a role, or a persona, and appreciate the key activities, questions, and decision points important to the role. Their layout is intuitive. Information is presented and layered to avoid information overload and supports natural reading methods. The user experience is also mindful of the infamous “four-second rule” – namely, if my eyes can’t orientate and find something within that time it’s a sure sign there’s a mismatch between my knowledge of the role and the dashboard design for the same role.
Take moment. Look around you now and during the rest of your day today. How many dashboards will you use? Which ones work instinctively, and which ones don’t, and why. How many seem to follow some or all the “8W” principles? Just to think, it all started with a simple plank of wood.
This article was originally published on IT Toolbox.