Realising Grounded Design in practice: reflections on using Design Case Studies for practice-centred computing

4.1 Pre-study

We started our investigation with an ethnographic study carried out over a period of 10 months. Our main goal was to obtain a deep understanding of the needs of machine operators regarding industrial set-up, so as to identify opportunities for the design of a CPPS that would effectively support them with their work tasks. To that end, we employed several different data collection methods. We started by carrying out a series of observations of various machine operators setting up different machines for the production of assorted products. In addition to fieldnotes, we also recorded these set-up sessions by means of an eye-tracking technology (the Tobii Pro Glasses 2 eye tracker). This gave us an additional, fine-grained resource for exploring the tasks and operations involved in the process. We also used a Thinking Aloud approach, ⁵¹ where the participants described the actions they were undertaking and their rationales, so as to obtain further insight into what the participants were doing.

Following our observations, we interviewed a number of workers who: (a) performed machine set-up as part of their work routine – i.e., machine operators; (b) considered machine set-up as part of their responsibility – e.g., the foreman who supervised the production activities, including set-up; or (c) had tasks relating to it – e.g., construction engineers involved in the production of parts used for set-up. The interviews lasted from 45 to 120 min and were transcribed using the intelligent verbatim method, where everything is transcribed word per word, except for mumbling expressions (e.g., ‘ums’ and ‘ers’), filler phrases (e.g., ‘you know) and stumbles. ⁵²

Apart from the above, we also carried out some shadowing sessions ²⁰ to collect situated data on the work processes impacting upon the process we were interested in. These lasted from 3 to 4 h and were always associated with the observation of at least one machine set-up session. In these sessions, the researchers followed the participants wherever they went, observing their interaction with other colleagues in informal and/or formal meetings – e.g., shop floor meetings – and during other work processes that would have an impact upon any up-and-coming set-up sessions.

Last but not least, we also collected documents concerning the process – e.g., production plans, process descriptions, machine manuals, etc. We found it relevant to collect and analyse these documents because we were told that they constituted an existing attempt to document expert knowledge and make it available to other workers. Inspection of these gave us some insight into the companies’ overt understanding of what it took to undertake machine set-up and the associated processes.

In summary, the pre-study featured 25 participants from 5 SMEs located in two different European countries. All the companies were manufacturing firms working on the production of metal parts, either for the automotive or home appliances industries. We sought to recruit participants with assorted roles, a distinct educational background, and different levels of experience, so to have as holistic a picture of the process as possible. We also felt that this diversity would better represent the different stakeholders with an interest in the system we were hoping to design. Table 1 provides an overview of the participants and the activities they participated in.

All the material collected during this phase was analysed using Thematic Analysis. ²³ Thus, interviews transcripts, fieldnotes and collected documents were read and re-read and coded using a mix of bottom-up and top-down coding. By the end of the coding phase, the code schema featured more than 70 codes – e.g., ‘sequential execution of steps’, ‘expertise-based solutions’, ‘strategies to find answers to set-up problems’, etc. These codes were further developed into themes through careful analysis and characterisation of their relationships – e.g., ‘the workflow characteristics of industrial set-up’, ‘the knowledge-intensive character of the process’, and the ‘environmental constraints upon interaction with certain types of technology’. These themes led to the design implications that were pursued in the design phase.

The eye-tracking videos were also subjected to Thematic Analysis. Here, the videos were watched several times and relevant video excerpts were coded using the same strategy described above. Findings from the analysis were triangulated to enhance their trustworthiness and authenticity, two key quality criteria for qualitative research. ⁵³ The results of this phase were translated into user requirements to inform the next phase in the DCS framework.

4.2 Technology design

Once the pre-study activities had concluded, we entered the Design phase of the DCS framework. In DCS, the activities associated with the Design phase must be informed by the results of the pre-study. However, many members of our consortium were not familiar with ethnographic methods, making it difficult to just simply describe the pre-study findings to our stakeholders. We therefore had to look for other ways to communicate them. We ultimately decided to use task models and a scenario-based design approach ²⁸ because these offered presentational languages that the stakeholders would find more accessible. ²⁹ Previous interactions with members of the consortium made it clear that task models were also well-understood by both members of the development teams and partners from the companies. All the task models and scenarios were empirically grounded in our data analysis.

Overall, five design workshops (DWs) were performed during this phase: one involving just researchers and designers from the project; one in company A; two in company B; and a last one in company C. The first workshop was deliberately planned to take place without the users. Its goal was to discuss which technological solutions could be suggested to the users based on the findings from the pre-study. We knew from prior experience that it is important to already have some ideas to suggest to non-expert participants because they are often not comfortable with trying to think of solutions from scratch. In this case, it was even more important to have an initial suggestion because we were dealing with innovative technologies, such as the Microsoft HoloLens, and state of the art sensors, which are not yet widely available to the general public. We were also keen to get feedback on potential design ideas because it can be challenging to get participants from the manufacturing industry to engage in this kind of exercise. By way of example, we had to negotiate at length with managers to have access to their employees for workshop activities and sometimes had to wait months for an appointment, only to be confronted with last minute cancelations because of the contingencies of production.

In the first workshop, the scenarios and task models put together after the pre-study to support the Design phase were presented to the other members of the consortium. A brainstorming session was carried out and a series of design possibilities were identified. By the end of this workshop, we had selected a range of technological artefacts that could be suitable for a CPPS that would respond to the identified requirements.^[2]

The remaining DWs were conducted using the following protocol: we started by explaining the goals of the workshops and their dynamics; a 5 min presentation was then given about how we had processed the pre-study data; after this, we presented the scenarios based on the results of our analysis of the pre-study data; a half-hour discussion was then facilitated, with the participants being able to identify flaws in our scenarios and suggest adjustments; we then presented the potential solutions we thought met the pre-study requirements and invited the participants to think of any pros and cons they could see relating to them; the participants noted down their ideas on Post-its were then affixed to a whiteboard; after this, an affinity diagram was drawn, based on five themes previously identified during analysis of the pre-study data (hardware; content; usability and user experience; potential difficulties with the system; integration with the current work infrastructure).

Following the DWs we used rapid prototyping techniques to elaborate mock-ups for a few potential CPPS interfaces. These underwent heuristic evaluation ³¹ with five usability experts. The interfaces were then refined and sent to production. As soon we had the first functional prototype of the CPPS interface, we presented it to our users and undertook a first round of formative usability tests, predicated on the idea of cooperative evaluation. ³² These final steps are not discussed in detail here as they are beyond the qualitative insight to design pipeline that we are interested in but should be borne in mind as a necessary corollary of having arrived at a concrete design. The last phase of the DCS framework is also predicated upon these latter steps.

5.1 A task model for industrial machine set-up

As already noted, model-based approaches to developing interactive systems for different use contexts are widely accepted within human-centred computing and, as soon as we started working with our development partners, it became clear that they were already familiar with task models. We therefore decided to represent our participants’ practices during industrial machine set-up by means of a task model, to make it easier for them to support us during the development of the CPPS. In so doing, we were trying to elaborate a conceptual model of the system. ⁵⁴

For the purposes of the modelling itself, we used ConcurTaskTrees (CTT) ⁵⁵ to elaborate a practice-based model of industrial machine set-up. CTT is a established approach for task modelling, which relies on the use of a standard notation to describe the temporal relationship between tasks or applications. Table 2 summarises the components of this standard notation.

Table 2:

CTT notation. ⁵⁵

#	Background
	User task
	Abstract task
	Application task
	Interaction task
>>	Enabling relationship
[ ] >>	Enabling with information exchange
[ ]	Either/or relationship
| |	Concurrent performance
| [ ] |	Concurrent performance with information exchange
T1*	Iteration
[T1*]	Option
	Order independency
[ >	Disabling relationship
| >	Suspend/resume relationship
| | |	Independent concurrency

Figure 2 introduces a task model showing the positioning of machine set-up within the core process steps involved in realising a production series. This is composed of four tasks: the release of a work order; the machine set-up; the production of the series; and its final verification.

Figure 2:

Positioning machine set-up in the production series.

Our findings show that the informational basis of the whole set-up is the article-specific work order, which can be presented in both digital and paper form. As this is issued by a computer system, it is represented in our model as a system task. This task enables the next one, i.e., the actual machine set-up, by passing on the relevant information for it to be realised – represented through the relationship [ ] >>. In summary, this consists of the article number, the work plan, the parts list, and the geometric data, as well as the final quantity of the component to be produced. When the specific article to be produced is changed, the information specifies which elements are to be set up on the basis of the previous article (disassembly article) and subsequent article (assembly article). As soon as this information is available to the machine operator, the set-up process can begin.

A “+” sign at the right-hand side of a task indicates that the task in question is composed of subtasks. Figure 3 introduces a further level of detail to the machine set-up task model. During the pre-study, we learned that industrial machine set-up consists of two modules: static and dynamic set-up. ¹³ The former consists of operations covered by standard procedures and steps that can be easily reproduced. The latter corresponds to highly variable work procedures. The quotes below illustrate the empirical findings that led to this:

The set-up of the tools always follows more or less the same procedure […]. In principle, the contents of the tool’s assembly and disassembly are the same. (Foreman, Company A, Interview).

After the set-up, it’s the first part produced those counts. When I see it, I know whether I have to make further adjustments or whether I can release the series. […] Either it fits the first time, or you have to correct it several times. (Machine operator, Company E, Interview).

Figure 3:

Positioning machine set-up in the production series.

5.2 Scenarios and personas as discussion artefacts

While the task models that we generated were very useful for communicating with members of the development team, they were less useful for communicating the findings to the fieldwork participants or for grounding discussion in the general DWs. We found that fieldwork participants tended to find them overly abstract or to be missing the information they needed to properly understand them. We therefore decided to use a scenario-based approach for our PD activities with them. This is already widely considered to be an effective way of: reducing the lag between scientific knowledge and the design activities; providing opportunities to reflect upon design decisions; and working around bottlenecks that can impact upon the flow of a design. ²⁸ So, based on the identified requirements, we created two scenarios, which were illustrated by means of storyboards. Figure 4 shows an excerpt from one of the scenarios and Figure 5 presents part of the associated storyboard. These artefacts were used to foster the discussions in the DWs and as a resource to arrive together with the participants at how best to proceed with the design and development of a suitable system.

Figure 4:

Scenario excerpt.

Figure 5:

Storyboard.

As noted, the scenarios were very effective at firing up discussion during the DW sessions and with helping us to assess the extent to which the fieldwork participants felt that requirements we had identified would correspond to their needs and expectations. Potential technologies that could be used to address those requirements were also discussed in the DWs. This proved very useful and helped us to refine the requirements and elaborate the relevant implications for design. To begin with, the discussion in the DWs reinforced one particular finding from the ethnographic study, namely that operators were particularly interested in learning from each other and identifying the best approach for particular set-up situations:

Everybody has his own methods. So, he has chosen one method that works fast. […] This means using as few steps as possible. But we must discuss it, to derive the golden mean. […] That is something we have to do together. (Foreman, Company C, DW3).

The above quote suggests that workers would appreciate a way of exchanging experiences with other colleagues and working collaboratively to optimise the set-up procedures. In terms of design, this means that the system must allow workers to record and edit information about the steps of particular set-up configurations. This also suggest that the system could potentially implement changes in work practice and encourage a degree of standardisation of set-up processes. This would respond to demands from methods like Lean Management, which focus on the optimisation of industrial process and the reduction of waste. ⁵⁶ This is only an example of the requirements collected during the DWs. They were added to the requirements from the pre-study and further helped to orient our choice of technology and the system design, as will be discussed in the outcomes in Section 6. Table 3 summarises our empirical findings regarding the elements that a CPPS should have to support machine operators in their everyday work.

7.1 Enriching Grounded Design for the design of complex systems

In its original conception, GD ² stood as a strong corrective to more typical design-centred perspectives that could be found at the time. These tended to disregard the reflexive aspects of design interventions and the ways in which “appropriating an IT artefact for use changes the very social practices for which the artefact had originally been designed” (op. cit.). Although it doesn’t eschew design’s need for “artificial, formal schemes or materialised functions”, GD adopts a holistic view upon IT systems, recognising their sociotechnical character and the need to understand their meaningfulness in use. GD originally built upon Multi-grounded Design ⁵⁷ and Soft Design Science Methodology, ⁵⁸ but overtly sought to uncover the uniquely local character of the contingencies that shape the design and appropriation process. Understanding these contingencies demands the capture of copious amounts of qualitative data and, for these purposes, GD expressly promotes the use of DCSs. ² What is perhaps missing from this process description is a recognition that accomplishing these principles itself involves a series of interactions with different parties, whose interests and preferences dictate that the resources made available to them have certain distinctive characteristics that will facilitate the doing of their work. This is further accentuated in the case of studies such as the one reported here, where establishing what an appropriate design should look like is seen to be a participatory process that should involve users in its articulation. Indeed, the adoption of some kind of PD perspective is now commonplace in DCSs.

We saw above that abstract representations of work and its associated tasks do not necessarily support all parties equally in these kinds of discussions. In the case study, we turned to scenarios, storyboards, and personas to underpin our engagement with a wider cohort of stakeholders. It is worth teasing out what these kinds of resources offer in this situation. Although they do not necessarily state it overtly, the kinds of scenarios being used here are squarely based upon the findings of the ethnographic pre-study and the requirements that were identified. As such, then, they are a vehicle for communicating the findings and requirements. They make manifest an understanding of the world that was observed and the dominant issues within that world that have to somehow be overcome. Thus, they implicitly invite verification of that understanding because the participants have to find that world recognisable and the identified problems have to be seen as valid problems.

On the other hand, scenarios are highly selective in what they represent: they do not seek to convey the totality of what was observed. Thus, they are indexical of the larger body of work undertaken and have a reflexive relationship with that body of work that sits as a currently unexplicated resource, but that can be drawn upon and explicated by the ethnographers should the need arise. In other words, if the ethnographers need to underpin the scenario with other examples of things seen, they can do so. As such, the ethnographers themselves are also a resource that can be turned to, if necessary. Of course, the scenarios are not just stories of what was seen. Their whole purpose is to envision how a possible technological solution could support the identified practices. So, then, scenarios provide recognisable narratives of encounters with proposed technological solutions. ²⁸ Just as they do not seek to convey the totality of the findings, they do not seek to be comprehensive in the solutions they propose. In other words, in this context, they are designed to seed the dialogue and open up a conversation, not to dictate what that dialogue should look like. The personas used within the scenarios provide the participants with recognisable actors who share at least some of their attributes, thereby enabling more ready identification.

All of these features together enable the participants to see the proposed solutions within the work as an unfolding course of action, facilitating reflection upon how the work goes, the implications of the proposed solution for the accomplishment of that work and where it might break down as a consequence, constituting what Blumer once termed prompts to a ‘sluggish imagination’. ⁵⁹ In the case study presented here this was further facilitated by the use of storyboards. The comic-book type format of a storyboard adds various additional affordances, by giving primacy to the visual characteristics which, in turn, bring to the fore specific features of the scene and push others to the background, further facilitating identification, and, by using a frame-by-frame presentation, encouraging active engagement by requiring viewers to ‘fill in the gaps’ and complete the represented narrative. ¹³ Together, the combined use of scenarios, personas and storyboards constitutes a physical presentation, open to in situ deictic reference and annotation that promotes discussion and interrogation of the solutions being proposed.

The discussion of the possible solutions already in-hand is then generative in its own right of the proposition of alternative solutions that can themselves then be assessed, documented (e.g., by means of post-it notes), ordered and prioritised (for instance by their relative position on some vertical surface) and annotated, leading to a richer set of possibilities. With these materials now available, further mutually visible ordering strategies can be adopted, for instance by using resources such as affinity diagrams. These can be used to structure the materials gathered so far, e.g., by applying some kind of thematic organisation, sorting and categorising, indications of possible relationships, further re-ordering, revision, and review.

Nonetheless, we can see from the points already made above that storyboards in design workshops can operate, within the microcosm of a workshop, in a very similar way. They can do this by: providing co-present participants with a publicly accessible representation of a stipulated work protocol; enabling definition and specification of the protocol by the participants themselves by drawing upon ‘the ordinary skills of their professions’; giving the participants ‘control’ over the ‘interpretation and execution of the protocol’, with them being able to accountably ‘modify or deviate from the protocol’ by proposing alternative understandings, requirements and possibilities; enabling the dynamic representation of ‘state changes’ through in situ processes of annotation and, when the representation is used to seed further propositions, through the use of post-it notes; and, by the use of affinity diagrams and other organisational artefacts, the alignment of ‘multiple coordination mechanisms’. ⁹ Obviously, this can be considered a creative misreading of Schmidt and Simone, ⁹ but there are certain advantages to conceptualising the nature of the resources to be provided in this setting in this kind of way. Thus, there is strong sense in which bringing together scenarios, personas, storyboards, descriptions of work and possible solutions appeal to wholly ordinary and familiar ways of proceeding, in turn facilitating ready engagement.

Looking back to the case study, we saw that, to get to the point of being able to seed design workshops with effective propositions and materials, it was necessary to engage in an earlier round of discussions with designers and developers in the project team. While these parties may have had certain distinct characteristics and concerns, they shared a reluctance to engage with the fully detailed results of an ethnographic study. Instead, they asked for more ‘concrete’ representations of practice than quotes, sketches, and pictures. So, for some kinds of recipients, there has to be some distillation and abstraction for them to be willing to engage and they have to be provided with resources that are amenable to their own work practices and objectives.

In the case study reported above, we used ConcurTaskTrees to generate a practice-based model, but in principle, a range of models and formal representations can be used to achieve similar ends. Many such approaches draw upon a set of standard notations, as was the case above. Typically, these kinds of models are designed to capture some kind of relationship between their core features, e.g., temporal, spatial, interdependency, primacy, and subservience, etc. It is, of course, the case that these models are still based upon ethnographic findings and analysis of those findings, so they continue to do the job of communicating the findings and identified requirements. However, here, the presentation of the findings is summative and is itself designed to facilitate elaboration of a conceptual model of a prospective system that might in turn guide development.

An important but easily overlooked further aspect of the above workshop-based engagement with more generic representations of the work is the fact that they are presented by the ethnographers who originally undertook the study and who remain on-hand. All abstract representations of the work have an indexical relationship with the original, rich, and detailed observations. Thus, whenever clarifications, explications, elaborations, etc. are needed, the ethnographers are able to pull upon the more detailed materials and their own understanding of the setting. There are a number of affordances that attach to this. First of all, it provides the potential for the reasoning underlying the abstraction to be made visible and open to interrogation. The very fact it can be interrogated in this way also provides the recipients with a source of verification and validation, should this be required. Beyond and above all of this, having the original ethnographers available as mediators, it makes it possible for the recipients to engage in a dialogue with the representation, so that they can uncover how it is relevant to their own specific purposes.

It must be remembered, however, that none of this can be got to without the original detailed work and immersion necessary to grasp what goals the specific practices visible in a setting are oriented towards. For instance, on top of the rich and varied data we gathered in relation to our work on cyber-physical systems, a key outcome of our study was the extent to which an interest in expertise and knowledge sharing was underpinning the identified requirements. As a resource, the original ethnographic data provides a ‘thick description’ of the accomplishment of relevant activities within some specific domain. ⁶⁰ This can be elaborated through other resources such as documents, machine logs, eye-tracking, etc. It is analytically bounded in that sense-making has already been applied to its capture. This analysis is a member’s analysis, as the ethnographer seeks to grasp the point of view of the members of the setting and to reason as they do. It uncovers: the primary orientations and concerns of those doing the work; relevant dependencies; overheads, troubles, and bottlenecks; the accountable character of the work undertaken; and the constraints that shape the work’s realisation. This thick description then stands as a further resource for analysis, according to the exogenous interests of the ethnographers themselves.

Having arrived at a point where prospective solutions have been put forward and refined by different stakeholders, one can move towards the creation of mock-ups. These work differently as a resource in that they invite direct engagement, with users able to interact with them, even if only on paper, and situate them within their own workflows, so that the solution can be reasoned about and reflected upon, as though it were being used. This is no longer a constructed narrative, driven primarily by the researchers, nor is it an abstraction of general principles governing the work. Instead, the user can create a narrative of use for themselves that captures their own ways of doing. They can also ground this narrative within the specificities of their own work. Clearly, from a project point of view, this is a low-cost way of getting evaluation of a prospective technology. Mock-ups are also quicker and cheaper to iteratively refine. For other stakeholders, especially prospective users, they concretise what is being proposed and invite a different order of imagining that particularises the solution to their own practices and orientations to the work.

Above and beyond all this, each specific DCS forms part of a growing portfolio of design interventions. So, as each new project begins, it can be potentially seeded with the outcomes of prior projects. However, new stakeholders encountering the approach for the first time themselves need certain kinds of resources to fuel the initial conversations. Here, again, previous models and scenarios can both be drawn upon to illustrate the ways in which prior design decisions were arrived at and their outcomes, transforming prior work into transferable assets that can inform, in turn, new DCSs and GD.

7.2 Taking things forward: some sensitising questions

In Section 3, we looked at a variety of ways that have previously been discussed to facilitate bridging between the thick descriptions offered by ethnographic studies and the abstractions needed to develop effective designs. In this section, we want to consider how we have extended upon those approaches.

Something to note in particular is how we have focused here not only on the resources that need to be made available in order to facilitate an effective transition from rich ethnographic insights to effective designs, but also on the actual process. Within this process, different resources with different affordances are made available at different times in order to support the necessary interactions and considerations that have to take place. At the same time, it should also be noted that this process is tightly wedded to a wider adoption of GD and its association with DCSs. Clearly the process can be followed without subscribing to GD, but it is informed by GD throughout. This process can be very broadly described as follows:

1. Undertaking ethnographic research to identify requirements and obtain a member’s point of view (i.e., get access to the reasoning associated with those requirements).

2. Developing an overview or abstraction of the requirements through approaches such as task analysis/modelling.

3. An initial engagement with project developer/designers, drawing upon the overview or models to uncover ‘what we could be talking about’ in terms of a solution. Note, within this, that the model elements are indexical of real-world practices and that, within the actual course of the engagement, they are open to exemplification by having the ethnographers themselves available as a resource who can to respond to specific questions, etc. This underscores the fact that models, etc., are not self-sufficient in this kind of endeavour, but rather discursive objects, with their implicativeness for design still needing to be established through their use in interaction.

4. Using the outcomes of this engagement to inform, in turn, the development of scenarios, personas and storyboards envisaging possible solutions to seed subsequent discussions of technological possibilities.

5. Engaging with original participants and prospective users of the system by using the storyboards, etc., as further discursive resources to identify additional requirements and potential solutions.

6. The co-production of things like affinity diagrams to give structure to the discussion of the proposed solutions.

7. Creating simple mock-ups to illustrate the proposed design solutions more concretely.

8. Evaluating the mock-ups (preferably iteratively) to allow for further refinement.

9. Developing working prototypes of the designed solutions for actual deployment and in situ evaluation and understanding of appropriation processes (again potentially iteratively).

10. Using the developed resources and designed solutions both together and separately as transferable assets to inform other projects.

What the above can be seen to amount to is a full pipeline for moving from ethnographic findings to the design of solutions and their deployment that indicates the kinds of resources required at each stage, without stipulating exactly what those resources should look like. So, this is not simply a recipe to follow, but rather a framework or heuristic device that demands active reflection and planning. Something we want to place especial emphasis on here is that the reflection and planning necessitate the asking of what one might term sensitising questions throughout the process, not simply applying the process. These sensitising questions provide for the work of moving from ethnographic insight to design, but they in no way stand in place of that work. They are as follows:

1. What ethnographic materials are necessary and sufficient for the identification of not only overt requirements, but also the reasoning associated with those requirements?

2. Who are the different stakeholders in the project, how will interactions with them need to be handled, and what different kinds of discursive resources will need to be developed to best support those interactions?

3. Given the interests and background of the designers and developers associated with the project, what kinds of abstractions will best convey the identified requirements, without asking the designers to wade through detail that they cannot easily translate into implications for design?

4. How will the outcomes of discussions with designers and developers be captured and how will these be transformed into discursive resources that can seed subsequent interactions with other parties, such as scenarios and storyboards?

5. How will those discursive resources be presented to other parties, to invite engagement and how will their responses be captured?

6. How will their responses then be structured to actively guide the next stages of design?

7. How can mock-ups be produced that capture the sense of the generated propositions, requirements, and original understanding of what the work is about?

8. How can the mock-ups be used as a discursive resource in their own right to support evaluation and how will the responses to the mock-ups be captured to enable further refinement?

9. At what point can the mock-ups be used as the basis of working prototypes?

10. How, again, can early prototypes be used as discursive resources to facilitate evaluation and drive further development?

11. How will uptake of the deployed prototypes be monitored to assess levels of appropriation and how will that be documented?

12. How will the outcomes of the project and the materials developed throughout its course be packaged as transferable assets so that they can inform subsequent projects?

While practice-centred computing pursues a holistic and inclusive agenda, it also needs to be recognised that many designers have developed their competences around the very ‘artificial, formal schemes’ that GD seeks to step beyond. Many, for instance, will have been trained in ways that are more or less compliant with various IEEE standards for software requirements specification – e.g., – which advocate the use of highly formalised procedures and models to describe use cases and functional and non-functional requirements. In the case workplace technology design, it is important to remember that workplaces are replete with representations that, in one way or another, seek to stipulate work protocols, hence the original interest of Schmidt and Simone. ⁹ So, there is a sense in which a recognisable presentation of a particular work process resonates with these, providing a sense of familiarity. Workers are also familiar with contesting such representations and seeking their modification. Of course, conventional manuals etc., which the system described in the case study sought to progress beyond, exist in the same space. So, giving workers a visibly accessible representation of their work in a way that actively invites them to modify and elaborate upon it pulls upon an existing common-sense understanding of how representations of work might be played with. This, can be achieved through the use of scenarios and storyboards, as demonstrated in our case. Furthermore, task models, as noticeable in our case, can be powerful resources for the design of usable interactive systems, even those encompassing multiple devices. While this kind of abstraction elides situational specificities, for designers it offers other kinds of affordances, by enabling things such as:

1. An overview of multiple devices at the same time.

2. A distinction between different types of tasks and the resources required for their accomplishment.

3. Identification of sequential interdependencies.

4. ‘Hyperlinking’, i.e., the model can be drilled into to reveal other requirements, such as necessary metadata, input and output requirements, related documentation, etc.

5. Indication and capture of subtasks, i.e., it can connect to layers containing further detail.

6. Representation of both standard and variable procedures.

7. Representation of constraints.

Some care needed to be exercised in doing this because many such models have cognitivist origins, where psychological processes can be seen as being open to representation via mental models, which has been subjected to criticism in parts of the HCI community. Nevertheless, in view of its familiarity to our partners, we saw advantages in appropriating certain facets of task modelling within a more practice-centred representation. Put differently, the results of the analysis of the ethnographic study became the basis of the model. As we saw, providing for this involves the production of a different set of resources. This, of course, can be seen to resonate with prior work on resourcing design. Dourish, for instance, sees relatively abstract process descriptions serving as ‘boundary objects’ that can service communication between a range of different parties. It should also be noted that we found it expedient to present these materials prior to the design workshops where the prospective users were present. Here, then, it was possible to cultivate an initial round of design propositions that could be specifically worked up by project members with a design expertise. These then provided us with materials we could actively weave into the later scenarios to ‘seed’ the subsequent discussions with innovative possibilities that we would have found it hard to devise on our own. The strategy we adopted here of grouping together different kinds of stakeholders at different points in the design process and providing them with different kinds of resources is an essential part of making the process work. While the different facets of what we have put forward here were prefigured in the literature we looked at in Section 3 (and, of course, others we have omitted for the sake of space), none of that literature has given such a worked through pipeline that can be systematically used to enable the richness of real-world ethnographic observations to result in viable, sustainable and appropriate innovative design that is closely aligned with the needs of the original setting. One of the key concerns within this is to not over-stipulate and ride roughshod over the specific character of the domain being investigated, the interests of the particular stakeholders in that domain, or the specific configuration of the parties involved in bringing about some kind of intervention.