5.1 What Are Designers Designing at This Level?

Designing the infrastructure for value co-creation means creating the conditions for customers to create value. This involves designing physical or virtual spaces in which the interaction will happen, orchestrating the timing for coordinating the contribution of various stakeholders, and visualising opportunities for customers to aggregate the available resources to create meaningful value.

In fact, the designer’s activity at this logical level is much more concrete than at the value-co-creation level. Shostack (1982) used the analogy of a battery to describe the value proposition created at this level. Designing services at this level, according to Shostack, can be compared to the power stored in a battery. The battery has potential power, which can only be used once the contact is activated. Likewise, the service designed at this level consists of material and immaterial components aggregated in a way that creates potential value. Such potential can only become real value with the interaction with the customer.

A bank is an organised structure that is designed and made available for customers, but only when customers enter the bank (or when they access its online services) does the value of the service become evident.

The aggregation of material and immaterial components is based on social, organisational or cultural instances that designers need to interpret and represent in the service proposition. The combination of such heterogeneous elements—what Casper and Latour (2000) would define as socio-material assembly—could be offered by a service provider or a constellation of actors, and the possible configurations are the outcome of an activity of design, which puts together the elements on the basis of knowledge about customers, technical issues, organisational instances and cultural contexts.

Designing a bank service means arranging people, competences, technologies, and organisational instances that will support the interaction between the customer and the bank, both in the front office (i.e. in the very moment in which the interaction happens) and in the back office (i.e. in each action generated in the organisation of the bank, as a prerequisite or a consequence of the interaction with the customer).

At this level, service design consists of generating the physical or logical context, which represents the ecosystem in which value is co-created. This means designing service organisations, public administration functions, service platforms or even policy instruments that all deliver specific service propositions. This implies a collaboration between designers and private or public institutions, such as firms, commercial platforms, healthcare or municipal organisations, or taxation offices.

5.2 The Role of Design at This Level

The creation of services as the infrastructure for value creation requires the use of expert knowledge and capabilities concerning technical issues (e.g. knowledge about specific software), system organisation (e.g. understanding the structure of a company or an institution in respect to its mission), other specialised knowledge (e.g. about logistics, healthcare, et cetera), and social and behavioural knowledge concerning the customers of the service, their preferences, their attitudes and needs.

None of these capabilities are in fact specific to the designer, but rather they concern diverse disciplines, from IT to marketing. The role of design, however, consists of orchestrating such knowledge, possibly bringing together perspectives that may not be represented in the mix of expert capacities in a design team. Designers, for instance, often bring to the table user-related perspectives, as their expertise and education often include methods and tools for understanding customers. In addition, designers’ user-related perspectives may be the result of their own involvement in co-creation processes.

Designers facilitate the process of creating such infrastructure through their capability to represent logical architectures, interactions, time sequences and experiential elements of the service. The contribution of designers may consist in generating tangible elements for negotiation among stakeholders that interact in different moments, bringing about different cultures and practices into the system. By tangible elements, we mean elements that can be materially perceived or logically understood by the stakeholders. This highlights the role of orchestrator that designers can have in the development of new services.

5.3 Design Capabilities at This Level

Because of their role as orchestrators, designers’ capabilities must include connective knowledge between different disciplines. Designers do not need to be coders, but they do need to know what to do with the results of the coding. They do not need to be managers, but they also need to know what the managers need for articulating their strategies or how to translate managers’ idea of a service into concrete instructions that will make the service possible. In addition, they do not need to be marketing experts, but they do need to know how to elicit information about the customers’ needs and expectations about the network of stakeholders. This will contribute to value creation and the existing value and motivations that keep the service system together.

The expert capabilities needed in the perspective of design for infrastructuring include:

  • Open problem solving, which is an approach to problem solving that involves the creation and evaluation of multiple alternatives. This would support the organisation of service platforms, business models, or the interaction between customers and the technological components involved in the service architecture.

  • Building logical architecture, which refers to the ability to create value by relating each individual element to the architecture of the service, thus generating structures and frameworks that link and combine different knowledge into service propositions.

  • Vision building, which is the ability to model and visualise solutions into coherent representations of possible futures. Such visualisations include the representation of interactions among the actors, systemic maps and representations of business opportunities.

  • Addressing the context, or more specifically, the ability to align solutions to their social/cultural context or to existing policies or corporate missions.

5.3.1 Open Problem Solving

If we accept the axiom that the value in service design is only created by the beneficiary (Vargo and Lusch 2004, 2008), we must understand that the design of infrastructure that supports value co-creation must remain open to a range of possible alternatives: the different ways that beneficiaries or other actors may interpret the service, the different cultural backgrounds of the beneficiaries, and the different conditions of the interaction. We must also take into account that, as mentioned, value in services is potential value—it is only released when interacting with customers. The action of expert designers can be more or less prescriptive in respect to the behaviour of different actors in the service ecosystem: it would give precise indications of time and the sequence of actions for services based on mechanical or safety-related procedures—for example, the procedures for accessing or undergoing medical treatments—or provide a framework of behavioural indications, or possible interactions, much like the interaction rules in service platforms.

5.3.2 Building Logical Architecture

Infrastructuring means aggregating a number of heterogeneous elements, including objects, technologies, knowledge, people and spaces, according to a logical organisation that can efficiently and satisfactory address the needs of users, communities and contexts. This involves understanding the relations between heterogeneous elements, such as the interaction between people and technologies, power relations, social relations, and knowledge exchange. Every new service consists of an ecosystem, which implies a systemic approach to the organisation of such interactions. When building the logical architecture of a service, an expert designer should be able to navigate among different kinds of knowledge and provide opportunities for this knowledge to combine in many possible ways.

5.3.3 Vision Building

The organisation of infrastructure implies the capability of figuring out its possible configurations and the way such configurations will be interpreted or used by the service beneficiaries or other actors in the service ecosystem. Vision building is also vital in negotiating possible configurations of the service with service providers and other stakeholders participating in the service because it is a way to propose concrete images or experiences of the service proposition, including business, organisational or emotional aspects, before any element of the service is in place. This capability gives designers a role as facilitator in the process of creating the service proposition, as such visions support the negotiations and alignment of multiple views and interests.

5.3.4 Addressing the Context

Service propositions are always related to specific contexts. While the organisational structure of a service can be replicated in different contexts, it is essential that any configuration of the service provides a valid service proposition in each specific context. This means the capability to understand how the interaction among the stakeholders of a service can be adapted to specific situations or contextual conditions. Designers can work on supports, such as cards, templates, guidelines or procedures, that help the actors in each specific context to generate relevant value out of a service proposition. For example, cards might be used to help the communication between different stakeholders, whereas journeys can be used to support users in figuring out how to interpret and adapt a service structure. Such elements must be part of the structure of the service and complement the functional or organisational components of the service ecosystem.

5.3.5 Summary

Table 5.1 summarises the expert design skills needed in the perspective of designing as infrastructuring, including some of the most common tools used.

Table 5.1 Designing as infrastructuring: the capabilities needed and most common tools used
Full size table

5.4 Cases

5.4.1 Platform-Based Services: Social Housing

Introduction

The pressure of the housing emergency in many countries and the increasing price of real estate on the housing market in bigger cities require solutions to provide an attractive place to live to the more economically disadvantaged part of the population that would otherwise be priced out of certain urban areas.

Public housing policies have often proved insufficient in satisfying the housing needs of the economically weakest part of the population, and in some cases, large public housing developments have become ghettos, where the social and health conditions of the inhabitants are substandard, thus increasing social inequality in cities. In some countries, non-profit organizations have joined the effort to provide affordable and decent housing for all, thus generating a form of social housing that considered not only the basic need for housing but also the social need to create an attractive, fair and social-minded environment within the housing estates.

In addition to the financial effort for the construction or adaptation of the buildings, social housing requires means testing to verify the access rights to social housing, but in more recent history, some social housing organisations have also created platforms to accompany citizens in a process of integration and co-creation of the social environment in the housing estate. Those platforms aim at accommodating the functional needs in the shared housing estate environment with the habits and social needs of its inhabitants.

During a number of experiences with social housing, the Fondazione Housing Sociale (FHS—Social Housing Foundation) in Milan developed a platform to guide new social housing settlements or else ensure that existing social housing settlements maintain a healthy and positive environment.

The platform includes a number of tools (e.g. social cards) to support the settlement of the inhabitants and negotiate a way to live together, by deciding how to use common spaces, getting to know each other. The stacking plan (Fig. 5.1) allows inhabitants to indicate their family composition, social capabilities, age and preferences to book common spaces and facilities and organise events. The platform also includes a roadmap for the creation of new communities that includes pre-settlement periods—in which it is possible to figure out what kind of life is possible to live in the housing—and the actions to regulate everyday routine.

Fig. 5.1
figure 1

Reproduced from Ferri (2016)

A stacking plan is a synthetic representation of the families that are going to live in the same social housing building, including the composition of the families, their preferences and their contact information.

Full size image

Definition of the service nature

The social housing platform is an innovative version of a new family of platform-based services, in which the value proposed consists of a number of supports for negotiation, while the definition of the nature and the form of the value to propose is left to the platform user.

Platform-based services are becoming extensively diffused, and they target various aspects of our life, such as tourism accommodation, car sharing, tool sharing, mutual help, and food preparation and consumption.

The platform service provider mediates with different actors, leaving different ranges of options for the platform users to control the service and decide on the value to be created in the platform (Choudary 2015). The platform model takes different forms, ranging from neo-capitalistic configurations, in which a company has the power to control the flows of information and economic transactions, to distributed models, such as the cooperative platform of this case, in which decisional, power and economic transactions are controlled by a community of actors (Scholz 2014).

Role and challenge for designers

The role of designers in this specific project was to ideate and create the tools to support the negotiation process between the different actors. Designers directly participated in the meetings, proposing tools such as cards, templates, roadmaps and other community-building procedures. However, the direct participation of designers in the negotiation process is not always the case in platform-based services. Direct participation makes it possible for designers to understand the dynamic of negotiation and the way different practices and routines are proposed, compared and framed, according to the specific conditions of the housing and the neighbourhood. In other cases, direct interaction is not possible, and different strategies are proposed instead.

The experience acquired by direct participation is often ‘codified’ in the tools proposed (cards, templates, roadmaps) in a way that can be independently used by new communities, without the presence of designers. In other cases (e.g. in worldwide platforms for house rentals), the negotiation tools are progressively developed, on the basis of the feedback from the platform users, the problems and complaints emerging in the platform and most probably the direct experience of the service providers. In this case, the designer’s effort is still to codify and ‘pack’ various suggestions, providing inspiration or support and creating consistent stories, checklists, or practical indications for the users.

Design capabilities involved

The work of platform-based services is based on the creation of practical support, from apps, cards, canvasses and templates to roadmaps. The capabilities involved are:

  • Open problem solving: designers do not solve the problems of the social housing community but rather generate a framework in which problems can be better understood, framed or articulated in simpler parts. It is up to the community to employ the designer’s support to solve specific problems.

  • Building logical architecture: in platform-based services, this capability consists of identifying key roles or matching different practices and competences to be framed in an organised structure. In this case, the capability of architecture building uses a real-life example of architecture, the social housing building, to study and define the way different families will live together.

  • Vision building: in this context, this capability consists of proposing leading inspirations about possible directions that the community of social housing inhabitants can explore. This is particularly evident in large platform services where the participation to the platform depends on the service provider’s and the designer’s ability to give their customers a good view of the work they have to do together and the results they can gain from participating.

  • Addressing the context: platform-based services providers often propose an ‘unfinished’ solution that is meant to adapt to different contexts. However, it is important that the design of the platform can capture and incorporate the characteristics of the context within the mechanisms of exchange among the platform users. Cards (as in Fig. 4.1) or roadmaps to consolidate the community of inhabitants of each social housing dwelling are the elements that, in this case, supported the formation of different communities in different contexts.

5.4.2 Hackathons in the Open4Citizens Project

Introduction

The hackathon format has emerged in the past few years as a successful format to gather participants and jointly work on issues of common interest. At the end of the 1990s, hackathons were niche events mostly organised and attended by open-source software developers (Briscoe and Mulligan 2014). However, today the format of the hackathon—appropriated or reinvented by design, innovation and start-up communities—is increasingly used to organise events attended by a variety of participants (including non-expert programmers) and aimed at different scopes, from exploring new production processes (Tanenbaum et al. 2014) and tackling social issues through humanitarian technology (Linnell et al. 2014) to prototyping a new generation of services and new ways of commoning (Morelli et al. 2017a, b).

The latest case is that of the EU-funded Open4Citizens project, which, through new forms of collaboration between public authorities, citizens, interest groups, local businesses and IT experts, aims to (1) aggregate communities around open data, (2) develop a set of practices and infrastructures for using such data and (3) generate new public and private services.

Open4Citizens was articulated in several pilots that worked on various challenges ranging from migration to tourism within a shared framework of design processes, tools and methods to increase citizens’ awareness of open data and to engage them in the creation of new solutions for their everyday problems.

The citizens’ participation in the pilots was mainly supported through the organization of hackathons (Morelli et al. 2017a, b), which would bring together a local community with shared interests in specific problematic areas, such as public roadworks in urban contexts or issues related to healthcare, integration, pollen pollution or the regeneration of parks. Within the Open4Citizens project, it was soon realised that in order to mobilise the relevant stakeholders for a successful hackathon event, a ‘hackathon campaign’ needed to be launched, which started a few months before the actual event. Many of the activities of the designers were then devoted to building a solid interaction that would give relevance and effectiveness to the hackathon. The design team's work aimed at (1) aggregating a number of relevant stakeholders around the event, (2) raising critical issues with the relevant stakeholders (is the data ready? Is the challenge relevant?), and (3) promoting a new generation of public services based on open data.

Definition of the service nature

In the Open4Citizens hackathons, a big effort was spent managing and keeping the stakeholders involved and securing their contribution to the hackathon. In this way, the designers were ‘infrastructuring’, given that they were supporting the creation of a new ecosystem around the open data commons.

Role and challenge for designers

The role of the designer in this project has mainly been to ideate and create tools to support the collaboration among the hackathon participants (the hackathon toolkit), but most importantly, it is to ensure the support of the relevant local stakeholders, from public authorities to the data owners. While the tools that supported the event could clearly and easily be applied in the various contexts, the mobilisation of stakeholders and communities took very different paths in the different contexts.

Design capabilities involved

To mobilise the needed stakeholders, several tools have been used as practical support, such as canvasses, mind maps, stakeholder maps, cards, et cetera. Of all the capabilities used, some were more relevant than others:

  • Open problem solving: this activity characterises the very nature of hackathons in which problems emerge and are clearly defined through the interaction of the different stakeholders. The hackathon was used as a physical and logical place for conversation and negotiation rather than to find a finite solution.

  • Vision building: the designers had to convince and involve public authorities and other private/public organisations in order to share a common vision about the use of Open Data. The pre-hack work was often dedicated to creating such visions, while the hackathon itself was an opportunity to build shared visions, where the outcome of a hackathon is often regarded as a possible representation of such vision.

  • Addressing the context is crucial to understand what kind of value proposition the different stakeholders can bring to the table or can contribute to create. This capability has been crucial in the pre-hack activities, to define the focus of the co-creation exercise in the hackathon and to aggregate the most relevant actors that could interpret the instances from the context.