Layered scenario mapping: a multidimensional mapping technique for collaborative design

Abstract Making use of insights gained through field research in design can be challenging. Some issues that design teams may face are making sense of fragmented data collected, sharing insight among the design team and presenting the data in ways that support the situated design work. This paper introduces layered scenario mapping, a technique aimed at meeting such issues when designing a ship’s bridge. The technique builds on and expands traditional techniques for representing user data in design and results in a map describing a typical scenario along several dimensions and at different levels of abstraction. It highlights the spatial and temporal aspects of the situation, and emphasises the use of visual presentations. This paper describes why and how the layered scenario mapping technique was created, it critically assesses the technique and discusses experiences with using it. The technique proved to be valuable in making sense of fragmented data, and supported the design team’s collaborative work when designing a ship’s bridge. It is expected that the technique can also prove valuable when designing for other contexts where the spatial and/or temporal dimensions are of importance.

textual descriptions, but they can also be presented using other means, such as by video or by visual storytelling (Buxton 2007). It is also possible to describe scenarios by presenting events in time, such as in Sequential Timed Events Plotting ('STEP') (Hendrick and Benner 1987). Nielsen (2002) criticises the scenario technique for providing unengaging character descriptions and focusing merely on user actions rather than on the user as a person.
Task analysis covers a range of techniques used to study what an operator (user) or team of operators needs to do to achieve a system goal (Kirwan and Ainsworth 1992). Different data sources can feed into task analysis, including field research. Examples of task analysis techniques are hierarchical task analysis, which presents tasks and subtasks that need to be carried out to achieve a goal; timeline analysis, which presents operator tasks in time; and link analysis, which identifies the links between an individual and some part of the system.
While task analysis techniques are valuable in presenting detailed information on user tasks, they do not describe the context of use. Contextmapping (Visser et al. 2005), on the other hand, is a technique specifically aimed at addressing the context and gaining an understanding of peoples' visions for the future. Although the strength of this approach is that it invites exploration and creativity, it may not provide the level of granularity needed during detailed design.
Many of the techniques for representing the situation to design for have strict boundaries and involve simplification. Giga-mapping is a systemic design technique used to 'embrace complexity' (Sevaldson 2013). It involves designing vast system maps where relationships between parts of the system are made visible to elicit potential areas for innovation. While one advantage of the technique is its flexibility, this flexibility also means that no starting point is provided, and the technique can be difficult to apply.
In the remainder of the paper, I will discuss layered scenario mapping which builds on, expands and combines many of these methods and techniques.

The Ulstein Bridge Concept design research project
The layered scenario mapping technique originated from design work carried out within the Ulstein Bridge Concept (UBC) design research project conducted at the Oslo School of Architecture and Design. The purposes of UBC were: (1) to design a completely new ship's bridge for offshore service vessels (i.e. ships serving the oil industry), taking into account the users' needs and the complex operations these ships engage in, and exploiting possibilities given by new technologies; and (2) to develop design-centred knowledge and processes tailored for innovation activities in the ship industry. The ship's bridge is the place from whence the captain and the deck officers control a ship. The project was carried out in close collaboration with Ulstein, a company that designs and builds ships.
The scope of UBC included the whole bridge, including the room layout, furniture and workstations, as well as the design of interactions, graphical user interfaces and the audio environment. The bridge design developed by the project is shown in Figure 1.

Research approach
UBC applied a research by design approach, where design practice is at the core of research and the researcher is also a practitioner, thus conducting research from a 'first-person perspective' (Sevaldson 2010). Throughout the process of developing and using layered scenario mapping, the author's reflections were documented in a research diary, while reflections from other members of the project were collected informally through project work; formally through short, semi-structured interviews, which were recorded, transcribed, and analysed; and in a workshop devoted to discussing the technique, which was video recorded and later reviewed. A representative from Ulstein was also interviewed to obtain insights into the company's experiences with layered scenario mapping.

Motivation for developing layered scenario mapping
From January 2010 to April 2014, 18 people were involved in UBC: some throughout the whole project's duration, and others for shorter periods of time. The team consisted of researchers and designers from the fields of industrial, interaction, sound, and graphic design, as well as experts in human factors and engineering. The core team consisted of nine people, one of whom was the author of this article, who held the role of interaction designer and designer-researcher. The work was at times carried out collaboratively across disciplines, while at other times the industrial and interaction designers formed mini-teams to address specific issues. The software developer, sound designer, and graphic designer alternated between individual work, and work at natural crossing points with the other disciplines. Most of our work took place in our laboratory at the Oslo School of Architecture and Design. Our laboratory was our 'virtual world' (Schön 1983), where we experimented with different designs and built models and demos.
We conducted a significant amount of field research to learn about what I refer to in this paper as 'the situation we designed for' -that is, the users and their tasks, the operations they carry out, and the context of use. A total of seven field studies lasting from two to eight days were conducted within the project. As reported by Lurås and Nordby (2014), we tested a number of techniques for sharing the data we collected and the insights gained from the field studies within the team. Team members provided formal and informal spoken reports after each field study. Written reports proved to be valuable in communicating focussed topics, but did not convey the richness of the insights we had gained. Images were used to help new members of the team become familiar with the physical environment and the equipment used on-board. We found it difficult, however, to convey the holistic, dynamic and interactive aspects of the use situation through still images alone. We used video for two purposes: to share detailed information about what happened during a specific offshore operation, and to convey the broader use patterns over a longer time span. We developed personas (Cooper 2004), which proved valuable because they made us realise that we had met the same types of people while at sea. The resulting personas, however, did not play an important role in our work. In addition to conducting field research, we learned about the situation we designed for through two workshops with users; by going through training materials, accident reports, and other written documentation; by attending industry fairs and conferences; and through following mariner work-blogs and online forums (as described in Lurås and Mainsah 2013). Through our substantial efforts in gaining insight, we developed a great deal of knowledge on the situation to design for. The knowledge was fragmented, however, and was not systemised in a way that made it easy to decipher and share.
We developed our ship's bridge design in several iterations throughout the project period (Lurås and Nordby 2013). In August 2012, our conceptual bridge (shown in Figure 1) was presented to the public for the first time through a film (see Ulstein 2012), and in June 2013 an interactive installation of the concept was exhibited at an industry fair. Following these activities, we started to develop a refined version of our concept with the aim of coming closer to realisation. To do this, we needed more detailed information on the situation we designed for. For example, the industrial designers needed to know the users' movements on the bridge and the frequency of use of different pieces of equipment to detail the workstations, while the interaction designers and software developer needed to know exactly what information the users require in order to decide what to present in which display area.
None of the methods and techniques described in Section 2 met all of our needs. Some of the techniques provided the detail, but lacked the context, while others provided contextual insights, but lacked the necessary level of detail. We developed the layered scenario mapping technique presented in this paper with the following objectives: (1) To offer a framework to use when interpreting information about the situation we designed for. This framework would help us understand the context and the individual parts of the situation, and how the parts relate to the whole, as well as to other parts.
(2) To facilitate the sharing of data collected, and insights gained among the team.
(3) To present the situation we designed for at the level of granularity necessary to gain an in-depth level of understanding. This was to be a description of the current situation, which would enable us to develop credible, relevant, and detailed designs for a desired future situation.

Developing and using layered scenario mapping
Layered scenario mapping was developed by the author with support from three members of the core team of UBC. In the following section, I will describe our process of developing and using the technique, and will introduce the guide that is included in the Supplemental data.

Selecting the scenario
A design team can never predict every possible situation in which the products they design will be used. Thus, selecting a scenario that is representative and that covers the most important aspects of the situation we designed for was important. The initial field studies and input from users informed our choice of scenario. We chose 'positioning the vessel alongside the rig and doing loading and offloading operations' for the following reasons: • Frequency: It represents the most common scenario that offshore service vessels engage in the North Sea. • Criticality: The scenario includes tasks that users deem to be high risk. In the first field studies, users were asked about what they feared most could happen in the course of their work. The users instantly replied 'losing position while on DP' , referring to dynamic positioning, a computer-controlled system that automatically maintains a vessel's position and heading. This system plays an important role in keeping the vessel at a safe distance from the rig in the chosen scenario.

Gathering information and gaining insights
We found that the best strategy for gaining insights into the situation we designed for was to conduct field studies at sea. We mapped out the main steps of the scenario in the first field study of the project in January 2010, although not with the purpose of developing a scenario. In three field studies conducted in 2012, we gathered information that was specifically aimed at mapping out in detail how the scenario played out. Through our work, we developed an approach to conducting field studies that are referred to as design-driven field research (Lurås and Nordby 2014). In this, we stress three focus areas: (1) data mapping, (2) experiencing life at sea and (3) on-site design reflection. Data mapping involves collecting specific data, such as data on user tasks and equipment. Experiencing life at sea suggests an ethnography-inspired approach similar to 'empathic design' (Leonard and Rayport 1997;Koskinen, Battarbee, and Mattelmäki 2003;Mattelmäki, Vaajakallio, and Koskinen 2014) and focuses on social and cultural aspects. It also involves understanding the environmental, temporal and bodily aspects of life at sea. Design reflection involves interpreting what one observes through a 'designer's lens' , and reflecting on design opportunities while in the field.
Most important in informing the layered scenario mapping was data mapping. We used a range of methods to map the data we needed. Observations and interviews in context were most important. The formal methods we used included Comms Usage Diagram (Stanton et al. 2005, 374-379), used to document the communication that was taking place, and Applied Cognitive Task Analysis (' ACTA') (Militello and Hutton 1998), which we used to analyse the expertise needed and to identify critical points in the scenario. The secondary sources we used included training materials, procedures and checklists, and reports of incidents that had happened during these types of operations in the past.

The design of the map
Designing the map involved deciding on what data to include, and how to present it. The content that the team included in the map was decided as a result of a collaborative process. Those who were working with the map made an initial list of potential content types to include based on experience from former design projects, as well as on the needs that were found during the first iterations of our bridge design. This list was presented to the rest of the team, which then made comments and suggestions. A new version was developed and once again discussed with other members of the team, until the final list was defined.
We initially wanted to make both a paper-based and an interactive map. We were unable to find an 'out of the box' interactive solution, however, and due to limited time and project resources, we decided at that stage only to make a non-interactive version. We created the map in Adobe In Design and plotted it on paper. The resulting map was a 0.9 m × 4.3 m poster (see Figure 2). We experimented with different layouts of the map. Our aims were to present the information both at the overview level and in detail, and to make visible how the information was related. In the resulting layout (Figure 3), the overview information was presented to the left and detailed information to the right.
The overview is meant to give the reader a frame of reference to use when deciphering the detailed information. It includes a descriptive title, a visual presentation of the ship's technical specifications, a description of the scene and introduction to the scenario, a presentation of the actors involved in the scenario, a written scenario story, and document information.
The detailed information section comprises the main part of the map, and is presented using a 'timeline matrix' , with a step-by-step description of what goes on. The timeline is not linear in a mathematical sense, meaning that there is no fixed scale; one step does not represent a set time period. We decided on this layout because we had a need for detailed information of very short time periods, and a mathematically linear timeline would result in an impractically long map.
Each row in the timeline represents a step in the scenario and provides: • the information and functionality the users need to be able to carry out each task; and • illustrative photos to provide contextual information. We used ACTA (Militello and Hutton 1998) to identify the steps that were particularly important to ensure safety, which we highlighted as critical points. The process of designing the map resulted in both our specific map and in a template, which can be used by other design teams as a starting point for making similar mappings. Figure 4 shows details of the map. Descriptions of each content element are provided in the guide in the Supplemental data.

Use of layered scenario mapping
We used the map both to gain insights into the situation to design for and in detailing our bridge design. It provided an organising principle to sort and make sense of the data on the situation to design for and helped us transfer knowledge from those project members who had taken part in the field studies to those who had not. Referring to Star and Griesemer's (1989) types of boundary objects, it was a 'repository' of data from field studies (although limited to the format), which could be accessed and used by all. It served as an 'ideal type' of the situation we designed for, in that it showed a generalised presentation of a typical way the scenario could play out. The timeline served as a 'coincident boundary' that could  encompass a considerable amount of the data gathered during the field studies. Although it was not used as a 'standardised form' , the layered scenario mapping provides a method for common communication of such scenarios in the future.
In UBC, individual team members used the map to generate and test ideas. The map served as a stage for a 'conversation with the design situation' (Schön 1983) and guided us in the process of detailing our design. We also used the map in collaborative sessions to discuss the appropriateness of ideas. The map further played an important role in a workshop we conducted with users. We used the map to prepare for the workshop, and in the workshop, we used the scenario as an outline for an enactment of our proposed new design in a full-scale prototype. We also used the scenario as a basis for asking 'what if ' questions, such as 'What if the scenario played out at a different time of year, or with a different type of ship?' This gave us insights into the diversity involved in the situation we designed for.
The first version of the map was thoroughly reviewed by two deck officers at Aalesund University College (one of the partners of the project), and we made minor corrections and updates based on their input. We found that the format of the map was well fitted for presenting our understanding of the situation to design for, and thus could also serve as a boundary object for engaging users and other stakeholders in the design process.

Guide
We developed a guide to using layered scenario mapping (see the Supplemental data). The guide can be applied directly in design projects to sort and map out data that have already been collected, or it may be used to identify information that needs to be mapped out, and to prepare for data collection activities, such as field studies. The guide is not intended as a definitive recipe; design teams using the guide must still identify a relevant scenario, decide what information they need to map out, gather and interpret the information needed, and design their final map. The content categories included, and the layout of the map, can serve as a useful starting point, however.

Discussion
In the following section, I will assess how layered scenario mapping meets the objectives presented in Section 3.2 and will consider the 'adequacy' of the technique in relation to Diggins and Tolmie's (2003) features of the successful design of outputs from field research. I will also discuss transferability and further development of the technique.

Framework to use when interpreting information
When designing the map, we found that the defined content and layout made it easier to sort and interpret data from different sources. The final map proved to be successful in helping us gain a holistic understanding of the situation we designed for, while at the same time providing the necessary details. This was especially true for those who had not taken part in the field studies.
Not all parts of the map were used to the same extent. The description of what happens in the timeline matrix was the most-used part of the map, and the design team stressed the visual elements as being important in gaining a broader understanding of the scenario. The written story did not play the role we expected in creating a frame of reference. This may be because the team members were already familiar with the scenario, and thus had a frame that enabled them to make sense of the details. The story did prove valuable in developing the map, though.
One shortcoming with the map that we observed was that we had not made visible connections between steps at different times that influenced each other, for example, the officers check the weather forecast in port to decide how to place the containers on the cargo deck, which informs how the vessel should be positioned in relation to the rig hours (or even days) later.

Facilitate sharing of data collected and insights gained
The responses from the team when they were presented with the map stood out when compared with other means of sharing data and insight from the field studies. The way the data had been filtered, sorted and put into a framework -particularly the timeline matrix -seems to have made the data more accessible. The map invited readers to delve into the material in a manner that we had not seen before. Some team members who had not taken part in the field studies stressed how spending a couple of hours going through the scenario helped them to get the situation we designed for 'under their skin' . As Beyer and Holtzblatt (1998) observed with their work models, our map became a substitute for doing field research. A few of the team members found that it was challenging to go through the map because of its extensiveness, although they acknowledged that the chosen scenario was inherently complex and thus not easy to grasp. The map made this complexity visible. The users validating the scenario made a similar observation; they were surprised by how complex this scenario, normally considered to be relatively simple, actually was when mapped out in detail.
As noted by Feast (2012), collaboration is more than merely distributing information. It is also about building new knowledge. We found that the map invited comments, corrections, and clarifying questions, and thus facilitated mutual knowledge development. This resulted in a shared understanding of the situation we designed for. The map's level of detail may have contributed to this understanding. Had a more high-level description been used, the readers of the map would have been required to add more information mentally, and different readers could have developed different mental models of the scenario.

Presenting the situation at the necessary level of granularity
The initial idea was that the current scenario would form a basis, from whence we could zoom out and identify functions that could be fulfilled in new ways in future scenarios. 'Functions' here refer to high-level goals. By asking 'why' something is carried out in the current scenario, the function at a higher level of abstraction can be identified, and by asking 'how' , one invites ideas for new ways of fulfilling the functions. Such an approach acknowledges that designing implies inventing new ways to work (Beyer and Holtzblatt 1998). The description of the current scenario would also help us to establish the framework conditions and to identify the details we needed in defining our designs.
In many ways, the map was successful in doing these things. It also invited many new ideas. As one of the project members said, 'I get hundreds of little ideas for how we can support the users from this' . One example is that the map demonstrated 'unnecessary' tasks carried out by the users, such as documenting actions in checklists, which could have been automatically registered. Another example is that the map made the parameters that the users check repeatedly during the scenario explicit, such as the vessel's position in relation to the set position, and the amount of bulk cargo transferred during offloading. Through the map, we identified the potential for presenting such information in better ways, using continuous visual and audio indicators.
We found, however, that it could occasionally be difficult to zoom out, and to consider the situation we designed for at a higher level of abstraction. On some occasions, we redesigned the interaction that was defined in the current scenario directly, rather than considering whether or not the user action itself needed to be redesigned. This is an example of constraints of future thinking (Diggins and Tolmie 2003, 152) and invites the question: is layered scenario mapping open enough? We had already used a range of open-ended techniques early in the design process, and we did not find that the map threatened the concept that had already been developed. Still, this may be a limitation to be aware of in future usage of the technique. Referring to our model for design-driven field research (Lurås and Nordby 2014), layered scenario mapping relies mostly on what we refer to as 'data mapping' . This was intentional, as we had a need for specific data. The limited focus on 'experiencing life at sea' and 'design reflection' , however, may invite the critique that the technique focuses too much on user actions, and does not evoke the designers' empathy for the users (similar to Nielsen's [2002] critique of scenarios). Many have stressed that empathy is vital in design and creative thinking (e.g. Leonard and Rayport 1997;Koskinen, Battarbee, and Mattelmäki 2003;Kouprie and Visser 2009;Mattelmäki, Vaajakallio, and Koskinen 2014). Layered scenario mapping builds on field research, which is a good way to develop empathy with the users. However, the design and content of the map influences to what degree the map itself evokes empathy. Our detailed descriptions of the users' tasks make it possible to envision what being in 'the users' shoes' would feel like, and thus support empathy. We suspect, however, that our final scenario could have benefitted from additional visual material, e.g. images from the users' point of view at each step of the timeline matrix. Others who intend to use the technique should consider how to evoke empathy through their maps and possibly find inspiration in techniques that emphasise empathy to a greater extent, such as contextmapping (Visser et al. 2005).

The 'adequacy' of layered scenario mapping
Although, Diggins and Tolmie (2003) focus on the transference of insight from ethnographers to designers, their features of 'adequate' design of outputs from field research also seem relevant when designers conduct field research and make representations for themselves and fellow team members. I, therefore, use Diggins and Tolmie's features in an assessment of the layered scenario mapping technique.

Economy
Our map was inspired by Giga-mapping (Sevaldson 2013) in its extensiveness, and took the form of a 0.9 m × 4.3 m poster. This size poster may seem 'uneconomic' . It is not easy to handle, and requires a large amount of wall space. Still, we found it appropriate in many ways. Too much emphasis on the economy of such representations may lead to simplifications, which can make the representation less useful. We found that the large format enabled us to present a substantial amount of information that could be accessed in parallel, and helped to create a holistic understanding of the situation. The presentation of information at different levels of detail made it easier to see how the parts related to each other, and to the whole. Having a paper-based representation did, however, introduce challenges when collaborating with team members located elsewhere. Although the map was shared as a PDF file, the PDF did, for example, not contain the annotations made on the poster hanging on the wall of our laboratory.

Appropriate format and ordering and logic of practice
The individual parts of the map were partly influenced by techniques we had former experience with, and were partly developed from scratch. The story in the overview information was similar to a textual scenario (Carroll 1995;Bødker 2000). The timeline matrix was influenced by hierarchical task analysis (Kirwan and Ainsworth 1992), timeline analysis (Kirwan and Ainsworth 1992) and STEP diagrams (Hendrick and Benner 1987). The visual presentation of the communication between actors was inspired by Comms Usage Diagrams (Stanton et al. 2005, 374-379), and the actors' position on the bridge resembled a link analysis (Kirwan and Ainsworth 1992) or physical work model (Beyer and Holtzblatt 1998). While the critical points were identified through ACTA interviews (Militello and Hutton 1998), ACTA does not represent the critical points in a timeline. The remaining content categories were included and designed based on our needs. We found that the layout of the map, and particularly the visual elements, played an important role in creating a holistic understanding of the context for user actions. A short introduction was valuable to help people read the map. Still, many readers of the map quickly understood its logic (described in Section 4.3) and started making sense of the content right away, presumably because conventional logic such as a timeline was used.

Indexicality
Our map hung on the wall of our laboratory and, as described, became a boundary object that was used in collaborative design sessions and was referred to repeatedly, and thus, held the feature of indexicality.

Iconicity, sequentiality and organisational accountability
We were surprised to see what an effect the map had outside of the core team of UBC. It became an icon of the substantial fieldwork we had conducted, and it resulted in a greater focus on field research within Ulstein. Another interesting observation was that the users validating the map started referring to it as an entity that conveyed the complexity of an operation. They stated that if we were to map out the more complex operation of 'anchor handling' , the map would have been twice as long.

Integration
We observed that people who were both internal and external to the project quickly obtained a sense of having a stake in the scenario. The map has been used as a resource in other projects within Ulstein, and the company now considers the map to be a business-critical resource. One reason for this may be that emphasising user needs and conducting field research in design for these industries is rare (Lützhöft 2004), and therefore few descriptions of the users' situation exist.

Transferability to other contexts
Layered scenario mapping was developed specifically to support the design of a ship's bridge. The technique is most relevant when designing for situations that include spatial and/or temporal dimensions. It may be used with little alteration when designing for moving environments in other transportation modes. When designing for other control environmentssuch as process plant control, involving control room operators and field operators -an adapted version of the technique may give new insights into the control situation. It may also be useful in other professional settings, such as hospitals where health care professionals collaborate on treating patients over time in different locations. Layered scenario mapping could also be used when designing for less complex scenarios in which the temporal and spatial dimensions are important, such as design related to mobile phones.

Further development
While I have shown that layered scenario mapping as described here can be used 'as is' , the technique may be developed further in many directions. For one, the content of the map could be elaborated upon. We mapped out the scenario from one perspective only: that of the deck officers on the bridge. We could have obtained broader insight if we had also mapped out the scenario from the other actors' perspectives -that is, the able seamen on the cargo deck, the engineers in the ship's engine control room, the crew on the rig, or even the on-shore personnel. Further, the layered scenario mapping technique could encourage more structured interpretations of what the current scenario would mean for a future scenario, and thus more actively invite 'design reflection' . One idea would be to include a layer that explicitly addresses 'what could be' .
New ways of presenting the map and its data could be considered in future versions. We found a range of benefits with our paper-based map: it made it easy to access information in parallel, and it supported the development of a holistic view of the situation; it invited annotations; it was easy to refer to in collaborative design work; and the physical map became an icon of the work conducted. It would still be interesting to investigate the benefits of digital layered scenario mapping, which, as originally intended, could serve as a digital 'repository' (Star and Griesemer 1989). Wodehouse and Ion (2010) have described the advantages of digitising information. Such information can easily be accessed, revised, edited and communicated across distances.
A digitised version could ease sharing and exploring the digital material collected during field studies (such as images, video, and audio recordings) and enable sorting and filtering of the data. Making raw data on users available to the whole team can result in increased empathy for the users (Kouprie and Visser 2009). In our experiences with different ways of reporting from field research, however, we found that it can be difficult to make sense of raw data. The logic of the scenario could therefore be used as an entrance into the data and presumably make it easier to make sense of the data. A digital map should also include the interpretations of those collecting the data.
Considerable work is needed to make a digital version. To attain the suggested functionality, all data would need to be described using a strict syntax. Another challenge is 'to find effective approaches to presenting and using digital information' (Wodehouse and Ion 2010, 4), and the map should be appropriately redesigned for screen-based use. Furthermore, one must consider how to maintain the advantages of the paper-based version in a digital version.

Conclusion
My colleagues and I experienced challenges with making use of the data from field research when designing a ship's bridge and developed the technique of layered scenario mapping as a response. Layered scenario mapping builds on existing techniques addressing the situation we are designing for, and combines these techniques in a unique way. The technique helped us make sense of fragmented data, and resulted in a map that supported our collaborative work. The map also became an icon of the substantial fieldwork we had conducted.
While layered scenario mapping was developed specifically to meet the needs faced when designing a ship's bridge, we expect that the technique can also prove valuable when designing for other contexts where the spatial and/or temporal dimensions are of importance.