Value Sensitive Design and power in socio-technical ecosystems

1. Introduction

Recent European policy papers call for the consideration of human values 1 in the design of information technology (European Commission, 2020a, 2019; HLEG-AI, 2019; Datenethikkommission, 2019). Approaches such as Value Sensitive Design (VSD) promote the idea that human values can be accounted for in the development of technological artefacts and provide a framework for systematically analysing, weighing, and operationalising them (Friedman et al., 2008; Friedman & Hendry, 2019). However, while VSD is well received in the academic context and attracts attention from various disciplines such as computer science and information systems (Friedman et al., 2008; Friedman & Hendry, 2019; Winkler & Spiekermann, 2018; Mueller & Heger, 2018), computer ethics (Brey, 2010; Introna, 2005), healthcare (Walton & DeRenzi, 2009), urban design (Borning et al., 2008; Waddell et al., 2008) and others, there are challenges barring the path to widespread adoption.

Reflecting on such “grand challenges”, Friedman and Hendry (2019) name “accounting for power” as one of them. 2 In this paper, the term “power” refers to “the ability of agents […] to realize a certain outcome” (Brey, 2008, p. 75) 3—specifically design decisions—“even against resistance” (Weber, 2019, p. 134). Friedman and Hendry (2019) elaborate on the challenge: VSD “has not yet explicitly addressed how to handle differences in power among […] stakeholders [and how] best to account for power relations within a value sensitive design framing remains an open question.”

This paper argues that this challenge is exacerbated in many cases by the integration of technical artefacts in increasingly vast and complex socio-technical ecosystems defined as “a dynamic community of competing and interdependent people, organizations, and computing systems operating in a complex, capricious environment” (McConahy et al., 2012, p. 1). In such socio-technical ecosystems, the power over the variety of independent design decisions which, in their totality, define the shape of an artefact is often distributed over various actors. Furthermore, due to their socio-technical nature, containing a “technical, social, political, and economic” (van House, 2004, p. 18) as well as “organizational […] and business” (Feiler et al., 2006, p. 27) domain, power can manifest in various forms in these ecosystems. 4 In order to account for all the domains in which power can manifest itself, the paper adopts a systemic view on power, which “regards power as the property of broader social, economic, cultural, and political networks, institutions, and structures” (Sattarov, 2019, p. 20) and focuses on how “systems confer differentials of dispositional power on agents, thus structuring possibilities for action” (Haugaard, 2010, p. 425; see also Sattarov, 2019).

The remainder of this paper explores the following questions: 1) how and to what extent does the “grand challenge” of accounting for power in VSD get exacerbated by the integration of technical artefacts in increasingly vast and complex socio-technical ecosystems; 2) how does the organisational structure of socio-technical ecosystems affect the challenge of accounting for power in VSD; 3) how can this challenge be addressed; and 4) are there positive effects for VSD if the approach is applied in settings in which the power to make design decisions is distributed over various actors.

Section ‎2 provides an overview of VSD. Section ‎3 further elaborates on the actors involved in developing technical artefacts in different types of socio-technical ecosystems and their respective leverage over how developers can account for specific values. It discusses two exemplary types of socio-technical ecosystems that differ in the degree of decentralisation and, thus, the way power is distributed within them: platform ecosystems such as Apple’s iOS ecosystem (section ‎3.1) and blockchain-based systems such as Bitcoin and Ethereum (section ‎3.2). Section ‎4 outlines how adopting a power-sensitive ecosystem perspective can foster a more pronounced understanding of the challenge of accounting for power. Based on these observations, section ‎5 derives some reference points for addressing the challenge of accounting for power in socio-technical ecosystems. Lastly, section ‎6 concludes.

2. The Value Sensitive Design approach

According to Friedman and Hendry (2019, p. 3), VSD “seeks to guide the shape of being with technology”. Directed at “researchers, designers, engineers, policy makers, and anyone working at the intersection of technology and society […], it provides theory, method, and practice to account for human values in a principled systematic manner throughout the technical design process”. To account for values in the design process of technical artefacts, VSD is structured in three phases of action: conceptual, empirical, and technical investigations. Pertinent literature maps out the respective phases primarily by determining what practitioners should aim to achieve in them. The approach deliberately refrains from prescribing specific methods in the individual phases, allowing VSD practitioners to select and integrate methods tailored to the respective context of application on a case-by-case basis (Friedman et al., 2008; Friedman & Hendry, 2019).

Conceptual investigations “comprise analytic, theoretical, or philosophically informed explorations of the central issues and constructs under investigation” (Friedman & Hendry, 2019, p. 12). They address issues such as the identification of direct and indirect stakeholders, the nature of the respective stakeholder’s implication, the conceptualisation of values, and dealing with value conflicts (Friedman et al., 2008). Regarding value conflicts, it is important to note that such conflicts can also exist between human and instrumental values (Friedman & Hendry, 2019) and between values that are directly affected and values whose preservation is being put at risk only in the future (see Czeskis et al., 2010). In a more recent publication, Friedman and Hendry (2019) also include developing a framework for evaluating a successful application of VSD into this phase.

Empirical investigations employ quantitative and qualitative social sciences methods to determine the stance of (groups of) stakeholders towards values and their respective weighing (Simon, 2016). Additionally, practitioners can deploy empirical methods in a later stage to “evaluate the success of a particular design” with regards to whether it supports the realisation of a particular value as intended (Friedman et al., 2008, p. 72). Empirical investigations of this second form aim to answer whether the objectives defined in the conceptual investigation have been achieved. In both early- and late-stage empirical investigations, developers apply advanced survey and interview methods to disclose discrepancies between the espoused practice of stakeholders with their actual practice (Friedman et al., 2008). Thus, empirical investigations provide “a more situated understanding of the socio-technical system” in question and facilitate “the observation of stakeholders’ usage and appropriation patterns, but also whether the values envisioned in the design process are fulfilled, amended, or subverted” (Simon et al., 2020, p. 4).

Technical investigations also take two different forms in VSD. The first form comprises a retrospective analysis of existing technological artefacts and aims at disclosing “underlying mechanisms [that] support or hinder human values” (Friedman et al., 2008, p. 73). This form thus corresponds roughly to what Brey (2010) and Introna (2005) refer to as “Disclosive Computer Ethics”. The second form of technical investigations “involve[s] the proactive design of systems to support values identified in the conceptual investigation” (Friedman et al., 2008, p. 73). Practitioners here address how the respective conceptualisation and weighing of values can be operationalised and accounted for in the design process, i.e., how they can be translated into code.

The three phases of Value Sensitive Design repeat iteratively. Neither a starting point nor an order is prescribed. The respective phases are intended “to inform and shape and reshape each other” through the iterations (Friedman & Hendry, 2019, p. 35).

Because VSD does not prescribe the use of specific methods in the respective phases, recent overview articles and literature reviews (Friedman et al., 2017; Friedman & Hendry, 2019; Winkler & Spiekermann, 2018) provide practitioners of VSD with heuristics on how to proceed by invoking exemplary case studies. They instance methods such as stakeholder analyses (Friedman et al., 2006), value scenarios (Nathan et al., 2007), ethnographically informed inquiries (Nathan, 2012), multi-lifespan timelines (Yoo et al., 2016), and others. Additionally, pertinent literature provides further heuristics such as lists “of human values with ethical import that are often implicated in system design” as a tangible basis for practical application (Simon et al., 2020, p. 4; see also Friedman et al., 2008).

3. Accounting for power in socio-technical ecosystems

In contrast to the development of independently working, stand-alone, monolithic technical artefacts, the development of artefacts integrated into socio-technical ecosystems have a much more constrained scope for design. To enable coordination among providers of components of a socio-technical ecosystem, the component’s design must account for the existing technical and non-technical features of the ecosystem. Thus, the actors (co-)determining these features set restrictions to design decisions for novel components of an ecosystem (McConahy et al., 2012), including attempts to account for human values.

The following sections showcase two types of socio-technical ecosystems, characterised by different actor constellations, to reveal the specific manifestation of the challenges for applying VSD in the respective contexts. Section ‎3.1 focuses on platform-based ecosystems such as Apple’s iOS, Google’s Android, and the Facebook ecosystem, whereas section ‎3.2 focuses on blockchain-based ecosystems. The cases differ in how power is distributed in the respective types of ecosystems, how it manifests, how visible its distribution is, and the available modes of governance to address power-related issues. The dissimilarity of the cases allows to take a wide-angle perspective and to identify various facets of the challenge of accounting for power in VSD.

3.1 Platform-based ecosystems

The majority of digital interactions occur in ecosystems, often facilitated and connected over a digital platform (Lusch & Nambisan, 2015). The term “platform” is often a source of confusion due to a variety of definitions. In this paper, the term refers to a software-based system as the core with an extensible codebase that enables functionality for users through additional software subsystems in the form of peripheral applications—or modules—that interoperate with it (Baldwin & Woodard, 2009; Reuver et al., 2018; Tiwana et al., 2010). Peripheral services are provided by developers to enable the provision of functionality, service, or content (Constantinides et al., 2018), which can be accessed by the user via the platform (Ghazawneh & Henfridsson, 2013).

Previous research has already addressed some challenges for applying VSD (or accounting for human values more generally) in platform-based ecosystems (Shilton & Greene, 2016; Shilton & Greene, 2019; van Dijck et al., 2018; Warnier et al., 2015). For instance, focusing on deliberations of mobile application developers in developer forums on how to account for values, especially privacy, Shilton and Greene (2016) demonstrate the extent to which platform providers can assert their ideas without actively engaging in design processes. Shilton conceptualises the platform provider’s means to do so as “value levers” (Shilton, 2012) and, together with Greene, provides comparative studies on the use of these levers in different platform ecosystems (Shilton & Greene, 2019). However, a more elaborate ecosystem perspective—as developed in information systems research—could provide a means to refine such an analysis.

According to information systems literature, the platform provider’s central role in platform-based ecosystems is a facilitating one (van Alstyne et al., 2016). To scale a platform, the platform provider needs to attract external actors into the platform ecosystem that engage in interactions. In platform-based ecosystems, mainly actors of four different groups come together: users, platform providers, app providers, and third parties. Platforms enable external developers to contribute to the ecosystem by providing so-called boundary resources (Constantinides et al., 2018; Tiwana & Konsynski, 2010). Boundary resources are socio-technical manifestations of the platform provider’s power to influence a platform ecosystem (Ghazawneh & Henfridsson, 2013), such as application programming interfaces (API), software development kits (SDK), legal guidelines, and application approval processes (Eaton et al., 2015; Karhu et al., 2018).

As control points for a platform provider, boundary resources facilitate an arm’s length relationship between the platform provider and service providers (Ghazawneh & Henfridsson, 2013). They offer the providers of peripheral applications access to a platform’s resources while allowing the platform provider to retain influence over the platform (Eaton et al., 2015). Using boundary resources, a platform provider orchestrates its platform ecosystems and enables service providers to participate in and contribute to the platform’s development (Eaton et al., 2015). Designing and implementing boundary resources is a balancing act of retaining power while supporting service providers to create independent platform-based innovation (Eaton et al., 2015). Thus, platform providers hold the privileged position to exercise power by determining the design of boundary resources and thereby influence the actions of service providers and third parties involved with the platform (Eaton et al., 2015; Ghazawneh & Henfridsson, 2013), with direct implications for how these actors can account for values.

This indicates that platform providers can serve a decisive role in encouraging (or discouraging) design decisions that support the realisation of human values. For instance, in the redesign of its boundary resources via iOS 13, Apple introduced fine-grained user configuration options regarding the usage of location data by apps (Apple, 2019). In previous iOS versions, users could choose among the three options ‘Never’, ‘While Using the App’, and ‘Always’ (Apple, 2019). iOS 13 introduced the additional option ‘Ask Next Time’. Users and the developers of applications in Apple’s ecosystem are directly affected by such decisions. The configuration options have a considerable impact on user information privacy since the user can make case-by-case decisions on whether or not to grant access to their location data to an app. App developers, on the other hand, have to consider these case-by-case decisions in the expected user behaviour. Platform providers mostly prescribe such changes in boundary resource design unilaterally. Users and developers of peripheral applications are often regarded as passive recipients of these changes. Although the developers of peripheral applications can generate some degree of pressure through public criticism (Hestres, 2013) or building coalitions to achieve their goals (Perez, 2020), the decision-making power lies with the platform provider, in this case, Apple.

In another instance, Apple changed the data interface design for apps to access the MAC (Media Access Control) addresses of the devices an iPhone is connected to. Various applications misused this interface to bypass restrictions on location data access. They approximated the location data by using these MAC addresses in combination with publicly available databases that offered the specific locations of the devices that hold the respective MAC addresses. With the update to iOS 11 in 2017, access to these network data was disabled (Butts, 2017). However, the interface design also blocked data access for app providers that offer network services. As a consequence, these apps were no longer functioning. Thus, Apple restricted the scope for design of app providers, ruling out an operationalisation of privacy that would maintain the existing functionality.

Lastly, digital service providers and related services may also be influenced by the necessity of maintaining and keeping up with platform updates by the platform provider, such as APIs or framework refinements (Ausloos & Veale, 2020). For instance, in OS 14, Apple established the framework App Tracking Transparency, playing out privacy features more prominently than in earlier versions of iOS. Due to these changes, app developers have to request user authorisation to access app-related data for tracking the user or the device (Apple, 2020). In the future, Apple intends to ban applications that track users without permission and thus violate the new requirements and respective guidelines (Leswing, 2021). In consequence, Apple’s decision to establish third-party transparency has a significant influence on how developers of peripheral applications can conceptualise and operationalise data protection and information privacy.

3.2 Blockchain-based ecosystems

A blockchain is a distributed, encrypted, chronological database of transactions recorded by a distributed network of computers (Morabito, 2017; Wright & De Filippi, 2015). It contains “every transaction that has been carried out and shared among those participating in the network” (Morabito, 2017, p. 4). The entries are “encrypted and organized” in “smaller datasets referred to as ‘blocks,’” each of which references “to the preceding block in the blockchain” (Wright & De Filippi, 2015, p. 7). A consensus mechanism warrants the integrity of each transaction over the network. Contrary to other approaches in computer security, in open, permissionless blockchains, the consensus mechanisms are not based on access control, i.e., on “carefully vetting participants and excluding bad actors” (Antonopoulos, 2014). Instead, they rely on economic incentive systems that aim at motivating actors—referred to as miners (Alsindi & Lotti, 2021)—to participate in the validation process and ensuring that it is “more profitable and attractive [for them] to contribute to the network than to attack it” (Brekke & Alsindi, 2021, p. 2). As a result of this approach, “the key characteristics of a blockchain […] are that it is: distributed, decentralized, public or transparent, time-stamped, persistent, and verifiable.” (DuPont & Maurer, 2015, p. 2). Moreover, the blockchain technology is not restricted to the record-keeping function it utilises in its origin in cryptocurrencies. More recently developed blockchain-based systems such as Ethereum incorporate Turing-complete virtual machines that allow executing not only simple transactions but also more complex operating steps. In turn, this enables running decentralised second-layer applications (DApps) as services on top of the system.

In line with discourses around earlier decentralised technical systems such as the internet (Bodó et al., 2021), developers, scholars, and the broader community discussed blockchain technology in value-related terms from the very beginning. In this discourse, a libertarian reading of the technology is dominant (De Filippi, 2017; Werbach, 2018; Wright & De Filippi, 2015). Furthermore, trustworthiness (Becker & Bodó, 2021; Hawlitschek et al., 2018; Jacobs, 2021; Werbach, 2018) and sustainability (Alsindi & Lotti, 2021; Giungato et al., 2017) are discussed prominently as values that should be accounted for in the technology’s technical design. Notably, design decisions regarding comparably subtle changes in a system’s protocol—such as a change in the number of transactions aggregated in one block—are debated by the community in terms of values embodied in the respective design decision (Werbach, 2018).

The technical properties of blockchain-based systems affect the applicability of VSD. In contrast to the platform-based ecosystems discussed in the previous section, there is no central entity controlling the system that can unilaterally determine the design of technical interfaces (Antonopoulos, 2017). Thus, consent between several (groups of) actors is necessary to implement protocol amendments successfully. These are, first and foremost, the developers themselves, but also a significant share of miners, cryptocurrency exchanges, and token holders.

The software protocols of open and permissionless blockchains are maintained as open source projects, i.e., the code is publicly available, everyone can propose or recommend code changes and amendments, and a “mix of volunteer and paid software developers write and update the software” (Walch, 2019, pp. 60–61). However, while there are no explicit boundaries to participating in the design process in many blockchain-based systems, there are still groups of core developers with additional rights that guide and oversee the design processes in most larger systems (Walch, 2019). Thus, as Werbach (2018, p. 104) notes, “developers have more power than they let on. […] And even in an open-source project, a single individual can exercise significant authority.”

However, core developers only propose updates. Ultimately, the actors running the network need to “adopt and run [these] implementation[s]” (Antonopoulos, 2017, p. 259). Since the developers do not operate the system, they only create a new version of the system’s protocol in a software repository, i.e., they create a “software fork”. The respective nodes, miners, and wallet-holders individually decide whether or not they use client software with the updated version of the protocol, i.e., create a “network fork” (Antonopoulos, 2017).

As many protocol upgrades lead to consensus rules that are not “forward compatible” (Antonopoulos, 2017; see also Swan, 2015), i.e., they are incompatible with the pre-upgrade version’s ones, miners continuing to proceed according to the old rules and miners proceeding according to the new rules from this point on participate in diverging ledgers. In such a hard fork, “two chains evolve independently” from one another (Antonopoulos, 2017, p. 257). If, in the long run, either all or no miners follow the core-developers advice to adhere to the new version of the protocol, one respective branch of the fork perishes. If a sufficiently large group of miners adheres to either version of the protocol, the network splits, with both ledgers persisting. These share the same history but are henceforth dissociated from one another (Antonopoulos, 2017; for a discussion of several cases see DuPont, 2019).

Furthermore, cryptocurrency exchanges, too, need to adopt the new rules for them to be successfully introduced (Antonopoulos, 2017). While exchanges do not directly engage in maintaining or running blockchain-based systems and exist merely at their fringes, they nevertheless impact the incentives that drive the more central actors. For instance, cryptocurrency exchanges need to decide which ledger they list, i.e., for which of the ledgers they offer exchanges to customers and thus provide easy access to the system as a whole. While a delisting on one exchange platform potentially only has negligible effects, a coordinated effort to delist a system by several major platforms can hinder access to the system and diminish the economic incentives to participate in it (Orcutt, 2019).

The actors involved in blockchain-based systems thus do not only potentially hold different values or have diverging preferences and incentives regarding the conceptualisation or operationalisation of values but wield sufficient power to unilaterally intervene in design decisions that concern the realisation of a specific value. Moreover, various recent examples showcase that this is not a mere theoretical possibility, but that diverging preferences regarding values in practice do entice these actors to make use of these means.

Regarding core developers, one of the most prominent instances took place in the aftermath of a hack—commonly referred to as “TheDAO hack”—in which an attacker was able to gain hold of assets worth around “$55 million at the time” (De Filippi & Wright, 2018, p. 141) and siphon them to a fund under its control. However, before the attacker was able to move the assets further or sell them on a cryptocurrency exchange (Botsman, 2017), the core developers of Ethereum pushed through a code update to ultimately void the illicit transactions and “recover the funds from the attackers” (De Filippi & Wright, 2018, p. 141). Because this update affected not just the general principles and functionality of the technology but also individual transactions, commentators commonly use the example of this update to illustrate the power of core developers in the system (De Filippi & Wright, 2018; Walch, 2019; Werbach, 2018). By voiding the transactions, the core developers made a value judgment in that they favoured the restoration of trust in the community over the ledger’s integrity, understood as the immutable nature of ledger entries. This is because the reversal of the transactions “meant that Ethereum transactions were not truly immune from centralized interference” (Werbach, 2018, p. 68). 5

Peculiarly, the case of “TheDAO” hack also serves as a curious case highlighting the role that significant miners take in the process of incorporating code amendments, as they independently decide whether or not to follow the core developers’ advice to update their client software. In the case of the TheDAO hack, the community split (DuPont, 2018, 2019). While most miners followed the core developers’ advice, a minority stuck to the old protocol and thereby created an incompatible version of the shared ledger called “Ethereum Classic” (Werbach, 2018). This example demonstrates that only by convincing large proportions of significant miners to adopt the updated implementation developers can turn a software fork into a network fork (Antonopoulos, 2017). Therefore, as a stakeholder group, miners cannot be overruled or circumvented in design decisions regarding protocol changes. 6

Lastly, the coordinated approach of various cryptocurrency exchanges to delist the Bitcoin-Cash spin-off Bitcoin SV highlights the capability of cryptocurrency exchanges to engage in the negotiation process on how a blockchain-based system should account for human values. Here, two groups of stakeholders proposed different code upgrades for the Bitcoin Cash protocol. One group, surrounding “the developers of the most popular Bitcoin Cash software client, called Bitcoin ABC, proposed a series of upgrades, including smart contract capability.” In contrast, another group, including a mining pool controlling “more than 15 percent of all Bitcoin Cash mining,” proposed a divergent upgrade without such fundamental changes to the system’s capabilities (Orcutt, 2018). The advocates of this alternative upgrade claimed that it adheres more closely to the original ideals of Bitcoin as outlined in early white papers.

Consequently, a hard fork occurred, establishing Bitcoin SV as a spin-off of Bitcoin Cash, followed by turmoil within the community and what Orcutt (2019) calls “social media-fueled coin delistings”. Major cryptocurrency exchanges like Kraken or Binance released statements criticising the team behind the newly established Bitcoin SV. KRAKENFX (2019) announced that the behaviour of “the team behind Bitcoin SV” in the aftermath of the fork was incongruent with the values held by “Kraken and the wider crypto community”. Binance (2019) questioned whether Bitcoin SV “continues to meet the high level of standard” they expect. Consequently, the two exchanges—among others—stopped exchanging Bitcoin SV on their platforms, which, in turn, lead to “a substantial drop in [Bitcoin SV’s] value” (Orcutt, 2019), restricted access to the system for its users, and diminished economic incentives to participate in the system for Bitcoin SV miners.

4. Findings

Sections ‎‎3.1 and ‎3.2 offer several insights into the challenge of accounting for power in VSD. These allow identifying four crucial factors that co-determine the effects of the distribution of power in socio-technical ecosystems on the applicability of VSD.

Level of decentralisation

Juxtaposing platform-based ecosystems and blockchain-based ecosystems suggests that considering the level of decentralisation of the ecosystem is of paramount importance for determining the kind of issues that might occur when accounting for power in the application of VSD. As Shilton and Greene (2019) demonstrate, actors like platform providers at the centre of more centralised ecosystems can assert their ideas of conceptions, weighings, and operationalisations of values to a large extent. Using boundary resources as value levers, they do not just enforce these conceptualisations, weighings, and operationalisations onto the core components of the ecosystem, which they directly control, but also onto the design of peripheral applications.

Conversely, in organisationally more decentralised ecosystems, there is, by definition, no central actor who can similarly assert itself. As shown in the case of open and permissionless blockchains, many actors have the power to impact decisions in the context of how human values are conceptualised, weighed, and operationalised in the design processes. The distribution of power in such ecosystems makes some form of deliberation and coordination inevitable to avoid gridlocks.

Core/periphery

Different issues arise in design decisions concerning an ecosystem’s core components and design decisions concerning peripheral applications. The design of the core components, for the most part, affects more stakeholder groups than the design of peripheral services. Accordingly, negotiation processes are often more complex and conflictual.

Conversely, on the side of peripheral applications, fewer actors are involved. Instead, VSD practitioners have to consider boundary resources that constrain their scope for design. They need to account for the ecosystem’s technical and non-technical infrastructure and the actors in charge of it. Section ‎‎3.1 underlines the resulting power imbalance in platform-based ecosystems. Platform providers determine the design of boundary resources largely independently and, as a result, determine the scope for design of developers of peripheral services.

Temporality

As demonstrated in the two cases, how actors can exercise power varies considerably. One key difference is temporality. Some means of exercising power function ex-ante, i.e., actors suppress potential design decisions from being implemented in the first place. Examples of ex-ante exercises of power are the design of technical interfaces that predetermine how data can be accessed and managed, how users and peripheral services can interact, and more generally, which criteria peripheral services have to meet in order to be compatible with an ecosystem’s technical infrastructure. By utilising technical interfaces, central actors can predetermine how human values like privacy can be conceptualised and operationalised in the entire ecosystem. Other modes of exercising power function ex-post, i.e., they interfere with a technical artefact’s deployment or usage after an undesired design decision is implemented. Examples of means to exercise power ex-post are, for instance, app-store approval processes that central actors can use to exclude specific applications or services from a platform, or the decision of significant miners in blockchain-based ecosystems to omit using a new version of a blockchain protocol after developers deployed it in a software repository.

Phase of VSD

The two cases demonstrate that accounting for power is relevant for making decisions in the conceptual, empirical, and technical phase of VSD. They reveal that the way power is situated in the “broader social, economic, cultural, and political networks, institutions, and structures” (Sattarov, 2019, p. 20) of an ecosystem affects how human values are conceptualised (as demonstrated in the analysis of iOS and Android developer forums by Shilton and Greene (2019)), weighed (as demonstrated by Ethereum’s core developers’ value-judgement leading to recovering the funds after TheDAO hack), operationalised (as demonstrated by Apple’s move to change the data interface design for apps to access the MAC addresses of devices), and how the overall process of accounting for values can be evaluated (as illustrated by “social media-fueled coin delistings”). Accounting for power thus concerns VSD practitioners in all phases of VSD.

5. Discussion

These observations allow deriving some points of reference for addressing the challenge of accounting for power. They suggest that the general applicability of VSD and its potential to address power-related issues varies tremendously depending on features of the ecosystem and the role that a given artefact is supposed to play in it. While the distribution of power within an ecosystem, in some cases, hinders the application of VSD, it appears to accommodate the approach in other cases. Though this is true for both more centralised and more decentralised systems, the decisive factors differ.

In more centralised ecosystems like platform-based ecosystems, boundary resources function as obligatory passage points (Law & Callon, 1992; see also Callon, 1984) for peripheral applications and constrain the application’s design process. These constraints cut back on the agency of developers and can either obstruct or compel design decisions that promote or demote the realisation of specific values. 7 Shilton and Greene (2019) outline discussions from iOS and Android developer forums that illustrate this lack of agency of developers of peripheral applications in platform-based ecosystems. Here, developers are often required to interpret and realise a concept of privacy that is predefined and manifests, e.g., in the platform’s boundary resource design. As Greene and Shilton (2017, p. 16) note, “platforms govern design by promoting particular ways of doing privacy, training devs on those practices, and (to varying degrees) rewarding or punishing them based on their performance”. Thus, while developers of peripheral applications can always decide to collect less data, privacy here, for the most part, is whatever the platform providers define as privacy. A meaningful application of VSD is virtually non-viable for developers of peripheral applications in such settings.

While Hestres (2013) and van Dijck et al. (2018) outline how concerted efforts of various stakeholder groups can principally have success in appealing to platform providers and lead to changes in boundary resource design, this commonly is not part of the design process of individual technical artefacts and thus outside the scope of VSD. Nevertheless, grassroots efforts proved effective in many cases and should be considered a tool to create the necessary environment for an application of VSD by VSD practitioners in more centralised socio-technical ecosystems. 8

However, if Apple’s boundary resource design is assessed regarding its direct impact on the realisation of values, it’s apparent that it gives users more autonomy by allowing them to configure the location data usage (Apple, 2019) and to protect their privacy by eradicating access to a device’s MAC address (Butts, 2017). Thus, this case shows that powerful actors such as platform providers can also encourage “ethical practice within their ecosystems” (Shilton & Greene, 2019, p. 144) by making use of a carefully considered boundary resource design. Regarding privacy, Shilton and Greene (2016, n.p.) describe this phenomenon as “a ‘trickledown privacy’ effect in which platform providers exercise strong power over privacy definitions”. As platform providers can shape the conceptualisation of values within the ecosystem more generally, similar effects can be realised with other values (Shilton & Greene, 2019). 9Therefore, if VSD is used in boundary resource design, it enables the value sensitive shaping of ecosystems.

While the means by which the platform providers exert power in the discussed examples are primarily technical on the surface, they also affect developers of peripheral applications economically. For instance, as Ausloos and Veale (2020, p. 138) note, platform providers can utilise a restrictive API design to “break an entire set of business models” that rely on specific data streams through the respective APIs (see also Bucher, 2013; Leerssen et al., 2019). Thus, platform providers can use technical means such as API design to exert economic pressure on other actors within the respective ecosystem by affecting the economic viability and potential profitability of business models behind peripheral applications. Such strategic exploitation of the API design as a tool “to exclude certain business or functionality from integration” (Ausloos & Veale, 2020, p. 138) can establish economic constraints on the scope for design of VSD practitioners at the periphery of ecosystems.

In more decentralised ecosystems, the challenge of accounting for power manifests differently. Here, the negotiation processes among the involved actors on how to account for human values can lead to gridlock. This is because various actors with divergent incentives and interests may disagree as to how human values are conceptualised, weighed, or operationalised. Applying VSD in such cases could ensure that various stakeholder groups are represented in decision-making processes and balance the interests of different stakeholder groups without calling into question the ecosystem's decentralised nature. However, in more decentralised ecosystems, VSD practitioners need to ensure that actors who are not directly involved in design decisions, but affected by them, are also taken into account.

These differences in ecosystems suggest that if there is freedom of choice, the selection of the ecosystem that VSD practitioners embed an artefact in has a significant effect on how human values can be accounted for in the artefact’s design. For instance, Atzori and Ulieru (2017) argue that research on platformisation, i.e., “the penetration of the infrastructures, economic processes, and governmental frameworks of platforms in different economic sectors and spheres of life” (Poell et al., 2019, pp. 5–6) is indicating that “the concept of distributive justice / distributive efficiency [is] strongly dependent on platform architectural design and they are unlikely to be achieved in centralized, two-sided markets” (Atzori & Ulieru, 2017, pp. 4–5). However, due to the quasi-monopolistic position of many platforms (Eaton et al., 2015), such a choice does not always exist for developers of peripheral applications if they want to attract a larger user group. Furthermore, that developers of peripheral applications need to consider not only a platform’s current features, but also the platform provider’s means (technical, economic, or other) to exert power in the future, further complicates the selection process.

Moreover, as the means of different actors to exercise power concern various phases of the design process and can come into play even after deployment, VSD practitioners have to consider the matter continuously: from early conceptualisations of values to the process of operationalising and implementing values to the deployment of artefacts and the evaluation of the design decisions related to values later on. More specifically, since both the development of core components of an ecosystem and peripheral applications often continue after deployment in the form of a constant redesign (Eaton et al., 2015), VSD similarly has to incorporate continuous monitoring of the respective ecosystem’s modifications, updates, developments and related effects on the distribution of power within the ecosystem. While the foundational texts of VSD in principal already set out the approach as extending over all of these phases (Friedman et al., 2008; Friedman & Hendry, 2019), in practice, most practitioners do not perform several iterations of the three phases over the entire length of the design process (Winkler & Spiekermann, 2018). Therefore, it is essential to stress the importance of a continuous application of VSD once more.

Furthermore, the findings of this paper suggest that the spectrum of tasks involved in VSD expands if applied in the design of artefacts embedded in vast and complex socio-technical ecosystems. Some tasks, such as monitoring the distribution of power in the ecosystem over extended periods of time or dealing with platform monopolies, appear to be too extensive to be addressed by individual VSD practitioners or even small development teams. Therefore, the range of tasks needs to be distributed over more actors if they are to remain manageable. Regulatory authorities, in particular, must play a role in addressing some of these challenges. In particular, challenges arising due to 1) (quasi-) monopolistic players, 2) the complexity of continuously monitoring the manifold actor constellations and distribution of power within an ecosystem, and 3) boundary resource design that prevents developers of peripheral applications from accounting for values surpass the capabilities of VSD practitioners and the scope of VSD in a traditional sense.

Dealing with (quasi-) monopolistic actors, especially platform providers, is in the domain of antitrust and competition authorities (Crémer et al., 2019; Kommission Wettbewerbsrecht 4.0, 2019; Monopolkommission, 2015), which therefore play a crucial role in ensuring the applicability of VSD. Furthermore, the European Commission’s recent proposal for the Digital Markets Act (European Commission, 2020c) contains several propositions for concrete regulatory measures aiming to curb the quasi-monopolistic standing of many platform providers. Relevant here are, for instance, the proposed requirements for gatekeepers to “allow business partners,” such as the providers of peripheral applications in a platform-based ecosystem, “to offer the same products or services to end users through third party online intermediation services at prices or conditions that are different from those offered through the online intermediation services of the gatekeeper” 10 (European Commission, 2020c, art. 5 (b)) or to “provide effective portability of data generated through the activity of a business user or end user […]” (European Commission, 2020c, art. 6 (h)). Thereby, regulation built on the European Commission’s proposal for a Digital Markets Act could help to counteract “winner-takes-all dynamics” (Anderson & Mariniello, 2021) that favour the development of (quasi-)monopolies. In turn, such a development would provide more choices to select a suitable platform (or suitable platforms) for developers of peripheral applications and make it a more viable option to integrate this selection process in the application of VSD.

Additionally, establishing oversight institutions like the recently launched AI Observatory of the German Federal Ministry of Labour and Social Affairs (Bundesregierung, 2020) or a competence centre for algorithmic systems, as proposed by the German Data Ethics Commission (Datenethikkommission, 2019), could play a crucial role in the monitoring of platform-based ecosystems. The proposal for the Digital Markets Act outlines further supportive measures. Especially the requirement for gatekeepers “to refrain from preventing or restricting business users from raising issues with any relevant public authority relating to any practice of gatekeepers” (European Commission, 2020c, art. 5 (d)) is crucial here, as it would allow for a closer collaboration of regulatory authorities and developers of peripheral applications. If cooperating closely, oversight institutions and developers of peripheral applications could identify the most problematic practices of platform providers jointly in a bottom-up approach and lay the groundwork for possible future regulation and governance that addresses the most urgent issues for VSD practitioners.

Furthermore, in future regulatory frameworks, regulatory authorities should consider an ecosystem’s boundary resource composition when determining. As outlined above, iOS is a closed platform. Apple controls and governs the unique distribution channel and, thus, establishes itself as an obligatory passage point. Developers of peripheral applications need to follow Apple’s guidelines closely since there is no alternative distribution channel for applications on iOS devices. This is a conscious decision by Apple which brings the company a wide range of business benefits. Yet, from a regulatory perspective, this decision could also be linked to stricter obligations for Apple since it constrains the scope for design of developers of peripheral applications and predetermines to what degree they can account for human values in design decisions. If platform providers use their power to exert influence over design decisions and limit access to alternative distribution channels for developers of peripheral applications, it seems reasonable to link these activities to a stricter regime of obligations. Suppose platform providers engage in exercising control over how developers of peripheral applications account for human values in the technical design of their applications and shape the ecosystem more proactively. In that case, this value sensitive shaping of the ecosystem should be subject to increased scrutiny by regulators. Conversely, if platforms refrain from exercising control over how developers of peripheral applications account for human values in the technical design of their applications, the focus of regulators should shift more to the actors at the ecosystem’s periphery.

6. Conclusion

Technical design in accordance with human values is increasingly considered a building block for shaping the digital future. VSD is a long-standing and well-established approach for achieving design in accordance with human values. This paper shows that the integration of technical artefacts in increasingly vast and complex socio-technical ecosystems with power distributed over various actors affects the applicability of VSD in multiple ways. Several factors determine how this challenge manifests in practice. This paper identifies 1) the level of decentralisation of the ecosystem in question, 2) whether VSD is applied regarding the design of components of an ecosystem’s core or periphery, 3) the temporality of the exercise of power, and 4) the phase of VSD in which power is exercised in as four of these factors.

Adopting a power-sensitive ecosystem perspective provides some reference points for addressing the challenge of accounting for power. While in some constellations, the application of VSD appears to be less applicable since the scope for design of developers is restricted, other constellations appear to accommodate the approach. On the one hand, these are cases where a multitude of assertive actors engage in decision-making processes regarding specific design choices that result in conflicts or even gridlock. Here, VSD can provide a structured approach that supports resolving these conflicts and balances the interests of different stakeholder groups. VSD also appears to be of particular importance for the design of an ecosystem’s core components, such as boundary resources. Here, individual design decisions can shape entire ecosystems in accordance with human values (see Shilton, 2012). For this reason, highly centralised ecosystems are also potentially more attractive to regulatory authorities because important nodes and actors in such ecosystems are more easily identifiable and addressable.

Dealing with (quasi-)monopolistic players, accounting for the complexity of continuously monitoring the complex actor constellations and distribution of power within an ecosystem, and addressing boundary resource design preventing developers of peripheral applications from accounting for values emerge as significant novel challenges when applying VSD in vast and complex socio-technical ecosystems. However, recent proposals for establishing new oversight institutions (Bundesregierung, 2020; Datenethikkommission, 2019) and new regulatory approaches such as the Digital Markets Act and the Digital Services Act (European Commission, 2020c, 2020b) indicate that regulatory authorities can support VSD practitioners in overcoming these challenges. Furthermore, in the future, close cooperation between oversight institutions and VSD practitioners can reveal problematic practices of powerful actors in socio-technical ecosystems and thereby lay the foundation for further regulatory action.

Lastly, a lesson that can be drawn for further research in the field of VSD is that developing a unified framework for dealing with power imbalances between stakeholders in socio-technical ecosystems does not seem to be an attainable goal because the way that power manifests in different ecosystems varies substantively. Thus, instead of aiming for a unified framework, practitioners need to make calls on adequate procedures on a case-by-case basis. Future research, therefore, should aim at advancing the understanding of the actor constellations in socio-technical ecosystems and the distribution of power within them. In particular, in-depth comparative analyses of various socio-technical ecosystems, the distribution of power among the actors involved in them, and the human values expressed in the design of their boundary resource design could provide valuable and more readily applicable insights for VSD practitioners.