Keywords

1 Introduction

We begin by briefly surveying several established design methods, exploring their strengths, weaknesses, and relations to inclusive design. In particular, we examine the degree to which these methods can support diverse participation by users during the design process and beyond. Next, we describe the community-grown design methods employed by Fluid, which blend established techniques with new inclusive methods. The challenges and opportunities of designing within an open source community are discussed; we provide an overview of common open source governance and decision-making processes, examining some of the social and technological mismatches between today’s developer-oriented open source practices and our goal of an inclusive, participatory community. We end by discussing how inclusive design and collaboration can be supported by technologies such as Fluid’s Infusion framework, which provides the foundation for what we call “user-continued design,” where software artifacts can be changed and redesigned even after the initial design process has been completed.

2 Design Methods

2.1 Interaction Design

Industry-driven interaction design methods such as those described by Cooper [4], Beyer et al. [2], and IDEO [11] primarily look inward; they are created by professionals and intended for an audience of like-minded designers and managers. These methods aim to provide prescriptive, generalized, and reproducible techniques for managing teams who design commercial software products or offer design consulting services. The predominant emphasis is on “modelling” users, their goals, and their work or organizational processes.

Despite an increased focus on user-centered design, which often invites users into the fold of research in a more active way (as with the human-centric design methods of [11]), such industrial modelling methods maintain the user in a passive role as “consumer” or “customer,” often advocating for a rigid design focus on typical or mainstream requirements while explicitly de-prioritizing the “edge cases” of outlying, marginal needs [4].

While this approach may simplify product requirements and focus designers on the most popular features, it also risks excluding the crucial features and customizations that enable people with disabilities to use a software product and which ultimately contribute to greater innovation and to the overall usability of a system [21].

Moreover, interaction design advocates often argue that their subjects (i.e. the individuals who use their software on a daily basis) are unable to be articulate or self-aware about their own technology needs, and that only the software industry can provide design innovation, not users themselves [20]. User input gathered through human-centered design methods tends to be seen only as a means for users to inspire the creative process of “real” designers. The result is that there are few opportunities for individuals to actively contribute to the design process and work alongside professional designers, except as consumers or research subjects.

2.2 Universal Design

Universal design, with an explicit focus on meeting the needs of all individuals, including those with disabilities, substantially expands a designer’s creative remit and responsibilities. However, the challenge of universal design is in its emphasis on a single product or design that aims to fit the needs of all users without adaptation or personalization. Ron Mace describes universal design as “the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design” [our italics] [15]. As the complexity and diversity of today’s software grows, it is no longer practical for designers to plan for every user and every feature within a single piece of software, nor to be able to fully understand and obtain expertise in the infinite variety of creative, serendipitous, and unexpected uses that software can be subjected to. Instead, the design process needs to be supported by technologies that provide users with a means to materially change, personalize, specialize, and extend their software environments.

2.3 Participatory Design

Participatory design, in contrast to many interaction design methods, offers the potential for users to more actively engage in the design process. This often takes the form of workshops and scenario-building exercises where users are invited to explore design strategies alongside professional designers [23]. While participatory techniques play a foundational role in the Fluid Project’s inclusive design methods, particularly the concept of experienced designers working in harmony with users and other non-designers, we argue that workshops and other “before-the-fact” design methods alone are insufficient for three primary reasons:

  1. 1.

    Participatory design methods do not explicitly provide a means for ongoing community “stewardship” or “curation” of the software product after the initial participatory methods have been completed

  2. 2.

    Additional technological tools are needed in order support ongoing or user-continued design, including the ability for individuals to customize, adapt, and modify a “finished” software product

  3. 3.

    Most user-centered or participatory methods do not fully support the participation of “extreme users” — those at the margins or who have particular needs that cannot be easily accommodated by traditional user research or workshops [18].

3 Fluid’s Inclusive Design Tools

Taking up the co-design position that “all people have something to offer to the design process and that they can be both articulate and creative when given appropriate tools with which to express themselves” [19], the Fluid Project has been developing design and technological tools to support user creativity. We aim to extend the design process into the designed artifact itself — to give users the ability to continue the design process themselves, after the specialized design effort has been finished and the product has shipped. This approach to “adaptation as design” extends from creating tools that allow users to configure their own interfaces, to technologies that support remixing, repurposing, and sharing.

Designing inclusively, we have learned, requires more than just design processes, but also new technologies. This is the motivation for tools such as Fluid Infusion [13], a software development framework that enables applications to be reconfigured in context- and preference-sensitive ways, and the GPII Nexus [10], which can integrate diverse software components together in a way that will eventually be supported by graphical authoring and programming tools accessible to non-developers.

3.1 Catalogue of Design Tools

Fluid’s software and design tools are rooted in open community practices that emphasize the role of users, especially users with disabilities, as co-designers, “gardeners”, and ongoing maintainers of the project’s outcomes. Fluid’s approach emphasizes the importance of non-prescriptive design methods and self-organizing collaborative teams who freely draw from a toolbox of design approaches (such as those documented in Fluid’s Design Handbook [14] and the Inclusive Learning Design Handbook [12]) based on the design context and the needs of participants and project stakeholders. We outline some of Fluid’s community-driven design methods below.

UX Walkthroughs are a hybrid technique based on heuristic evaluation and cognitive walkthroughs. They emphasize paired or collaborative evaluation of user interfaces by designers and non-designers alike, and serve to bring a diversity of perspectives to bear on the design process.

The UX Walkthrough technique is a procedure for critically examining a user interface by following one or more predetermined scenarios and making assessments based on common user experience heuristics such as those by Jakob Neilsen [17]. It is an amalgam of several proven conventional inspection procedures, supporting reviewers in making assessments both from the user’s point of view and that of a design expert. Pairing actual users up with designers to define scenarios and participate in walkthroughs can further enrich the results.

The multifaceted nature of the UX Walkthrough enables reviewers to make assessments across several dimensions, including: general design quality, task-oriented usability, assistive technology usability, accessibility standards compliance, and code quality. A UX Walkthrough can be performed by novices as well as experienced evaluators. The result is a comprehensive and multidimensional report of usability and accessibility issues in a website or application.

Personas and Use Cases provide models of potential stakeholders who may use a product or service and the scenarios they may encounter when using it. Personas often play an ambivalent role in an inclusive design process; as tools, they offer teams a useful way to identify with and design for certain users, yet they also simultaneously risk stereotyping or reducing users to static, product-oriented identities.

Although personas represent fictional people, their characteristics, needs, goals and motivations are rooted in the insights and feedback collected from various sources including formal or informal research techniques (such as interviews and surveys), or through familiarity with the needs and interests of self, co-workers, friends or family members. They begin as early, provisional sketches and often evolve iteratively as more information is gathered. Personas are behavioural models; they do not represent the full demographics of any given population of complex and unique people. They enable designers, developers and evaluators across a project to keep a broad and diverse collection of stakeholders in mind. Considering non-obvious or unconventional users helps a design team to think broadly and stay open to unexpected uses of the systems they are creating. Personas are most useful for inclusive design when they are understood as full and idiosyncratic individuals, rather than as representatives of a broader category of disability, age group, or market demographic [18].

Use cases describe particular scenarios in which a persona may encounter and use a product or service, providing more detail about specific tasks and goals as well as helping to map out the potential steps in a workflow. User personas and accompanying use cases are not meant to exhaustively describe all potential stakeholders or situations; rather they help to illustrate key goals and behaviour patterns related to the design in question.

When paired with the other tools, particularly User States and Contexts and UX Walkthroughs, personas and use cases can help to paint a clearer picture of a broad and diverse range of user needs and preferences. They must be used with caution, since by their nature they create a distinction between user and designer, and they must be tempered with the awareness that no single persona or group of personas can independently determine the full range of potential uses of a product or service. Most importantly, like the real world, they need to be understood as always in flux; user needs and goals change significantly in different contexts and at different times.

User States and Contexts serve to “de-centre” and “multiply” personas, reducing the risk of stereotyping with personas by emphasizing the dynamic nature of a user and their needs across different contexts of use. This tool offers a way to represent and “query” or visualize different user needs and perspectives individually or in aggregate.

Fig. 1.
figure 1

A user states and contexts diagram.

Full size image

These diagrams can be considered a use-modelling tool for evaluating the ability of a design to be perceived and operated by users in a wide range of states and contexts. A user states and context map can be used to demonstrate the range of needs of users that are represented by a particular persona, or those of a collection of personas. The map can also be used to consider and demonstrate how a user’s state and context can change in the short term (e.g. on a daily basis) or the long term (e.g. over a lifetime). Each “constellation” in a User States and Contexts diagram shows the needs of a particular user in a specific context, environment, or situation. These diagrams can be layered on top of each other to plot how needs change across different contexts. Similarly, diagrams of different users can be clustered in order to analyze relationships amongst users. This helps to reveal patterns and commonalities that might not otherwise be obvious when using personas alone, as well as serving to highlight unique needs, interesting outliers, and edge cases that may suggest new design opportunities and features (Fig. 1).

Community Design Crits bring together designers, developers, and users to discuss and critique design artifacts, including ideas, scenarios, mockups, and in-development software.

Design crits provide a space, both locally and remotely via the use of video conferencing tools, for informal feedback and input to be gathered on a regular basis from a group of people with differing perspectives and differing stakes in the design. Gathering feedback in this way allows everyone a chance to participate in the design process from the start and in so doing reduces the typical design/develop/test cycle time.

Open, Transparent Sharing of design artifacts and discussion on mailing lists and other community forums based on “lazy consensus” governance principles [3]. Lazy consensus is a form of community-based decision-making that allows participants to make design and technical decisions freely based on their own personal judgement, trusting that, by virtue of the fact they are working openly and visibly, others will be able to speak up, contribute, or ask questions if issues arise.

When working transparently, diverse participation in the design process is more likely, because those who wish to get involved and who have access to the content and tools can contribute. Accessible and open communication tools can provide both a means of alerting the community to a group discussion or other activity, as well as a means of distributing collaborative artifacts including meeting minutes, design mockups, and other relevant information.

3.2 Using and Exploring Design Tools

These design and development techniques have been used with some success on a number of software design projects, and have been expanded for use in other communities and open source projects such as the Global Public Inclusive Infrastructure [22]. However, there are significant challenges to designing within the context of open communities, many of which we are still exploring. In particular, meritocratic governance runs the risk of being exclusive and dominated by contributors in privileged positions (socially, culturally, technologically, and economically) if a system is not in place to ensure that diverse contributions, especially those by non-coders, are recognized and promoted [7]. Access to open source collaborative forums, which are often synchronous, require high bandwidth, or privilege text-based communication over verbal or visual means, can limit diverse contributions. We continue to experiment with, evaluate, and test new social and technical methods for supporting ongoing engagement by individuals with disabilities, non-technical contributors, and those who might otherwise be excluded from conventional open source culture.

4 Technological Tools for Design

Technological tools to support such open and interactive design processes are, in our experience, relatively scarce. This is not only a result of the rarity of the processes they would support, but also because the underpinning for them is missing at the technological level. In this section, we survey the parallel story of technologies designed to support software developers in order to highlight what is missing for inclusive design, and to imagine the types of support which could be created for a community-oriented design process.

4.1 Distributed Version Control for Software Developers

Distributed version control systems gradually took over from traditional centralized version control systems during the 2000s. Distributed versioning offers a more democratic, “peer to peer” model for managing community assets, rather than the previous authority-based model whereby the definitive version of a community asset was stored in a nominated central repository. The most widely-used system of this kind currently is git [8], designed by Linux architect Linus Torvalds in response to problems he faced managing a very large source code base of millions of lines of code shared amongst thousands of contributors. Especially as hosted by the hugely popular infrastructure site GitHub [9], git offers important new affordances for software developers, beyond those directly implied by adopting an open source contribution model.

Amongst the most interesting for our purposes is GitHub’s review model. This allows a suggested contribution to a project to enter a rich interactive lifecycle centred around a git artifact known as a pull request — a request by the contributor that their work be accepted (pulled) into the community’s shared project. GitHub’s pull request review interface provides the following facilities to contributors:

  1. 1.

    Difference focused: the interface highlights the differences between the project’s state before and after the contribution is accepted. It is possible to navigate to complete views of project artifacts before and after the contribution.

  2. 2.

    A Content-focused discussion: comments can be attached to particular parts of the contribution. These can start off a dialogue between the contributor and other project members which remains attached to the particular content it is relevant to.

  3. 3.

    An archived record: even after the contribution is accepted into the project (or perhaps rejected) the pull request interface remains permanently available in the archive, making it easy to revisit and understand previous discussions.

It is worth noting that this pull request workflow is particularly a facility of GitHub rather than simply git itself, although it is enabled by the core technology of git. Unlike git itself, GitHub is not an open source project and its free-tier facilities are provided to the open source community as part of a wider commercial offering. However, alternatives to Git and free alternatives to GitHub exist, such as Gitorius on git, or the darcs hub [5] on darcs (although this currently has no pull request UI).

4.2 Nothing for Designers

Nothing similar to GitHub’s pull request user interface and workflow currently exists to facilitate contributions to open source culture from non-developers. Because of this, open design teams are often left to devise ad hoc processes, such as exchanging designs as “rendered” image files (e.g. bitmaps and PDFs) using Dropbox [6] or other cloud file sharing systems, attachments to wiki pages, email, and so on. As a result, comments and discussion are separated from the design artifacts and occur in parallel channels such as emails, IRC chats and Skype messages. There is no easy way to interleave comments, suggestions, and critiques with a design “source” file, and it can be difficult to publicly archive and preserve such discussions for future reference. This complicates lazy consensus and collaborative governance for design, and makes it difficult to establish stable, shared archives of design knowledge within a community to help bring newcomers on board.

Additionally, none of the design tools most commonly in use today have accessibility features to facilitate contributions from individuals with disabilities, such as the ability to attach descriptive text narratives to wireframes and mockup images. This huge discrepancy between the quality of tools provided to technical as opposed to design contributors further erodes the ideology of a “meritocracy” in open source communities.

4.3 Fluid’s Dream of an Inclusive Tool Chain

We dream that the same community affordances can be extended to all kinds of contributors. The technical, economic, and social barriers to this are, however, significant. Providing, for example, an accessible equivalent to Adobe’s Illustrator or similar visual design tools is a prohibitive task. Even where open source alternatives to popular commercial visual design tools exist, they are unlikely to provide useful accessibility and collaborative features that can be integrated with robust, decentralized version management in a manner suitable for non-technical users. Such tools will likely never be developed without a fundamental change to both the economics and practices of software design and development. Indeed, such a collaborative, accessible design tool could likely never stand alone as a single product; it could only be viable within the context of a broad collection of mutually-supportive technologies that take the needs of inclusion and collaboration into account at each infrastructural level.

5 Building an Inclusive Tool Chain

The primary aim of Fluid’s Infusion framework is to provide the foundation for such an inclusive tool chain, including supporting “user-continued” design. The needs of inclusion and collaboration both induce similar kinds of requirements on software and content creation processes.

5.1 Working with Design Landmarks

At the technical level, one of the strategies we have found to be effective in Infusion for supporting both adaptability and collaboration is to provide landmarks in a design — named architectural points that can be used to focus discussion as well as used to target further design or customization after the fact by users. We take our inspiration from the kinds of landmarks visible in HTML documents, which can be successfully referenced by means of a vocabulary of CSS selectors [16]. Landmarks can, for example, take the form of tag names, CSS class names, or other attributes of a document node. By referencing these landmarks using CSS selectors, designers can meet both the needs of styling (using CSS rules) and further authoring (by using document-oriented manipulation tools such as the jQuery library). Landmarks are also valuable for supporting collaborative design tools, since they provide a means to attach comments and document-directed discussion to the design. Such CSS rules have been an early success for inclusive design, allowing designers and developers to share access to a design space in a harmonious way.

Infusion aims to bring the affordance of these selectors and rules not just to markup and styling, but to the rest of the software development process. This is accomplished by organizing Infusion applications into cellular units named components that can be referenced by means of a CSS-like system of IoCSS rules, allowing components to be easily altered, replaced, or removed at any time. This casts the world of software development more in terms of document authoring than source code editing, with its final artifacts taking the form of structured trees with landmarks rather than binary opaque blobs [1]. The key difference between such document-based software and traditional code is that it is intended to be modifiable at any point in the software’s creation and use lifecycle. By providing an infrastructure which is suitable for authoring such trees, and for casting designs both visual and architectural in terms of them, we aim to support the creation of inclusive, collaborative workflows for designers of all kinds, including users.

5.2 Requirements Beyond Frameworks

Despite our technical efforts, we recognize that collaborative, open, and participatory design communities cannot be supported solely by means of a development framework. Other requirements need to be met through:

  • Building up hosting infrastructure for applications and data, and the tools and infrastructure needed to manage it

  • Building up community structures and workflows for welcoming, supporting and reviewing contributions

  • Building up and curating shared understanding of productive ways of casting and solving design and implementation problems, organized, for example, in “handbooks” of design guidelines, “bestiaries” of real-world problems and their solutions or other approaches like those listed in Sect. 3.1.

6 Conclusion

The design processes and technologies we describe here aim to support new forms of participation in open source software and to ultimately provide users with the ability to materially redesign and adapt software themselves. These goals are, needless to say, highly complex, ambitious, and challenging. We believe that such processes and tools need to be prototyped, evaluated, and refined within the context of open, collaborative communities that recognize the many and diverse contributions necessary to make highly usable software. Our approach continues to evolve and grow based on real-world experience designing and implementing software for a variety of projects, and we invite others to join our community and help creatively explore these issues with us.

The authors would like to thank James Yoon and Sepideh Shahi for their contributions to the design methods described in this paper.