Introduction

Background

The software usability approach set out by Gould and Lewis [130] in 1985, of a continual focus on users, empirical measurement of usability, and iterative redesign to resolve problems, is still the basis of most current practice as described by practitioners [129,53,363]. However, evaluations of usability testing methods have raised concerns about their reliability [183,242,327]. Even experienced usability professionals carrying out usability inspections will not find all the usability problems in the product [242]. Analysis of a design early in a product’s life, to identify undesirable interactions before it is built, is normal practice in the safety [87] and security [232] domains, but not in most other business contexts.

This research explores current user experience design practice in the IT sector through empirical studies with practitioners. The focus is how interactions that are undesirable are identified, because they are contrary to the interests of the users. The practice area of interest is the discovery stage when designers are working to understand the user’s aims and identifying opportunities to achieve the desired outcomes.

Undesirable interactions

In this research I focus on undesirable interactions that stem from incorrect and unchallenged assumptions at the design stage, that result in unwanted outcomes. These outcomes can range from the local, affecting a single user, to the global, affecting large numbers of users and potentially having consequences for wider society. I focus on outcomes within the scope of the application design, which will generally be those that directly affect its users.

Users are sometimes annoyed enough by undesirable interactions to comment on social media, as in the following example. Mobile phone applications are increasingly being used instead of paper ticketing, and train station barriers have been adapted to work with them. These applications also gather customer feedback, but sometimes ask for it when the phone is being used at a barrier, blocking the ticket code from being read [72]. Any assumption that users could always see the screen when using the application was invalid, as the phone is held screen-down to be scanned by the barrier.

Some examples are serious enough to attract media attention. In 2015, The Guardian reported that automatic image tagging at Google and Flikr was labelling dark skinned people as animals [178], and as recently as 2020 face recognition failures were still reported to be erasing black people from Zoom meetings and cropping them out of Twitter pictures [149]. Regardless of what technology was used to build these systems, the underlying problem was their discovery process as it did not adequately identify who the product was being built for.

Interaction discovery

Identifying undesirable interactions is not only a problem in software design, it is also a problem in drug design, where biological interactions might lead to adverse side-effects [253]. There it is called “interaction discovery”, and I have adopted the term to describe any methods that might be applied to a software design or product to identify unwanted interactions between it and its users, or with other software, or between the users themselves.

The earliest opportunity to start interaction-discovery is when designers are beginning to understand the user’s aims, identifying opportunities to achieve the desired outcomes, and visualising solutions that will provide a positive user experience. During this stage user researchers are planning and conducting research activities to gathering the information needed. These early design activities are described by Torres [363] as discovery.

Definitions vary, but the term discovery is widely adopted by practitioners, and by the GDS in its training material [131]. Discussion of discovery as a distinct activity is less common in the academic literature, due to the limited research into design practice in industry. Reviews of practitioner oriented ‘grey literature’ [246], and recent case studies, show a variety of prefixes in use distinguishing the aims, such as design discovery [44] and product discovery [53], or the methods, such as lean discovery [57] and continuous discovery [363]. For the purposes of this study, those distinctions are not significant, as practitioners may select from several authors when tailoring their own approach.

Usability inspection [251] methods such as heuristic evaluation and cognitive walkthroughs, which require expert evaluators, and usability inquiry methods, that involve current or prospective users to gain insights into how they will use it, require at least a detailed design and usually a prototype of some kind, so cannot be applied until sufficient discovery has been completed. Methods that try to anticipate problems, such as “consequence scanning” [45], are now emerging but do little to frame the problem or provide the scaffolding that I believe, based on my own past experience of safety analysis, that practitioners will need in order to identify undesirable interactions and address them early enough, before they are embedded in the design and expensive to resolve.

With current methods of framing [172], discovery activities do not usually consider whether any interactions implied by the design might be harmful or place the user in jeopardy unless the problem is potentially a safety or security issue. Finding that undesirable interactions are often not considered in advance, the present work aims to integrate the anticipation of undesirable interactions into discovery.

Ethical properties

The ethical property that engineers are most familiar with is safety, and whole professions exist to establish and assess it. Other whole-system properties are important enough that the law demands them, such as equity and proportionality, or are associated with particular circumstances, such as dignity in healthcare. Considering different experiences of a design, centred on these properties, is general enough to use early in the design process, and refinable enough to build into detailed service blueprints.

Study scope

This thesis concerns UX design practices used in industry. Safety and security issues may overlap with UX and share a common basis, as I discuss later, but generally their impact means they require different methods. In framing the research questions, I focus on interactions that the intended users will consider undesirable. There are circumstances where designers and users will disagree on which these are, but recognising the imbalance of power between them I have taken the side of the user. Malevolent use belongs to the security domain. Knowingly reckless or malevolent design [136,137] is likely to be unethical if not illegal, and would not be avoided by further methods of discovery. My focus is the inadvertent and accidental.

Assumptions about how long software would remain in use led to urgent work before 2000 to correct leap-year calculations and date formatting [103], and that kind of problem will continue to appear. However, I do not address legacy issues as it would be unusual for a design to include an explicit ‘sunset clause’ setting a finite life for its use, and I wish to focus more on challenging assumptions about ‘who’, and ‘why’, and ‘how much’ rather than ‘when’ as the important questions.

Assumptions can be embedded in data, and can result in unfair outcomes. For example, when predictive models are applied to policing and probation services [30,49], feedback loops could reinforce previous patterns [241]. Using research data from a context shaped by historical unfairness requires particular care, and skills from other disciplines, so is outside the scope of this thesis.

The problem addressed by this research concerns emergent properties and non-functional qualities, the need to be resilient and adaptive under change, the need for new structuring schemes to separate concerns about correctness and efficiency and desirability [95], and the need to adapt methods to support rapid non-classical styles of software development: five of the key areas for software engineering research highlighted by Finkelstein and Kramer [113].

Motivation

Professional challenges

The programme of study that produced this thesis followed twenty five years of professional practice as a scientist, consultant, and senior engineer. While researching better systems for air traffic management and collision avoidance, and assessing the effectiveness and safety of fighter aircraft, I encountered challenges that existing approaches struggled to cope with. My hope was that techniques developed to provide a better experience might usefully be applied to improving safety. During the study described here, it became apparent that the reverse might be the case: that safety thinking might contribute to improving usability.

As an independent observer, my flight test reports were often different from those made by the company, because our observations are a product of our current focus of attention [124]. The test engineers were focussed on whether their functional tests were passed, whereas my focus was how it worked and how it might not work when, for example, flown by a less experienced pilot. I was concerned with the non-functional properties of the system, and whether the non-functional goals had been met. Primarily, these were safety goals, but in some contexts safety can be inseparable from effectiveness and usability.

Understanding the consequences of human-computer interactions starts with one-to-one interactions of one user with one feature but how one interface works creates expectations of other interfaces, and if those expectations are not met then misunderstandings or harmful misuse may result. These second order interactions can be important when our intentions are communicated more widely to third parties, and contribute to their situation awareness. In the past, dependencies like this were addressed through the training that specialist operators received. Mass participation has brought them into the mundane software used by the wider population, for example on social media platforms when bookmarking behaviour is confused with approval [230].

So, the challenge was to find a way of discovering unwanted interactions that could be applied early enough in the product life to avoid rework, which would scale up to more complex designs developed at greater pace, and which all the members of a cross-disciplinary team could participate in and understand. The nature of this challenge is further developed in Chapter 3.

Knowledge gap

The knowledge gap that is explored by this study is what current software design practice does to identify unwanted interactions, and how that might be addressed as part of the design discovery activity when the team is developing its broader understanding of the problem to be solved.

The mechanistic view of safety that was developed for hazardous industries assumes that harmful events have causes that can be readily identified and prevented. It aims for robustness, where failures are to be eliminated, and safety is achieved when tolerably few things go wrong. Many modern systems are too complex for that assumption to hold [194], so a more proactive approach has developed that aims for resilience, where success is maximised, and safety is achieved when as many things as possible go right [154].

A proactive approach to avoiding unwanted outcomes tries to anticipate them by looking for patterns of failure rather than individual events, and assumes that both success and failure arise from the same working practices through pragmatic adjustments and variations in performance rather than by ‘unusual’ mistakes. That makes it as important to understand how organisations get things right as how they “drift into failure”, as Dekker puts it [89]. Software engineers do not necessarily have the ethnographic study skills to form that understanding. Some user experience practitioners and user researchers have the necessary skills, but often lack the time and resources, so may benefit from a supporting framework to reduce the overhead of creating a bespoke approach for their organisation and help them to reflexively study a process that includes their own work.

Aims and objectives

Aims

This study aims to understand how practitioners anticipate usability problems, and to explore a means of facilitating that anticipation that would be suitable for practical application in a typical Agile workplace.

Motivating question

Some industries have products independently assessed before their delivery to the ultimate customer and address shortfalls by imposing limitations on how they are used. The motivating question (MQ) that underlies this study arises from my participation in these evaluations, where I observed that experienced teams still deliver products that have undesirable interactions:

This research is an exploration of how teams establish a shared understanding of the product, what they do to identify undesirable interactions prior to the testing of a solution, and the role that the ethical properties of the design might play in their discovery.

Research Questions

The motivating question (MQ) is too broad for a single study, so the research questions focus on understanding current practice (RQ1) and exploring how that might be modified (RQ2) to anticipate and avoid problems.

Current practice RQ1

Within the broader question of what current practice is, my focus is how practitioners identify interactions with potential usability issues:

Future practice RQ2

The initial literature review identified that discovery was under-researched, and discussions with practitioners had not identified any one dominant approach, so the future practice question needed to be flexible enough to reflect that. This was done by thinking more generally about the structures that designers create for themselves:

The information on current practice needed to address RQ1 was gained through two studies. Study 1 involved Ketso workshops with practitioners, and Study 2 involved practitioner interviews (Chapter 5).

After investigating current practice, RQ2 was explored by developing the Jeopardy Analysis method (Chapter 6) and then evaluating its usefulness to practitioners in Study 3 (Chapter 7).

Contributions to knowledge

This thesis makes an original contribution to knowledge in three principle areas: insights into how practitioners view discovery and conduct it in the workplace, the development of a novel approach to identifying potential harms by applying safety and resilience techniques to the ethical properties of the design, and an initial evaluation of this Jeopardy Analysis method. A conceptual map of the contributions from each study is given in Figure 1.1. The contributions are described in section 9.3.

Thesis structure

The conceptual links between the chapters are mapped out in Figure 1.2.

The research is introduced and motivated in Chapter 1, and the research questions stated.

A review of practice as described in publications and relevant recent literature is given in Chapter 2. Relevant findings are summarised and put in context.

In Chapter 3 the nature of the problem is further analysed and examples used to set out general categories of poor user experience that current methods often fail to pickup at the design stage. The challenges of doing effective discovery in an Agile working environment are identified.

The general approach and detailed methods used to explore the research questions are described and justified in Chapter 4.

Current practice is explored in Chapter 5. The use of Ketso community engagement workshops with retail practitioners is described, and key themes in their ideas about successful discovery methods are identified. These themes are further explored in structured interviews with practitioners from the civil service, design agencies, and contractors selling services into the public sector.

The jeopardy analysis method (a usability counterpart to hazard analysis in the safety domain or threat analysis in security) is introduced and developed in Chapter 6. The reasons for a focus on the ethical properties of the design are set out and explained.

The use of user jeopardy workshops is evaluated in Chapter 7. Application of the technique to a pre-prepared scenario is compared to a session using a problem suggested by the participants themselves.

A synthesis of all the findings and a discussion of the implications for each of the identified challenges is provided in Chapter 8.

The summary conclusions of the study, its contributions to knowledge, and my recommendations for further work are set out in Chapter 9.

Literature review

Introduction

This chapter describes how the research goals and questions were mapped onto literature searches to identify prior work and gaps in knowledge. The social context of the problem, the professional practice context of user research and UX design and discovery activity is explored, and related to the theoretical context used for the analysis. Key background material is summarised and its implications for this research identified.

Exploration of the question

Research goal breakdown

The broader question of what an understanding of interaction discovery would entail was initially broken down into sub-goals, using a GSN diagram [182], using possible contributing factors as decomposition strategies. This captured my initial understanding of the problem and identified topics relevant to the research questions for the initial literature search. Relevant factors identified at this stage were practitioner use of different data capture techniques, ideation under resource and organisation constraints, and responses to design outcomes.

TODO - GSN diagram

Research question breakdown

The question of how to discover unwanted features (RQ1) of a design was decomposed by mind-mapping [51] into a set of closely related questions, as shown in Figure 2.1. This decomposition helped shape the literature search by providing a broader view of the problem, as given in the following paragraphs.

Pain points as predictors

If user research identifies pain points, specific problems that current users are experiencing, how relevant a prediction they are for a new or modified system that does not exist yet may be difficult to determine. An analysis of the use of user support data by Oskarsson [260] suggested that pain points may provide useful insights, but creation of the categorisation meta-data needed to support efficient retrieval was found to be onerous. A recent study by Salminen et al [309] applied machine learning to the identification of pain points expressed on social media, and demonstrated comparable accuracy to a human operator, but again found classification to be challenging and recommended that companies train up their own bespoke classifiers by supervised learning. The use of user journey maps from two interacting viewpoints, which were then merged to identify mutual pain points, was described by Sinitskaya et al [326]. Their findings suggested that increased in-person interaction at designated points influenced satisfaction for both, but that pain points were not consistently reported by different individuals.

User customisation

Current use may also include important workarounds developed by the users themselves if elements of the system are programmable in some way, raising questions of customisation. In a study of highly configurable systems, Han and Yu [143] found that the majority (69%) of performance problems in the open-source web server, database, and browser studied (Apache, MySQL, and Firefox) were configuration related, so harder to anticipate or reproduce.

Differentiating undesirable alternatives

Design alternatives are commonly investigated by comparative testing. How the alternatives are chosen when some might have undesirable outcomes, and whether they would be sufficiently different for any suspected problem to be seen in typical use or would need an unusual scenario for differentiation, was not discussed in the available literature. A systematic mapping study by Ros and Runeson [296] found comparative ‘A/B’ testing use described in diverse settings, but a lack of guidance on ethical experimentation techniques and techniques compatible with rules on personal data use, such as the General Data Protection Regulations (GDPR).

Hypothesis design during discovery

Lean UX methods [129] use testable prototypes to validate design choices. The practicality of writing a clear and pertinent test hypothesis while still exploring a problem, and the consequences of any over reliance on imagination, were not addressed in the available literature. The challenges identified by Aarlien and Colombo-Palacios [1] included communication and knowledge transfer within the team, and cumbersome decision making processes in large organisations, and dependence on the thoroughness of the testing conducted if problems are to be discovered early. My concern with the Lean UX approach was the risk that the hypothesis would be chosen to be easy to test and target desired business outcomes rather than guiding the design in the way that will result in good outcomes for the user.

Recognition of success

When considering resilience, recognition of how you are currently succeeding was highlighted by Kitchens [186]. Bagchi et al distinguish resilience-by-design, using anticipation of likely perturbations, and resilience-by-reaction, achieved by detecting a perturbation at run-time and responding appropriately [20]. The former is more relevant to the discovery activities of interest to this thesis. Their suggestion that testing should consider the distribution of inputs as well as individual values, as a way of minimising assumptions, may be applicable to more than the machine learning context that they discuss.

Simulation and model-based design

Use of modelling and challenge-simulation in design, in for example Simulation Based Design (SBD) [229], can be used as a way of animating a specification to understand its consequences before a full system is available, and I have previously used fast-time simulation in that way when assessing fast-jet mission systems. However, it raises questions of how reliable indicators will emerge from those models, and whether representation of the user population is adequate at the start and how its evolution should be managed to track contextual changes. It may be difficult to anticipate the user’s navigation of a future system, and extrapolation to identify future issues may have validation problems. Use case models can be used to describe usability problem scenarios, just as they can be used for hazard mitigation scenarios as described by Allenby and Kelly [5], but design teams might find it difficult to do at the discovery stage with only an outline functional requirement to base them on. Stålhane and Sindre found the textual form of use cases more effective in identifying failures than the diagram form [334], so a lack of Unified Modelling Language (UML) tools need not be an obstacle, but user researchers and designers might nonetheless be resistant to it if is not part of the team’s normal toolset, as it may not be given previous adoption rates [272] and declining satisfaction with modelling tools reported by Badreddin et al [19].

Literature mapping

Mind-mapping was used on topics for literature search, focusing on user and designer behaviours, to look broader and deeper than those suggested by the question breakdown and as a sense-making activity to understand the coverage achieved. For example, linking search “persona design” with “persona stories” and “user stories” and contrasting with “job stories”. In this way, searches built incrementally into a body of relevant literature.

Search tactics and issues

The research questions are focussed on the practice of software design. The context of the research and the method used are key features of the prior literature, and the most relevant studies will feature active involvement of practitioners in user experience design and ideally be drawn from identified communities of practices. Initial searches based on keyword patterns were found to be largely ineffective at identifying the cross-domain and cross-functional literature that was needed, so a series of targeted literature searches were used.

Search engines based on a citation index, such as Web of Science, do not index the full text of the paper. For a study cutting across domains that was unhelpful, for example design discovery might not be the nominal subject of the paper and so would not be present in the title or metadata, but might still be what the paper substantially described. The Google Scholar engine does index the full text, and was found to be more efficient and effective at identifying relevant work, but although it indexes a wide range of sources, it is not comprehensive, so manual browsing of the ACM Digital Library and BCS Electronic Workshops in Computing (eWiC) entries for recent HCI conferences was used to supplement the search.

Social context

Challenges of ubiquity

Software is now ubiquitous in everyday life [383,267]. Public services in the UK follow the ‘digital by default’ policy first announced in 2012 [153]. This includes challenging sectors such as health and social care [249]. Some commercial services require customers to provide their digital address as well as the physical one, so for example, many banks require customers to have an email address and a mobile phone number. Recognising a desire for change after the coronavirus pandemic, several large IT companies announced in May 2020 that they were moving to remote working by default, with Tobi Lutke of Shopify saying “Office centricity is over” [215], so workplace digitisation is likely to accelerate.

User experience as described by Norman [255] is a response to the design, and people respond differently, so the more ubiquitous the product is the greater the variety of responses it will encounter. Some people will respond in a way that interacts badly with the product and has undesirable outcomes for themselves or others. Usability testing may identify these cases, but there is a problem of scale, as it may be impractical to recruit enough participants to be confident of covering all the interactions likely to be seen in use.

Cultural dependencies

People have differing sensitivities toward problems, reflecting their expertise and experience. Comparing alternative theories of usability, Clemmensen [67] suggested their effectiveness in explaining usability outcomes depended on the cultural background of the participants and their attitude to task performance versus aesthetic preferences. This is consistent with a survey by Lee et al [200], which found different attitudes toward quality and productivity as performance goals amongst different software engineering communities of practice, but they noted that it might be premature to ascribe these differences to underlying national attitudes and culture, and more research was needed. In a study of cross-cultural software teams, Barrett and Oborn [23] found that knowledge sharing may be inhibited and cultural boundaries reinforced if design artefacts are exchanged in a way that redistributes authority over the design. This has implications for how information is gathered about user needs, and the methods used by the project team to achieve a shared understanding of what they should design and develop to meet those needs, in addition to the challenges of delivering products for culturally diverse users. As a result, design discovery practices that work well in one cultural context may require local modifications to be effective elsewhere, and direct read-across of results from academic studies in other countries should not be assumed.

Attitudes to risk

Codes of conduct

When its use is no longer discretionary, there is an ethical and social duty on those that design software to ensure that it respects the dignity and autonomy of the people using it, and that its use does not place a burden on them that is out of proportion to the value it provides. This is reflected in the codes of conduct of the Engineering Council and professional bodies involved in software [351,350,107]. It is not sufficient for what it does to be correct, achieving its functional requirements, it is also important that the way it does it is acceptable, so meeting its non-functional requirements.

Managing risks

One of these requirements is that it should be safe, and there are rigorous methods for ensuring that software risks are appropriately managed when the consequences of failure might be dangerous [206,379]. Risk assessments typically have three key components [256]:

• Risk identification – what risks are there in this design?

• Risk analysis – what impact and frequency might they have?

• Risk evaluation – how do we get to an acceptable level of risk?

Risk analysis and evaluation are normally quantitative in nature, so require a sufficient through-life history of the system components to estimate their failure rates and calculate event probabilities. That would be generally unhelpful for discovery activity where the problem is not yet fully understood and the relevant component choices have yet to be made. The initial identification step does not require a deep understanding of the system or need to be informed by past problems, as infeasible scenarios can be filtered out during analysis and evaluation, but it does require creativity and imagination. Risk assessment is preceded, at some point, by a risk framing activity to establish what level of risk is tolerable and what priorities and trade-offs the organisation is able to make within their operating constraints. It is followed by ongoing risk monitoring and review, and communication of the risks and their mitigation measures.

The harms caused by software that is stressful or ineffective or an unpleasant experience to use are not considered with the same rigour. A recent taxonomy by Sedano et al of types of ‘waste’ in software development [317] only identified the distress of software developers, not the distress of those using their output.

Practice context

Design practices may be tailored for the context of the product (see section 2.2.2), but few studies directly involve the UX industry, so practitioners were an important focus of my research.

Importance of User Research

Experience cannot be designed as such [145], but can be designed for in the same way that the punchline of a joke can be designed for amusement: whether a particular individual is amused depends on them. Recognising that change is possible and desirable allows a team to prepare practically and psychologically to address it. This mobilisation is an important decision point. Having decided to act, the key questions are then

• who the problem should be solved for

• in what circumstances it should work, and

• what part it should play in those lives

These questions are addressed by user research within the wider practice of UX. Various definitions of user experience are in use [197,198] but they broadly agree with the international standard for Human Centred Design ISO 9241-210:2019, which defines it as:

user’s perceptions and responses that result from the use and/or anticipated use of a system, product or service

Hence, user research is the process of determining what those perceptions and responses are in a given context, and may support a refinement of the problem into hypotheses to be tested.

Software engineering practice has been slow to recognise the importance of UX, with undergraduate text books [330] still making no mention of it, and practitioners in Human-Computer Interaction (HCI) do not always acknowledge the full scope of user research, some even equating it with usability testing [199]. Recognition of its breadth has come more from the design community. The importance of context is particularly highlighted by Holtzblatt and Beyer [155] in their principles of contextual enquiry.

Over time, any repeated activity will tend to create boundaries between those who have participated and gained specific knowledge and competence from their participation, and those who have not. The specialisation of user research as a distinct activity will therefore tend to give user researchers a boundary-role as gatekeepers to the understanding of user needs and a buffer to the uncertainty around them, as suggested by Tushman [369].

Appreciating the position of the user requires imagination, which necessarily introduces divergence in understanding across the team, so continual alignment and re-alignment with an agreed interpretation is required. With each iteration of the design, and any associated usability testing, there will be a deepening of their understanding and new opportunities for divergence until resolved by alignment. The process of exploring the problem, interpreting the findings, and translating them into project objectives is inherently a negotiation [101]. That boundary process of negotiation between user researchers and the wider team is a key part of the overall process of discovery.

In the context of frequent delivery, it is unhelpful to refer to a discovery phase, rather it is a continuous process that adds to the depth and scope of understanding as the product is developed, as illustrated in Figure 2.2. This figure is an application to UX work of the alignment 'mode of belonging' to a community of practice described by Wenger [384]. To these could be added the practical step of mobilising a team, on recognition of an opportunity to pursue, while wrapping the whole in its iterative context. The work involved may be concentrated during the early life of the product, and diffuse as it matures, but is not considered complete while the software and its context continue to co-evolve [202]. The alignment of individual and collective understanding will tend to increase over time as it becomes part of the team identity [384] but may retreat and advance as new information is discovered.

The UX practitioner’s interest in interactions is for their consequences rather than their mechanisms, so anything that changes the mental state or behaviour of a user is regarded as an interaction, whether it involves a change in state in the computer system or not. For example, a pop-up that obscures something in their field of attention has already interacted with the user whether or not they outwardly respond to it, so there is no requirement for an interaction to involve a two-way transaction.

Not all interactions are intended or desirable. Some interactions create false expectations when the system has been given the data but other people who needed it have not [14]. Lack of interaction may also be a problem, such as when the operators of autonomous aircraft lack the situational awareness to respond to unusual events 158. Potentially traumatic interactions can be avoided by careful design. Avoiding those particularly related to death and bereavement is referred to by Massimi as thanatosensitive design [226].

Agile development

If adoption rates are as high as claimed [335], Agile software development methods provide the context for a significant proportion of future UX work. The ‘Build’ component of Figure 2.2 hides potentially significant complexity. For example, does the use of a Test Driven Development approach, and its tendency to make coders focus on more local and testable behaviour [364], alter the way the design is interpreted? Such questions are outside the scope of this study but could be important to the applcation of its conclusions.

Scope and Hand-off

While human-centred design has developed into a broader consideration of user experience, development approaches have evolved from process-led ‘waterfall’ models to continuous delivery approaches such as that described by Gothelf and Seiden [129], where iteration is used to constantly refine the design. The changed relationship between scope and time, as illustrated in Figure 2.3 and Figure 2.4, is the key feature of this evolution. Rather than planning, requirements elicitation, design, development, testing, and deployment covering the whole scope of the initial vision for the product, with detailed hand-off documents between them, successive development iterations include only as much of these activities as required for that increment in functionality and hand-off may be less formal.

The change in the means of hand-off has important consequences for user experience practice. When Takeuchi and Nonaka first used a rugby metaphor to describe development [345], they contrasted the linear hand-off of the baton between runners in a relay race and the more dynamic and integrated flow of the ball on a rugby pitch. One of the features of this metaphor, possibly missed by writers unfamiliar with the game, is that a scrummage is what happens between sprints. It is a point at which everyone is brought back together, the game is brought under control, and then play moves on. Sometimes it moves in a new direction.

In his initial description of the Scrum framework Sutherland [343] said little about the time between sprints and only indirectly distinguished the Product Backlog of stories to be considered over the product life-time, embodying the Product Owner’s vision for the product, from the subset of these stories to be addressed by the next sprint. This subset is called the Sprint Backlog in later work [342]. The recognition of distinct backlogs can contribute to the integration of UX with Scrum.

UX in Agile development

A review of approaches to UX integration by Kikitamara and Noviyanti [185] identified three broad categories: parallel working, working within a sprint, and Lean UX.

In a parallel working approach, or dual-track Agile, as described originally by Lynn Miller [239] and advocated by Marty Cagan [52, 53], the UX practitioners and the development team work in distinct discovery and delivery tracks and synchronise their activities through the progression of validated ideas from a discovery backlog into the delivery backlog. The shared understanding that would have been gained from a single cross-functional team may be lost by this approach, but it can allow more time for user research activity. A possible course structure for teaching this approach is discussed by Péraire [270], using project-based learning.

Some organisations initially integrated UX design by adding an additional ‘Sprint Zero’ for discovery activities and then staggered the UX activity to be a sprint ahead of development, with a hand-off from the UX practitioners to the developers. In a case study at VeriSign, Najafi and Toyoshiba [247] describe a project taking this approach and contrast it with a later one where a more integrated cross-functional team was used. The staggering allowed feedback from usability testing and the resulting refinements to the design to be addressed in the remaining sprints.

People who identify as designers can be very protective of the title and can be reluctant to accept that design happens at every stage of development or Don Norman’s observation that “we are all designers” [254]. In an analysis of UX roles in Agile teams, da Silva et al argue that integration of UX design into development requires a culture in which designers and developers both understand what the other is doing, and why they need to be part of the process [80], supporting earlier work by Ferreira et al that identified the need for mutual awareness and negotiation of progress [112]. They do not always realise the need for communication, or that the power balance between them may evolve during the project [274]. As UX work tends to be spread across the whole development process there is a need for continuous user research, design, and evaluation [81].

Unlike manufactured physical objects, the cost of replicating a software product is essentially zero. Existing code that already does what is required need only be distributed and installed. It follows that software development consists of building something new, either new to the world or at least new to the developers, and so involves some element of learning and discovery. The Lean UX approach described by Gothelf and Seiden [129] places discovery at the heart of development. In their experience UX outcomes are improved if design sprints produce a backlog of hypotheses about features that contribute to achieving the desired business outcomes, given current assumptions about the users to be served and the outcomes that motivate them. They then define the content of the next development sprint and the MVP that it will produce in terms of the most important question to be answered next.

Uncertainty

A failure to engage with uncertainty contributed to some high profile project failures. One of the key findings of the National Audit Office (NAO) report into the £100m failure of the BBC Digital Media Initiative [122] was a lack of assurance that its design was technically sound. In a study commissioned by the BBC Trust [278], it was also reported that management were more focussed on technical delivery than business outcomes, so failed to identify key dependencies. A more iterative approach would have exposed the inherent complexity and risk in what they were doing, as described by Marton and Mariátegui [225], at a much earlier stage.

The Cynefin sense-making framework [328] is helpful in understanding how different levels of uncertainty demand different approaches to problem solving. It defines Simple, Complicated, Complex, and Chaotic problem domains. The word Cynefin is often translated as habitat but more accurately means our place within the social and intellectual affiliations, shared narrative, and relational agency that underlie human interactions. As such it is similar to the overlapping occasions of experience or `nexus of multi-membership' that Wenger refers to in communities of practice [384].

For problems in the Simple domain, the relationship between cause and effect is clear and discernible. If the situation can be categorised, then best-practice responses for each category can be determined or may be self-evident. The premise of standards like WCAG [55] is that accessibility falls in this domain, but Power et al [276] found that only half of the problems encountered by blind users were covered by the standard, and recommended taking a design principle approach rather than focusing on the problems. In similar research, Tixier et al suggested that approaching accessibility from the ethics of care rather than the ethics of justice may be more effective [359], so we should prioritise meeting needs and avoiding harm over compliance with rules and standards.

The Complicated domain has clear cause and effect relations but they are discernible only by those with appropriate expertise, and expert analysis may be needed to select a response from a number of equally viable options. Data protection, security and safety issues are typically in this domain [127,280], although preventative good practice can reduce the risk and the consequences.

The Complex domain is characterised by cause and effect relations that are unclear until viewed in retrospect, when patterns may emerge that could not be predicted, so providing what Snowden refers to as retrospective coherence. The recommended approach to problems in this domain is to make sense of the situation by conducting safe-to-fail probe experiments to uncover patterns that may then inform the response.

The availability of affordably ubiquitous networks has first enabled and then accelerated an important paradigm shift in software development. Previously software was just an artefact, that we interacted with as we would with any other tool, but we are increasingly building systems that are a platform for us to interact with each other. In these systems, the artefact is no longer the product, the interaction is. This shift in what we value creates unknown unknowns, and places social media and online workspaces in the Complex domain where we may only understand how harm has been done after the event. Nevertheless it should be possible to anticipate undesirable features inherent in the design, such as the imbalances of power described by Curchod [78], and from these and similar characteristics identify potential problems, even if the mechanisms are unclear, by probing the team’s understanding of the problem in a safe-to-fail way.

In the Chaotic domain cause and effect are unclear and confusing. Action is needed to establish an island of stability [205] from which the situation can be sensed and understood before responding. A chaotic situation can result when an unintended consequence of the design causes a surprising problem for significant numbers of users, or becomes a high profile failure due to social media engagement with those affected, such that action needs to be taken urgently whether the cause is properly understood or not. The likelihood of acting swiftly in the right direction might be improved if the possibility had at least been considered sufficiently to recognise the symptoms and make a reasonable initial diagnosis.

Decision making and information

Information from ‘better’ questions does not necessarily improve the decisions made. Jacoby argued that ‘better’ can only be reasonably defined with respect to the information available [168]. Mennecke and Valaccich found decision quality to be related to group cohesion. Less cohesive ad hoc groups are less inclined to discuss minority information, challenging availability [233]. Using theory and simulation models of decision making, Raghunathan [283] found the quality of the decisions made only improved with better information if the decision makers understood the relationships between the decision variables. A study by Brodbeck et al [43] into group decision making, where members of the group had additional unshared information pertinent to the decision, found that minority dissent within the group was helpful in bringing the additional information into play but only if the degree of dissent was sufficient to overcome the natural tendency to align with perceived group preferences. Similar work by Scholten et al [315] indicated that decision making processes that motivated higher levels of evidence and raised doubts about the sufficiency of the available information were effective in using unshared information but not necessarily in bringing it out in open discussion.

Geographical variations in practice

Currently there is only sparse literature on UX practice specific to the United Kingdom. It may be like that in North America as described, for example, by Gray [132,133], or more like that in Nordic countries as described by Bruun et al [46], but the commercial culture and context are different, which may result in different outcomes. The UK Government Digital Service was included in an international study of digital service teams by Mergel [234], who noted their role as innovators and catalysts of change, but concentrated on their emergence rather than actual practice. This study addresses some of the design discovery aspects of that gap.

Theoretical context

The motivating question (MQ) must address two interwoven and dependent questions: how do groups of people work together to arrive at a design that achieves the desired outcomes, and how do individuals within these groups make the choices that enable desired outcomes to be delivered. These questions are informed by the social learning theory of Communities of Practice, and by the cognitive theories underlying Choice Architectures.

Communities of Practice

Teams engaging with uncertainty participate in a form of social learning, but may not recognise it or have sufficient awareness to reflect on it. Developing the concept of a community of practice [384], Wenger introduces the idea as “a community created over time by the sustained pursuit of a shared enterprise.” and stresses the need for a balance between the shared understanding achieved by participation and that gained by projecting abstractions onto more concrete forms, termed reification.

The negotiation of meaning that occurs in participation involves an exchange of assumptions, but not all the abstract ideas are likely to be captured in full in any objects created, so some assumptions will remain implicit and understood only in the context of the community. The resulting ambiguity provides flexibility needed to maintain the community by allowing any misalignment in interpretations to be resolved by discussion. Similarly, any inconsistencies in practice can be identified and repaired by reference to a more concrete form of the shared understanding, and Wenger describes the latter reification of meaning as having a close interplay with participation.

The Agile manifesto [27] prioritises participation over objectification, to the extent that it prioritises delivery over documentation, but that is not the same as giving lower priority to reification. Daily stand-up meetings with their verbal reports and updates to the progress board, usability tests, and stakeholder demonstrations of prototypes are all forms of reification. They make abstract notions of progress and design more concrete and further negotiate meaning by the participation of the team.

Leaving some information to the collective understanding of the team, rather than documentation, reduces the inertia of revising details, and functional changes can be contemplated that might otherwise have a disproportionate cost. Making small, frequent changes affordable enables continuous deployment and rapid iteration. The penalty for this implicit knowledge is the impact it has on the management of competence within the team.

Members of a community of practice will have a changing relationship with it over time. Wenger refers to these relationships as trajectories. Some never fully participate and have a peripheral trajectory, and may find it difficult to maintain alignment of their understanding. New members are on an inbound trajectory, where their participation is expected to grow. Their induction into the shared understanding places a burden on existing members if answers are not available independently. External changes create a need for members to refresh and extend their knowledge, so their insider trajectories may include excursions for professional development. Any additional boundary trajectories linking their work to other communities or other aspects of their personal or professional identity enrich their understanding but constrain their available time. Career changes will place some on an outbound trajectory. Capturing their contribution to the shared understanding within the institutional memory before they go may be limited by collective awareness of that contribution.

At its most abstract, alignment of practice is an alignment of mindset and its associated norms and values. Studies by Töytäri et al and Huikkola et al found mindset to be particularly relevant to products with communication capabilities [365,156]. In an immature discipline, mindset may be all that practitioners agree upon, and Gray suggests this may still be the case for UX activities [133].

Over time, as details of practice become standardised by regular engagement with other practitioners, the agreed practice may be refined from an informal understanding by increasingly concrete descriptions and codified into a more formal idea of how activities should be conducted. If this process continued without the enrichment provided by boundary trajectories, a mechanistic rote procedure might be arrived at that required no interpretative imagination in its application but which might become ‘brittle’ and too inflexible to cope with external demands. Wenger identifies the cause of such brittleness as alignment that depends on the absence of unforeseen situations, and a lack of what he refers to as negotiability.

The importance of that enrichment can be seen when a practice is adopted mechanistically from another organisation without learning and adapting it to the local context. Pyle and Liker described the introduction of lean methods into General Motors [282]. This was intended to avoid problems in production by anticipating their occurrence at the product development stage and taking countermeasures to prevent them. They concluded that problem solving across organisational boundaries required adaptive organisational learning not just a rote copying of processes, building on Pyle’s suggestion in earlier work [281] that when a process requires both explicit and tacit knowledge then more sophisticated methods of knowledge transfer are needed.

Learning is a response to the design process, not a designed output, but its context can be designed [384]. New information requires the team’s active participation in the negotiation of its meaning before it can be usefully exploited as new knowledge in the next iteration. The negotiability of this information is a reflection of how much opportunity the individual members of the team have to discuss and internally translate it into something relatable and meaningful to each of them. If they are reliant on an imposed encoding of it then their own understanding will be brittle, and vulnerable to the failure of embedded but unchallenged assumptions if applied to a new situation. If the initial design thinking lacks important considerations then the corresponding voices are likely to be missing from the negotiation, and conflicting interests may not be addressed, as discussed further in section 3.2.3.

Choice architectures

Companies in what Dahlström describes as the experience economy [82] aim to create not just a product but a curated experience of using it. By enrolling potential customers into these purposeful stories they differentiate themselves from competitors, and nudge us toward a more favourable opinion of their product. Thaler and Sunstein introduce the idea of a choice architect as someone with responsibility for organising “the context in which people make decisions” [349]. How designers act as choice architects for the users of their products, as applied to human-computer interaction for example by Jameson et al [170] and reviewed more generally by Szaszi et al [344], is well described but there is little recognition of the choices that designers themselves make and of their own entanglement in the stories that they construct.

The review by Szaszi et al [344] recommended that, as the cognitive processes involved are complex and poorly understood, choice architecture interventions (‘nudges’) could be more reliably characterised and described if the techniques applied were used as a structuring principle. The ARCADE model described by Jameson et al describes strategies for supporting choices, including:

• Provide access to relevant information or experience

• Represent the choice to assist judgement

• Provide a systematic argument structure

• Provide supporting analysis and calculations

Lloyd identified storytelling as central to shared understanding in design teams, and an important means of linking events to the people needed to enable or prevent them [213]. If the ARCADE strategies were applied to design activities involving important choices, such as identifying user interactions that should be prioritised or prevented, then a storytelling approach would suggest the following tactics:

• Distilling relevant information and experience into scenarios

• Visualising choices around an associated event

• Structuring an argument around user outcome goals

These are applied in my method design, in Chapter 6.

UX process models

In a process reference model for UX [184], Kieffer et al divided methods into those eliciting and capturing knowledge, with or without involving users, and those facilitating communication by the creation of artefacts. They make no mention of user research, and do not distinguish it from UX design. The artefact mediated methods they considered are not listed, but they assume artefact creation is their purpose and only necessary distinguishing feature. They do not consider the boundary-object role that design artefacts play in comprehensive approaches such as Goal Directed Design [71]. The elicitation methods they focused on aim to capture attitudes, feelings and opinions on user interactions with the system, or to observe and understand user behaviour. They acknowledge the gap between research and practice, but mention no practitioner involvement in their study. The life-cycle models referenced are more than ten years old so have not benefited from more recent attempts to integrate Agile and UX.

In an effort to integrate UX with the unified process [13], Nasiri and Sadler proposed a ‘UXUP’ [248] life-cycle which was then evaluated by practitioners in Queensland, Australia. Feedback was collected by interviews, questionnaires and group workshops, and was positive toward its user orientation but indicated a lack of clarity in the process. In line with ISO standards [166], discovery was treated as a distinct stage but they acknowledged its role in modelling and risk management throughout the life-cycle. The user research role was not distinct in their model, but listed as a sub-discipline of UX modelling and covered by the UX designer role.

Following integration of IT operations with development [333] to support continuous delivery, and in response to the difficulty of aligning design studio culture with Agile development [217], practitioners in the design community have been sharing ideas on how to define a discipline of Design Operations, to enable efficient design practice at larger scale and complexity. Some companies are sharing their experience in informal handbooks [220] and ‘playbooks’ [84]. Within it the user research activity and its organisation belong to the Research Operations discipline, as shown in Figure 2.5.

Design ethics

Ethics in practice

Ethics in software development

Bowles suggests that when making choices a designer is making a claim about “what should be”, bringing design into the realm of ethics [38]. The role of ethics in design has previously been under-taught in business generally [214] and in computing [222], but historically the software profession has perceived a failure to meet customer expectations as a failure, regardless of whether cost and time objectives have been met [210]. Analysis by Luz et al suggests a collaborative culture that avoids unfair blame assists innovation [216]. An acceptance of moral responsibility and consideration of ethical issues has not been an explicit part of the software engineering process, but Barbosa et al suggest this might be assisted by capturing and acknowledging our intent [22].

Learning from adjacent disciplines

Working across disciplines can help understanding of complex issues, as found by Hall et al when using artworks in security awareness [142]. The distinction between safety, security, and usability can be somewhat arbitrary, and this thesis later considers whether ethics can provide a unifying theme for their design, in section 8.3. In the military aviation context, effectiveness and safety are closely linked. Consideration of safety issues during the earlier design stages was found by Hewitt and Foito to increase the effectiveness of mitigations and allowed them to be more fully integrated into the design [150]. This is referred to as moving up the order of design precedence [206]: firstly eliminating it by design, reducing the risk of occurrence, adding barriers that interrupt the mishap sequence, incorporating equipment to protect people from the consequences, providing a warning of their occurrence, or lastly developing procedures and training to avoid triggering it.

Safety and usability are linked, as incidents result from confusing interfaces or assumptions about how people will respond [340]. User information distilled into personas has been adopted from usability by security analysts wanting to understand threat actors [108]. Formal analysis of non-interference conditions, that was developed for understanding security constraints [297], has also been applied to transport safety [325] and drug interactions [59].

Excluded and unwanted interactions

The extent of the fully considered interactions in a design, compared to those actually possible, can be visualised with a panda diagram such as that shown in Figure 2.6. This is based on the ‘Inclusive Panda’ diagram proposed by Per Axbom and used in his design ethics workshops [17]. The distinction is made between ‘excluded’ and ‘unwanted’. Interactions that are fully considered and included in the design are a subset of those that are actually possible, but some of these may be broken in some way. Of the interactions that are possible, some may be an inadvertently useful ‘Undesigned Good’ to people we wanted to design for but were excluded in some way, who will be disadvantaged if they disappear. Other interactions may inadvertently enable an ‘Undesigned Harm’ to people we never wanted to use our product, who could exploit them to harm themselves or others.

There is a direct link between the people considered and the interactions designed: if we exclude interactions we exclude the people who need them, and if we exclude people from participation in the design process then we orphan the interactions that supported them. These orphaned interactions, and their code, are a triple threat to the product: they may have latent bugs that are no longer getting usability testing as we have excluded the stakeholders, they may provide exploitation routes for cyber attack, and they may be an obstacle to refactoring and other architectural improvements needed to support wanted improvements.

TODO - Figure 2.6

Avoiding harm

PenzyMoog focussed on the problem of how to design products in ways that avoid deliberate harm [269]. An outline for ‘Inclusive Safety’ is described that primarily addresses the ‘unwanted’ side of the problem (2.5.1), to assess how technology will be used for harm and empowering vulnerable users to prevent that harm. Harms specifically covered are Technology Facilitated Domestic Violence (TFDV) and coercive control. The process described has five steps: conducting research to surface misuse cases, constructing abuser and survivor archetypes, brainstorming problems, designing solutions, and testing for safety. The focus of this process is distinct, but the method itself is essentially that already used in design sprint [189] and creative sprint approaches [121]. The focus is on how things go wrong rather than what we want to go right, which has a tendency to robust hindsight rather than resilient foresight [89], and there is only limited additional abstraction of the problem that might help with creativity and imagination [397]. So, while a welcome addition to practice in a specific area, it does not address the broader aims of this research.

Bowles is concerned about the use of “vehemently empirical” methods that are outcome agnostic and treat unintended consequences as externalities that are outside the scope of the design [39]. He makes some general suggestions: rather than prohibitions, define positive heuristics and codify virtues, bring ethics specialists into the company to facilitate the design conversation, and slow down and challenge. As an aid to challenging assumptions, he provides a long list of ‘virtue prompts’ that serve a similar purpose to guide words in the HAZOP method. One of the criticisms that can be made of this approach [26], is that indiscriminate additions to the list of prompts can cause confusion and do not necessarily identify the system property that you are trying to preserve, so fewer and better understood prompts may be more effective.

Academic analysis of design ethics

Expert practitioners

Practice-led research by Gray and Chivukula [135] looked at case studies of design from an ethical perspective to identify individual and organisational practices and how these were mediated by ethics. Their findings were a rich narrative description of those cases, including the impact of legal frameworks and a contractual mindset, and the ability of individuals to uphold personal value systems. They recommended future work should engage at both the individual and organisational levels, to understand how organisational practices constrain, fragment, and subsume individual practice.

Student practitioners

In a related paper, Chivukula et al [63] explored how UX students interacted with each other while solving either altruistic or commercially focused tasks, using a Value Sensitive Design (VSD) approach [119]. Values that the students considered were identified, but were found to be inconsistently engaged and decisions were made that were not ethically focused, despite the value-related training in their design curriculum. The authors recognised that further work would be needed in professional practice settings, but the findings suggest that practitioners using an unfamiliar or novel method might similarly struggle to be consistent and might benefit from active facilitation.

Ethics focused design methods

In a pre-print paper, Chivukula et al [64] report the results of a survey of 89 methods, tools, and approaches that have a stated intention of supporting ethical design. These were characterised by which design phase they supported, whether they were aimed at teams or individuals, and what artefacts or other outputs were produced. Only nine of the methods addressed discovery activity. Of these nine, only three were applicable to the whole life-cycle through to deployment and maintenance. These were ‘Design Fiction Memos’ [389], and the ‘Inverted Behaviour Model’ and ‘360 Review’ from the Design Ethically Toolkit, all of which took the form of a document or guidebook rather than worksheets, cards, or other media that designers could creatively engage with. The ‘Inverted Behaviour Model’ is a form of anticipation based on Fogg’s work linking motivation and user behaviour [114], and might be a useful starting point for more general anticipation.

The Value Sensitive Design (VSD) approach has been criticised by Reijers and Gordijn [289] for being too general, in the sense that its notion of value is whatever the stakeholders consider important at the time of asking [119], rather than any fundamental property of the design that will be persistent over time. They argue that this makes it essentially a form of participatory design, with an ethical flavour but lacking in moral substance. The capture of values onto ‘envisioning cards’ [118] might address this criticism by embedding values regularly identified as important into organisational practice. The questions that accompany envisioning cards are a weak form of anticipation, being based on problems seen before or assumptions previously challenged.

Discovery activities may not consider a sufficiently wide range of human and system behaviours to identify problems arising from the interactions between them. Reliance on previous solutions may result in ‘design fixation’ [376,75] prioritising some aspects but overlooking others. Designers may believe they have a thorough understanding of the context without adequately considering what has changed, so the role of UX practitioners in constructing design stories, and the relationship between them and outcomes, is relevant [261,213,265]. Stories are not generally discussed in the context of anticipating problems, though Dahlström does include the topic of antagonists [82].

Knowledge gap

An analysis of requirements engineering papers by Curcio et al [79] still found specific gaps in research on the management of requirement sources at the elicitation stage, despite Gotel and Finkelstein having raised the issue in the mid 1990’s [128]. A review of the application of Agile methods by Dikert et al [96] collated challenges and success factors reported by practitioners, but found that there was “a lack of sound academic research on the topic”. Wahlström et al [380] described methods of modelling user activity intended to facilitate radical design ideas, which may be applicable to interaction discovery. These were further developed by Varsaluoma et al [375], but with inconclusive results, so they identified a need to repeat their study with practitioners from industry rather than participants from academia. Gaps in current literature were identified by Ogunyemi et al in knowledge creation and sharing [257], reporting of the working context in Agile studies by Vallon et al [374], and relevance to practice by Jurca et al [175]. By focusing on discovery, I aimed to address those gaps in a coherent and practice-centred way.

Recognising a social context in which the ubiquity of software makes it use non-discretionary, the topic of design ethics was identified as important to the study. Within the wider practice of UX, the central role of user research in ethical design practice was identified. A strong theme of knowledge sharing in Agile practice [195,263] led to the adoption of Wenger’s work on Communities of Practice [384] as a useful basis for understanding the relationships between the roles in a multi-disciplinary team. The role of designers as choice architects was noted. Studies involving practitioners were identified, but few were focussed on discovery or described current practice within the UK.

Challenges of discovery

Characterising the problem

The review of recent publications in Chapter 2 concluded that current discovery practice and the nature and scope of the problem I wish to address are not adequately described in the literature. In this chapter, examples from daily life are used to illustrate why I believe there is a problem that originates in design and might be resolved by it. Some of the categories that these issues may fall into are identified, and the consequences for user experience are set out.

Scope

The most readily encountered examples of poor user experience are websites. Sometimes it is a deliberate choice by the designer, a ‘dark pattern’ applying their understanding of psychology to further a goal that is contrary to the best interests of the user, by deception and misdirection [137]. This thesis does not address ‘asshole designers’, as Gray calls them [136], because new discovery methods cannot prevent wilful harm. My concern is the accidental reliance on a flawed assumption or incomplete analysis. The examples below follow from inadvertent flaws that might be avoided by a willing designer if a different approach were taken.

Public confidence

In their final digital attitudes publication [238], the Doteveryone think-tank reported that nearly half (45%) of those surveyed felt that there was no point reading product terms and conditions because companies do what they want anyway, and only a fifth (19%) believed that digital products and services were designed with their best interests in mind. A quarter (26%) said that no action was taken when they reported experiencing a problem online. Despite this, most people (81%) thought the Internet had made life better for them and the majority (58%) that it had a positive impact on society. The contrast between these positive and negative sentiments suggests a potential for sudden and significant swings in public confidence. Public trust and confidence in complex systems is important because it facilitates innovation [61] by reducing aversion to new approaches and ideas and by making the interactions between the participants more predictable to each other [207].

In November 2013, Adrian Wooldridge predicted we would see a “growing peasants’ revolt against the sovereigns of cyberspace” [391] and described it as a techlash. The prediction may have been a little premature, but by November 2017 congressional hearings into the role of social media platforms in the 2016 presidential elections [320] and later in 2018 into the use and abuse of data [319] demonstrated that law makers were taking the growing power of Silicon Valley seriously. Self-regulation mechanisms have been proposed [147] but change at the organisational level can only be effective if it is based on a change in the disposition of engineers to the things they are being asked to do and the reaction of wider society [338].

Technical debt

Analysis of the trend in software project outcomes published by the Standish Group in their regular CHAOS reports, as illustrated in Figure 3.1, shows that outright success and failure rates significantly improved in the period 1994 to 2014 coinciding with the introduction of Agile methods. However, the likelihood of the project being delivered with at least some significant shortfalls, compared to the intended scope, remained largely unchanged. The criteria for success used from 2015 onward [353] is based on customer satisfaction, regardless of the initial scope, so is a better reflection of outcome but makes comparison with earlier studies more complex [352].

TODO - Figure 3.1

Whether shortfalls are strategic technical debt, for example incurred in the rush to be first to market, or tactical debt resulting from limited understanding or implementation challenges [360], they are a form of unfulfilled obligation. They might result in correspondingly unfulfilled usability, security, or safety obligations that need to be carefully managed. When considering the notion of safety debt, Cleland-Huang and Vierhauser [66] suggest additional ‘hardening’ sprints to address any safety concerns identified by analysis at the end of the sprint. These are a more analytical counterpart to the spike tasks commonly used to address issues found in usability testing or gaps in understanding [3].

In addition to the technical consequences of unfulfilled obligations, technical debt can also impact team motivation and undermine its effectiveness [292]. By reducing self-efficacy, the ability of team members to cope with stress resulting from ambiguous performance expectations or uncertainty in how to perform a task may also be reduced [354].

Human performance

Design is recognised as a wicked problem [293, 47] where our understanding of the problem is entangled with our conception of possible solutions. Each design problem is essentially unique and not solvable by applying a general technique. However, the goal of efficiency [279] is still pursued by organisations wanting to reduce commercial risks, make their processes more predictable, and scale their activities to larger teams dealing with more complex problems. The design operations movement attempts to do this in a sustainable way, by focusing on collaboration and communication to improve workflow [220].

The combination of behavioural design [60] and lean startup methods [36] is criticised by Bowles for its reliance on narrow business metrics as the driver for its empirical iterations [39], without proper consideration of the user impact, as characterised in the phrase “Anything that moves the needle is fair game” [37]. Their application to public service design, in conjunction with Scaled Agile Framework (SAFe) [201] ideas of value streams, has had significant impact on the working environment. Analysis of lean working in HMRC and DWP by Martin [223] found that it resulted in deskilling, echoing what had been found in earlier studies by Carter et al [58] that also commented on an intensification of the pace of work, and that the focus on performance targets also impaired the quality of decision making and reduced the scope for professional judgement.

There is a dynamic relationship between the complexity of a system, the work involved in understanding its behaviour, and how quickly this can happen [88]. There is a risk, when pushing teams to the limit of how quickly they can work, that individual professionals can be so constrained that they have no space to manoeuvre. If they slow down, the whole project stalls waiting for them, if they speed up then important questions might be overlooked and the downstream consequences could be disruptive. Rasmussen described these kinds of situation using a dynamic safety model [285], typically illustrated with a three boundary diagram such as Figure 3.2. Given boundaries set by the ‘worst’ tolerable efficiency of resource use, quality of output or outcome, and workload on the team, a business will try to find an optimum operating point somewhere between those boundaries by improving efficiency and reducing the effort required, but in doing so may reduce the safety margin unless there is also a countering drive to improve quality.

Using an analogy from aviation gives an alternative presentation of dynamic safety in terms of the operating envelope available between working too slowly and ‘stalling’ the project, impacting efficiency, or ‘skimming’ complex material too quickly, impacting quality, then suffering disruption when problems surface later. I used this in discussions with practitioners, as stalling and skimming were easier to communicate, and these informal terms did seem to be intuitively understood without making references to safety that might have confused their understanding of the research aims. The expression “flattening the curve” was in widespread use at the time to describe the public health response to coronavirus, so was helpful in describing the aim of reducing complexity to a level that could be coped with at pace without being limited to trivial problems, as illustrated in Figure 3.3. The analogy and figure should not be taken too literally, as it is not based on empirical evidence of work rates at different levels of complexity, but it reflects my experience as an analyst.

Reducing complexity, and providing tool support to sustain high work rates, was the approach we took in the 1990’s to increase air traffic system capacity and reduce delays [180,314]. Structuring the problem to reduce the complexity of design challenges [25] felt a natural candidate approach to scaling up software design activity while still anticipating potential harms and avoiding them.

TODO - Figure 3.2

TODO - Figure 3.3

Poor outcomes

Quality of experience can be impacted in ways that usability tests miss due to over reliance on ‘typical’ cases.

Poor quality advice

Recommendation systems using machine learning [109] are widely used in online retailing. They can be very helpful in exploring an otherwise daunting array of choices, but our trust in the recommendations may be misplaced [21] or the results may occasionally be so strange that we withhold our trust in future, as illustrated in Example 3.1. Integration of algorithmically driven social media with online retail to give social commerce platforms [310] may create a situation where it is not clear what the biases might be or even whether the apparent recommender is human. A lack of trust and transparency detracts from the user experience and may infringe legal rights [218], but also complicates the work of designers and analysts in understanding user behaviour and motivations.

TODO

Research design and methods

Current UX practice

Jeopardy Analysis

Evaluation of Jeopardy Analysis

Discussion

Introduction

This chapter discusses the findings of my research, relates them to prior work, and makes suggestions for further study. The findings of each of the studies are discussed, and the research questions answered. The use of ethics as a unifying concept is discussed and related to ethical frameworks by illustrating the relationship between safety and usability and security, and mapping technical risks onto ethical properties. The idea of jeopardy analysis is then related to prior work and related practices, and its relationship with usability heuristics illustrated by mapping them onto ethical properties. Finally, limitations and reliability are discussed and further work suggested.

Discussion of findings

The first research question asked how current practice identified undesirable interactions:

The question was refined for Study 1: Ketso workshops to focus on discovery goals and practices:

The question was refined for Study 2: Practitioner interviews to focus on shared understanding:

The second question, addressed by Study 3: Jeopardy workshops, was how practitioners might be helped to identify undesirable interactions:

The findings for each of these questions are discussed in the following sections.

Discovery goal findings

Research questions

In order to gain insights into the reasons for practitioners method choices, the question was split into three sub-questions aligned with the workshop design, as discussed in section 5.3.1. Three questions were explored in face-to-face Ketso workshops: what is done in practice (RQ1.1.1), what would improve practice (RQ1.1.2), and what are the challenges (RQ1.1.3). No clear trends were identified in what is done, reflecting a diverse experience of discovery. Challenges centred around pressure on timescales.

Current practice themes

Two kinds of themes were identified in answer to the first sub-question. Firstly, the goals that the participants had in choosing discovery Methods, the Mindsets they saw as beneficial, and the Outcomes that they sought. Secondly, the practices that they considered to work well in Empowering them to succeed and in being Knowledge-led in their approach. These were summarised in Table 5.5 and Table 5.6.

Participants indicated a preference for data-driven approaches. These are widely used for marketing purposes [208] and to drive innovation [313] and are well represented in the literature [29,237] but analysis of the motivations for them is lacking. By identifying co-incident themes of certainty in how to proceed, having evidence to justify decisions to continue or terminate work, and a desire to be user-centred and have a validated understanding of the user, my findings provide possible reasons for the preference but further evidence and analysis are required to understand the commercial drivers for the collection of user data.

Knowledge sharing was a felt by the participants to be an important part of successful discovery and something that their organisations were good at. Effective knowledge sharing was found by Kuusinen et al [195] to be improved within teams that adopted agile practices but wider sharing with customers and colleagues across the company required more active motivators. This effect can be seen in my participating organisations. The Empowering theme included use of agile rituals such as stand-up meetings as a positive aspect of discovery but the Communication theme discussed below also identified cross-organisational communication as one of their challenges.

Aspiration themes

Three themes were identified in the things that the participants aspired to and felt would improve practice, in answer to the second sub-question. These would support their professional Curiosity, be further Empowering, and make better use of Knowledge, as summarised in Table 5.7.

Aspirations for deeper and broader discovery, and more continuous discovery processes, were linked to their desire for more flexible schedules and the time pressure they felt. A need for more discovery is consistent with the findings of a grey literature review by Münch et al [246] which gave inadequate discovery as a common reason for product failure. The aspirations for future practice discussed by the participants align with the aims of the emerging professional of research operations discussed by Metzler [235]. Efforts by the DesignOps and ResearchOps communities to develop a more scalable and sustainable approach to UX are ongoing, but case studies are beginning to appear in the literature, such as the Arizona University library case described by Blakiston et al [33].

Challenges and obstacles themes

Four themes were found in the challenges and obstacles to successful discovery discussed by participants, answering the third sub-question. Problems with Communication, local constraints on human and material Resources, obstacles resulting from human Behaviour, and problems embedded in an organisational Process were mentioned, summarised in Table 5.8.

Many of the challenges and obstacles cited were those that might be expected in any large organisation and were not necessarily specific to UX or discovery activities. Availability of the necessary skills and knowledge, and having the right mindset, were two that might be addressed by training and continuing education. A study by Cajandar et al of life-long learning processes in UX [54] found that practitioners thought methods were too complex and took too long to learn, that time pressure limited them to approaches they knew well, and that tool choice was sometimes limited by company policy on license purchases as well as current availability of licenses.

Methods versus tactics

The breadth of factors participants discussed suggested a diverse experience of discovery, and an ad hoc definition of success with no widely shared criteria within the organisation. This is consistent with previous work by Gray [133], that identified a flexible approach, and may reflect organisational procedures that embed tailored parts of published methods rather than adopting them as a whole or using an associated toolset, so reducing any ‘brand awareness’ of the method. Tactics that could be selected and combined according to the circumstances were preferred to a standardised method. In the descriptions of the practices they aspired to, there was a strong theme of empowerment and autonomy, and interestingly a desire to spend more time with stakeholders but also to be less constrained by their objectives. A desire to conduct both a broader and deeper discovery was expressed, which suggests that exercising greater autonomy and achieving the desired ‘user-led’ process might require a more time efficient approach.

Time pressure

A frequently discussed factor was time pressure. A focus on customer value and agility, leading to shorter development cycles as found by Clarke et al [65], implies a need for agility in user research and other discovery activities, so the mention of inefficient processes as an organisational challenge may also be related to a feeling of insufficient time. Currently, discovery and development are often separate streams of activity such as the dual-track approach described by Cagan [53]. Better integrated forms of continuous discovery that avoid sharp peaks in demand, such as described by Torres [363], were not in use by the participating organisations at the time of the workshops.

Challenging assumptions

An interesting omission from the data was vocabulary associated with rigour and challenge. This was missing from both of the sessions, and was not a point of difference between the participants with retail and academic backgrounds. If challenge is not considered an important part of discovery, that might be because it is more strongly associated with later stages of development, but more specific questioning was needed to determine how the emerging narrative is challenged during discovery, and this was included in Study 2: Practitioner interviews under research question RQ1.2.3.

Tailoring the workshop format

The standard Ketso pack assumes up to eight people per workspace, but my experience with the first session suggested this would be too many, so in order to limit the number of people around each one to three or four an additional workspace was purchased. The number of leaves written by the participating design professionals, who were experienced in similar activities if not with Ketso, was sufficient that freedom to arrange them as they wished might have been curtailed if we had not done so. It also allowed everyone to read each other’s ideas the right way up while seated, without walking around the table, so saving time.

For a complete cycle of questions starting with a definition of done, covering what works or does not, and revisiting the definition of success, a period of 90 minutes was barely sufficient to allow proper discussion. If the availability of meeting spaces is limited, the ease with which the felt workspace can be folded and packed up without disturbing the leaves could be exploited to hold a follow-up discussion session at another time or with the workspace mounted vertically on a convenient wall space rather than on a table.

Discovery practice findings

Research questions

Five question areas were explored in the interviews: how the next piece of work was chosen (RQ1.2.1), how information was gathered (RQ1.2.2), how their understanding was shared and challenged (RQ1.2.3), how much was enough to proceed (RQ1.2.4), and how that was translated into design choices (RQ1.2.5).

From audio recordings, interview transcripts were prepared, and a reflexive thematic analysis (see section 4.5) used to address the question of how practitioners achieve a shared understanding of the problem (RQ1.2) and how undesirable interactions are identified (RQ1).

The analysis identified key themes in the interview conversations structured around these questions, as discussed below. The answers to these specific questions were dependent on the role of the participant (see Table 5.10).

In answer to the first question on mobilisation, the business analyst was driven by what was next in the product backlog. The civil servants by one of three things: stakeholder initiatives, requirement changes or policy changes, or technical changes in the technology employed. The agency was driven by tenders they could bid for. The digital media designer had been driven by user generated data from experiments, the company having allowed any experiment to be applied to up to 1% of the users. The system supplier was driven by requirement changes and problem reports from customers.

In a study of new product development, Katzy et al linked mobilisation to recognition of an opportunity [179]. Kreuzer et al identified that digital technology has accelerated opportunity recognition by dissolving boundaries between companies and their customers, and thereby enabling more continuous interaction either directly or via the data their product use generates [193]. That effect was apparent in the statements from the digital media designer, but not from the other participants.

Answering the second question on engagement and discovery, the responses were consistent with what had been seen in Study 1: Ketso workshops where a range of methods were employed. The agency had a preference for qualitative methods, while the civil servants collected a broader range of quantitative usage data as well as qualitative data about the context, so used mixed methods. The system supplier was reliant on a documented requirement, but this could be quite vague so was supported by interviews with the customer to refine it. The digital media designer had a preference for quantitative methods, and commented that ideally quantitative and qualitative methods should be used together to produce combined insights, but knew of only one big technology company doing that.

A recent case study of user research in the National Health Service by Duda and Chearman [98] described how a new website was brought into use in five weekly sprints. The first sprint was based on the statement of work between the agency and the NHS, reflecting typical public sector mobilisation patterns described above, and included production of a user research plan. Repeated use of card sorting [86] and feedback from remote interviews was supplemented by analytical data from the previous website, in line with the mixed methods described by my civil service participants.

Responses to the third question on sharing included some of the same ideas as the Empowering theme identified in Study 1: Ketso workshops. The agency and civil service participants made regular use of team presentations and agile rituals such as sprint reviews to share insights and challenge findings from user research. They also tried to involve the whole team in user research activities, either as observers or scribes, so that they would have personal experience of the context and not be surprised by the findings. Use of open display, or the online equivalent, of the research outputs was also favoured. The business analyst had a similar approach but made more use of artefacts, ranging from sketches to short reports, to communicate findings. The digital media designer was less specific, but highlighted the need for user researchers to be present in design critique sessions to challenge departures from the findings. The system supplier used requirement documents, supplemented by prototype demonstrations and meetings, to share understandings with the customer and colleagues.

Challenges and barriers to effective knowledge sharing are well represented in the literature [123,10], but descriptions of the practices adopted in practice are lacking. Regular briefings to colleagues, as used by several of the interview participants, was one of the practices described by Hemon et al in a case study involving a large multi-national software developer [146]. Another they describe as “backlog grooming” resembles the practice followed by the business analyst participant, of incrementally refining work-to-be-done as information becomes available.

The forth question on iteration and how much discovery is enough gained similar answers from most of the participants, though articulated in slightly different ways as having a clear question, or knowing your next action, or understanding what the MVP or Minimum Viable Service (MVS) would be. For the system supplier, the important criteria was reaching a point where the client was happy with what was proposed. For the digital media designer, where change was driven by micro-experiments, the question did not arise in quite the same way as discovery was a less distinct activity.

The question of how much is enough is directly addressed by Hall [141], who also notes that unless it is based on recent user research specific to your current goals then prior knowledge may embed incorrect assumptions. Her advice, that the highest priority questions should be addressed, accords with the approach taken by most of the participants. Similar advice is offered by Gothelf and Seiden [129] but framed in terms of hypotheses about what design features will result in the desired outcome.

The final question on how choices are made and captured identified that designers are not always aware that other options were available, so choices are sometimes made by default, but it was felt to be part of UX research and design roles’ responsibilities to interrogate assumptions and challenge choices made if there were alternative options. The agency participant felt that people with an agile mindset were more conscious of making choices. Tactics adopted included involving the whole team to identify the riskiest assumption, and briefing choices made as part of regular team briefings. The system supplier had the interesting insight that they were well aware of their own choices at the design stage, but less aware of choices made by the development team while building it that might also impact the user experience.

Unconscious processes in design have been discussed in the literature, for example by Badke-Schaub and Eris [18], but not specifically the question of whether designers are aware of making a choice. Nor was any recent prior work found that documented how UX practitioners capture their design choices.

Shared understanding

The first key theme T1 identified that whatever methods were chosen to suit the context, the process of discovery was consistently driven by a need to build a shared understanding, and the challenges that practitioners experienced were linked to factors that frustrated that aim. Three supporting themes to T1 were identified.

Development of supporting theme T2 showed discovery activity was tailored to the context and had no fixed process, supporting findings by Gray [133] that practitioners considered mindset more important than process, and that the generated artefacts were diverse in content and had life-spans varying from single-use ephemeral sketches to high quality research outputs retained for the project duration. Participants occasionally referred to a discovery ‘phase’ but made it clear that discovery activity was ongoing and not confined to any one stage of the work.

Supporting theme T3 found a strong desire to challenge assumptions, and recognition that the equality of outcome needed to provide equity in the provided service did not mean uniformity, so design choices were made that focused on user groups with particular needs and prioritised removal of barriers over efficiency. The mention of personas was limited to contexts where the abstraction was useful for presenting inconvenient truths or including challenging user behaviours.

Supporting theme T4 captured the challenges of time constraints and funding mechanisms, and tactics used by practitioners to cope with them by prioritising discovery effort.

Anticipation mindset

The second key theme T5 drew out the implications for efforts to anticipate problems of current discovery practice and its integration into development. It found a growing awareness of the need to anticipate, and some early adoption of techniques based on patterns in previous failures, but found these to be passive and lacking in depth. The significance of impact on the user was not always appreciated, and there was a preference for responding to problems rather than avoiding them, and a belief in some practitioners that anticipation was impractical. A conflict was identified between the desire to conduct more experiments and the impact that an unconstrained empirical approach can have on design. Concerns were raised about design being disenfranchised and that if the risks of an experimental approach were not better managed that design would be reduced to a multivariate test, treating all experimental outcomes as equal regardless of the possible harm.

Ethical safety

The final key theme T6 developed the relationship between achieving a shared understanding and the approach needed to anticipate problems. It found that design choices were often locked in too early, not consistently documented or recognised as choices, and that usability was sacrificed to meet business objectives or to prioritise throughput. Addressing these problems was linked to the performance of individuals in the Product Owner role and the boundary-role played by business analysts. Recruitment choices were significant enough to be regarded as design choices, and the diversity of routes into UX presented opportunities for a multidisciplinary approach that would cope better with complexity by actively negotiating understanding across the team. Remote working was found to be well established and was also felt to have a role in breaking artificial barriers within the company. These interactions within the organisation reflect the importance of boundary roles in innovation described by Tushman [369], and the importance of negotiation in boundary spanning behaviour is consistent with the role of persuasion described by Vesalainen et al [377]. The benefits to information flow of remote working, as seen by my participant, were not identified in a recent study by Franken et al [115], but it is perhaps too soon to expect the available literature to reflect the full breadth of experience of the rapid increase in remote working seen in 2020.

The term ethical safety was synthesised as a way to describe how harm might be avoided by anticipating problems on the basis of design ethics and the ethical properties that the system should have. Achieving ethical safety was associated with a multidisciplinary approach, actively seeking a shared understanding, and developing a mindset that recognised the imbalance of power between designers and users and sought to address it by anticipation of problems. The term ethical safety is used in nursing ethics to refer to a practitioner’s independence to act according to their professional values [275] and to preserve respect for patients [203]. My generalisation to usability is in keeping with that use.

Evaluation findings

Research questions

The question was refined into two sub-questions RQ2.1 and RQ2.2 using the hypothesis developed in Chapter 6 that consideration of ethical properties of a design provides a stable basis of analysis that can be applied before discovery activities are complete:

Addressing RQ2.1, participants answering the second debrief question (Q2) said they thought it had helped them challenge their assumptions. Addressing RQ2.2, participants answering the third debrief question (Q3) thought that it did help them to uncover latent issues in the scenario.

Identifying underlying assumptions, and challenging them, is a key part of critical thinking. In terms of Bloom’s taxonomy [34], the aspects of critical thinking needed to uncover design issues are analysis of which components might interact, synthesis of what would happen to the system as a whole as a consequence, and evaluation of whether that is tolerable or not. Question RQ2.1 focuses on the analysis step, and asks if thinking about ethical properties assist that analysis, while question RQ2.2 focuses on the synthesis step.

Participant successes and struggles

When the use of different levels of abstraction in design was explored by Kokotovich and Dorst [190], they associated higher levels of abstraction with higher levels of expertise and ability to innovate. When they evaluated the ability of a multi-disciplinary team of students to move from ‘novice’ levels of abstraction to higher levels, they found that their participants did not move far from conventional views of the problem or develop higher level abstractions and were generally unsuccessful in stepping back from it. My choice of somewhat abstract ethical properties as the basis of the method was intended to concentrate on the essence of what was required, and give room for a more creative analysis of the problem. My participants relative success in doing so may be a result of the facilitation they received, and my prior decomposition of the abstract goal into more concrete questions, or their greater professional expertise in design compared to student participants.

The use of abstract ethical properties was problematic, to the extent that the participants found them difficult to relate to practical issues, but when translated into more concrete questions by the facilitator they were able to address most of the latent concerns in the scenarios without further prompting.

The generic properties chosen are potentially overlapping concepts, and to some extent this was done deliberately to prime the discussion for the next step, but it did appear to make it harder for the participants to associate concerns with properties or to suggest other properties that might be relevant to their domain.

The richest coverage was expected for concerns where there is an established regulatory requirement such as accessibility and data protection, or concerns where the participants might have direct personal experience. The team in the first evaluation had personal experience of part-time working and low-wage jobs paid by the hour, so fully covered all the concerns related to people on different types of contract experiencing a four day week differently. Both teams did well in covering the first equity related concern in their scenarios, namely health and accessibility.

The least well covered concern was Accountability Jurisdiction. Where the data is held, and therefore in whose jurisdiction it falls, may be less relevant to companies that predominantly draw customers from their home market, or may be delegated to information governance specialists within the company. Working from home might have been expected to raise awareness of these issues, and related concerns about applications like Zoom [2], but designers themselves may not have direct responsibility for them or discretion to choose. For delegated concerns, and those related to particular life-experience, the diversity of the team is important. This reinforces the current practice finding that ethical safety requires a multidisciplinary approach (see section 8.2.2).

The Proportionality property was intended to explore areas where the user contributes disproportionately compared to the benefit they receive in return. One aspect of this is how often actions need to be repeated, and the related issue of how long data is held. Neither team addressed these directly. The additional user burden of repeating information already provided, particularly if the request interrupts the intended action, may be unwelcome and in the case of compliance interactions such as cookie consent dialogues, Soe et al found that it can be a vehicle for unfair nagging and other dark patterns [329]. Repetition is not always addressed by usability heuristics [251], considered in information architectures [298], or included in measures of user burden [339], but without considering how often a question should be asked the related issue of how long the answer should be kept is poorly served. The participants did, partly or indirectly, consider what might be involved in correcting data and identified that having to erase all cookie data from your browser might seem a disproportionately costly way of changing your mind about one website, so a little more nudging from the facilitator might have surfaced the Repetition concern and with it Longevity, but this may be an example of issues that need explicit training to raise awareness of them.

Student practitioner use of Value Sensitive Design (VSD), as described by Chivukula et al [63] and reviewed in section 2.5.2, suggested that facilitation might be needed. The participants were unfamiliar with the method and did need the abstract prompts to be translated into more concrete questions, but once that was done no active facilitation was needed for them to consistently identify latent issues.

The property that the participants said they found most difficult, but also the most interesting from the point of view of things they were not currently thinking about so much, was Agency. Considering ways in which the user might lose confidence in their ability to influence outcomes or control the course of events, took more thought and had no obvious mapping onto things they were already doing, whereas Equity felt similar to accessibility concerns and Proportionality reminded them of data protection rules.

Ethics as a unifying concept

Hartmann used the values that a culture embodies as a unifying concept for the social sciences [144]. Applying this idea to UX design, the common ground between safety, security, and usability can be seen as the ethical properties that underlie these different views, as illustrated in Figure 8.1. The advantage of considering ethical properties when shaping the design is that they can be agreed early in the process and are likely to change only slowly over time.

I have contrasted ‘probability’ in the safety domain with ‘possibility’ in the usability domain, as it should not be necessary to quantify the likelihood of a usability problem to address it, though businesses may need to be convinced of that to justify corrective action. Similarly, judging quality of ‘experience’ can be a qualitative assessment rather than a quantitative assessment against a threshold for ‘tolerability’. How easily practitioners are able to relate properties to potential design features requires more evaluation, so this diagram will evolve as further research identifies other distinctions between the domains.

Ethical frameworks

As Lindberg et al found [212], practitioners are not in the habit of thinking about ethics yet, and find it hard to integrate into their practice, but practical means of addressing the issues are being actively discussed. The ethical field guide [258] produced by social change venture the Omidyar Network explores eight technical risk zones identified by the Institute for the Future [140,259,163]. These risk zones and their defining question are mapped onto the four generic ethical properties I derived in section 6.3 in Table 8.1. Many of them involve more than one property, and accountability is prominent.

Table 8.1Mapping of IFTF risk zones onto properties

Zone	How might we ...	Property
Surveillance	protect privacy?	Agency
		Proportionality
		Accountability
Disinformation	promote truth?	Accountability
Exclusion	enable equity?	Equity
		Proportionality
Algorithmic Bias	promote fairness?	Equity
Addiction	promote healthier behaviours?	Agency
		Accountability
Data Control	enable transparency?	Agency
		Proportionality
		Accountability
Outsized Power	promote choice?	Agency
		Proportionality
Bad Actors	promote civility?	Accountability

Protection of users from surveillance has three related questions, as discussed by Andrew and Baker [7]: did I say you could have that, do you need it, and did you tell me you took it? These might need distinct interactions so it is useful to separate them. The same applies to data control. As discussed by Shu et al, measures to counter disinformation on social media have become necessary [323], so Twitter now inserts an accountability nudge and asks its users if they “Want to read the article first?” if they try to retweet a linked article they have not yet accessed. Exclusion and bias are both aspects of equity, but for exclusion it is useful to distinguish hard exclusion where access is impossible and soft exclusion where there is no desire to participate, as this may be because the pre-conditions of participation are disproportionate to the perceived value.

Turel links addiction with agency [368] but it may also be an accountability problem if behavioural design is deliberately misused to create the addiction. Imbalances of power and choice can be a loss of agency and proportionality, and could also impact accountability if the imbalance is sufficient. I am sceptical about whether design can address civility as that assumes antisocial behaviour is inadvertent, rather than actively sought and associated with sadism as found by Buckels et al [48], and in extreme cases it becomes an abuse of power [70] or what Mall et al call toxic behaviour [219]. The response in these cases might be choosing not to build that feature, as discussed by Sandelin and Homewood [311], or as Widdicks et al put it, to repent and withdraw it [387]. Algorithmic amplification and wider dissemination of bad behaviour in pursuit of higher engagement scores, as alleged by a Facebook whistle-blower [395], is an issue of current concern to policy makers [386,111] and may require audit activity, as discussed by Juneja and Mitra [174]. Lawyers and legislators are responding with litigation [31] and new law [192], whether the problem is fully understood or not.

Jeopardy analysis

Scope of jeopardy analysis

In designing a new method, my focus was high-level interaction design, on the assumption that more minor issues are adequately addressed by usability testing. Usability problems range from minor inefficiencies in a user interface, that are easily remedied, to fundamental flaws in the interaction philosophy that require a complete redesign. They were characterised by Manakhov et al as negative phenomena caused by a combination of design and context that result in a shortfall in efficiency, effectiveness or quality of experience [221]. I find their definition broadly useful but do not accept their non-overlapping partitioning, as negative halo effects [4] may lead users to complain about efficiency and effectiveness because their experience was poor.

I intend jeopardy analysis to support user research and design from planning onwards. In a survey of ethics-focussed design methods, Chivukula et al [64] found these planning and scoping activities were under-served. Discussing ethical concerns, Gray et al [136] demonstrated close alignment of the use of unfair processing strategies [137] with negative end-user reactions in online discussion fora. These ‘dark pattern’ strategies give useful examples, but a method that focussed on deliberate misusability might support independent audit while offering little to honest practitioners. The anticipation needs to be effective enough that unfair design would be picked up, but the scope broad enough to include inadvertent problems that they would be motivated to avoid.

Limitations of testing

Some participants saw the need for anticipation, but believed they fulfilled that need by testing, as shown in Extract 5.27. Jeopardy analysis aims to avoid the situation where a failed test identifies an issue so far into development that it is then too expensive or disruptive to address.

Deming said that testing a completed artefact is too late [92], as its quality is already determined. For usability tests to have value they need to be formative assessments [305], that feed back into development, not summative assessments that are either passed or failed. For products where mistakes are inevitable but intolerable, Deming recommended inspection, but in those I was involved in all we could do at that late point was apply limitations on use. The risk of that safety management approach becoming “rear-end analysis” had been identified by Taylor and MacLeod [348] and repeated an earlier finding by Taylor that processes based on “ergonomic checklists and late demonstration evaluation were ineffective and not directly related to mission effectiveness criteria” [347].

Reviewing operation of the safety case approach, Inge observed that deciding what evidence was needed “requires a greater degree of competence from those involved in it than does a prescriptive approach to safety, where managers can achieve compliance by following rules rather than making decisions” [162]. Linking problems with evidence of their mitigation, as Kelly advocated with goal structuring notation [182], first needs an understanding of what might happen and why. Jeopardy analysis is intended to provide that.

There may be occasions and contexts where anticipating a potential usability problem does not provide enough information for it to be avoided. In such cases practitioners might choose to do nothing until they have seen it enough to understand it properly, or give advice to users to help them recognise it and recover. The output of the anticipation method needs to be rich enough to support both of these strategies, and persistent enough to match the life of the problem (D14). If that can be achieved then it may ease reliance on testing.

Resilience and Robustness

It is useful to make the distinction between designing a system to be robust, so that failures are avoided, and designing a system to be resilient so that failures are detected early and recovered from quickly. My priority is to support resilience, by priming teams to recognise a problem quickly even if it cannot be avoided by design. Robustness can be difficult and expensive to achieve [89,90], and focusing on failure can take attention away from unexpected successes that we might want to secure for future designs [154], as discussed in section 2.5.1.

Stability during change

Freezing the design for extended periods while risk analysis is done would be incompatible with the desire for continuous discovery and delivery (see 8.2.2), and repeated analysis would seem wasteful and costly. For anticipation to be practical, it needs to be based on properties of the design that can be agreed upon early and that will remain stable throughout the life of the product, so that the analysis can be a continuous refinement of the issues, supporting and supported by continuous discovery and delivery.

Related practices

Project Premortems

The practice of performing a project premortem was described by Gary Klein in an article for the Harvard Business Review [188], and built upon the strategies suggested in a study by Mitchell et al [240] for constructing explanations of uncertain events. When compared with brainstorming, Gallop et al [120] found that working backwards from an imagined failure to the possible reasons was more effective and more time efficient in generating good quality ideas. That it worked well for safety analysis did not necessarily mean that it would be equally effective for usability, but it was an attractive starting point.

Consequence scanning

The responsible technology think-tank Doteveryone describe an ‘Agile event’ they call Consequence Scanning [45]. I find it a useful contribution to thinking about the problem, and it suggests sensible prompts for specific but common issues. My criticism would be that it simply asks the question ‘what are the unintended consequences’ without much conceptual scaffolding to support the discussion. For twenty five years, it was my job to answer that question. It was hard, even in a tightly regulated domain with a detailed goal tree to provide focus [182]. I believe it is too broad a question for general use.

Holistic personas

Holistic user persona descriptions, distilled from user research then augmented with personality traits, were found by Anvari et al [9,367,366] to be helpful in the conceptual design stage. As I aim to support the planning of user research campaigns, as much as their execution, there would be insufficient data at that early stage to build a persona. If jeopardy analysis could guide designers to think about the impact on users in a way that invoked the same discussion of personality and emotional characteristics, either permanent or situational, then some of the same richness of thinking might nonetheless result.

Mapping heuristics onto ethical properties

The generic ethical properties used in the evaluation were sufficiently general that it should be possible to map known usability issues onto them, and doing so might indicate whether the approach is practicable. A time efficient source of suitable issues was those already distilled into usability heuristics.

Mapping Nielsen’s heuristics onto properties

The usability problems analysed by Nielsen related to systems that predated the widespread use of graphical interfaces, but his analysis identified seven general factors, later extended to the ten commonly used heuristics , that can be mapped onto desirable properties, and as shown in Table 8.2.

Table 8.2Mapping of Nielsen’s usability factors onto ethical properties

Heuristic	Description	Ethical properties
N01	Visibility of system status	Agency
N02	Match between system and real world	Agency, Equity
N03	User control and freedom	Agency, Proportionality
N04	Consistency and standards	Agency
N05	Error prevention	Agency, Proportionality
N06	Recognition rather than recall	Agency, Proportionality
N07	Flexibility and efficiency of use	Proportionality
N08	Aesthetic and minimalist design	Proportionality
N09	Help users to recognise diagnose and recover from errors	Agency, Accountability, Proportionality, Equity
N10	Help and documentation	Agency

Mapping web and work heuristics onto properties

Other heuristics directly address the needs of website users . Those not already covered are shown in Table 8.3. Three heuristics targeting workplace use, from Muller and McClard [245], are included in the summary. These cover having respect for the skills of the user (H11) and supporting quality work (H13), which map onto Accountability. Having a pleasurable experience (H12), in a workplace context, was mapped onto Proportionality on the basis that increased tool use can make a task more stressful, as found by Martin et al for adoption of online meeting tools [224], but depending on the tool might also map onto Agency if self-efficacy factors were important to workplace stress, as found by Thompson and Gomez [354], or perceived team engagement and social agency, as found by Price and LaFiandra [277]. The mapping is illustrated in Figure 8.2.

Table 8.3Mapping of web and work heuristics onto properties

Heuristic	Description	Ethical properties	Reference
T03	Match system and user’s cultural aspects	Equity	[266]
W01	Make text and interactive elements large and clear enough	Equity	[273]
W03	Avoid short time-outs and display times	Equity
W06	Provide sufficient but not excessive content	Proportionality
W11	Avoid duplication or excessive effort	Proportionality
W14	Make the sequence of interaction logical	Equity
W18	Indicate if links go to another site or page	Accountability
W19	Interactive and non-interactive elements should be clearly distinguished	Agency
S07	Link depiction indicates its visited status	Agency	[362]
S13	Elements hinting where the user is exist	Agency
S14	Map to directly access content exists	Proportionality
H11	Respect the user and their skills	Accountability	[245]
H12	Pleasurable experience with the system	Proportionality
H13	Support quality work	Accountability

Mapping summary

From the spread and coverage achieved, it appears that these four properties would be a reasonable starting point for practitioners learning the method or beginning to explore the ethical landscape of a new product. Addressing properties also forces more context specific thinking, compared to the rather vague workplace heuristics.

Limitations and reliability

Limitations of this qualitative research are discussed here, and the measures taken to ensure reliability, by identifying recognised weaknesses, and following the categorisation suggested by Lincoln and Guba [211] of credibility, transferability, dependability, and confirmability.

The findings are credible if the research addressed the intended phenomena, and described them accurately [321]. Transferability to another context can only be judged if sufficient contextual detail about the fieldwork is provided for other researchers to make that judgement. Dependability rests on having sufficient detail on the methods employed to be able to repeat them, though not necessarily with the same results as the phenomena may have changed. Confirmability depends on being able to demonstrate that the results derive from the participants and their ideas, rather than those of the researcher.

Participation

Three organisations participated in the workshops and six in the interviews. The three studies involved 26 practitioners in total, whose business activities included higher education, retail, digital media, and public services. Their types of employment included freelance individuals and agencies bidding for work, companies who supply and support a proprietary system, and specialists within larger organisations or civil service departments. As exploratory work, the aim at this stage was depth and richness of description, rather than breadth and coverage, but there are inevitably limits to the generalisability of findings based on this small sample.

As discussed in the critical reflection on Jeopardy Analysis (see 7.5.3), only designers were invited to participate. In a practical application of Jeopardy Analysis, concerns about the balance of power between designer and user would be better addressed by fully involving the current or prospective users and making it a co-analysis and co-design activity.

Period of engagement

The workshops and interviews provided snapshots of practice at the time they were held, from the perspective of the individuals involved. Engagement over a longer period, involving different workshop groups and interview participants, would have captured a broader view and understanding of the typical practices in the organisation.

Data captured

Only the transcripts of the evaluation workshops and interviews, and the leaves completed in the Ketso workshops, were included in the analysis. No audio or video recordings were made of the Ketso sessions, out of respect for workplace and participant privacy. Analysis of the conversations around the table might have provided additional information on the rationale for the statements made.

Pandemic conditions

Both Study 2: Practitioner interviews and Study 3: Jeopardy workshops were conducted during the coronavirus pandemic that began in late 2019. The participants and the researcher were all working from home with domestic network infrastructure and equipment. Individually purchased audio and video equipment, of variable quality, was used to conduct the online interviews and workshops, and they took place in domestic settings with the available lighting and furniture and occasional distractions from other family members.

The evaluation workshops were time-limited to 90 minutes as an adaptation to remote working, so only included jeopardy identification activities, and not the subsequent construction of a jeopardy model with challenges, mitigations, and consequences linked visually with a loss event in a diagram [68] as had been intended. This may have made it harder for participants to think about the problem, as they were not able to benefit from the act of creating and revising the bowtie diagram, or align their understanding by sharing it.

Highly regulated industries

Retail and public sector practitioners were recruited for the research. Contact was made with practitioners in the banking and finance sector, but despite expressing an interest they felt unable to participate, and expressed concerns about the regulatory framework they work under. Practitioners in healthcare were also initially interested but did not respond further. These are sectors that could potentially benefit from jeopardy analysis, and their feedback would have been valuable. Their absence limits the claims that can be made for its general applicability.

Credibility

Credibility of the study was addressed by contextual familiarisation, by the use of established methods, and by member checks and triangulation [321], in order to have confidence that the data gathered from them were relevant to the research questions and gave a coherent account of the practices described. Familiarity with the research context was developed by active engagement over three years with the communities of practice from which the participants were drawn, in person and on social media. Established methods for trustworthy qualitative analysis were adopted from Braun and Clarke [42]. The strategies suggested by Shenton [321] and case study practices from Runeson and Höst [302] were considered when reviewing the study limitations. After processing, the data gathered for was shared back with the participating organisation before analysis. The post activity debrief questions used in established whether the participants found the approach plausible, or applicable to their organisational context. The thematic analysis approach applied to the interviews enhanced credibility by working across the whole corpus of data when constructing and reviewing themes. A degree of triangulation of the current practice findings was achieved by using the structured questions in Study 2: Practitioner interviews to explore in more detail, with different participants and organisations, a related question to that already covered in Study 1: Ketso workshops.

Transferability

Transferability of the results to other contexts was addressed by providing sufficient relevant details of the working context of the participants and relevant aspects of my background for other researchers to judge the transferability of their contributions and my analysis of them. As suggested by Shenton [321], these details include the number of organisations involved and their locations, the number of participants and the professional background required for their selection, the methods employed, the number and length of the data collection sessions, and the overall time-period involved.

Dependability

Dependability was addressed by detailed descriptions of the processes followed, sufficient to allow others to repeat the method, with example extracts provided to illustrate how the analysis method was applied to the data. Dependability and confirmability were enhanced by discussion of my approach to the work with my supervisors.

Confirmability

Confirmability was addressed by maintaining an audit trail, as suggested by Lincoln and Guba [211], tracing data through each phase of the analysis to the results to support review activities and ensure that the findings reflect the experiences of the participants, not the preferences of the researcher. Findings were also discussed with my supervisors.

A trail was created by the use of the NVivo qualitative data analysis software to record data coding decisions, by digitising all physical artefacts generated during data collection and analysis, and by tabulating the allocation of coded extracts to themes in a spreadsheet as part of the review phases.

Materials used in the workshops were included in Appendix A of the printed edition. The transcripts, coding, and themes were tabulated in Appendix E, and used as the source of example extracts. The volume of material in the Appendices made them unsuitable for presentation in this web edition, but they are available for download.

Contributions and further work

Summary of the research

Informed by a review of prior literature and a thematic analysis of current practice resulting from two empirical studies, an interaction-discovery process was developed that considers the ethical-properties that the design should preserve, maps these onto concepts that are meaningful in the problem domain, and uses the resulting provocations to anticipate and explore jeopardies implied by the design, as summarised in Figure 6.1. This was evaluated in a third empirical study.

Concept mapping and goal structuring were used to identify topics for an initial literature search (Chapter 2). Recognising a social context in which the ubiquity of software makes its use non-discretionary, the topic of design ethics was identified as important to the study. Within the wider practice of UX, the central role of user research in design practice was identified. A strong theme of knowledge sharing in Agile practice [195,263] led to the adoption of Wenger’s work on communities of practice [384] as a useful theoretical lens through which to understand the relationships between the roles in a multi-disciplinary team. The role of designers as choice-architects was explored, noting that they may be entangled in their own purposeful stories. While studies were found that involved practitioners, few were focussed on discovery or described current practice within the UK, and specific advice on suitable approaches for participants from the design community was lacking.

The description of the problem was refined and challenges identified using examples from daily software use (Chapter 3). A contrast between negative sentiment toward technology companies and positive sentiment about their products was reported in a public attitudes report by Doteveryone [238]. The threat to public confidence in the software profession has so far not led to the ‘revolt’ predicted by Wooldridge [391] but tech workers report negative impacts on their social interactions with friends [338]. Analysis of reported software project outcomes was used to demonstrate the lack of progress in addressing requirement shortfalls, and the distinction was made between market-driven strategic technical-debt and practice-driven tactical debt. The conflict between working quickly enough to maintain progress but carefully enough not to miss the potential for harm, while taking on larger and more complex projects, was identified and related to Rasmussen’s dynamic safety model [285]. Examples of poor quality advice, tactless prompts, conflicting interests and motivations, and ways that well intentioned features supporting one use case may negatively impact another potentially more important one were provided.

The researcher perspective, methods used, and reasons for their selection were described (Chapter 4). My professional background was summarised, the epistemological, ontological, my methodological positions stated, and reasons for adopting a qualitative approach set out. Data collection methods were described, and details provided of the reflexive thematic analysis [40] approach used. The evaluation of the jeopardy analysis method was described, using guidance on design science research [356] and cognitive work analysis [378].

An initial understanding of the goals, methods, and mindsets employed in the current practice of discovery, from the perspective of practitioners, was obtained in Study 1: Ketso workshops by a thematic analysis of statements generated in collaborative idea generation workshops. Findings from the first study informed the questions in Study 2: Practitioner interviews. Analysis of the interview transcripts enriched this initial understanding of priorities and aspirations and suggested how the approach might need to change in order to successfully anticipate problems (Chapter 5). Using those findings, criteria were explored for an anticipation method based on the ethical properties that should be preserved (Chapter 6). A method was constructed and evaluated online with practitioners in Study 3: Jeopardy workshops (Chapter 7). Main findings from these three studies were discussed and related to prior work, and further work identified (Chapter 8). The answers to the research questions are summarised in the next section. Identified threats to validity, and how they were addressed, and limitations of the research were discussed in section 8.5. Questions arising from this study that require further work are discussed in section 9.4.

Answers to the research questions

Motivating question

The motivating question MQ was

The purpose of the motivating question is to acknowledge the wider context of the research. Analysis of current practice for RQ1 found that up-front design thinking is sometimes concerned with possible solutions, informed by pre-conceived ideas about the problem as imagined, rather than an inquiry into the problem as experienced. That analysis provided further insights into what could be done differently and an enhancement to discovery practice was developed in response to RQ2. The resulting user jeopardy analysis method progresses the aims of the motivating question by:

• identifying ‘undesirable’ as the loss of ethical properties

• considering all user outcomes, not just those desired

• supporting model-based approaches to usability testing

Progress in answering the MQ links findings to further work, as set out in section 9.4.

RQ1 – Current Practice

The first research question RQ1 was

In Study 1: Ketso workshops and Study 2: Practitioner interviews, it was found that practitioners chose methods that build a shared understanding, and their challenges related to factors frustrating that aim. Method selection was context dependent, processes were tailored by the team to suit their circumstances, and communities of practice within companies actively explored and experimented with new methods and shared their experiences of using them. There was a growing recognition of the need to anticipate some kinds of problems, but in general agility in responding to a problem identified in testing was preferred to anticipation. Predominantly, no methods are applied at the discovery stage to identify undesirable interactions. Usability testing, once a testable product is available, is preferred.

RQ2 – Anticipation of problems

The second research question RQ2 was

This was refined into two sub-questions

These were addressed in Study 3: Jeopardy workshops by observing design practitioners using the jeopardy analysis method (Chapter 6) and requesting their feedback after doing so. The participants reported that structuring their discussion of interactions around people and the design properties important to them did help them challenge design assumptions. They found the framing of the problem in ethical properties unfamiliar but felt they could use it by themselves with more practice. Latent issues in the scenarios were identified, and the participants engaged in rich discussions around them, without further prompting by the facilitator, beyond that already provided by the pre-scripted questions and their explanation. This initial evaluation suggests that thinking about usability issues as the loss of an ethical property could help practitioners uncover them, but generic properties are too abstract so they do need to be mapped onto domain specific terms, and therefore the provocation design step of the method (section 6.2.2) is important to its application.

Contributions

Contributions to knowledge

Practitioner view of discovery

Thematic mapping of responses to questions about the goals, tactics, current aspirations, and challenges of discovery practice provided insights into how UX practitioners view discovery activities in a workplace context. These included key features of the desired mindset [133], the methods used, and the outcomes sought. Success in the participating organisations required approaches that were knowledge-led and empowering. For them, their aspiration to greater curiosity meant broader, deeper, and more continuous discovery activity with more diverse user groups. Obstacles to successful discovery were identified in communication, culture, and business processes. Factors imposing material and human constraints were identified with implications for education, training, and operational management.

Current discovery practice

Analysis of interviews, building on my earlier insights, provided an enriched understanding of current practice. This identified that shared understanding was actively sought, that prototyping and Agile rituals played a part in more effective sharing, and that alignment with their colleagues and their end-users was valued by designers. The desire to challenge assumptions was associated with an empirical approach, where practitioners value anticipation of problems, but believe they do so by usability testing. The analysis also identified ‘consequence scanning’ approaches to anticipating problems that differ from current discovery practice, and are potentially in conflict with it, which were associated with ethical design advocacy and a more risk averse mindset.

Development of Jeopardy Analysis

Development of the Jeopardy Analysis method offers an interaction discovery practice that can help practitioners to identify some undesirable interactions, and addresses some potential weaknesses in existing ‘consequence scanning’ approaches. It helps anticipate usability issues, in a manner consistent with the aims of Value Sensitive Design, while focusing on positive system properties that are stable over product life-times. It supports time efficient but rigorous analysis that integrates conceptually with existing safety techniques and tools.

Evaluation of Jeopardy Analysis

Evaluating the Jeopardy Analysis method with UX practitioners has provided initial indications that this is a practical approach, and a suitable basis for further research into interaction discovery techniques for general application.

Practical contribution

A method guide, worksheets and explanatory material guiding practitioners through a generic user jeopardy identification process were used under supervision during the study, and were available for independent use from the project website for a limited time after completion of the research.

Dissemination and publication

A paper describing the results of Study 1: Ketso workshops was presented at the British HCI conference in 2021 [291]. Further papers covering the findings of Study 2: Practitioner interviews and Study 3: Jeopardy workshops were planned, but I decided the individual studies were too small to justify a journal paper. Engagement with the practice communities that participated in the research was expected to use professional meetups and the project website.

Further work

Refinements for industry use

Initial feedback was encouraging but further contact with practitioners is needed to refine the method and gather data on how it might be used in a workplace context with real projects and commercial pressures.

Constructing domain-relevant provocations

My proposed jeopardy analysis method includes an activity (Phase 1) of translating the ethical properties relevant to the design into domain-relevant language when choosing provocations that will evoke a creative response to them. For evaluation purposes, my provocations were neutral and aimed only to pose questions rather than to trigger personal dilemmas as Ozkaramanli and Desmet did [262] or use aesthetically, functionally or conceptually challenging features as employed by Raptis et al [284]. As such they remained somewhat abstract. The difficulty of translating abstract concepts of user jeopardy into concrete concerns applicable to their domain and product, that was expressed by participants in the study, indicates that more detailed evaluation of this aspect is required.

Anticipation and discovery mindsets

The analysis here used a snapshot of practice as described by practitioners in 2020. With the introduction of the Online Safety Act (2023) the regulatory framework is changing [192,390,346] and technologies such as VR may complicate platform governance [32] and the design practices adopted [341]. Ongoing work is needed to track the development of this topic during a period of potentially rapid change.

Jeopardy analysts

Participants found it difficult to translate abstract concepts of jeopardy into concrete concerns applicable to their domain and product. A more detailed evaluation of this aspect of the method is required, which should focus on whether the its use in the workplace requires team members with an aptitude for abstraction to adopt a `jeopardy analyst' role analogous to the boundary role of safety engineers in multidisciplinary teams.

Cross-disciplinary awareness

Poor coverage of some concerns, particularly those which might normally be delegated to specific departments within larger organisations, requires more investigation and it is suggested that the utility of targeted cross-disciplinary awareness training should be assessed in a workplace context, where jeopardy identification has been integrated into the design process for a real project.

Bowtie diagrams and jeopardy models

Visualising the path of a latent problem from threat to consequence in a bowtie diagram may assist its anticipation, its understanding, and its recognition when it occurs. An evaluation of this would ideally follow similar projects from their inception, through the complete life-cycle to product retirement, so that the through life costs and benefits could be assessed.

Teaching jeopardy analysis

As discussed in Chapter 7, teaching Jeopardy Analysis in higher education settings would contribute to learning outcomes in inclusive design, identifying societal impact, making ethical choices, risk management, and recognising professional responsibilities.

Concluding remarks

This research is intended to benefit practice and enrich understanding of its UK communities of practice. It was only possible with the participation and encouragement of practitioners in Manchester and the wider design community.