Chapter 6: Making data an explicit element in the co-design of
technologies and data sources that support their (data) work practices (see images 3 and 4).
In this case, however, the icons themselves did not illustrate specific data entities in a specific IT system, but acted as an ‘open’ category, where the data(sources) were
undetermined prior to the mapping exercise. The expansiveness of the icons prompted the domain experts to discuss and negotiate what constitutes a data source in this context. This emphasizes that although their representations may be similar, the design of the
representation and its intended (and afterwards actual) design and use may differ significantly.
This research shows that the concrete–abstract data design continuum is an important dimension to consider when designing data notation for co-design. Building on the examples above, it seems that abstract representations of data work better when the design task at hand is rather open-ended and undetermined, as was the case when the project group worked with data icons for the mapping. In contrast, during the first intervention, where the project was much more predefined, the use of more concrete data notation seemed to help the multiple stakeholders to relate the data to concrete data practices.
6.2 Routine and emergent data needs
The second dimension that became apparent as important for the work of developing and implementing data representations in co-design was routine and emergent data needs. The field work showed that at IU, there exist both routine and emergent data needs. Specifically, our analysis of the roles data plays emphasized how the established structures generate rather well-known and predictable data needs on an ongoing basis. These routine data need included, for example, statistics to support committee work. However, the analysis also showed that new forms of coordinated actions involved new data work, which further created emerging data needs (Publication 6). An example of emerging data needs was revealed by the education consultant, who changed the way stakeholders in the network cooperated around Elective Specialization Courses, by including a new data source. However, eventually, this emergent data need turned into a more routine data need, as many
education consultants in the organization and in the external committees began to use – and thus establish practices based on – this data source. Another instance where routine and emergent data needs became visible was during the first intervention, where domain experts from IU and external organizations (representing key stakeholders) worked with the data icons. This design activity took as its starting point the consideration of existing data entities in the IT system, and through discussions the participants were able to reach a mutual understanding concerning routine data needs related to their current work practices.
observed how emerging data needs also became visible (Publication 3). For example, workshop participants stated that the redesigned IT system should also be able to document the many meeting minutes that Local Education Committees are required to produce and share after each meeting. In this case, the emerging data need was expressed as a vision of making better use of this data source. Based on this, I refer to a ‘routine data’ need when data is identified as essential to supporting a data-based service that is provided regularly. In contrast, an ‘emergent data need’ describes a situation where data that has not been
previously used as part of a data-based service is introduced and identified as a useful service innovation or service provision. This research shows that it is important to consider the routine–emergent data needs continuum when designing data representations for co- design, because it supports reflection on the ‘state’ and ‘familiarity’ of the data: is this data critical for the organization to provide a specific data-based service? Is the data ‘well-known’
and already implemented in the organization somehow, or does the data involve an
increased level of complexity and/or uncertainty? In other words, routine and emergent data needs require different toolkits.
Current data science practices propose more sophisticated support for routine work, for example, how to use artificial intelligence to assist workers in local government to provide services to citizens (Publications 7 and 8). Through such data science practices, complex algorithms are embedded in established information systems; however, these algorithms mainly support routine data needs. An example is the increasing number of autonomous agents (‘chatbots’) in local government services, which aim to decrease the pressure of face- to-face and telephone services by allowing citizens to conduct transactions online
(Publications 7 and 8). Autonomous agents are often established and further developed based on routine data needs, for instance, frequently asked questions. Thus, to design with data in ways that support routine data needs requires organizations to be able to identify more specific and recurrent data needs. However, I argue that it is also necessary to consider how emergent data needs may be supported so organizations may take these evolving needs into account in the process of developing data-based services. Taking care of emergent data needs requires a different toolkit, because it implies that domain experts should be enabled to flexibly explore and analyse data and data sources. In co-design practice, this calls for tools and representations of data that promote exploration and experimentation with data, to further recognize emergent data needs.
6.3 A data mode map for co-design
I propose combining the two ‘data dimensions’ presented above (concrete and abstract data design, and routine and emergent data needs) to create a map that illustrates various ‘data modes’ in design. The map was inspired by Manzini (2015), who developed a ‘design mode map’ that illustrates the various ways design capabilities are enacted. By considering various modes of ‘designing’ and ‘being designers’, he suggests that the design mode map may support an understanding of who the design experts are, and what they do in various situations (Manzini 2015). The data mode map presented below (figure 8) has a different objective. It suggests an outline for how we may contemplate including data as an explicit element of the co-design of data-based services. I have populated the data mode map below with the main data representations included in this work, to illustrate the use of this tool. The data representations are mapped according to both their intended inclusion of data as an explicit element of co-design, and the use of their representation, meaning, how they were applied in a co-design situation. For example, the Data Sphere was intended to prompt users to think about new data sources that might be interesting in the context of service innovation in the organization. Moreover, The Data Sphere was used in an open-ended manner at IU, where all its members were invited to contribute their ‘data ideas’. Based on this, I have placed the Data Sphere in the upper right corner of the data mode map. I have done so to illustrate the tool’s the abstract configuration of data and simultaneously its aim to identify emergent data needs. It is important to note that this placement is based on a
specific instance in a specific context. That is to say, if this tool for representing data was applied to a new context, it might generate a different effect, and thereby position the Data Sphere differently on the data mode map. Thus, the data representations do not prescribe how the map is used. I suggest that the data mode map is a tool that can support
researchers’ or practitioners’ reflection on our (more or less articulated) intention to include data in co-design processes, and to reflect on the later use of a proposed data
representation. In this way, the map is a tool that attempt to address the difficulties of
reconciling an understanding of data as interpretive, flexible, and situational when designing (Feinberg 2017).
Figure 7. The Data Mode Map
Maps such as the Data Mode Map have certain limitations. From a critical point of view, this map might promote a more reflective inclusion of data in co-design processes; nevertheless, it is still a way of framing data. Thus, this map might support certain ‘data constructions’
rather than others. It is important to be aware of the ways in which it might generate certain constructions of the world that feed into the design of data-based services. Therefore, it is vital to critically consider – on an ongoing basis – whether the proposed dimensions are relevant, or whether dimensions are missing.
Another limitation is the map’s embedded assumption that organizations know how to go about developing data representations and apply these in practice. To be able to benefit from the idea of these different data modes implies that an organization has certain established design capabilities, in order to enact proposals to work innovatively with data.
The next chapter elaborates on this challenge by discussing how an organization with very limited design capacity such as IU can establish a culture of design and innovation.