Deriving Personas to Inform HMI Design for Future Autonomous Taxis: A Case Study on User Requirement Elicitation

Abstract

Automated Vehicle Mobility-as-a-Service (AV MaaS)—or autonomous taxis—are expected to offer an inexpensive, mobility-on-demand service supporting greater sustainable transportation systems, including “last mile” solutions. However, to date, little is understood about how different people, whose needs and requirements may vary considerably, will best be supported to use these vehicles when there is no human driver/operative present to mediate or support them. Aiming to capture users’ experiences from existing taxi services and apply these in the context of an AV MaaS, we conducted a series of interviews with 35 taxi users, with different usability/accessibility needs. This was enriched by relevant literature. The information gathered from both activities informed the creation of eight unique “personas,” illustrating potential end users of the service, and thirteen unique “scenarios,” depicting and encompassing current taxi usage. The personas and scenarios were subsequently used to highlight potential human-machine interface (HMI) issues that need to be considered for a driverless mobility service, which then informed the development of key user requirements for HMI design and service type models. Specific user requirements were elicited and categorized using a requirements template. This paper presents an overview of personas and scenarios, and the process by which they were derived, and provides a case study of how key user requirements and service types were subsequently elicited from these persona-scenarios. The work is important to ensure that AV MaaSs successfully meet the as-yet unknown needs of end users and offer usability for all.

Keywords

Autonomous vehicles, Mobility-as-a-Service, HMI development, User requirements Engineering, Persona-Scenarios

Introduction

The Automated Vehicle Mobility-as-a-Service (AV MaaS) concept projects that a number of transport issues can be addressed in urban areas through the replacement of personal cars with a shared autonomous transit system. For instance, AV MaaS operations could better provide for the first/last mile to complement mass public transport, can facilitate and improve traffic flow, potentially remove the need for parking spaces in cities (Merat et al., 2017), and also further facilitate people with accessibility needs to access other modalities such as existing public transport (Krueger et al., 2016). The AV MaaS concept also addresses the need for more sustainable transport/travel, encouraging behavior shifting from conventional, single occupancy cars to shared electric MaaS vehicles. In their design of an agent-based model for shared and autonomous vehicle (SAV) operations, Fagnant and Kockelman (2014) stated, “Preliminary results indicate that each SAV (Shared Autonomous Vehicle) can replace around eleven conventional vehicles” (p. 1), without travelers experiencing unusual delays or wait times. The same authors also expect significant beneficial impacts on emissions because of SAVs. The expected personal impacts of AV MaaSs to users include greater opportunity for social engagements with others in the vehicle, a smoother and less demanding mental transition between home and work, extension of other activities (e.g., work, leisure), and smarter uses of resources to reduce demand on individuals (including running errands, sharing with others, vehicle driving itself to the next rental, etc.; Pettersson & Karlsson, 2015). Responses to an international survey by Wilson et al. (2020) suggested that respondents anticipate being able to participate in leisure activities, resting and sleeping, socializing, and “being productive” while traveling in such vehicles, activities which drivers of traditional vehicles are largely prohibited from engaging with at present.

Although much research effort has worked toward enabling the underlying autonomy of the vehicles and associated technologies, there is little established knowledge to answer questions of precisely how end users will be supported to use such services in the absence of a driver or another human operator to mediate or support them. Here we focus on the users of future AV MaaS services, examining how they may interact with such vehicles to not only use them successfully, but also to enjoy them and to fully realize the AV MaaS vision. Human-machine interfaces (HMIs) will play a vital role here, replacing the interactions between passenger and driver, yet much knowledge surrounding automotive HMI relates to how drivers can be supported to drive safely.

Purpose of the Study

Within the AV MaaS concept, end users will all be passengers—many of whom will have no driver training—and as such will not be expected to engage with any driving tasks. Thus, we consider how future HMIs will support users of these passenger-only services. Often the development of new or improved products is intended to address problems that people already experience in the present. However, the design of AV MaaS HMI needs to consider problems that have not yet been experienced because the product is not yet widely available, so questions relating to how potential end users will interact with such vehicles cannot be fully understood and answered until passengers start to use these services.

There are many user-centered design techniques available to designers to consider the needs of their intended end user in order to more precisely design their products toward the people who actually use them. Borglund and Öberg (2007) described the use of scenarios and their accompanying personas as a basis for decisions in domains in which the future use needs to be predicted, for example, developing future-proof information systems and assisting military decisions. In relation to HMI options for future cars, Kunur et al. (2015) highlighted the importance of the use of persona-scenarios (and other related “visual research” processes) specifically in designing inclusive HMI designs. They suggested that through considering the actions and motivations (etc.) of potential users of future vehicles, designers are facilitated to consider the as-yet-unknown needs of different kinds of users.

The purpose of the study then was to represent potential user-based needs and requirements for a service/technology domain that does not yet exist. One way of gaining an understanding how people might interact with these vehicles in the future is to examine how people use similar mobility services available today. It can be argued that taxi users gain some of the expected benefits of AV MaaSs, in that they are relieved of the task of driving and as such are free to conduct social or work based activities during the journey, they are afforded a semi-private environment for their journey (compared to, for example, a bus), they do not need to walk to or from a specific pick-up or drop-off location, and do not need to consider parking. As such, taxi users were considered to be a close match to the potential user of AV MaaS, with the obvious difference of the presence of a driver.

The approach documented herein is to examine the experiences of potential end users (those who currently use taxis) in order to consider their current needs and interactions and touchpoints with both the driver and the vehicle itself, in order to set out user requirements and service types for future AV MaaS HMI interactions in which a driver is not present. This is achieved using personas and scenarios (hereafter persona-scenarios) developed from interviews with people who use taxis regularly. A particular focus is on taxi users who have accessibility requirements and those who travel with dependents.

Persona-Scenarios

Persona-scenarios are a method of representing a comprehensive group of “real” users—their goals, motivations, attitudes, and so on (Schneidewind et al., 2012)—via an evidenced, yet fictitious, qualitative and/or quantitative description of each individual and their actions. They are commonly used in the early stages of design as a means of representing and communicating possible end users, describing their characteristics and how they might interact with a product or service, in order for designers to understand their needs and requirements (Schneidewind et al., 2012). Empathy with the potential end user can be built through the inclusion of a rich background, goals, and motivations along with a visual representation, and this empathy can facilitate the understanding of context of the potential users (Lopez-Lorca et al., 2014). They should be completed before the elicitation of requirements stage begins in the development process (Schneidewind et al., 2012). The approach was employed here as a means of illustrating the various characteristics, individual needs, and issues that potential end users might face through telling stories of a persona’s experience in using an existing mobility service. In doing so, the persona-scenarios could be synthesized into user requirements for a future, not yet widely available or understood AV MaaS.

Persona-scenarios can support the elicitation of requirements in a number of ways: supporting the identification of actors and scenarios, supporting the specification and prioritization of use cases, prioritizing the requirements, supporting a deeper understanding of requirements, supporting the comprehensible communication of requirements to stakeholders, supporting the validation of requirements, and supporting the tracing of requirements (Mayas et al., 2016). Furthermore, persona-scenarios can be used as a traceability tool to enable the identification of the origins of design ideas/concepts as a form of “design rationale” (Lopez-Lorca et al., 2014). Through supporting the entire requirements engineering process, the usability of the final product or service should be increased. Specifically for this study, in building an understanding of the entire taxi journey “taskscape” (Strickfaden & Langdon, 2018), user requirements for different tasks and sub-tasks can be identified, providing an evidenced basis for HMI design that can then be tested in order to build a set of AV MaaS HMI guidelines.

In this paper, we present a case study of the iterative development of qualitative persona-scenarios of taxi users and show how these were utilized to generate user requirements for an AV MaaS under development in the ServCity project[1]. This project is conducting a range of development activities to address the question of how AVs might become an everyday experience (for everyone?). The work described here was conducted during the beginning stages of the project in which potential users of the service and their experiences were sought to inform user requirements generation activities.

Background: Potential AV MaaS HMI Issues

As an example of one of the many HMI issues needing to be addressed is a consideration of how passengers might enter the vehicle. In trials run by Kim et al. (2019), the passenger’s entry to the vehicle first utilized a quick response (QR) code that passengers could scan during their walk-through; however, participants found this to be inconvenient, prompting a switch to the use of Near Field Communication (NFC). Although this technology enabled automatic door opening, passengers still found this inconvenient compared to situations in which the driver would open the door for the passenger. It would also rely on the user having NFC technology enabled on their smartphone (and be carrying a functioning smartphone). Interaction design participants in a study by Asha et al. (2020) suggested that an external HMI (eHMI) could provide an authentication interface to replace the need for keyed entry, with suggestions that this could be achieved through the user scanning a verification code with their smartphone (e.g., QR code) that could be located on the side (“wing”) mirror (though it remains unclear why an autonomous vehicle would require a side or rear-view mirror). Participants engaging with a prototype of this system thought that it could be useful in identifying the user’s particular vehicle. However, it was warned that the QR code system could be prone to errors or malfunction that would prevent a user’s entry.

The devices used in passenger interactions with the vehicle throughout the entire journey (e.g., on entry to the vehicle all the way through to payment and exit at the end) also needs careful consideration. It is possible that passengers will need differing levels of information and types of interaction at different stages of the journey. Participants who used a prototype Connected and Autonomous Vehicle (CAV) HMI valued future journey planning, information and entertainment, and a user profile facility as functionalities that they were most likely to use during a journey (Voinescu et al., 2018), with journey planning being the most important general function. Information and entertainment functions were also rated positively. However, it is also suggested that in some situations (e.g., while users are engaged in an activity such as reading or sleeping) users might require a more passive interface, which enables the continuous monitoring of traditional driving information if needed, but otherwise enabling this information to become salient only when needed (e.g., when re-routing; Pettersson & Karlsson, 2015). Also considering that users are likely to be using a variety of different personal devices, and some may not use a connected personal device at all, information will need to be communicated through varying devices/media, for example, smartphones and on-board devices/displays (Lundquist, 2018; Mirnig et al., 2019) in order to be usable by as many different types of users as possible.

The picture becomes further complicated when considering people with diverse needs and with accessibility concerns, as well as those who are traveling with dependents who may have particular needs. The “inclusive Human Machine Interface” (iHMI) approach (Kunur et al., 2015) assumes that an accessibility issue or impairment owes more to the characteristics of the environment, of the task, or the design of the interface, than the abilities (or disabilities) of the individual. Within this approach, any human user can be impaired as a result of capability limitation or from excessive cognitive, physical, or sensory (etc.) demands of the interface. Kunur et al. (2015) argued that an audit of “exclusion” is necessary for all tasks and sub-tasks of a goal (in this case, effectively utilizing an AV MaaS) to estimate the extent to which different kinds of users are likely to be prevented from achieving the goal as a result of the design of the technologies and service. However, Jeon et al. (2016) noted a lack of attention to certain types of end users within current knowledge, especially people with disabilities, older adults, and children. These groups have thus far been largely ignored in the development of AV technologies, and each of whom have particular needs and requirements that influence how they might interact with an AV MaaS vehicle and its associated technologies (e.g., app).

Clearly, passengers in AV MaaSs will need to have an accessible and inclusive means of communicating with the vehicle about a number of matters both inside and outside of the vehicle and during all stages of their journey. It is important to ensure that the services are as easy to use and enjoyable as possible from the outset in order to encourage a critical mass of people to adopt the services as part of their regular travel options. A detailed understanding of the needs and motivations of potential end users is an important step in the development of such services; however, there is as yet a lack of sufficient qualitative detail in existing literature. Specifically, an examination of real-life experiences of people using similar services was considered as one valuable means of identifying future requirements. As such, persona-scenarios based on interviews with a surrogate population exploring these (and more) HMI issues of a similar kind of service were conducted to begin to build this detailed understanding of potential future needs.

Methods

The methodology included several stages as represented in Figure 1.

Figure 1. Flowchart of methods in persona-scenario and user requirements generation.

User Interviews

In order to identify and examine user-based requirements for an AV MaaS that is not currently widely available (not available at all in the UK), users were selected from the closest representative groups, that is, users of existing taxis (including ride hailing services and Hackney cabs). It is reasonable to assume that many current needs and requirements of those who use such services would be directly transferable to a future AV MaaS.

Interviews were conducted with 35 taxi users. Initial interviews were conducted with people who use taxis regularly (1-2 times per month, pre-COVID-19 pandemic); however, to broaden the range of potential participants from a limited pool, we expanded this criterion to include people who have used taxis at least twice a year. We also included those who fit at least one of the following criteria:

• Those who were over the age of 60.
• Those who have an accessibility requirement that influences their usage of taxis (e.g., vision/hearing/other sensory impairment, physical disability, hidden disability, etc.).
• Those who regularly travel with a dependent (e.g., child/children, partner or friend who needs assistance because of their illness, frailty, disability, a mental health problem or an addiction, etc.).

These participants were recruited via invites sent to staff and students at the University of Nottingham’s Faculty of Engineering, as well as friends and family of these students/staff, and individuals from the Age Friendly Nottingham network and the University of the Third Age (U3A).

Participants first filled in a short questionnaire regarding their demographics and ratings of their regular travel choices and taxi usage, covering their most frequent types of transport used (e.g., bus, tram, private vehicle, as well as taxis), reasons for using this transport, and important factors in their decisions for using this transport (e.g., cost, accessibility, etc.). Once the eligibility criteria were broadened, new participants were also asked whether they had an accessibility need that influenced their decisions to use taxis (although specific details of the need were not required) and whether they regularly travel with a dependent. One participant did not return this questionnaire.

Participants attended an hour-long interview that involved a “critical incident” technique to examine both positive and negative taxi experiences. This interview required participants to recall one to two positive experiences and the same number of negative experiences they have had in taxis, and then required them to talk through the process of using a taxi from what they saw as the first stage of the journey process until the last stage. Participants were not initially guided with regards to what the stages might be, but were given keywords as examples (booking, waiting, pick up, and so on) if they had difficulty interpreting the question. Participants were prompted to think of any specific tasks that they would conduct at each stage, as well as any features of the booking system, vehicle, or behaviors of the driver (and so on) that either facilitated or hindered their ability to complete these tasks. As the data collection was carried out during the initial UK COVID-19 travel restrictions in spring-summer 2020, participants were asked to consider their experiences prior to this event as well as any experiences they may have had since the beginning of the pandemic.

Researchers made notes during the interviews, and audio recordings were made. Ethical approval was granted by the Faculty of Engineering’s Ethics Review Board, and all participants gave fully informed consent to participate in the research activities. Participants were reimbursed with a shopping voucher as compensation for their time. The age range and gender split of participants are presented in Figure 2.

Figure 2. Age and gender of participants.

Five of the participants reported that they had an accessibility issue that influences how they use taxis, and six reported that they regularly travel with a dependent. Although we sought participants with accessibility needs, recruitment wasn’t focused on a particular type of accessibility need. It was, however, considered particularly important to represent passengers with certain needs—such as visual impairments, those with aging related impairments, and wheelchair users—as it is reasoned that such impairments are likely to present difficulty for people accessing AV MaaS. To ensure representation of such users, relevant literature that discusses such matters was consulted (e.g., Brinkley et al., 2018; Davey, 2007; Pyer & Tucker, 2017; Schmöcker et al., 2008; Shergold et al., 2012). These papers were also used to enrich personas of those with specific needs where information was not available from the interviews.

Initial Persona-Scenario Writing

There are many ways that individuals can be classified, and characteristics of individuals can influence their behaviors and experiences of a product or service in different ways (Liu et al., 2010). The major characteristics selected for presenting the personas were those that were considered to have a direct impact on the way in which users would interact with current taxi/ride hailing services, as well as future AV MaaS. Characteristics were selected strategically to ensure that personas differed within the previously mentioned criteria, as well as portraying a variety of HMI related issues that may potentially present a challenge to an AV MaaS (and associated technologies) facility. It was the intention to introduce a variety of different tasks and points of interaction that each persona might encounter with the driver/vehicle and throughout a journey in order to consider an extensive (although not exhaustive) range of HMI issues that might arise from switching from a human-driven vehicle to an AV. Difficulties and challenges were purposefully included to provoke discussion and consideration of how an AV MaaS might cope with the dynamic and often novel/nuanced circumstances that humans face when interacting with a vehicle, an interface, or other people in such contexts. Each persona was given one or two scenarios in which they required the use of a taxi for a journey. In some cases, the circumstances were directly inspired by stories described by a particular interviewee (specific details were generalized to prevent the identification of any of the interview participants). In other cases, scenarios were formed from multiple and general descriptions of how the interviewees approached different aspects of a journey or of common issues that were mentioned.

Each persona included the following information as a minimum:

• Age
• Gender
• Access to technology (e.g., smartphone, laptop, landline, and so on)
• Top three modes of transport used
• Top three reasons for using taxis
• Level of technology acceptance
• Openness to experience
• Budget

Personas included further information from the following categories. However, only those items relevant to the specific persona, and the different information needs and challenges they faced, were presented to showcase these needs and challenges. In other words, not all the following items featured in all personas:

• Home/family situation (e.g., dependents)
• Details of home/workplace (e.g., access to public transport, type of accommodation)
• Accessibility needs
• Work/study/interests
• Public transport use/private car ownership/access
• Descriptions of their regular usage of taxis

Figure 3 depicts a template of the personas with descriptions of the kind of information included within.

Figure 3. Persona template.

During development of the persona-scenarios, a table was drawn up as a means of drafting. Each persona was allocated certain pieces of information taken from either the interview/questionnaire data and/or research papers, or novel information introduced for continuity and coherence. This stage was employed to avoid overlap or duplication of key characteristics and contexts.

The information allocated to each scenario was grounded within and generated from the interview data as well as accessibility literature where sufficient detail was missing in the interview data. In order to inform the more narrative aspects of the persona-scenarios, an initial hierarchical task analysis was conducted to map out each stage of the journey, from the decision to book a taxi through the payment and feedback stage at the end. This process identified common tasks that are employed at each stage in order to assist with the “storytelling” aspect of the scenarios (i.e., what happened when?). The high-level tasks are represented in the scenarios as the “key journey stages,” where the stages of particular relevance to the scenario are highlighted for each.

A thematic analysis approach was taken to introduce details to the scenario. Here, interview notes and recordings were scrutinized for common themes surrounding each stage (for example reasoning for using taxis over other modes of transport, feelings about each stage, specific needs, and so on). This approach enabled the identification of some key issues and differences that would be represented, for example, that some people automatically select a taxi as they have no other choice whereas some make the decision based on time restraints. Such key issues for each stage of the journey were then allocated to personas where there was a plausible fit with their background and journey purpose, for example, concerns surrounding drunken behavior were more appropriate for a person who regularly socializes with friends, while concerns surrounding the ability to work during the journey were more appropriate for someone who regularly uses taxis for business purposes. This process ensured that common themes from taxi users’ experiences were represented across the scenarios. In addition, where participants had discussed particularly challenging incidents or issues with direct relevance to future AV MaaS development, this information was also included in the most relevant scenario. In this way, both common themes were represented as well as unique insights into particularly challenging situations.

Scenarios therefore include a summary of the purpose behind the journey along with some decisions made by the user and a timeline describing the journey as it happens with quotes paraphrased from interview data to show how the persona is feeling about the events as they unfold. Scenarios also include a list of journey tasks in order of completion, with key tasks for the scenario highlighted for each journey. Figure 4 depicts a template of the scenarios with descriptions of the kinds of information included within.

Figure 4. Scenario template.

Descriptions of the fictional individuals and their journey(s) were then created using the custom templates depicted in Figure 3 and Figure 4. It is important to reiterate that the persona-scenarios were not based specifically on any single interview participant, rather a collective mix of characteristics identified from conducting a hierarchical task analysis and thematic analysis on the interview data, with insights taken from relevant literature, which were considered to best showcase certain issues of relevance to a future AV MaaS (for example, some personas do not carry/use smartphones which would present an issue to an entirely smartphone managed system). Slider scales were included as a visual means to portray aspects of the persona’s openness to experience, technology acceptance, and budget, which were thought to influence the user’s experience. The levels indicated by the slider scales were decided collectively among members of the research team based on characteristics that were thought to present a challenge for designers and as such were not based on collected data.

Consortium Workshop

The persona-scenarios were developed during the initial stages of the project. It was assumed that at this early stage the assumptions and motivations of each project partner would not yet be in perfect alignment with each other. For example, it was expected that the engineering team would not have a deep understanding of end users while the user-research team did not have a deep understanding of the possibilities and potential of the technologies under development. As such, personas were discussed with ServCity project consortium members who were involved in the project, predominantly made up of other researchers, engineers, software developers, and project managers. The overall goal of this process was to collectively consider the project aims and ensure that, firstly, the consortium would develop a shared understanding of the possible end users and, secondly, that the persona-scenarios were aligned with the potential of the technologies (e.g., that they did not highlight issues that were beyond the scope of the project). Draft versions of the persona-scenarios were presented to representatives from all consortium partners (composed of partners from automotive, digital, transport, and smart mobility industries) who were asked to provide structured feedback in workshop style discussions regarding the relevance of the personas/scenarios to them and the ServCity project more broadly. Consortium members were asked to comment on the persona-scenarios using the “I like,” “I wish,” and “What if” method as described by Dam and Siang (2020). Again, it should be noted that the persona-scenarios were being utilized as a discussion point to facilitate shared understandings, and as such, the aim was not to change the persona-scenarios in order to fit with the motivations of the stakeholders, but to ensure that the persona-scenarios represented the overall aims of the ServCity project.

Persona Refinement

Comments and suggestions from consortium members were noted and utilized in revisions of the persona-scenarios to ensure that the opinions of the consortium were also represented in these outputs. Feedback collected under the “I like” heading can be considered as those aspects that partners considered to be relevant and interesting to the project, for example, that one persona has a focus on safety concerns, that another persona likes to talk to a person when booking, that another persona prefers not to talk to the driver, or that another owns a range of interconnected technologies which would prompt consideration of booking methods. Some partners liked that one scenario highlighted the issue of booking return journeys and that another scenario demonstrated the difficulties of planning for the first and last mile for public transport planning. Such items, therefore, were preserved in the revised persona-scenarios.

The “I wish” heading prompted consideration of possible changes that could improve or clarify the persona-scenarios or enhance their relevance to the goals of the ServCity project. Points of interest to be taken into account within the revisions included that one persona needs to be able to identify her taxi in a congested city environment, that another might benefit from the provision of a universally adapted child-seat, that information relating to one persona’s attitude to driving were included, that another persona description should have more information relating to the protagonist rather than his daughter, that one persona could include information relating to a physical disability that would affect their usage of vehicles, and that another persona gave information relating to the timings/distances she travels in taxis. This heading also attracted comments relating to the possibilities of a future AV system, which could be included in “future scenarios” involving the personas.

Finally, the “what if” heading predominantly attracted feedback relating to the future possibilities and/or services to be provided by a future AV service, as well as potential details to include which might introduce new issues and complexities for consideration by designers/developers. Examples include the following: the possibility of one persona’s phone losing battery power after entering the vehicle, that there might be flight information provided en-route for another persona’s journey to the airport, that the vehicle might need recharging on a longer journey, that one persona could begin their meeting while still inside the vehicle, that the vehicle could show a map or plan of the hospital for another persona, and that there were “office” facilities in the vehicle (such as a laptop stand and power point for charging devices). This heading also attracted comments relating to the structure and content of the persona-scenarios in general.

This feedback was discussed within the research team and edits were made following an assessment of the suitability of the suggestions while still preserving the original user data. Information relating to future actions and activities (e.g., responses to the “what if?” prompts or anything specifically relating to an AV MaaS) was predominantly retained for use in further activities relating to future scenarios. This said, some more futuristic statements were incorporated into individual persona-scenarios, where appropriate, for example, introducing quotes to some of the personas to represent their feelings toward challenges identified at the consortium workshop. The remaining feedback, where feasible, was incorporated into the personas and scenarios by either editing the existing content or adding new content.

Consortium Validation

Following the refinement of the persona-scenarios, consortium members were again presented with the documents and asked for feedback regarding their relevance to the project, which aspects were in scope of the project’s outcomes, and whether more or less information was needed to adequately understand the end users. This feedback acted as a final validation process for the persona-scenarios, considering the priorities of the ServCity project, and also of the potential capabilities (and limitations) of the technologies being developed. One representative from each partner organization was involved in these discussions, which took the form of a focus group style session. Some minor edits were suggested but largely it was agreed that the persona-scenarios adequately illustrated to other ServCity partners a diversity of taxi users and corresponding usage in order to open discussions around how AV technologies might address a wide range of HMI needs and issues.

User Requirements Generation

To synthesize the persona-scenario information into usable user requirements, two workshops were held with researchers from the University of Nottingham team and project partners from SBD Automotive. During the workshops (held in a virtual reality environment owing to COVID-19 restrictions), the researchers considered the persona-scenarios in turn. Of particular focus were the characteristics and events described in the persona and their scenarios in which an interaction with taxi drivers or vehicles is mentioned. However, other factors were also of interest, for example, how accessibility issues or external (e.g., environmental, social, work based) factors influenced the decisions made by the persona, what communication technologies were available to the persona, the extent to which their budget or preferences might influence their actions, and so on. Such factors were considered for their implications for an AV MaaS system, considering the kinds of interaction methods that might be implied by the persona/scenario characteristics.

The process of deriving user requirements from the persona-scenarios was therefore a consideration of the persona’s tasks, values, and motivations (as described by Mayas et al., 2016); along with their goals, skills, attitudes, and so on (Schneidewind et al., 2012); and available resources in identifying specific needs for each journey stage. The persona-scenarios were scrutinized for any preferences or problems that personas might face in their interactions with drivers and vehicles, journey specifications that would require an interaction, abilities and capabilities of the personas (and conversely disabilities), and experiences with vehicles and drivers relevant to a potential HMI. A key strategy here was to consider the very specific issues described within the persona-scenarios and frame these issues as more generic user requirements that could be applicable to many different users. Each persona-scenario was discussed in turn, taking into account that they represent different individuals with different needs. The key journey stages identified and presented in the scenarios enabled consideration of what each persona would do at each stage, identifying multiple different (often conflicting) requirements for each part of a typical journey. As such discussions focused around how each persona might approach the task of using an AV MaaS service, similar to the “what would Barry do?” technique described by Faily and Fléchais (2010). For example, in considering the task of booking, the team considered how each persona would approach the task given their preferences and available technologies/services; those with access to a smartphone who were highly tech savvy would prefer an app-based system, whereas those without (reliable) access to a smartphone would consider other ways of booking. Table 1 shows some examples of the requirements that have been derived from the personas/scenarios in this way. The requirements were then displayed in a bespoke template inspired by the taxonomy provided by the Volere Requirements Specifications Template[2].

Service Type Modeling

Finally, project partners SBD Automotive sought to develop a set of tailored and branded AV MaaS services derived from the persona-scenario development work. Each service type model was designed to cater for specific user requirements found in certain persona groups. Four aspects for each potential service type were carefully considered including features, pricing model, business model, and overall operational style. These decisions and thoughts were also informed by benchmarking existing ride hailing apps and services including the likes of Waymo. Thought was given to a number of operational styles and the type of vehicle that might be used for each service.

Results

Here we present examples of the persona-scenarios and of the user requirements drawn from these.

Example Persona-Scenarios

In total, eight personas were developed with thirteen scenarios depicting fictional taxi users approaching the task of taking a taxi with varying levels of success. Figure 5 and Figure 6 below are two examples of personas, and Figure 7 and Figure 8 are two examples of scenarios created.

Figure 5. Example persona “Lena.” Photo by RODNAE Productions from Pexels.

Figure 6. Example persona Julien. Photo by ELEVATE from Pexels.

Figure 7. Example scenario “Ahmed: Catching a train.” Photo by Hannah Nelson from Pexels.

Figure 8. Example scenario “Mary: Going to Church.” Photo by Andrea Piacquadio from Pexels.

The personas represent a variety of different types of users with differing motivations and experiences. It is important to note that these were developed as a means of prompting discussions over HMI considerations and do not represent an exhaustive account of potential future users of AV MaaSs. One of the primary goals of producing the personas and scenarios was to facilitate examinations and discussions around how possible it will be for end users to interact with a possible AV vehicle/mobility service, and this goal was met through the consortium validation activities. The workshops in which these persona-scenarios were discussed prompted the consortium partners to consider how AV MaaSs can cater for different needs (encouraging speculation about how an AV MaaS could operate) or suggestions of particular functionalities.

Persona-Scenarios to User Requirements

Table 1 shows examples of HMI challenges identified in this process for two of the persona-scenarios, and some examples of user requirements derived from these issues.

Table 1. Examples of Main HMI Challenges and Derived User—Requirements for Two Personas and Their Scenario(s)

Persona	Main HMI challenges	Example user requirements
Mary	Mary doesn’t use a smartphone, instead she uses a landline at home and cannot make phone calls when out of the house.	Service should enable bookings and journey management using phone calls. Service should not rely on communications outside of the home/pick-up location.
	She has a hearing impairment, making it difficult for her to hear when there is background noise.	Audio-based interfaces should enable volume adjustment to suit hearing ability. Internal systems (entertainment etc.) should be adjustable to enable user to hear important communications.
	She prefers raised buttons to touchscreens.	Users should be given the option of keypad control of journey tasks.
	She is “slow” in getting into and out of vehicles.	Vehicle should wait for confirmation from user that they are ready for the journey; however, a reasonable time limit should be set to prevent misuse.
	She values the “personal touch,” such as being greeted by name or knowledge of her location/destination.	Interfaces should greet the user by name and confirm the destination details where it is sensible to do so; however, some situations may require that personal details are not communicated within hearing/sight distance of others in the vicinity/vehicle.
	She needs reassurance that the booking is confirmed.	Booking systems should be able to confirm that the booking has been made. Users should be provided with a means of checking the progress of the vehicle to their location, which can be accessed online or by phone. Alternatively, they could be given automatic updates.
	She needs the vehicle to alert her to its arrival at her location.	The vehicle should send an alert to the user when it has arrived at their destination, which is accessible online or by phone.
	Cleanliness is important.	Users should be provided with information relating to the cleanliness of the vehicle, for example, when it was last cleaned.
	She wants the service to wait for her while she completes her visit rather than booking separate services for the outward and return journeys.	Passengers should be able to request that the vehicle parks and waits for their return when they know that they will not take a long time to complete their task. Vehicle should provide reassurance that it will not leave until the user returns, with a maximum time limit to prevent misuse.
Lena	Lena has access to several devices that she travels with, especially when traveling for work.	Hand-held/passenger-based HMI systems should be usable on different devices.
	She needs her employer’s team to be able to interact with the vehicle/operator on her behalf.	The passenger does not need to be the person who books/manages/pays for the service.
	She must book work related travel through her employer’s booking system.	Operators could provide a business booking system that can be used by or on behalf of passengers.
	Lena had to hail a taxi at short notice because her employer’s booking system failed.	Passengers should be able to book a vehicle at short notice using different profiles, e.g., work profile that charges the employer rather than the individual.
	She would rather avoid social interaction when traveling to be able to concentrate on her work.	Passengers should be able to request a private (not shared) journey or request a “quiet” shared journey (i.e., matched with others who do not wish to talk).
	She values journey related updates in case of changes to route or timings.	When journey decisions need to be revised, the vehicle should present the user with information regarding the impacts on the journey.
	She wants to be able to pay via card.	Card payments should be possible.
	She has lost her phone and wants to retrieve it.	The vehicle should remind passengers to check for their belongings before exiting the vehicle. If people leave items behind, there should be a secure lost property service.
	She no longer has her phone with her, so she cannot make a booking by phone.	Service should be accessible by browser or telephone and avoid smartphone app-only systems. Service should not be reliant on the user using the same device throughout the journey process.
	She is concerned that she doesn’t know who will be sharing her journey.	Safety features should address the potential actions of others in a shared vehicle and prevent making others vulnerable.
	She needs help with managing the behavior of other passengers.	A facility for monitoring and management of passenger behavior should be employed.

This user requirements activity generated 61 individual user requirements relating to the HMI requirements that would help AV MaaS facilities match the existing needs of taxi users as showcased in the persona-scenarios. A prioritization process was conducted, in which requirements were categorized according to the MoSCoW framework (Clegg & Barker, 1994), labeling requirements according to what provisions must, should, or could be made, and finally what requirements passengers might want. The term “must have” is used to define fundamental requirements, without which the system will be unworkable and useless, that is, the minimum usable subset of requirements (an example is provided in Figure 9). The term “should have” indicates requirements that would be essential if more time/resources were available but recognizes that the system will be useful and usable without them (an example is provided in Figure 10). The term “could have” indicates requirements that are of lesser importance and could therefore be more easily left out of the initial development cycle but could be included at some later stage. The term “want to have” indicates requirements that are desirable but would not be included in the initial development (an example is provided in Figure 11). In addition, each requirement is categorized as Functional or Non-Functional. Functional requirements are things the system has to do, while non-functional requirements are qualities the system has to have (e.g., appropriate look and feel, performance, security, usability metrics).

Figure 9. Example of a “must have” user requirement.

Figure 10. Example of a “should have” user requirement.

Figure 11. Example of a “want to have” user requirement.

Service Type Models

The challenge for similar development projects is to keep such discussions in mind as the technologies are developed. One means of doing so is through considering the potential business models that might be prompted by the differing types of users depicted within the persona-scenarios. Four service type models were proposed as detailed in Table 2.

Table 2. Service Type Models Derived from the Persona-Scenarios

Business model	Descriptors	Pricing model
An “Exec” model, in which small vehicles can be pre-booked via corporate administrators/accounts. Alternatively, for those users who need to book themselves but cannot use third party apps on business phones, the vehicle must be bookable via telephone or web. Holistic redundancy should ensure that if a user is not allowed to interact with the vehicle using a business smartphone, all features must be accessible via the in-vehicle interface (IVI). Tipping should be possible separate to the corporate account (in case a vehicle has a teleoperator who remotely assists riders, for example).		Corporate subscription account charged monthly. Individual payment method that is contactless (for users who cannot use apps on work devices).
A “Fun” model, in which medium/large vehicles would typically operate in and around urban areas, especially nightlife areas in the evenings. Alternatively, vehicles would be on hand to ferry school children to and from school. A clear definition between these two use cases must be in place. Holistic redundancy should ensure that if a user’s phone runs out of mobile data or the user decides not to interact using a smartphone, all features can be accessed via IVI. Advanced pre-book should be possible, but also rapid pick up, e.g., outside of night clubs, shopping centers, etc.		Pay As You Go (PAYG) model to ensure flexibility in making extra stops or multiple trips. Must be easy to split payment multiple ways on the go with other passengers.
An “Access” model, in which medium/large/extra-large vehicles must have the ability to provide easy ingress and egress for a wide range of disabled users including wheelchairs. Vehicles should be able to pick up and drop off door-to-door in exact locations to prevent extra walking for older or disabled users. Vehicles would receive extra monitoring and assistance due to the type of passenger traveling. Potentially a dedicated remote operator who can be contacted from within the vehicle will be in place. Vehicles would be able to wait outside of certain destinations to provide immediate return journeys, i.e., hospitals or care homes.		Be able to pre-pay via telephone or web. Pensioners receive reduced rate.
A “Together” model, in which large/extra-large vehicles would primarily serve business parks, transport hubs, and universities. These areas would be the most likely to produce situations where people may want to ride share to a common destination. Alternatively, the trip may consist of multiple drops. If multiple people want to share within a few hundred yards of each other, a common pick-up location should be agreed between all parties.		Ability to split the bill between strangers without excessive effort. Pricing would be cheaper and reflect the amount of people who are riding.

Depending on the intended users, the style of the service would ideally be different in meeting their specific needs and journey habits. The service style can involve any aspect of the user journey from how they book a trip to what size and type of vehicle arrives. A set of features both in cabin and exterior based tailored to the target customers’ needs have been considered. For example, for a business type service, next leg journey information should be available along with the ability to request quiet rides for users who want to continue working during the journey. Pricing and business model considerations were also addressed, reflecting on how these elements could change based on the service type. For example, for business use, a subscription model may be suitable for regular business trips. Alternatively, having the ability for an office travel administrator to book a taxi on an employee’s behalf needs to be considered.

Discussion and Conclusions

This paper has described the process of eliciting information from interviews with potential AV MaaS end users. These interviews informed fictitious (yet grounded in real data) persona-scenarios that have been synthesized into user requirements for AV MaaS HMIs, from which service type models could be created to suggest ways in which an AV MaaS could operate in the future. It presents a case study of a requirements engineering process for a future AV MaaS context and highlights some of the complexities that are likely to be involved in designing HMIs for such a system. Specifically, we have described a process for eliciting user requirements for a service that does not yet exist by conducting interviews and developing persona-scenarios about a surrogate population to predict future requirements.

In relation to future AV MaaS HMI user requirements, the volume of (in places contradictory) requirements produced by interrogating the persona-scenarios presents many challenges for those designing HMIs, along with the implication that different types of users may benefit from different single modes of interaction or from different combinations of interaction types for distinct journey stages. For example, “Lena’s” expectations of booking an AV MaaS would be one involving an employer-based app or system, potentially involving administrator input or control such that Lena would simply need to indicate her needs and then arrive at a designated pick-up area to enter the vehicle. Yet Mary’s expectations might be of a more user-controlled experience in which she would organize the entire journey in one phone-based interaction, relying on the vehicle to follow these pre-arranged instructions.

The idea that there may be justification for multiple types of HMI (indeed multiple types of service) is upheld by consideration of the priorities and needs of the user. For instance, the priorities of “Lena” are different to those of “Mary,” suggesting two distinct types of use case: one that is tied into a business, enabling journeys to be booked and paid for by an employer and featuring mobile office functionalities, and one in which the user is responsible for booking and customizing the journey to their individual needs. While Mary’s use case focuses more on the accessibility and customizability options available, and the extent to which the vehicle can accommodate her needs that may change between and within journeys. Thus, one question arising from an examination of only two persona-scenarios is to what extent should different vehicles/services incorporate specified HMIs for different use cases in order to better cater for specific populations? In other words, should the designers of a system only consider whether all vehicles should (or could) be equipped with all features for all users or only consider whether the design of all the vehicles’ HMIs should focus on a basic level of functionality/accessibility to cater to a more generalized population? If it’s the latter, the design approach would be adopting “must have” requirements while sacrificing “should have” or “want to have” requirements. Here, the creation of service type models directly from user-based information was intended to inform service providers and prompt consideration over the types of service, vehicle, and experience that should be offered.

Requirements engineering can be challenging owing to a number of factors, including poor representation or communication of user characteristics and needs, as well as the need for individual interpretations by members of the development team, which could be error prone (Schneidewind et al., 2012) and potentially biased by individual beliefs and attitudes. For instance, challenges lay in designing a service type model that met the very broad needs and potential use cases for certain personas. Some personas had viable needs and wants that not a single service by itself could offer. Anticipating a persona’s needs for a technology that isn’t deployed yet is hard enough, let alone trying to design features in service models that meet those needs. There was also a difficulty in trying to place personas into only one user category, when in reality users have an array of complex needs. The four service types described here reflect some key themes arising from interviews with different types of end users; a key question remains over whether a single vehicle and/or HMI can cater for all kinds of users or whether operators should focus on more use case specific options.

Persona-scenarios themselves have many drawbacks: Anvari et al. (2017) summarized the criticisms aimed at the technique that includes that they are abstract, may be misleading, open to misinterpretation, could be missing elements, and so on. We would add that there is a particular challenge in eliciting coherent user requirements using persona-scenarios when the final product has many difference facets, for example, internal HMI, external HMI, the vehicle itself, service level operations, and so on. Yet Schneidewind et al. (2012) argued that one of the benefits of personas is the common language descriptions used to highlight key information that makes them easy to understand and facilitate communications between members of the development team. It should be taken for granted that users have individual differences, and no one persona/scenario can represent all people who match their objective characteristics. Yet their uniqueness allows persona-scenarios to “humanize” design decisions, providing evidence for the reasoning behind certain design decisions, especially when designing for marginalized user groups (Faily & Fléchais, 2010), for example, disability groups, older people, and so on.

In spite of the drawbacks discussed here, we posit that persona-scenarios, and the underlying data gathering that contribute to their development, offer a flexible and unbiased means of generating user requirements and service type models, as they showcase the user’s context and goals before considering how these might contribute to their needs and interactions with future technologies (Mayas et al., 2016). In other words, it is better to examine the needs of users as they stand and then take steps to outline how the new technology can meet those needs than to ask people to imagine what their needs would be oriented toward the new, as-yet imaginary technology. Moreover, in revising and revisiting persona-scenarios, the emerging priorities of the project or individual teams can be reflected in addition to ensuring that the persona-scenarios, along with considerations of the user-based complexities and nuances, do not “fade and die” after initial interest wanes (Kirmani et al., 2019).

We have provided a description of how persona-scenarios have been used in the early development stages of a future technology-based service to identify user requirements and potential service type models in a context in which it can be assumed that users do not already have a clear idea of their needs and preferences for that service. One of the primary goals of producing the persona-scenarios was to facilitate examinations and discussions around how possible end users will interact with a possible AV vehicle/mobility service. This goal has been achieved through deriving a comprehensive set of user requirements in addition to beginning to model how services could function in the future. We have taken an “inclusive” approach, that is, not driven by a particular user/location, enabling outputs to be narrowed during further research and project activities. The challenge for ServCity, and indeed for any AV MaaS developer, is to keep such discussions in mind as the technologies and services are developed. The outputs presented here will be revisited throughout the ServCity project to update and expand them as necessary in light of new user-based information, while also incorporating any decisions made relating to the targeted user/use case of the ServCity technologies. It is also envisioned that the final persona-scenarios and service type models will be relevant and useful to stakeholders outside of the ServCity project who may be involved in the development of similar kinds of technologies and services. A key indicator of the success of these outputs will therefore be the extent to which they are useful and usable by those outside of the ServCity consortium as an illustration of a wide range of HMI issues.

Tips for Usability Practitioners

Reflecting on our experience of developing personas and scenarios, we offer the following tips for user researchers:

• There are many differing needs and preferences of users to be considered during the development of new HMIs, products, services, and so on; the views of a wide range of different types of end users should be considered from the beginning stages of development.
• It is recommended that the persona-scenario creation process is iterative, ensuring that the views and priorities of the developers (and other project partners) are recognized, and persona-scenarios can be revisited and revised depending on new decisions and emerging priorities of the project.
• Eliciting user requirements (which tend to be generic) directly from persona-scenarios (which tend to be specific) requires consideration of key challenges and usability issues that personas might face within the imagined future service, and re-framing these as potential service offerings.
• Considering unique attributes of persona-scenarios alongside more generalized user requirements can facilitate modeling of potential service types.

Acknowledgments

The authors thank their consortium partners Nissan, Connected Places Catapult, Hitachi, and TRL for their input into the persona-scenario creation.

The ServCity project is funded by UK Innovation Agency and Centre for Connected & Autonomous Vehicles, grant number 105091.

References

Anvari, F., Richards, D., Hitchens, M., Babar, M. A., Tran, H. M. T., & Busch, P. (2017). An empirical investigation of the influence of persona with personality traits on conceptual design. Journal of Systems and Software, 134, 324–339.

Asha, A. Z., Anzum, F., Finn, P., Sharlin, E., & Costa Sousa, M. (2020). Designing external automotive displays: VR prototypes and analysis [Paper presented]. 12th International Conference on Automotive User Interfaces and Interactive Vehicular Applications.

Borglund, E., & Öberg, L.-M. (2007). Scenario planning and personas as aid to reduce uncertainty of future users [Paper presented]. Proceedings of 30th Information Systems Research Seminar, Tampere, Finland.

Brinkley, J., Gilbert, J. E., & Daily, S. B. (2018). A survey of visually impaired consumers about self-driving vehicles [Paper presented]. 33rd Annual International Technology and Persons with Disabilities Conference Scientific/Research Proceedings, San Diego, CA, USA.

Clegg, D., & Barker, R. (1994). Case method fast-track: A RAD approach. Addison-Wesley Longman Publishing Co., Inc.

Dam, R. F., & Siang, T. Y. (2020). Test your prototypes: How to gather feedback and maximise learning. Interaction Design Foundation. https://public-media.interaction-design.org/pdf/I-Like-I-Wish-What-If.pdf

Davey, J. A. (2007). Older people and transport: Coping without a car. Ageing & Society, 27(1), 49–65.

Fagnant, D. J., & Kockelman, K. M. (2014). The travel and environmental implications of shared autonomous vehicles, using agent-based model scenarios. Transportation Research Part C: Emerging Technologies, 40, 1–13.

Faily, S., & Fléchais, I. (2010). Barry is not the weakest link: Eliciting secure system requirements with personas [Paper presented]. Proceedings of the 24th BCS Interaction Specialist Group Conference. Dundee, Scotland, United Kingdom.

Jeon, M., Politis, I., Shladover, S. E., Sutter, C., Terken, J. M. B., & Poppinga, B. (2016). Towards life-long mobility: Accessible transportation with automation [Paper presented]. Adjunct Proceedings of the 8th International Conference on Automotive User Interfaces and Interactive Vehicular Applications, Ann Arbor, MI, USA. https://dl.acm.org/doi/10.1145/3004323.3004348

Kim, S., Chang, J. J. E., Park, H. H., Song, S. U., Cha, C. B., Kim, J. W., & Kang, N. (2019). Autonomous taxi service design and user experience. International Journal of Human–Computer Interaction, 36(5), 429–448.

Kirmani, S., Gupta, B., Vansover, H., Arellano, J. G., & Zhu, Z. (2019). Designing with personas. Journal of Usability Studies, 15(1), 23–46.

Krueger, R., Rashidi, T. H., & Rose, J. M. (2016). Preferences for shared autonomous vehicles. Transportation Research Part C: Emerging Technologies, 69, 343­–355.

Kunur, M., Langdon, P., Bradley, M., Bichard, J.-A., Glazer, E., Doran, F., . . . Loeillet, J. J. (2015). Creating inclusive HMI concepts for future cars using visual scenario storyboards through design ethnography. In M. Antona & C. Stephanidis (Eds.), Universal access in human-computer interaction: Access to the human environment and culture [Lecture Notes in Computer Science, vol. 9178, pp. 139–149]. Springer, Cham. https://doi.org/10.1007/978-3-319-20687-5_14

Liu, Y., Osvalder, A.-L., & Karlsson, M. (2010). Considering the importance of user profiles in interface design. In R. Mátrai (Ed.), User interfaces. INTECH Open Access Publisher.

Lopez-Lorca, A. A., Miller, T., Pedell, S., Mendoza, A., Keirnan, A., & Sterling, L. (2014). One size doesn’t fit all: Diversifying “the user” using personas and emotional scenarios [Paper presented]. Proceedings of the 6th International Workshop on Social Software Engineering, Hong Kong, China.

Lundquist, M. (2018). Autonomous bus passenger experience. [Independent thesis Advanced level, professional degree]. Umeå University, Sweden.

Mayas, C., Hörold, S., & Krömker, H. (2016). Personas for requirements engineering. In A. Ebert, S. Humayoun, N. Seyff, A. Perini, & S. Barbosa (Eds.), Usability- and Accessibility-Focused Requirements Engineering [Lecture Notes in Computer Science, vol 9312, pp. 34–46]. Springer, Cham. https://doi.org/10.1007/978-3-319-45916-5_3

Merat, N., Madigan, R., & Nordhoff, S. (2017). Human factors, user requirements, and user acceptance of ride-sharing in automated vehicles [International Transport Forum, Discussion Paper No. 2017-10]. Paris, France: OECD. https://doi.org/10.1787/0d3ed522-en

Mirnig, A. G., Gärtner, M., Wallner, V., Trösterer, S., Meschtscherjakov, A., & Tscheligi, M. (2019). Where does it go? A study on visual on-screen designs for exit management in an automated shuttle bus [Paper presented]. Proceedings of the 11th International Conference on Automotive User Interfaces and Interactive Vehicular Applications, Utrecht, Netherlands.

Pettersson, I., & Karlsson, M. (2015). Setting the stage for autonomous cars: A pilot study of future autonomous driving experiences. IET intelligent transport systems, 9(7), 694–701.

Pyer, M., & Tucker, F. (2017). ‘With us, we, like, physically can’t’: Transport, mobility and the leisure experiences of teenage wheelchair users. Mobilities, 12(1), 36–52.

Schmöcker, J.-D., Quddus, M. A., Noland, R. B., & Bell, M. G. (2008). Mode choice of older and disabled people: A case study of shopping trips in London. Journal of Transport Geography, 16(4), 257–267.

Schneidewind, L., Hörold, S., Mayas, C., Krömker, H., Falke, S., & Pucklitsch, T. (2012). How personas support requirements engineering [Paper presented]. 2012 First International Workshop on Usability and Accessibility Focused Requirements Engineering (UsARE), Zurich, Switzerland.

Shergold, I., Parkhurst, G., & Musselwhite, C. (2012). Rural car dependence: An emerging barrier to community activity for older people. Transportation Planning and Technology, 35(1), 69–85.

Strickfaden, M., & Langdon, P. (2018). Improving design understanding of inclusivity in autonomous vehicles: A driver and passenger taskscape approach [Paper presented]. Cambridge Workshop on Universal Access and Assistive Technology.

Voinescu, A., Morgan, P. L., Alford, C., & Caleb-Solly, P. (2018). Investigating older adults’ preferences for functions within a human-machine interface designed for fully autonomous vehicles [Paper presented]. International Conference on Human Aspects of IT for the Aged Population, Las Vegas, NV, USA.

Wilson, C., Gyi, D., & Morris, A. (2020). Working at 70mph? Non-driving related tasks in future autonomous vehicles [Paper presented]. Contemporary Ergonomics and Human Factors 2020.

[1] https://www.servcity.co.uk/

[2] https://www.volere.org/templates/volere-requirements-specification-template/

Published in: in Volume 17, Issue 2,