Relation Artefacts Type IV

Abstract

This chapter is about relation artefacts Type IV which are socio-technical interventions in organizational and wider contexts. Three subtypes of these relation artefacts move the design from the technical to the social: interaction interoperability checkups, digital legacy interventions, and organizational strategy alignments. The HWID platform is shown to provide a massive push toward such interventions, through the continuous relations building between empirical work analysis and interaction design activities that aims to create new local sociomaterial realities for stakeholders involved. Ways of avoiding falling into a ‘techno-determinism’ trap and instead keeping the relations to the social, and vice versa, are introduced. The chapter ends with a summary of how to do socio-technical HCI design interventions.

6.5 Appendix

Evaluations with persona in standard (legacy) work scenarios

A part of considering legacy systems as socio-technical systems is to consider evaluation of legacy systems in terms of legacy (systems) work scenarios. In such work scenarios interventions are taken and used by expert workers with extreme amounts of practice on the relevant circumscribed set of tasks in that particular work environment (Feltovich, Prietula, & Ericsson, 2006). Evaluation of legacy systems interventions will have to be carried out in such scenarios.

The collegial verbalization (CV) evaluation method

When evaluating with classical UX and usability thinking aloud methods in scenarios where the employees are highly experienced, it is possible to go beyond the established protocols of concurrent and retrospective verbalizations, and include a third protocol of ‘conspective’ verbalization to achieve the needed (Erlandsson & Jansson, 2007; Jansson, Erlandsson, & Axelsson, 2015; Jansson, Erlandsson, Fröjd, & Arvidsson, 2013) In a concurrent verbal protocol the verbalizer is performing the work task, in a retrospective verbal protocol the verbalizer is remembering own performance, and in a conspective verbalization the observer is observing colleagues performance, in real time or as recording of past performance, whilst thinking aloud. Jansson et al. (2015) suggested an evaluation method they called collegial verbalization (CV) that combined the three protocols. The CV evaluation method is relevant for evaluating legacy work scenarios, since it builds on the assumption that when domain knowledge is shared between colleagues, one might find that they share cognitive strategies, and hence a colleague thinking aloud during observation of colleagues’ performance is just as valid as thinking aloud while performing own tasks. Thus, evaluation can be done with independent observers (colleagues) comment in the form of conspective protocols on the behavior of target users in legacy work scenarios well-known to all involved employees.

To identify the target users (the expert workers) to take part in the evaluation, a modified persona method might be helpful. The idea of a persona might deliver an approach to utilize the independent source of data of the CV method (Jansson et al., 2015), if the persona is cast as an expert colleague. Hence personas for selecting participants to do CV for relation artefacts type IV such as interaction designs for digital legacy should be codesigned among work colleagues (the experts) and data-driven with substantial understanding and description of the legacy work scenario(s).

Co-designing Data-Driven Personas for Organizational UX

Personas is a method that for several years has been applied in multiple domains. Though there is no standard definition of personas, there is agreement that it is a description of an end-user based on data with or with-out fictitious elements. Some authors emphasize that the persona description should contain a one-to-one correlation between data and the description. Other authors allow to include fictitious elements in the description for the sake of enhancing the empathy for the users (Nielsen, 2019).

However, the idea that personas should be based on data is being challenged by recent trends of Lean UX and co-design. Lean UX supports the integration of UX activities into the widespread use of agile development by using personas based on the design team’s assumptions. With the perspective of Lean UX, the emergence of the concept of assumption-based personas is spreading. The argument is that these personas are fast and easy to generate and a starting point for “proper” data-driven personas (Gothelf & Seiden, 2013). Similarly, within the participatory design framework the notion of co-designed personas has emerged. Co-created personas encourage users to engage with co-design sessions (Neate, Bourazeri, Roper, Stumpf, & Wilson, 2019). Common for both the personas based on assumptions and the co-created personas is that both have no underlying data. However, co-designing personas should focus on collaboration around the foundation of data for the persona, and that this is particularly important for Organizational UX.

What is known about data collection for personas in general is that data for personas can take many forms both qualitative (Miaskiewicz, Sumner, & Kozar, 2008) and quantitative (Jansen, Salminen, & Jung, 2020). The content is most often related to back-ground information such as demographics, information related to the system to be designed such as work tasks, use of technology, and relation to the domain. Data may also include general business and marketing related information, such as brand relationship, business objectives, and market segment size (Nielsen, Hansen, Stage, & Billestrup, 2015).

For employee-personas in legacy workplace scenarios aimed at designing for organizational UX, data may include data about organizational structure, employees, work tasks, work systems, and their interrelations. That is, who the persona will be with, where they are, what they are doing during the workday, and with what systems (Clemmensen et al., 2020). Often this will reveal a quite ordinary set of user experiences for the persona (Clemmensen et al., 2020; Meneweger, Wurhofer, Fuchsberger, & Tscheligi, 2018). Data collection for personas in workplace scenarios may require consideration of technology as a design element and how the relation between the users and the technical systems are transformed for this purpose.

Co-creating data understandings is a collaborative practice around using data for persona creation, inspired by the work of Feinberg (2017) that views data as something that may be designed through practices and the work by Seidelin (2020) that suggests a collaboratively practice of design with and of data and data structures. Employee data may be understood as the most important data for personas when co-designing personas for organizational UX that requires data about structure, people, tasks, technology and their interrelations. Employee data could be thought of as data about people. Such data is found in organizations’ HR departments. However, employee data should be considered more broadly and in relation to employee experience, that is, centering the organizational and interaction design around the employee’s total experience of the workplace (Plaskoff, 2017). We imagine that employees and other stakeholder participants in different ways can help collect data about structure, people, tasks, technology, and their interrelations. It is thus not enough to parse the HR department’s database; interviews and surveys with employees and managers at different levels may be required, before entering co-design workshops to create personas. An example of co-design of personas that include collection of data about structure, people, tasks, technology and their interrelations is the creation of contextual personas for the Swedish defense reported by Cajander et al. (2015).

Using co-created data understandings for designing personas for legacy work place scenarios may provide a solid empirical basis for designing alternative technology solutions to deal with wicked issues in organizations. Involving employees in co-design of personas can be done by using digital tools that support and empower employees focused data collection about personas. An example of using digital tools that support and empower employees focused data collection about personas is the automation scenario of manufacturing with (a legacy) collaborative robot proposed by Clemmensen and Nørbjerg (2019). Here employees use a digital tutoring tool that nudge them towards systematic data collections about a target user group of (expert) colleagues. Then, the tool supports the employees in identifying, prototyping, and evaluating interactions with the robot and of the social arrangement around the robot, based on the personas coming out of the data (Clemmensen & Nørbjerg, 2019).

In summary, (1) co-design of personas should primarily mean co-design of data-driven personas, (2) co-design of data-driven personas may be particularly important and possible when designing for organizational UX, since it can focus on the organization-specific employee experience, and (3) co-designed data-driven personas focused on organizational UX provides a solid basis for creative variation of socio-technical designs, and thus contribute to evaluation of legacy workplace designs.

Design case with HWID prototyping and interventions in a university course

The design task was to do a quick and dirty relation artefact Type III prototype and a relation artefact Type IV intervention. The context was a university course in a Scandinavian business school. It has a LMS (learning management system) with one module per teaching session. The users were mostly students with a need for feeling competent and the organizational problem was to support easy access for all students to teaching material. A one button solution, Fig. 6.4, was created based on relation artefact Type III subcategories, and evaluated.

Fig. 6.4

A one-button solution for overview

Figure 6.4 shows a prototype for both individual and collective user, as the LMS course was used by individuals and on a class basis. The organizational action hypotheses were to give students better overview of course modules to enhance the course capacity for learning. The prototyped worker experiences were a single-step interaction that moves the student directly to today’s session to give a feeling of overview. The field evaluations and UX tests were done as the prototyped hypothesis to be testes in the course setting with actual students interacting with the prototype was that the prototype would show positive indications of overview experience among students.

The data collection was done as individual and organizational UX and usability measures, with home-made “overview”-experience scales and qualitative interviews. The sociomaterial analysis was focus on relation artefact Type IV subcategories. The interaction interoperability checks asked the question if the solution would give the student a similar interaction experience as in other parts of the LMS course environment did? The digital legacy intervention asked the question if there was a way that the student could see the previous overviews provided by the user-interactions with the prototype for this specific course? The organizational strategy alignment asked the question if a one-button solution of this design would be the kind of experiences that the business school would want its students to have?

The theory and methodology in the project included theory about clinical overview in emergency rooms (Hertzum & Simonsen, 2010), field experiments with overviews for document navigation (Gutwin, Cockburn, & Gough, 2017), and particularly time and structure based navigation in web-lectures (Mertens, Brusilovsky, Vornberger, & Ishchenko, 2009).

The design contribution with relation artefact Type IV was thus the one-button answer to the questions of how the desired “experience of overview” in online course settings fitted to usual interactions of the students, if it was ‘their’ overview, and if this was a university-certified experience. The relation artefact Type IV discussions then again opened up for further discussion about if “overview” was the experience that was designed for, or was it perhaps the more classic “situation awareness” with its known socio-technical conditions and implications, see for example (Tharanathan, Bullemer, Laberge, Reising, & Mclain, 2012).