User Interface Design Patterns for Infotainment Systems Based on Driver Distraction: A Colombian Case Study

: In this paper, we present a set of nine user interface design patterns for in-vehicle infotainment systems centered on the content, interaction mode, style, shortcuts, and notiﬁcations of the system, which are built based on both theoretical support and an empirical pattern ﬁnding process. This empirical process consists in an exploratory test made with 10 users from an age range from 18 to 29 and with a minimum of 2 years of driving experience, who were asked to perform a set of 13 secondary tasks in the vehicle to identify recurrent problems, behavioral patterns, and best practices. The output of this exploratory test was used as the main data source for the design patterns consolidation. It is worth mentioning that the proposal of these patterns arose as an initiative to begin to consider factors that can affect the driver’s experience in the Latin American context. The set of design patterns has been validated via a content validation (as an exploratory study) by a panel of Latin American experts in the area of HCI and UX through the development of a prototype using the patterns as a tool for the redesign proposal of the infotainment systems tested during the empirical ﬁnding process. attention when trying to play a song while driving. interaction 1, would imply that unlocking the screen would lead drivers to risky situations such as unlocked all the time. Additionally, partial unlocking in these cases user of the system.


Introduction
Today, the automotive industry has been positioned as one of the most important economic sectors in the world [1]. In recent years, globalization, digitization, and the constant growth of competition have caused this industry to face a great number of challenges and changes [2]. These new challenges lead the different companies to make decisions in the design, development, manufacturing, and other processes, to improve the experience of drivers and passengers. New technologies such as autonomous vehicles, the Internet of Things (IoT), facial recognition, gesture detection, modern infotainment systems, among others, immerse users in a world full of opportunities for interaction and bring with them an incalculable number of additional activities to the portfolio of tasks compared to previous years [3]. One of the technological trajectories that has managed to emerge in conjunction with the growth of the automotive industry is the incorporation of infotainment systems in vehicles [4]. An in-vehicle infotainment system, or IVIS, corresponds to the set of components used to provide information and entertainment to the driver and other passengers in the vehicle, through interfaces supported with audio and video, control elements such as touch screens, central panels with buttons, voice commands, among others [5]. These kind of IVISs bring with them a world full of interaction opportunities for both the driver and other passengers to complete driving-related tasks and other secondary activities mostly related to entertainment that complement the in-vehicle experience. However, the increase in the number of components provided by this type of system, and even the design under environment and context in which the system will be used, in addition to involving the user during the design and development process [24]. This explicit understanding of the user, their requirements and their environment, helps designers to have a better understanding of their mental model, and the smaller the gap between the designer's mental model and the user's mental model, the probabilities of having a positive user experience will be greater, because errors can be prevented and the user's navigation through the system occurs in a more intuitive way [25]. This is a special form of "Mental Models", a term strongly associated with [26] the so-called "Situation Models", as per [27]. Ideally, one would like to also have the UX device itself have a situation model of different aspects of the human being, their environment, and the tasks at hand for the human, in order to adapt its behavior and, thus, try to reduce some dangers; certainly, part of the future research will go toward that direction toward pro-active interfaces that understand the situation and the user's current tasks and intentions. In that way, the so-called "Grounded Situation Model" [28] theory and techniques will be of primary importance to be considered in further works. For that reason it is too relevant to consider cultural aspects into the design of any kind of interactive systems (and in particular in the infotainment systems design) [29].

Pattern Finding Process
After a systematic literature review, one of the main conclusions was the lack of relevant literature in the Latin-American context in the design of infotainment systems. In order to characterize the drivers' behavior during the execution of secondary tasks in the vehicle, and thus be able to identify the elements to be considered in the patterns to build it was decided to conduct a test in which a set of users carried out multiple activities while driving in order to collect data related to completion times, interaction times, interaction cost, workload, etc., and with that in mind, be able to identify pain points, behavior patterns and good practices of Colombian users when interacting with infotainment systems. In that way, a set of steps was carried out (Figure 1).

Survey
As an initial activity, an online survey was built in order to obtain information about frequency of use of Infotainment Systems in the Colombian context, also trying to determine the ages of people who more frequently use these kinds of infotainment systems and the most relevant task people use when interacting with these kinds of devices.

Participants
Ninety-one (91) people participated in the survey (ages ranging from 18 to 60 years) Then, and according to the survey, where ~90% of drivers from the 18 to 29 age range reported using IVIS with high frequency, we selected only ten drivers (5 males, 5 females) for the final test, with ages ranging from 18 to 29 years (mean = 23, SD = 2.74). All participants had a valid Colombian driver's license and at least 2 years of driving experience.

Driving Environment
Testing was conducted using a Mazda 3 ® 2018 model. This vehicle was selected on the basis of Mazda being one of the top three brands with the highest number of registered vehicles of 2020 in Colombia [30], and its native infotainment system, the Mazda Con-nectTM, was classified as a system that placed very high visual and cognitive demand on drivers according to research conducted by the AAA's Center for Driving Safety and Tech-

Survey
As an initial activity, an online survey was built in order to obtain information about frequency of use of Infotainment Systems in the Colombian context, also trying to determine the ages of people who more frequently use these kinds of infotainment systems and the most relevant task people use when interacting with these kinds of devices.

Participants
Ninety-one (91) people participated in the survey (ages ranging from 18 to 60 years). Then, and according to the survey, where~90% of drivers from the 18 to 29 age range reported using IVIS with high frequency, we selected only ten drivers (5 males, 5 females) for the final test, with ages ranging from 18 to 29 years (mean = 23, SD = 2.74). All participants had a valid Colombian driver's license and at least 2 years of driving experience.

Driving Environment
Testing was conducted using a Mazda 3 ® 2018 model. This vehicle was selected on the basis of Mazda being one of the top three brands with the highest number of registered vehicles of 2020 in Colombia [30], and its native infotainment system, the Mazda ConnectTM, was classified as a system that placed very high visual and cognitive demand on drivers according to research conducted by the AAA's Center for Driving Safety and Technology [31]. As the experiment sought to characterize the drivers' behavior when executing distracting tasks regardless of the IVIS, we also did the test on a second IVIS: Apple CarPlay ® . CarPlay was installed in the same vehicle and provided some navigation and internet-related tasks that Mazda's native infotainment system did not offer. The vehicle was equipped with three cellphone cameras-one facing the road, one facing the IVIS' touchscreen and one facing the participant ( Figure 2). All cameras were carefully positioned in a way that did not obstruct the participant's view or cause any additional distraction. Moreover, it is worth mentioning that the on-road test was conducted on an open area in Popayán, Colombia, with very low traffic and straight roads with some turning points. Participants could do as many laps as necessary to complete all the tasks. nology [31]. As the experiment sought to characterize the drivers' behavior when executing distracting tasks regardless of the IVIS, we also did the test on a second IVIS: Apple CarPlay ® . CarPlay was installed in the same vehicle and provided some navigation and internet-related tasks that Mazda's native infotainment system did not offer. The vehicle was equipped with three cellphone cameras-one facing the road, one facing the IVIS touchscreen and one facing the participant ( Figure 2). All cameras were carefully positioned in a way that did not obstruct the participant's view or cause any additional distraction. Moreover, it is worth mentioning that the on-road test was conducted on an open area in Popayán, Colombia, with very low traffic and straight roads with some turning points. Participants could do as many laps as necessary to complete all the tasks.

Secondary Tasks
The tasks that the experimenter instructed the participants to do were chosen from the same 91 drivers' survey mentioned earlier, in which the participants reported the tasks they performed with more frequency and the ones that they thought were more distracting. In total, 13 tasks were chosen; some of them were the same for the two IVIS, while others were specific to just one. The list is presented below: On Mazda Connect TM : 1. Connect mobile phone via Bluetooth. 2. Make a phone call from the main screen. 3. Answer a phone call from the main screen. 4. Play a mobile phone song via Bluetooth from the main screen. 5. Tune in to a specific FM radio station from the main screen. 6. Search vehicle sound information from the main screen. 7. Set the system language from the main screen.
On Apple CarPlay ® : 1. Make a phone call from the main screen. 2. Answer a phone call from the main screen. 3. Compose a text message from the main screen. 4. Receive a text message from the main screen. 5. Play a song from the mobile phone through an Internet application from the main screen (Spotify ® ). 6. Set a navigation route from the main screen (Waze TM ).

Execution Tasks
The execution task consisted of one session that would last 45 min or less, where each driver had to complete the 13 secondary tasks on the infotainment system, while they drove following a slow traffic route. Participants were given some time to adjust their seat

Secondary Tasks
The tasks that the experimenter instructed the participants to do were chosen from the same 91 drivers' survey mentioned earlier, in which the participants reported the tasks they performed with more frequency and the ones that they thought were more distracting. In total, 13 tasks were chosen; some of them were the same for the two IVIS, while others were specific to just one. The list is presented below: On Mazda Connect TM : 1.
Connect mobile phone via Bluetooth.

2.
Make a phone call from the main screen.

3.
Answer a phone call from the main screen.

4.
Play a mobile phone song via Bluetooth from the main screen.

5.
Tune in to a specific FM radio station from the main screen. 6.
Search vehicle sound information from the main screen. 7.
Set the system language from the main screen.
On Apple CarPlay ® : 1. Make a phone call from the main screen.

2.
Answer a phone call from the main screen.

3.
Compose a text message from the main screen.

4.
Receive a text message from the main screen.

5.
Play a song from the mobile phone through an Internet application from the main screen (Spotify ® ). 6.
Set a navigation route from the main screen (Waze TM ).

Execution Tasks
The execution task consisted of one session that would last 45 min or less, where each driver had to complete the 13 secondary tasks on the infotainment system, while they drove following a slow traffic route. Participants were given some time to adjust their seat and test-drive the vehicle and the route they had to follow. Once they felt comfortable and ready, the video recording was started, and the experimenter began to instruct the tasks that the participant had to complete. Participants were highly encouraged to make comments or express their feelings while they were doing the tasks (Thinking aloud protocol [32]) and were told multiple times about prioritizing safety. They were also free to choose their preferred interaction mode (e.g., touchscreen, console's physical controls), but if they wanted to use the touch option, they had to drive very slowly, because the Mazda Connect TM touchscreen auto-locks when the driver exceeds a speed greater than 10 km/h. No time limit was set for completing the tasks or the test in general. It is worth mentioning that the observational method [33,34] was carried out during all the experiment execution, because we wanted to gather all data possible from the users' experiences.
After the on-road test was over, participants were taken to a room where they had to fill out the DALI test. DALI is a method for measuring users' subjective mental workload. It is based on the NASA Task Load Index (NASA TLX), adapted to the driving context [35]. In the DALI test, drivers are asked to rate secondary tasks, post-trial, along with six rating scales: effort of attention, visual demand, auditory demand, temporal demand, interference and situational stress. To prevent participants from forgetting details from their test and how they performed, we played the video recordings from each task while they answered the corresponding question of the DALI test (retrospective testing [36]). Last, but definitely not least, participants gave overall feedback about the experience.

Metrics
After performing the test with the 10 users and gathering diverse information from it, some methods were implemented to fully understand the drivers' behavior and give value to the data. As a summary, there were proposed three main to-track metrics to comprehend the overall performance and behavior of the user in each task. These three metrics are the following: net interaction time, interaction cost, and mental workload.
Each of the tasks was analyzed in detail based on these metrics to identify the moments of interaction that cost the most to users, the tasks that required the highest demand and attention effort, and similar behaviors among drivers, all with the purpose of listing a set of problems and good practices that would be the main source of empirical information for the construction of the patterns. Conducting multiple statistical exercises, analysis of interaction graphs, user segmentations and deep dives in the users' recordings, allowed us to obtain a large number of insights that led to the following preliminary outputs of this phase of the study:

1.
It was possible to validate that the problem described in the introductory section is evident in the Colombian context, because most tasks presented pain points that deteriorated the driver's experience, and in an even more real scenario, they could have been subjected to dangerous situations due to the distraction generated.

2.
It was possible to characterize the behavior of the users regarding the execution of tasks in the infotainment system by identifying pain points in the interaction and also the analysis of the good practices carried out by the users. Both pain points and good practices are the main source of information for the construction of user interface design patterns.

3.
The metrics for evaluating the tasks (i.e., interaction time, interaction cost and mental workload) were obtained to have them as a point of comparison in the Pattern Validation section, and thus be able to show whether the patterns brought improvements or not.

Pattern Structure
In the field of HCI, patterns have been used to document the results of empirical studies because they allow structuring and compiling the results of the study in a systematic manner [37]. Generally, design patterns are presented with a specific structure or on a template; however, there is no single defined structure to present them, but different authors have established their own presentation structure. For the definition of the structure of the design patterns of this research, some representative models of user interface design patterns and interaction design patterns were reviewed.
The revised design pattern models include the Interaction Design Patterns by Van Welie [38], the User Interface Design Patterns by Anders Toxboe [39], the Automotive User Experience Design Patterns from the HCI Center of the University of Salzburg, Austria [22], the Patterns for Effective Interaction Design by Tidwell [40], and Contextual User Experience Patterns from the HCI and usability unit of the University of Salzburg, Austria [41]. Based on the identification of each of the attributes or sections defined in the revised pattern models, a comparative table was made, which can be seen in Table 1. From the analysis of the comparison of models presented in Table 1, it was decided that the patterns of this work would be composed of the attributes present in most of the revised proposals (Name, Problem, Solution, Use when, Examples), and that an attribute called Category would be added to describe a general area in which each pattern can be classified. The structure defined for the presentation of the design patterns of this research can be seen in Table 2. Table 2. Defined structure for the user interface design patterns.

Problem
Description of the problem the pattern is expected to address or solve.

Solution
Description of the proposed solution to solve the problem. The design solutions can range from very general suggestions to very concrete suggestions for the specific pattern and are supported by empirical results, theoretical foundations, recommendations and existing guidelines.
Use when Description of the situation or possible scenarios in which it is appropriate to apply the solution.

Example
Presentation of one or more examples that illustrate more clearly the use of the pattern.

Category
General area in which the pattern can be classified. It can be used to have a simpler reading of the complete set of patterns.
The categories in which the patterns were classified are described below: Shortcuts: This category is composed of patterns that seek to provide alternatives to access a section or functionality of the system in an agile way to complete frequent tasks in less time.
Content: This category is composed of patterns that include solutions related to the structure of the interface, the composition of the interface menus, the organization of the displayed information and the limitation of on-screen functionalities.
Interaction mode: This category is composed of patterns that specify relevant aspects to improve the way in which the driver interacts with the system.
Style: This category is composed of patterns related to the elements of the system and their attributes, which allow an assertive communication of the system functionalities and help to maintain the aesthetic appeal of the interface.
Notifications: This category is composed of patterns that seek to specify the way in which the system status and warnings coming from applications are reported to the driver.

User Interface Design Patterns
According to the pain points, behavior patterns and good practices of the drivers during the execution of secondary tasks in the empirical test described in the Pattern Finding Process section, it was possible to consolidate a set of nine user interface design patterns. These patterns present design solutions regarding the driver's needs and requirements in the user interface, addressing problems and solutions related to content, interaction mode, style, shortcuts, and notifications. The main objective of the patterns is to help reduce the net time of interaction, cost of interaction and mental workload perceived by drivers when performing secondary tasks in the infotainment systems, and thus be able to contribute to the reduction in driver distraction.
The link to the full extended version of the design patterns can be found here: https: //tinyurl.com/userinterfacedesignpatterns (accessed on 2 May 2022). Please refer to the link for a better understanding of the solution proposed in each pattern and to find the numerous design implications to be taken into account to apply the solution in the most optimal way. Likewise, the examples are described more extensively and with more illustrations in the full version of the patterns. Tables 3-11 summarize the proposal of the nine user interface design patterns. Table 3. Physical buttons as shortcuts in the system.

Problem
The driver needs to access a section or functionality of the system in an agile way to perform a task that is considered frequent in the user's geographical context.

Solution
Including a physical button or key as a shortcut can reduce the interaction cost, the net interaction time and even the driver's mental workload when performing a task. Reducing any of these three factors can result in a decrease in the level of distraction generated by the task. When including a physical button or key, the following should be considered: The physical button must include an icon or text label. If an icon is included, it must be related to the functionality of the button, it must be intuitive for the driver, and it must be understandable in the geographical context where it is used. Preferably, it should be a universally understood icon [39][40][41].
If a text label is included, it must be related to the functionality of the button, must be very descriptive to the driver, and must use vocabulary that is easily understood in the geographical context of use. Preferably, it should contain words that are universally understood [41][42][43][44][45][46][47].
Text labels serve as an alternative to identify buttons when graphic symbols or icons could become ambiguous or context dependent [43,48,49]. Additionally: The physical buttons should be strategically placed in the vehicle so that the driver can reach them as quickly as possible, thus avoiding a high level of manual distraction [22,50].
The number of physical shortcuts should be limited, allowing the driver to perform only the most frequent tasks in the driver's context. This is to avoid a saturation of options that would prevent meeting the pattern's objective, which is to execute the main tasks in a more agile way.
Use when Use only when the task has been identified as a frequently performed task in the user's geographic context, that is, in the country or region where the interface design will be implemented.

Example
Playing a song on the infotainment system is one of the most recurring tasks in the context in which the study was carried out. Figure 3 shows how the normal interaction flow to play a song implies a high interaction cost for the driver, which also increases the task time and perceived mental workload of the driver. Figure 4 shows how the use of a physical shortcut located in the center console can reduce the number of steps required to complete the same task, which also reduces the task time and cognitive load of the driver.

of 24
Example study was carried out. Figure 3 shows how the normal interaction flow to play a song implies a high interaction cost for the driver, which also increases the task time and perceived mental workload of the driver. Figure 4 shows how the use of a physical shortcut located in the center console can reduce the number of steps required to complete the same task, which also reduces the task time and cognitive load of the driver. Category Shortcuts

Problem
The driver needs to access a section or functionality of the system in an agile way to complete a task that they frequently perform.

Solution
Including a personalized quick access bar with shortcuts can reduce the interaction cost, the net interaction time and even the driver's mental workload when performing a task. Reducing any of these three factors can result in a decrease in the level of distraction generated by the task. driver. Category Shortcuts

Problem
The driver needs to access a section or functionality of the system in an agile way to complete a task that they frequently perform.

Solution
Including a personalized quick access bar with shortcuts can reduce the interaction cost, the net interaction time and even the driver's mental workload when performing a task. Reducing any of these three factors can result in a decrease in the level of distraction generated by the task.

Problem
The driver needs to access a section or functionality of the system in an agile way to complete a task that they frequently perform.

Solution
Including a personalized quick access bar with shortcuts can reduce the interaction cost, the net interaction time and even the driver's mental workload when performing a task. Reducing any of these three factors can result in a decrease in the level of distraction generated by the task. The shortcuts included in the bar should adjust to the user's behavior based on how often he/she performs tasks on the system, and thus the bar is automatically updated according to that frequency [51,52]. Personalizing the interface according to user behavior can result in higher levels of efficiency, and therefore greater overall user satisfaction. Additionally, the interface personalization can increase the performance of the task execution and reduce the level of effort required to complete it [53,54]. When including this quick access bar, the following should be considered: Each shortcut included in the bar must have an icon. The icon must be related to the functionality of the shortcut, it must be intuitive for the driver, and it must be understandable in the geographical context where it is used. Preferably, it should be a universally understood icon [42,48,55].
In the case of a particular company's application, it is recommended to use the application's logo as an icon [56].
In the case of an application also included in mobile phones, the icon in the system must include the same logo that appears on said devices to preserve consistency [57]. Additionally: The bar should be strategically placed in the interface so that the driver can reach it as quickly as possible, thus avoiding a high level of manual distraction [50]. The bar must be visible at all times so that the driver can easily access the applications from any interface they are in, even if they are performing another task. The number of shortcuts within the bar should be limited, allowing the driver to perform the tasks they perform most frequently [5]. This is to avoid a saturation of options that would prevent meeting the pattern's objective, which is to execute recurring tasks in a more agile way.
Use when Use only when the task is frequently performed by the driver.

Attribute Description
Example Following a regular interaction flow without shortcuts, to access an application included in the system, the driver must scroll back multiple times to reach the main menu, then swipe to the page where the application is located and subsequently enter it. Figure 5 shows how the driver enters the Spotify ® application when they initially were in the wallpaper configuration interface.
Using the quick access bar, the driver can enter the Spotify app with a single interaction cost from any interface they are on, as shown in Figure 6.
In the case of a particular company's application, it is recommended to use the application's logo as an icon [56].
In the case of an application also included in mobile phones, the icon in the system must include the same logo that appears on said devices to preserve consistency [57]. Additionally: The bar should be strategically placed in the interface so that the driver can reach it as quickly as possible, thus avoiding a high level of manual distraction [50]. The bar must be visible at all times so that the driver can easily access the applications from any interface they are in, even if they are performing another task. The number of shortcuts within the bar should be limited, allowing the driver to perform the tasks they perform most frequently [5]. This is to avoid a saturation of options that would prevent meeting the pattern's objective, which is to execute recurring tasks in a more agile way. Use when Use only when the task is frequently performed by the driver.

Example
Following a regular interaction flow without shortcuts, to access an application included in the system, the driver must scroll back multiple times to reach the main menu, then swipe to the page where the application is located and subsequently enter it. Figure 5 shows how the driver enters the Spotify ® application when they initially were in the wallpaper configuration interface.
Using the quick access bar, the driver can enter the Spotify app with a single interaction cost from any interface they are on, as shown in Figure 6. Category Shortcuts

Attribute Description Problem
The interface menus must be structured in a way that allows the driver to complete a task in the most efficient way.

Solution
Limiting the depth and breadth of the interface menus can reduce the interaction cost, the net interaction time, and even the driver's mental workload when performing a task. Reducing any of these three factors can result in a decrease in the level of distraction generated by the task. The depth of the menu refers to the number of sublevels or categories within the menu, while the breadth refers to the number of options in each of these sublevels [58][59][60].
In order to constrain menu attributes, one can follow the empirically derived Formula (1) provided by Burnett et al. [61], which is T = D (0.87 + 1.24 * loge(B)) (1) where T is the time to complete the task, D is the depth of the menu, and B is the breadth of the menu. This formula seeks to find a value for the depth and breadth of the menu, which would result in a task completion time that does not exceed the recommendations of international associations such as NHTSA, which indicates that a task should not allow the user to look away from the road for more than 12 s, divided into 6 periods of 2 s or less, or 9 s divided into 6 periods of 1.5 s or less [11]. Other cases such as the JAMA guidelines, recommend not exceeding a time of 7.5 s [10], and the AAM principles suggest not exceeding 15 s [18]. In case of wanting to follow the NHTSA guidelines, and the 12-s recommendation factor, The following content can be used to maintain a structure in the menus according to the recommendation.

Problem
The interface menus must be structured in a way that allows the driver to complete a task in the most efficient way.

Solution
Limiting the depth and breadth of the interface menus can reduce the interaction cost, the net interaction time, and even the driver's mental workload when performing a task. Reducing any of these three factors can result in a decrease in the level of distraction generated by the task. The depth of the menu refers to the number of sublevels or categories within the menu, while the breadth refers to the number of options in each of these sublevels [58][59][60].
In order to constrain menu attributes, one can follow the empirically derived Formula (1) provided by Burnett et al. [61], which is T = D (0.87 + 1.24 * loge(B)) (1) where T is the time to complete the task, D is the depth of the menu, and B is the breadth of the menu. This formula seeks to find a value for the depth and breadth of the menu, which would result in a task completion time that does not exceed the recommendations of international associations such as NHTSA, which indicates that a task should not allow the user to look away from the road for more than 12 s, divided into 6 periods of 2 s or less, or 9 s divided into 6 periods of 1.5 s or less [11]. Other cases such as the JAMA guidelines, recommend not exceeding a time of 7.5 s [10], and the AAM principles suggest not exceeding 15 s [18]. In case of wanting to follow the NHTSA guidelines, and the 12-s recommendation factor, The following content can be used to maintain a structure in the menus according to the recommendation. Additionally, it should be noted that, although following the recommendations established by this formula, a balance is maintained between the depth and breadth of the menu to not exceed the suggested time limits; having more than nine items in a single sublevel already generates a cognitive demand considerably high to result in distraction [59]. With this mentioned, this number should be kept in mind to not saturate a single depth of the menu with more than nine options.
Use when Use when menu options can be segmented into groups according to their functionality.
Example Figure 7 shows the interaction flow to complete the task of Configuring the system language, starting from the Settings menu, which corresponds to a depth of 1. The Settings menu takes the user to the Screen sublevel by default, which has 7 options ( Figure 7a). Then, the driver must move through 7 tabs until reaching the System menu. Analyzing each sublevel, we find that Security has 1 option (Figure 7b (Figure 7i). Now, as the Settings menu tabs are distributed in a way that the user must pass each one of them to configure a system attribute, such as the language, they have the same impact as if each of them were a sublevel of the previous one, causing users to have a high interaction cost, a net time higher than recommended, and a considerably high subjective mental workload.

Category Content
Sustainability 2022, 14, x FOR PEER REVIEW 12 of 25  Attribute Description

Problem
The system interface requires filters that facilitate the search for results in menus whose number of options cannot be reduced due to their hierarchy. Including an intermediate menu to limit the breadth in menus whose options cannot be segmented

Problem
The system interface requires filters that facilitate the search for results in menus whose number of options cannot be reduced due to their hierarchy.

Solution
Including an intermediate menu to limit the breadth in menus whose options cannot be segmented because they belong to the same hierarchy level (e.g., 150 contacts in a cell phone directory) can reduce the net interaction time and even the driver's mental workload when performing a task. Reducing either of these two factors can help decrease the level of distraction generated by the task. For these cases, the interaction cost can be sacrificed in order to reduce the net interaction time and mental workload of the user [62,63]. In some cases, where a kind of filter is included using a search sidebar as in the contact list of a cell phone directory, it can be assumed that there is already an intermediate menu that will help the driver to reach the desired contact faster; however, in multiple occasions, as this bar is not automatically deployed, the driver does not have it present and omits its functionality, and this leads to the user taking a long period of time navigating through each of the contacts on the list. Additionally, the attributes of this sidebar are not the most suitable for touch interaction mode, so the inclusion of an intermediate menu may improve the performance of the task.

Use when
Use when menu options cannot be segmented into groups according to their functionality. Use when the menu breadth cannot be decreased because the options belong to the same hierarchy level. Use when you need to find a specific item from a large and time-consuming list.
Example Figure 8 shows the interaction flow for calling the contact "User" without using any filtering by letter.
Although the task appears to be performed in a short set of four steps, the time it takes the user to go from the first contact (Figure 8b) to the desired contact (Figure 8c), according to the study performed and the length of the directory (276 contacts), is approximately 87% of the total task time.
Including an additional step where a filtering menu is displayed to select the desired letter would considerably decrease the time it takes the user to find the contact and, therefore, the net interaction time to complete the task. This is shown in the interaction flow of Figure 9.

Category Content
Sustainability 2022, 14, x FOR PEER REVIEW 13 of 25 Use when the menu breadth cannot be decreased because the options belong to the same hierarchy level.
Use when you need to find a specific item from a large and time-consuming list.
Example Figure 8 shows the interaction flow for calling the contact "User" without using any filtering by letter.
Although the task appears to be performed in a short set of four steps, the time it takes the user to go from the first contact (Figure 8b) to the desired contact (Figure 8c), according to the study performed and the length of the directory (276 contacts), is approximately 87% of the total task time.
Including an additional step where a filtering menu is displayed to select the desired letter would considerably decrease the time it takes the user to find the contact and, therefore, the net interaction time to complete the task. This is shown in the interaction flow of Figure 9.

Problem
The driver needs to use mobile applications installed in the system taking into account their interaction limitations compared to when using them on the mobile device outside the vehicle. Use when the menu breadth cannot be decreased because the options belong to the same hierarchy level. Use when you need to find a specific item from a large and time-consuming list.
Example Figure 8 shows the interaction flow for calling the contact "User" without using any filtering by letter. Although the task appears to be performed in a short set of four steps, the time it takes the user to go from the first contact (Figure 8b) to the desired contact (Figure 8c), according to the study performed and the length of the directory (276 contacts), is approximately 87% of the total task time.
Including an additional step where a filtering menu is displayed to select the desired letter would considerably decrease the time it takes the user to find the contact and, therefore, the net interaction time to complete the task. This is shown in the interaction flow of Figure 9. Category Content (a) (b) (c)

Problem
The driver needs to use mobile applications installed in the system taking into account their interaction limitations compared to when using them on the mobile device outside the vehicle. Adapting the structure and limiting the functionalities of mobile applications installed in infotain-

Problem
The driver needs to use mobile applications installed in the system taking into account their interaction limitations compared to when using them on the mobile device outside the vehicle.

Solution
Adapting the structure and limiting the functionalities of mobile applications installed in infotainment systems, also known as third-party apps, can reduce the interaction cost, the net interaction time and even the driver's mental workload when performing a task. Reducing any of these three factors can result in a decrease in the level of distraction generated by the task. Nowadays, mobile applications have hundreds of features that allow users to interact and accomplish countless tasks on a daily basis. However, a driver should not have the same freedom to interact while driving as a different user may have on their desktop. Therefore, the number of activities a driver performs in a third-party app should be very limited to the main functions [64]. An unadapted mobile application in an infotainment system, although it may result in a higher level of driver acceptance by allowing more functionalities, undoubtedly results in a higher indicator of visual distraction [65]. Additionally, for adaptation, it is suggested to follow the recommendations about the structure of the menus in the systems, presented in Pattern 3.

Use when
Use when a mobile application has been included in the vehicle's infotainment system.

Example
The Spotify ® music application is one of the apps included in the Apple CarPlay ® system. One of the tasks in the study was to play a song on Spotify ® , giving drivers the freedom to select any song they wanted. However, and due to the freedom of interaction provided by the internal structure of the app, users tended to spend considerably high time intervals entering multiple levels and sublevels of the interface. Figure 10a-e show some of the different levels of interaction that drivers can explore in Spotify ® , not following the recommendations of depth and breadth of the interface menus. It is worth mentioning that Spotify ® does limit this freedom of interaction in the mobile device application when a connection to a vehicle is detected, and in theory, this limitation should be the same or greater in the infotainment system, because it will be the focus of the driver's attention when trying to play a song while driving.

Category Content
Sustainability 2022, 14, x FOR PEER REVIEW 14 of 25 Nowadays, mobile applications have hundreds of features that allow users to interact and accomplish countless tasks on a daily basis. However, a driver should not have the same freedom to interact while driving as a different user may have on their desktop. Therefore, the number of activities a driver performs in a third-party app should be very limited to the main functions [64]. An unadapted mobile application in an infotainment system, although it may result in a higher level of driver acceptance by allowing more functionalities, undoubtedly results in a higher indicator of visual distraction [65]. Additionally, for adaptation, it is suggested to follow the recommendations about the structure of the menus in the systems, presented in Pattern 3.

Use when
Use when a mobile application has been included in the vehicle's infotainment system.

Example
The Spotify ® music application is one of the apps included in the Apple CarPlay ® system. One of the tasks in the study was to play a song on Spotify ® , giving drivers the freedom to select any song they wanted. However, and due to the freedom of interaction provided by the internal structure of the app, users tended to spend considerably high time intervals entering multiple levels and sublevels of the interface. Figure 10a-e show some of the different levels of interaction that drivers can explore in Spotify ® , not following the recommendations of depth and breadth of the interface menus.
It is worth mentioning that Spotify ® does limit this freedom of interaction in the mobile device application when a connection to a vehicle is detected, and in theory, this limitation should be the same or greater in the infotainment system, because it will be the focus of the driver's attention when trying to play a song while driving. Category Content

Problem
The driver needs to complete a task of minimum mental and physical effort by their preferred interaction mode.
Partially unlocking the touch screen when executing a task with an estimated interaction cost of 1

Problem
The driver needs to complete a task of minimum mental and physical effort by their preferred interaction mode.

Solution
Partially unlocking the touch screen when executing a task with an estimated interaction cost of 1 can reduce the net interaction time and even the driver's mental workload when performing a task. Reducing either of these two factors can result in a reduction in the level of distraction generated by the task. This unlocking can also reduce the number of errors when performing the task [66]. Touchscreen lockout as a distraction mitigation strategy comes at the price of lower user acceptance, and while touch screen locking can improve driving performance in multiple cases, for tasks with minimal interaction cost, such improvement can only be implemented if user acceptance is guaranteed to reduce errors [66]. Additionally, it is worth mentioning that the total lockout of the touch screen in tasks with low interaction cost may lead the user to make mistakes or have to slow down the speed at which they are driving in order to unlock it, increasing the time to complete the task and possibly causing frustration to the user.
Use when Use when the system locks the touch screen interaction mode when exceeding a specific driving speed. Use only when the task has an estimated interaction cost of 1, i.e., a single step, which is interpreted as a task of minimal mental and physical effort.

Example
Although throughout the study it was noticed that in multiple tasks, drivers attempted to select options using the touch screen when driving faster than 10 km/h (speed limit for blocking the touch interaction mode in the vehicle studied), the most noticeable example of frustration presented and described by users was when attempting to answer and hang up a phone call using the touch screen. Drivers, seeing the simple interface to answer a call ( Figure 11) or to hang up (Figure 12), tended to bring their hand to the screen and, as the screen did not respond to this tactile interaction, they looked away from the road for much longer and on multiple occasions, as described by them, increased their situational stress due to putting more effort in finding the correct way to answer or hang up. It is worth mentioning that the tasks of answering a call or ending a call have an estimated interaction cost of 1, so it would not imply that unlocking the screen would lead drivers to risky situations such as having the screen unlocked all the time. Additionally, partial unlocking in these cases could increase user acceptance of the system.

Category Interaction mode
Sustainability 2022, 14, x FOR PEER REVIEW This unlocking can also reduce the number of errors when performing the task [66]. Touchscreen lockout as a distraction mitigation strategy comes at the price of lower user ac ceptance, and while touch screen locking can improve driving performance in multiple case tasks with minimal interaction cost, such improvement can only be implemented if user acceptance is guaranteed to reduce errors [66]. Additionally, it is worth mentioning that the total lockout of the touch screen in tasks with teraction cost may lead the user to make mistakes or have to slow down the speed at which are driving in order to unlock it, increasing the time to complete the task and possibly caus frustration to the user.
Use when Use when the system locks the touch screen interaction mode when exceeding a specific dri speed. Use only when the task has an estimated interaction cost of 1, i.e., a single step, which is int preted as a task of minimal mental and physical effort.

Example
Although throughout the study it was noticed that in multiple tasks, drivers attempted to s options using the touch screen when driving faster than 10 km/h (speed limit for blocking t touch interaction mode in the vehicle studied), the most noticeable example of frustration p sented and described by users was when attempting to answer and hang up a phone call us touch screen. Drivers, seeing the simple interface to answer a call ( Figure 11) or to hang up 12), tended to bring their hand to the screen and, as the screen did not respond to this tactil action, they looked away from the road for much longer and on multiple occasions, as desc by them, increased their situational stress due to putting more effort in finding the correct w answer or hang up. It is worth mentioning that the tasks of answering a call or ending a call have an estimated tion cost of 1, so it would not imply that unlocking the screen would lead drivers to risky si tions such as having the screen unlocked all the time. Additionally, partial unlocking in the could increase user acceptance of the system. Category Interaction mode Figure 11. Interface to answer a call.   Figure 11. Interface to answer a call.

Attribute Description
Sustainability 2022, 14, x FOR PEER REVIEW This unlocking can also reduce the number of errors when performing the task [66]. Touchscreen lockout as a distraction mitigation strategy comes at the price of lower user ac ceptance, and while touch screen locking can improve driving performance in multiple cas tasks with minimal interaction cost, such improvement can only be implemented if user acceptance is guaranteed to reduce errors [66]. Additionally, it is worth mentioning that the total lockout of the touch screen in tasks with teraction cost may lead the user to make mistakes or have to slow down the speed at which are driving in order to unlock it, increasing the time to complete the task and possibly caus frustration to the user.
Use when Use when the system locks the touch screen interaction mode when exceeding a specific dr speed. Use only when the task has an estimated interaction cost of 1, i.e., a single step, which is int preted as a task of minimal mental and physical effort.

Example
Although throughout the study it was noticed that in multiple tasks, drivers attempted to s options using the touch screen when driving faster than 10 km/h (speed limit for blocking t touch interaction mode in the vehicle studied), the most noticeable example of frustration p sented and described by users was when attempting to answer and hang up a phone call u touch screen. Drivers, seeing the simple interface to answer a call ( Figure 11) or to hang up 12), tended to bring their hand to the screen and, as the screen did not respond to this tactil action, they looked away from the road for much longer and on multiple occasions, as desc by them, increased their situational stress due to putting more effort in finding the correct w answer or hang up. It is worth mentioning that the tasks of answering a call or ending a call have an estimated tion cost of 1, so it would not imply that unlocking the screen would lead drivers to risky si tions such as having the screen unlocked all the time. Additionally, partial unlocking in the could increase user acceptance of the system. Category Interaction mode Figure 11. Interface to answer a call.

Problem
The driver needs to perform a task that would take an extremely high interaction cost to execute via the touch screen or the center panel controls.

Solution
Although executing tasks via voice commands could increase the driver's cognitive load in some cases [67,68], enabling this mode of interaction for tasks that are not feasible to do using the touch screen or the center panel controls may reduce the interaction cost, the net interaction time, and even the driver's mental workload when performing a task. Reducing any of these three factors can result in a decrease in the level of distraction generated by the task. However, in order to avoid an increase in the driver's mental demand, the following should be taken into account: The instructions given to the user through audio in tasks that require voice commands must have sufficiently understandable terms in the user's geographical context. Additionally, the instructions must be specific and concrete, but explanatory enough to prevent user errors [69].
The system must guarantee feedback for each of the interactions resulting from a voice command given by the user [69]. This feedback must be provided in two modalities; one, audibly; and two, visually on the interface [70]. Additionally, also in search of error prevention, the system must indicate the moment in which the user must respond to an instruction through voice commands, thus preventing users from expressing themselves before the appropriate time and ending up in an error, and therefore in a distracting factor when performing the task [68][69][70].
Error prevention seeks to give a proactive response, however, in the event of a problem when expressing a voice command, the system must tolerate the error in a reactive manner, giving feedback of what was presented. This feedback should be presented in the most explanatory and at the same time most pleasant way to avoid increased situational stress while driving.
The system must provide flexibility so that the user can use different terms when performing the same task (e.g., if the system asks the user "Do you want to send the text message?", the user should be able to confirm the sending of the message by expressing different words such as "Yes", "I confirm", "Send", "Send it", etc., and not only rely on a single possible answer) [69]. Although modern systems increasingly have a greater amount of data to process, and physical and software resources may be limited in some cases, it is necessary to try to ensure that the feedback has a response time of less than 250 ms [22], to reduce competition from the user's cognitive resources and decrease overall distraction. The system's voice assistant must maintain consistent response times because feedback message delivery times that vary in duration can cause driver distraction and increase the time they take their eyes off the road [71]. Adapting the tasks that require voice commands according to the aforementioned specifications can translate into a decrease in the number of errors and an improvement in the mental workload required by the driver to complete a task. Improving either of these two factors may result in a decrease in the level of distraction generated by the task.
Use when Use only when the task is not feasible to execute using the touch screen or the center panel controls.

Example
During the execution of the task of sending a text message, it was noticeable that multiple users made the mistake of answering to the instructions dictated by the system earlier than they should have, which caused confusion during the task, and in a couple of cases, led them to significantly increase the net interaction time and mental workload demand levels. In Apple CarPlay ® , the system plays a tone right after it gives an instruction to the user (e.g., "To whom do you want to send the text message?"), so that the driver knows when to respond; however, the time lapse between the last word of the instruction until the tone is played is relatively long, so 6 of the 10 drivers in the study had a problem, as they responded to the voice command at the same time the tone was played, or even moments before, and therefore had to repeat their message again.

Category
Interaction mode Table 10. Pattern 8: Icons and text labels.

Problem
The options in the system interface must be represented in condensed spaces and be easily understood.

Solution
Including an icon as a strategy for segmenting interface options can result in space savings on the interface and ease of system navigation for drivers.
Icons are a visual representation of an object, an action, or an idea [68]. If said object, action or idea is not immediately clear to drivers, the icon is reduced to mere visual appeal and noise that prevents users from completing a task efficiently, and therefore, the following recommendations should be considered [41,44,72,73]: The icon must allude to the option it is representing. The icon should be kept small enough to maintain its purpose of representing options in condensed spaces, but it should also be large enough to be accessible to the driver. Try to make the chosen icon universal, and in a worst-case scenario, at least understandable in the geographical context of the user. The icon should be recognizable at a glance. This is to avoid cognitive distractions by having to process information for a long time trying to understand what the icon alludes to. The icon should be visually pleasing and should help to enhance the aesthetic appeal of the interface design. The icon should keep the design simple and schematic, following the indication that intricate details are difficult to distinguish in condensed spaces.
In case of having to repeat the icon in multiple system interfaces, the icon must be consistent and represent the same thing wherever it is located. Additionally, and according to the Nielsen Norman Group [48], it is important to consider that if it takes more than 5 s to think of an appropriate icon for any option, it is unlikely that an icon can effectively communicate the expected meaning. Now to help overcome the ambiguity that many icons face, a text label should be present alongside the icon to clarify its meaning in that particular context. It is recommended that icon labels are always visible, without the need for user interaction. If the driver must scroll or make any movement to see the text label of an icon, the cost of interaction to complete the task clearly increases. Moreover, the need for interaction to display the label on icons does not translate well on touch devices. If a text label is included, it must be related to the functionality of the icon, it must be intuitive for the driver, and it must have a vocabulary that is understandable in the geographical context of the user. Preferably, it should contain words of universal understanding. Including icons following the aforementioned specifications can translate into a decrease in the net interaction time and an improvement in the mental workload that takes a driver to select an option. Improving either of these two factors may result in a decrease in the level of distraction generated by the task. Additionally, these recommendations can reduce the occurrence of errors when performing a task.
Use When Use when the functionality of a menu option can be condensed into a visual representation.

Example
In the conducted study, it was possible to notice some graphic representations that were not intuitive enough for drivers, and that led them to make mistakes and waste time when they entered these spaces incorrectly. Additionally, some text labels did not help users understand the meaning of these icons and the options that they would find if they were selected. An example of this situation was found in the Entertainment interface. Figure 13 shows a section of this interface called Root Menu, whose icon and text label confused multiple users about its meaning. The Root Menu presents the options for viewing the mobile devices connected to Bluetooth audio; however, several drivers pressed this icon both in the task of tuning a radio station and in the task of configuring the vehicle's sound information, expecting to find there the necessary options to complete these tasks.

Category Style
Sustainability 2022, 14, x FOR PEER REVIEW 18 of 25 Figure 13. Root menu in Entertainment interface. Attribute Description

Problem
The system must provide feedback to the driver of the information it receives, minimizing the in- Figure 13. Root menu in Entertainment interface. Table 11. Pattern 9: Prioritization of notifications.

Problem
The system must provide feedback to the driver of the information it receives, minimizing the interference that may cause to the driver.

Solution
Categorizing received information according to a priority system can reduce unnecessary visual and auditory distraction for the driver. Not all the information received by the system has the same relevance for the driver when driving [74,75]. Therefore, establishing a set of conditions according to the priority of the information for the user, can result in a reduction of interference and, thus, of the level of distraction generated by the notification. The following content summarizes some aspects to be taken into account according to the type of priority of the information to be shared with the user. This table is based on the recommendations and empirical studies of [22,75], and contains the priority of the information, the types of notifications, details that are recommended to be used when presenting the notification in the interface, the auditory icons or sounds that can be used to notify the user, and a couple of examples for better understanding.
Warning Recommendations for situations of varying urgency.
Sound of pouring water, air being released, a waterfall, or no sound at all.
Notification of an application (e.g., arrival of a text message), general non-urgent vehicle information (e.g., mid-tank fuel levels, low nib water levels).
Sound of an engine noise or a sound that is inharmonic, discordant or out of tune.
General vehicle information with increased urgency (e.g., fuel levels near zero, low oil levels), door open, speed limit exceeded, parking brake on.
Sound of a car horn, a short-lived siren.
Too close to another vehicle, possibility of collision, engine overheating, obstruction of an internal circuit.
Use When Use only when the information received from the system must be notified to the driver.

Example
For low priority notifications, such as receiving a simple text message, a sound alert can be omitted to avoid diverting the user's attention from the main driving activity. During the study, one of the tasks required the driver to listen to a text message that they would receive while driving. In this case, the Apple CarPlay ® system, by default, is programmed to mute notifications coming from the Messages application, which is why, when the drivers received the text message on the screen, none of them turned their attention away from the road, and the experimenter guiding them had to warn them that the message had already been received. The notification shown on the screen when a text message arrives lasts only 10 s and does not have any sound alert, making it difficult for the drivers to perceive it while driving, and therefore, preventing distraction by this type of notification.

Pattern Validation
In search of validating the user interface design patterns described in the previous section, it is proposed to evaluate them through two procedures: (1) content validity by panel of experts and (2) proof of concept via construction of an artifact. Both procedures are part of the conceptual model validation strategy described by Mora in [76,77], and they seek to obtain a validation through a conceptual evaluation by experts on the subject and another a more empirical validation in which the concepts of the patterns are instantiated in a prototype which a set of users can make use of.

Content Validation by Panel of Experts
Because user interface design patterns serve designers as a reference to provide design solutions to recurring problems arising from user interaction with a system, the proposal of the developed patterns was presented to 10 professionals with experience in design and evaluation of user interfaces, UX design, interaction design, and in general, with extensive experience working in the area of human-computer interaction. Figure 14 depicts some information about experts, where the major part is from Colombia (4); México (3); and the others are from Argentina (1), Costa Rica (1) and Ecuador (1).

Pattern Validation
In search of validating the user interface design patterns described in the previous section, it is proposed to evaluate them through two procedures: (1) content validity by panel of experts and (2) proof of concept via construction of an artifact. Both procedures are part of the conceptual model validation strategy described by Mora in [76,77], and they seek to obtain a validation through a conceptual evaluation by experts on the subject and another a more empirical validation in which the concepts of the patterns are instantiated in a prototype which a set of users can make use of.

Content Validation by Panel of Experts
Because user interface design patterns serve designers as a reference to provide design solutions to recurring problems arising from user interaction with a system, the proposal of the developed patterns was presented to 10 professionals with experience in design and evaluation of user interfaces, UX design, interaction design, and in general, with extensive experience working in the area of human-computer interaction. Figure 14 depicts some information about experts, where the major part is from Colombia (4); México (3); and the others are from Argentina (1), Costa Rica (1) and Ecuador (1). All evaluators are UX experts; with more than 10 years in experience in topics related with Usability; Accesibility; User Centred Design; Heuristics; Interactive Systems development; among others ( Figure 15 shows some information about experience in years). All evaluators are UX experts; with more than 10 years in experience in topics related with Usability; Accesibility; User Centred Design; Heuristics; Interactive Systems development; among others ( Figure 15 shows some information about experience in years). The content validity evaluation was carried out following the proposal defined by Mora [77], which has 7 questions rated on a Likert scale from 1 to 5 (1: totally disagree, 5: totally agree), referring to the theoretical principles supporting the proposal and its relevance to the topic, the relevance of the literature reviewed for its development, the coher- The content validity evaluation was carried out following the proposal defined by Mora [77], which has 7 questions rated on a Likert scale from 1 to 5 (1: totally disagree, 5: totally agree), referring to the theoretical principles supporting the proposal and its relevance to the topic, the relevance of the literature reviewed for its development, the coherence of the proposal, whether it fulfills the purpose for which it was designed and the contributions to the topic offered by the proposal. Additionally, we decided to ask six more questions, five of them evaluated with the same scale, dedicated to the validation of each of the attributes of the patterns (Problem, Solution, Use when, Example and Category) and an open question at the end (optional), where the experts could leave their opinion about how the set of patterns could be strengthened. In total there were 13 questions: P1. The Pattern Proposal is supported by recognized theoretical aspects. P2. The theoretical principles used to support the patterns proposal are relevant. P3. There is no omission of important aspects in the theoretical principles. P4. The pattern proposal is coherent. P5. The pattern proposal is complete. P6. The pattern proposal gives innovative aspects in the design guidelines of interactive systems.
P7. The style of presentation of the pattern proposal is adequate. P8. The described and suggested problems in the pattern proposal are clear. P9. The solutions give correct answer to the problems in an adequate manner. P10. Section "Use when" specifies in a clear manner the different scenarios where pattern could be implemented.
P11. Examples proposed allow us to clarify the use and justification of the suggested design pattern.
P12. The content of the design patterns is coherent. P13. From your research experience, could the suggested patterns proposal be improved? From the evaluation results, it was observed that the vast majority of the marks were high for each question, and in general, positive feedback was obtained about the proposal. This allowed us to subjectively determine that the model satisfactorily meets three main criteria: (i) the model is supported by robust theories and principles; (ii) the model is logically coherent, congruent with the reality of study and adequate to the purpose for which it was designed; and (iii) the model contributes something new and is not just a duplication of an existing model.

Proof of Concept via an Artifact Construction
As previously mentioned, after validating the content of the set of patterns by the panel of experts, a prototype was built taking into account the design guidelines established in the patterns. This prototype seeks to compile some of the solutions proposed to validate that the level of distraction of users may decrease if certain elements described in the patterns are taken into account. It should be noted that the level of distraction was measured according to the three evaluation metrics described previously: (i) net time of interaction, (ii) interaction cost and (iii) mental workload.
For this procedure, we selected the tasks in which the users had recurrent pain points and from where the vast majority of the design patterns arose, and a redesign proposal was made based on the guidelines established in the patterns so that we could validate whether effectively performing tasks with these settings would decrease the level of distraction for drivers. A total of 7 tasks were selected, of which 3 were carried out in the IVIS directly to reconfirm the theory described in the patterns, and the other 4 were redesigned in a prototype developed in Adobe XD [78], which was deployed on a tablet to simulate the touch screen of the original IVIS. For this validation stage, the test was carried out with 5 users (3 females, 2 male) who had the same characterization of the users of the first test (i.e., 18-29 age range, minimum 2 years of driving experience and valid driving license). The equipment, the route taken and the conditioning of the test were intended to be the same as the ones of the first test to avoid data contamination. Likewise, the same methods were used for the gathering of information (i.e., observational method, retrospective technique, DALI, etc.).
After performing the validation test, an exercise was done very similar to the one performed for the first test, including statistical analysis, identification of pain points, etc. and the evaluation metrics of the original version of the system were compared with the metrics obtained with the prototype. Satisfactorily, the different solutions described in the patterns were validated, reducing the time to complete the tasks, the interaction cost and, very importantly, the mental workload perceived by the drivers. After having validated the patterns by proof of concept via construction of an artifact, and having obtained feedback from the users of the validation phase, it was proposed to carry out a focus group with the intention of receiving more feedback regarding the solutions described in the patterns. In order to do this, virtual meetings were scheduled with users of the first test, in two groups of five participants per session, to share the adjustments made to the user interface through the prototype and, in general, make them aware of the solutions proposed in the list of design patterns, which, in one way or another, were built in search of solving the pain points identified in their exploration tests. After carrying out the sessions, at a general level, it was possible to obtain positive feedback regarding how useful the solutions proposed in the patterns can be in search of reducing the level of distraction in a real scenario.

Conclusions and Further Work
In this paper, we have presented a collection of nine user interface design patterns for infotainment systems in vehicles, based on the distraction of the driver when performing secondary tasks while driving. These patterns present design solutions regarding the driver's needs and requirements in the user interface, addressing identified problems that relate to the content, interaction mode, style, shortcuts and notifications of the system. The main objective of the patterns is to help reduce the net time of interaction, interaction cost and mental workload perceived by drivers when performing secondary tasks in the infotainment systems, and thus be able to contribute to the reduction in driver distraction. This collection of patterns was built mainly from the execution of an exploration test which served to identify pain points, characterize drivers in the Colombian context, and find similar behaviors among users, in order to focus on recurrent problems within the region. The structure of the patterns, which is described in the previous sections as well, consists of an identified problem, a solution to the problem, a 'use when' section to understand the context under which the pattern would be useful, and an example to clarify the use and the reason of the pattern.
The set of design patterns was validated by a panel of experts, consisting of 10 Latin American researchers in the area of human-computer interaction, with extensive experience in user interface design and evaluation, UX design and interaction design. The experts helped determine that the developed design patterns satisfactorily meet three main criteria: (i) they are supported by robust theories and principles; (ii) they are logically coherent, congruent with the reality of study and adequate to the purpose for which they were designed; and (iii) they contribute something new and are not just a duplication of an existing model. Additionally, a second and more empirical validation was carried out, in which a prototype was built based on the solutions described in the patterns so that another set of users could interact with this redesign proposal and thus be able to compare the performance of this group of users with those who presented pain points in the first test prior to the construction of the patterns. Effectively, it was also possible to validate the patterns during this second procedure.
Having this set of design patterns already proposed, as further work, it is planned to continue expanding and consolidating more solutions to multiple problems that may arise when conducting more tests with users, as well as expanding the scope to not only consider metrics that affect distraction, but also other factors that affect the overall driver experience such as accessibility, fatigue, feelings, and cooperation with other passengers, among many more. Moreover, it is expected to continue expanding the geographical scope of the study to begin to contemplate the mental model of users from other Latin American countries and, thus, to be able to contribute to the problems of the region. As further work, it is planned to consider not only age and cultural aspects, but also physical limitations that prevent us from executing some activities in a good manner. In that way, it is expected to understand more aspects of the users, maybe with the inclusion of techniques such as PERSONA or EMPHATHY MAPS, in order to obtain not only quantitative information but also qualitative (wishes, pleasures, expectations, etc.). Finally, it is expected to consider the use of different interaction devices as a control of infotainment systems such as mobile phones.