Interaction With In-Vehicle Infotainment Systems Development of Interaction Tools For In-Vehicle Infotainment Systems During Low-Levels of Automation In Rural Environ- ments Master’s thesis in Interaction Design and Technologies JONAS ARVIDSSON JONATHAN GRANSTRÖM Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY UNIVERSITY OF GOTHENBURG Gothenburg, Sweden 2018 Master’s thesis 2018 Interaction With In-Vehicle Infotainment Systems Development of Interaction Tools For In-Vehicle Infotainment Systems During Low-Levels of Automation In Rural Environments JONAS ARVIDSSON JONATHAN GRANSTRÖM Department of Computer Science and Engineering Division of Interaction Design Chalmers University of Technology University of Gothenburg Gothenburg, Sweden 2018 Interaction With In-Vehicle Infotainment Systems Development of Interaction Tools For In-Vehicle Infotainment Systems During Low- Levels of Automation In Rural Environments JONAS ARVIDSSON JONATHAN GRANSTRÖM © JONAS ARVIDSSON, 2018. © JONATHAN GRANSTRÖM, 2018. Supervisor: MORTEN FJELD Examiner: STAFFAN BJÖRK Master’s Thesis 2018 Department of Computer Science and Engineering Division of Interaction Design Chalmers University of Technology and University of Gothenburg SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: A driving simulator with a tablet representing a head-up display mounted in front of it. Typeset in LATEX Gothenburg, Sweden 2018 iii Interaction With In-Vehicle Infotainment Systems Development of Interaction Tools For In-Vehicle Infotainment Systems During Low- Levels of Automation In Rural Environments JONAS ARVIDSSON JONATHAN GRANSTRÖM Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg Abstract Increasingly more car manufacturers are implementing advanced driver-assistance systems in vehicles. Furthermore, the rise of smart devices has created an environ- ment where people expect more of their devices to be connected to the internet. As a result, the infotainment systems in vehicles are becoming more connected and provide more functionality, e.g., direct messaging. This thesis presents a concept which allows a driver to interact with the communicative tasks of an infotainment system in both non- and partially automated vehicles, driven in rural environments. The concept consists of a trackpad placed to the side of the driver, in an arm rest position, which acts as the input device. A head-up display placed in the front win- dow of the vehicle is used as the output. We believe the concept shows promise, but requires more development in certain areas, such as text-input, and more thorough evaluation in real life environments, in order to properly confirm if the concept is safe enough to use in a vehicle when driving. Keywords: automotive, interaction design, human-machine interface, autonomous, infotainment, user interface iv Acknowledgements We would like to thank Semcon for providing us with the project our master thesis is based on. A big thanks to both of our supervisors at Semcon, Jan Nilsson and Joel Hammar, who provided us with vital feedback and guidance. We would also like to thank Claudia Wege and Justyna Maculewicz for their feedback. We would also like to thank our supervisor at Chalmers, Morten Fjeld. His guid- ance and suggestions of literature, methods, and measures helped shape our project process. Finally, we would like to extend much gratitude to all those who participated in our user tests. Their time, effort, feedback, and input was essential for our project. Jonas Arvidsson & Jonathan Granström, Gothenburg, June 2018 vi Contents List of abbrevations xi 1 Introduction 1 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6 Ethical Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Theory 5 2.1 Driving Automation Taxonomy . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Dynamic Driving Task or Primary Task . . . . . . . . . . . . 6 2.2 Advanced Driver-Assistance Systems . . . . . . . . . . . . . . . . . . 6 2.3 In-Vehicle Infotainment System . . . . . . . . . . . . . . . . . . . . . 7 2.4 Driver distraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4.1 Secondary tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.2 Situational Awareness . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Driver Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.1 Mental Workload . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.6 Research Through Design . . . . . . . . . . . . . . . . . . . . . . . . 10 2.7 Guidelines for Safe In-Vehicle Systems . . . . . . . . . . . . . . . . . 10 3 Methodology 12 3.1 Interaction Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1 User-Centered Design . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 Methods and Measures . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1 Data Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.2 Task Description . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.3 Task Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.4 Ideation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.5 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.6 User Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.7 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4 Process 26 viii 4.1 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.1.1 Literature study . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.2 Research of Similar Products . . . . . . . . . . . . . . . . . . 27 4.1.3 Driving Habit Survey . . . . . . . . . . . . . . . . . . . . . . . 28 4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3 First Design Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3.1 Conceptualization . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3.2 Initial Ideas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.3 Rapid Prototyping . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3.4 Trackpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.5 Head-up Display . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3.6 The Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4 Second Design Iteration . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.4.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.4.2 Information Architecture . . . . . . . . . . . . . . . . . . . . . 42 4.4.3 Text Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.4.4 Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.4.5 Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.4.6 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.4.7 Android Prototype . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4.8 User Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.5 Third Design Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.5.1 Re-designing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.5.2 Final User Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5 Result 54 5.1 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.1.1 Follow-up Questions and Personas . . . . . . . . . . . . . . . . 62 5.2 Field Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3 Conceptualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.4 User Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.1 Test Number 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.2 Test Number 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.4.3 Test Number 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6 Discussion 83 6.1 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.1.1 Understanding the domain and its users . . . . . . . . . . . . 83 6.1.2 The prototypes and technical difficulties . . . . . . . . . . . . 85 6.1.3 Extensive amount of evaluation measures . . . . . . . . . . . . 86 6.1.4 Using a controlled environment for testing . . . . . . . . . . . 86 6.2 Result discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.2.1 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.2.2 Field Research . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.2.3 Conceptualization . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.2.4 User Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.3 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 ix 6.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7 Conclusion 94 Bibliography 95 A Appendix 1 I A.1 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I A.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII A.2.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . VII A.2.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . X A.2.3 User requirements . . . . . . . . . . . . . . . . . . . . . . . . . XII A.3 Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV A.3.1 Low-fidelity Wireframes . . . . . . . . . . . . . . . . . . . . . XIV A.3.2 Final Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVI A.4 Field Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXV A.5 User Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXXI x Abbrevations ADAS Advanced Driver-Assistance Systems. 1, 2, 3, 6, 8, 9, 28, 30, 52, 54, 55, 56, 58, 59, 65, 87 CR Completion Rate. 20, 21, 47, 68, 79 GUI Graphical User Interface. 18, 34, 37 HMI Human-Machine Interface. 2, 8, 94 HTA Hierarchical Task Analysis. 17, 28, 33, 44 HUD Head-Up Display. 37, 38, 42, 43, 52, 64, 65, 89, 91, 92, 93 IA Information Architecture. 18, 19, 66, 84, 89, 92 IVIS In-Vehicle Infotainment System. 1, 2, 3, 7, 27, 84, 87, 92, 94 MWL Mental Work Load. 9, 24, 73, 75, 76, 91, 92, 93 OEM Original Equipment Manufacturer. 2, 6, 7, 10 PT Primary Task. 6, 7, 8 RP Retrospective Probing. 24 SA Situational Awareness. 8, 25, 50, 73, 74, 77, 90, 91 SAE Society of Automotive Engineers International. 2, 5 SEER Seamless, Efficient and Enjoyable user-vehicle inteRaction. 1, 2, 3 SEQ Single Ease Question. 22, 23, 47, 48, 69 ST Secondary Task. 2, 7, 8, 9, 28, 31, 33, 55, 56, 57, 58, 59, 60, 61, 94 SUS System Usability Scale. 23, 47, 48, 50, 53, 70, 71, 73, 74, 81, 82 SWAT Subjective Workload Assessment Technique. 24, 50 TBE Time Based Efficiency. 21, 22, 47, 68, 79 TTD Total Task Duration. 21, 22, 24, 47, 68, 79 UX User Experience. 3, 12, 13, 64, 92, 93 xi Chapter 1 Introduction Modern vehicles implements a number of different Advanced Driver-Assistance Sys- tems (ADAS) (see section 2.2) to assist with the driving process. As these systems assume more responsibilities, the role of the driver change from an active controller to a supervisor. On one hand, ADAS have the potential to improve driver safety and comfort. On the other hand, the driver might focus too much on other tasks and fail to pay enough attention to the road or traffic. Worldwide adaptation of portable smart devices has driven the integration and com- munication between these devices and In-Vehicle Infotainment System (IVIS) (see section 2.3). Drivers increasingly demand vehicles with the same level of connected interaction and infotainment as they find in their smart devices. This demand, in combination with ADAS, further boosts the use of IVIS. However, this growing de- mand and the availability of in-vehicle applications, makes the cognitive and visual driver distractions more relevant. 1.1 Background This thesis project is a part of the Seamless, Efficient and Enjoyable user-vehicle inteRaction (SEER) project(2016-2019) [1]. The SEER project is a partnership between Volvo Technology, Volvo Cars, Semcon, and RISE Viktoria, and is partially funded by the swedish innovation agency Vinnova. 1 The aim of the SEER project is to investigate and gain knowledge in three key areas: 1. How driver’s behavior change when ADAS are active. 2. How driver safety and experience change as the driver interacts with Secondary Tasks (STs) (see subsection 2.4.1). 3. How STs should be designed to allow for smooth, efficient, safe, and enjoyable interaction when ADAS are active. The expected results of the project will serve as assistance for Original Equipment Manufacturers (OEMs) during the design of IVIS in vehicles. The results will also provide recommendations as to how current decisions, standards, and guidelines surrounding the development of IVIS and other vehicle Human-Machine Interfaces (HMIs) should be updated. For the project to achieve its aim, it has been divided into four parts. This thesis project belongs to the second part, which address the design of concepts for interaction with STs. This thesis project was done in collaboration with Semcon, a multinational tech- nology company with specialization in product development, who mainly cooperate with companies in the automotive, energy, and life science industries. According to Semcon’s own research, there is currently much exploration, testing, and implemen- tations involving classic means of interaction with IVIS, e.g., via keyboard, touch, or voice input. As a result, Semcon are looking for concepts with a focus on non- traditional “outside the box” concepts and solutions for driver interaction with STs. The project is divided between two student groups who will focus on two different driving environments, city and highway. This project is focused on highway envi- ronments. However, both groups will work work closely together during the research phase and share information and findings. 1.2 Stakeholders Stakeholders for this thesis project are: • Semcon • Volvo Cars • Volvo Trucks • RISE Viktora These companies are the ones executing the project, and are therefore major stake- holders. Additional stakeholders are: • We, as students performing this project • Chalmers University of Technology 2 1.3 Aim The aim and expected result for this thesis project is a final evaluated HMI concept which allows a driver to interact with communicative STs, e.g., instant text messag- ing, found in a typical IVIS. It should be designed for vehicles placed in and below the second level of automated driving, according to the terminology, classification system and definitions provided by the Society of Automotive Engineers Interna- tional (SAE) standard (see section 2.1). The concept should only adhere to vehicles driven in non-city environments, e.g., highways. The concept should not impair the driver’s ability to operate the vehicle to a great extent. 1.4 Limitations Beyond the limitations set by the aim of the thesis project, the concept will not consider the actual operations of the ADAS in vehicles, just their consequences. The concept is limited to an internal and built-in solution within the vehicle and is not portable or removable. Concepts utilizing voice recognition or eye movement as a main solution will not be considered due to technical limitations in an automotive context, but could be used as a complement. 1.5 Research Question Addressing the purpose of the SEER project and the aim and limitations of this thesis project, a research question can be established: "What is an alternative way for interacting with the communicative functionality of an IVIS, such as text messaging, that is safe, efficient, comfortable, and provides a good general User Experience (UX)?" While this question was later re-phrased, this first question served as the start off point for this project. See section 6.3 to read about the new research question and the reasons for changing it. 3 1.6 Ethical Aspects This thesis project involves vehicles and drivers, and the final concept is meant to apply to vehicles in traffic. As a result, ethical concerns regarding the safety of both the driver and others, needs to be taken into consideration. The concept and its design need to adhere to established safety guidelines of the motor industry to reduce the probability that the concept contributes to any traffic accidents. User tests will be conducted to evaluate and improve the concept, which brings forth other ethical issues. Proper protection and respect for the users’ personal information, as well as keeping the users well-being a priority, is very important. It is hard to foresee if any user tests performed would cause the users’ in any problems to their health, but if that is the case, communicating this clearly to the users, so the risk is understood, is important. As this thesis project is conducted on behalf of Semcon, making sure to respect their image, values, integrity, and clients is another important ethical aspect. Finally, there are environmental aspects to this thesis project as well, such as making sure our design does not contribute in a significant way to any environmental hazards or emissions. 4 Chapter 2 Theory This chapter presents the different theories chosen based on their relation to the aim and research question of this thesis project. These theories are presented below and explained more in-depth. 2.1 Driving Automation Taxonomy The SAE is a global association developing standards for the aerospace, automotive and commercial-vehicle industry. In 2016, they issued a set of revised recommended practices surrounding the taxonomy and classification of motor vehicle driving au- tomation systems [2]. This classification describes six levels of automated driving, from zero through five, ranging from no driving automation to full driving automa- tion. Figure 2.1: A visual representation of the SAE levels of driving automation 5 This thesis project will focus on vehicles placed in levels two and below, where level two is named partial automation. In a partially automated vehicle, the system executes the steering and acceleration/deceleration. However, the driver is still required to monitor the driving environment and act as a fallback if the automation fails. 2.1.1 Dynamic Driving Task or Primary Task A "driving task" is a term describing a requirement for driving a motor vehicle [3]. This term can be broken down into three aspects: • Operational, i.e., lateral steering, longitudinal acceleration and deceleration. • Tactical, i.e., monitoring the driving environment, recognizing and responding to events and objects, maneuver planning, and signaling/gesturing to enhance conspicuousness. • Strategic, i.e., determine destinations and way-points. A Dynamic Driving Task, hereafter referred to as a Primary Task (PT), includes the operational and tactical aspects of the driving process, but not the strategic [4]. 2.2 Advanced Driver-Assistance Systems Systems developed to automate or help the driver during the driving process are increasingly more common in motor vehicles today. These systems are generally referred to under the broader term ADAS. In a partially automated vehicle, the longitudinal and lateral control of the vehicle is handled by certain driver assistance systems, mentioned below. Adaptive Cruise Control As an enhanced version of conventional cruise control, adaptive cruise control de- termines a set speed and following distance based on another vehicle ahead called a lead vehicle. The adaptive cruise control can automatically increase or decrease the speed to match the speed of the lead vehicle. It can also provide some limited breaking or completely stopping the vehicle if the OEM has implemented this func- tionality. As a lateral control system, adaptive cruise control can reduce the drivers cognitive, visual, and physical work load. 6 Lane Centering Lane centering steers the vehicle and keeps it in the center of the lane, relieving the task of steering from the driver to a certain extent. Compared to lane keeping assist, the car does not swerve inside the lane, as lane keeping assist does not keep the vehicle centered in the lane. Some lane centering systems provided by OEMs require the driver to keep their hands on the wheel in order for the system to function. If the lane lines are faint or covered, the lane centering might not work properly. As a result, the driver must still maintain focus on the road. 2.3 In-Vehicle Infotainment System An IVIS is an embedded information and entertainment system, which provides both vehicle-specific and traditional portable smart device services. Certain IVIS may utilize wireless connectivity, enabling the IVIS to provide the driver and passen- gers with content related to information, entertainment, and communication, e.g., phone calls or direct text messaging. The rise of portable smart devices, e.g., smart- phones, and increasing expectation on IVIS from consumers has further pushed the advancement and implementation of IVIS in motor vehicles. As a result, new STs (see subsection 2.4.1) have emerged in motor vehicles, e.g., social networking, in- stant text messaging, and web browsing. For this thesis project, only STs possible through a IVIS will be relevant. 2.4 Driver distraction Driver distraction is a serious problem with real-life consequences. Human error, e.g., misjudging the driving environment, was considered the probable contributing factor in 92% of accidents, where lack of attention was a major cause [5]. Research shows that a shift in attention away from PTs could increase the risk of an accident [6]. Glancing away from the road for longer than two seconds increase this risk by a factor of two [7]. Different solutions have been implemented by OEMs to reduce driver distraction, e.g., by utilizing voice-commands instead of touch based input. However, this might not solve the problem, as University of Utah psychology professor David Strayer puts it: "... putting another source of distraction at the fingertips of drivers is not a good idea." [8] 7 Furthermore, a bad design approach to these solutions might also lead to driver distraction, due to the underlying nature of the design. Strayer again says that: "Many of these systems have been put into cars with a voice-recognition system to control entertainment: Facebook, Twitter, Instagram, Snapchat, Facetime, etc. We now are trying to entertain the driver rather than keep the driver’s attention on the road." Using this information, we can determine that driver distraction is not only caused by human error, but also poor design of current solutions. 2.4.1 Secondary tasks In a study conducted by Klauer et al., they define driver distraction as: "... a driver has chosen to engage in a secondary task that is not necessary to perform the primary driving task" [7]. Using this quote and the previous definition of a PT, a ST can then be defined as the opposite of an PT, e.i., a task not connected to the operational or tactical aspects of driving a vehicle. Research suggest that drivers engaging in STs increase the risk of an accident, e.g., a slower reaction time to sudden events. An increase in attention towards STs leaves less cognitive resources towards PTs and the driving process. Too demanding or too much prioritization on STs could overload the driver and impact the driving performance. 2.4.2 Situational Awareness Drivers must use the current feedback gained from the vehicle and the dynamic driv- ing environment, but also how these variables could or will change in the future, to properly adapt their driving behavior. Mica Endsley defines Situational Awareness (SA) as: "the perception of the elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future." [9] Endsley has proposed other definitions as well but the one provided above is more broad and suitable for different domains. However, they all have the common basis of an individual "knowing what is going on". SA is an important safety aspect in driving and a lack of it increases the risk of an accident [10]. Making sure a driver has a high sense of SA is therefore very important, especially in partially automated vehicles where the driver needs to be able to take over when the ADAS fail. 8 2.5 Driver Characteristics How effective and safe a HMI is depends not only on the individual technology of the car, but also the psychology of the driver. The HMI needs to consider the different types of drivers and their varying tendencies towards driving and ADAS. Creating a HMI concept which keeps driver behavior in mind and does not promote an unsafe driving process is required. In order to better understand the psychology of the driver, the psychology concept presented in this section are used. 2.5.1 Mental Workload Mental Work Load (MWL) is the quantity or quality of the work required to perform a task. The concept has many direct implications on driving, as a drivers MWL often determines how well they are able to respond to dynamic traffic conditions. Research shows that MWL is decreased when automation is enabled [11]. It is important to understand the drivers MWL to understand if certain systems are overwhelming, which can lead to mental overload, or if the systems are underwhelming, which could lead to mental underload. Mental Overload Mental overload can occur when performing tasks requires too much attention and energy, leading to a loss of focus and control in regards to the primary driving task. This can lead to dangerous situations in traffic as the driver can be too focused on performing either STs or driving tasks, and will not be able to respond to dangerous traffic situations. Mental Underload A lack of tasks and inattentiveness may lead to mental underload, which is seen as just as bad as mental overload [12]. With ADAS enabled, the driver is able to focus on STs such as text messaging, which likely requires less mental effort than driving does. When a driver is experiencing mental underload, and their attention is on STs, reclaiming control of the vehicle in cases where adaptive cruise control fails can become difficult. Mental underload can also lead to skill degradation over time as the driver is no longer required to focus on the main driving tasks and will not have to practice their driving as frequently [13]. Skill degradation also contributes to problem of the driver not knowing how to reclaim control when required. 9 2.6 Research Through Design Research through design is an approach to research where knowledge is acquired through the design process. For this thesis project, research through design will be used with the intent to gain knowledge and insight through the design of dif- ferent concepts, and the evaluation of those concepts. Looking at related work and research, as well as look into areas besides the automotive industry, and draw knowledge from this is another important aspect to this approach. One issue with research through design is that it might lack validity in certain scientific communities, as the approach currently lacks definitions and standards. However, William Gaver suggests that too many protocols can be counterproduc- tive [14]. He claims standards can lead to research through design becoming too restrictive, when it’s currently a more creative approach to research. Gaver finally makes the claim that this type of research might be accepted as a science if it has more guidelines and protocols, but that a lack of this should not stop designers from pursuing research through design. 2.7 Guidelines for Safe In-Vehicle Systems To establish a foundation of what is considered essential in safe driving, a list of guidelines provided by National Highway Traffic Safety Administration, Japan Au- tomobile Manufacturers Association, Alliance of Automotive Manufacturers, and the Commission of the European Com- munities has been created [15–18]. The guidelines are meant to be used as design input for internal use by OEMs. The list also does not contain all guidelines found, as guidelines outside the scope of this project have been removed, as well as guide- lines that are very similar to each other. Examples of guidelines and what types of guidelines there are, see the table on the next page. 10 Type of Guideline Description Example Overall guidelines General guidelines that do not belong in any particular category. The system supports the driver and does not give rise to potentially hazardous be- havior by the driver or other road users. Installation guidelines Guidelines that discuss how systems should be installed into the vehicle. The system should be lo- cated and securely fitted in accordance with relevant regulations, standards and manufacturer’s instructions for installing the system in vehicles. Information presentation guidelines These guidelines deal with how the system should dis- play information. Information with higher safety relevance should be given higher priority. Interface with displays and controls guidelines Guidelines regarding user operation of the system. The driver should always be able to keep at least one hand on the steering wheel while interacting with the system. System behaviour guide- lines Describes how the system should behave. While the vehicle is in mo- tion, visual information not related to driving that is likely to distract the driver significantly should be auto- matically disabled, or pre- sented in such a way that the driver cannot see it. For full list of guidelines, see section A.1 in Appendix A. 11 Chapter 3 Methodology The theory presented in chapter 2 served as a basis for the decisions made regarding the chosen design process, methods and measures presented in this chapter. This chapter goes through what was used to ideate, design, and evaluate the concept of this thesis project. 3.1 Interaction Design Interaction design is the practice of shaping the users’ interactions with products, with a focus on user behaviour. For this project, interaction design is used as a design principle that falls under the term Human-Computer Interaction which specifically focuses on the interfaces that facilitate interactions between users and computers. When discussing interaction design, it is important to also acknowledge the term UX, with both terms being involved in the overall experience of products. However, the interaction designer is focused solely on the interactions, flow and behaviour of that product, while UX is focused on the overall experience between the user and the product. E.g., conducting user research is an important aspect in creating a good UX and to determine if user goals are supported in interaction design. As a result, interaction design could be seen as a subset of UX. Within interaction design, there are established methods and measures approaches which are described in section 3.2. 12 Four general and basic activities, which can be found in other design disciplines as well, can be established: • Establishing requirements Understanding who is the target group, what their needs and goals are, and how those can be achieved, is very important in interaction design. Differ- ent data gathering methods, e.g., surveys or interviews, can provide data to be analyzed for initial user requirements. In order to better understand the data gathered, task description methods, e.g., scenarios and use cases, could help in documenting and establishing more refined and detailed requirements. Performing task analysis techniques help in investigating existing systems and practices. • Designing alternatives This could be considered the core activity of interaction design, suggesting ideas for products that meets the established requirements. The activity can be broken down into two sub activities: creating a conceptual design and a physical design. The conceptual design involves the creation of a conceptual model. This explains what a product should do and how users interact with it. The physical design determines the details of the product, e.g., colors or sounds. Brainstorming is a tried and valid method to establish early concepts to explore and evaluate. Sketching and storyboards are other means to create conceptual designs. For the physical design, different prototyping methods are used to create a more interactive design. • Prototyping To properly evaluate a conceptual design, a physical and interactive prototype is necessary. A prototype does not necessarily need a piece of software to be effective. A low-fidelity prototype is often a paper-based build with a low cost in time and effort. The objective is to identify both obvious and unforeseen problems with the design, and if the design satisfies the established requirements. • Evaluating The validation of the concepts usability, user experience and support of estab- lished requirements is an important aspect of interaction design. By evaluat- ing the concepts with users, a higher chance of the concept being accepted is achieved. Other more technical evaluations, e.g., quality assurance and safety inspection, is another part of the evaluation process. The methods used dur- ing the data gathering can be used as well, but they will be structured and conducted differently, in order to validate and understand if the concept fulfills the user’s goals, the requirements, and provides a satisfying UX. Other more specific methods are case studies in controlled or open environments, e.g., in simulators. Gathering and comparing data related to the usage of the concept and data collected before is another way to measure improvement. 13 Figure 3.1: A visual representation of the design process These four activities are initially conducted sequentially, but are nonetheless inter- twined and performed repetitively. The feedback gained from each step can be used and influence other steps. New requirements could be established by evaluation, new alternative designs could be needed by creating a prototype, and so on. This iterative process is a key aspect of the user-centered design approach of interaction design. 3.1.1 User-Centered Design As an approach to interaction design, user-centered design involves the user in every step of the design process. The benefits of having the user as the centre of focus during the design process is that the resulting product fills all the user requirement and needs. In order to exercise user-centered design, gathering data about users is essential. Some data gathering methods are outlined below (see subsection 3.2.1) and are used to help the designer establish requirements. Other ways of including users in the design process is through evaluations, which is also detailed in the following section. In conclusion, the aim of user-centered design is to, by involving users in the design process, deliver products that are intuitive, easy to use, and that accommodate all the users’ needs. 14 3.2 Methods and Measures The methods and measures presented in this chapter are commonly found in inter- action design and will serve as the basis for the design process used in this project. Some methods are more suited for certain steps, while others can be used across multiple steps of the design process, although modified to serve a different purpose. 3.2.1 Data Gathering During any part of the design process, collecting qualitative and quantitative data is an important aspect, as it provides a foundation for requirements, decisions and proof of concept. These data gathering methods serve different purposes and are suited for different contexts and situations. They each have their own pros and cons, but they also complement each other in different ways. Observation Observation is a broad but useful tool in any stage of the design process. It can be used in the early stages of the project to determine user goals, tasks, or context. During the evaluation phase, observation can help determine whether the concept supports those user tasks and goals. The method can be conducted in a controlled setting, e.g., in a simulator, or in the field. Users can be observed directly as they perform an activity or indirectly through different types of records, e.g., photos or video. Observations is a useful complement to other data gathering methods, as it provides real world data and could help bridging any gaps in data or knowledge not found with interviews or surveys. Survey Surveys are used to collect quantitative user opinion of a concept and establishing their background through carefully constructed and contextually aware questions. A great benefit of utilizing surveys is distribution. By providing surveys electronically, e.g., by a web page, many users can be given a survey to answer. It also has a low time cost, since surveys can be answered by users separately and concurrently. Also, since a survey is the same for every users, collecting, sorting, and categorizing data from answered surveys can be a short process. However, a problem with surveys is user motivation to answer. There is no guarantee that every recipient of a survey will answer it. A solution is to try and conduct a survey directly with individuals in person, but this requires more time and effort on behalf of the project team in order to reach and question these potential participants. The data gained through 15 a survey is also limited to the given answers, so any attempt to gain further insight or clarification in a subject would require further data gathering. Follow-up questions As a complement to surveys, asking follow-up questions has the potential to give more qualitative data due to its one-on-one nature. Follow-up questions can be unstructured, through an open conversation about the subject, or structured, where the user is asked predefined questions. By asking users follow-up questions, one may gain a better understanding of the users and their needs, their likes and dislikes, and their opinions and thoughts. Also, these questions can be altered based on the response of the user, in order to gain more insight in relation to a given answer. On the other hand, this one-on-one nature also means that follow-up questions are time consuming. 3.2.2 Task Description Different task description methods can be used to better convey the knowledge gained from the collected data to stakeholders and the project team. Properly understanding the needs of the users is very important in order to assure they are addressed properly. Personas Data gathering methods tend to create a lot of similar data, both subjective and objective. This data can be used to create summarized representations of larger user groups called personas. A benefit with personas is that their are easier to develop for, as they cover a wide set of users with similar goals. They are also easier to target during development and provide an overview of the different users. They are usually created in the beginning of a project when sufficient analyzed data has been established and can be used. Use Cases Unlike user goals, use cases focus on the interaction between a user and a system. A use case can for example describe a desired goal that is desirable by using the system. By analyzing these use cases, it is possible to understand the different functionality that a system needs to have in order to reach these goals. By breaking down use cases, one can determine the necessary steps needed to complete a task, 16 what deviations a user might take, and how to handle the different cases that might appear. To create a use case, one first determines the actors interacting with the concept. You then examine the actors, what their goals are when interacting with a concept. Finally, you note down the necessary or theoretical steps the actor has to complete in order to reach their goal. 3.2.3 Task Analysis Investigating existing systems and practices can help understand the underlying motivation of users, as to why they use them in the first place. The goal is not to consider alternative products or solutions, but to analyze these systems and practices in order to establish new requirements based on the knowledge gained. Hierarchical Task Analysis Hierarchical Task Analysis (HTA) is used to break down the necessary steps required to reach a user goal [19]. By doing so, one can compare the steps to other solutions, understand the necessary interaction and levels of abstraction, and see in what ways design can be reused. 3.2.4 Ideation Once requirements, scenarios and use cases are established, coming up with concepts with the potential to address and support this is the next step of the design process. Different methods can be used, but using the common methods brainstorming and affinity diagram help in the creation and categorization of ideas to prototype and evaluate. Brainstorming Brainstorming is used to generate ideas. There are many ways to conduct a brain- storming session, but two key factors should be considered: that users’ goals should be known and understood by the participants, and that no idea is to be criticized or debated. Other more general tips are to present the problem to solve clearly, to document all suggestions, allow expansions on already documented ideas, and to not conduct the session for too long as to not loose focus or interest. 17 Affinity Diagram After a brainstorm session, a lot of different ideas has generally been gathered, many of which are similar, deal with different areas, and so on. This tends to create the need for organization. A good way to categorize and organize all these ideas is to create an affinity diagram [20]. To create an affinity diagram, one begins by putting similar ideas based on their natural relationship into groups. These groups are then analyzed and discussed. Groups can be split up into additional subgroups or combined. Similar ideas might also be discarded or combined. Each group is then given a name, based on its content. In the end, a large cluster of analyzed, reviewed, and named groups which contains related ideas is achieved. 3.2.5 Prototyping Creating prototypes is an effective way of getting an early perception of the viability of a product. A prototype is simple model that represents a product or an idea where the complexity and quality of the prototype can be different depending on what project the prototype is for, and what resources are available. Prototypes are often divided into two categories, low-fidelity and high-fidelity prototype. Low-Fidelity Prototype This version of a prototype is used to explore conceptual designs. They do not provide all of the final functionality, or only represent the functionality without actually performing it. It is often made rapidly with paper, or other cheap materials, to provide a quick way to check the feasibility of certain concepts. This also means a low-fidelity prototype is fast, cheap, and easy to update or modify, based on knowledge gained through evaluating the prototype. Sitemap Sitemapping is a technique used mainly during the creation of websites, but it works with software as well. It is basically a way to structure the Information Architecture (IA) hierarchically and establish how different views of the software relate to each other. IA refers to the structure of information on the Graphical User Interface (GUI). This is displayed using a tree structure. Starting with a "home view", one determines which views a user can navigate to. E.g., a view called "Messages" brings the user to a messages view, and from there, they might be able to navigate to "Message", "New Message", and "Contacts". For each identified view, this process is repeated until a final view is reached and the user can not navigate further down the 18 tree structure. Sitemaps provides a way to gain oversight of a software’s structure and help determine which views are needed. Flow chart While sitemaps are beneficial in establishing a structure and provide a general overview, flow charts helps determine when and how a user may navigate between views, e.g., which buttons starts a new view or are certain conditions meet to allow a user to navigate to a new view. Wireframes Creating a low-fidelity representation of the IA of a project has a number of benefits. It is a fast way to determine paths between different stages, the layout of elements, information to display, functionality, and which templates can be used. Wireframing is a great tool to achieve these things. A wireframe is a two dimensional illustration of an interface. Its focus is on layout, space allocation, content, behavior, and functionality. A wireframe does not include any styling, color, or graphics. High-Fidelity Prototype High-fidelity prototypes often require more time and resources to create. They achieve more of the "look and feel" of the final product and provides more func- tionality than the low-fidelity prototype. The main objective of this version of a prototype is to convince the stakeholders and users of the viability of the design, and to find any technical issues. 3.2.6 User Testing To learn what users think about your design, it is often vital to conduct user tests. Depending on the purpose of the test, whether it be to find critical issues with your design, or to test out the usability of a system, user tests can look very different. One common example of a user test is simply to observe the user while they use your product, or if the testing is done early, the users can interact with your prototypes, and record anything of note. Another example of a more time consuming user test could be to use eye-tracking software to learn where the users attention is directed. Regardless of what type of test you are conducting, any test can provide vital information and insights to the designer that they might not have thought of themselves. 19 3.2.7 Evaluation The evaluation could be one of the more complicated parts of the design process. Satisfaction and efficiency are hard aspects to get conclusive data on. Furthermore, what to evaluate, where to do the evaluation, and when to do it are additional factors that needs to be considered. There are two distinct settings where an evaluation differs in its conduction, focus, and result: a controlled or natural setting. Performing an evaluation in a controlled settings could be considered an easier way to determine if a concept allows a user to accomplish their goals, the use cases and scenarios, and requirements. A directed and controlled evaluation allows for more in-depth observation and evaluation of usability, where issues or divergence can be more easily detected. However, the context of use will not be as easy to establish or control, meaning the result of the evaluation might not represent the realistic use cases. Field studies in more open and natural settings are a lot more relaxed and open ended, and has a better potential to show how the concept is received by users in its’ intended setting. Furthermore, unforeseen or unintended issues could more easily be discovered, due to the unstructured nature of the evaluation. However, external factors have more impact on it as well. A natural setting for the evaluation could also cost more in time and resources. Common for both approaches is the collection of data through different data gath- ering methods, some of which are mentioned below. This is easier in a controlled setting. It is also valid for for more open settings, but the data gathering method has to adapt to the unstructured nature and lack of framing. Besides the setting and environment during evaluation, a use of objective and sub- jective evaluation methods also needs to be considered. A product can be objectively good, but lacking subjectively, meaning the users are not happy with the product. This also works the other way around. A product can be ineffective but users enjoy the product so much, they are willing to overlook this flaw. A proper balance of both subjective and objective measures helps in getting a better evaluation of a product. Lastly, the evaluation will be formative in its nature, as its results will be used to monitor our progress towards our goals. This means the data and feedback received will be used to determine how to best revise of modify our concept for improvement, and not to compare to any other standards or benchmarks, e.g., other studies of a similar nature, which is more of a summative assessment. 20 Effectiveness To determine whether or not a product is effective, two measures can be used: Completion Rate (CR) and number of errors. Measuring the CR is straightforward; You take the number of tasks a participant completed successfully, divide this number by the total amount of tasks for the test session, and finally multiply it with 100 to gain a percentage. As a result, a CR is gained which represent how effective the solution is. The full equation to calculate the CR is shown below: CompletionRate = Number of tasks completed successfully Total number of tasks undertaken × 100 Error Rate The amount of errors a participant encounters has an effect not only on the effec- tiveness of a product, but also the participants perception of the product. Getting a good grasp on a product’s error rate and what kinds of errors a participant encoun- ters is therefore important. During a test session, noting down the number of errors a participant encounters in each task is helpful in keeping track of error prone tasks. To further understand these errors, a categorical system can be used to break down each error into a subcategory: • Unintended actions, e.g., missclicks • Slipups, e.g., an obvious navigational error. • Mistakes, e.g., selecting a wrong element • Omissions, e.g., not noticing presented information. Keeping track of what kind of errors a participant encounter and during which tasks they occur helps in understanding which tasks are error prone and what is the cause. Efficiency Two methods can be used to determine the efficiency of a product: Total Task Duration (TTD) and Time Based Efficiency (TBE). Much like measuring a products CR, it is just as straightforward to measure TTD. For each task, after the participant has begun with the current task, start a timer. Once the participant has completed the task, successfully or not, stop the timer. 21 The TTD is achieved by subtracting the end time with the start time, much like the equation below: Total Task Duration = End Time − Start T ime Using TTD, one can quickly establish which task requires a significant amount of time for the participants to complete. However, one must also keep in mind the nature of each task. E.g., a task which requires a participant to enter text would naturally take more time to complete than selecting an element. The second method, TBE, is primarily used to see how many tasks the participants completes on average per second. TBE takes the resulting time and success for each task, for each participant, and provides a final value which represent the overall efficiency of the product. The equation below is used to achieve this result: Time Based Efficiency = ∑R j=1 ∑N i=1 nij tij NR where N is the total number of tasks, R is the total number of users, nij is the result of task i by the participant j; if successful, then nij = 1, else nij = 0. tij is the amount of time spent by the participant j to complete the task; if not successful, then tij = the time until the participant gives up. Important to remember is that if the time is measured in seconds, the result will give tasks per second. Multiplying by 60 will give tasks per minute, and so on. Single Ease Question The Single Ease Question (SEQ) is a simple but effective way to quickly gain a subjective measurement of a product on a task level. At the end of each tasks a participant completes, they are asked a single question: "Overall, this task was?" Using a Likert scale1, the participant then selects the alternative they feel represents their answer to the questions above. The scale can look something similar to what is given below: Very Difficult Very Easy O O O O O 1https://en.wikipedia.org/wiki/Likert_scale 22 In this case, "Very Easy" represents the value 5, and "Very Difficult" represents the value 1. These are later converted to a 0 to 100 scale for easier scoring. Since this data is gained after each task, one can quickly get an oversight of which tasks participants find difficult and easy to complete. The SEQ is short, easy to under- stand from a participant perspective, and easy to score and administer during a test session. System Usability Scale In order to get a quick but still broad and test specific subjective measure, the System Usability Scale (SUS) [21] can be used. SUS provides a quick but reliable way to measure the subjective usability of a product. At the end of a test session, the participant responds to 10 statements. Each statement deals with a different area of usability. An example of a statement is "I found the system easy to use". Each statement has 5 options of responses the participant can choose from. These responses, much like the SEQ, use a Likert scale and the responses range from "Strongly agree" to "Strongly disagree". When interpreting the responses from a participant, it can be somewhat complex. Each response has a single designated value. These values range from 0 to 4. For an even numbered statement, the response value is kept, while for an uneven numbered statement, the number 4 is subtracted with the value of the chosen response. The new value is then multiplied by 2.5, in order to convert the value into a 0 to 10 range. In the end, all response values for all the 10 statements are added together, providing a percentage which represent the participant’s usability score for the product. What makes the SUS good is that it is easy to administer to the participants, still provides a reliable results even when a small size of participants are questioned, and can quite effectively tell if a product is usable or not. Another benefit is that each statement has its own category of usability, so you can easily determine in what area a product is lacking. E.g., the product can achieve a high score in categories such as low technical complexity and is easy to start using, but a low score in reliability, meaning focus has to be put into making the product more reliable. However, as mentioned before, the scoring system can be quite complex. Also, the SUS gives a general picture of a products usability, but does not go into any specifics as to what makes or breaks the product. Therefore, it should not be used as a final evaluation tool to determine usability, but rather as guidance. 23 Retrospective Probing In order to combat some of the shortcomings of the objective and subjective measures mentioned above, Retrospective Probing (RP) is a good method to utilize. RP is a technique where after a test session, questions regarding a participants thoughts and action during the session is asked. This is helpful as it provides a richer and deeper insight into what the participant thinks about the product. Another benefit of RP is that it does not interfere with the test session, e.i., interrupts the participant, or disturbs other evaluation methods, e.g., TTD. However, depending on how long a test session is, it can be hard for a participant to remember. This can be countered by taking down notes during the test session, in order to later remind the participant of what happened. Subjective Workload Assessment Technique Since the MWL of a driver of a vehicle is an important aspect of how usable and safe a product is, a relevant technique has to be used to establish the over or under-load a participant experience. The Subjective Workload Assessment Technique (SWAT) [22] is subjective measure where the participant rates the time, mental effort, and psychological stress load the product requires. The SWAT can be done on a task to task basis, or at the end of the test session. The participant has to chose one of three statements, whichever one represent their opinion the most, provided for each category: time, mental effort, and psychological stress. Once the participant has provided an answer for each category, a final MWL score is achieved. This is done by giving each statement for each category a value from 0 to 2. These values of the chosen statements are then converted to a 0 to 100 scale. The average score of the three statements are then calculated, which represent the MWL required. A high score represent an experience that creates overload, while a low score represent an experience that creates underload. The benefits of SWAT is that it is unobtrusive, as you do not need any hardware such as heart beat monitors or eye tracking headsets to measure stress. Also, it does not require much time and is easy to administrate. It also provides an easy measure of the MWL required from the participant. However, a disadvantage is that it can be quite time consuming if it is administered on a task to task basis. Also, the phrasing of the statements can be confusing, as it uses quite technical and advanced sentencing. Rewriting these sentences to make them more understandable might be required. 24 Situation Awareness Probing There are a lot of methods which can be used to determine the SA of a partic- ipant, e.g., eye-tracking. However, asking simple questions about a participants environment can be a simple and effective tool to gauge how situationally aware a participant is. During a test session, e.g., during a driving simulation session, a participant is asked at certain times or during certain events, questions about their surroundings. If the participant answers correctly, they were situationally aware of their surroundings. However, a potential problem is if the participant lies and gives a positive answer to a question, even if the participant was not situationally aware and did not know the correct answer. To combat this, one can have a number of decoy questions. e.g., Did you see a warning sign? when there was no warning sign present. This sort of question both shows if the participant was situationally aware, i.e., they did not see a sign, or guess/lies when giving answer. 25 Chapter 4 Process Ultimately, the project consisted of five different phases: a initial research phase, a establishment of initial requirements phase, and three sequential iteration phases. Each phase had a different set of goals, measures, and methods to reach the goals of each iteration, utilizing what was presented in chapter 3. This chapter will describe in-depth what the goals for each phase was, the problems encountered, the solutions discovered or used, and present the process to reach the goal of each iteration. 4.1 Research The research phase was an important first step of the project process. The research provided a important and solid basis on which our concept was based and built upon, but also evaluated and judged by. There were a few different goals for this phase, and because of it, different areas the research had to be focused on. The first goal was to gain a better grasp on what is currently used and what is being researched and developed in terms of interaction and presentation of information in the automotive industry. The second goal was to understand current guidelines and taxonomy used in the automotive industry in regards to the project domain. The third goal was to look into the characteristics and behavior of drivers, in order to better understand how they think and act. The results of this research was used to establish what was presented in the chapter 2, but also carried over into the next phase, the establishment of requirements. 26 4.1.1 Literature study The first step in the research phase was the study of appropriate and relevant lit- erature. A majority of the literature was provided by Semcon and included studies curated by other people involved in different parts of the SEER project. The study of this literature was crucial for us to be able to quickly attain knowledge in dif- ferent areas relevant to the SEER project. Further access to literature was gained by using the Chalmers online library. A large part of the research topics dealt with automotive industry guidelines, taxonomy, technology, and driver characteristics, and contained terms and concepts which was significant when designing tools for interaction in vehicles. The literature read during this part served as the basis for the topics presented in chapter 2. 4.1.2 Research of Similar Products In order to understand how users currently interact with IVIS, much of the early research was spent on researching the types of interaction tools other vehicle man- ufacturers were currently implementing. Some of this research was done online, by looking at different car manufacturers web pages, expert and customer reviews, and tech-shows, e.g., CES1. By reading articles and watching footage of various future concepts from various auto shows, we also got a good grasp on where future in- teraction technologies in vehicles are heading. As a result, it was easy to get an overview of current IVIS and the means of interaction, both the cutting-edge as well as current standards. A number of different requirements could be established using the knowledge gained from this research. However, this part was mainly done for the benefit of the team itself, in order to get inspiration and understanding about what users considers positive and negative in regards to current IVIS. Field Research While parts of the research was done online, field research was also conducted in order to get hands-on experience with different IVIS and their means of interaction. The research consisted of traveling to different car retailers and testing out the IVIS. This provided insight into what types of interaction worked well, and what did not work as well. Some issues that were encountered were the fact that most system required either the car to be turned on and started, or to have a mobile phone connected via bluetooth. While these issues could be resolved in most instances there were still some cases were this issue made us unable to properly investigate the system, as the car retailers did not allow us to start the cars or the cars IVIS 1https://www.ces.tech/ 27 were locked in a presentation mode. Pictures from the field research can be found in section A.4 in the appendix. During this step in the research phase, a HTA was conducted by recording the steps necessary in order to reach a final goal. A number of different tasks were used, e.g., call a number or send a text message. Only tasks which adhered to the limitations of this project were tested and mapped out via HTA. Also, because of the limitations mentioned in the previous paragraph, certain tasks could not be analyzed using HTA, e.g., connecting a phone to the car was not possible in certain models, and having a phone connected was necessary in order to do certain tasks. The different HTAs was used as a reference during later phases of the process, as it provided guidance during the creation of our concept, but also something to compare to during internal evaluations. 4.1.3 Driving Habit Survey A survey was conducted in the early stages of the project with the goal of under- standing the driving habits of different drivers, as well as how and which STs they do or do not perform while driving. In order to achieve this, and to get as many responses we could, from a wide range of demographics, we implemented a survey using Google Forms2. The survey was distributed through various online channels, e.g., Facebook groups, forums, friends and family, and so on, with the goal to tar- get as many different types of drivers as possible, i.e., truckers, people who own vehicles with ADAS, and so on. The questions the participants had to answer were about subjects as their personal and driving backgrounds, if they have ever driven using ADAS, what kind of tasks they perform while driving, and so on. Additional questions regarding the participants experience with touch screens and other forms of input were also asked in order to understand which technologies the participants were the most comfortable with. The survey was conducted in collaboration with the other student group who focused on city driving. This was done as both groups wanted to learn the same type of information, just regarding different driving environments. It also prevented the groups from having to send out two very similar surveys to the same users. In the survey, the users also had to answer what environments they primarily drive in. Based on the answer to that question, the survey branched into different paths where the questions were focused on either city driving, highway driving, or both. Using different queries on the finished data, the results could be easily divided to only show relevant data to each group. 2https://www.google.com/forms/ 28 Pilot Before the survey was distributed, a pilot session was conducted with various people at Semcon, including our supervisor. This was done as a means to find any mistakes or to see if we had overlooked any important aspect of the survey before we send it out. After receiving feedback from Semcon and proper updates had been made to the survey, it was distributed to a small number of people for further feedback. The feedback gained was that the survey was quite long and with a very technical language. Also, small mistakes such as spelling errors, were also found. As a result, the survey was condensed further and questions were rewritten in order to make it more understandable by participants who are not as knowledgeable in the subject matter. Follow-up Questioning While the survey provided quantitative data, a more qualitative method was required in order to get more detailed feedback and knowledge. As one of the final questions in the survey, the users were asked if they could be contacted with follow-up questions. Out of all responses, a few agreed to answer some more questions, and left their e-mail as contact information. These users were then asked more detailed questions, and were asked to clarify some of the comments and answers they gave in the survey. To get as qualitative replies as possible, each e-mail sent was customized to each individual, asking questions based on their answers in the survey. On the next page is one of the e-mails that we sent out: 29 "Hi, About two-three weeks ago you were kind enough to answer our survey re- garding driving habits in motor vehicles with advanced driver assistance. We really appreciate you for taking the time to answer it. The reason why we are contacting you is because we have some follow-up questions. If you don’t want to answer, please tell us and we will not contact you further. NOTE: For all questions below, assume you are driving a car on a high- way/rural road without any driver assistance enabled. You answered that you either rarely perform voice calls: 1.) To perform voice calls, do you use your phone or your car (by connecting the phone to it)? If neither, how do you perform voice calls? 2.) What problems do you experiencing when you perform voice calls? 3.) If you have any problems, how do you currently handle them? You answered that you feel a little comfortable when performing voice calls: 4.) What would have to change in order for you to feel more comfortable with voice calls? You answered that you mainly use “Touch” when performing voice calls: 5.) Do you think touch works well? Why/why not? 6.) Would you like an alternative to touch? If so, what could that be and why? You answered never when asked if you use direct messaging, social media or email: 7.) Would you like to be able to engage with the activities above through an in-car system (as in, not using your phone directly)? If yes, which ones? 8.) What are the main reasons you’re not currently engaging with the activities above? 9.) What would have to change in order for you to engage with the activities above? Final question: 10.) Do you have any other comments about improving the use of communi- cation activities? If you have any questions, do not hesitate to ask us and we will answer. Otherwise, please reply to this email with your answers. Your reply only needs the number of each question above followed by your answer. Thank you for your time!" The relevant responses from the follow-up questions were then compiled into differ- ent personas, some being related to driving without ADAS and some with ADAS. By analyzing the data from the survey, as well as the answers from the follow-up 30 questions, some user needs and requirements were identified and could be used as a foundation when thinking of our own design solutions. 4.2 Requirements Using the literature study, the research of similar products, and the user research, a thorough set of requirements could be established. These requirements were divided into three categories; • Functional Requirements - These requirements describes what the system should do. • Non-Functional Requirements - Describes constraints around the system [23]. • User Requirements - Requirements gathered from the user research. While the majority of requirements are compiled from the guidelines mentioned in section 2.7, the full set of all requirement also contain those acquired from the user research. To read all requirements, see section A.2 in the appendix. 4.3 First Design Iteration The first iteration began as soon as the initial literature study was completed. For the first iteration, the aim was to, through various methods, establish initial concepts that could be viable solutions to our research problem. 4.3.1 Conceptualization After the initial requirements were established, categorized and framed, the concep- tualization phase of the project was carried out. The main goal was to establish as many diverse ideas and concepts as possible which deal with the interaction with STs, discuss and transform those which were deemed interesting or showed promise, and finally narrow down and combine the options into a full solution. Brainstorm In order to generate early ideas and concept to later explore and discuss, a brain- storming session was conducted. A small conference room was used as the location for the sessions, so that the session could be conducted without outside disturbance or interruptions. Small notes and markers were brought so we could write down our 31 ideas. This makes sure the ideas are recorded for later reference. To begin the brain- storming session, the goal of the session was clearly written down on a whiteboard in the room, along with some bullet points related to the scope of the project. This was done so we would remember and understand the underlying goal of the session. Once everything was setup, we were ready to proceed with the sessions. Approx- imately one hour was spent on generating ideas. The session was conducted in silence. The reason behind this was to reduce the probability of getting sidetracked and to give each of us room to think. Once an idea was generated, it was written down on a note and laid out on a table in the room for easy overview. This was so that inspiration could be drawn from each others’ ideas. Affinity Diagram Once the brainstorming session was over, all the notes were looked over and any duplicates were removed. The notes were then put up on a whiteboard in order to create an affinity diagram. The notes were sorted into groups based on their similarity, as seen in Figure 4.1. Once all notes were sorted, each group was given a category name. We then proceeded to discuss each category, where ideas were either dropped due to scope limitations, a lack of engagement from us, or due to technical, economical or logistical concerns. Other ideas where further discussed and depending on our judgment, were then kept and moved to the next step of the process. The categories we came up with were: • System Behavior • Tangible • Steering Wheel • Gestures • Design In the end, a list of diverse ideas had been established through the brainstorming session. These ideas where then sorted and discussed. Those ideas that remained had been further transformed and explored. Finally, we narrowed down ideas into a few of concepts to further explore and discuss. 32 Figure 4.1: Affinity diagram created from the result of the brainstorming session. 4.3.2 Initial Ideas The concepts produced through the brainstorming session where often unclear at this point, and needed to be transformed into easy-to-understand ideas. The HTA done in an earlier stage provided a lot of insight into which steps are required and in which order they need to be completed to allow the interaction with different STs in an infotainment system. By utilizing the HTA, three different interaction subcategories could be established, which had to be addressed in any of the concepts we came up with. These categories were: • The selection of elements • The navigation between different elements • How the textual and numeral input is achieved Narrowing Down Ideas First, focus was directed towards how textual and numeral input could be imple- mented. Early on, we found the idea of handwritten text input, sometimes called scribble, which means physically writing the input with a finger on a touch surface, 33 to be interesting. Different ideas for how the driver could scribble the text was established during the brainstorming phase, but they all shared the same base idea: a semi-flat or flat surface which takes touch input from the driver and presents the result on a some sort of screen or via a projection. Using the idea of a touch surface for scribble text input, focus was now diverted towards the first two points mentioned earlier, i.e the selection of elements, and navigation between elements. A great source of inspiration was the Microsoft’s Surface Dial, a tactile "puck" which is placed on a screen and provides contextually aware controls and options3. Using this tactile and movable puck as inspiration, a early concept of a similar product which could be used to control different settings or menus in the vehicle was initially explored. However, this concept was later dropped as we felt that a detachable solution could get lost or the driver could experience mental overload trying to locate the puck when trying to use it. Still, the idea of a fixed tactile puck with different means of controls, such as being able to rotate, shift, click, and lift, was established and what these means of controls would achieve. However, as the idea was discussed further, concerns regarding nav- igation between elements was raised. The scope of the project entails social media and other similar applications. The diversity in content placement and number of elements could mean that the driver would have to rotate the dial many times in order to scroll though a large amount of options to reach what they desire. This could potentially require a lot of mental workload from the driver, as they would have to provide a large amount of inputs and check visually to confirm they have arrived at the correct option. Drawing inspiration from smartphones, the idea of using gestures with the touch area placed on top of the puck was explored. Different gestures could be used to scroll through content while rotating the dial would provide a more precise selection of elements. To provide even further precise selection of elements, the puck could be shifted in different directions, mimicking that of a computer mouse to move around a pointer. Very precise selection of elements could now be achieved and allow for the usage of different diverse applications, while traditional touch gestures in combination with the dials rotational and vertical controls would allow for more natural and tactile navigation and selection. However, the questions as to why use a dial at all was raised. The track area is used to provide text input and navigate in the system, while the puck itself is used mainly for moving a cursor. Instead, we explored using a trackpad as a single solution, where the output display which contains the GUI that the user would look at, would mirror the trackpad 1:1. Meaning that if the user places their finger in the top-right corner of the trackpad, the element in the top-right corner of the GUI would be selected. The user would select elements based on the general position of the finger on the trackpad rather than a mouse pointer. The touch area would allow for scribble input and using different finger gestures would allow for scrolling, 3https://www.microsoft.com/sv-se/surface/accessories/surface-dial 34 swiping and other actions. The concept of a trackpad seemed a lot more simple, intuitive and interesting than the idea of using a puck, which is what we aimed to investigate by building prototypes. 4.3.3 Rapid Prototyping While exploring both the puck idea, as well as the trackpad, we wanted to build simple prototypes for both concepts, to get an idea of their viability. Rapid prototyp- ing, which is quickly creating very simple representations of a product, or concept, allowed us to get hands-on with our ideas and to get a feel of how they could work. The first prototype we built was for the puck, and was as simple as cutting out thick circular piece of extruded polystyrene foam, and placing a strap of paper around it, which could be rotated around the puck. A small piece of soft padding was then glued to the underside of the puck, which created a space between the surface the puck is placed on, and the puck itself. This allowed the puck to be pressed in different directions, and provided the final functionality that we had in mind for the puck. Being able to rotate, press in multiple directions, and use the top of the puck as a touch surface, we could now test how it felt to use these different interaction tools. What we found was that too many different means of interaction in one single unit, i.e the puck, could be confusing for the user. We also noted that the scribble area on top of the puck was quite small, and would make it difficult for the user to easily write entire words, and would most likely end up writing one character at a time. This would increase mental workload, and force the user to focus their attention on text input. Another flaw that was discovered was when pressing the puck in multiple directions, compared to simply using the trackpad where the user moves their finger in any direction, the puck seemed overly-cumbersome and in-precise. Figure 4.2 shows the prototypes together with a large paper containing some of the sketches we did. The second prototype was of the trackpad. Using a hard paper cutout was sufficient as a simple prototype, as it provided enough resistance and structure needed to get a feel for the concept. Another part that we included in the prototype, was a stand, which could angle the trackpad in various different degrees and positions. By testing different gestures and positions, and comparing that with our experience with the puck, we concluded that the trackpad would be a more viable solution to our research problem, than the puck would. 35 Figure 4.2: A collection of sketches together with the early prototypes 4.3.4 Trackpad After the rapid prototyping sessions, and having evaluated the concepts based on the prototypes we created, we decided to pursue the trackpad idea. Part of the reasoning for this is the familiarity with trackpads, as it would work like a combination of a computer touchpad and a smartphone screen, meaning that people using the trackpad would already have experience using similar products. Other reasons are the larger input area, as well as the simplicity of having touch based input. The main points of interaction with the trackpad is the user using their finger to select elements, and using gestures to complete other tasks, such as scrolling, zooming, text editing, and so one. To avoid accidental presses while driving, the trackpad also makes use of a physical click to select elements or perform certain actions, similar to that of certain laptop touchpads. While testing the trackpad we did however discover the need for simple, easy to understand shortcuts to commonly used actions. At this point we added buttons to the trackpad, which would have permanent actions connected to them. Three buttons were added to the top of the trackpad, a "Back" button that we would take the user back one step to the previous screen, a "Home" button which takes the user all the way back to the systems landing screen, and finally a "Options" button, which is meant to bring up 36 additional, contextual options depending on where in the system the user currently is. Unlike a traditional computer touchpad, this concept tracks the relative position of the users finger, and maps that position to the output display. This eliminates the need for precise control by the user, as they would not need to find the exact position of their target element, but instead only need to be in proximity of the target. As we decided to move forward with the trackpad concept, we decided that in the next design iteration, the concept would be tested by users, and evaluated to get an objective view of how the trackpad could work in a driving environment. 4.3.5 Head-up Display The system GUI also has an effect on how viable the trackpad, as well as the entire system, is. Having too many elements on one single screen would make it difficult to select the right element, but dividing major elements between different screens would force the user to explore the system in order to find what they are looking for. This means that an effective information architecture, i.e the logic order and layout of the elements in GUI, needs to be established. This was however not the focus of this iteration, but something that we planned to do in the next iteration. An alternative to using a traditional screens is using a Head-Up Display (HUD), which is a screen being projected on a transparent display. In a automotive context, the screen is often projected onto the front windshield, but some cheaper commercial HUDs use a separate screen which mirrors the users smartphone. Some commonly used information to display in a HUD is the speed limit, the speed of the vehicle, and some basic navigation. As HUDs are becoming more prevalent in cars, we wanted to explore the advantages of using our system in combination with this technology. Testing and evaluation of the HUD is however planned for the next iteration as well. 4.3.6 The Concept We decided to move forward with using a trackpad as the main input method. Using this tool, the user will navigate through the system, make selections, and enter text. We also decided to use a HUD as output for the system. As of this iteration, the screen will be projected onto the front windshield, and will display the entire system. The HUD is also where the user will direct most of their attention while interacting with the system. The concept can be seen in Figure 4.3. 37 Figure 4.3: A drawing of the concept. The user will highlight elements in the HUD by placing a finger on the trackpad. The element which is highlighted depends on the placement of the finger relative to the trackpad. If the user moves their finger to another location, the highlighted element change, as seen in Figure 4.4. Figure 4.4: The user highlights elements by touching the trackpad. The highlighted element is chosen based on the finger’s location. 38 In order to actually select an element, the user has to click the trackpad, much like how a typical trackpad on a laptop works. To scroll content, e.g., lists, two fingers has to be used, since one finger is used to highlight. This can be seen in Figure 4.5. Figure 4.5: Selecting elements is done by clicking the trackpad. Scrolling is done with two fingers Text input use the trackpad as well, as seen in Figure 4.6. The user will scribble the character or word to input on the trackpad. 39 Figure 4.6: The user use handwriting to input characters or words. Some physical buttons are also part of the setup. This is to provide some easy to reach alternatives to options that are typically used often, e.g., "Back", as seen in Figure 4.7. However, there is another reason for this as well. Since the trackpad is used for highlight elements, the user needs to press the physical back button to leave the handwriting mode. 40 Figure 4.7: The three physical buttons placed above the trackpad. 41 4.4 Second Design Iteration For our second iteration, we wanted to take what we got from the first iteration, and develop it further. One of the main goals and focuses of this iteration was to further visualize our concept, as well as decide on how important aspects such text input would work. Another goal with this iteration was to get actual user feedback of the concepts, which will be achieved by creating high-fidelity prototypes, and testing those with a diverse group of users. By collecting both their opinion and feedback, as well as data collected via observations, we get a collection of subjective and objective data that we can use to further develop our concepts. 4.4.1 Use cases Using our research as a base, we started this iteration by creating different use cases which served as the basis for the upcoming wireframes, prototypes, and flow charts. By having these use cases established early, we knew which areas to concentrate on, and which ones we should not focus on. These use cases all have to do with communicative tasks, as that is the focus of our research. Other tasks, such as car status, climate control, and so on, is left for future work. The use cases are found below. • Answer a phone call. • Decline a phone call. • Make a phone call to a random number. • Make a phone call to a contact. • Read a text message. • Send a text message. • Decline a text message. • Read an email. • Send an email. • Read a social media time line. • Comment on a social media post. 4.4.2 Information Architecture When first designing the information architecture, the requirements established ear- lier were used to guide the process, e.g., only 30 characters should be displayed at a given time. A simple layout where only the most pressing options and information was presented was chosen, as to not overburden the driver with information, and because the small display area of the HUD would only allow a small amount of 42 elements. Furthermore, since the information is not displayed on a physical screen but rather projected on the front windshield, extra attention to font size and color scheme of the elements was important. Otherwise, content could blend in with the environment, making it harder for the driver to see. We kept this problem in mind, but since we did not have access to an actual vehicle HUD projector, we instead used a background picture of a driving environment, as seen in Figure 4.8. 4.4.3 Text Input During the first design iteration, we decided that handwritten input would be a suitable option when it comes to text input. This is an area we discussed extensively, as according to National Highway Traffic Safety Administration, distracted drivers caused over 3000 deaths in 2015 [24]. We wanted to find a method that would decrease the amount of time the driver has to look away from the road, while still being a fast and effective way of typing. The result of a study by Kern et al [25], which is based on the research done by Burnett et al [26], shows that handwritten input is generally better than standard on-screen keyboard input. For this reason, the solution presented in this thesis uses handwriting as the main text input method. We also tested this method in a driving simulator, where the input surface was mounted on the steering wheel and the input was displayed on a HUD. Based on this experience and the research presented in this section, handwriting input was deemed as the most appropriate, and safe method. There are many cases where the user would enter a text input mode. For example when writing an email, replying to a message, or searching for a specific person in their contact list. As mentioned previously, text is entered by using their finger to write characters, but there are also a some options that the user can utilize to make text input, as well as editing that input easier. 4.4.4 Wireframes In order to visualize our concept, wireframes were created using Figma4. This web tool allows for collaborative design, with up to two users at the same time using their free model. Collaboration makes for faster creation of wireframes, as the work could be divided while still working on the same space. These wireframes were based of the initial sketches and whiteboard drawings, and took them further by making them higher fidelity. We also focused the wireframes around the use cases mentioned in subsection 4.4.1, meaning that we ignored including options such as navigation, car status, and other alternatives that are not related to communication. Figure 4.8 shows the first iteration of wireframes. When creating these wireframes, we used images of real traffic as the backdrop, although we dropped this approach for later 4https://www.figma.com/ 43 designs. To view more wireframes, see section A.3 in the appendix. Figure 4.8: An early design of the HUD. 4.4.5 Flowchart Creating flowcharts played an important role in figuring out the logical steps the user has to take in order to complete certain tasks. The charts which were pri- marily drawn on whiteboards gave a simple overview that allowed us to catch any superfluous steps that could be eliminated. After reaching a flow of steps that was satisfactory for each task, we could compare those tasks to the steps compiled in the HTA to see which if our system provided fewer or simpler steps for completing a task. 4.4.6 Prototyping Two different kinds of prototypes were creating and then evaluated based on how they could be used for testing with users. The first prototype make use of the wire- frames created in the previous step. The first prototype is an interactive prototype made using Invision5, which allows for the user to see and experience interactive elements in the wireframes. This prototype also enables the user to test the infor- mation architecture by navigating through the wireframes. The second prototype was made in Android, as Semcon requested an Android prototype to later evaluate 5https://www.invisionapp.com/ 44 and discuss internally, and was meant to be used in a driving simulator in order to test the navigation while driving. The prototypes had different intended uses which were meant to provide insight into. The data collected from testing each prototype could then be compiled and analyzed to see which parts of our solution needs to be changed, and which parts works well. 4.4.7 Android Prototype To properly test the interaction with the system, a functional high-fidelity prototype had to be created. The high-fidelity prototype also serve as a proof-of-concept. Initially, InVision was supposed to be used to create the functional prototype, as this service can be used to quickly create a high-fidelity, interactive prototype using the content created in Figma. However, a number of limitations, e.g., not being able to specify or use different touch input gestures, the need to create a path for every single possible combination of navigational or selective inputs, and so on, put a stop to these plans. Instead, the decision to create an Android application was decided on. The first major challenge was the fact that Android does not have support for a hover state for touch input which is a major part of the concept. The concept use the idea that the user can explore and confirms where their point of contact is through the highlighting of elements. A hover state is supported when mouse input is used but this sacrifices another important aspect of the concept, namely having multiple points of touch input. As a result of these shortcomings with Android, a new solution had to be implemented. The solution was the use of hitboxes. A hitbox is a bounding box which stores four groups of x and y values, each group represent the corner of the box. For each element displayed, a hitbox was created by keeping a reference to each element and using its’ positional data to create a hitbox. The application could then retrieve the x and y value of the touch input and compare it to a list of hitboxes. If the touch input was within the bounds of a hitbox, the same reference used to retrieve an elements positional data could be used to change its properties, allowing it to be highlighted. The solution was effective, allow the user to put their finger on the screen and highlight different elements by simply swiping their finger around the screen. However, the hitbox solution created a new problem. Android uses a hierarchical system to decide what the user has touched on the screen. So a parent element with any number of child elements within it would first register the touch event. If the parent element does not use the touch event, it would be passed down to its’ children and so on. In order to get the hitbox solution to work, the application uses the top parent view in order to get the position of a touch event and compare to the list of hitboxes. This would consume the touch event and not allow it to be transferred 45 down the tree of child elements. Because of this, any child element which has some functionality which is performed on a touch event could not be performed, e.g., a button which opens up a new activity. The solution to this problem was to intercept the implemented methods used by android and re-write what should happen, in this case, highlight or select. The same solution to intercept and re-write the executed code was used for scrolling in lists, which is implemented as a single finger touch event but was changed to two fingers, as one finger is used in the concept to select and explore. A third problem, which could not efficiently be fixed is the selection of an element. The concept utilizes the idea of a tactile click, much like a mouse button, to select an element. However, this is not possible on a touchscreen. Some initial effort was used to create a solution for this, e.g., connecting a Bluetooth mousepad which the phone could then be placed on and pushed down to register a click, but the phone was too heavy which meant the mousepad could not return to a clickable state. Due to time constraints and the fact that the rest of the application had to be programmed, the decision was made to not implement a solution to this problem at this point. Lastly, the final problem was how to implement handwriting into the prototype. Some research into how a self-made solution could be created was conducted, but ultimately, this was considered to time consuming to do. As a solution, a third party alternative was used, namely Google Handwriting Input. Although the alternative was not optimal, e.g., the handwriting input area only covered half the screen, it was deemed good enough since the goal of the prototype was the overall interaction with the system and to test this interaction. In the end, a functional Android application was created, utilizing the gesture based system of interaction developed in previous parts of this iteration and previous iterations. The application only implements the messaging activity. The reason behind this was that the the actual means of interaction, navigation, selection, and so on, does not change between different activities. Another reason for this was that the goal of the application was not to test out the information architecture but rather how a user interacts with it. Figure 4.9 shows the prototype being used while also being mirrored from one tablet to another. 46 Figure 4.9: The Android prototype being mirror between two tablets. 4.4.8 User Testing The user tests were divided into two different areas. One test aiming to give insights about the information architecture using the prototype made in Figma. The other test was more focused on the interactions with the system, and made use of the Android prototype and a driving simulator. Information Architecture Test The goal with this test, labeled "Test number 1", was to test the usability of our solution and its effectiveness and efficiency. We wanted to see if the users could efficiently navigate and understand the different parts of the system. In order to do this, we used the SUS method, as well as observations, SEQ, measured the CR, TTD and TBE. Before starting the tests, we aimed to gather 10 users to test with. In order to find testers, we mostly asked people working at Semcon if they wanted to participate in our test. Finding just 10 people was quite easy as the required time commitment was low for each user, as we found from our internal pilot testing the actual test would 47 take around 15 minutes to complete. The test setup consisted of one laptop, with the interactive wireframes that we created earlier being opened, an Apple Magic Trackpad connected to the laptop via bluetooth, and paper cutouts of the physical buttons meant to represent the buttons that are included with our touchpad. As the test begins, the user is given a brief explanation of the objective of our project, and an explanation of what the test will entail. The user then filled out a demographic survey where the objective is for us to be able to see how different demographics might respond to our system. After filling out the survey, the user had a few minutes to get familiar with the system before we began any actual testing. After the user had tried the system by navigating through the different parts and menus, we asked the user to return to the home screen, so that we could begin giving the tasks and writing down any observations we made, as well as carefully recording the time for each task. The tasks we asked them to perform were: 1. Open and read the text message history with your mother. 2. Write and send a text message to your mother. 3. Open and read the text message history with Kalle Eriksson. 4. Open and read the text message history with Adam Adamsson. 5. Call the number 0733456789. 6. Open the email conversation with Mattias Isaksson. 7. Open the latest email from Mattias Isaksson. 8. Send a reply to Mattias Isaksson. 9. Send an email to email@company.com. 10. Read a social media time line. 11. Open and read the latest post in your social feed. 12. Give the same post a like. 13. Open and read the latest comment to the same post. 14. Write a reply to the comment. The user would start by reading the task out lo