Critical user-configurations in mHealth design: How mHealth-app design practices come to bias design against chronically ill children and young people as mHealth users.

Mobile health smartphone applications (mHealth-apps) are increasingly emerging to assist children's and young people's management of chronic conditions. However, difficulties persist in applying design approaches in mHealth projects that return apps that are useful to this group. In this article, we explore ethnographically two self-proclaimed 'user-driven' projects designing mHealth apps for Danish patients below the age of 18 living with, respectively, haemophilia and rheumatoid arthritis. These projects initially included the perspectives of children and young people to inform the designs, however, eventually launched the final apps for adult patients only. Through a concept of 'critical user-configuration', we examine the projects' challenges with attuning the designs to children and young people and how these drove their exclusion as users of the emerging mHealth apps. Critical user-configuration draws attention to critical moments in design practices where significant shifts in user-configurations take place, shaping who can become a user. More specifically, we uncover three critical moments: where mHealth projects expand the group of prospective users; where test subjects are selected; and where data governance systems and digital health infrastructures are mobilised in the design process. Throughout these critical moments, there is a drift from user-driven to data-driven design approaches which increasingly exclude groups of users who are less datafiable - in our case children and young people. We argue that besides giving voice to minors in mHealth design processes, we need to be mindful of the design practices that become decisive for - often implicitly - who can be configured as a user.

Introduction

Mobile health technologies (mHealth) targeted at children and adolescents below the age of 18 (‘minors’ in the following) living with a chronic condition constitute an expanding area and are deemed promising in respect to improving condition management in daily life. Although mHealth is not clearly defined, it is generally perceived as the use of mobile devices, often smartphone applications (apps), for monitoring health-related data enabling the user to assess and improve their own management of treatment, symptoms, and everyday life, in communication with health professionals.[3, 4] In some cases, with mHealth, communication between minors and healthcare professionals has improved, fostering engagement, relationship, and trust. However, there is simultaneously an expanding body of evidence questioning the usefulness and outcomes of mHealth for minors.[1,6] Adherence to treatment and improved health outcomes is difficult to achieve in most cases,[7,8] and continuous use and integration into minors’ lived reality with such apps often fails, though we know little about why this is. The lack of evidence for mHealth's usefulness and integration into minors’ lives, has suggested a need to involve minors in the design of mHealth, to ensure such apps are attuned to the lived realities of young people as particular kinds of users. In line with this, self-proclaimed user-driven or user-centred mHealth projects for children and young people are, increasingly, including these groups in the design process.[10-12] Still, challenges remain in launching apps that are useful to minors. In this article, we argue that challenges in attuning the design directly at how minors would be able to make use of them can be explained by some design processes’ incapacity to configure ‘the minor user’. We argue that specific design methods, stakeholders, and integration with existing infrastructures can cause the design to bias against minors, even when this group of patients is initially cast as central to ‘user-driven design’.

Minors that live with and manage a chronic condition

Living with a chronic condition in childhood and adolescence clearly diverges from that in adulthood, and, equally, condition management differs in a range of ways. First of all, minors are largely dependent on caregivers’ decision capacity, power, and capability to support learning about the complexity of their condition, management of it in everyday life, and interaction with the healthcare system. Their assuming responsibility for their own care is gradual and the caregivers’ close supervision of management activities can be needed until the age of 18 years. In adolescence, young people must deal with complex issues of maturation while also learning to deal with their condition and treatment.[15,16] Goal setting can be particularly useful for minors’ motivation to self-manage their condition, but minors’ and caregivers’ goals might differ and even clash. Some minors regard their process of liberation from their parents differently from peers’, while the parents on the other hand find it difficult to let go of the responsibility. Furthermore, minors’ main concern is most often to fit in, and be like ‘normal’ peers, but their condition follows them everywhere and puts everyday restrictions on them, preventing them from forgetting about it, and disrupting their leisure time, freedom, and social connectivity. Adapting their lifestyle to adherence and strict treatment routines, finding condition management complex, monotonous, boring, time-consuming, and interrupting of their everyday life – all are constant reminders of their condition. To counteract this, young people can perform passive coping strategies such as withdrawal, non-adherence to treatment, avoidance of certain activities, and not paying due attention to their bodies, symptoms, condition, and treatment. Their concern with not being different and establishing normalcy is thus associated with suboptimal self-care management.

Designing mHealth with and for minors

Many mHealth projects seek to develop apps to assist minors in improving their illness management and take a ‘user-driven’ approach to design these apps. Although it is hard to grasp what exactly a user-driven design approach implies, it refers in general to a process of collecting various types of information about the user, either by traditional methods, focusing on what people from the intended target group say and think, or with contemporary interdisciplinary design methods, such as ethnographic and observational methods that investigate what people do, want, and feel.

The role of minors in technological design is thus increasingly moving from that of passive users to participants involved in the design processes. However, scholars have voiced challenges associated with including minors in such processes in terms of power gaps, complex technology, and objectives that seem distant from the child's own experience. Furthermore, user-driven innovation is often challenged in continuously involving users and transforming gained insights and requirements into technical requirements of the design (and the other way around) in a multidisciplinary development process. ‘Although the user-driven innovation paradigm advocates an open perspective and stimulates the involvement of users from the early development stages onwards, this still contrasts sharply with the narrow and technology-centric scope of many projects’ de Moor argues.

Other scholars have argued that adaptations in mHealth depend on alignment between values inscribed in the design and values of the patient, and awareness of contextual and motivational aspects of the design. If the design processes do not take into consideration particular circumstances associated with the group that the design is intended for, it might embed barriers in the design, preventing this particular group from using it. For instance, studies have shown that minors and parents hypothesise that the parent will be the main actor performing condition management with a proposed mHealth app, yet that parental involvement and role are neglected in the design processes of mHealth for minors. Another example, given by Vinther finds that minors living with juvenile idiopathic arthritis (JIA) felt they had a normal life and did not want to pay more attention to the condition, but that the introduction of a self-management app necessitated a reflective manual activity which increased their thinking about the condition and feeling like patients. Furthermore, Wong et al. argue ‘there has been limited attention focussed on how different user-centred approaches identify, select, interact with and assess their “users” […]’. mHealth-studies rarely account for how patients were engaged, informed the design, or how they were conceptualised as users during the design processes, which leaves the field of mHealth innovation with little experience in qualifying design practices to realise designs useful for minor patients. In Table 1, we summarise the challenges that other scholars have found to play part in designing mHealth that resonates with the minors’ ways of living with chronic illness.

Table 1.

Challenges in designing mHealth that resonates with minors that live with a chronic illness found in secondary research materials.

Reference	Challenges in mHealth design projects
Read et al. 24	Inability to level out power gaps between minors, developers and other adult participants in the design process.
Metatla et al. 25	Inability to translate complexity of the objectives into something that minors can relate to.
Poole and Peyton 31	Minors’ inability to account for themselves in semi-structured interviews, workshops, and observations.
Smith at al. 32	Lack of recognizing that what children and young voice can conflict with their actual experience and practices with the final technology.
Stålberg et al. 33	Failing to apply design methods that enable insight into minors’ daily routines, perceived benefits, and obstacles in making use of healthcare technologies.
Shin and Holtz 34
Shin and Holtz 35	Favouring of parents’ perspectives over minors’.
Armoiry et al. 29	Neglecting parents’ roles in illness management while only attending to practices of the minors.
Shin and Holtz 35	Limiting involvement of minors and parents to a single design activity or interview instead of throughout the design process.
Freeman and Neff 36	Repurposing technologies built with adult users for youth’, thus seeing them as ‘mini-adults’.
Majeed-Ariss et al. 37	Omitting to collect project experiences on developing mHealth with and for minors to be used for furthering other mHealth design projects.

On an overall level, the challenges presented here emphasize the problem of minors being represented through adult perspectives. Furthermore, they speak to the neglect of the socio-material and structural context of minors’ illness management and which the mHealth apps are to be integrated with. In an extension of this, we will in this article argue that mHealth design projects’ can come to steer the design of the mHealth apps accordingly with some adult standards that are highly embedded in the innovation frame of digital health technologies.

In this article, we will explore two design processes that initially aimed at providing mHealth for minors with either haemophilia or rheumatoid arthritis, yet ended up launching the apps only for adult patients. We aim to make explicit how this exclusion of minors as users happened during the design processes – how the projects encountered barriers to keeping minors in the design loop and turned to focus on adult patient target groups instead. By introducing a concept of ‘critical user-configuration’, we mobilise the rich literature in Science and Technology Studies (STS) that focuses on the co-construction of design and user identities. Feminist scholars of STS have furthermore provided critical analyses of processes of bias and exclusion in design,[38-40] which direct our attention to what we call critical moments in design practices where such biases and exclusions arise.

In the following, we expand the analytical approach, situating our concept of ‘critical user configuration’ in the STS literature on users and critical moments in the design of digital systems. Following an outline of our methods, we will present our findings focusing on three critical moments of user configuration; and finally, end by discussing how a focus on these may explain how users otherwise central to design aspiration become excluded and why. Attending – critically – to such user-configuration moments may be of particular importance as digital design is increasingly becoming data-driven, despite still claiming to be user-centred, user-driven, or participatory.

Analytical perspective

Configuring the user in designing technologies

Users and their relation to design and technology have received much attention in social science fields. An extensive body of work in Science and Technology Studies (STS) has laid grounds for contemporary thinking of technological innovation and argued that design and ‘the user’ are co-shaped by numerous social and technical actors involved in the design process.[41-43] Woolgar famously argued that users are configured along with technological design. He accounted for processes where developers define the identities of assumed users while also determining what they can and cannot do with the designed technologies. Woolgar's approach has been criticised for merely attributing user-configuration to the actions of developers and regarding user-configuration as a one-way process, missing that the technology is also shaped by users. However, his semiotic approach focused attention on ‘the user’ as a flexible imaginary abstraction of who can use the design that is constructed along the design process, rather than a fixed representation of a real individual or group. ‘User-configuration’ thus implies an ongoing conceptualisation (during the design process itself) of who will be able to interact with, and benefit from, the technology and how. Akrich argued that in developing new technology, the developers inscribe certain preferences, motives, and competencies of potential users into the design of the product: therefore, the final technology contains a ‘script’, meaning that the technology attributes and delegates certain competencies, responsibilities, and actions to users. This means that all technologies have embedded demands of who can use them, how and for what, and that if actual users do not match these inscribed representations of the user and use-cases, it is likely that the technology will fail. Storni elaborated user-configuration by arguing that purpose, designers, participants, technologies, methods, and the user are mutually constructed during the process of technological design. Furthermore, feminist scholars interested in technological innovation raised awareness of historical and cultural bias in user-configuration that can lead to exclusion of women and other specific groups as users[38,39] and called for various kinds of non-users of technologies to be recognised. Oudshoorn et al. examined the semiotics of how technologies come to be adjusted to certain groups and not to others. They argued that to understand why technologies come to incorporate barriers against groups as users, requires investigation into how users are imagined by designers of the technology.

Critical user-configuration

The existing literature has thus critically explored how both human and material actors and larger structural settings shape both design and the user. Little attention has, however, been given to how these actors and settings in practice come to create bias against particular kinds of users – despite their being explicitly targeted by, and actually involved in, the user-driven design processes. What are the specific moments at which these users ‘disappear’? In our particular case, we wonder how, despite these mHealth projects’ striving to include minors as participants in the design from the very beginning, do they come to realise designs that are not useful to minors? While existing – particularly feminist – perspectives on user-configuration have enabled a critical analytical stance, we want to add a second aspect of criticality – namely by attending to critical moments in the design process which afford a divergence away from certain user groups. We are here inspired by the work of Kaufmann et al., who, in their analysis of data-intensive practices, introduce the concept of ‘data criticality’ to draw ‘our attention to those moments of deciding whether and how data will exist, thus rendering data critically relevant to a societal context […]. These encounters, we argue, also require our critical engagement’. Although we are focusing on users, rather than data as such, our analysis will demonstrate that these two can, in practice, become very difficult to distinguish, and that a shift from ‘user’ to ‘data’ can in itself become a critical moment of exclusion. With our concept of ‘critical user-configuration’ we – like Kaufmann et al. – call for attention to certain moments requiring our critical engagement, so as to help us account for the socio-technical constellations in the design processes that become decisive for who becomes the user. Further, we explore how different actors are drawn in to inform the design's purpose and functionality, but in doing so also bias the design towards specific groups and against others – even if these groups seem to be represented in the design method and design ideology.

Study setting and cases

We followed ethnographically the two projects that designed apps for continuous condition management of, respectively, rheumatoid arthritis and haemophilia in Denmark, initiated in 2013 and 2015. In the following, we use ‘mHealth-supported condition management’ to describe both projects’ design aims: vis-à-vis, to enable the user to monitor, share, read, and act upon correlations between symptoms, treatment, activities, and behaviour in communication with healthcare professionals. The projects were chosen as ethnographic cases because they initially targeted minors as users of the mHealth technologies.

Haemophilia-app for better decision-making in condition management

The haemophilia project was a public–private collaboration between two clinical haemophilia centres, two regional telemedicine centres, a digital health company, and the Danish Haemophilia Society. The project set out to design a digital ‘decision-supporting tool’ (this and the following quotations from the projects are translated from Danish by the first author) for all haemophilia patients in Denmark, including children and young people. Haemophilia is a rare bleeding disorder caused by a deficiency of a blood coagulating factor that leads to post-traumatic and spontaneous bleeds. Despite major advances in treatment, patients must endure frequent injections, pay attention to and act upon bleeds, and attend frequent hospital visits. As haemophilia patients mainly treat themselves at home, a driver for the project was to improve treatment plans, ‘optimise the patient's self-mastering of the condition’, and furthermore support patients in economising their treatment to decrease enormous medicine expenses in haemophilia treatment by enabling patients’ self-monitoring of bleeds and treatment. The project's design approach was defined as ‘user-driven innovation’, which implied ‘discovering demands during the process in close consultation with the users’. Users were scoped as various age groups of patients living with haemophilia – including a group of 0–18-year-olds – and clinicians of the haemophilia centres.

Rheumatoid arthritis-app for young people's self-empowerment in condition management

The rheumatoid arthritis project was a private partnership between a patient association for young people with rheumatoid arthritis (FNUG), a rheumatologist, and a digital health company. The project aimed to develop a self-monitoring app for young people between the ages of 12 and 35 years living with juvenile idiopathic arthritis (JIA) or rheumatoid arthritis (RA) that ‘offered the user a self-insight into the condition, to see correlations in fluctuations of arthritis and achieve better control’; 30–50% of minors diagnosed with JIA carry it into adult life. Due to advances in medication, the prognosis of the disease has improved. However, symptoms and treatment side effects still include fatigue, eye inflammation, joint pain, stiffness, swelling, and inhibited growth. The monitoring was imagined to be useful for the patient him or herself to gain an overview of the condition, but furthermore to be used as documentation for clinicians. Because the project later broadened its target group to include all people living with arthritis, we will refer to the project as ‘the RA project’ – which also framed its approach as user-driven innovation.

Comparability between cases

Some differences between the haemophilia and RA projects should be noticed. First, the haemophilia project was conceptualised as a telemedicine project that would integrate into public clinical practices and public data infrastructures, whereas the RA project aimed to offer patients a self-management tool independent of the public health system, which patients could themselves bring to consultations with their rheumatologists. This leads to the second difference: the haemophilia project would first deliver a finished product with fixed features, and then apply for funding for implementation. In contrast, the digital health company of the RA project could more freely launch and iterate early app-versions continuously within the scope defined with the patient organisation. Our observations of both a public–private and a private project enabled us to compare them and generated insight into design practices related to different market strategies, test approaches, and data processes which nuanced our view on how different structural settings play a part in health technology design practices and configuration of users, as we will show in the Findings section. Third, the RA project did not include children below the age of 12, whereas the haemophilia project initially did, which limits the comparison of the youngest patients across the cases. However, as we are interested in practices of shaping users throughout the projects and the related bias in this, rather than differences between children and young people of different ages, we regard this difference as a peripheral limitation.

Method

Ethnographic exploration of design practice and ‘the user’

From July 2017 to June 2019, the first author, a trained ethnographer with a background in techno-anthropology (henceforth, ‘the researcher’), took part in the two projects by participant observation. At this point of time, both projects had already produced and started testing app prototypes with users. As the full design processes extended over several years, we had timed the fieldwork to achieve first-hand insight into the finalization and launching of the designs. This was out of the belief that we would be able to follow the shaping of the mHealth apps and hereafter how actual minor users would make use of the apps. However, as we have already revealed, we encountered during fieldwork that both design projects increasingly minimized their attention to the target groups of minors until launching the final apps for adults only. Our cases thus indicated something beyond whether designed apps efficiently target actual users’ needs. We realised that they offered an opportunity to understand mechanisms in how and why a design process can drift towards favouring one population group over another event if having an inclusive offset. We therefore decided to look specifically at how certain design practices led up to a point where minors were excluded as users.

Apart from participant observation, we collected materials from prior phases of the projects. These materials included presentations of the early version apps, reports of design workshops and meetings with different stakeholders, user test guides, prototypes, analytics of usage with test users, and reports on needs and development, evaluations, and summaries of participation of patients (i.e. minors). Through readings of these materials, we aspired to reveal ‘neglected issues or forgotten dimensions’ of how the design methodologies and practices of user-driven innovation drove the design and emerging user profile. More specifically, we saw how mentioning of minors, their objections and suggestions regarding the evolving designs, and their representation by user profiles and in use scenarios were increasingly diminished over time, which could be discussed with members of the projects in semi-structured interviews and informal conversations.

Regarding the participant observation, the researcher participated in workshops, meetings, presentations, and conversations in office spaces among UX-designers and developers where current designs were discussed and altered. The researcher positioned herself as a participant in the design process in the sense of sharing with developers reflections about how current designs applied to minors as users. Developers appreciated such opportunities to discuss their target user groups and design methods, while at the same time such conversations gave insight into reasons for former and present design practices and perspectives on designing with and for minors. Through field notes, the researcher thus sought to keep track of how the design and configured user emerged at different times and how certain design decisions, user profiles, and design methodologies made sense in the design situations.

Through thematic network analysis of the documentary material, fieldnotes, and transcribed interviews, we identified and labelled characteristics of ‘the user’, for instance ‘one that needs support when becoming involved in condition management’, at different points of the projects. This labelling helped expose how ‘the user’ changed during the design process. It was not always explicit what ‘the user’ implied during the design process, because user profiles, personas, and so on were only sometimes described. Furthermore, the change of users did not happen abruptly, but gradually, making it difficult to notice that minors were progressively less fitted to the user profile that the designs afforded. However, we continually checked our material to find out what the changing scopes of the design's purpose, features, use-cases, scenarios, and so on, implied for who could use the design, and related this to the circumstances of chronically ill minors. Thereby, we enabled insight into the many phases that an mHealth innovation process includes which ranges from scoping of the project, applying for funds, stakeholder involvement, market analysis, exploration of different stakeholders’ needs, exploration of technological architectural frameworks, target user involvement, drafting of possible designs, prototyping, user tests and iteration phases, analysis of test usage, integration with other digital systems, until launching the apps. We found that within these extensive innovation processes three design practices in particular drove away attention to minors as users. These we refer to as: 1) involving clinicians, 2) adult user testing, and 3) integrating with governance systems for health data.

Although mindful that other moments in the whole of the innovation processes also affect how the design, the use-cases, and the configured user is shaped, we focus on the mentioned three design practices in the following. Through thorough analysis of these, we show how structural bias towards adult patient circumstances characterises the design practices and come into critical tension with chronically ill minors’ particular circumstances – these being that they are not familiar with proving data for assessing healthcare but depend on support on this; they constitute a minority group whose objections can be minimalized compared to a large adult patient population more proficient in generating large amounts of data; and they constitute a group that is incompatible as data subjects with some existing health data infrastructures crucial for the integration of the mHealth apps.

Table 2 illustrates our attention to the three design moments in between the initial involvement of minors in the design process and the final apps were launched. The table refers to what happened in these design moments in each project and how this affected the attention given minor patients as users of the app-designs in the projects.

Table 2.

Overview of moments in the mHealth design processes and how they drove attention away from the minor patient as user.

Moments in the design processes	The haemophilia project	The RA project	Attention to minor users
Involvement of minors	Minors are involved in a workshop to offer their perspective on managing heamophilia.	Young people are involved in a workshop to offer their perspectives on managing life with JIA.	Attention in the projects are drawn to minors’ particular need for support in learning how to manage and deal with their condition.
Moment 1: Involvement of clinicians	Workshops and observations with clinicians voice need for generating continuous data on patients’ treatment and symptoms in a manner that fit clinical system standards.	Meetings with rheumatologists voice need for generating continuous data on the condition's effect on the individual patient in a manner that fit clinical system standards.	Attention shift to the user as one that provides data relevant for clinical assessment of the condition and treatment.
Moment 2: User-tests	Patient usability tests of an app-prototype voice minors’ objections and suggestions, but these are disregarded when related to the greater pool of feedback from adult patient test-persons.	In an early version app launch the project members emphasize the kinds of users that the app has attracted, namely adult patients, but miss reflecting about the non-use it generates with minor patients.	Attention stays with the adult groups of users that show to be proficient in using the apps and generating data, while the minors’ non-use and limited and conflicting outputs in the user tests are disregarded.
Moment 3: Integration with existing data systems and infrastructures	While aligning the app with existing data governance systems and national digital infrastructures a log-in system for adult patients’ access to health care information is chosen for the app.	While data sets from the current users of the early version app is used to form a machine learning algorithm, this algorithm is set to learn from datasets where minor patients are not represented.	Attention to adult data subjects in existing data structures and samples are reinforced while minor patients, that are incompatible with these, are excluded.
Launch of apps	Launch of an app that only allows app-users above the age of 15 to create an app-patient profile.	Launch of an app that target adult patients in its marketing and illness pattern-seeking functionality.	Attention to minors as users of the apps vanished.

Findings

In an effort to nuance the purpose of the initial design idea, both mHealth projects initially involved chronically ill minors through workshops with minors, to learn about their perspectives and needs when living with a chronic condition. ‘Workshop as method’ could be discussed in terms of whether this produces correct insights into patients’ living with a condition and participants’ actual possibility of affecting the initial purpose of the projects. However, we here attend to how this, and other design practices, configured the user. The RA project facilitated a workshop of 12 young members from the patient organisation where challenges in living with JIA were discussed, and solutions proposed via the writing of short notes. The project summarised the expressed needs under the theme ‘The disease should not take me over’; and that the final design would ‘support young people living with RA in the process of managing their lives along with their condition’. The haemophilia project conducted a workshop with haemophiliac minors (0–18-year-olds) living with their parents (18 participants in total), where participants were asked to draw miniature figures of themselves, sketch places and people related to haemophilia and everyday life, and draw ideas for technological solutions to their challenges on templates, which represented a smartphone, a tablet, and a PC. The report summary of the workshop concluded that ‘to increase the involvement of the children, support is needed for the parents in how to involve them [their children], but also the development of tools that support the children in exercising self-management. […] To do this early in life will also be more efficient because children acquire new habits and knowledge more easily [than adults].’

The initial design processes thus made explicit chronically ill minors’ particular circumstances as depending on support in taking responsibility for, and managing, the condition in everyday life. In the following design practice of involving clinicians in the design process, these characteristics of minors’ dependency on support, however, received much less attention, as we shall now describe.

Involving clinicians – configuring the user as a data provider

Both projects engaged clinicians throughout the design processes to ensure the designs were relevant for clinicians’ interaction with patients and assessment of the condition course and treatment plan – patients were still seen as the central user. The haemophilia project regarded clinicians as crucial gatekeepers in making the design feasible, and assured inclusion of their perspective through workshops: here clinicians especially expressed a need for ‘insight into whether the patients – in periods between ambulatory checks – comply with instructions for treatment, or if they possibly need counselling and help in adjusting treatment’ as this went ‘under the radar of the clinicians’. Similarly, the RA project's user-experience consultant explained that their regular meetings with rheumatologists provided insight into challenges in targeting individual patients’ actual needs during limited consultation time, and into patients’ inability to account for the condition course since last consultation. The design could help ‘simultaneously assist [the patient] to get a picture [of the condition] – but also [ensure] that this is a picture that [the patient] can pass on [to the rheumatologist] for shared decision-making’, as the CEO explained in an interview. Thus, in both projects, clinicians brought in demands for information about how the condition was actually managed in daily life as a way to improve communication with patients and assess treatment plans.

Furthermore, in both projects involvement of clinicians also enabled the gathering of information about technical and practical settings for clinicians, so as to secure the feasibility of the designs. To do this, the haemophilia project conducted field observations of clinical work processes before, during, and after paediatric consultations. According to the project's associated observation report, these observations illuminated clinicians’ need to transfer paediatric data to adult healthcare information systems, and for standardising patients’ and parents’ registrations of treatment and symptoms that were at that time paper-based, deficient, and inconsistent. Based on these insights, the haemophilia project reckoned that ‘the shared theme of needs between clinicians and patients was registering and sharing of data’. Patient-provided data would enable ‘professionals to offer individualised and personal guidance to patients’ and ‘offer patients a better insight into their condition course’. Comparably, the RA project collaborated closely with a chief physician and professor in rheumatology to align the design with clinical data practices, to safeguard that, for instance, ‘the pain scale [in the app] is directly comparable to [those in the clinical database]’. Similar to the haemophilia project, the RA project thereby scoped the design purpose as a tool for patients to document various experiences of the condition for ‘better insight into their condition’ to be used as ‘documentation at the hospital’, while also ‘supporting self-empowerment’ of the patients. Both projects’ designs were thus associated with improving processes of information quality and quantity which would strengthen the design's integration with clinicians’ needs, support assessment of the condition, and daily help patients achieve insight into their condition.

The projects’ attuning of the design purpose with clinicians’ perspectives gives rise to important reflections concerning how the user was configured along with this. Clinicians’ perspectives noticeably focussed attention on ‘use of data’ rather than ‘the user’: this brings about a reflection regarding who is positioned as able to predict the use of the design. As argued by Woolgar, IT development often replaces ideas of designing for ‘what users want’ with ideas of future requirements of the technology: ‘[…] configuring the user involves the determination of likely future requirements and actions of the users’. Clinicians were – by the projects – positioned to speak of imagined futures and potentials of the design because of their role in condition management, medical knowledge, experience in health-care services, and their role as gatekeepers for the designs’ integration. Their particular frameworks of time, systems, measures, and data practices drew attention to the necessity of generating patient data. ‘Insight’ became the important objective. Here, we thus argue that the user was configured not in terms of the chronically ill minors’ particular needs, agency, and dependency, but in terms of data fit for clinical settings that took for granted users’ ability and willingness to continually produce, share, read, assess, communicate, and act upon condition-related data. That there are often multiple kinds of users with different concerns, purposes, and abilities that can be difficult to align is a renowned challenge. Here, it means a shift in focus from the group that the design was meant for, to a user who could fulfil the purpose of achieving insight into the condition. The user was thus taking the shape of a data-provider patient. This shift towards the user as a data-providing subject became a critical moment for minors to fit (or not fit) this outline. Whereas minors’ involvement initially in the projects fostered attention to needs for support in becoming involved in condition managing, and support in not letting the condition overshadow the person, little reflection now concerned exactly how patient-provided data would ensure attendant support, or how such data-provider work could possibly demand support. How would, for instance, parental responsibilities for condition management and difficulty in involving their children fit in with this notion of the user as a data provider? How would generating data that clinicians could use to monitor patients’ home condition management affect the distribution of responsibility? Instead of answering these questions, implicit assumptions were made: that patient-provided data would give insights into correlations between everyday condition management symptoms and treatment, increase patients’ knowledge about condition causality, make minors involved and responsible, and inform clinicians to improve treatment and communication.

User tests – the selection of the data-proficient adult user

With these elaborated purposes of facilitating insight into the management of the condition through monitoring patient data, both projects built the first versions of the app-designs to test with patients the value and usability of each design. In these test phases we noticed, in both projects, ambitions to secure the designs’ relevance to chronically ill minors. However, as we shall see, attention was more directed towards proving extensive use and production of data with large populations, rather than towards separate age groups. This caused the objections from, and non-use by, the minors who were test subjects to be drowned out, compared to the majority of adult use-cases.

The haemophilia project drafted first a ‘clickable’ prototype app and carried out a series of usability tests with five adult and two young haemophilia patients. These tests were think-aloud tests where the test subject was given scenarios and tasks for interacting with the prototype, such as: ‘It is Saturday, and you have an activity to attend to in half an hour that demands you to be particularly active, and therefore you decide that you should take extra medication. You decide for yourself how much medication you take and register.’ The scenarios and tasks of the tests were the same for adult and younger test users. The prototype contained pre-registered data simulating that the test subject had been monitoring treatment, bleeds, and activities for a while. In the associated usability report, we read accounts of how an 11-year-old boy and an 18-year-old participated as test subjects, and their experiences with the app. For instance, a graph of bleeds made the 11-year-old to resolve that: ‘I know I have to go to football during these months, and it's already in this period I get the most bleeds, so I’ll just take my medication all those days.’ In this, we notice that he accepted the premise of reviewing and assessing the test data. Another screen told him that his average period between bleeds was 32 days and he assessed that: ‘if I get a bleed, just the slightest, and it's 32 days since, then I can hit it there with a little extra [treatment].’ Here interestingly, but also problematically; he deciphers the number as a prediction for his next bleed to guide his home treatment, while the number rather indicates how well adjusted the treatment plan is. The young test subjects also expressed disagreement with specific features while referring to their everyday lives. For instance, the 11-year-old found it ‘frustrating to register information for clinical purposes, like activity information prior to taking extra treatment’ as his bleeds could not always be linked to injuries. The 18-year-old stated that he appreciated the lack of condition management recommendations in the app. Yet conversely, he later expressed a wish that the app could change his treatment plan in accordance with his registered bleeds. There was thus ambiguity in whether management recommendations should be generated by himself, automated in the app, or proposed by a clinician. However, these particular ways of reading data and reflections on responsibility distribution with the app did not transfer to the summary section of the usability test report that only referred to adult test subjects’ reflections. In the last test phase, the project facilitated a pilot-test with 52 adult haemophilia patients, and one parent, but with no minors, to gather information about use in everyday life context and wishes for improvements of the app. The CEO of the digital health company of the haemophilia project explained in a conversation that the absence in the pilot of test subjects who were also minors was due to the massive workload in the paediatric haemophilia clinic: the healthcare professional who should have helped recruit paediatric patients was too busy to do this.

The RA project also ran a series of small-scale tests with young people living with RA to iterate the app; but, soon after this, launched an early version app to assess its usability and value with real users. As explained in an interview with the CEO of the digital health company in the project, the data generated with the launched app served as ‘real-world evidence data’ of what mattered to users and what features they used. For instance, the data that the company achieved with the launch would witness what symptoms users chose to track. In his opinion, these data expressed people's real needs and motivations in real-life contexts, as ‘[…] we can listen in on their everyday life: What is it they are tracking? How do they feel?’ The real-world evidence data could thus provide knowledge about patients, but also serve for continuous assessment of the usability of the app, the CEO confirmed. These assessments of users’ data productions – downloads, user profiles, and tracking data – however, surprisingly displayed that the app attracted people living with RA much older than the initial target group of 12- to 35-year-olds. Young people did in fact not maintain continuous use of the app. Those who downloaded it merely created a profile and made a few registrations. As the CEO stated: ‘We started off developing for young people, or, with young people for young people, but we have subsequently seen that for a number of older people it looks like it works.’ Herein, lies an assumption that the app only creates a value if the user uses it for months to witness patterns in various registered measures. We suggest that the more sporadic kind of use, that young users performed, could possibly be valuable in other senses. However, this did not conform to the perspectives of the project that determined the value of the app and ran their development and business plans by means of continuous flows of data. The sustained usage among older users led the directors of the project to broaden its target group to people living with RA in general, as the CEO explained. In later design work with the app, we further noticed how user profiling constituted solely adult target users. During a project workshop aimed at having the app take on the identity of a virtual coach, the researcher noticed that participating employees of the digital health company and a hired-in coach had older users in mind when discussing users’ possible personal goals as ‘be able to do gardening’, ‘prioritise one's career’, or ‘be able to play with grandchildren’.

The test practices of the two projects provided two very different accounts of usability. The haemophilia project's tests offered insight into the concrete navigations and reflections of users, whereas the RA project's real-world approach produced numbers of downloads, continuous use, symptom tracking, and user-profile data in patients’ lived settings. Both test approaches aimed to include minors’ perspectives in the tests, but due to different aspects of their user-test methodologies they ended up driving attention away from use by chronically ill minors. The haemophilia project involved two young test subjects, but did not differentiate scenarios to expose particularities of under-18-year-old test subjects’ relations to condition management with the app-prototype, or take these insights further. This was despite the test showing uncertainty among the minors as to what the technology was able to do, and what role they themselves would take on as users of it. The issues raised by the two young test subjects reflected possible non-alignments of the work and responsibility distribution between patient, parents, clinician, and app in the condition management set-up. That the design was to enable patients of all ages seemed to make variations between minors and adults hard to process. Besides that, the pragmatic obstacle of over-burdened paediatric clinicians’ being unable to recruit test subjects prevented their inclusion in the pilot-test, causing the final attuning of the design to rely solely on adult experiences. In the RA project, preoccupation with real-life data caused a shift from user-driven to data-driven innovation, inadvertently causing the project to follow what data evidenced as useful, rather than what missing data hinted at in terms of non-use with the young target user. The attraction of gaining adult users, moreover, formed the developers’ imagination of the user as being an adult in further development activities.

Prior to the test phases, we had seen an increased focus on data in both projects as means to help both clinicians and patients manage chronic conditions. At the point of the user tests, data seemed to shift to centre stage in the design practices, and became less the means than the ultimate goal. The user-test methodologies of the projects were in these different ways not set up to differentiate between users being either adults or minors. The user-test methodologies in both projects were instead attuned to the data-proficient patient who could generate, read, and act upon data for further development of the apps. This attuning to the data-proficient user thus became a critical moment for the chronically ill minors using the app, because these young test subjects only constituted a minority of the test populations, and their difficulties, suggestions, and dropout from the project, thus drowned in the pool of data from adult test subjects in these data-driven user-test setups.

Integrating with data governance systems and digital health infrastructures – the compatible data subject

In the final implementation phase, the haemophilia project collaborated with a regional IT architect to secure the design's integration with the Danish health data governance systems and national digital infrastructures to be able to share data between the patient, clinical systems, patient records, and databases. Through this collaboration, it became evident that implementation required users to use their NEM-ID to log in on the app. NEM-ID is a safe and secure personal log-in for Danish citizens to access public digital self-services. However, only citizens above the age of 15 can obtain a NEM-ID, which meant that minors below this age had to be excluded as users of the app. In discussing this, the CEO of the digital health company of the project explained that chronically ill minors constituted a much more complex case than adult patients: ‘Often it is not the children themselves who should register, it's the parents, and they would then register on behalf of the children, and how does one then manage… this legal finesse?’ The complexity referred to the legal position of minors as subject to parental custody, which excluded them from getting NEM-ID and thereby from direct access to, or delivery of, digital health information. This exposed infrastructural challenges in integrating into the design the requirements of patients not legally responsible for their own health and data. In a classic ‘catch-22’ situation, neither was it possible for parents to use their own NEM-ID to create profiles on behalf of their children, as the digital system would automatically link app-data to parents’ own personal health information and not to their child's health record. Parents can access their children's health information via sundhed.dk by using their own health profile and NEM-ID, but as in this case, parents cannot use their NEM-ID for health-data tracking of their child. The fact that parents have a digital health profile while also having legal responsibility to take care of their child's digital health profile posed an architectural enigma when attempting to align the mHealth innovation with existing data governance systems and national digital infrastructures. The above quotation however also reflected an uneasiness in the CEO as to who should and could register experienced symptoms, treatment, and other measures of the child within these domestic dynamics. At what point was the child able to report on their own symptoms? To what extent could parents report on the experiences of their child? The CEO's proclamation that the parent should monitor on behalf of the minor, however, conflicted with the projects’ initial insight into parents’ expectations that their children could be involved in, and responsible for, management practices with the app's design.

In the RA project, another digital infrastructural issue emerged as a critical moment for configuring minor patients as users in the further development of the app. The CEO reasoned that the number of app-users was currently limited because the algorithm in the early versions of the app was too simple to provide insights into complex correlations between symptoms, treatment, and daily life, and thus did not really create value for users. This reasoning for non-use depicts a paradox similar to the one pointed out by Cressey et al. about developers’ wanting users’ inputs for what the machine should be like, but at the same time wanting them to interact with ‘the kind of machine a user would expect’. The RA project depended on users’ tracking in order to realise an intelligent algorithm that included insights users found relevant in their daily living. However, according to the logic of the CEO, users refrained from providing such insights if they did not receive intelligent feedback from an advanced algorithm. Therefore, the CEO explained in an interview, the project was preparing a collaboration with a foreign company and a Danish university to create a machine learning algorithm capable of providing more complex insights for users. To develop the algorithm, the company planned to use machine learning where the algorithm itself evolves by building a mathematical model based on a sample of data. Thereby, the algorithm is not simply mathematically constructed by engineers but depends on input data to improve its performance on the specific task. Although the app-data were not plentiful enough to teach the algorithm, the machine learning would be established on statistical properties from cohort data sets in databases of RA patient data. This would allow the app to ‘know’ correlations of some measures for RA, while it would then find correlations with other measures via the data that app-users generated to find patterns in the symptoms, activities, triggers, treatment, and various personal experiences of the users. The algorithm would thereby provide the user with new insights into their condition. Regarding minors with JIA, this raises an issue of the extent to which paediatric JIA patients would be represented in the databases selected for teaching the algorithm. At the time of writing [September 2021], we do not yet know which databases will eventually be used for this algorithmic work, or if paediatric data will be included; yet it seems crucial to find ways in which the algorithm will be able to distinguish between the statistical properties of minors, youth, adults, and possibly any other groups. Regardless of this however, the algorithm would learn to create value for users of the app and thereby amplify the previous de-selection of patients who are minors because of their lack of data proficiency in the previous user-test setup. What minors would find useful to track, and their particular patterns of app-measures would not be reflected in the continuous learning of the machine learning algorithm. Theoretically speaking, and voiced by other scholars as bias in machine learning (see for instance Sun et al. ), the machine learning algorithm would provide insights into ‘adult patient condition patterns’ because this is what it would continuously detect.

In line with feminist STS scholars’ attention to structural bias in technological innovation against specific groups of people (13–15), our point here is that minors’ particular restricted affiliation with data governance systems and digital health infrastructures, and their absence from data sets used for algorithmic data work, prevent their representation both in configuration processes of the user, and in designs for further development. Their exclusion as data subjects in these data-driven design processes has consequences as to how projects can configure this group as users. Whether minors can be configured as users in the process of integrating designs with existing infrastructures, legal regulations, and existing datasets thus depends on how they are already datafied and datafiable, which we would suggest framed as: how they are compatible data-subjects. Compatible data subjects would thus mean a data representation of a person who fits a given system. When the minor is not represented by data in a system, or cannot access a system to become represented, he or she is incompatible with the system, and this is a critical moment for further configuration of the minor as a future user. In our cases, the projects came to configure those groups that were already enrolled as data subjects in existing data practices, because these were compatible with the data governance systems and digital health infrastructure for the algorithmic learning, while overlooking users who did not transfer to these digital spaces, namely minors.

Discussion

Design practices critical to user-configuration of minors with chronic conditions

In the analysis, we explored three design practices that particularly configured the user to hold characteristics different from those characterising patients who are minors. With the involvement of clinical perspectives in the design came a demand for patients to be data providers in continuously monitoring and assessing their condition management, which conflicts with the knowledge we have as to minors’ resistance towards a regular focus on their condition, and their reliance on support in reading and acting on health information. In the material from the user tests, the distinction between the minor and adult user ceased and the user was configured as a data-proficient patient belonging to a large population capable of generating data for further development of the technologies. In integrating the design with governance structures and national digital infrastructures for health data, the user was characterised by his or her existing affiliation with and access to digital spaces, which excluded minors because of their incompatibility as data subjects. We argue that the three highlighted design practices configured the user as: data-providing patients, part of a large data-proficient population, and compatible data subjects. This user profile, while also excluding other groups such as patients subject to legal custody or groups with impaired health literacy, to an especially great extent excludes patients who are minors.

Similar to feminist STS scholars’ explication of how male developers can come to bias design towards males we observe that adults project members made use of design methods more attuned to adult patients to further the design. On top of that, it seems that the limited involvement of minors fuelled the process of biasing the design against the minor user and towards the adult user. Like Shin and Holtz, we found that the actual involvement of minors in the design processes was limited to a few activities. The minimization of opportunities for minors to feed back into the emerging design might have prevented objections towards the emerging of designs that were more attuned to adult data-able patients.

Design processes are steered by more than users

Although the projects initially identified both clinicians and different age groups of patients as their target users, we see that the shape of the app design and the user were much driven by a broad range of human and non-human actors drawn into the design process at various times. Clinical practices, data systems, technical infrastructures, safety and security structures, data-reliant economy and development strategies, and juristic categorisation became decisive for how the user could be configured along with the design. Embedded in these structural settings were certain scripts for minors and their agency. We find that the structural settings of minors are decisive for how they can be configured in these design practices. The user is configured not only by designers or children and young people but by settings and emergent purposes that accompany the design methods. Although the user-driven design practices entail methods of involving stakeholders, user tests, and integration into data systems and structures, we argue that these structures also shape the design and the user. The very design methodology of aligning the design with clinical practice, facilitating user tests, and the integration with data structures did not set off an alarm when the target group of minors became more and more excluded because the design process focused on those groups that could become represented by data and that would keep the development process going. In turning to data as both a goal and a means to design technologies for condition management, we thus identified a critical point at which the design turned away from minors as potential users. The design methodologies became increasingly more data-driven than user-driven: since the need for sharing data became predominant, the development of the app configured those users who could be datafied – who could be data providers, were data-proficient and compatible data subjects. We regard the privileging of data problematic because limitations in existing data practices, access, capabilities, and engagements can exclude specific groups as users of innovation projects that are to deliver certain quantities and qualities of patient data to prove their effect and economic worth.

If the incapacity of mHealth innovation to attune to minors goes unresolved we might risk that this group does not benefit from the technological opportunities that lies in assisting challenging processes of adapting complex treatment directives to everyday life. Furthermore, we might risk that mHealth app that convey expectations more applicable to adult patients make minors lose the courage to seek out their own opportunities to engage with illness management in a manner that fits their present being. Lastly, we might risk losing opportunities to achieve a more informed and economically efficient setup for minors, parents, and healthcare provider to collaborate on finding increased ways of managing the illness, because minors do not recognise their role in making use of mHealth apps. On the other hand, we also need to bear in mind the projects’ dependency on and embedment in the data infrastructures and incentives, clinical practice, juristic categorisations, and digital safety and security structures. The projects were not all free to align the design with minors’ less datafiable positions. Although scholars have called for identifying what restricts and enables minors in their lives, we suggest that attention is also given to what restricts and enables their representation as users in data-focussed design processes.

In suggesting how to seek out opportunities for bridging between different stakeholders’ demands of the emerging mHealth design and minors as users, we are reluctant to call for increased participation of minors’ in mHealth design processes. This is because, as we have shown, they are easily voiced over by adult actors and they are not fully capable of explicating the barriers and opportunities for using health data-reliant technologies. Rather, we suggest focussing more attention to the usecases than the users. We encourage that project members are the ones that take the role of being participants, namely in minors lived realities. More specifically, we encourage mHealth design projects to make use of ethnographic methods in various situations where illness management can be said to be going on in minors’ lives. This would further insight into the orchestration of people and things in minors’ illness management and possibilities to identify structures and existing (health data) practices that individuals do not think to mention when invited into the design realm. As other scholars have shown, minors’ ways of learning how to take on more responsibility for illness management differ from adult patients’, and especially imply that they engage practically and playfully with physical objects associated with treatment and through negotiations with parents.[60,61] mHealth design projects that target minors should obtain and bring into play such knowledge which could imply that innovators participate in the targeted group's lived realities and seek out how practices and roles in illness management are formed and which underlying (digital, normative, legal etc.) structures this implies.

Critical user-configuration as a way to expose bias

Although inspired by feminist scholars’ demonstration of bias in technological innovation towards particular users – for instance towards white highly educated male users – we formed a critical user-configuration approach both to enable a critical analytical stance and also to focus on moments in the design process that are critical for configuring certain groups of users. This approach afforded insights into mutual processes of configuring users and shaping designs in relation to participants and to structural settings involved in the design process. We continually asked what kind of user these involvements afforded, and how this fitted the initially imagined user. This critical user-configuration approach fostered descriptions of design practices and engagements of social and technical actors crucial for moving the design towards a stable form for condition management.

However, our attention to how the continuously changing user of the projects fitted the minor as user, also spurred us on to ask new questions – in relation to the turns the design took – about minors living with chronic conditions. For instance, minors’ dyadic dependency on caregivers, malfunctioning paediatric data practices, over-burdened paediatric clinics, legal subjectification, and incompatibility with data systems seem to be characteristics taken for granted regarding minors’ situatedness in broader societal structures. However, it is not taken for granted that these factors also constitute obstacles when projects innovate digital technologies for establishing minors’ improved agency in, and greater benefit from, health services. When observing the technological design, our continued concentration on the issue of minors as potential users of the final mHealth technology, helped to reveal the bias in the design processes. We argue that while attention to technological bias against women, other gender identities and ethnic groups are increasing, bias against children and adolescents living with chronic conditions similarly calls for greater attention. Feminist scholars have argued that ‘Technological innovation requires a mutual adjustment of technologies and gender (among other) identities’. Further to this, we find that when it comes to under-age people, technological innovation requires additional mutual adjustment of both technology and the structural circumstances of minors, because it is these factors that become critical in enabling minors to be configured as users. This concerns minors’ social boundedness and inexperience with data and condition management practices. This also concerns minors’ personal experience of readiness, or lack of readiness, to take on more responsibility for their own condition management in relation to their caregivers and their lives in general.

Furthermore, our study highlights technical and data-driven methodologies’ incapacity to support the sustaining of chronically ill minors as a particular kind of user when it comes to their (lack of) data compatibility until they turn 18. Minors do not have legal responsibility over their own health, which, naturally, is a protective measure, but which also limits their access to digital health innovation and contrasts with clinicians’ and parents’ experiences of children's potential capabilities in taking on responsibility for their own health management. However, extraordinary work would be involved in changing these embedded structures around minors to afford their configuration as users in such digital health innovation and would create other concerns to be addressed.

Our case study took place in Denmark which serves as a specific context in terms of the healthcare system, digital innovation, data governance systems, digital health infrastructures, safety and security measures, and legal regulations. We however propose that critical user configuration is relevant internationally and beyond the field of digital health, as it requires us to remain focused on technological innovations’ initial targeting of particular people as users, and to detect – throughout the design process – critical moments for configuring these target groups as users. Descriptions of these critical moments make explicit the inconsistencies between the particular group, the imaginations of the group, the design, other user-representations, stakeholders, infrastructures, regulations, design methodologies, and incentives of innovation projects.

Conclusion

This article examined obstacles in mHealth design processes that led to the failure to realise a design useful for minors living with chronic illnesses. We found that although our two project cases initially accounted for minors’ perspectives, minors were eventually dropped as potential users of the mHealth apps that were, ultimately, only realised for adult patients. We examined what drove this exclusion of minors from being users of mHealth through a concept of ‘critical user-configuration’: this drew attention to critical moments in design practices – points where significant shifts in user-configurations take place, shaping who can become a user and thus biasing the design towards specific groups, but against others. Through this conceptual framework, we explored the impact of three critical moments: when the mHealth projects expand the group of prospective users; when test subjects are selected; and when data governance systems and digital health infrastructures are mobilised in the design process. Any or all of these may lead to the exclusion of certain groups of users – in our case minors – even if initially included as part of a user-centred design process. We furthermore showed that throughout these critical moments a drift happens from user-driven to data-driven design approaches which increasingly exclude groups of users who are less datafiable. We argue that besides giving voice to minors in mHealth design processes, we need to be mindful of the critical moments of design and datafication which – often implicitly – determine who can be configured as a user. Furthermore, we want to highlight that mHealth designers should be encouraged to pay close attention to all groups of target users, and to voice any concerns they might have as to difficulties in maintaining particular groups throughout the design process. This could help bring to light any potential bias against particular groups in the context of design and avoid their being excluded from the use of the final mHealth technology.