Which dashboard is right for business?

Hello! My name is Ivan Uspensky, I am a user experience (UX) architect of the analytical solutions department of KORUS Consulting Group of Companies and I want to share some opinions about why a high-quality dashboard that formally meets the customer’s requirements may turn out to be unclaimed and not bring value to the business – and how it can be done avoid such a situation.

Instead of a speedometer, following formal requirements, you can show the amount of fines received for trips since the beginning of the current month

Many believe that the same methods are suitable for creating or developing an information and analytical system as for any other class of systems. For example, when creating a document management system, we can easily clarify the requirements for it gradually, without deviating from the initial concept. But using the usual approach to developing dashboards, we risk creating screen forms that no one needs, even though all the formal requirements for the project will be met.

Problems with dashboards for business

The degree of compliance of the solution with the requirements determines the degree of quality. At the same time, even the functional requirements for the information and analytical system or its part, drawn up by the customer, often do not describe what exactly this software should do. What can we say about non-functional requirements, for example, regarding the use of shades of a certain color to design screen forms. And the larger and more complex the customer’s business, the less likely it is that the user’s initial requirements for the BI system will allow the creation of a truly effective tool, since in fact they only seem exhaustive. Why does this happen?

Data visualization using dashboards allows you to obtain up-to-date, reliable and complete information for decision-making. But the higher the position of the main customer of future dashboards, the less time and opportunity he has to formulate his wishes, on the basis of which a set of requirements is compiled. The apparent brevity of a dashboard for a top manager actually hides complex aggregations, careful selection of indicators, versions and data structures, as well as determination of the most suitable types of visualization. And if the BI system is complex, it also includes specially designed work scenarios for different details, transitions and corresponding controls in the user interface.

Let’s imagine a situation: a top manager of a large organization needs a dashboard that will display current data about the areas of business and individual processes that interest him. During the next meeting, the top manager sets the task for department heads to ensure that data is displayed in the information and analytical system. In turn, department heads can delegate the task to their subordinates, and those to their own. The number of iterations depends on the complexity of the organizational structure, but in the end there are always several responsible customers, each of whom the executive team works with. Each of these customers has its own interests (for example, it may want to partially hide “unprofitable” sections of data that raise questions among management) and its own aesthetic ideas about analytical visualization. In some cases, methodological approaches to collecting and processing data or interpretation of business terms may diverge.

This often leads to the fact that at each level of responsibility, wishes and solution options prepared “on the floor below” are not generated, but only accepted or rejected. Although, of course, there are exceptions when an involved and responsible employee designs a solution along with other project participants.

As a result, requirements, documents, layouts and even interactive prototypes, carefully worked out with customers, if they are created during the design process, go through all stages of working coordination and formal approval, dashboards are developed and implemented, are successfully accepted and transferred into permanent operation. Everyone is happy, except for the only user of the top-level dashboard, from which it all started. A dashboard for him objectively exists, but it is either not effective enough or does not help at all.

Consequences? The most likely ones are the ineffectiveness of the solution, wasted resources spent on development and implementation, as well as the loss of interest by the key customer in the development of information and analytical systems or working with this contractor. How to avoid such consequences? Most publications and training courses discuss UX design (user experience design) methods and techniques exclusively for the B2C segment. However, BI systems are more complex from the point of view of the designer’s ideas about how future users will work with the system. Although the data itself, the processes of its collection and processing are no different.

Think about all the bad, uninformative, and unreadable presentations you’ve ever seen. But slides are, in fact, the same dashboards, when data is broadcast on the screen in one form or another. The nuances (data sources and algorithms for processing them) are hidden “under the hood”. On the contrary, let’s remember examples of successful data visualizations – for example, the presentations of Apple products, which were conducted by Steve Jobs. One indicator and one value on a giant screen – doesn’t seem like a good dashboard? However, it is the right figure, at the right moment, presented in the right way in a clearly designed context. What would his presentations look like if they were filled with all available (and, obviously, formally significant) indicators, values, and visualizations? How would such a difference affect the viewer’s decision making?

What is an effective dashboard

How to make an effective dashboard? Use UX design.

The first stage of a UX designer’s work is immersion in the user’s goals, objectives and problems. This is described in sufficient detail in the methods of designing products for the B2C segment, using examples of services and applications for Internet banking, maintaining a healthy lifestyle and listening to music. However, what about the business sphere?

The process is both simpler and more complex. It’s simpler because we design an experience for an audience that is obviously understandable (often single users). More difficult – because traditional data collection tools in the form of in-depth interviews or focus groups may not be available, as well as technical analysis methods that analyze recordings of user eye movements, cursor movements on the screen, etc. (usually this allows you to find problem areas where users get lost and cannot find the necessary data, objects or system functions).

The main difference between a business user lies in his goals and objectives, solved with the help of an information and analytical system. All of them are defined by processes, regulatory and methodological documents, and business rules. The situation, i.e. The context in which these dashboards will be used can also well be analyzed and described – from, for example, the properties and qualities of the equipment in the meeting room (screen resolution, display control capabilities) to the agenda of these events. The initial data for analysis can be collected during the usual procedures for examining the automation object – perhaps using a slightly wider scope and separately recording UX moments that are significant for design.

The design process itself can be divided into several stages.

Focus on business goals

We have already pointed out the limitations of the possible participation of the main users – as a rule, they concentrate on business goals. The business goal depends on what the customer needs and is formulated on the basis of:

• roles (who is the consumer of the result),
• situations (circumstances in which this need arises),
• the need itself (general description of the required information),
• clarifications and context (any significant surrounding circumstances).

Example. Every Monday, the General Director (role) during an operational meeting (situation) must receive information on the implementation of the weekly plan (key performance indicators by division) for further decision-making on changing work plans. During the meeting, a video wall is used; presenters should be prepared to answer questions and provide details (clarification and context).

It is highly advisable to agree on the business goal with the top manager (the main user of the BI system being created or developed). This will be the basis for further design.

Formulation of business objectives

Based on the formulated business goal, we can identify and formulate business tasks for all categories of users who will have access to the dashboard or participate in generating data for it. This work is carried out at the level of department heads. The tasks can be more or less complex, but it is better to keep them independent from each other. Examples: “find out the value of the indicator”, “find out the nature of the deviation (deviations, indicator state)”, “understand what indicators you need to pay attention to”. Here, using quite ordinary business analysis tools, including interviews and documentation research, we supplement these tasks with specific sets of indicators and their attributes, understanding, taking into account the study of the subject area, exactly how to do this.

Scenarios for working with the system

The next stage is creating scenarios for working with the system. Having all the scenarios in hand, we can create an information architecture (static and dynamic logic in which the data and functions of the system will be perceived by users), navigation and visualization control systems, and, finally, the dashboards themselves – screen forms containing the necessary structured data , with justified types, forms and display priorities. A complex user scenario may include a long path from the initial general screen through details and sections to the information that is needed to make a management decision. And it is very important to make this path simple, seamless and obvious, and not require the user to remember the names of sections and screen forms, and work on several screens, sequentially opening them on their device.

The result of the work, understandable for future users, is mock-ups of screen forms and/or an interactive prototype, allowing you to test the future solution before its development. Prototyping can save a fair amount of resources because… making changes will happen incomparably faster and easier. The end result will become predictable, and the business benefit will be as probable as possible.

All of the above, of course, requires resource costs. Typically, with a minimum amount of work, additional qualifications of analysts and designers are not required – design approaches will be most important, and a human-centered approach in itself is designed to ensure good results.

conclusions

1. User experience (UX) design is important and necessary for B2B projects. Such work in terms of the project is not a tribute to fashion and not a waste of resources.
2. A comprehensive set of metrics and their attributes and a role model for accessing this data are not a sufficient initial set for creating a useful BI solution.
3. As a customer and the main consumer of the result of work on creating or developing an information and analytical system, try to concentrate on fixing business goals and checking their implementation, and not on the requirements for a more complete set of data for dashboards. If your work scenarios are quite complex, ask for a prototype with realistic data. This will allow you to assess the potential benefits of the solution being developed in advance and guarantee a successful user experience.
4. If you design an interface based on functions, and not on work scenarios for end users, this can lead to reduced efficiency of the solution, automation of the processes of collecting and processing reporting data, as well as incomplete achievement of business goals by users, constant loss of time and other problems.