We Need Non-formal Methods Based on Formal Models in Interaction Design
According to our experience, early collaboration with non-expert stakeholders aimed at designing interaction in a user-centered way is mandatory if the goal is a great user experience. We have found that insistence on formal modeling when collaborating with non-experts leads to insufficient results. Therefore, we propose a user-centered approach in order to enable collaboration and communication among expert and non-expert stakeholders. This non-formal approach should be based on a formal model, which also builds the common ground for discussions between all involved project stakeholders.
KeywordsUsage Type Interaction Design Elementary Interaction Requirement Elicitation Output Interface
Well-designed and usable human-computer interaction (HCI) is a key factor for successful software products. Offering a large number of features is no longer sufficient for achieving success on the market. We observe stronger interest in usability and user experience factors in the decisions people make regarding particular products in the same class of devices (e.g. iPhone vs. other smartphones, iPod vs. other MP3 players). Users expect good usability and want to enjoy a great experience when interacting with the system. But what makes an interaction a great experience? What are the elements of a great HCI? Which dependencies exist between these elements? How do we design such an interaction? These are the questions we want to answer in order to improve the results of interaction design and contribute value to the HCI community. To do so, we developed a formal interaction model, which shows the most important elements of HCI and their dependencies. This model is called MAInEEAC (Model for Accurate Interaction Engineering, Enhancement, Alteration, and Characterization) and is introduced briefly in Sect. 2. Since we are aware of the fact that a model is not applicable to conversations between expert stakeholders and non-expert stakeholders, we also created and use the non-formal interaction design method mConcAppt, which is built on MAInEEAC and tailors HCI elements to the given context in which an HCI is designed. During this article, we refer to experts as experts in terms of software development. After the description of MAInEEAC, we describe our interaction design method in Sect. 3. Section 4 sums up the advantages of our approach. The article closes with a conclusion and an outlook on future work.
1.2 Our Model-Based Interaction Design Approach
In contrast to purely formal model-based approaches or the strict performance of formal methods, we apply a user-centered design approach , which combines the advantages of both formal models and non-formal methods. In this approach, we involve non-expert stakeholders as early as possible, since only potential operators of the system under development know what constitutes a great experience in their context. When non-expert stakeholders are involved, experts use formal models to work effectively and efficiently: Every expert has a formal conceptual model of the target system in mind when designing an interaction , in this case a formal model for interaction design. With the help of this model, the experts are aware of every element of HCI and every dependency between elements. In conversations with non-expert stakeholders, the experts are able to ask for all relevant information regarding HCI, trace the development of the HCI, and find conflicting specifications immediately by matching the conceptual model to the non-expert stakeholders mental models of the system [ibid.]. To prevent non-expert stakeholders from being confused, the expert does not show the formal model to them, but only uses it as preparation and for post-processing. With the formal model in mind, the experts can describe a particular HCI on a very detailed level. They can easily show interaction elements and dependencies, can facilitate communication between stakeholders involved in the development process, and close the gap between interaction designers and end users. The non-formal method is used for eliciting, analyzing, and specifying requirements, prototyping HCI according to the elements given by the formal model, and validating the interaction design.
2 MAInEEAC - A Model for Interaction Engineering, Enhancement, Alteration, and Characterization
2.1 General Overview
2.2 System View
2.3 Human Action View
2.4 System Action View
The System Action view (see Fig. 4) describes the way the System reacts to the Human Action and the transmission of information from the System to the Human. The System Action is a composition of Direct Input Feedback, Indirect Input Feedback, Application Feedback, and System Function. Direct Input Feedback is feedback the Human gets directly from the Input Interface, i.e., not via any Medium. Example: the physical resistance of a keyboard stroke or the sound when pressing a key on a keyboard or a PC mouse. In contrast to this, Indirect Input Feedback is input feedback the Human gets via a Medium as a reaction to his usage of an Input Interface. It is the System Action on a humans action to confirm the systems correct understanding of that action. Indirect Input Feedback is always based on a System Function and can be influenced by a designer. Examples: bordering of an icon that the mouse cursor points to or highlighting of a selected menu entry. A System Function is a System Action that is performed automatically by the System as a reaction to an external trigger. An external trigger may be, for example, a Human Action, a call from an external system, or an environmental context change. A System Function does not necessarily address a Human directly, but recognizes events, interprets and manipulates data, and plans and initiates Application Feedback and Indirect Input Feedback. A System Function cannot be influenced by an interaction designer. Examples: an internal change in the system state, working hard disk drives, control of external but system-related objects (e.g., lights). From an interaction-centered point of view, a System Action is given when at least one Application Feedback exists. Furthermore, an arbitrary number of the other elements can be included. The rationale for this composition is that Application Feedback directly refers to the humans Intention. Without feedback to the Intention, we are not able to fulfill an Elementary Interaction. For example, if a user performs an action on a user interface and only receives the feedback that his input was successful, we do not refer to this as an Elementary Interaction. The user always has to perceive the part of the System Action that belongs to his Intention in order to complete an Elementary Interaction. This part is the Application Feedback. Depending on the Environmental Context in which the System Action takes place, the System Action might be influenced by that context. For example, the System Action might be to transmit information to the Human by means other than sound when the environment is noisy, or to show relevant information to a particular person when it detects that that person is near. The System Action triggers a humans Perception, which is composed according to the System Action. Because of this segmentation, we can trace which Perception is triggered by which kind of System Action. For each kind of Perception, a Modality Type is specified that determines if the Perception is unimodal or multimodal. Unimodal perception is given when exactly one Modality is used to perceive the part of the System Action. In multimodal perception, at least two different Modalities are used. In addition to that, for Indirect Input Feedback Perception and Application Feedback Perception, a Medium Type is specified that determines if the Perception is unimedial or multimedial. This is necessary for those two types because they are the only ones that are transmitted via a Medium. If one Medium is used for transmission, the medium type is unimedial; if at least two different Media are used, the medium type is multimedial.
2.5 Interaction View
2.6 Elementary Interaction View
The Elementary interaction view (see Fig. 6) describes the composition of an Elementary Interaction and its specializations in detail. Furthermore, it is shown how an Elementary Interaction is constructed. Elementary Interactions are restricted to exactly one Human Action and one to many System Actions. Example: Typing text into a word processing application (Human Action) and perceiving the written text on a screen in order to check the correct spelling (text output as System Action). An Elementary Interaction always has three types, which specify how the Elementary Interaction takes place in detail. First, the Method Type specifies if the Elementary Interaction is unimethodical or multimethodical. A unimethodical Elementary Interaction is an Elementary Interaction where the Human Action is unimethodical. A simple example is pressing a key on the keyboard in order to select a list item and visually perceiving the selected item. The attribute that is relevant for determining the Method Type derives directly from the Human Action; i.e., a unimethodical action remains unimethodical on the Elementary Interaction level, a multimethodical action remains multimethodical. Of course, in this simple example we have just one Action Method, namely pressing a key. A multimethodical Elementary Interaction is an Elementary Interaction where the Human Action is multimethodical. A simple example is pointing with a finger to an icon and saying open that and visually perceiving the opening application. In this example, two different action methods are used in parallel during the action, namely Gesturing and Speaking. Therefore, the Elementary Interaction is multimethodical. Second, the Modality Type specifies if the Elementary Interaction is unimodal or multimodal. A unimodal Elementary Interaction is an Elementary Interaction where Perception is unimodal. An example is requesting information from a speech dialog system on the phone and aurally perceiving the answers. A multimodal Elementary Interaction is an Elementary Interaction, where the Perception is multimodal. An example is requesting information from a speech dialog system on the PC and aurally as well as visually perceiving the answers. To determine the modality types, all Perceptions are subsumed and it does not matter which kind of Perception the modality derives from. Third, the Medium Type specifies if the Elementary Interaction is unimedial or multimedial. A unimedial Elementary Interaction is an Elementary Interaction where the Perception is unimedial. An example is using a command-based input shell (as in UNIX), perceiving only alphanumerical text. A multimedial Elementary Interaction is an Elementary Interaction where the Perception is multimedial. An example is using a GUI-based operating system (like Microsoft Windows) and perceiving alphanumerical text, graphics, animations, and icons during one single elementary interaction. To determine the Medium Type, each medium involved in Indirect Input Feedback Perception and Application Feedback Perception is considered. An Elementary Interaction always has to be characterized through the triple method type, modality type, medium type. For example, the Elementary Interaction of clicking the recycle bin icon on a MS Windows desktop to open the context menu is multimethodical (moving an object and pressing an object), unimodal (visual perception of the moving mouse cursor and the opening context menu), and multimedial (representation of information via the icon, text, and graphics within the context menu). An Elementary Interaction specified by only one or two of these types does not exist from our point of view.
3 A Non-formal Method Based on MAInEEAC
When collaborating with non-expert stakeholders in order to define an interaction concept for a particular software system, MAInEEAC as a formal model is not applicable in its original condition. Therefore, we have developed non-formal methods based on this formal model to facilitate this collaboration. After having accomplished a huge number of software engineering projects with interaction design activities, we have found that these methods, where stakeholders can speak freely, lead to more relevant information than strict formal and restricted approaches. One of these methods is the mConcAppt method [2, 3, 5], which is a method for the user-centered conception of mobile business apps. In this chapter, we focus on the part of mConcAppt that is relevant for the construction of the HCI.
3.1 Upfront Requirements Elicitation and Analysis
List of involved stakeholders
Description of a user persona 
Description of the as-is situation
Problems in the as-is situation
Description of the to-be situation
Exchanged domain data
3.2 Iterative Interaction Design
4 Advantages of Our Approach
The application of the approach we propose in this chapter bears a number of advantages: Non-expert stakeholders are not forced to worry about formal models, since expert stakeholders do not discuss formal models with non-expert stakeholders, but rather prepare their conversations with the help of the model. Due to the unrestricted and non-formal conversations, all stakeholders can speak freely and more relevant information is gathered than with strict formal and restricted approaches like workshops and interviews. During the conversation, the expert stakeholders know which information is missing and can describe and discuss the impact of decisions made collaboratively. But it is still the interaction designer who creates the final interaction design and the developer who implements the interaction. Benefits of our approach can also be found within the groups of expert stakeholders and non-expert stakeholders, where communications are facilitated, since a single model with a single terminology can be used. When single group members are familiar with or used to another terminology, both terminologies can be mapped very easily. Besides requirements engineers, interaction designers, and developers, visual designers, architects, business analysts, customers, and end-users will also benefit from this facilitation of communication. The requirements elicited, analyzed, and specified by these communications while applying the non-formal method can be traced to concrete interactions and their highly detailed elements. While the formal model represents the elements, the non-formal method assures traceability.
From our point of view, early collaboration with non-expert stakeholders is mandatory. This is done best by applying non-formal methods based on formal models. Insisting on formal modeling when collaborating with non-expert stakeholders leads to insufficient results, since non-expert stakeholders have to familiarize themselves with unusual formal models and unusual formal thinking instead of focusing on considerations about needs, wishes, and demands in terms of HCI. In this article, we presented our user-centered design approach for an interaction design based on our non-formal method mConcAppt, which follows our formal model MAInEEAC. Due to the early involvement of non-expert stakeholders, the software development process can be shortened and thus could be applied to a wide range of software development projects, especially to projects using an agile development approach. Such agile development approaches are often applied to mobile business applications, for example, which need a lightweight user-centered approach because of their special challenges. Formal approaches do not satisfy this requirement sufficiently. The approach can be applied to a large number of domains due to its flexibility and the formal structure in the background. The approach presented (MAInEEAC, mConcAppt and their interrelation) is based on best practices resulting from many projects in which we have designed interaction in collaboration with non-expert stakeholders, and is even supposed to enable semi-experts to design a wellconceived HCI. An example of the application of the approach in an actual project can be found in . However, the approach is still evolving and work is in progress. We plan to integrate interaction-related aspects such as user experience and architecture in order to be able to cover a holistic view on HCI and to discuss all relevant aspects with non-expert stakeholders. We also believe that this approach is able to create new value through its capability to apply the co-creation practice. However, investigations of such effects by applying the approach were not conducted yet and remain an open issue to carry out as future work. Eventually, we hope to achieve a huge increase in interaction design quality with the help of our approach.
- 1.Cooper, A.: The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis, USA (1999)Google Scholar
- 2.Hess, S., Kiefer, F.: mConcAppt Methode - UX und Interaktionsdesign für mobile Business Apps in Usability Professionals Association, German Chapter: Usability Professionals 2012 Tagungsband. Konstanz (2012)Google Scholar
- 3.Hess, S., Kiefer, F.: Quality by construction through mConcAppt - toward using UI-construction as a driver for high quality mobile App engineering. In: QUATIC 2012 (2012)Google Scholar
- 4.Hess, S., Maier, A., Trapp, M.: Differentiating between successful and less successful products by using MAInEEAC - a model for interaction characterization. In: Jacko, J.A. (ed.) Human-Computer Interaction, Part I, HCII 2011. LNCS, vol. 6761, pp. 238–247. Springer, Heidelberg (2011)Google Scholar
- 5.Hess, S., Kiefer, F., Carbon, R., Maier, A.: mConcAppt - a method for the conception of mobile business applications. In: Uhler, D., Mehta, K., Wong, J.L. (eds.) MobiCASE 2012. LNICST, vol. 110, pp. 1–20. Springer, Heidelberg (2013)Google Scholar
- 6.International Organization for Standardization. ISO 9241–210:2010 - Ergonomics of human-system interaction - Part 210: Human-centred design for interactive systems (2010)Google Scholar
- 7.Norman, D.A.: Some observations on mental models. In: Gentner, D., Stevens, A.L. (eds.) Mental Models, pp. 7–14. Lawrence Erlbaum Associates Inc., Hillsdale (1983)Google Scholar
- 8.Norman, D.A.: The Design of Everyday Things. Doubleday, New York (1988)Google Scholar
- 9.Schomaker, L., Munch, S., Hartung, K.: A taxonomy of multimodal interaction in the human information processing system. Technical report, ESPRIT BRA, No. 8579 (1995)Google Scholar