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

Abstract

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 notifications of the system, which are built based on both theoretical support and an empirical pattern finding 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 finding process.

1. 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 which these elements are distributed, can cause the user–vehicle interaction to increase the complexity of the experience, and therefore, it could make it difficult to carry out secondary tasks and, in a worse scenario, affect safety while driving [6]. In fact, according to [7], it has been proven that the improper use of advanced infotainment systems such as Android Auto^TM or Apple CarPlay^® while driving can be more dangerous than driving under the influence of alcohol or cannabis, which supports the hypothesis of the researchers of the referenced work, who argue that current approaches that guide the design of infotainment systems are not sufficient to achieve the levels necessary for safe driving. Performing a secondary task demands a high level of cognitive attention; likewise, it is possible that it requires high levels of visual or physical attention, which can lead the drivers to divert their eyes from the road, their hands from the wheel and, in general, leads them to remain in a state of constant distraction [8]. These are some of the reasons why it is important to prioritize the safety of the driver and passengers when designing the infotainment system, because, although greater permissiveness is being provided and a better user experience may be being sold, the results of driver–vehicle interaction can lead to unwanted events.

Some European [9], Japanese [10] and American [11] organizations, involved in the automotive industry, have proposed some guidelines for the design, placement, and distribution of infotainment system components inside the vehicle, ensuring that the general design of the system is more focused on the welfare of the driver and passengers, as well as in search of a better relationship between interface and user [12,13]. While this is a positive step, these design guidelines are not required for vehicle development, and compliance with their recommendations is voluntary. In addition to this, and although some of the guidelines try to give a global vision of the factors to take into account for the implementation of infotainment systems in the vehicle, they are designed under the context of each of the regions in which the proposal was made, omitting difficulties and behaviors of users belonging to different socioeconomic groups, different levels of education and without a doubt, with another mental model, as drivers from Latin American countries may have. Users’ preferences in interface design are very important and are given great attention by technology designers and application developers. One of the main features of the design approach is the cultural feature.

In general, and in accordance with the contextualization presented, the design of the infotainment systems interfaces is not totally focused on the behavior of drivers when executing tasks that can generate distraction, which leads to constant competition from the driver’s cognitive resources and subjects them, together with passengers, drivers of other vehicles and pedestrians, to unwanted situations on the road [3]. Additionally, the scarce documentation and regulation regarding the distraction generated by infotainment systems inside the vehicle in Latin American countries leads the interface–driver relationship in the regional context to become a topic of research interest and great responsibility. In this manner, the following study presents the proposal for a set of user interface design patterns, obtained from an empirical test and theoretical supports, which were proposed with the aim of compiling recurring interaction problems along with some design proposals to contribute to the solution of these issues that may arise from the use of infotainment systems in the Latin American region.

2. Related Work

During the last decades, international government entities and automotive original equipment manufacturers have published different guidelines and design principles that seek to facilitate interaction with vehicle infotainment systems and specify certain characteristics of automotive human–machine interfaces to ensure both good user experience and adequate road safety. The most recognized publications have been developed by the European Commission (EC) [14], the Japan Automobile Manufacturers Association (JAMA) [15], the Alliance of Automobile Manufacturers (AAM) [16] and the National Highway Traffic Safety Administration (NHTSA) [17].

The EC has issued a series of design recommendations condensed in the document of the European Statement of Principles on HMI, commonly referred to as ESoP [9]. The ESoP, last updated in 2013, includes safety aspects that must be considered for the design of human–machine interfaces (HMI) of in-vehicle infotainment systems, and is made up of three general design principles on the human–machine interaction and 32 principles that cover the areas of system installation, information presentation, interaction with screens and controls, system behavior and information about the system.

The Design Guidelines for Display Systems in Vehicles [10], in its third version published by JAMA in 2004, brings together 4 basic principles and 25 specific requirements for the design of the interfaces of display systems in vehicles to guarantee the user the safe use of the different functionalities while driving. The main areas in which the requirements are grouped include the installation of the system, the functions of the system, the operation of the system while the vehicle is in motion, and the presentation of information to users.

The Statement of Principles, Criteria and Verification Procedures on Driver Interactions with Advanced In-Vehicle Information and Communication Systems [18], developed by the American AAM (2006), sets out 24 design principles grouped into 5 sections: principles of installation, principles of presentation of the information, principles on interactions with screens/controls, principles of the behavior of the system and principles of information about the system.

Among the many NHTSA publications related to the design of infotainment system interfaces, the Guidelines to Reduce Visual–Manual Driver Distraction During Interactions with Electronic Devices Integrated in the Vehicle (2013) stand out for this work [19], corresponding to Phase I of the guidelines related to driver distraction. This first phase applies to the electronic devices of the vehicle used by the driver to perform secondary tasks (communications, entertainment, navigation, etc.) through visual and/or manual means. The document lists certain ancillary tasks that the agency identifies as inherently interfering with the driver’s ability to safely control the vehicle and specifies a test method to measure “eye glance behavior” during the performance of these tasks. Phase II of the guidelines (2016) [20] addresses the visual–manual distraction produced by interaction with portable and aftermarket devices, and Phase III (still under construction) will address the driver distraction produced by auditory-based interfaces in voice interaction [21].

On the other hand, in the literature search of existing design patterns, a set of design patterns applied to the automotive domain and with a focus on the user experience within the vehicle was found. This proposal is described in [22], where a group of researchers from the human–computer interaction (HCI) area work together with engineers and designers from the automotive industry to present a set of eight UX design patterns in the vehicle that offer solutions to recurring problems in the design of human–vehicle interactions. The problems faced in these patterns include the depth of the menu and number of options in the interfaces of the systems, the size of the touch field of the screen, the design of warnings and auditory information, the choice of the best modality for the visualization of warnings, the response time of the system when interacting by touch mode, the size of the icons presented on the screen, the choice of suitable colors for on-screen display, and the preference for using touch screens or physical buttons.

The current literature review shows the existence of various principles, guidelines and recommendations for the design of user interfaces of infotainment systems in vehicles; however, no publications of this type were found in the Latin American context. There are some publications where cultural aspects have been considered in the design of website applications [23]. The regional mental model is paramount in human–computer interaction area, especially in user-centered design, which focuses on having an explicit understanding of the user’s needs, the tasks to be performed, and the characteristics of the 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].

3. 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).

3.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.

3.2. 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.

3.3. 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.

3.4. 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:

• Connect mobile phone via Bluetooth.
• Make a phone call from the main screen.
• Answer a phone call from the main screen.
• Play a mobile phone song via Bluetooth from the main screen.
• Tune in to a specific FM radio station from the main screen.
• Search vehicle sound information from the main screen.
• Set the system language from the main screen.

On Apple CarPlay^®:

• Make a phone call from the main screen.
• Answer a phone call from the main screen.
• Compose a text message from the main screen.
• Receive a text message from the main screen.
• Play a song from the mobile phone through an Internet application from the main screen (Spotify^®).
• Set a navigation route from the main screen (Waze^TM).

3.5. 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.

3.6. 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:

• 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.
• 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.
• 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.

4. Pattern Collection

4.1. 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. Design pattern structures comparison chart.

	Van Welie	Toxboe	Center for HCI (University of Salzburg)	Tidwell	HCI and Usability Unit (University of Salzburg)
Name	x	x	x	x	x
Problem/What	x	x	x	x	x
Solution/How	x	x	x	x	x
Use When/Usage/Scenario	x	x	x	x
Example	x	x	x	x	x
Why/Rationale	x	x		x
Topics			x
Intent			x
Context parameters					x
Forces					x
More Examples	x	x

.

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. Defined structure for the user interface design patterns.

Attribute	Description
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.

4.2. 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. Table 3, Table 4, Table 5, Table 6, Table 7, Table 8, Table 9, Table 10 and Table 11 summarize the proposal of the nine user interface design patterns.

Table 3. Physical buttons as shortcuts in the system.

Attribute	Description
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.
Category	Shortcuts

Table 3. Physical buttons as shortcuts in the system.

Attribute	Description
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.
Category	Shortcuts

Figure 3. Interaction flow to play a song without using a physical shortcut. (a) Select a song. (b) Select the frequency. (c) Select connection mode. (d) Choose the song.

Figure 3. Interaction flow to play a song without using a physical shortcut. (a) Select a song. (b) Select the frequency. (c) Select connection mode. (d) Choose the song.

Figure 4. Interaction flow to play a song using a physical shortcut. (a) Select the shortcut. (b) Select the song.

Figure 4. Interaction flow to play a song using a physical shortcut. (a) Select the shortcut. (b) Select the song.

Table 4. Pattern 2: Personalized quick access bar.

Attribute	Description
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.
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

Table 4. Pattern 2: Personalized quick access bar.

Attribute	Description
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.
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

Figure 5. Interaction flow to access Spotify^® without using the quick access bar. (a) Select the menu. (b) Select the button. (c) Main menu. (d) Select the application. (e) Execute the action.

Figure 5. Interaction flow to access Spotify^® without using the quick access bar. (a) Select the menu. (b) Select the button. (c) Main menu. (d) Select the application. (e) Execute the action.

Figure 6. Interaction flow to access Spotify^® using the quick access bar. (a) Select the menu. (b) Execute the action.

Figure 6. Interaction flow to access Spotify^® using the quick access bar. (a) Select the menu. (b) Execute the action.

Table 5. Pattern 3: Depth and breadth of menus.

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.
	Menu depth and breadth following NHTSA 12-s recommendation [11]
	Menu Depth	Menu Breadth
	3	12
	4	5
	5	3
	6	2
	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), Sound has 7 options (Figure 7c), Clock has 5 options (Figure 7d), Vehicle has 4 options (Figure 7e), Devices has 4 options (Figure 7f), and finally, System has 7 options (Figure 7g). Here, the user must enter Language (Figure 7h) and choose the desired option (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

Table 5. Pattern 3: Depth and breadth of menus.

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.
	Menu depth and breadth following NHTSA 12-s recommendation [11]
	Menu Depth	Menu Breadth
	3	12
	4	5
	5	3
	6	2
	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), Sound has 7 options (Figure 7c), Clock has 5 options (Figure 7d), Vehicle has 4 options (Figure 7e), Devices has 4 options (Figure 7f), and finally, System has 7 options (Figure 7g). Here, the user must enter Language (Figure 7h) and choose the desired option (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

Figure 7. Interaction flow to configure the system language. (a) Setting. (b) Security. (c) Sound. (d) Clock. (e) Vehicle options. (f) Device options. (g) System options. (h) Languages. (i) Final selection.

Figure 7. Interaction flow to configure the system language. (a) Setting. (b) Security. (c) Sound. (d) Clock. (e) Vehicle options. (f) Device options. (g) System options. (h) Languages. (i) Final selection.

Table 6. Pattern 4: Quick search filters.

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.
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]. The intermediate menu should function as a breadth reducer, and therefore should have as few options as possible, as long as it complies with the total segmentation of all the options of the main menu.The intermediate menu should not have a number of options greater than or equal to the number of options that it is trying to reduce. 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

Table 6. Pattern 4: Quick search filters.

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.
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]. The intermediate menu should function as a breadth reducer, and therefore should have as few options as possible, as long as it complies with the total segmentation of all the options of the main menu.The intermediate menu should not have a number of options greater than or equal to the number of options that it is trying to reduce. 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

Figure 8. Interaction flow to call the contact “User”. (a) Initial activity. (b) Look the contact. (c) Choose the contact.

Figure 8. Interaction flow to call the contact “User”. (a) Initial activity. (b) Look the contact. (c) Choose the contact.

Figure 9. Interaction flow to call the contact “User” using the intermediate letter menu. (a) Initial activity. (b) Look the contact. (c) Select the initial letter of the contact. (d) Choose the contact.

Figure 9. Interaction flow to call the contact “User” using the intermediate letter menu. (a) Initial activity. (b) Look the contact. (c) Select the initial letter of the contact. (d) Choose the contact.

Table 7. Pattern 5: Internal structure of third-party applications.

Attribute	Description
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

Table 7. Pattern 5: Internal structure of third-party applications.

Attribute	Description
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

Figure 10. Spotify^® interface on Apple CarPlay^® infotainment system. (a) Spotify menu in Apple car. (b) Main interface in Spotify. (c) Recent songs played. (d) Search interface. (e) Playlist Interface.

Figure 10. Spotify^® interface on Apple CarPlay^® infotainment system. (a) Spotify menu in Apple car. (b) Main interface in Spotify. (c) Recent songs played. (d) Search interface. (e) Playlist Interface.

Table 8. Pattern 6: Partial lock of touch interaction mode.

Attribute	Description
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

Table 8. Pattern 6: Partial lock of touch interaction mode.

Attribute	Description
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

Figure 11. Interface to answer a call.

Figure 11. Interface to answer a call.

Figure 12. Interface to hang up a call.

Figure 12. Interface to hang up a call.

Table 9. Pattern 7: Voice command interaction.

Attribute	Description
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 9. Pattern 7: Voice command interaction.

Attribute	Description
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.

Attribute	Description
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

Table 10. Pattern 8: Icons and text labels.

Attribute	Description
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

Figure 13. Root menu in Entertainment interface.

Figure 13. Root menu in Entertainment interface.

Table 11. Pattern 9: Prioritization of notifications.

Attribute	Description
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.
	Priority	Notification Type	Interface Details	Auditory Icons	Examples
	Low	Informational	Terms that do not indicate urgency (e.g., “Notice”, “Information”, “Notification”, “Suggestion”).	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).
	Moderate	Warning	Terms indicating medium urgency (e.g., “Warning”, “Caution”).	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.
	High	Critical	Terms indicating high urgency (e.g., “Danger”, “Risk”).	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.
Category	Notifications

Table 11. Pattern 9: Prioritization of notifications.

Attribute	Description
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.
	Priority	Notification Type	Interface Details	Auditory Icons	Examples
	Low	Informational	Terms that do not indicate urgency (e.g., “Notice”, “Information”, “Notification”, “Suggestion”).	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).
	Moderate	Warning	Terms indicating medium urgency (e.g., “Warning”, “Caution”).	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.
	High	Critical	Terms indicating high urgency (e.g., “Danger”, “Risk”).	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.
Category	Notifications

5. 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.

5.1. 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).

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.

5.2. 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.

6. 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.