By now, prototyping is commonplace in the development process for software, websites and apps. It is the ultimate way to ensure that users are involved in the product’s design, by getting them to work with a prototype before you set out to build the final product. All things considered, it is odd that organisations often forget about prototyping when they develop their dashboards. This puts them at risk of failing to meet the users’ needs or that the data that’s displayed will be interpreted incorrectly. Therefore, the time has come for a new generation of dashboards!
Previously I explained how to develop the perfect dashboard in five steps; a dashboard that will be used and will have an impact on the organisation. There I already emphasised the need for prototyping. With a sketch of the dashboard’s layout, you automatically invite feedback. Users discuss it, which gives you input for a new and improved sketch. This allows you to create a good foundation very quickly. In response to this outlook, I was repeatedly asked to provide more information on the importance of prototyping when it comes to dashboarding. Here you have it…
My ideas about the design process for dashboards originate from the time when I entered the world of business intelligence. Before then, my expertise involved user surveys, usability testing, prototyping and interaction design. Thanks to this knowledge, I look at the dashboard as an application that supports the user in his or her work. Therefore, it is important to consider how much of the data that you are showing is understood by the users. You can go with a rough estimate of this and hope that you are right. Or, you can get users on board at an early stage to provide you with the essential feedback. That is the main reason to adopt prototyping in your dashboarding process.
Five reasons why dashboard prototyping is essential
With prototyping, you want to discover, on time, whether there is a mismatch between the design and your users’ objectives. After all, you want the end user to use the dashboard for his or her work and you want it to provide new insights to facilitate better decision-making. Even so, there are other reasons to get users in on the development at an early stage. I will list five of them:
1.Reflecting and asking questions
Prototyping gets users thinking. What do they consider important? How can the dashboard support them in their work? They see what the dashboard looks like and automatically come to you with questions/requests involving subsequent screens, added detail or context which help you with the next sketch. Don’t shy away from new requests/questions. In the end, this input ensures that the final version of your dashboard is embraced by all users.
2. Content is not important (for the moment)
Prototyping prevents users from placing the emphasis on the content during the development phase. When a prototype contains real data, users tend to provide feedback on a number, even though that is not important at this stage. This explains why we omit the content during the prototyping phase and focus on functionality and usability.
3. No graphic design
With a prototype, the right colour or perfect design isn’t important. Prototypes should encourage a discussion of the dashboard’s structure and layout. Nevertheless, a prototype is a visual product and there is no harm in it appealing to the users.
4. Faster iteration
A prototype can be developed and adjusted quickly. If it doesn’t meet the requirements, you can get rid of it and start from scratch. This flexibility results in a process where feedback is processed fast. Each new sketch brings you a step closer to the final version. In other words, prototyping gives you the power of repetition in combination with quick sketches.
5. Initiating a change to the working method
Dashboards change the way users work. Don’t underestimate this process. Users need time to get used to the new working method. Furthermore, end users have a hard time imagining the potential interaction with a dashboard or how to display information in a useful way. By getting users in on the development of the dashboard, at an early stage, you flip the switch with them on time. You ensure that users can obtain value from the new tool as soon as the final version of the dashboard is available.
How do you get started with dashboard prototyping?
Have I convinced you that prototyping is a dire necessity for the development of dashboards? Great! Then I’ll gladly explain your best strategy. Before you start, however, it is imperative that your preparations are solid. You can determine your course beforehand by identifying the users before you even start with the prototyping process. Give the following some thought before you start:
- You have clearly identified the users based on personas.
- You have described what your users want, and why, in use cases.
- You translated these use cases into a data request and determined the associated measuring values and dimensions.
A little later I will explain how these preparations help you tailor your dashboard to your users.
Opt for paper prototyping
Good, now we can start with the dashboard prototyping. You can obviously use a digital tool, but I prefer paper prototyping. I have a few good reasons for my preference. Let me start by telling you why I don’t believe in digital tools. Firstly, the functionalities are usually quite limited. One can usually design up to a certain point with tools, but often you can’t adjust prototypes exactly the way you want to. You often get stuck tinkering with the prototype, losing sight of what is important, namely, the usability.
Therefore, opt for a paper prototype. It costs practically nothing. You don’t need expensive tools. A sheet of paper, a flipover or a whiteboard will suffice. As long as you can make the changes quickly or can throw the outdated version away. This makes paper prototyping such an iterative process. You can adjust your sketch quickly based on input from users. I often sketch what comes to mind on paper. It is easy for me to then take this sketch along to the user. I then ask for feedback on the spot and create a new version that better suits his or her needs. By repeating this process with other users, my sketch will have improved markedly within a few hours. Moreover, I get the user expressly involved in the process.
An added advantage is that the data is kept out of the picture a while longer. This prevents you from getting caught up with content-related questions. Also, there’s no need to consider the details just yet. Colours, logos and other graphic frills come into the picture much later.
What DO you sketch?
- Titles and headings of blocks in which you want to tell something through visualisation
- Navigation and workflow
- Categories (dimensions)
Even so, the user might feel the need to get an overall impression of what the dashboard will look like. I often use a digital tool for this, once the paper prototyping phase is complete, and click together a prototype in the tool. Then I send it to management for inspiration.
Some of the tools that are suitable for this include Balsamiq, Geckoboard and Klipfolio. With Balsamiq, your user can click through the dashboard to test the navigation. The advantage is that it is easier to distribute and gives the impression that much has already been incorporated. The other tools give your prototype a polished look, quite quickly, because frequently used visualisations and navigation forms are pre-programmed. In Geckoboard and Klipfolio, however, you’ll be working based on real data or dummy data.
How your prototype is structured
My graduation project was decision support systems. For my thesis, I investigated how decision-making works in the mind and in organisations. I still use this knowledge to determine the structure and layout. For guidance, I always use three layers for the dashboard’s structure:
You can use them for any dashboard. The difference is mainly in the content for a specific user. You use the personas, use cases and user stories that you developed in the preparatory phase. By using an example, I illustrate how to tailor your dashboard’s structure to your user.
Say hi to Nordin. He is a pricing & asset analyst at a car leasing firm. He wants to see if the model for the forecasting of the residual value of lease cars still works well, using a dashboard. This will give him enough time to make adjustments if the model deviates. In the prototyping process, I validated his working method against this use case. I then incorporate his wishes in the three layers of the dashboard.
This is the ‘top layer’ of the dashboard. Here the user sees the numbers that are most relevant to him or her, at a glance. Is everything going according to plan, or are there problems that call for adjustments? In this layer, Nordin wants to see if there is a difference between the predicted residual value and the actual residual value. Of course, it is important to talk to Nordin to find out what qualifies as a ‘deviation’ in the model. This might already take us to an essential point, prompting us to also call the model builders in on the process. In the monitoring layer, you can specify that a signal is given when a deviation exceeds 5 percent, by way of a different colour, size, icon, or even a push notification or email. Think of monitoring as your car’s dashboard. Here you also see several meters and lights. When a light comes on, you know you must act. Sometimes you can tell right away how to solve the problem. For example, by refuelling. Other times more investigation is needed to get to the bottom of the problem.
In the latter case, you get out of your car and look under the bonnet. What caused that light to come on? Investigation gives more background to the ‘bare figures’. The second layer of the dashboard is where you conduct your investigation. Why is my dashboard telling me that the data deviates from what is expected? What is the cause? In this layer, Nordin wants to see what is causing the deviation and how to explain it. Is the deviation only seen in white cars or only in cars that are sold for export or through a specific seller?
By looking under the bonnet you can tell that you have a problem, but you lack the technical knowledge to determine the exact cause. You want a detailed explanation of why the red light came on. To get your answer, you drive to the garage for an explanation. A mechanic helps you to find out exactly what is wrong with your car and to solve the problem. This layer is essential to Nordin, to help him uncover which cars are causing the outliers in terms of the residual value. This enables him to present specific deviations in his next team meeting with the Sales Department.
You see, dashboarding involves more than a tool or data. It is about your users and how they can do their work smarter and better. However, users differ more than you might think. This explains why you need time to tailor your dashboard to their specific needs. My advice is to spend this time on prototyping, for the most part.
Will you use prototyping for the development of your next dashboard?