Keywords

1 Introduction

In today’s world, the relevance and value of user experience (UX) design is more and more acknowledged. This is also true for industrial environments like Siemens. In industrial environments, one important UX quality is efficiency, the focus of this paper.

An interaction designer produces interaction design concepts, often in the form of wire frames and screen flows for Graphical User Interfaces (GUIs). Frequent questions are: How efficient is a proposed interaction design concept? How more efficient could the interaction design concept be? The questions are not only relevant for the interaction designer, but also for project stakeholders which like to know the quality of the presented UX work.

The question this paper attempts to answer is: How to determine a user experience efficiency benchmark? If such a user experience efficiency benchmark exists, it could be used to check the gap between the actual efficiency of an interaction design concept and such an efficiency benchmark.

This paper introduces GAIS (Goal - Assumption –Interaction Steps). The purpose of GAIS is to determine a user experience efficiency benchmark for a given use case which can be used to guide the design and the selection of interaction design concepts. GAIS has been successfully applied in several Siemens UX projects.

The paper is structured in the following way: In Sect. 2, GAIS is compared to GOMS. In Sect. 3, we discuss the efficiency benchmark dilemma. It motivates why an early efficiency benchmark is not a trivial endeavor. In Sect. 4, we explore the UX project context to explain when GAIS should be applied in a typical UX project. In Sect. 5, the GAIS approach will be presented, illustrated with several examples in Sect. 6 and lessons learned using GAIS in industrial projects. Section 7 concludes the use of GAIS and outlines future research and extension opportunities.

2 Related Work

GAIS is a distant relative of GOMS [1,2,3]. The purpose of GOMS (Goals, Operators, Methods, Selection rules) is to provide engineering models of human performance for human-computer interaction [1]. GOMS aims to optimize four criteria [4]:

  • C1 (a priori prediction) – a priori prediction of the human performance;

  • C2 (learnability and usability) – it can be used by computer system designers (not necessarily by psychologists or human factor experts).

  • C3 (coverage) – it covers a range of activities from perceptual-motor actions to complex activities to creative problem solving.

  • C4 (approximation) – it includes just the level of detail which is necessary for the design task. The purpose of using one of the GOMS derivates is to predict the human performance while interaction with a computer device.

The purpose of using one of the GOMS derivates is to predict the human performance while interaction with a computer device. GOMS breaks down the task hierarchy from goals to single interaction steps on several layers (goals and subgoals, operators, methods). GAIS has a different purpose, that of guiding rather than predicting efficiency. Instead of GOMS three aspect layers GAIS has two: Assumptions and Goals; and Interaction Steps. The reason for the simplicity is to consider only the necessary interaction steps in GAIS, and to ignore interaction steps which are the result of an interaction design process. GOMS considers such design decisions because it aims to make predictions about the outcome of the design process; GAIS does not considers such design decisions because it provides input for the design process and guides it. The design result may or may not follow identified GAIS options. GOMS is applied by computer system designers, GAIS is intended to be applied by human factor experts, psychologists, user experience designers, interaction designers etc., and not by technical experts.

3 Digitalization

3.1 UX System in a Digital Value Chain

A new megatrend Digitalization is “the use of digital technologies to change a business model and provide new revenue and value-producing opportunities” [6]. Two of the envisioned benefits of digitalization are speed and scale of processes [5, 7]. The focus of this papers is on speed. When we consider a human-in-the-loop, speed relates to how efficient a human can perform a task with the use of a machine.

The user is part of the digital value chain. A digital value chain is a process designed to create an outcome of value and which consists of digital tools, and users to create such an outcome. Typically, a user initiates the digital value chain. It is followed by automated steps which often require user involvement at some point. The result of involved users (user-machine interaction) and automated steps is an outcome of value (see Fig. 1).

Fig. 1.
figure 1

Digital value chain

Full size image

Digital value chains in industrial environments are supported by digital tools, such as engineering tools, dashboards, configuration tools, HMIs of industrial devices, field service applications, IT applications etc.

Often, the least efficient part of such a digital value chain is the human-machine interaction (here also called the “UX system”). The human is a human actor, directly or indirectly interacting with a machine to produce the outcome of value. The machine is a human-made artifact designed to support producing the outcome.

If the performance of such an interaction can be increased, the performance of the entire digital value chain increases. That’s the reason why the UX system is on the critical efficiency path of a digital value chain.

Therefore, it is worthwhile to design the UX system with efficiency in mind. Efficiency, of course, is not the only relevant UX quality criterion, but an important one (see [8, 9] for other UX quality criteria such as effectiveness, satisfaction, accessibility, safety, well-being, and sustainability).

3.2 Interaction Types of UX Systems

Since the efficiency of the UX system is on the critical efficiency path, it is worthwhile to look further into interaction type which have a direct relevance for efficiency levels of the UX system. Without references to existing research results, the author introduces three interaction types.

Manual: The user interacts manually with the machine. There is no, or a very low degree of, system support. The efficiency level of the UX system is low.

Semi-automated: The machine takes over some of the manual interaction steps and or the machine provides recommendations to users, so the user saves interaction steps. In this case, the user is still in the loop and makes the final decision. The efficiency of the UX system is medium.

Automated: The user does not interact at all with the machine. All activities are performed by the machine. The level of automation is maximized. This is the highest level of efficiency. The efficiency of the UX system is high.

The three interaction types and their differences are illustrated with an example for entering data into a form and using the data:

  • Manual: The user enters data manually into a form (Interaction step 1); the user reviews and submits the data (interaction step 2).

  • Semi-automated: The machine populated the data automatically into the form, based on past data entries (no user interaction). The user reviews the data and submits the data (interaction step 1).

  • Automated: The machine fetches automatically the data from past data usage (no interaction step) and submits the data automatically to where they are needed (no interaction step). The user is not involved at all.

All three interaction types are relative to the state-of-the-art of interaction technologies. What we consider “manual” interaction today might be “semi-automated” yesterday. Here is an example how to create a shape in a vector graphics tool: Today, we draw a shape with a mouse or pen. We would categorize this user task it as a “manual” interaction type. Before the first GUI-based system was invented, around 40 years ago, the user needed to define a shape by specifying its coordinates. At that time, the definition of a shape with coordinates would be considered “manual” interaction type and using a mouse (or a pen) and a GUI would be considered “semi-automated”.

When applying GAIS for a given use case, the question will arise whether a manual interaction type can be made more efficient by introducing a semi-automated or even an automated interaction type. A technical solution exists in many, but not in all cases for introducing a semi-automated or automated interaction types.

It is known that semi-automated and automated interaction types have their own challenges. Some of them are described in [10, 11]. GAIS does not consider those automation related challenges. They need to be considered and evaluated separately.

3.3 Research Question

The motivating question for this research effort was: How to determine a user experience efficiency benchmark? The efficiency benchmark is intended to be used to determine the actual efficiency of a drafted interaction design concept, and to determine the efficiency gap between the interaction design concept and the efficiency benchmark.

If such a method is expected to be accepted in an industrial environment, additional requirements apply:

  • R1 (Core): For a given use case, the method shall be used to determine a quantitative UX efficiency benchmark. Note: The requirement articulates the core outcome of the method which is the determination of a UX efficiency benchmark.

  • R2 (Independency): The method shall create an efficiency benchmark independent from the creation of an interaction design concept. Note: The method needs to be allocated to a step in the UX process prior to creation of interaction design concepts.

  • R3 (Scalability): The method shall be applied to larger UX elements (e.g. an entire UX framework) as well as to single UX elements (e.g. a single UI widget). Note: The method should not be constraint to a smaller (widget level) or larger (framework level) UX scope.

  • R4 (Modality): The method shall be applicable to different interaction modalities, or combinations of them, such as Direct Manipulation, Voice, Gesture. Note: This requirement addresses the trend that more and more UX solutions include more than one interaction modalities. Examples of interaction modalities are: Direct Manipulation (with GUIs), Voice User Interfaces, Gesture etc.

  • R5 (Effort): For a given use case, the method shall allow an interaction designer to create an efficiency benchmark in equal to or less than one working day. Note: The cost/benefit ratio needs to be reasonable to be applicable in industrial projects. “One working day” is an arbitrary, but reasonable upper limit for use in industrial projects.

  • R6 (Explainability): The method shall allow UX stakeholders to understand the efficiency benchmark and how to apply it. Note: The underlying assumption for this requirement is that a UX professional should be able to explain and defend a proposed UX solution. The method to determine a UX benchmark should therefore be explainable to UX stakeholders. (Subjective) feedback from UX stakeholders help to check whether this requirement is met.

This paper proposes GAIS as such a method. Before GAIS is introduced, additional information about the UX process performed at Siemens Corporate Technology is presented.

4 User Experience Background

4.1 User Experience Process

At Siemens Corporation, Corporate Technology (CT), we apply the user experience process, depicted in Fig. 2. The process consists of four phases.

Fig. 2.
figure 2

User experience process; the efficiency benchmark should be identified during the “Define” step and document as part of “UX Essence”

Full size image

Discover: In an initial “Value and Scope” phase, the UX team understands the business case of the product under design and how UX can support the business case. It also outlines the initial UX scope. Afterwards, the UX team gains an understanding about the involved user roles and their user profiles (e.g. use cases, user needs, user characteristics), the use environments (e.g. spatial, work flow, social), relevant good and bad practices and known constraints (i.e. business, technology, design, and regulatory).

Define: The insights are consolidated in a step called “UX Essence” which includes UX goals, optimization use cases, and UX quality and quantity criteria which are used to access explored interaction design concepts.

Ideate and Select: The UX teams create several interaction design concepts and assess them against the established UX quality and quantity criteria. If the UX criteria are not met, further interaction design concept options will be created. The UX team finally settles on an interaction design concept which ideally meets all the defined UX criteria.

Design and Refine: The UX teams refine the selected interaction design concept, adds missing details and creates the visual design. Users are involved to evaluate the designs. UX designers refine the design according user’s feedback.

Develop and Deploy: The UX teams creates optionally a specification or another kind of document as input for the front-end development and implements the front-end. The implementation can be a prototype or a product-quality front-end. The UX teams may evaluate the implemented prototype/front-end (e.g. with usability tests) and refines the design afterwards to address the findings.

Some additional explanations about the outlined UX process:

  1. 1.

    Representatives from identified user groups and project stakeholders (e.g. product manager which determines the business case and selects product features; project manager which keeps the project on track in terms of quality, time, and cost; front- and back-end developers which implement the UX and technical design) are involved in all phases, so close feedback loops are happening along the way. For instance, we prefer involvement of user reps on a weekly basis. If users have concerns, the process may go a step back, e.g. from “Ideate and Select” to “Learn and Define”, or from “Design and Refine” to “Ideate and Select”. These loops are not displayed in Fig. 2.

  2. 2.

    This UX process can be applied to an entire UX framework (e.g. an Engineering Tool) as well as to a single UX element (e.g. Find and Replace widget). For an entire UX framework, more time is necessary for each phase than when the process is applied to a single UX element.

  3. 3.

    This UX process can be applied to agile, waterfall, or hybrid (called “wagile”) product development approaches. It is critical that the first phases (“Discover”, “Define”, “Ideate and Select” and “Design and Refine”) are performed before the UX results are implemented.

Back to the efficiency topic: When should the UX efficiency benchmark be determined? Since the efficiency is determined for use cases, it can be applied only after the use cases are identified. This means it can only be applied after the “Discover” phase is completed. The efficiency benchmark should be used as input into the creation of interaction design concepts. Therefore, the benchmark should be determined before the “Ideate & Select” phase. Therefore, the appropriate phase is the “Define” phase (see highlight in the Fig. 2).

5 GAIS Method

5.1 Elements

The GAIS method uses the following structural elements: Goal, Assumptions, and Interaction Steps. The way to visualize the result of a GAIS analysis can vary. One way to visualize the structural elements of GAI it is shown in Fig. 3.

Fig. 3.
figure 3

GAIS elements

Full size image

Here a few explanations:

  • The GAIS method is applied to a single use case.

  • A goal is an intended state for a given use case.

  • Assumptions are an initial state before the identified interaction steps are performed to achieve the goal.

  • The identified interaction steps are the result of a cognitive task analysis for the given use case.

  • The identified interaction steps should consider necessary steps for the given use case, and they should not consider design decisions or design elements (e.g. select an item from a list). Otherwise, unnecessary design decision may over constraint the design space.

  • The identified interaction steps should consider design constraints. These are steps which must be executed, due to business or regulatory constraints.

  • The interaction steps should consider the interaction nature of the selected modality or modalities.

  • The granularity of interaction steps per GAIS analysis can vary. For instance, for a low-level use case (e.g. identify payment information), the GAIS interaction steps can relate to single mouse clicks (for a direct manipulation interaction modality); for a high-level use case (e.g. order a product), the interaction steps may relate to a sequence of mouse clicks. It is assumed that a single GAIS analysis identifies a similar granularity level for the identified interaction steps for a given use case.

5.2 Measurement Units

It is useful to introduce some language which explains how efficient an interaction design concept is, compared to the determined efficiency benchmark. The envisioned number of interaction steps for a use case is called the “Benchmark Interaction Steps” (abbreviated “BIS”). The “Actual Interaction Steps” (abbreviated “AIS”) is determined by counting the actual number of interaction steps of an interaction design concept to perform a given use case.

To determine the efficiency category of an interaction design concept, we use the following terminology:

  • If AIS > BIS: the interaction design concept is called “inefficient”

  • If AIS = BIS: the interaction design concept is called “efficient”

  • If AIS < BIS: the interaction design concept is called “super-efficient”

The BIS is determined during the “Define” phase, and the AIS is determined during the “Explore and Select” phase (see Fig. 2).

5.3 GAIS Process

The GAIS method is applied to a single use case. The GAIS process consists of four steps (see Fig. 4). For a given use case, the interaction designer identifies the goal (intended state) (step 1). In addition, the designer defines the assumptions, which are the pre-conditions or initial state before the user performs any interaction (step 2). Afterwards, the interaction designer outlines the interaction steps for a first GAIS option, typically the “manual” efficiency type (step 3). Afterwards, the interaction designers may identify a semi-automated interaction option and fully automated interaction option (step 4), where applicable. The interaction designer may iterate step 3 and 4 (Fig. 4).

Fig. 4.
figure 4

GAIS process

Full size image

To achieve efficiency improvements with a semi-automated or automated GAIS option, single interaction steps are assumed to be performed automatically by the machine. The result of that performance is added to the assumption box (see Fig. 5).

Fig. 5.
figure 5

GAIS process; results of interaction steps are added to assumptions.

Full size image

Afterwards, the interaction designer can make notes of the BIS for each identified GAIS option by counting the number of interaction steps. When creating an interaction design concept, the designer can then compare the different BIS with the AIS of the actual interaction design concept and can iterate the interaction design concept until the AIS is equal to or even better than the BIS. Let’s look at some examples.

6 Examples

6.1 Example 1: Order a Product

The first example illustrates how GAIS can be used to check whether an existing design is inefficient, efficient or super-efficient. We picked an everyday use case “Order a product”. Three different BISs are depicted in Fig. 6.

Fig. 6.
figure 6

GAIS, applied to use case “Order a product”

Full size image

For all three GAIS options, it is assumed that the product is already selected (as stated in the Assumption box). Option 1 shows the manual option. It reflects that a user identifies the payment method (interaction step 1), the shipping address (interaction step 2) and then places the order (interaction step 3). The BIS is therefore 3.

For the use case “Order a product”, the manual interaction can be optimized by considering a semi-automated approach which is shown in option 2. Since the order process is often applied many times, the optimization applies to the identification of the payment and shipping information. The efficiency optimization semi-automates the use of the payment und shipping information. Every time the user wants to order a product, the order and shipping information is automatically fetched, so the user does not have to enter it manually. This leads to a changed assumption: product selected, payment information identified, shipping information identified. The only step the user must perform is to order the product. The BIS went down from 3 steps (option 1) to 1 step (option 2).

Option 3 is further optimized the use case by identifying a fully automated option. In this case, even placing the order is automated. This might be useful if a user knows that s/he needs to order a certain product frequently. In such a case, automating the process might be more convenient than a manual order. This is reflected in option 3. The payment method and the delivery address are identified, including an order schedule. The product will automatically be ordered and shipped following the defined order schedule. The BIS went down from 1 (option 2) to 0 (option 3).

This example reflects what Amazon™ has implemented. Option 1 reflects ordering a product manually, by manually entering the payment method and the shipping information the first time (AIS: 3). Option 2 reflects the 1-Click™ order which Amazon™ has implemented and patented [12] (AIS: 1). Option 3 reflects Amazon’s™ subscription feature (AIS: 0). If we compare the three BISs with the AIS of Amazon’s™ implementation, then the Amazon™ implementation is “GAIS efficient” in all three cases.

Amazon’s™ Dash Button™ is very interesting. It selects and orders a product with one interaction steps (AIS: 1), literally with one click. Option 2 assumes that a product is already selected. The selection of a product requires at least one interaction step. The Dash Button™ does both with one interaction step. Therefore, the Dash Button™ is “super-efficient”.

6.2 Example 2: Respond to an Alarm

The second example illustrates how GAIS can guide the design of an interaction design concept for an industrial example. The modality is GUI. The use case is that an operator responds to a received alert (Fig. 7).

Fig. 7.
figure 7

GAIS, applied to use case “Respond to alert”

Full size image

In this case is only one GAIS option with a BIS of 1 (see Fig. 7). The reason for the one step is a business constraint which does not allow to make it more efficient. In the UX project, different wire frame options with different Actual Interaction Steps (AIS) were created (see Fig. 8).

In the first GAIS option, the user receives a notification (interaction step 1). After the user selected the notification, the user is taken to a list of alerts. The user selects the alert on the top of the list (interaction step 2). The user is taken to a detailed view. The user reads the description of the alert and responds with populated options (interaction step 3). The AIS of option 1 is 3 (“Inefficient” because AIS > BIS).

In the second GAIS option, the information of the alert summary (in the alert list) is moved over to the notification. After the user has received the notification, the user selects the notification is taken directly to the alert description (interaction step 1). After the user has read the alert description, the user responds with populated options (interaction step 2). The AIS is option 2 is 2 (“inefficient” because AIS > BIS).

In the third GAIS option, the alert description and the populated options are displayed in the notification. The user reads the alert and response to it with populated options. The AIS of option 3 is 1 (“efficient” because AIS = BIS) (Fig. 8).

Fig. 8.
figure 8

Wire frame options for use case “Respond to alert”

Full size image

The example illustrates that the BIS, determined with the GAIS method, can guide the refinement of the interaction design concept to achieve systematically a higher efficiency. It also shows that the interaction designer when to stop making the interaction design concept more efficient. As this example, and the other examples illustrate, the BIS provides an objective measure for efficiency, however it is determined by the interaction designer and therefore subjective.

6.3 Example 3: Create an Engineering Artifact

A third example illustrates how GAIS can be applied to an engineering tool. The chosen use case is “Create engineering artifact”. The modality is GUI. The first GAIS option shows the creation of an engineering artifact, step by step. The BIS is n which equals the number of engineering elements added. The semi-automated option reduces it to one interaction step, under the assumption that reusable templates for such an engineering artifact are available (see Fig. 9).

Fig. 9.
figure 9

GAIS applied to use case “Create engineering artifact”

Full size image

The GAIS method can also be applied to the use case “Create engineering artifact template” with two options (see Fig. 10).

In option 1, the user creates the templates manually, and in option 2, the engineering tool automatically creates templates for established engineering artifacts for later reuse.

As shown in this example, the usefulness of GAIS lies in the systematic consideration of efficiency improvements, considering semi-automated and automated interaction types (Fig. 10).

Fig. 10.
figure 10

GAIS applied to use case “Create engineering artifact template”

Full size image

6.4 Example 4: Change Motor Speed

This example illustrates how different interaction modalities influence the BIS. In the third example, we compare how the speed of a motor can be changed with a Graphical User Interface (GUI) and a Voice User Interface (VUI).

The first GAIS option (see Fig. 11) shows two interaction steps for a GUI: Select a motor and set the speed of the motor (BIS: 2). The second GAIS option shows the same use case for a VUI. It has only one step because the user can utter in one sentence “Change the speed of motor 1 to 250 rpm”, and the VUI is assumed to understand both parameters [13]. This is often not possible with a GUI where interaction is typically serialized. Beside hands-free usage, the efficiency increase, compared to GUIs, is another advantage of VUIs. This increase is reflected in the BIS (=1) for option 2, compared to a BIS (=2) for option 1 (Fig. 11).

Fig. 11.
figure 11

GAIS applied to use case “Change motor speed” (GUI and VUI)

Full size image

6.5 Lessons Learned from Using GAIS

One question is to which use cases GAIS should be applied. GAIS can be applied to all use cases (the author does it) of an UX project, however if the reader wants to try it out, it is recommended to consider the following types of use cases:

  • High frequency use cases (the efficiency improvements have the biggest impact for high frequency use cases)

  • Urgency (these use cases do often not occur frequently, but when they occur, they are optimized for efficiency)

The highest efficiency improvements lie in finding semi-automated and automated interaction options. This means that additional functionality needs to be developed. If the semi-automated or automated options are preferred by users, the author encourages UX people to request the needed additional functionality. UX does not stop at the visualization layer.

The author also experienced that users sometimes do not want semi-automated or automated support because it takes away control from users. Loss of control needs to be taken seriously. Therefore, it is important to involve users when envisioning semi-automated or automated interaction options. Users should provide feedback whether they accept a proposed semi-automated or automated option, or not. If users are concerned about an automated option, try to understand the underlying concern. Sometimes, a settlement on a semi-automated option is agreeable, keeping users in the loop and let the user make the final decision. In general, user acceptance is more important than efficiency.

A designer applying GAIS may face the situation that the user preferences are split. If the development budget allows the implementation of several options, the designer may want to go for it. If development budget is only available for one option, you may pick the one which satisfy most of the critical users.

GAIS identifies an efficiency benchmark which is used as an objective measure. However, the determination of a GAIS option is the result of a cognitive task analysis, performed by a user experience designer and still subjective.

In this paper, the GAIS options are visualized with diagrams. Other ways to visualize the GAIS options are possible, e.g. as a bulleted list. It could look like this:

  • Assumption: Motors has initial speed

    • Interaction step 1: Identify motor

    • Interaction step 2: Identify speed

  • Goal: Motor speed has changed

A bulleted list is easier to create and maintain than a diagram. The diagram has advantages when it comes to comparing different GAIS options and recognizing their differences. The preferred way to visualize depends on the audience. The author used the diagram technique with a positive feedback from project stakeholders. They understood the intent of the method and the resulting BIS per GAIS option.

Another visualization option is to make explicit which interaction steps were added to assumptions. This can be done as illustrated in Fig. 5.

7 Conclusion

GAIS is a cognitive task analysis method which allows the UX designer to identify several interaction steps, the so-called benchmark interaction steps (BIS). The BIS is used to inform and guide the subsequent design of interaction design concepts. When creating an interaction design concept, the actual number of interaction steps (AIS) can be determined and compared to the BIS. If the number of actual interaction steps (AIS) for a given use case is larger than BIS, then the interaction designer has a hint to refine the interaction design concept. With GAIS, an interaction designer can make an interaction design concept systematically more efficient by comparing the AIS with the BIS and exploring semi-automated and automated interactions. By comparing the AIS with the BIS, the interaction designer knows how efficient an interaction design concept is.

The intent of GAIS is not to predict the efficiency or effort, like GOMS does, but to identify an efficiency benchmark. As shown in this paper, GAIS can be applied to different modalities, e.g. direct manipulation, voice or multimodal interfaces.

Let’s check whether GAIS complies with the six requirements:

  • R1 (Core): GAIS supports the determination of the number of interaction steps for a given use case, including different options. The number of interaction steps becomes the efficiency benchmark.

  • R2 (Independency): GAIS is applied during the “Define” phase which takes place before the interaction design concepts are created during the “Explore and Select” phase.

  • R3 (Scalability): This requirement refers to the scope of the use case. The use case can be very broad, so an entire UX framework is needed for the implementation and the determination of the AIS. Example 1 is such broad use case. The use case can also have a smaller scope and will be implemented by a single UX widget. Example 4 is such a use case. GAIS can be used for both cases.

  • R4 (Modality): GAIS is agnostic of interaction modalities. However, when applying GAIS, it should be made explicit which interaction modalities is used because the GAIS option can lead to a different BIS, depending on the selected modality. This was demonstrated with example 4 (VUI vs. GUI).

  • R5 (Effort): In our experience, when applying GAIS, it usually only takes a few minutes to find different options and determine the BISs.

  • R6 (Explainability): GAIS options, their BISs and the corresponding interaction design concepts with their AISs were presented in several projects to project stakeholders. They could easily follow the approach and the thought process. GAIS helps to make design decision explainable and defendable.

Our conclusion is that GAIS complies with all six requirements.

GAIS has limitations, though. The GAIS method does not consider other user experience qualities, like learnability, safety, accessibility etc. In other words: the application of GAIS does not guarantee a usable design. That means, the interaction design, informed by a BIS, need to go through the normal, overall UX process, including a usability evaluation. This is particularly important when semi-automated or automated options are proposed. User acceptance is still more important than efficiency. In addition, GAIS does not consider effort for performing single interaction steps. This is kept out deliberately as a simplification. However, it is a potential area for extension. Finally, research is needed to extend the GAIS method to address other user experience qualities.