Thesis on Design Discovery | Interaction Discovery

Interaction Discovery by Analysis of Ethical Properties

Abstract

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.

Two research questions are explored: what methods are used in current software design practice to identify undesirable interactions during discovery activities, and how can designers be helped to structure their work in a way that assists them in identifying undesirable interactions.

Three empirical studies were conducted with user experience practitioners. The first used Ketso workshops to gather data on discovery goals, practices, and challenges. These informed the second study, which used interviews to gather data on attitudes and practices. Reflexive thematic analysis was used to analyse findings. Using findings from the first two studies and lessons from the existing literature, I developed a new method of anticipating undesirable interactions by identifying ethical properties that the design should preserve and considering how they might be lost. This Jeopardy Analysis method was evaluated in the third study through remote workshops with user experience design practitioners who were asked to apply it to an unfamiliar scenario and provide feedback on its use.

Findings about current practice from the first two studies indicate that user experience practitioners favour methods that build a shared understanding, but select them to suit the context. They tailor their approach, and actively explore and experiment with new methods. There was some recognition of the need to anticipate problems, but no methods were applied at the discovery stage, instead relying on usability testing.

The evaluation of the Jeopardy Analysis method found that it helped to challenge assumptions. Practitioners found framing the problem in ethical terms unfamiliar and difficult, but felt they could use it by themselves with more practice. The generic properties used for the evaluation were found to be too abstract, so the method step tailoring them for the domain would be an important part of its application.

The research contributes insights into the goals practitioners have for their discovery activities, and their current approaches to identifying undesirable interactions. It identifies practitioner interest in recent ‘consequence scanning’ approaches to anticipating problems that differ from current practice, and are associated with a more risk averse mindset. It contributes a novel Jeopardy Analysis method, and reports encouraging results from its initial evaluation.

Further work is needed to refine Jeopardy Analysis for use in industry, and to evaluate practitioner selection of ethical properties tailored to their domain and product. Its natural domain of use is seen as software applications supporting life in our increasingly digital society, where the general public are co-opted into our designs, and the ethical case for intervention is most compelling. Extension of Jeopardy Analysis to involve prospective users in co-analysis and design would further address the potential imbalances of power in current practices. It is suggested that teaching Jeopardy Analysis in higher education settings would contribute to learning outcomes in inclusive design, societal impact, the making of ethical choices, risk management, and the recognition of responsibilities.

Preface

The post-graduate research project that produced the Jeopardy Analysis Method (JAM) was motivated by a desire to understand why well-funded teams of talented engineers still delivered systems that had serious flaws in them. A full answer to that is still a research question, but if the reasons included a reluctance to anticipate problems, or an over reliance on testing with limited coverage, then an exploration of design discovery practice seemed a good starting point.

Beginning with an exploration of current practice, workshops and interviews were conducted with UX practitioners. The data from the workshops focussed on what the aims of a good discovery activity were, what people would like to be doing, and what got in the way. The interviews gathered more detailed information on what organisations did to share their understanding of the user needs, how projects were started and who drove that mobilisation to action, and what role anticipation had in their discovery process, if any. The interview transcripts were analysed, and the themes constructed in that analysis were then used as input to the design of the method.

A doctoral thesis is a strange document. It serves as both a description of a piece of academic research, and an artefact for summative assessment of the research student. The former needs to be detailed enough to understand the work and its findings, but the latter needs to meet the needs of the examiners and be concise enough to fit within their workload. That tension can result in some much needed context and background thinking being left out.

These pages are a version of the academic thesis. The text has been expanded where needed to better explain the ideas to an interested practitioner, and pruned of material that was only relevant for examination purposes. All the diagrams have been reworked from the LaTeX originals into a more web friendly form and their accessibility improved. The introductory chapter has been extended in places, because the journey from interaction discovery as a general concept to something that can be done early in the design process is a more winding path than the academic thesis had room for.

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 . 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.

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

Knowledge gap

Aims and objectives

Aims

Motivating question

Research Questions

Contributions to knowledge

Thesis structure

Glossary

Bibliography

Index