A fantastic resource that can be used to create many valuable products. The (big) data possibilities are endless. However, the potential value often binds developers. Putting data into a dashboard does not automatically imply added value for your organisation. Perhaps you’ve created a visualisation or dashboard that you feel is perfect, but the users interpret and use the information in an entirely incorrect way. In the worst-case scenario, this could lead to wrong decisions. Or, everyone seems enthusiastic, but the dashboard is hardly ever used. A crying shame, because it can be such a success!
Human centered BI
As an experienced usability expert, I have ventured into the world of business intelligence. I am often astonished at the ‘data-centred’ or ‘tool-centred’ approach of dashboards and other information products: they build what the data and / or tools can offer. However, as a BI consultant, I only have one goal: make the end users happy. How cool is it when a user embraces your dashboard, uses it for his or her work, and makes better decisions or works more efficiently based on the insights that were obtained? Human-centred BI is what I call it.
In my previous blog, I showed you how to further enrich data to arrive at information, knowledge and wisdom. To use the reporting of periods gone by, to arrive at a BI product that enables you to make decisions for the future. This is just one of the aspects of proper information design. Naturally, one of the other most important aspects of your design is the end user! I explain how to focus on users when you design your information products.
Don’t ask ‘what do you want?’
Never ask the users that you work for what the dashboard should look like. It is your job, as a designer, to understand the needs and tasks of your user, and to then surprise him or her with an information product that dovetails perfectly with these aspects. It is your job to design a dashboard that users could never dream of developing on their own. After all, information design is a profession. As a designer, you come up with solutions to best support your end user in his or her work and in the decisions that he or she must make. Henry Ford’s famous quote says it all: ‘if I had asked people what they wanted, they would have said: faster horses.’
Failure to meet high expectations
It might all seem logical to this point, but I still come across reports, lists and dashboards at companies, daily, which don’t correspond with the user’s world:
- Remarkably often, it is entirely unclear who the information product was intended for or what it is used for.
- When I review the user’s information product with him or her, it often appears that information is interpreted incorrectly.
- Many information products are delivered faithfully, only to remain unused.
- Users often devise tricks so they can use the information product after all; they know the ins and outs of the information, and have created their own spreadsheets or work instructions to deal with it.
This supports my standpoint that many products are still developed based on the available data and tools. This is understandable, because many companies feel a sense of urgency to get the value out of their data, and press for the ‘wealth of information’ to be accessed via a – mostly valuable – visualisation tool. In most cases, the high expectations are not met, and the resulting disappointment is great. All the more reason to also develop a solid user centered design for dashboards and other information products. As an experienced usability expert, I automatically fall back on my experience with user analysis, information design, prototyping and user testing. In so doing, I always follow the same five steps when designing truly valuable information products.
User analysis in 5 steps
In a user analysis, you identify your users, their needs, and how you can best help them in that regard. You usually capture the results of the analysis in persona’s, user stories and information designs. You use this to deduce the requirements for your chosen visualisation or dashboard tool and the decisions on the required data.
Step 1: Who are your users?
A good way to start a user survey is to identify your user’s position (task) and the global purpose of the information product. Does this involve people from the management team, the customer service operational manager or a service technician? What is important for their position and what do they want to achieve? Demographic information is also interesting in this regard. Is the user a male or female, what is the end user’s generation and what is his or her background / educational history? What is his or her experience with IT and BI? What is his or her knowledge level of statistics, for example?
You can conduct a user survey in different ways. Each method has its own purpose, result and costs. This could involve personal discussions, meetings, surveys and observations. You capture the results of your user survey in persona’s or user profiles. A persona describes a user type and can therefore represent multiple end users. It is certainly not always true that people in the same position have the same needs.
Step 2: What do your users want?
If you have a good picture of your users, it is time to get more specific. What tasks are performed by the user? What are they evaluated on? What are the user’s goals? What are the KPIs for his or her position? What are his or her information needs? To ensure that you get clear answers, it helps to repeatedly ask why someone would want to know something. Also, not unimportant, is to ask about his or her expectations for the end product. What is the current ‘problem’ that will be solved with the product? What is the current situation and what do they expect the situation will be with the new product? Are they confident about it, or sceptical? How will the use of the product soon fit into their activities? But also…what did they collect themselves before, in Excel, and how do they use that now?
All this information is captured in user stories. A one-sentence description of what a user wants, and why he or she wants it. To identify the problem or process, you can write out a scenario or make it visually visible in the user flow.
As a customer service manager, I want to know what our conversion rate is, so I can adjust on time when it looks like we are going to miss our targets.
As a customer service manager, I want to be able to compare the performance of my team members, so I can find ways to improve my team.
As a customer service manager, I want to be able to see how clients rate my calls, so I can learn from it.
Step 3: How can you best help them with this?
Now it’s your turn to act. You determine the required measuring values per user story (like the number of clicks, sales, article inventory, number of hours spent) and dimensions (like the department, year, category, employee). You can design the required visualisations and sketch them already, per user story. Apart from a design per user story, it is also important to create a global information design. What information belongs together and what can be placed on a separate sheet? How do you ensure that your users keep within the right context when going through your dashboard’s pages? In short, how do you ensure good usability of your information product and a good user experience for every user?
In most cases, I start with paper prototyping. I sketch the dashboard’s layout and discuss it with the users. I get them to talk about it, and soon come up with an improved version, which is again improved after the next user’s feedback. This allows you to create a good foundation very quickly. You can sketch the foundation in a prototyping tool like Balsamiq, for example, and can present it to your users again. A tool like this allows users to already click through the structure and information design. By getting them to talk about this, you soon discover whether it ‘clicks’ or not. Take note, I have not even touched yet on the use of colour or pixel perfect design. Prototypes don’t have to be pretty. They must enable discussion of the content and structure (which does not imply that the graphic aspect is not essential to many users).
Tip: try to surprise your client in this phase. For example, keep the DIKW pyramid from my previous blog in mind. In my opinion, everything is permitted during this phase! Show your client all the possibilities and aim for the best possible solution. At a later stage, we will divide this into must haves and nice to haves.
Step 4: What data and tooling are required?
Now that you know what type of information product your users need, you can deduce the technical-, functional- and non-functional requirements. Did your client indicate that he or she wants to present monthly figures to an external client, via a big screen? This will require a smart export option or a licensing formula that enables external access to the dashboard. Does your client use the information product all day to manage inventory? In that case, it is important that the data can be refreshed fast. Does the CFO want to use the information product to provide information in the context of Basel III? In that case, it imposes demands on the quality and traceability of the information, and special attention must be paid to data governance. Does the conversion specialist want to see the Google analytics data analysis in his or her dashboard? In that case, it will be a requirement for the tooling that you will select. Does your user want an update on his or her team’s KPI progress for the month? In that case, the information product must be available on mobile devices. Does a user attach considerable importance to the visual wow-effect of the insights on the dashboard? In that case, you’d impose graphic requirements when choosing the tooling.
You record the requirements in a functional design. I often include an overview of all the required data segments and the definition or calculation thereof. Together with the BI or IT department, you will have to check whether the data is available in a suitable format, like in a data warehouse, for example.
Of course, a great deal more will be involved when choosing suitable tooling. Apart from your end users, other stakeholders must also be considered for this decision. IT will have its requirements, and a specific budget will apply; perhaps tooling is already being used, etc.
Step 5: What if it doesn’t fit?
There is always something that doesn’t fit. A tool that meets all the requirements, but is unable to process real-time data. Software with strong visual capabilities, but no ability to perform certain analyses. There is always something that doesn’t fit perfectly. Sometimes it doesn’t fit in at all…
This leads me to my crucial point! Since you’ve conducted a thorough analysis, you can now make an informed decision. Okay, that’s not included. What exactly did we need it for again and what will it give back to us? Perhaps we can come up with an alternative? In so doing, you’ll give the budget keeper substantiated arguments for the decision-making process. Customisation allows you to build anything that the users may want, but that comes at a price. You can also opt for this standard tool, but the following items are not included, and you’ll therefore have to boot in on the following results… This also prevents you from purchasing tooling that won’t be able to meet important user needs at a later stage. This is exactly how to prevent the building of dashboards and data visualisations from becoming strictly reserved for ‘teckies’. With lovely data access mechanisms, breath-taking ETL processes… and a dashboard that never gets used.
A phrase that we use rather freely: ‘the right information with the right person at the right time and at the right place.’ But, are you certain that the dashboards that you build:
- Provide the information that suits the tasks and goals of the user?
- Are directed at a person who understands the information and can act based on it?
- Are available at the right time, in other words, as soon as the user must make a decision or needs the data to perform his or her work?
- Is accessible at the right place, in other words, where the user needs the information: on his or her mobile, as part of another system or on-site at a client’s location?
Do you only look at the data that’s on hand and at what the available tooling can achieve with the data? Or did you give these aspects considerable thought, beforehand, so that your dashboard will truly be used? I hope my approach helps you to enhance the usability of your information products!