Why MRDCL for crosstabs / tabulations?
MRDCL is one of a small number of software produc…Read more
Custom dashboards have become a popular way to manage data and to share information amongst colleagues, clients, customers or, indeed, any audience. So, what are the 10 most important things to consider before buying an online dashboard? Are all dashboards a success? It won’t surprise you that some are failures and, in our experience, this is mostly due to either poor preparation or poor design. Putting together a dashboard is a skilled task – it’s one of those things that looks easy but needs a proven skill. It’s rather like the way I cannot take a photograph that looks anything like as good as one taken by a professional photographer.
When I am working with potential clients, the first question I ask is ‘What is the purpose of the dashboard?’ Some answers are good, some are vague, some people admit to being unsure. If you can’t answer this question, it’s probably best to keep your money in your pocket and spend it later or in some other way. That may sound blunt, but it is a surprisingly common fault. In my view, each part of a dashboard should have a purpose with a business objective. Each part should enable the user either to make a business decision or to do their job better than they would without the proposed dashboard.
Knowing who will use the dashboard is another important criterion that must be considered before developing a dashboard. Dashboards can easily fail if they become a compromise. It’s almost impossible to please everyone, but if there are mix of high level and low level users of dashboard, there’s no point producing a mid-point compromise that satisfies no one. It is important to ensure that all types of users are consulted to ensure that they are getting the information they need. I have seen occasions when the buyer of the dashboards understands the needs of one team, but not others. This will usually result in failure. A collaborative process is needed, possibly conducted by an independent person or the software developer. Where there are different types of users, it is usually best to have different views and entry points to the dashboard via logins which reflect the needs of each type of user.
Thinking through the steps that someone will want to take when using the dashboard is a crucial part of the initial design. We need to understand your workflow and your less obvious goals. Clear thinking here is important and it is better if it is sketched out, however badly, rather than having a series of thoughts in the head. Having thought through the work process, it is equally important to consider what someone will want to do next. Is it another similar enquiry? Is it to start the process again? Is to download or share information? What things are users most likely to want to do next? Users may make little or no use of dashboard if every operation takes just a few more clicks than they would expect.
One of the emails that I dread to receive is one that reads something like “The CEO is delighted with the dashboard. However, he would just like it changed to look like our company’s website”. We are not talking about changing the colour of a bar on chart to the company logo’s shade of blue, but redesigning every tab or page so that it is laid out like the company’s website. This might seem trivial, but it might be a lot of work. A dashboard is designed with each part of page allocated to controls, information, views etc. Changing that can mean some fundamental changes. We will ask if there is anything important about the design, but it can be one of those disregarded questions that are only considered when it’s too late.
A dashboard can contain as little or as much data as you choose, but that’s not a reason to make every possible bit of data available. Generally, the more data that is available, the less easy it will be for users to work with the dashboard. Just as redundant information or hard to find options will reduce consumer expenditure on a shopping website, redundant information or hard to find options will reduce the user experience on a dashboard, which can lead to the user ceasing to ‘shop’ on the dashboard. It is always tempting to plug in all sorts of measures that are available, but if the data adds no value, it should be excluded. Similarly, if the data is already available in a convenient form, such as a spreadsheet, does it need to be available in a dashboard? Will the users be able to make a better business decision or do their job better with the data in a dashboard? If not, a dashboard may the wrong route or it may be right to reduce the scope of your dashboard. Another issue with data is the frequency of refreshing data. Data can be refreshed by live feeds or periodically. If it is periodically, it is usually best to publish on a significant date, such as the 1st of each month. If updates cannot be guaranteed on time, it is important to have a broadcast system to alert users to data updates. Live feeds are highly effective in the right circumstances, but can be problematic when a data source becomes unreliable or disrupted. Live feeds can mean regularly changing results or output, which may mean that someone needs to be more readily available in your organisation to answer queries on results produced. If that’s a problem, maybe less frequent updates are more appropriate.
Some dashboards just provide prepared information – they are effectively reservoirs of data waiting to be displayed. Where analysis is needed, consideration needs to be given to the depth of analysis that is available. Complex online analysis, especially where there are large volumes of data, can take time, so processing time needs to be considered. Some of the comments about data are equally applicable. Is it important to be able to analyse data using any combination of options, variables, selections etc.? Further, you need to protect innocent users when producing online analysis. You don’t want someone to lose their job because they calculated in a dashboard that 75% of people of a customer type are high spenders, when the data is based on 4 people. Consideration is needed as to what controls are put in place as well as what depth of analysis that is available.
There are five main ways to display data in a dashboard – in a tabular format, as a chart, as an infographic or as a list or as textual information. Each has their place, but considering the user is of greatest importance. If a dashboard is going to be used constantly by the users, it is possible to put a lot of information on a page as the users will soon become familiar with the layout and able to use or absorb the data that is being displayed. However, generally, a page should not be cluttered and you should not attempt to show too much information. This means considering the business purpose of a page or tab in the dashboard. Each way of displaying data has its pros and cons. If you are planning to specify how each display is presented, you will need to consider how that data is displayed. However, leaving it to the experts is often a good idea. To look at each briefly:
Tabular format: Displaying a small number of figures in a table format is fine, but large banks of figures tend to have little impact unless the dashboard is used regularly and users ‘know what to look for’. Colour coding and ranking can help, but both have their limitations.
Charts: There are many ways of displaying data in charts. However, it is important that the charts are easy to read and not open to misinterpretation. For that reason, bar charts, pie charts and dials are commonly used because they are easy to understand. If the dashboard is going to be used occasionally by some users, it is best to avoid charts that might look good but are not easy to understand.
Infographics: Infographics can make an online dashboard more attractive and more intuitive. Too many infographics, particularly if they are styled differently, on one page can be become confusing.
Lists: Lists or bullet points summarising main findings or actions are an impactful way to communicate information. Top 5 answers or top 5 areas for improvement, possibly showing some figures alongside, are a good way to give actionable data. Texts though should, if possible, be as short as possible.
Textual information: Sentences or concise text summaries that are conditional on the results displayed can be helpful to explain information displayed. Text should be short if it is giving actions, but may be longer if it is explaining terminology or what is being displayed etc.
Colours: I’ve added a category for colours. Colours can be used to highlight positives and negatives (green and red are commonly used), but if there is already a lot of detail on page, the use of colours can soon become confusing. Colours tend to work well when they are the main message of a dashboard page.
It may be important to consider how the dashboard will be accessed and how it will be used. The way that information is displayed on a PC screen is often quite different from the way it is displayed on a smartphone. If information is needed ‘on the move’ using a smartphone,
consideration will need to be given as to how this should appear or whether the full dashboard is available on a smartphone
Dashboards are usually not static displays that will never need to be changed. Exceptions to this may be simple displays that show a small number of regularly updated key figures or dashboards that are fundamentally information retrieval systems. However, depending on the number of users and the data available, most dashboards evolve – new things are needed, some things shown differently as well as data being available in ways that no one had thought of when the dashboards was initially designed. It’s important to have a budget for continuous developments and to give some thought as to what might be on the horizon and to discuss the likely cost – and, indeed, to develop the dashboard so that adding in new features later is easier. The cost of software development is often hard to anticipate, so giving thought to the future can reduce future costs.
The dashboard should be intuitive to use and not need long training sessions except, perhaps, where it is used by a clearly defined team who will be making extensive use of a more complex dashboard tool. Asking your grandmother to look at the prototype for a dashboard may be impossible or not the best solution, but explaining the design to someone from outside your business can be a useful step in the design process. We always recommend that a prototype is produced showing how the dashboard will work before we start full development. We think it’s a minor cost that is not worth avoiding on as seeing what your dashboard will look like can focus the mind and avoid unnecessary changes later.
So, there’s my 10 things that I think you need to consider before ordering a custom dashboard. I would say that the same thought is needed where the dashboard is created within a software tool. Unless the dashboard is for your own use only, consulting with the users other before starting the process will usually bring you a payback and certainly reduce the risk of failure or badly spent budget.
ite or contact us directly.