Information dashboards are useful tools for exploiting datasets and support decision-making processes. However, these tools are not trivial to design and build. Information dashboards not only involve a set of visualizations and handlers to manage the presented data, but also a set of users that will potentially benefit from the knowledge generated by interacting with the data. It is important to know and understand the requirements of the final users of a dashboard because they will influence the design processes. But several user profiles can be involved, making these processes even more complicated. This paper identifies and discusses why it is essential to include the final users when modeling a dashboard. Through meta-modeling, different characteristics of potential users are structured, thus obtaining a meta-model that dissects not only technical and functional features of a dashboard (from an abstract point of view) but also the different aspects of the final users that will make use of it. By identifying these user characteristics and by arranging them into a meta-model, software engineering paradigms such as model-driven development or software product lines can employ it as an input for generating concrete dashboard products. This approach could be useful for generating Learning Analytics dashboards that take into account the users' motivations, beliefs, and knowledge.
Information dashboards are compelling tools for generating knowledge and for supporting data-driven decisions. These tools allow users to visually understand and extract patterns from their datasets, fostering informed decision-making processes.
However, dashboards are also sophisticated tools, both in terms of development and use. First, the development of an information dashboard is not trivial; developers need to detail and understand the goal of the dashboard, the domain in which it will be framed, the information that will be presented, and, last but not least, the users that will use the dashboard.
Users, from an abstract point of view, are complex entities, with different
characteristics from one to the other, with different behaviors, beliefs, and goals [
In existing literature about the process of designing a dashboard, several authors
point out the necessity of taking into account the problem to be solved through the
visual presentation of data [
Generalizing these user dimensions can be useful to understand the problem's domain better, to improve the dashboards' development processes, and to provide personalized products that take into account individual requirements. That is the reason why it is crucial to extract commonalities in user tasks and interactions, no matter the data context or domain. In the end, the user behavior is based in primitive tasks (pan, zoom, click, hover, etc.) that will provide them with outputs to reach their goals and to improve insights delivery processes.
Some software engineering paradigms can benefit from the abstraction of the
elements that compose a dashboard, users included. Such paradigms, like model-driven
development (MDD) [
In this paper, an extension of a previously developed dashboard meta-model [1012] is presented. This extension takes into account different user dimensions that can influence dashboard components, to establish a framework for generating personalized dashboards that foster better user experience and insights delivery.
Characterizing the user could lead to benefits in fields like Learning Analytics (LA),
where dashboards showing the users’ learning data could be counterproductive if
individual aspects are not addressed [
The remainder of this paper is organized as follows. Section 2 describes the methodology followed to model the user from an abstract point of view using meta-modeling. In Section 3, the obtained meta-model is provided and explained. In Section 4, the meta-model is discussed, to finally close with Section 6, where conclusions and future research lines are presented.
The followed methodology employs a meta-model, an artifact from the model-driven
architecture paradigm [
But why applying meta-modeling to the dashboards' domain? As introduced, this
domain is extraordinarily complex, because not only the technical features of a
dashboard should be identified and detailed, but also the final users’ characteristics that can
influence their experience with the dashboard. Through domain engineering [
These abstract models can be mapped to concrete products, according to the OMG
four-layer meta-model architecture [
In this section, the designed meta-model is presented. As introduced in the previous section, the level of abstraction of the meta-model is high, to capture generic commonalities among the potential objects. The main benefit from these levels of abstraction is the achievement of a general model from which concrete models can be instantiated.
The initial dashboard meta-model to be extended consist of five main classes, and two specializations (showed in Fig. 1). This meta-model captures at a very high level the different components of an information dashboard, as well as its generic layout, which, in the end, is based on containers that can be either rows and columns. A user could employ one or more dashboards, and a dashboard, through this approach, belong to one user, because involving more users would introduce noise in the personalization process of a dashboard.
As can be seen in this simple meta-model, details are omitted. The User class represents a high-level user, but none of his or her characteristics are represented nor detailed. However, the user should be defined in terms of different significant and influential aspects to support a personalized dashboard design, thus being necessary to extend this meta-model with more elements regarding the users’ characteristics and goals, as well as defining the relations of these aspects with the dashboard’s components.
Given that, the extended dashboard meta-model is presented in Fig. 2. The diagram represents the same dashboard structure as in Fig. 1, but in this case, the user has been decomposed in terms of his or her goals and his or her characteristics.
Firstly, a new concept arises; Goal. A user employing a dashboard must have at least one goal, however implicit. Even users that want to explore data casually have a goal (that is, exploring data itself). That is the reason for the "one or more" (1..*) multiplicity. In turn, a goal can belong to any user, and users can share common and general purposes, explaining the "zero or more" (*) multiplicity on that side of the relation.
On the other hand, a goal can be broken down into individual and more specific tasks. Simple goals can be accomplished by performing one task, e.g. if a concrete goal is “to know which USA city has the largest number of inhabitants," a straightforward yet necessary task could be “to sort USA cities by population number," meaning that the dashboard components must support sorting capabilities.
However, more complex goals might involve several specific and chained tasks such as “to understand why there has been a business income loss within the last six months," which could involve applying different tasks to different dimensions of the data to reach insights about the stated problem. That is the reason why the dashboard’s components need to support the identified responsibilities to enable them.
Finally, a user can have zero or more identified characteristics, given the fact that, at a certain point, there could be no user data available of the possible dimensions. These characteristics can belong to zero or more users, as different users can share general characteristics. Characteristics can be of a different kind; preferences, disabilities, knowledge about different domains, visualization literacy, and bias (action, perceptual, or social bias). These characteristics can influence the dashboard’s components to adapt them and, therefore, to match the identified user aspects. 4
Including the user as an extremely significant element within the dashboard, domain is
crucial. The development processes of a visualizations and dashboards start with the
user (requirement elicitation) and end with the user (product refining) [
The developed meta-model defines the users of a dashboard in terms of their goals
and their characteristics. The users' goals drive the whole dashboard design processes,
as it will influence user behavior when interacting with the dashboard's components
[
High-level user goals and user characteristics would be mapped low-level interactions in particular dashboard views presenting specific data dimensions to provide the user with a dashboard that could fulfill their information needs.
Once goals are addressed at high-level, the next phase is to take into account user preferences (implicitly exposed in its purposes, like, for example, the data that the user is interested in) as well as other characteristics, like the user’s knowledge level about the data domain, the user’s visual literacy and the user’s potential biases. This process would provide the most suitable view type by configuring recognizable visual marks or visual metaphors, proper axes domains, preferred visual design, etc. Finally, user disabilities, such as color blindness, hand tremors, etc., would refine the dashboards' visual design and interaction methods by choosing right color palettes, mouse sensibility, etc.
The listed characteristics are hugely significant as they play an essential role when
interpreting visualizations and reaching insights from them. For example, not being
familiar with a type a visualization can lead to confusion and could be error prone when
trying to reach insights [
On the other hand, user bias is not only influenced by past visualization experiences,
but also by gender, age, race, etc. Why is it important to take this information into
account? It could be seen as irrelevant factors, but the truth is that, unconsciously, bias
could lead to valuable information loss [
Using generalization for modeling the above characteristics support the inclusion of
new factors that might arise, allowing the meta-model’s evolution. These identified
factors can influence dashboards to match both explicit and implicit characteristics,
obtaining an effective and tailored visualization tool. However, there should also be room
for customizing the dashboard, as the user should also have the freedom to craft their
dashboards or to modify certain features. The main drawback of this approach is the
retrieval of all the presented user dimensions, not only because several factors are
involved, but because the information must be precise to map these characteristics into
proper dashboard components successfully. Questionnaires about the different
dimensions could be employed, like [
Understanding user necessities is essential in the dashboard domain, but especially
in some subdomains, such as LA dashboards. LA dashboards aim at visually assisting
users (teachers, students, etc.) through a “single display that aggregates different
indicators about learner(s), learning process(es) and learning context(s) into one or multiple
visualizations," as stated in [
In this paper, a dashboards meta-model extension is presented. The extension involves the inclusion of the final users as the main element of a dashboard, given their influence in the different design processes regarding the development of these tools. Different perspectives of the user are identified and discussed, such as the user goals, preferences, bias, disabilities, etc., to include them in the meta-model through high-level classes.
The purpose of having a dashboards meta-model is to provide a framework for instantiating any possible dashboard product, enabling personalization of individual dashboards. This approach could be useful for tailoring LA dashboards, where the necessities of each user can depend on their learning processes and motivations.
Future research lines would involve refining the meta-model through the addition of more specific properties, constraints, rules and the inclusion of design guidelines to support the automatic generation of concrete dashboards by instantiating the metamodel, and also designing questionnaires and methods to retrieve the presented user characteristics to finally implement the meta-model and validate it through case studies. Acknowledgements This research work has been supported by the Spanish Ministry of Education and Vocational Training under a FPU fellowship (FPU17/03276). This work has been partially funded by the Spanish Government Ministry of Economy and Competitiveness throughout the DEFINES project (Ref. TIN2016-80172-R), T-CUIDA project (Ref. SA061P17), and the PROVIDEDH project, funded within the CHIST-ERA Programme under the national grant agreement: PCIN-2017-064 (MINECO, Spain).