Designing a User Interface to Explore Collections of Directly-Follows Graphs for Process Mining Analysis

Designing a User Interface to Explore Collections of Directly-Follows Graphs for Process Mining Analysis Mar´ıa Salas-Urbano1,2(B), Carlos Capit´an-Agudo1,2 , Cristina Cabanillas1,2 , and Manuel Resinas1,2 1SCORE Lab, Universidad de Sevilla, Seville, Spain {msurbano,ccagudo,cristinacabanillas,resinas}@us.es 2I3US Institute, Universidad de Sevilla, Seville, Spain Abstract. Process mining tools use Directly-Follows Graphs (DFGs) as the main means of visualization for exploring event logs and extracting valuable insights therefrom. Extracting significant insights from DFGs is a laborious process that involves multiple data manipulation operations and comparisons between the resulting DFGs generated after each manipulation. However, current process mining tools lack the ability to uniformly manipulate and manage multiple DFGs in a consistent manner. The objective of this study is to identify the requirements for designing a user-friendly interface to handle collections of DFGs to search for interesting visualizations for process mining analysis. To achieve this, three different data sources were used: a literature review of visual query tools, the analysis of LoVizQL, a query language for process mining, and the examination of reports from Business Process Intelligence Challenges. By combining these sources, insights into interface design needs aligned with real process mining applications were obtained. As a result, we have identified 14 requirements grouped into 3 main categories. These requirements serve as the basis to build future user interfaces of visual query tools for process mining. Keywords: directly-follows graph ·process mining ·query language · requirements elicitation ·user interface 1 Introduction In process mining tools, Directly-Follows Graphs (DFG) are the most common visualization means used to explore event logs and search for relevant information in them [17]. The process of discovering insights from an event log usually This work has been funded by projects PID2022-140221NB-I00 (TAPIOCA), PID2021-126227NB-C21 (PERSEO) and TED2021-131023B-C22 (ORCHID) granted by MCIN/AEI/10.13039/501100011033/ and ERDF A way of making Europe. M. Salas-Urbano is supported by PREP2022-000372 financed by MICIN/AEI/10.13039/501100011033 and by FSE+. C. Capit´an-Agudo is supported by the Spanish Ministry of Education under the FPU national plan (FPU21/03631). https://doi.org/10.1007/978-3-031-61007-3_4 36 M. Salas-Urbano et al. involves multiple data manipulation operations and comparisons between the resulting DFGs generated after the manipulation. For example, consider a user who wishes to explore a log of travel declarations, in which different human resources are involved, with the goal of searching for resources whose process executions are associated with process delays. First, the user filters the cases related to the process execution of one concrete resource. Then, the user filters the cases by performance and examines the resulting DFG to gain insight and detect delays in the process. This process is repeated for each resource in the dataset, and the corresponding DFG is created in each iteration. To contrast the results, the user must apply the same filters repeatedly to understand the differences between the process executions related to the resources and discover relevant insights. This makes this whole process very manual and time-consuming. The underlying problem is that current process mining tools are not designed to explicitly consider the collection of DFGs that is created by the successive application of filters. In the previous example, the collection of DFGs would be the DFGs obtained after filtering by each resource [20]. Consequently, searching for visualizations with specific characteristics from such a collection requires several manual comparisons between visualizations. This problem is not specific to process mining, but can also be found in data analytics and is typically addressed using visual query tools [16]. In these tools, the users can generate collections of general purpose visualizations and they can query this collection to find visualizations specifying their desired patterns at high-level manner through interfaces [15,16]. For example, the users can identify line charts of products with increasing sales trends per year from a collection of line charts of all products sold by an organization. However, existing approaches are not well equipped to handle process event log data and DFGs as a visualization type. In this work, our objective is to identify the requirements to design a userfriendly interface to explore and manipulate DFG collections intuitively. Similarly to [13], we have elicited several requirements from three different and complementary sources as can be seen in Fig. 1. Firstly, we review the literature on visual query tools that operate with collections of visualizations [14,18,21,22] and analyze the main components of their interfaces. Secondly, we analyze LoVizQL [20], the only existing process mining approach for this purpose to the best of our knowledge. LoVizQL is a Log Data Visualization Query Language that allows users to retrieve collections of DFGs that meet specific conditions. Although it does not have a user interface, the query language model enables the identification of the information items required to query a collection of DFGs. Thirdly, we analyze reports sent to the last six Business Process Intelligence Challenges (BPICs) [5–10] to extract requirements based on actual use cases. The BPICs are annual contests in which an event log of one or more processes of an organization is published together with some business questions that participants must answer through data analysis. The participants send reports informing about the analysis performed and the results. We have analyzed the use of DFGs in these reports using a mixed-methods research approach similar to that used in [2,12] to understand how DFGs are used in practice, and Designing a UI to Explore Collections of DFGs for Process Mining Analysis 37 define requirements based on them. This variety of sources provides a better understanding of DFGs and the addition of use cases improves their alignment with its practical applications in process mining. The catalog of requirements obtained from these three sources provides the basis for the user interfaces of future visual query tools in process mining, which we use to discuss possible improvement points for current tool interfaces. The paper is structured as follows. Section 2outlines the literature related to this work. Section 3describes the methodology followed to conduct the analysis. Section 4provides details of the results. Section 5presents the findings and limitations of this research. Section 6summarizes the conclusions drawn and directions for future work. 2 Related Work In process mining, different query language approaches have been developed to search for information related to specific patterns [19]. On the one hand, there are languages that take event logs as inputs and search for information such as key performance indicators or data subsets [19]. On the other hand, other languages take process models as input (e.g., BPMN models), allow to modify them, and to search for specific process models or model parts [19]. There are also mixed approaches that retrieve information from event logs and process models. However, the previous query languages are not suitable to search for specific DFGs and their properties. While the first ones search for metrics but not process models, the second ones retrieve models but lack the capacity to search for metrics. Additionally, mixed approaches do not consider DFGs. Thus, the only existing approach to search for collection of DFGs that meet certain conditions, and retrieve their properties is Log Data Visualization Query Language (LoVizQL) [20] a query language inspired by the Zenvisage Query Language [21]. However, LoVizQL lacks an interactive interface to do this search, which can be a problem for certain users. This problem is tackled in this article. In the data visualization field, there are also query languages to search for interesting general-purpose visualizations (e.g., a scatterplot) in collections, and different approaches have been developed to facilitate this process by adding user-friendly interfaces [14,18,21,22]. This addition in query languages has resulted in visual query tools which aim to help users understand the result of a query more quickly, as well as to create the query itself [3]. In [16], three sensemaking processes followed by users are outlined which have been described as crucial for the design of a visual query tool. First, the context-creation process involves users navigating through diverse sets of visualizations and compare subsets of data to gain an understanding to search for patterns embedded within their data. Thus, this process helps users to discover the attributes that they are interested to consider in the search [15,21,22]. Once the user has discovered the attributes that she is interested, the following processes are followed (one or both): the top-down and bottom-up processes. In the first one, users have an initial intuition about the pattern that the data should follow and use it to guide 38 M. Salas-Urbano et al. the search. To support this process, visual query tools have integrated mechanisms in which users can articulate this pattern intuition to initiate queries. For example, some tools have integrated sketching boxes that allow users to draw the shape of the results of interest they want to obtain (e.g., an increasing linear trend between two attributes) [15,18,21,22]. Subsequently, they provide users with relevant results based on the described pattern. However, the findings in [11,16] indicate that sketch queries are not frequently used, because analysts often struggle to articulate their patterns of interest accurately. Consequently, some tools are integrating novel mechanisms, such as natural language search [23], where users describe their desired results in natural language and the tools generate the corresponding queries. In the bottom-up process, users use existing relevant observations in the data to define the pattern to be considered in the search. To ease this process, tools have integrated mechanisms to start the search by recommending visualizations with typical trends or data outliers [15,21]. However, the mechanisms that these visual query tools provide to support the sense-making processes in visualizations cannot be directly integrated with DFGs for several reasons. First, process mining considers filters that are not present in these tools (e.g., filters whose conditions are related to the execution order of process elements). Second, DFGs are a specific type of process mining representation that is very different from the visualization types considered in these tools. Third, the conditions to consider a pattern as interesting in process mining are different from those considered in these tools (e.g., searching for the bottlenecks of the process). Therefore, the query languages associated with these tools are not suitable for this task, as we indicated in [20]. 3 Research Methodology We aim to address the following research question: RQ: Which requirements should be considered in the interface design of a visual query tool to facilitate discovering insights from a DFG collection and performing comparisons on them? To answer this question we followed the research methodology illustrated in Fig. 1. Our objective is to derive the requirements for a user interface designed to manage collections of DFGs through a comprehensive requirement analysis from multiple perspectives. To address step 1 (requirements elicitation), we took inspiration from the approach followed in previous studies [13,23] and used three different data sources to analyze current tools and languages, conducted a domain analysis, and improved the understanding of the use of DFGs in practice. The diverse types of analyses performed on these data sources are outlined below. Details and materials are available in our repository1. Step 2 (prototyping) dealt with the design of a prototype of the user interface based on the elicited requirements, which shall be evaluated with real users, and conducting 1https://doi.org/10.5281/zenodo.10939675. Designing a UI to Explore Collections of DFGs for Process Mining Analysis 39 Fig. 1. Research methodology (the scope of this work is the blue dashed box) (Color figure online) interviews with experts to validate its usability. This task is outside the scope of this paper, but we present a wireframe created with Figma2software of a potential user interface aimed to better illustrate the identified requirements. Tools Analysis. We conducted an in-depth analysis of visual query tools that operate with collections of visualizations to explore the data [14,18,21,22]. Each tool was carefully examined to identify all requirements included in the interface. To this end, we extracted how each visual query tool presents the elements of its user interface (information items) and the purpose of each item. For example, one of the tools presented in [21] integrated a panel where the system suggested various visualizations to users based on the data context. Also, in [22]asketch frame was included to enable users to illustrate a desired pattern. Domain Analysis. For this analysis we relied on LoVizQL [20] as a domain model, a query language capable of handling collections of DFGs to search for those that meet specific criteria. Its queries are characterized by three main steps. In the first step, some event log subsets are created using filter operations defined by the user (e.g., filter traces in which a certain activity does not occur). Next, a DFG is created for each subset according to the metrics (e.g., average cycle time) and the attribute selected for the nodes (e.g., activities), which are defined by the user. Finally, the user can search for specific DFGs by specifying conditions related to properties or metrics of DFGs using functions (e.g., find the two DFGs with the minimum number of nodes). The DFGs that meet the conditions are displayed to the user, who can customize the resulting representation (e.g., percentage of nodes displayed). Using LoVizQL as a domain model helped us to identify the information items that are necessary in a user interface of a visual query tool for searching in collections of DFGs. 2https://www.figma.com/. 40 M. Salas-Urbano et al. Reports Analysis. The goal of this analysis was to identify the use cases that the user interface must support. In this paper, we tackle this goal by analyzing how DFGs were used in practice and what insights could be extracted from them. To this end, we carried out a mixed-methods research approach similar to that used in [2,12], based on multiple coding iterations to analyze the usage of DFGs in real-world process mining reports. As data source, we have used the 92 reports belonging to the last six editions of BPICs: 2015, 2016, 2017, 2018, 2019, and 2020. MAXQDA3software was utilized for the coding, and the approach for these iterations was inspired by the Grounded Theory methodology [1]. Before the analysis, we followed a deductive approach and created two types of codes to interpret the use of DFGs: descriptive codes and identification codes. Descriptive codes were used to identify what was represented in the DFG, such as the main process flow or the two most frequent process variants. Identification codes were used to signal when the analyst drew a conclusion or insight from the DFG (e.g., identifying a bottleneck as a result of a transition between activities with high cycle time depicted in the DFG). Afterwards, we followed an inductive approach and coded the information related to DFGs provided in the reports to figure out the codes related to each code type. Concerning the descriptive codes, we exclusively took into account the DFGs whose figures were included in the report. The DFGs mentioned in the text without illustration were disregarded in the coding process. In total, we coded 391 DFGs. Of the 92 available reports, 74 of them include DFGs with the respective figures. So, we considered six of nine reports in 2015, four of five in 2016, 23 of 23 in 2017, two of three in 2018, ten of 15 in 2019, and 29 of 37 in 2020. Furthermore, it was possible to assign multiple descriptive codes to the same figure to represent various features. Regarding the identification codes, we considered the insights that were clearly referred to a DFG, even though it was not explicitly mentioned. The coding process was iterative and we created a total of 42 codes: 20 descriptive codes and 22 identification codes. Subsequently, we grouped some of them by similarity, creating more general codes. So, finally, six more general codes were created for the descriptive category and seven for the identification category. Examples of descriptive codes are Show a filtered DFG and Zoom in the process. These general codes include more specific codes, such as Show a DFG filtered by an activity existence or Zoom in a transition between activities, respectively. Examples of general identification codes are Identify bottlenecks and Identify deviations from the happy path. Furthermore, specific codes are included, such as Identify activities as bottlenecks or Identify loops, respectively. Finally, we derived specific requirements for each descriptive code identified in the BPIC reports analysis, and we used the identification codes to define the mechanisms of pattern search and the parameters that can be customized in the search for patterns by the users (e.g., thresholds to identify bottlenecks). 3https://www.maxqda.com/es/. Designing a UI to Explore Collections of DFGs for Process Mining Analysis 41 4 Results Table 1shows all the requirements identified. For each row, which represents one requirement, we include: the necessary information elements in the user interface for that requirement, the source from which the requirement was extracted, the user story [4] to describe in natural language what is the user need and why, and finally a usage example obtained from the coded BPIC reports with its corresponding code to illustrate the need in real cases. Additionally, the requirements depicted in the table are grouped into three categories (represented with different colors) that have been identified from the current visual query tools based on the three sense-making processes described in Sect. 2. These categories include Context Creation,Pattern Search,andResults Information.Next,we detail each of these categories. 4.1 Context Creation The Context Creation group comprises requirements related to the specification of a collection of DFGs. A collection of DFGs is obtained from a set of event log subsets by performing some manipulation actions on them. First, this specification requires selecting the input data to generate the collection, which can be one or multiple event logs, as highlighted in the BPIC reports (e.g., to compare similar processes). This is the Event log requirement in Table 1. Second, it is necessary to indicate the filter parameters: Filter type and Filter condition requirements. The former indicates the type of filter that will be applied. There are different types of filters for event logs: those based on event attributes or those based on the process control flow, between others. The latter represents the need to express which data will be selected in the filter. Third, users can perform multiple consecutive filters by adding additional filters, which is indicated with the Number of filters requirement. Furthermore, the information included in the collection of DFGs also falls under the Context Creation group. This includes the attribute used for nodes (e.g., activity, phase, resource), and the metrics displayed in the nodes and transitions like cycle time or frequency (Node information and Node and transition metric requirements in Table 1). 4.2 Results Information This group includes requirements for visualizing the results of queries, that is, a collection of DFGs. To differentiate each DFG shown in this collection, it is necessary to use an identifier related to the data source (Data source identifier and Visualization of a collection of DFGs requirements in Table 1). Furthermore, in order to abstract away details in the DFGs, it is necessary to include the Activity threshold and Transition threshold requirements, which set thresholds that limit the nodes and transitions that appear in the DFG based on their frequencies, as it is usually done in most process mining tools. Finally, to visualize a DFG in more detail, it is required to define a zoom percentage that indicates the level of detail to go through (Zoom percentage requirement). 42 M. Salas-Urbano et al. Table 1. Elicited requirements. The Source column refers to Tools Analysis (T), Domain Analysis (D), and Reports Analysis (R). Screen numbers correspond to the wireframe in Fig. 2. Designing a UI to Explore Collections of DFGs for Process Mining Analysis 43 Table 2. Identification codes. General identification code (Specific identification codes) Identify activities (Identify activities with high duration, Identify infrequent activities, Identify the most frequent activities, Identify startpoint activities, Identify endpoint activities, Identify group of activities, Identify the activities belonging to a fragment) Identify resources (Identify resources with high workload, Identify resources by performed activities, Identify cluster of resources) Identify fragments (Identify the most frequent fragment, Identify a frequent sequence of fragments) Identify transitions (Identify transitions with high duration) Identify bottlenecks (Identify resources as bottlenecks, Identify activities as bottlenecks, Identify transitions as bottlenecks, Identify activity loops as bottlenecks) Identify deviations from the happy path (Identify activity loops, Identify outliers, Identify decision point activities) Identify differences (Identify differences between process flow and process model, Identify differences of throughput) 4.3 Pattern Search Requirements associated with the search of interesting visualizations are included in the Pattern Search group. These requirements are divided into two groups according to the search mechanism used. The bottom-up search group is required to display visualizations that may be relevant for users based on the current data context. These recommendations include a DFG collection with the corresponding description of the pattern based on the identification codes obtained from the BPIC reports analysis (Pattern description requirement in Table 1). The identification codes extracted are shown in Table 2. This allows the user to express interest in some pattern and obtain the corresponding query by selecting the desired visualization. For instance, the system could show DFGs where resources are identified as bottlenecks as shown on the third screen in Fig. 2. The top-down search group includes requirements about the specification of the patterns. The purpose is to present interesting query objectives to users based on the data context. Thus, some parameters associated with the specification of the pattern are required. It is necessary to specify the pattern function of interest based on identification codes extracted from the analysis of the BPIC reports (Pattern function requirement), such as: Identify transitions with high cycle time,Identify activity loops,orIdentify resources with high workload (cf. Table 2). Additionally, it is required to customize this pattern determining some conditions (Pattern condition requirement). For example, the system could display visualizations that highlight transitions with high cycle times. However, determining what qualifies as a high cycle time lacks a universal criterion. There-