Participatory Collaboration Mapping of Design-Enabled Urban Innovations: The MappingDESIGNSCAPES Case

Abstract

Wicked societal problems, such as environmental issues and climate change, are complex, networked problems involving many intertwined issues, no optimal solutions, and numerous stakeholders. Cities are problem owners and living labs for finding solutions through design-enabled innovation initiatives. However, to reach collective impact, it is paramount that these initiatives can learn from one another and align efforts through collaborative sensemaking. In the MappingDESIGNSCAPES project, we piloted a participatory collaboration mapping approach for cross-case sensemaking across design-enabled urban innovation initiatives. We used the CommunitySensor methodology for participatory community network mapping and the Kumu online network visualization tool to help representatives of three urban prototype cases share and collectively make sense of their design lessons. In this first of two papers, we describe how we set up the MappingDESIGNSCAPES project as part of the DESIGNSCAPES urban design innovations R&D program; how we created a conceptual model of the collaboration ecosystems around design-enabled urban innovations; and co-created a visual knowledge base centered around the case and cross-case maps grounded in this conceptual model. We end this paper with a discussion of participatory mapping lessons learned. In the accompanying paper [1], we show how we used this visual knowledge base to drive a process of collaborative sensemaking to share lessons learned across cases.

1 Introduction

Wicked societal problems, such as climate change, are hugely complex, networked problems involving numerous intertwined issues, solution directions, and many stakeholders [2]. Cities are a significant contributor to these problems but can also be catalysts in finding ways out, acting as living labs to prototype and scale up solutions through design-enabled urban innovations [3]. Scaling up these innovations, however, requires an ongoing process of reflection: situating existing innovation projects in the overall problem space, identifying conceptual and operational connections between various initiatives, and identifying collaborative gaps and opportunities within and between new initiatives [4, 5].

DESIGNSCAPES (Building Capacity for Design-enabled Innovation in Urban Environments) is an EU H2020 program. Its aim is “to exploit the generative potential of urban environments in the highest possible number of European Cities to encourage the uptake and further enhancement and up scaling of Design-Enabled Innovations by existing enterprises, start-up companies, public authorities and agencies, and other urban stakeholders”¹. In successive calls (Feasibility Studies, Urban Prototypes, and Scalability Proofs), many local design-enabled innovation initiatives of different focus and maturity have been developed.

The DESIGNSCAPES initiatives vary widely, demonstrating many scopes, interpretations, and approaches to making these design-enabled innovations work. However, the value and potential impact of DESIGNSCAPES as a consortium and program of projects go beyond the local impacts of the individual initiatives. The whole - breaking both conceptual and practical ground in approaching design-enabled innovations (DEI) - may well be much greater than the sum of its parts.

MappingDESIGNSCAPES was one of the 41 funded so-called urban prototype projects in the second call of DESIGNSCAPES. In the call, prototypes were defined as “[a]n experimental release of a new product, service, process or other innovative solution, built according to a predefined guideline (including a feasibility study) and tested in a laboratory environment and/or in real life conditions, with or without the participation of its prospective end users.”² MappingDESIGNSCAPES could be considered a special kind of prototype, a meta-urban prototype, as it aimed to help other urban prototypes learn from one another’s experiences, representatives of those prototypes being the “end users” in our case. The design-enabled innovation of the project was therefore not to be yet another local urban innovation. Instead, it aimed at developing a prototype of a systematic yet practical participatory mapping-driven collaborative sensemaking approach to catalyze the sharing of lessons learned across design-enabled urban innovation projects.

In MappingDESIGNSCAPES, we used the CommunitySensor methodology for participatory community network mapping [6] and the Kumu online network visualization tool³ to help representatives of selected DESIGNSCAPES urban prototypes share and collectively make sense of their design lessons learned. This paper presents how we developed two essential knowledge resources – a conceptual framework and a visual knowledge base. The following paper presents their role in prototyping a systematic yet practical cross-case collaborative sensemaking approach. We did not aim to come up with a fully developed methodology. Instead, we wanted to show a proof of concept that it is feasible to make sense across multiple design-enabled urban innovation cases towards collective impact in addressing wicked societal problems.

The paper is structured as follows: first, we introduce the main ideas behind participatory collaboration mapping of design-enabled urban innovations. Next, we outline the MappingDESIGNSCAPES project, including the cases and the overall design approach. We then introduce the conceptual model underlying our participatory mapping and sensemaking efforts, followed by a description of the visual knowledge base used to construct and apply the conceptual model. We continue with a discussion of participatory mapping lessons learned and end with conclusions.

2 Participatory Collaboration Mapping of Design-Enabled Urban Innovations

We introduce design-enabled urban innovations and then describe participatory collaboration mapping as a process to capture and visualize the essential elements and connections of collaboration ecosystems. Next, we introduce the roles of the Kumu network visualization tool and the CommunitySensor methodology for participatory community network mapping in supporting the process.

2.1 Design-Enabled Urban Innovations

Global society is awash in wicked environmental problems, including climate change, war, migration, social exclusion, and health issues. These complex problems often seem impossible to solve, are long-standing, intractable, and come with many different opinions about possible ways to go about them [7].

A necessary condition for addressing such intricate problems is to build collaborative networks that focus on knowledge sharing and developing a common focus for interpreting and using that knowledge [8]. Social innovation, in which new ideas are put to work in meeting social goals, is a crucial process for such collaborative networks to engage in [9]. According to Smith et al., such innovation processes should be sufficiently broad in scope and ambition; adopt a multi-level perspective on socio-technical transformations; and take place via many pathways in evolving socio-technical systems of niches, regimes, and landscapes. Socio-technical regimes are the mainstream, highly institutionalized way of currently realizing societal functions, whereas, in niches, novel alternatives arise. Niches and regimes, in turn, are situated in broader (land)scapes of social and physical factors providing a macro-level context [10].

Innovation is closely interrelated with design, with design activities having user needs, aspirations, and abilities as their starting point. Involving users as core innovation process agents in co-design and co-creation is key [4, 11]. This design for innovation involves many different human and non-human design agencies, including expert and diffuse design by humans. However, the larger scapes and regimes also exert design influences, involving many meanings and functions [12].

Cities are stimulating and productive ecosystems for innovation design. They are the arenas where wicked problems materialize, provide many transition opportunities, and need innovations that align and synergize towards transition. Cities are thus crucial environments for the emergence of innovative interactions and relationships [13]. Still, how do the numerous stakeholders involved in cities work together effectively in such complex societal co-design activities, especially if they move beyond individual initiatives towards more impactful collaborations?

Reflective design communities can play an essential capacity-building role. Such communities are embedded in cultures of participation and have a clear design rationale, including the meta-design of getting the participants to act as designers and be creative [14]. Yet, how to organize and catalyze productive community reflection in a complex urban environment? One way to go about this is through a process of participatory collaboration mapping.

2.2 Participatory Collaboration Mapping

Society can be seen as a supra-community, a “community of communities” [15]. We prefer to speak of networks of communities, as not all communities need to be tightly interconnected. Urban society consists of richly overlapping, more or less interrelated, and interacting networks of communities and other stakeholders, such as neighborhoods, clubs and associations, learning communities around local schools, business communities, and, of course, the cultural sector.

To better understand what community networks are and how to strengthen them, both the network and community dimensions need to be considered. The network-aspect concerns the relationships, interactions, and connections among participants, providing affordances for learning and collaboration; the community aspect refers to developing a shared identity around a topic or set of challenges [16].

Community networks entail significant social complexity due to the number and diversity of the social players involved. Such social complexity results in the need for new understandings, processes, and tools that are attuned to the fundamentally social and conversational nature of work [17]. Communities working together means finding ways to build bridges across communal boundaries of cultures, languages, and practices. Those boundaries can be hard to cross, leading to many misunderstandings and much fragmentation. Essential here is sensemaking: turning circumstances into a situation that is comprehended explicitly in words and that serves as a springboard into action [18]. For members of community networks to learn from one another across their community boundaries, they require a well-supported process of collaborative sensemaking of the collaboration ecosystems – the organically growing systems of interconnected participants, purposes, interactions, content, and resources - that they form. This entails jointly finding out what their collaboration is about, what relationships and interactions their communities and contexts consist of, what collaboration resources are available, and what concrete opportunities exist for better working communities [6].

Still, how to make such collaborative sensemaking of collaboration ecosystems work in the case of large-scale transition innovation design? Maps may be instrumental, as they help to navigate complex territory. Visualizations, such as maps, are crucial in enabling societal transformations: they determine what we can and cannot see, what we notice, and what we ignore, and in this way, shape all that follows [19]. Yet how to create and use such maps in scalable urban innovation is still unclear. New methodologies for mapping such transitions from a multilevel perspective are therefore needed [10].

ICT - provided it is used correctly - can support the innovative design and the formation of creative clusters, which are complexes of interconnected activity, encompassing multiple domains and providing opportunities and incentives for productive cross-fertilization [20]. One ICT with powerful features for creating, analyzing, and interconnecting community network maps is the online network visualization tool Kumu.

Fig. 1.

An example of a Kumu map

Kumu: Online Network Visualization

Kumu⁴ is a web-based tool to capture, visualize, and leverage community and network relationships. Kumu maps consist of elements and connections between those elements (Fig. 1). A core feature of Kumu is that both elements and connections can be typed, and different layouts can be applied to different types. For instance, elements of a particular type can be visualized by their colors, icons, and sizes. In contrast, connections of a particular type can be represented by lines with a specific combination of color, width, and pattern (e.g., solid or dashed). Different views can then be applied to each map, in which Kumu shows custom selections of elements and connections of interest in the layout desired. Views can be constructed by selecting subsets of the elements and connections on the map and then applying a certain focus and/or filters. Focus allows one to zoom in on and out of the context of a selection on the map. Filter is used to select which types of elements and connections should be made visible according to advanced search criteria. A wide range of layout options can be applied based on the properties of the elements and connections selected. The resulting views get their own customized hyperlinks and can be easily shared.

However, mapping is not a neutral technology. What is to be mapped (but also what is NOT), who can access the maps, and how and by whom they are to be used is often very political: there tend to be many interests at stake and numerous different ways to look at these interests [21]. Providing ICT access is, therefore, insufficient in a societal context: the effective community (network) use of such powerful technologies needs to be explicitly shaped as well [22]. Creating community network maps and putting them to good use in supporting collaborative design communities for urban innovation like those in DESIGNSCAPES is therefore far from trivial. Instead, it requires a carefully tailored participatory mapping and sensemaking process of the collaboration ecosystems at stake. CommunitySensor is a methodology supporting this highly contextualized collaborative process.

CommunitySensor: Participatory Community Network Mapping

The CommunitySensor methodology supports inter-communal sensemaking [6], which can be used to help community networks grow the scalable multi-sectoral collaboration ecosystems needed in effective urban innovation [5, 22]. These ecosystems are of the essence to work towards more collective impact in addressing wicked societal problems at the societal scale needed, like the climate emergency (e.g. [10]). Strengthening the public interest, building the commons, and contributing to emerging, smarter network governance are critical aspects of interest in using this methodology.

In CommunitySensor, stakeholders, facilitated by a professional map maker, first define their mapping language (in particular, the element and connection types to use and the perspectives to make sense of their maps). Only then do they start the actual mapping and making sense of relevant parts of their collaboration ecosystem. This is a crucial difference from many other methodologies, which often start from a predefined set of knowledge types and modes of reflection. In CommunitySensor, participants first explore what is essential in their collaboration, starting from the everyday shared working language that conceptually connects them. This language is the first layer of common ground on which they build their maps. Participants then explore the maps on their own and collectively via a set of relevant perspectives in the ensuing collaborative sensemaking processes.

Participatory community network mapping is the participatory and iterative process of capturing, visualizing, and analyzing community network relationships and interactions and applying the resulting insights for community sensemaking, building, and evaluation purposes [6]. Applied to collaborative contexts, such as the case in design innovation communities, we also refer to this process as participatory collaboration mapping. Collaboration ecosystem maps are the core socio-technical design artifacts produced in and driving this collective mapping process forward.

Fig. 2.

The CommunitySensor methodology

In CommunitySensor, participants do not try to map their collaboration ecosystem fully, nor all at once: it is not a comprehensive information systems analysis or data modeling process. Instead, the initial “seed map” of the most important (in the eyes of the stakeholders) elements and connections only sketches the collaboration context around a common problem or question that is relevant, maybe even urgent, now.

In the subsequent sensemaking process, stakeholders then reflect upon the seed map using relevant map perspectives to jointly identify issues, priorities, and subsequent actions, as part of the common agenda-setting activities of the community network. These insights, grounded in an - at least partially - common conceptual reality, help inform stakeholders in designing and connecting their community network building activities. In this respect, CommunitySensor acts as a meta-methodology: it augments other community building and network development approaches but does not prescribe how this community network building will take place. Finally, relevant stories, data, and indicators can be added to the seed map in the community network evaluation stage. The process is reiterated, solidifying, and scaling up the collaborative common ground over time (Fig. 2).

In earlier work, we applied the combination of the CommunitySensor methodology and Kumu tool to many different collaborative community network settings. These include supporting the building of a local community of urban farmers; multidisciplinary agricultural field building at conferences; strengthening agricultural collaborations across local, regional, and national levels in a developing country; and identifying collaborative potentials in budding climate action coalitions [23,24,25,26]. However, the case most closely related to DESIGNSCAPES was part of another EU innovation project: BoostINNO. In that project, ten major European cities - with the Ukrainian city of Lviv as an observer - worked together on sharing knowledge about local social innovations learned in and with the public sector. Using CommunitySensor, we conducted two participatory collaboration mapping experiments: (1) finding relevant collaboration partners and (2) comparing social innovation lessons learned about urban spaces developed by each of the cities [27].

In MappingDESIGNSCAPES, we wanted to take the BoostINNO findings one step further. Whereas in BoostINNO, our primary focus was comparing the structures of the social innovation collaboration ecosystems of the participating cities (the WHAT), in MappingDESIGNSCAPES, we concentrated on the design processes in which such urban social innovations are being co-designed (the HOW).

3 The MappingDESIGNSCAPES Project

In MappingDESIGNSCAPES, our design-enabled innovation objective was to develop a proof-of-concept participatory collaboration mapping approach for effectively making sense across design-enabled urban innovations. Our goal was not to develop a fully developed methodology but to show proof of concept of the conceptual and practical steps needed. Underlying this approach was a conceptual model that provided the common meta-language on which to base mapping and sensemaking activities. Mapping and sensemaking results were to be stored in a visual knowledge base, which in turn was to be used as input for the next round of collaborative mapping, sensemaking, and conceptual model development. Thus, we engaged in a profoundly participatory co-design process of the MappingDESIGNSCAPES mapping and sensemaking approach, as well as the knowledge resources the approach produced and used. After introducing these knowledge resources, we present the cases in which we developed them and the design approach adopted in the remainder of this section. In the following sections, we will describe the conceptual model and visual knowledge base in greater detail.

3.1 The MappingDESIGNSCAPES Knowledge Resources

The MappingDESIGNSCAPES conceptual model and visual knowledge base drove the participatory mapping and sensemaking processes.

MappingDESIGNSCAPES Conceptual Model

The MappingDESIGNSCAPES conceptual model was to cover collaboration ecosystems around design-enabled innovations and to be grounded in the overall DESIGNSCAPES approach. At its core was to be the high-level MappingDESIGNSCAPES community network ontology: the element types, connection types, and core collaboration patterns that capture combinations of element and connection types relevant to the collaborative community. These patterns were a conceptual starting point for constructing relevant perspectives to make individual and collective sense of the maps produced. The ontology was to seed, position, contextualize and conceptually interconnect the MappingDESIGNSCAPES urban prototype case maps.

MappingDESIGNSCAPES Visual Knowledge Base

A visual knowledge base was to be largely implemented in Kumu, with its knowledge architecture firmly grounded in the conceptual model. The knowledge base was to implement and illustrate the conceptual model (including case examples taken from the knowledge base to illustrate the concepts); contain the urban prototype case maps, the aggregate maps for cross-case comparison, the core collaboration patterns, the common and individual perspectives applied to the maps; as well as a set of sensemaking stories produced in making sense of the individual and cross-case maps through the various perspectives.

3.2 The MappingDESIGNSCAPES Cases

Although the base layer of the conceptual model had already been constructed in prior work and a literature review at the start of the current project, the urban prototype cases were to play an important role in iteratively further refining and validating the conceptual model and knowledge base. The urban prototypes were to provide inputs for constructing their case maps, make sense of the conceptual common ground between their maps, and provide feedback on iterations of the conceptual model, visual knowledge base and mapping/sensemaking methodology. We selected three existing DESIGNSCAPES urban prototype cases. Given the limited resources, this ensured having sufficient differences in scopes and approaches, while still having enough capacity to go into enough depth in making sense within and across the cases. One selection criterion was that the cases needed to be from different regions in the EU. They should also have at least one broad thematic interest in common, so that representatives would be sufficiently willing and able to learn from the other cases.

Out of the 40 other urban prototypes, the selected cases were The Landmarks Net (Greece), SciberCity (Finland) and CityBarge (the Netherlands). The thematic interest they had in common was environmental sustainability. Here is a synopsis of their cases in their own words:

• The Landmarks Net (Thessaloniki, Greece): “the design and construction of a [green spaces] landmarks’ web, along in the area of the Municipality of Neapoli – Sykies (Greece) and their connection to the existing free-space urban context, parallel to the activation of a human network through educational interaction and participatory design”

• SciberCity (Lahti, Finland): “a participatory process to create future personas called ‘SciberPunks’ that could be used in more than human design scenarios for the purpose of building empathy towards the environment and its non-human inhabitants. The design process utilized real data and information as well as arts-based methods to support building empathy via data.”

• CityBarge (Delft, the Netherlands): “contributes to the livability of cities by reviving the canals and providing a clean, easy and affordable water logistics solution. Together with its partners, Skoon Energy, KOTUG International and FYNLY, CityBarge developed a fully electric push-boat combined with a system of mini-hubs on the canals.”

3.3 The MappingDESIGNSCAPES Design Approach

Our design approach involved three main stages: (1) defining (and refining) our conceptual model, which was to act as our common mapping language; (2) making the maps, including the conceptual model map and individual case seed maps, as well as the cross-case maps; (3) and individually and collectively making sense of the case and cross-case maps.

Stage 1: Initializing the Conceptual Model

We started our design process by taking the CommunitySensor community network conceptual model [23] and analyzing the visual knowledge base developed in the related URBACT BoostINNO project for element and concept types relevant to DESIGNSCAPES [27]. Furthermore, the initial version of our conceptual model included concepts selected from the DESIGNSCAPES body of research and program resources⁵.

Stage 2: Seeding the Maps

Using the conceptual framework as the foundation, we then defined the architecture of the visual knowledge base and implemented it in Kumu. Next, the knowledge base’s initial version was filled with case maps. Via interviews and surveys, using the conceptual framework as a basis for the survey design, case representatives were asked to outline their seed maps. A seed map is a starting map that captures an essential part of a collaboration ecosystem of a case around a topic of common interest to its stakeholders. It does not provide a complete or utterly accurate information or knowledge model but rather sketches the most important elements and connections, as seen through the eyes of the stakeholders. Since all maps used the same underlying conceptual model, they could be aggregated into collective maps, showing how things are done across cases. This allows various sensemaking questions to be asked, such as: how do/could you do similar things in your case? Why do you do similar things differently? Do we mean the same things by things that look the same? A conceptual model can thus make sensemaking exercises more connected, focused, productive, and scalable.

Stage 3.0: Sensemaking - the Plan: Focusing on Face-To-Face Design Sessions with Local Stakeholders

By analyzing and discussing the individual/aggregate maps from various perspectives, we aimed to explain and make sense of the lessons learned and further develop and test the conceptual model and knowledge base.

In our original plan, on-site face-to-face sensemaking was to take center stage. We planned field visits for the project leader to come to each city as a participant-observer in design workshops. The seed maps prepared in advance would sketch the respective local collaboration ecosystems on which the design projects focused. These maps were to focus on the design processes and roles related to the innovation interventions in the local collaboration ecosystems. In the design workshops, they would be discussed and revised with local stakeholders. This would lead to deeper insights about design roles and concerns and allow the project leader to collect additional observations on the design practices on site. Time was a constraining factor for the cases (case representatives joined MappingDESIGNSCAPES after their projects had already started, and their participation was voluntary). During those field visits, the project leader would first engage in a preparatory meeting with each design team, followed by the actual stakeholder design meeting and an evaluation meeting with the design team afterward. The project leader would summarize local observations and cross-case patterns in post-workshops research analysis. These findings would then be discussed in some additional joint online sensemaking sessions with all case representatives.

Stage 3.1: Sensemaking in Pandemic Times - Going Entirely Online with (Just) the Case Representatives

Due to COVID, the field visits and physical sensemaking sessions in co-creation workshops had to be canceled. Without access to local stakeholders for our initial purposes, our project now had to take place entirely online. We shifted the focus from analyzing detailed local design observations to iteratively developing the knowledge resources and collaborative sensemaking approach of the design-enabled urban innovation process in more depth. We focused on further detailing (1) the conceptual interrelationships of design concepts within and between the critical dimensions of problem domains, project scopes, and design processes; (2) the collaboration patterns, common/individual perspectives through which to view them, and (3) the individual and collaborative sensemaking processes.

As our alternative collaboration approach, we had the project leader construct draft versions of the various MappingDESIGNSCAPES knowledge resources and then validate and refine them with the case representatives in a series of online collaborative sensemaking sessions over several months. In total, 12 online individual sensemaking sessions between the project leader and representatives of the three cases separately and six plenary cross-case sensemaking sessions with representatives of all cases were held (Fig. 3). Furthermore, a closed Facebook group was used for additional informal updates and discussion in between joint sessions.

Fig. 3.

Online cross-case collaborative sensemaking

In the online sensemaking sessions, we examined different kinds of maps (the conceptual framework map, case seed maps, and cross-case maps) and various perspectives. Session outcomes included (1) identification of valuable and usable collaboration patterns in the various maps, (2) common and individual perspectives through which to examine those patterns (3) interpretations of the possible meaning of the content of the maps in the form of sensemaking stories and (4) suggestions to change the conceptual model, map content, perspectives, visualizations, and processes.

We present in more detail our conceptual model and visual knowledge base, which formed the mapping foundation of the cross-case collaborative sensemaking approach of MappingDESIGNSCAPES.

4 The MappingDESIGNSCAPES Conceptual Model

As significant effort was spent throughout the project on the (re)making of the conceptual model, we first summarize its development process before outlining the model itself.

4.1 Developing the Conceptual Model

The MappingDESIGNSCAPES conceptual model represents the DESIGNSCAPES take on the essence of collaboration ecosystems around design-enabled urban innovations. The foundation of this model was the existing CommunitySensor community network conceptual model. It was distilled from a range of collaborative community network projects by classifying common concepts being used in such projects in practice. It provides a set of main element and connection type categories related to the dimensions of Purposes, Interactions, Participants, Content, and Resources [23]. For example, an element type subcategory under Purposes is overarching Themes. An example of such themes are the UN Sustainable Development Goals, increasingly used in multi-stakeholder collaborations worldwide [28]. Although communities may use very differently named element and connection types, these broad categories help to provide crucial cross-case “conceptual hooks” for collaborative sensemaking. Another example of conceptual common ground concerns Interactions. In communities, these processes - including Conversations, Discussions, Meetings, Workshops, and Events - are vital to building community and collaboration: they are of the essence to make connections, build trust, and work together on common interests.

Before defining the first version of the MappingDESIGNSCAPES conceptual model, a brief review of the conceptualizations used in the related DESIGNSCAPES resources was done (e.g., the interpretation of design-enabled innovation in [3] and the DESIGNSCAPES Toolbox [29]). These resources turned out to be conceptually very rich and diverse. Integrating all of them in one comprehensive metamodel would have been detrimental to our goal of finding and comparing conceptual common ground between the cases with efficacy. Creating an overly complex conceptual model would have hampered mapping and making sense across cases in practice, given the real-world time pressures of participants. We, therefore, aimed to find a core of well-understood design knowledge constructs that could act as conceptual “boundary spanners” between cases of a very different nature [30]. Societal context dimensions we considered of particular importance, given the challenges of wicked problems. Such societal aspects are often lacking in more technically (software) engineering takes on design.

The starting point for this effort was obvious: the core conceptual structures underlying the DESIGNSCAPES urban prototype proposal form (e.g., Problems, Fields of Action, Project Focus, Project Orientation, Design Activities, and Design Tools). Much thinking had gone into those structures by the program management framing them and the project teams interpreting and writing their proposals around them. This meant those categories were shared, “alive,” and laden with potentially case-crossing meaning. On the other hand, the categories used were still abstract and likely not immediately actionable in the local contexts of the various cases. So, a further knowledge engineering task was to translate those DESIGNSCAPES categories to the “lifeworld” of participants so that these “conceptual bridges” were also rooted in very different local realities. Only after establishing this grounded conceptual foundation - a “sensemaking interlingua” - can it become helpful to start adding more specialized design concepts, such as possibly the numerous specific design tools and methods listed in the DESIGNSCAPES Toolbox [29].

Due to COVID, we could not observe local stakeholders jointly making sense of their design innovations while engaged in rich conversations. We had no access to their situated and subtle interpersonal interpretation, adoption, validation, and adaptation processes of design innovation concepts in their physical, hands-on design tasks. Instead, we concentrated on the conceptual meta-analysis of the knowledge resources and cross-case sensemaking processes. What our conceptual model now lacked in local stakeholder design diversity, it gained in methodological validation and applicability across the cases. For example, we now paid much more attention to cross-case sensemaking essentials: collaboration patterns and various types of sensemaking perspectives and practices, including cross-case storytelling.

The conceptual model evolved throughout our mapping and sensemaking journey with the case representatives. As it was so fundamental as a backbone to all our mapping and cross-case sensemaking efforts, we renamed it into the conceptual framework. In total, it took nine iterations to arrive at its final form (Fig. 4). Core changes in the framework included the classification of the elements and connections; the clustering of the elements, as well as their relative positioning on the map; differences between the conceptualization of local and global (= cross-case) elements; and alternative visualizations of the elements and connections.

Fig. 4.

The making of the MappingDESIGNSCAPES conceptual framework

Next, we outline the conceptual framework that resulted from those iterations.

4.2 The MappingDESIGNSCAPES Conceptual Framework

In analyzing the proposal structure, we arrived at three core dimensions to map design-enabled innovation projects: Problem Domain, Project Scope, and Design. They form the conceptual backbone for mapping and sensemaking activities and include main element types and connection types describing possible relationships between element types. Figure 5 shows the critical element types making up those dimensions.

Fig. 5.

Key element types of the MappingDESIGNSCAPES conceptual framework

Problem Domain

The Problem Domain makes DESIGNSCAPES stand out from more technology-driven urban design innovation programs with a more limited societal scope. Design-enabled innovation from the program’s perspective is about impacting the outside world, in this case contributing to the common good in the city. The core problem domain concept type categories from the application form concerned the DESIGNSCAPES Problems and Fields of Action. These are examples of “boundary objects that can be used to facilitate knowledge sharing across professional boundaries” [30], forming an interlingua between design projects regarding their WHY? and WHAT? Still, these categories are just abstract terms from the local stakeholders’ perspective. Therefore, they were mapped to Local Problems and Local Solutions, representing the actionable working languages in the various cities.

Project Scope

The Project Scope concepts help position each design-enabled innovation project. On the one hand, they characterize the local stakeholder network in terms of its innovation aims. On the other hand, they summarize the design approach used to try and achieve the objectives.

Main proposal terms related to the project scope connect the problem domain and design dimensions and include the Innovation Target, Project Focus, Project Orientation, Design Agency, and Design Approach. As the possible value options for each of these aspects were prescribed in the proposal template, using these to find minimal common ground on which to compare the scopes of different projects was relatively straightforward. However, as those options were broad in scope (e.g., Process Innovation as one of the options for Project Focus), there were still many degrees of freedom to interpret these concepts. This ambiguity was not a barrier in our experiments but in fact helped trigger inspiring discussions.

Design (Process, Outputs, Impacts, Context)

Design has many aspects, which we could not even begin to cover in depth in our model. With the Design Project as the bridge between the Project Scope and the other Design dimensions, we focused on the Design Process adopted in the design project as the conceptual core of this dimension.

In our model, each design process includes several Design Activities and supporting Design Tools. We only included the list of design activities used in the proposal form as this was relatively comprehensive and could provide a standardized language across cases. In design process research, numerous frameworks exist for classifying design activities. Allowing each stakeholder to define their own activity classification would have created too little conceptual overlap for effective cross-case sensemaking.

In modeling the design process, we looked at the activities and tools as initially planned, but also at those in fact applied. Complex socio-technical design innovation projects are often implemented very differently from initially envisioned, as the COVID crisis has abundantly clarified. However, as our mapping and sensemaking processes proceeded, we found that several additional local tools were used in the various projects. These differences turned out to be important in the cross-case conversations. We, therefore, relaxed the constraint in the conceptual model about only using the DESIGNSCAPES list of predefined tools and also allowed local tools to be mapped on the case maps.

As to modeling the outputs of the projects, we focused on the Design Proposals. These were the most concrete and fully developed results that all the projects had in common. Given case time, budget, and COVID constraints, the envisioned implementations of the proposals could only be partially completed. In future work, we aim to focus more on the implementation and scalability of the prototypes. More mature outputs of the design-enabled innovation cycle, such as fully developed, tested, and adopted products and services, could then also be considered.

For a tentative analysis of (potential) Impacts of these proposals (and their ultimate, scaled implementations), we engaged in mapping and sensemaking exercises on how they might contribute to addressing the problems and solutions identified in the problem domain. Such impacts were represented as connections between the conceptual model’s Design and Problem Domain dimensions. A typical connection found in the case maps would be how a particular design proposal could be a design for (addressing a) particular local problem or (implementing a) specific local solution.

We only did a very preliminary exploration of the Design Context. This is still a black box in the literature, involving many political, infrastructural, organizational, and societal conditions [12]. Context concepts may modify the other design concepts from the framework. Despite our limited analysis, we did find that certain contextual factors sometimes helped make better sense of the impacts of designs. An example was the Landmarks and Landmark Locations in The Landmarks Net case. These findings suggest such contextual concept types could, for instance, be included in domain mapping templates that might be used to initiate urban design innovation projects on green spaces in other cities.

5 The MappingDESIGNSCAPES Visual Knowledge Base

Having defined the initial version of the MappingDESIGNSCAPES conceptual framework, we started validating, testing, and refining it. To do so, we created an initial version of the visual knowledge base. Note that an ontology (in our case: the conceptual framework) and its associated knowledge base are entwined, with only a fine distinction between where the ontology ends and the knowledge base begins [31]. The knowledge base comprises the (implementation of the) ontology and the instances of its types (in our case, the element and connection types).

Based on the MappingDESIGNSCAPES conceptual framework, we defined the knowledge architecture - containing the map structure, element, and connection type definitions (including their field definitions and visualization conventions), and some initial perspectives such as the bird’s eye view on the collaboration ecosystem. We further populated the knowledge base with the case seed maps. We filled the knowledge base with common and individual perspectives and sensemaking stories (stored outside the Kumu platform). As we went along, we adjusted the conceptual framework, the perspectives, and the visualizations of the maps.

We now introduce our maps: the conceptual framework map, the three case seed maps, and three cross-case maps. The following paper presents the other knowledge base components (collaboration patterns, common perspectives, and sensemaking stories) as part of the collaborative sensemaking process [1].

5.1 The Conceptual Framework Map

The most fundamental map in the knowledge base is the conceptual framework map (Fig. 6), which underlies all other maps. It is abstract in that it only shows the possible combinations of element and connection types, not their instances (represented in the case maps). The conceptual framework map shows the element types at the heart of the conceptual model; the connection types by which these elements are connected; and the topological regions in which these element types are positioned.

Fig. 6.

The MappingDESIGNSCAPES conceptual framework map

General Visualization Conventions

• Circular shapes stand for organic concepts (e.g., interactions and individual participants); rectangular shapes for resources, content, and institutional actors (e.g., organizations).

• Large size and bulls-eye elements indicate concept type categories.

• Shadows indicate common, cross-case concepts (e.g., DESIGNSCAPES Problems).

• Solid lines in the problem domain indicate connections between common concepts (e.g., a DESIGNSCAPES Field of Action being a solution for a DESIGNSCAPES Problem), dashed lines between a local and a common concept (e.g., History and Identity Connection being an example of (DESIGNSCAPES Field of Action) Arts and Culture).

Map Regions

• An essential finding in our sensemaking sessions was the value of using different “map regions” to quickly visually position and contrast design dimensions across case maps (Fig. 7).

Fig. 7.

Map regions in The Landmarks Net case

Map Region: Problem Domain

• At the top of the conceptual framework map, the problem domain is modeled: the DESIGNSCAPES Problems (Crisis of Values, Social Exclusion, etc.), with their associated DESIGNSCAPES Fields of Action addressing these problems (Fig. 8). An example would be the field of action Alternative Democratic Models as a solution for the (DESIGNSCAPES) problem Crisis of Democracy.

• This map region also shows how Local Problems and Local Solutions are examples of DESIGNSCAPES Problems and Fields of Action, respectively. Note that the conceptual framework map does not provide actual examples of such local problems and solutions (that is what the (cross-)case maps are for). It does visualize which particular DESIGNSCAPES fields of action are related to what DESIGNSCAPES problems, however, as these are both cross-case common concepts, indicated by their both being shadowed.

• We use red to indicate problems and green to indicate solutions.

Map Region: Design Project Scope

• The Design Project is the starting point here (Fig. 9).

• The various project scope dimensions have different colors. Each project scope dimension’s possible values are modeled in the same color.

• Since all project scope dimensions and their values are common concepts, they all have shadows surrounding them.

Fig. 8.

Excerpt of the Problem Domain region of the conceptual framework map

Fig. 9.

Excerpt of the Design Project Scope region of the conceptual framework map

Map Region: Design Process

• We made the Design Process element big with a bull’s eye in the middle (Fig. 10). This central - but abstract - “container concept” can thus act as a clear visual anchor on which to focus in sensemaking discussions easily.

• Surrounding this central element – in the inner circle, are the Design Tools.

• The standardized Design Activities have a fixed position and surround the Design Process element in an outer circle. Design activities are grouped by the Design Process Step they belong to in the proposal (e.g., Design activity 2.1 Draw Ideas belongs to step 2. GENERATING IDEAS), these steps being on the outside of the design activities ring and visualized as (slightly larger) design activities themselves and capitalized.

• A Design Tool planned to support a design activity is represented by a dashed brown line, the fact that it was in fact used is modeled as a solid brown line in the (cross)-case maps.

• Design process/activity/tool concepts are modeled in shades of yellow, orange, and brown. All are shadowed since they are cross-case concepts in the conceptual framework (apart from local tools).

Fig. 10.

Excerpt of the Design Process region of the conceptual framework map

Map Region: Design Outputs/Impacts

• The solid conceptual connection between the design process and its outputs (i.e., proposals) is represented by a thick yellow line (Fig. 11)

• Similar to the Design Process, we made the Design Proposals-container element large with a bullseye in the middle.

• In some case maps, design proposal categories helped structure large amounts of design proposals and clarify their semantics (which helps better to understand their potential impacts on the problem domain). Design proposal categories are represented as larger versions of design proposal icons on the map.

• Design proposals are connected to the Local problems and Local Solutions they aim to impact in the case maps.

Fig. 11.

Excerpt of the Design Outputs/Impacts region of the conceptual framework map

Map Region: Design Context

Design context elements vary widely in scope and function (e.g., acting as inputs for design processes or classifying design proposals or local problems/solutions). Their visualization was therefore not standardized. Instead, we used symbols that matched their local context of use. Future work could use more standardized visualizations representing meaningful design context concept types (e.g., Landmarks).

5.2 The Case Maps

The visual knowledge base also contains case maps. For all three cases, an initial seed map was created. To this purpose, the project leader extracted relevant elements, connections, and descriptive text using the conceptual model as a lens to analyze the urban prototype proposal form submitted for each case. Case teams also answered two surveys to elicit additional information for the seed maps. The first survey captured how they saw their problem domain. The second survey was sent after some initial sensemaking sessions to capture in more detail what their design process looked like, both as initially planned and as it had turned out in practice regarding design activities and tools actually used.

Here we briefly characterize each of the case maps in turn. Note that although the maps differ in content and structure, one can recognize in each case map the underlying conceptual framework map in the topology of the map regions, the types of elements and connections, and their visualizations. One could argue that even when just looking at an individual case map, the other maps - and the cases they represent - are mentally present in the background this way.

Seed Map: The Landmarks Net

The Landmarks Net map (Fig. 12) shows many different design proposals at its center, many more than the other cases. This is a direct effect of the COVID crisis. Initially, the plan was to have a few physical co-design workshops with selected stakeholders, including citizens and experts, to develop elaborate landmark designs. Due to COVID, all those workshops had to be canceled. Instead, citizens were invited to create digital designs from home, using a template with landmark design elements such as plants, furniture, and people. They could then submit their designs online, which were exhibited via an online notice board. Instead of having only a few in-depth design proposals, there were now around 50 citizen submissions. Although the technical quality of the proposals was much less than the expert-assisted ones initially envisioned, the result was more participatory in terms of hearing many more citizens’ voices.

Fig. 12.

The Landmarks Net seed map

Seed Map: SciberCity

In the SciberCity map (Fig. 13), the rich set of design tools and activities stands out, in contrast to its - compared to The Landmarks Net - much smaller set of problem domain concepts and design proposals. This could be explained by its focus on developing an innovative technical design format instead of exploring the problem domain in-depth. The result was a more standard software engineering design trajectory than The Landmarks Net’s.

Fig. 13.

The SciberCity seed map

Seed Map: CityBarge

Fig. 14.

The CityBarge seed map

At first sight, CityBarge - like SciberCity - also seems rather traditional software design process-orientated, as many technical engineering issues need to be resolved (Fig. 14). Still, by comparing the maps, one immediately sees that the CityBarge problem domain was modeled much more extensively. Numerous (business, government, citizen…) stakeholder interests must be balanced to get an actual barge sailing and operating in a city’s busy canals. So, this case is an interesting example of a combination of social (problem domain) and technical (design) complexity.

5.3 The Cross-Case Maps

The next step was aggregating the case maps along the different Problem Domains, Project Scope, and Design-dimensions. For each cross-case map, we show an excerpt of a map discussed in one of the joint cross-case sensemaking sessions (more details on that collaborative sensemaking process in the accompanying paper [1]).

Fig. 15.

Excerpt of the Problem Domains-cross case map

The Problem Domains-Cross Case Map

In the Problem Domains-cross case map (Fig. 15), Crisis of Values was a problem addressed by all cases, while two also developed Environmental Awareness fields of action to address them. This helped the case representatives realize they were all engaged in a form of (environmental) value driven-development.

The Project Scopes-Cross Case Map

In the Project Scopes-cross case map (Fig. 16), all cases turned out to be working with Design Methods to Generate Ideas. This was a good starting point for a rich discussion on the shared common methodological ground in the various design approaches used in the cities.

Fig. 16.

Excerpt of the Project Scopes-cross case map

The Design-Cross Case Map

Fig. 17.

Excerpt of the Design cross-case map

Figure 17 shows an interesting application of how all three cases (not shown in the excerpt) used either one or both of the Personas and Experience Prototyping tools to support design activities that are part of three separate design process steps (Sketch, Listen to the feedback of users, Create insight by observation). Such shared patterns proved to be starting points for often surprisingly rich discussions.

These “dimensional cross-case maps” reduced complexity by each showing only a subset of elements and connections from a particular angle of analysis, compared to the overall map showing the complete collaboration ecosystem. However, we found them still relatively hard to interpret without further guidance. How could we more effectively and efficiently make sense of what we see here by making and taking “the right” perspectives? We describe the participatory mapping-driven collaborative sensemaking process we prototyped to address this question in our second paper [1].

6 Discussion

In this paper, we described how we prototyped two essential knowledge resources (a conceptual model and visual knowledge base centered around various types of maps) in the process of participatory collaboration mapping. This sets the stage for a process of collaborative sensemaking to compare and discover design-enabled approaches to addressing wicked problems at the local city level and beyond [1]. Such an approach is an example of collaborative visualization: the shared use of computer-supported (interactive) visual representations of data by more than one person with the common goal of contributing to joint information processing activities. Information processing in this definition refers to those cognitive activities involved in individual or collaborative visual information processing, such as reading, understanding, applying knowledge, discussing, or interpreting [32]. The main goal of collaborative visualization systems, strategies, and techniques is to achieve common ground, of which shared mental models are the foundation [33]. Significant collaborative visualization research challenges remain around analyzing and making sense of the data, including many social, task, and cognitive aspects [32, 33]. In MappingDESIGNSCAPES, we aimed to address at least some of those issues.

In this discussion, we reflect on the lessons learned and point at directions for future research and development concerning the mapping foundation of the collaborative sensemaking approach. We do so by examining the intertwined knowledge creation processes of collaborative ontology engineering and participatory mapping.

6.1 Collaborative Ontology Engineering: Laying the Conceptual Foundation Together

Creating a shared vision, brainstorming, exchanging creative ideas, and evaluating them in diverse multi-stakeholder partnerships presupposes first devising a shared language to reach a common understanding [34]. One fundamental process of participation - often forgotten in co-design- is having case representatives co-define the visual language they use to construct their maps and make sense of them. Ideas on creating meaningful collaboration languages can be found in the field of ontology engineering.

Ontology engineering is a consensus-building process in which a community of stakeholders agrees upon a common view of a domain of interest and how their shared knowledge can be conceptually structured in an ontology. In collaborative ontology engineering, stakeholders jointly agree upon their requirements and priorities, then propose and discuss various alternatives to create a conceptual model complying with these requirements and reflecting both their interests and the shared goals of their community of interest [35]. In MappingDESIGNSCAPES, we created a practical collaborative ontology engineering methodology that balances representing conceptual common ground and individual interests. We created a (design-enabled urban innovation) conceptual framework that grounded individual seed maps and cross-case aggregate maps.

Ontologies define a common knowledge-sharing vocabulary in a domain [31]. Many ontologies are heavyweight, including rigorous axiomatic definitions of concepts, relations, and functions. Our MappingDESIGNSCAPES conceptual model, however, is an example of a lightweight ontology, with only loosely formalized semantics, making concepts open to multiple interpretations [36]. This is in line with standard practice in ontology engineering, to model the concepts among which domain experts commonly make a distinction without modeling the distinctions themselves [31]. This limited degree of formalization sufficed for our purpose, with our maps only providing seed content to trigger rich sensemaking conversations across cases. Through our experiments, we established and validated our conceptual foundation regarding core elements and connection types. We did not define semantic constraints on, for instance, canonical (permitted) uses of concept types in connection types or permitted attribute values within concepts and connections. This could be future work, although creating meaningful higher-order socio-technical collaboration pattern languages and processes for sparking and focusing human conversations rather than machine-dominated pattern generation and analysis remains our primary goal.

As to what such socio-technical pattern languages might entail, some promising, potentially more universal domain patterns came to the fore. For example, in the CityBarge case, many socio-technical design considerations in their local problem domain were mapped. Such proto patterns might also be helpful for sensemaking when introducing waste barges in other congested cities. Similarly, the design considerations around introducing green spaces in The Landmarks Net, including such concept types as Landmarks and Landmark Locations and knowledge categories like Historical Identity, Sentimental Interaction, and Connecting with Nature, could be instructive in similar projects in cities elsewhere. Our collaboration patterns are still rudimentary and specific, as they were created for the practical sensemaking needs experienced by just our participants. In future work, we aim to expand the reusability and interlinking of these patterns, leading to more mature collaboration pattern languages for design-enabled urban and regional innovation. Related design pattern languages to draw inspiration from can be found in the Human-Computer Interaction tradition, e.g. [37, 38]. Although helpful, these are not sufficient to capture the societal dimensions, such as problem domain and design contexts, that need to be considered when scaling up collaborations towards real collective impact. Higher-level “societal-technical” pattern languages could prove inspiring here as well. Existing urban and regional design pattern languages like [39] come to mind. Another example is the LiberatingVoices pattern language for empowering communities, which we used to design collaborative scenarios for collective climate action in related work [2].

6.2 Participatory Mapping: Applying the Concepts to the Messy Real World

In collaborative ontology engineering, community members systematically evolve their joint ontology in incremental consensus-building processes [35]. For us, our ontology/conceptual framework is not a goal, but a means for collaborative sensemaking. It provides the initial common conceptual structure(s) to create maps that provide an overview, focus, and connection. Such maps need to be meaningful within and between their communities of use. For “[Kitchin and Dodge], maps are fleeting, without any ‘ontological security’ […] Maps are practices: ‘they are always mappings’: they argue that we need to shift from ontology (how things are) to ontogenesis (how things become)" [40]. Just grounded in their own isolated reality, such fleeting maps are often the output of physical brainstorming sessions. Here participants create detailed maps, often by sticking numerous post-its on empty walls. Enthusiasm is high, but the half-life of its collective meaning is often short once the participants have left and gone back to their organizations. We would argue that our maps are between the situatedness of such fleeting maps and the more or less stable representations of typical ontologies. Our conceptual framework provides just enough ontological security, helping to anchor and find meaningful connections across case maps while also allowing the maps to preserve local, situated terminologies. This way, maps can act as shared boundary objects to talk about, think with, and coordinate perspectives and actions [33]. Boundary objects inhabit several communities of practice and maintain a constant identity [41, p. 16]. They help communicate and coordinate the perspectives of various constituencies by performing a brokering role involving translation, coordination, and alignment among the perspectives of different communities of practice coming together in a community of interest [14]. Our cross-case MappingDESIGNSCAPES community is a meta-community of multiple interest spanning local communities of (design) practice. Their seed and cross-case maps, viewed from various perspectives, provide the conversation triggers and conceptual bridges for effective collaborative sensemaking processes.

One more remote yet intriguing mapping finding of our project can be described as “the overview effect.” Yaden et al. describe this phenomenon as the overwhelming sense of oneness and connectedness reported by astronauts seeing Earth from space. It has been shown to help shape how individuals understand and approach new concepts, generating the motivation to make sense of such an intense experience in one’s life narrative. By altering the conceptual framework through which individuals approach new information and make sense of old experiences, it prompts changes in conscious reflection [42]. Of course, our “bird’s eye views” of collaboration ecosystems were only a much-watered-down version of such transcendent outer space experiences. Still, we did occasionally experience “micro-overview effects” of our own. What properties of maps might induce them more systematically could be a fascinating topic of investigation.

7 Conclusion

Wicked problems such as climate change urgently need much increased societywide collaborative capacity. Cities are a crucial enabler of this transition, with design-enabled urban innovations leading the way forward in the multiple transitions underway. This first of two papers outlined the participatory mapping foundation of an approach for collaborative sensemaking across design-enabled urban innovations: the MappingDESIGNSCAPES methodology. The core of the mapping foundation consists of two knowledge resources: a conceptual framework and a visual knowledge base of individual and cross-case maps. MappingDESIGNSCAPES itself is grounded in the CommunitySensor methodology for participatory community network mapping. We used the CommunitySensor community network ontology as an “upper ontology” to circumscribe the MappingDESIGNSCAPES conceptual framework tailored to the more specific needs of urban innovation design collaboratives. We found this weaving of a generic community network mapping approach with an urban design innovation-domain fruitful. It helped to efficiently map the essence of local urban design innovations into concepts and terms that were both locally meaningful and could be connected and compared across local cases. How those connections helped to make better collaborative sense of both wicked problems and design solutions within and across urban cases is what our second MOVE paper [1] is about.