1 Introduction

With the increasing proliferation of mobile technologies, computing’s traditional application areas have broadened and encompass a variety of mobile scenarios, such as m-commerce, mobile banking, and entertainment services (e.g., [1, 2]). Researchers often investigate consumer-oriented mobile services, but have paid less attention to mobile applications in organizational contexts. In this paper, we argue that mobile applications are particularly suited for supporting routines, i.e., repetitive patterns of activity that occur throughout an organization [3]. Since routines embed much organizational knowledge [4], they often rely on artifacts such as forms, checklists, written procedures, or rules [3, 5]. Mobile applications can replace or enhance traditional artifacts to improve the support for workers in the execution of routines. However, we are still lacking design guidelines for these applications. Prior studies mainly focus on user-centric design and adaptive mobile interfaces from the individual user’s perspective [6, 7]. They see user interactions mostly as a silo – able to help individual users perform better – but not embedded in an organizational context of a user group or company.

Since the performance of an organization is positively linked with the effectiveness of its organizational routines and its artifacts [8], we are interested in understanding: (1) What are the roles of mobile applications in organizational routines? (2) What are the design principles for mobile applications to support organizational routines? In view of our research goals, we analyzed two mobile applications that support domain experts in diverse contexts, automotive car dealerships and hospitals. Both are advanced and innovative examples of mobile applications that were created to support complex activity patterns and have been developed in close collaboration with end-users. From our involvement in the design process and collaborations with these applications’ developers, we were able to identify patterns as well as five design principles for mobile applications supporting organizational routines.

The remainder of this paper is structured as follows: First, we review the literature related to organizational routines and their representations as IT artifacts. We then present our research methodology. After presenting the two case studies, we synthesize our findings related to the roles and design principles. The paper ends with a summary of our findings and provides an outlook on future research.

2 Organizational Routines and the Role of Artifacts

Organizational routines are repetitive patterns of activity that are functionally similar, but are not fixed and do not constrain to follow a strict sequence [3]. They capture and codify individuals’ experience in order to increase knowledge transfer in an organization [9]. Organizations rely on different kinds of artifacts such as forms, checklists and written procedures to support the execution of organizational routines [10]. Interestingly, the roles of artifacts have evolved over time. In early contributions, artifacts were seen as an organization’s external memory with the aim of helping people to solve complex problems [3]. Later, artifacts were considered an enabler for the evolution, transfer, and replication of routines [11]. More recently, artifacts are seen as central to organizational routines and as actively enhancing individuals’ knowledge, skills, and competence [12]. With the democratization and evolution of technology, IT artifacts play an increasingly significant role in organizational routines. On the positive side, IT artifacts facilitate data sharing, enable tracking the progress of changes and swifter feedback exchange [13]. There are, however, also negative effects [12]: IT artifacts, specifically software applications, have their limits when it comes to adapting to individuals’ routines. In practice, their adaptations often require the involvement of dedicated resources. This often results in users adapting their behavior [14], sometimes at the expense of an organization’s performance and competitiveness. In short, organizational literature shows that artifacts play a strategic role in supporting and maintaining organizational routines. To date, researchers have focused on software applications as IT artifacts, but have not yet investigated mobile applications as an IT artifact in supporting organizational routines. However, mobile applications provide new opportunities for supporting routine work through their small touchscreens, gesture navigation, and integration of sensors [15, 16].

3 Methodology

Our research analyzes two mobile applications supporting complex activity patterns (see Table 1). Their goal is to support experts in two domains, customer service as well as healthcare, which are among the best representative domains for the use of mobile technology [17]. Our first case describes the Mobile Service Advisor (MSA), which guides mechanics in the interactive service reception routine in car dealerships. MSA is a mobile application developed by proaxia consulting group AG, a Swiss IT consulting company with expertise in innovative solutions for sales and service in the automotive and other technical industries. The mobile application has been co-developed with Autohaus Bald, a group of car dealerships in Germany with more than 20 000 customers, and is currently used by more than 20 of their mechanics in eight different locations. The second case describes the Legon Clinical Solution (LCS), a mobile application that guides physicians during routine patient care. This solution has been developed in collaboration between a rheumatology department of a Swiss cantonal hospital and Legon Informatik AG, a Swiss software company that specializes in the development of customized software solutions for healthcare. The LCS supports physicians’ particular way of practicing and is currently being tested by rheumatologists in their daily work. Both cases can be considered as innovative examples of mobile applications and have been recognized as such by experts: The MSA was awarded best mobile application in November 2012 by a primary software vendor for its innovativeness, functionality, usability, and customer feedback [18]. The LCS is considered by senior physicians to be one of the most advanced and innovative mobile applications used in Swiss hospitals.

Table 1. Factsheet case studies
Full size table

The authors were able to gain in-depth insights into the designs of these applications, since they were either part of or collaborated with these mobile applications’ development teams. We participated in discussions with future users as well as with software developers and graphic designers, collecting valuable insights towards understanding the user requirements and organizational contexts, as well as their implications on mobile application design decisions. Thus, we argue that such an approach is far more valuable to understand the roles and the designs of mobile applications than simply analyzing existing solutions available in mobile app stores.

4 Case Studies

4.1 Case I: Mobile Application for Service Reception in Car Dealerships

Background and Motivation. This case focuses on customer interactions in the early phases of car inspection in automotive dealerships. Traditionally, when customers bring their cars to the dealership for service maintenance, they give the car keys to a mechanic, exchange few words about problems that they detected or specific parts that must be repaired, then leave. This approach is increasingly replaced by the so-called interactive service reception (ISR), which seeks to guide mechanics in a more professional way and establishes a dialogue with customers towards better satisfaction. ISR intends to overcome two main shortcomings centered around the lack of systematic car inspection and the lack of interaction between mechanics and customers. Existing studies in the automotive industry demonstrate that without a consistent service reception routine, only one quarter of cars’ problems are detected and eventually repaired [19].

Many dealerships are currently introducing ISR by means of paper-based checklists as support to routines’ execution. Despite listing the primary activities of the ISR routine, paper-based checklists have many drawbacks: They require one to re-enter the manually collected information after the inspection in the dealership’s information system. Also, they do not prevent mechanics from looking for and copying a great deal of information related to a specific customer and vehicle, while they cannot adapt to specific situations (e.g., specific cars).

Mobile Application’s Roles. MSA’s primary role is to guide mechanics through the inspection process and to explicitly document the inspection results to ensure high work quality and full transparency for the customer. On the one hand, the mobile application can ‘force’ mechanics to perform specific activities – e.g., access current customer information to consider his or her wishes – before continuing the routine. On the other hand, the mobile application suggests a predefined sequence of activities, which mechanics can then decide to follow or not, depending on the context (e.g., interaction with a customer) and on their experience. With the MSA, mechanics have access to various kinds of information to successfully conduct the ISR routine, such as customer information and previous inspection outcomes, potential open points from previous inspections, and warranty and recall. This information is usually centralized in the dealership’s enterprise systems, but is not necessarily available for the mechanic during customer interactions. Finally, MSA supports the documentation of activities that are traditionally performed manually at the end of the routine, avoiding much administrative work and reducing potential errors that can occur during manual post hoc reporting.

User Interface Design and Interaction Flow. MSA’s storyboard consists of three main views: (1) Customer selection, (2) the current service order with access to detailed customer information and vehicle history, and (3) the detailed inspection checkpoints. Access to information is possible through the SAP Mobile Platform, which connects the mobile application and the dealership’s enterprise systems. This data is copied locally on the mobile device, while the synchronization occurs at the end of the routine to ensure data consistency. The first view contains a list of fields used as a filter to find customers and access previous inspections (see Fig. 1. #1). The second screen allows mechanics to update customer information and access a vehicle’s information and history and review the status of the current inspection. When previous inspections are opened, damages that were repaired are displayed. If it is a new inspection, the known customer wishes and issues are listed. The user interface contains a primary navigation element as a tab-based menu to access the third view (see Fig. 1. #2). A second navigation level, also as a tab-based menu, provides access to the closing activities, including notably the handover report and its customer validation (see Fig. 1. #3). The third view is dedicated to the car’s inspection. In this case the second navigation level describes the car’s different parts, following a physical structure [20] – the checkpoints are grouped based on their proximity e.g., inside, chassis, outside (see Fig. 1. #4). Each group’s activities are presented along with a checklist approach that allows for the quick and systematic documentation of each activity. It is described with a number to facilitate its identification, a short text to describe the checkpoints, a checkbox to indicate the state of the activity (i.e., not checked, checked and no damage, checked and damage), a text field that provides predefined entry sets related to each checkpoint if damage is observed, and a switch button to indicate if the customer wants to repair the damage or not (see Fig. 1. #5). For activities that require specific documentation and that are also car-specific, MSA embeds different visual elements. This is notably the case for the chassis check that relies on a 3-D model of the customer’s car to mark the potential damage (see Fig. 1. #6). At the end of the inspection, all the repair activities are listed in a report that a customer digitally signs to validate the inspection. The transfer of data into the dealership’s enterprise systems terminates the routine.

Fig. 1.
figure 1

Storyboard of MSA with customer selection, car inspection and validation

Full size image

4.2 Case II: Mobile Application Supporting Routine Patient Care in Hospitals

Background and Motivation. This case focuses on routine patient care, i.e., the activities that a physician performs to cure a patient’s disease, at a rheumatology department of a Swiss cantonal hospital. Clinical routines are very specific and sensitive to context, in particular to the patient in focus and the medical discipline. They are also highly individual, since physicians often practice in a particular way or style similar to that in which they were trained [21]. Routines in patient care are thus characterized by a high degree of variations and exceptions. These routines are mainly structured through the anamnesis, the examination, and the reporting activities. During the anamnesis, a physician gathers information about a patient’s medical history by asking him or her specific questions (e.g., medication, allergies, and family diseases). While the anamnesis seeks to provide useful information for the diagnosis and treatment, information gathering is limited to the fact that a patient or his or her family can only report symptoms that are known to them. The anamnesis is therefore complemented by an examination. Thereby, a rheumatologist gathers information by directly investigating a patient’s body. Finally, rheumatologists document the routine to report the outcome (e.g., diagnosis and therapy plan) to various stakeholders such as the patient or other health professionals.

Previously, the routines at the rheumatology department were entirely supported by paper-based forms. The rheumatologists opted for mobile devices as a new artifact assisting their routines, because it allowed them to capture digital information during routine execution without disturbing face-to-face communication with patients.

Mobile Application’s Roles. The mobile application represents the basic sequence of activities in routine patient care, i.e., anamnesis, examination, and reporting. Anamnesis and examination are codified in forms, which provide the stable and visible part of the routine. One of the mobile application’s role is to provide a shared vocabulary among rheumatologists by means of forms. The latter are especially useful for less experienced physicians, who need more help and guidance during routine execution. The mobile application automates the creation of medical reports. When a physician activates a checkbox during a routine, a predefined text module is added to the medical report together with content of the free-text fields. During the routine, the medical report is updated in real time, providing the physician with an overview of his or her current activities. When a rheumatologist finishes a routine, the related medical report is immediately ready to be sent to the various stakeholders (e.g., patients and general practitioners).

In our first analysis, it was particularly interesting to observe how rheumatologists use the mobile application during their activities. Even though the item order in the primary and the secondary navigation was fixed, it was not perceived as a predefined structure to do a routine. For instance, during the anamnesis, there is a high variation in the information gathering process. A rheumatologist would limit the medical history to a minimum in an emergency case, and would focus on important details such as a patient’s name or previous allergies. Thereby, the forms and the related navigation structure are perceived as a repository of activities that provides the basis to dynamically build the supporting mobile application for each instance of a routine.

User Interface Design and Interaction Flow. The mobile application’s storyboard is composed of two different screens. On the first screen (see Fig. 2. #1), a rheumatologist searches for a patient. Administrative data about patients is provided by a centralized clinical information system. Through the selection of a patient, the physician triggers a transition to the second screen, where the patient’s medical history is accessible and where the actual routine is executed (see Fig. 2. #2). The navigation elements and the forms on the second screen constrain and guide the physician during the routine. An important paradigm when designing artifacts for routine patient care is the effort of switching from one patient to the other. For a rheumatologist, it must be highly visible to whom a medical history belongs, and in which patient’s record he or she is documenting. Therefore, the mobile application clearly separates the patient selection from the routine.

Fig. 2.
figure 2

Storyboard of LCS with patient selection and routine support

Full size image

A tab-based menu on the top of the screen is the primary navigation element (see Fig. 2. #3). This menu describes the physician’s main activities during the routine, i.e., anamnesis, examination, and reporting. The list menu on the left is the secondary navigation element, and its items adapt to the selected primary navigation item (see Fig. 2. #4). Items in the secondary navigation are generally named after anatomic terms (e.g., skin, eyes, abdomen) and represent specific parts of the body. A form describes each item in the secondary navigation and provides details for asking questions during anamnesis and for investigating a patient’s body (see Fig. 2. #5). Clinicians basically use checkboxes and free-text fields to document a routine. Rheumatologists also use anatomy sketches (e.g., joints or muscle groups) to draw in a patient’s specific pain points and inflammations. The form elements are intelligent and listen to specific events. For instance, when a physician fills in a patient’s height and weight, the form elements for body mass index and body surface area automatically calculate their value. Forms are validated during data input. A yellow background on the form element indicates a false data entry. However, the data is saved anyway, and the rheumatologist can continue the routine without handling the data errors. In an emergency case, physicians prefer to have data errors that can be corrected afterwards than dealing with alerts from the mobile application during stressful situations.

5 Findings: Roles and Design Principles

The analyzed cases illustrate how mobile technology allows for the use of digital devices during routines that were traditionally supported by paper-based artifacts. The two investigated mobile applications represent different domains and different actors. While the MSA focuses on physical objects, i.e., cars, the LCS centers on human beings, i.e., patients. Both domains depend on domain experts’ knowledge and experience, but show different levels of variability of the routine. Whereas MSA imposes a higher level of standardization, LCS aims at accommodating different individual ways of working. Despite these differences, the mobile applications expose many commonalities so that we identified generalizable patterns.

5.1 Mobile Application’s Roles in Supporting Organizational Routines

R1. Support experts in performing routines and reduce variation in routine execution.

In the cases of the MSA and the LCS, mobile applications structure a routine and guide workers during routine execution. Their design constrains the number of possibilities, in which the experts can do their work. For instance, they might be “forced” to perform a group of activities, before they are allowed to access the next group of activities. Input validation ensures that outcome of an activity is correctly achieved. Such an approach standardizes the patterns of some activities and ensures quality and consistency of routines.

R2. Support experts in documenting their activities during execution.

A key benefit of using mobile applications in routines is that they facilitate the documentation of a routine while executing it. Predefined forms and checklists assist an employee in documenting his or her activities. In both cases, documentation was enhanced through the use of visual input elements (e.g., 3-D models of a car, anatomy sketches).

R3. Support experts in reporting a routine’s outcomes.

The documentation provides the basis to automatically generate reports in order to summarize and communicate the routine outcomes. In the past, this work was typically done after a routine, when the domain expert wrapped up his or her activities in a written report. This process was cumbersome and prone to loss of information. In both cases, the automatically generated reports are also directly distributed or made accessible to other stakeholders.

R4. Support experts in accessing context-specific knowledge.

Routines depend on context-specific knowledge. In our cases, we find that this knowledge is often related to the ‘objects’ (e.g., customer, car, patient) involved in a routine. A key role of mobile applications is to provide individuals with direct access to relevant administrative and historical data about the context-relevant object when executing a routine.

R5. Enable transparent communication between domain expert and individual.

In both cases, the domain expert (service technician or physician) interacts with an individual (customer or patient) while executing his or her tasks. Here, the domain expert must adapt his or her language, as they do not share the same knowledge as the counterpart. Mobile applications can support these different communication styles. For instance, they can visualize information in order to make them understandable for non-experts. This endeavor enables transparency in documentation and seeks to create a shared understanding between the domain expert and the individual.

5.2 Design Principles for Mobile Applications Supporting Routines

From our analysis, we were able to synthesize five design principles:

DP1. Mobile applications need to implement a routine’s context and boundaries. Each instance of a routine focuses on one specific object, which defines a routine’s boundaries.

When experts define and formalize a routine, it is often not clear to them where a particular pattern of activities starts and ends. The storyboard for a mobile application must separate the selection of the physical ‘object’ (e.g., a customer, car, or patient), which defines both a routine’s boundary and a routine itself. Once the routine has started, the mobile application must prevent an individual from changing an object in use – by mistake or unconsciously. For instance, in hospitals, an emergency might change a physician’s priorities. In that case, switching from one patient to another in the mobile application must occur without confusion. This can be achieved via buttons, which trigger a transition from one screen (definition of boundaries and selection of physical object) to the other (support of routine). Thereby, a mobile application cannot efficiently support a routine without knowing about the context in which a routine takes place.

DP2. User interface elements, such as navigational elements, forms, and checklists, should guide domain experts with a predefined structure for routine execution.

Navigation elements, forms, and checklists are typical user interface elements, which allow for codifying the formalized routines built on an organization’s existing knowledge and past experience. The latter elements guide and support a domain expert in taking actions and contribute to providing a shared understanding of a routine. They provide a predefined structure and represent the stable parts of a routine.

DP3. A mobile application’s navigational elements should be flexible enough to cope with a specific routine executed by a specific actor at a specific time.

Mobile applications are highly customizable to an individual’s needs, supporting the required stability and flexibility of routines. On the one hand, navigational elements must implement a clear structure, which defines the stable parts of a routine, while on the other hand they must also provide enough flexibility to adapt to the required actions in a specific routine by a specific actor at a specific time. As we have seen in the case of routine patient care, the higher the variation and the number of exceptions, the more freedom domain experts will require to effectively and efficiently perform their activities. Instead of prescribing fixed navigation sequences, the interfaces have to provide a certain flexibility, e.g., by creating groups of activities. Thereby, primary and secondary navigation elements provide a repository out of which a routine is dynamically created, rather than a predefined enforced structure.

DP4. Mobile applications should provide the functionality to create and formally approve reports in order to communicate the outcomes of a routine to stakeholders.

While the use of mobile technology allows one to document a routine during its execution, an application must provide the functionality to automatically generate a report based on this documentation. An automatically generated report allows one to communicate the outcomes of a routine right after a worker has completed his or her tasks. Report generation is typically complemented by a formal approval of the routine outcomes (e.g., via a signature) and by automated distribution to those who were directly involved in the routine (e.g., customers or patients) or need to know about the outcomes. In medicine, a specialist usually sends the report to the general practitioner, who will explain the outcomes of a routine to the patient. In a future scenario, one could imagine that the documented routine serves as a basis for communicating an outcome to various stakeholders (e.g., a patient, general practitioners, insurances), each of them with a different language to make the outcome understandable to a specific audience.

DP5. Mobile applications must provide ubiquitous access to data about context-relevant object.

While executing a routine, a domain expert needs access to administrative and historical data about the context-relevant object (e.g., customer, car, patient). This data is usually centralized and stored in an organization’s enterprise system that is used across different departments. The connection and integration of mobile applications to organizations’ information system is then essential. Since one can typically not ensure that internet connectivity is available throughout the conduct of a routine, data needs to be synchronized as soon as the routine is completed or internet connectivity is available. In our cases, a local database and document storage served as a cache to store the history about an object of interest. At the same time, one must ensure that an organization’s privacy policies and security guidelines are taken into account. These rules might prevent the storage of certain data on a mobile device or the accessibility to certain information outside of a specific location or area.

6 Conclusion

This paper investigates the roles and designs of mobile applications that support organizational routines. Our main research contributions are the insights into the role of mobile applications in routines, as well a set of design principles that can guide software developers in developing mobile applications for routines. We find that mobile applications guide workers in routine execution by standardizing the sequence of activities and validating the outcome of activities. Moreover, they provide context-specific information and enable transparent communication between domain expert and individual. Our design principles highlight the relevance of identifying the routine’s boundary and creating pre-defined structures for routine execution, while leaving a certain degree of flexibility to the experts. The design principles further suggest providing reporting functionality for communication to stakeholders and access to context-specific information. By looking into mobile application design for organizational routines, we complement existing research on user-centered design [6, 22] with specific design principles for expert users working in organizational contexts. Our research is meant to be a first step towards extending the notion of user context in mobile application development to the broader context of organizational routines.

Among the obvious limitations of our study is the limited number of cases we analyzed. In this regard, it will be interesting to analyze how different types of organizational routines and different contexts influence the ways mobile applications are designed and used.