Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Introduction

Creativity and collaboration are inevitable in user-centered design (UCD), which considers end-user needs from the beginning of the design and development process of a user interface (UI) for an interactive system. The teams that are responsible for UCD of interactive systems ideally involve members with various backgrounds. As considered in the ISO standard for usability, a multidisciplinary UCD team should include team members with expertise in, among others, human-computer interaction (HCI)/human factors/ergonomics, user interface/visual/product design and systems engineering/software engineering/programming, as well as end-users/stakeholder groups and application domain specialists/subject matter specialists (International Standards Organization 2010). Nowadays, several creative and participatory design techniques support collaboration within such multidisciplinary teams for the design and development of interactive systems. However, since the team members often have different expectations about the representations and transformations of end-user needs and concepts for a future software system, it is a challenging task to ensure that they all reach a common understanding in the first stages of a UCD process.

An additional challenge when collaborating within a multidisciplinary UCD team, is communication within the team without information loss. One missing link in most user-centered processes is an approach and accompanying tool to progress from informal design artifacts (e.g. scenarios) toward more structured and formal design artifacts (e.g. task models, abstract user interface designs) without losing any information. Existing tools and techniques often require specific knowledge about specialized notations or models, and thus exclude team members not familiar with these notations or models. Furthermore, functional information may be missing in informal design artifacts, while structured design artifacts may not always contain all non-functional information. We put forward storyboards as a comprehensible notation to overcome these shortcomings.

In the next section, we present a storyboarding notation that specifically considers UCD practices in multidisciplinary teams. This notation mainly focuses on collaborative storyboarding to facilitate multidisciplinary teams during different stages of the UCD process. Collaborative storyboarding activities also involve the contributions of team members with different skills, perspectives and goals in the creation of storyboards. We present an observational study that presents insights into important aspects of collaborative co-located storyboarding in multidisciplinary teams, which lead to recommendations for facilitating this type of storyboarding sessions. In addition, these recommendations can inform the design of digital storyboarding tools that support this type of group work.

Storyboards for User-Centered Design

The early design stages of a UCD process include a user needs analysis and generally result in several artifacts that contain the user needs, such as usability requirements documents (Redmond-Pyle and Moore 1995), scenarios that represent how a future system is used in a certain context (Carroll 2000) and personas concerning hypothetical archetypes of key users of the future system (Pruitt and Adlin 2006). These artifacts are written in natural language, usually have a narrative style and are typically created by team members with expertise in UCD or HCI, but not necessarily technical knowledge. Similar artifacts are used in more technical domains such as software engineering and agile development (Holtzblatt et al. 2004) (e.g. essential use cases and user stories), albeit in a different context.

Although several disciplines provide and use notations to describe user needs, these notations are not always suitable to pass information of the user needs to other members of the multidisciplinary team without misconceptions (Haesen et al. 2008). A wide interpretation of tasks and user needs analyses often confuses multidisciplinary team members (Lindgaard et al. 2006). The use of stories combined with sketches in the early stages of user-centered approaches, which is comparable to the use of storyboards, is considered as a powerful technique to reveal errors and to consider temporal and contextual information (Brown et al. 2008).

The professional use of storyboards originates from the film-industry and was introduced in several disciplines, such as advertisement and product design (van der Lelie 2006). For similar visualization purposes, storyboards are used in UCD approaches, where they can have different forms. Storyboards can visually express scenarios of use, or can represent the flow of interaction throughout the application to clarify interactivity in the early stages of UCD (Landay and Myers 1996). We concentrate on the first approach, which considers storyboards as a technique to complement scenarios, resulting in a visual depiction of how a user carries out a task using the system that is to be developed (Kantola and Jokela 2007; Preece et al. 2002).

In UCD, storyboards can be used as powerful artefacts to clarify user needs. In particular, storyboards can depict systems that are used in several contexts of use or on multiple devices. In earlier work, storyboards were used for the design of mobile systems (Sonja and Wally 2005), to provoke empathy in a design team (McQuaid etal. 2003), and to validate conceptual ideas of new interactive systems (Davidoff etal. 2007). In the next sections, we describe COMuICSer storyboards and how they can be specified and used in order to support multidisciplinary teams in UCD.

Definition of a COMuICSer Storyboard

COMuICSer is an acronym for COllaborative MultIdisciplinary user-Centered Software engineering and is pronounced as “co-mixer”. The name also refers to comics, which have a similar representation as storyboards (Haesen et al. 2010; McCloud 1993). COMuICSer concerns a notation, and accompanying tool support, which are designed specifically to support multidisciplinary teams in UCD. We introduce the COMuICSer notation and COMuICSer tool support separately because a COMuICSer storyboard can be specified by simply using pencil and paper. However, in order to fully benefit from the advantages of COMuICSer storyboards, using the COMuICSer tool is recommended.

The COMuICSer notation concerns a storyboard that is defined as a sequence of sketches of real-life situations, depicting users carrying out several activities by using devices in a certain context.

Real-life situations, depicting the circumstances in which the future system will be used, are the main component of a COMuICSer storyboard. These situations explain realistic circumstances in which the system is or will be used by means of a scenario. The depictions of real-life situations in a storyboard show the end user needs to all members of a multidisciplinary team and may provoke empathy for the users among the team members.

In UCD, the focus is on the users from the start of a project. Consequently, the users have a prominent role in a COMuICSer storyboard. If available, personas can be linked to the storyboard. As stated in ISO 13407 (International Standards Organization 2010), which specifies human-centered design, not only the user should be considered, but also the activities carried out by the user, the technology or devices that are provided, and the context in which a system is used. All these elements can be depicted by the COMuICSer storyboarding notation.

An example of a simple COMuICSer storyboard is presented in the center of Fig. 1. This storyboard depicts a few hours of a journalist’s working day. In the first scene, the journalist is working behind his desk. This is how he usually starts his day at work. However, very often he receives a phone call that notifies him about a certain incident in the neighborhood, for instance a car accident. Next, the journalist hurries to the place of the incident, where he takes notes about the incident on his personal device, which is depicted in the second scene. Afterwards, the journalist searches for a park bench and finalizes his article for the newspaper remotely using his laptop, as shown in the third scene.

Fig. 1
figure 1

A storyboard and its relationship with other artefacts in the UCD process. The large light blue arrow presents the general evolution of artifacts in the early stages of UCD, while the small dark blue arrows represent evaluations and iterations of artifacts

Full size image

Bridging the Early Stages of UCD Processes Using COMuICSer Tool Support

The creation of storyboards happens at the early stages of a UCD process, ideally after the observation or analysis of the user needs and the creation of informal design artefacts such as scenarios and personas. A storyboard can lead to user interface designs that carefully take into account the situation in which an interactive system will be used. The interrelationships between a COMuICSer storyboard and other artifacts are shown in Fig. 1. The large light blue arrow shows the general evolution of artifacts in the early stages of a UCD process. The small dark blue arrows indicate that the creation of a storyboard is an iterative process that also considers discussions, evaluations and adjustments within a multidisciplinary team. When informal design artefacts are available in the UCD process and formal artefacts need to be prepared in order to continue the design and prototyping of the interactive system, a COMuICSer storyboard can be used to bridge the gap between both types of artefacts.

Several commercial tools, such as Comic Life,Footnote 1 Celtx,Footnote 2 ToonDoo,Footnote 3 Storyboard ThatFootnote 4 and Indigo StudioFootnote 5 support the creation of digital storyboard. These tools mainly focus on comics or storyboards in general, and rarely provide features that consider the use of storyboards in multidisciplinary UCD teams. Ozenc et al. address the need for tools that support refining rough designs and a scenario-driven process (Ozenc et al. 2010). The ActivityDesigner (Li and Landay 2008) tool allows storyboarding at the early stages of user interface design processes. In this tool, designers can extract activities from concrete scenarios, making it possible to include rich contextual information about everyday life as scenes. Based on the scenes, higher level structures and prototypes can be created. However, not all information is visually represented by the scenes and it is not specified which components need to be available in a scene.

Due to the limited availability of storyboarding tools for UCD, the COMuICSer notation is accompanied by tool support to facilitate UCD in multidisciplinary teams (Haesen et al. 2011, 2009). The proof of concept of the COMuICSer tool supports the creation and use of COMuICSer storyboards based on scenarios and personas, and passes contextual information to other artefacts in the UCD process (e.g. UI designs and their interaction sequences).

In practice, a COMuICSer storyboard can be created using pen and paper. However, the COMuICSer tool can be very useful to support the transitions between a COMuICSer storyboard and the other artifacts mentioned in Fig. 1. The following process of creating a COMuICSer storyboard is supported by the proof of concept of the COMuICSer tool (Fig. 2). First, the scenario can be written or loaded into the scenario textbox, e.g. by an interaction designer (Fig. 2-1). Next, this scenario can be split into a number of scenes. A sequence in the scenario textbox can be selected, followed by creating a new scene, which appears in the storyboard panel (Fig. 2-2). The selected sequence of the scenario is automatically added as a description to the scene. Now, the interaction designer can load an image and add a title. The image of the scene can be a scanned sketch or a photo of the user observations. As all scenes of the storyboard typically include personas and devices, this information can be annotated in the scenes. These annotations are made in a similar way to the photo tagging features on Facebook or Flickr. The storyboard in Fig. 1 shows a persona (e.g. Bart, journalist, 43 years old) in the three scenes, which is specified in the properties panel (Fig. 2-3). The device used in the first and third scene is a laptop, while a personal mobile device is used in the second scene. Highlighting or tagging personas and devices enriches the information contained by the storyboard and is useful to make the transition to other artifacts (Haesen et al. 2011, 2009). For instance, automatically constraining a UI design space according to the screen resolution of the selected device decreases the risk of information loss.

Fig. 2
figure 2

A screenshot of the COMuICSer storyboarding tool. This tool supports storyboarding by connecting a storyboard with a scenario, personas and other annotations

Full size image

By carefully considering the situation of each scene, designers and developers can build an application corresponding to the contextual information, requirements and constraints contained in the storyboard. Interaction designers can use a storyboard to verify that the UI designs take into account all requirements. Using COMuICSer storyboards in UCSE processes increases the visibility of a project’s requirements: the accessible notation allows all team members, including end users, to be involved in the UCSE process, and new team members can, for instance, explore the requirements of the project at a glance by looking at the storyboard (Haesen et al. 2011, 2009).

The COMuICSer notation is very accessible and suitable for usage in multidisciplinary teams. The current proof of concept of the COMuICSer tool supports an individual team member in the creation of a COMuICSer storyboard, which can be shared within a UCD team. To create COMuICSer storyboards during a collaborative co-located storyboarding session, further tool support is needed. Such a tool needs to accommodate co-located collaboration practices, where people gather around a shared surface (e.g. a table or whiteboard) to co-create storyboards in which the considerations of each team member is included. For this purpose, we investigate interactions that occur during collaborative co-located storyboarding.

Collaborative Storyboarding in Multidisciplinary Teams

COMuICSer storyboarding supports the involvement of multidisciplinary teams in the early stages of UCD. A storyboard can be created by one team member, who shares the storyboard with others in a meeting. However, by organizing collaborative storyboarding sessions, all team members and their different skills and perspectives can be included in the storyboard, which is valuable for later stages of UCD.

To get insights into how multidisciplinary teams collaborate during a storyboarding session, we set up a study in an environment where co-located teams can create storyboards using low-fidelity tools such as paper, color pens, scissors, glue, and post-it notes. These tools, although non-digital, provided all necessities to create COMuICSer storyboards.

Multidisciplinary Teams and Study Setup

Three teams of four people participated in the study, all experienced researchers with expertise in the design or development of interactive systems from a HCI and/or user interface design perspective. In order to be able to consider the multidisciplinary aspects of collaborative storyboarding, each participant was instructed to take on a particular role during the study. We used some of the crucial roles considered in UCD (International Standards Organization 2010): HCI specialist, UI designer, systems analyst, and stakeholder (end-user or application domain specialist). These roles were assigned based on the participants’ skills and expertise. Results from a post-study questionnaire indicate that most participants felt “comfortable” to “very comfortable” in their role. Three participants felt “neutral” and nobody felt uncomfortable.

Assembling multidisciplinary teams in this way may yield some differences compared to actual teams that have been working together for some time. In real-life settings, one team member can have a combination of skills, which implies that the roles in a team are not always as easy to distinguish as in our three teams. However, in order to observe the influence of the different disciplines involved in a UCD team, we instructed our participants to take on a very specific role. The participants were thoroughly informed about their role and collaborated before in different contexts, so there were no social boundaries during the study. We therefore believe that our setup provides a sufficiently similar approach as real-life settings.

The storyboarding sessions were carried out on a regular table (160 by 160 cm), with each team member sitting at a corner (Fig. 3a). We provided a stack of A4 sheets and a box with images representing personas and items. Each participant also had a personal box of non-digital ‘tools’ (Fig. 3b).

Fig. 3
figure 3

Setup of the observational study: (a) each participant positioned at a different corner; (b) contents of the toolbox that was provided to each participant

Full size image

Instructions for the task and a description of the participant’s role were provided to each participant. We used personas and a scenario as identical starting points for the three storyboarding sessions, because these documents describe the use of a future software system and can be related to COMuICSer storyboards. First, each participant had 15 min to prepare the storyboarding session individually. They were asked to write down or sketch anything considered to be important, bearing in mind their specific role and goals. Next, the teams were asked to create a storyboard that represents the given scenario. Each team had 60 min.

A video camera recorded the sessions for later analysis, and two observers took notes. Upon completion of the storyboarding task, the participants filled in a questionnaire about their former experiences, and their findings regarding the storyboarding task and collaboration within a multidisciplinary team.

Case: Home Automation

The personas and scenario that were provided to the participants revolved around a home automation system to control the heating and lighting, which can assist a household in saving money on energy consumption. The system can be controlled by different family members (differing in age and technological aptitude), using different devices (e.g. touchscreen, laptop, smartphone). Although not explicitly mentioned, the scenario suggested that the system should take into account settings related to personal profiles and activities, that settings of profiles should be merged in some situations, and that the system should be able to detect people’s presence in certain rooms.

Observations and Results

In this section, we present the findings of the study, based on the results of the post-study questionnaire and our observations. To complement the observations, Fig. 4 visualizes the physical activity on the table throughout the sessions. We automatically generated this visualization from the video recordings, based on the movements of participants. Because the participants were seated at a prearranged location around the table, we can roughly associate physical activity with particular participants. This approach obviously has its limits, as it for instance not considers participants reaching across the table, so we rely on our observations to interpret the physical activity correctly.

Fig. 4
figure 4

A snapshot of a video recorded during a storyboarding session and a visualization of the participants’ physical activity on the table throughout each of the three sessions, automatically generated from the videos (darker color means more frequent activity)

Full size image

Individual Preparation

During the individual preparation, several participants highlighted phrases in the provided text. Each participant structured the information in a particular manner: a few used bulleted lists, while others represented it by means of graphical artifacts, ranging from diagrams to sketches.

In terms of content, the roles of the participants were clearly expressed in the artifacts they prepared (HCI specialists focused on relations between personas, devices and tasks, designers on UI designs and requirements, systems analysts on devices and their connections, and stakeholders on general requirements and the personas’ needs). In all sessions, participants began to explain their prepared artifacts to the others once the collaboration started, but in two out of three sessions, not all members presented their preparation. Prepared artifacts were rarely included explicitly in the storyboard, but participants did use them during discussions.

Storyboarding Task

The approach to the storyboarding task differed in the three teams. Team A started by shortly discussing their strategy and decided to first depict the equipment and users in the different rooms of the house. Next, they started creating the first scene collaboratively, in a shared space in the middle of the table. Next, the team implicitly split in two to prepare other scenes. Awareness was maintained, since participants frequently switched between cooperating with their neighbor and cooperating with the entire team, and a lot of work was done in the middle of the table. The HCI specialist maintained the relationship between the storyboard and the scenario. For team A, Fig. 4 clearly shows the high degree of activity of the HCI specialist, the cooperation between neighbors, and cooperation with the entire team.

Team B first discussed the system based on the requirements mentioned by the stakeholder. After a discussion of approximately 15 min, in which some decisions regarding the system were made, the HCI specialist reminded the team of the storyboarding task and took the lead in creating scenes. The other team members were actively involved in the discussion. Once the HCI specialist started creating a new scene, the stakeholder and designer finalized the previous scene together. Fig. 4 shows the high activity corresponding to the leading role of team B’s HCI specialist, as well as the stakeholder and designer collaborating to complete scenes.

Not unlike team B, team C first discussed the system based on the requirements presented by the stakeholder. This discussion lasted nearly 30 min before a first scene was created. While discussing the devices for the system, the available images were put in the middle of the table to debate the different options. Again, it was the HCI specialist who reminded the team of the storyboard and who started creating scenes. Team C shows the least amount of cooperation in Fig. 4. The seemingly high activity in the systems analyst’s region was actually caused by the HCI specialist, who was active in that region while creating scenes.

In the three storyboarding sessions, features that were implicitly described in the scenario led to a lot of discussion. Sometimes it was just one person who noticed a particular requirement, but in many cases, visually representing situations sparked discussions. Participants used the part of the table in front of them as personal workspace, and the available images were scattered across the middle or side of the table to give an overview, somewhat similar to the findings of Scott et al. (2004).

Resulting Storyboards

The resulting storyboards consisted of 7–10 scenes that represent personas and devices, and show the status of particular devices (e.g. a light that is switched on or off). Figure 5 shows how each team structured their storyboard and what materials they used. All teams used some of the available images to depict personas and devices in the storyboards. While teams B and C made extensive use of the images, team A also sketched a lot. Two storyboards contained text to indicate the location or general context of scenes. One team added post-it notes that would remind team members of particular features, difficulties and decisions.

Fig. 5
figure 5

Frames from the videos that were recorded during each session, showing the final storyboard of each team. The actual contents of the storyboards is of lesser importance, as we are mainly interested in the general storyboarding approach of the multidisciplinary teams, the materials that were used and the way the storyboards are structured: (a) Resulting storyboard of team A; (b) Resulting storyboard of team B; (c) Resulting storyboard of team C

Full size image

Structuring the scenes of the storyboard was done in different ways. Team A created a visual representation of all rooms and their equipment, and consequently depicted the situation in different scenes for each room. Teams B and C put the scenes in a chronological order, based on the flow of events in the scenario. Extra scenes were inserted into the storyboard sequence when considered necessary. Scenes were labeled with numbers, and in team C, titles were added as well.

Multidisciplinary Team

The participants confirmed in the questionnaire that being part of a multidisciplinary team had a positive impact on the storyboarding session, since it resulted in a combination of different perspectives, ideas and considerations. HCI specialists rated their direct contribution to the storyboard highest on average. Most systems analysts, designers and stakeholders rated their direct contribution considerably lower: analysts and designers prepared artifacts that were used to a lesser extent during the session, while stakeholders were more verbally involved.

We can relate these ratings to the physical activity seen in Fig. 4 (e.g. team B’s systems analyst and team C’s designer and stakeholder ranked their direct contribution lowest) and to the observation that two of the HCI specialists took the lead for the creation of the storyboard. Furthermore, the HCI specialists of all the teams controlled the link with the scenario by reading it aloud or referring to it. Stakeholders and systems analysts rated their general influence on the storyboard notably higher than their direct contribution. Frequent discussions about feasibility and costs of particular approaches, but less active contributions of these team members to the creation of the storyboard, account for this difference.

Collaborative Storyboarding: Recommendations

The observations of the teams indicate that findings of a study on a creative activity such as storyboarding are not easily generalizable. However, this study shows different aspects that are important for the organization of co-located collaborative storyboarding sessions for multidisciplinary teams in UCD.

Besides the recommendations, we also consider tool support. Several efforts are presented in literature toward the creation of digital tools that focus on individual or collaborative storyboarding as part of a software development process (Atasoy and Martens 2011; Haesen et al. 2011; Truong et al. 2006). These tools concentrate on the (re)use of storyboards, which is useful to support alterations and consistency checks with the system’s requirements. Some tools, such as Coeno-Storyboard (Haller et al. 2005) and StoryCrate (Bartindale et al. 2012), assume that one person has the role of a coordinator and organizes artifacts on a timeline. However, none of the tools consider the respective contributions of team members with different skills, perspectives and goals. Because existing tools have demonstrated the benefits of digitizing storyboards for user-centered design and development purposes, we put forward a number of recommendations for a digital tool that supports collaborative creation of storyboards by a co-located multidisciplinary team.

Allow for Differences, Support Agreements

One of the first things to bear in mind is the individual preparation of a storyboarding session. Most designers, for instance, continuously accumulate graphical material, and they frequently use this material as a source of reference and inspiration (Atasoy and Martens 2011). Since paper is still a very ubiquitous medium, team members should not only be able to use digital artifacts, but also tangible artifacts such as paper documents. Prior studies indicate that designers still prefer pencil and paper early in the design process (Bailey et al. 2001).

In our study, the individual preparation resulted in many different artifacts, including device or task descriptions, UI designs, and requirements. Relations between artifacts were also considered during preparation. As the representation style and viewpoints differed greatly and the members of a multidisciplinary team are already accustomed to their specific tools and devices, we should not enforce one particular way of preparing artifacts. The accustomed tools and devices can be supported by allowing the use of personal devices, and by facilitating an easy exchange of data between personal devices and a shared device (e.g. an interactive table or a whiteboard).

Given the differences in the prepared artifacts and viewpoints, the team members had to come to an agreement on several occasions. All teams, for example, had to agree on the devices that would be used in the home automation system. Since involving all team members in the decision making process results in more comprehensive storyboards, active participation should be encouraged. On the other hand, we also observed that it can be beneficial to have someone take the lead, to make sure that sufficient progress is made, focus is maintained, and discussions are called to a halt at appropriate times. A digital tool can incorporate approaches that allow one or more team members to take the lead, while preventing more quiet users from being less involved. Such a tool can facilitate balanced decisions supported by the entire team. For instance, to enforce decisions supported by the entire team, a voting feature (Ryall et al. 2005) may require all users (or a quorum) to agree.

Facilitate Different Approaches in Structuring

Structuring the storyboard happened in two ways: a spatial arrangement, connecting the scenes to a particular location, or a temporal arrangement, organizing the scenes chronologically. Consequently, different approaches in structuring should be facilitated. Mapping scenes to a floor plan can provide insights regarding devices available at a certain location and the use of the system by certain people, while sorting the scenes according to a timeline shows the moments in which particular features of a system are used.

A digital tool should not be restricted to one particular arrangement and should allow teams to create (different alternatives of) scenes and connections between them freely. In Storify (Atasoy and Martens 2011), for instance, a team can add multiple alternatives per storyboard frame, with the purpose of discussing various user experiences. The Anecdote (Harada et al. 1996) tool, on the other hand, allows various design styles by providing several views of the design, including an outline view, timeline view, and scene view. Creating multiple alternatives of a scene and switching between multiple arrangements of scenes can offer different perspectives, but teams will not take advantage of such features if the actions are too time-consuming.

Maintain the Design Rationale

Visually representing the future home automation system stimulated the teams to discuss some unclear and challenging features. Despite the interesting discussions, almost none of those considerations or decisions were included in the storyboard. Since the design rationale is often valuable for later stages of UCD, it is very important to capture this rationale one way or another.

Wahid et al. (Wahid et al. 2010) state the importance of presenting the rationale in a designer-digestible format based on their study on the relationship between imagery and design rationale. This designer-digestible format depends on factors such as the homogeneity of the team and the familiarity of the team with the problem.

When organizing co-located collaborative storyboarding sessions, it is recommended to capture the design rationale. A digital storyboarding tool can record the rationale and monitor all the artifacts. Furthermore, it can encourage team members to connect those artifacts to the storyboard (e.g. connect a designer’s user interface sketches to a particular scene). SILK (Landay and Myers 1995) also enables, for instance, designers to examine, annotate and edit a complete history of the design. Maintaining the design rationale, in combination with the balanced participation of the different roles we mentioned earlier, may lessen the dissatisfaction some participants reported regarding the extent of their contribution, because their artifacts did not end up in the actual storyboard. To keep track of vocal discussions, audio or video annotations can be connected to the storyboard.

To monitor all storyboard artifacts, the tool can track their ownership or origin. Haller et al. (Haller et al. 2005) state the importance of clearly identifying who is manipulating each data object in Coeno-Storyboard. Similarly, Avila-Garcia et al. (Avila-Garcia et al. 2010) use a DiamondTouch (Dietz and Leigh 2001) tabletop to identify the input of up to four different users, because identifying, saving and tracking contributions made by team members can be relevant in a decision making scenario. To support easy logging and audit trail creation, identity-differentiating widgets (Schmidt et al. 2010) or lenses (Ryall et al. 2006) can be incorporated.

Favor Shared Over Personal Space

While preparing, participants each created a personal workspace. Within the boundaries of our observational study, privacy was never an issue when participants shared data. In a real-life setting, however, privacy might come into play from time to time (Shoemaker and Inkpen 2001), although further studies are required to investigate this aspect in the context of storyboarding in multidisciplinary teams.

During the cooperative storyboarding sessions, almost all work was done in the shared space between two participants or toward the middle of the table, even when multiple scenes were being created in parallel. Personal workspaces were still used sporadically, for actions such as writing on a post-it note or consulting the instructions or preparation. The sides of the table were mainly used for storage (e.g. toolboxes, available images, finished scenes). Since space is often at a premium, care has to be taken with personal workspaces or toolboxes taking up lots of space, leaving too little shared space to support a clear overview (as requested by participants in the questionnaire) and effective collaboration.

When asked about the participants’ preference for a digital system, all participants favored a shared device such as an interactive tabletop, because it makes collaborating easier and it encourages involvement and discussion. They commented that physical interactions on a shared surface emphasize what is being done and make participants explicitly aware of the progress and contributions. Some participants, however, voiced concerns over the fluency of sketching and text entry on a digital system such as a tabletop. These concerns can be alleviated to some extent by incorporating additional input devices, such as a physical pen and keyboard, or by supporting paper.

Since the use of a large digital tabletop is not always feasible, this approach might not offer adequate space for all team members and their expected tasks. Integrating personal devices can reduce the problem of limited space, since they can act as personal workspaces. An object storage space can be provided to store unused physical objects, and the digital space can be extended by making space-demanding components zoomable.

Another solution is to extend the environment with additional displays. Ryall et al. (Ryall et al. 2004) state that for larger groups it might be necessary to add additional vertical displays for shared information. Avila-Garcia et al. (Avila-Garcia et al. 2010) also suggest the addition of one or more vertical displays. However, their goal is to accommodate passive team members, as one of the displays could show the interactions that are taking place on the tabletop. In our case, we want to avoid members being passive, and adding more displays may have a detrimental effect on balanced participation. About half of the participants also suggested including a personal device to consult preparations or take notes, with the ability to easily share items with others. A point of attention, however, is the possible decrease of mutual awareness and involvement when personal devices are being used extensively.

Conclusion

Design often is a collaborative activity that takes place in multidisciplinary teams. When it comes to UCD of interactive systems, the early design stages, in which informal design artifacts need to be translated into formal design artifacts, often cause difficulties and ambiguity. COMuICSer storyboards and the accompanying tool support can be used for detailing scenarios of use and connecting parts to informal artifacts needed at later stages of design. COMuICSer storyboards support the different backgrounds involved in a multidisciplinary team, and it is important that co-located collaborative storyboarding sessions adequately facilitate the needs of multidisciplinary teams.

We performed an observational study that includes an analysis of group interaction in multidisciplinary teams during co-located storyboarding sessions. Based on this study, we put forward a number of recommendations: allow for differences and support agreements, facilitate different approaches in structuring, maintain the design rationale, and favor shared over personal space. By taking into account these recommendations, multidisciplinary collaboration can be facilitated during co-located storyboarding sessions and digital storyboarding tools, including an extension of the COMuICSer tool, can be designed to engage all team members, while respecting individual contributions and creativity. An extended COMuICSer tool can for instance be provided using a multi-touch tabletop, by considering the aforementioned recommendations in combination with related collaborative tabletop design patterns (Remy et al. 2010; Vanacken 2012).

We strive for a balance in participation among members of a multidisciplinary team, because involvement of all members results in more complete storyboards that carefully take into account different aspects of an interactive system’s context of use. The result of a storyboarding session should reflect all opinions and artifacts, also those of more reserved team members. Incorporating viewpoints of multiple disciplines remains a challenge and cannot be entirely delegated to a storyboarding tool. Therefore, the recommendations presented in this chapter should not only be taken into account for the design of digital storyboarding tools, but also when organizing co-located collaborative storyboarding sessions in multidisciplinary teams with the use of non-digital tools.