Some mistakes when creating dashboards in BI systems and how to avoid them with the help of UX

Dashboards are a very convenient tool for business. An information panel that allows you to quickly get data on the status of indicators is an indispensable tool for operational management. Dashboards allow you to make decisions, understand where to pay attention.

However, it is very easy to make a mistake when creating a dashboard. Our hypothesis: when designing dashboards, you are in any case engaged in user experience design (User Experience, UX design), even if you do not realize it and do not declare it. But without a methodological basis, without using proven practices, you act intuitively, which can be quite risky.

The purpose of this article is to describe the main mistakes made when creating dashboards and to suggest ways to avoid them by implementing UX methods. The price of a mistake in user experience design is often not just the creation of a not entirely convenient working tool, but the risk that the system will cease to be developed because it is not used – users do not look at dashboards, since they are not able to help quickly and effectively solve business problems.

Things directly related to business and systems analysis that enable the creation of dashboards are not covered in this article, although they are undoubtedly extremely important.

The basic error that determines all others…

… this: do not read this and other publications dedicated to building user experience when creating and developing BI systems. Accordingly, do not plan and do not carry out UX design work, do not develop employee competencies and do not expect such work if you are the customer of the project.

How to avoid:

You are already reading the article. And – we recommend the following: depending on the scale of the system (project), the team should have people with the appropriate level of UX design competencies. These competencies can complement the qualifications of a business analyst or UI designer – or anyone else, not necessarily separate people. However, the more dashboards and tasks the system solves, the higher the level of specialists required.

Structural error when you don't have an information architecture

Let's start with a mistake that is as global as it is optional (yes, it sounds paradoxical). So, what happens when your system has developed a second, third and subsequent dashboards? There is a need to build some kind of navigation system that takes into account the roles of users (is your information unlikely to be equally accessible to everyone?). In its simplest form, this is a list of hyperlinks, each of which allows you to open the desired screen form. While there are few dashboards, you can use something like a set of bookmarks at the top or side of the screen, with their help you can switch between dashboards without leaving the page.

However, already at this stage (and especially when there are really many dashboards) the question arises: how to build a navigation system? If we discard the methods of “intuitively” and “by analogy with the example”, there remains the correct path, which many follow unconsciously – the creation of an information architecture.

Information architecture is a system of information organization that allows to build a complete user interface for using all the capabilities of the solution, including the navigation system and the management of the displayed content; it is a model of connections of entities, attributes, objects, functions – in relation to the business roles of users. By the way, it can also be useful in development – when designing logical models.

How to avoid: If you have more than five dashboards and some plan for the development of the system, it is recommended to do information architecture. If you have more than ten dashboards, do it for sure.

Information architecture can be built on a variety of principles, the main thing is that the structure is understandable and familiar to users and at the same time holistic, atomic and capable of development on the scale that you expect in the future.

To build an information architecture, it is necessary to choose a method and a basic hierarchy (it is possible and often even necessary to use several at the same time).

The construction method is the type of diagram you use – a classic tree, sequences, matrix, etc. Examples of hierarchies: by organizational structure, by areas of activity, by business processes, by KPI.

Mistakes in Forming Business Requirements

The main design work begins with defining the business goals (i.e. why the dashboard exists) and the business tasks that the dashboard (or dashboards) should help users solve. If it starts, of course. Established practice and limited resources, unfortunately, often lead to a simple solution – literally embodying the functional requirements received from the customer in the dashboard design. There is nothing wrong with this, of course; moreover, it is a reliable way to successfully pass acceptance tests. However, behind the scenes are the business value and convenience, efficiency, which can only be achieved by accident.

So, the errors:

• Dashboard has no purpose (it seems that the presented data is needed by the business, but why exactly the user will look at this dashboard and how he will use the information received remains “behind the scenes”);

• Dashboard created not for users (very similar to the previous error, but caused by insufficient user involvement in the requirements gathering process – or, if/when users are unavailable for any reason, insufficient study of the processes your dashboard should be implemented into. A special case could be, for example, the lack of differences in data display and management for different user roles – or visualization that does not take into account the display device);

• Used incorrect assumptions about the user’s knowledge and skills (the consequence of the previous error, however, can also be realized quite independently, if, for example, the designer simply does not use human-centered approaches – and judges others by himself, using non-obvious headings in the dashboard, controls and patterns of interaction with the system that are unfamiliar to most future users);

• Focusing on issues that are insignificant at this stage (an extremely important point and a very common mistake: before fixing goals, tasks, developing user scenarios, discussing with the customer and choosing types of diagrams, design colors, button types, etc. This radically increases the risks of creating a very visually appropriate solution that, nevertheless, will not be useful and in demand).

By the way, you can read about how exactly we recommend designing here: https://habr.com/ru/articles/816945/

Mistakes in the stage that everyone goes through, but often does not know about it

The first and main mistake is the lack of isolation of this stage. It seems that all the design in a low degree of visual fidelity can be done “in the mind”, casually, without wasting time on “useless work”, without generating additional artifacts. But it is not for nothing that this stage is given the maximum amount of time in the training programs of UX designers, it is definitely important and significant. It is here that we determine what exactly should be displayed on the dashboard, how it should be ordered and organized, how it should be managed, etc. These tasks should be solved at the convergence point of the results of business analysis and user experience design competencies, taking into account the specifics of user requirements and context; if they are not solved properly, then the following is quite possible:

• Not designed scenarios use (you can read more about this in the publication at the link above; briefly, we note that the lack of scenarios excludes the guarantee of achieving the desired goals by users when working with the dashboard, but makes dead-end situations quite likely, when the user's work process stops somewhere in the middle of the path, and what the user should do next to obtain the necessary information is absolutely unclear);

• Not implemented low fidelity design stages (these stages involve designing a dashboard using conventional screen areas, where the designer concentrates on dividing the space and placing the necessary elements, rather than on the final visual solution. This reduces the resource costs of iterative changes, while the sophistication of the user experience, on the contrary, increases significantly);

• No focus of attention (on the necessary information – with the proper ranking and in the right order, depending on the context, including the user's role and his actions in managing the dashboard);

• Trying to fit in too much (when a dashboard turns from an information panel that solves specific business problems into a complex board that requires careful concentration on certain areas of the screen. Such dashboards have every right to exist, but should only be created for those cases where such a design is truly justified);

• Flaw context and relatedness (both externally, for example, the lack of visualization of the current dashboard’s place in the overall hierarchy, and internally, for example, the lack of grouping of related indicators);

• Random arrangement of elements (in fact, of course, there should be absolutely nothing random in the dashboard – even for indicators of equal importance, you can find ways to order and/or rank them – or even more than one);

• Suboptimal visualization (when the types and properties of visualizations selected are not suitable for the tasks, i.e. the type of chart, its settings, text attributes, etc.; a classic example is displaying a small number of shares as a whole not using a pie/doughnut chart, but, say, an appropriate number of columns on the X-axis).

A mistake that can be made (or avoided) at both the previous and next stages

• Bad composition (There are many techniques for arranging elements in the desired area, both related to the hierarchy of information and based on harmony and aesthetics. Neglecting these techniques is not fatal, of course, but the quality of the composition definitely affects the user's perception, and therefore the efficiency of his work).

Errors at the design stage of a visual solution

These mistakes are more likely to be made in the aesthetics sphere, but the “I’m an artist, this is how I see it” solution is not suitable for business decisions. Therefore, a visual designer should be “supervised” by a UX designer (if these roles are not combined in one person) in order to avoid the following mistakes:

• Unnecessary decorative elements (yes, sometimes color blocks and compositions, pictograms, infographic elements or even photo images are needed and in demand, but only to solve the user’s problems, and not for aesthetic appeal);

• Not enough emptiness (air”) or, on the contrary, the abundance of the same emptiness

• Incorrect color scheme (too many or too few colors, incorrect color associations, when, for example, the corporate red color and the negative emphasis on the status of the indicator come into some conflict);

• Bad contrast (low readability) (this dashboard property should not be left to a subjective view; there are quite effective methods for measuring contrast – for example, based on Web Content Accessibility Guidelines 2.0, as well as tools that automate the process of such an assessment);

• Deficiency or excess metadata (It is often extremely difficult to shorten methodologically established names – and this is a task that should be solved, but of course, one should not forget to indicate units of measurement or other attributes).

Having considered the main errors, we will now provide a brief description of the work scenario in which their risk is minimized. This is achieved by involving specialists of the required level in the work on designing dashboards (the level range corresponds to the complexity range of the designed system or individual dashboard):

If everything is done correctly, we get the following example; it demonstrates a situation when you know perfectly well what the result should actually be. However, if we imagine that the dashboard is designed from scratch, the illustrations given above in the text may well reflect the vision of the designers. And the customer may well agree on them and accept them into operation (why – you can read here: https://habr.com/ru/articles/830916/).

Bonus for those who read to the end. All of the above is true not only for dashboards in BI systems, but also for presentation slides, if they display data and are designed to help achieve some business goal. Thus, obviously, the field for improving efficiency becomes even wider, and there are more reasons to think, right?