upa - home page JUS - Journal of usability studies
An international peer-reviewed journal

Curating Evolution

Austin Henderson and Jed Harris

Journal of Usability Studies, Volume 7, Issue 2, February 2012, pp. 51 - 55

Article Contents


Introduction

Consider the meanings of words. Since language was invented hundreds of millennia ago, the meanings of words have continuously evolved. Importantly, this collective evolution has been achieved, not through premeditated coordination, but rather through exploration and convergence in use. It is a buzzing, booming cauldron of meanings, yielding effective, drifting, locally-coherent yet globally disparate support for human linguistic engagement.

Then, in the sixteenth century, printing made reading and writing far more common. As a result, there was great concern among the well-educated that language would devolve in the hands of masses. The keepers of language invented the dictionary to maintain coherence in word meaning. The Johnsons and Websters positioned themselves as the arbiters, indeed the designers, of the meanings of words. However, the actual meaning of words continued to evolve in everyday use largely as they had before widespread literacy and dictionaries.

Later, in the nineteenth century, some dictionary writers recognized this inherent tension between meaning based in definition and meaning based in use. In what may be thought of as a user-centered move, word meanings in the Oxford English Dictionary (OED) were explicitly grounded in actual usage. Readers were invited to submit quotations of words from written works; that is, words as they were actually being used. The OED compilers organized these quotations to reflect the evolving meanings of words. The language rolled on, with the dictionary tracking its evolution, contributing to the self-awareness and coherence of language users without presuming to exercise control.

Now, in the twenty-first century, we have the ability to harvest an instant history of how a word has been used from Google Books. We also have the crowd sourced Wiktionary, a “collaborative project to produce a free-content multilingual dictionary. ... You can edit it.” The users of language—the speakers, readers, and writers—are also its legitimate and authoritative documenters, the dictionary creators.

What has happened to the language arbiters, the keepers of the flame of language? They continue to play two important roles. They curate the process, writing, editing, and critiquing the use of language. And they provide the infrastructure for widespread use and participation in online language resources.

Thus, over time, we’ve come full-circle in determining the meanings of words. Since prehistory, the evolution of the meanings of words was the province of every speaker. Relatively recently, it became the province of a specialized few, then the contributions of many organized by the few, and now again the province of us all. Further, because contributing to a dictionary these days requires skills and access that are widely available, there are a growing number of participants. We can all play, and have our own dictionaries if we want them.

Our point? We want to argue that all areas of design are likely to follow a similar path and reach the same end. These changes are already underway in most areas, particularly those that are based on computation. And we want to argue that there is a very important role in these ever-more-user-produced systems for those with a gift for order, good design, and usability.

Evolvable Systems—The Only Kind

Historically, like language, all areas of human practice were directly shaped by the needs of practitioners. Accounting, message addressing and delivery, the management of employees, and so forth were managed through a locally idiosyncratic but mostly conventional set of practices that evolved as they were used and adapted to circumstances.

As aspects of these processes were increasingly supported by computers, this changed. The computer tools of the later twentieth century were very rigid (except under the hands of the few who could write code). Applications for accounting, mail, human resources, and so forth, had to be spec’d, designed, built, and deployed by specialized groups. These applications could only handle very limited complexity and nuance and were difficult to modify once created. However, the practices that these rigid tools supported were no different from language: their usage was embedded in life, and life went on—changing and demanding response. Despite whether dictionaries evolve, language use evolves. Despite whether computer-based products evolve, the life and practices they support evolve. In the face of new needs and applications that are misaligned with those needs, users muddle through by inventing work-arounds. Even if the technical systems can’t, or won’t, change, the socio-technical systems (technical systems in use by people) evolve and diversify.

In response to this continuing pressure, tool-builders are beginning to make the same moves that the dictionary-builders made. They are opening tool-creation to the participation of users, either by incorporating suggestions on design or by making tools malleable in the hands of everyone. Releasing control even more, tool-creation practices are being moved from protected private centers into the public domain. Even the goal is changing: products are designed to branch into a host of variants, based on plug-ins and add-ons, generating a braided stream of interdependent pieces in endless configurations. There was only one Multics; there are many Linux’s. And every service is different in each installation.

Many years ago, one of us (Henderson) evolved a design tool (Trillium) for UI designers at Xerox. Designs were created by “wiring together” interactional widgets (we called them items, and each item had an itemtype). Initially, we thought that we could find a collection of itemtypes that would work for everyone (at least those making copier interfaces), and then we would use them as the Xerox design language. A central learning was that one language does not fit all. Each product line—indeed each product—tended to have variants on the itemtypes. Our response was to let go of the itemtype definitions, open them up to everyone, particularly the designers. We evolved Trillium to support users in creating itemtypes. Trillium’s user support for this was far from perfect and provided only fairly simple constructions, but it worked well enough. The resulting languages of design used by different groups could then evolve, and branch, and (through sharing) merge.

The Trillium creators, almost from the beginning, delegated creation of the design language to the community of practice of Xerox UI designers and supported them through language design tools. Furthermore, we organized and managed the essential context of user design: a community-wide conversation about the use of Trillium, the design of UIs, and the design of design languages. That context must enable participants to become aware of the conversation; find out who else is “there,” determine what the discussion is about, why it is being held and to what end; determine how the discussion is being shared, both with those there and those not; enter, be present, and withdraw in socially-appropriate ways; present themselves and negotiate their self-presentation; develop standing and relations (e.g., trust, friendship) with others; and all the other nuanced interplay of multi-perspective, inter-personal interaction. We shaped and maintained this context through the practices of using mailing lists and file systems, coordinating community-wide gatherings, and introducing and nurturing video-based distance collaboration.

Trillium was an early example of this pattern of community-wide evolution of local configurations, but since the broad adoption of the internet there are many more. Version Management Systems have rapidly evolved to support diverse local configurations while still enabling consistency and sharing. Wikipedia has evolved a rich set of practices to generate an excellent encyclopedia from the “drive by” contributions of a huge community. A wide range of peer production projects have benefited from substantial user participation while improving both their design quality and their scope.

Drive the Bus or Get Run Over

We have a long way to go on all these fronts, but the direction is clear. Our working – and playing – environments are evolving, multi-perspective, negotiated. To stay relevant, our system designs have to become more evolutionary, multi-perspective, negotiated. Every deployment will be different.

This is not new. Traditionally, we have made our rigid tools as broad and flexible as possible, and hoped that would do. We have recognized that we cannot keep up with all the needs of all our users all the time. We have implicitly relied on users to adapt the tools to their circumstances. And they have.

However, now it is time to recognize that we need to support those users in all that adopting and specializing and aligning and working-around. We cannot anticipate it, so we must help them do it themselves.

This affects the design of the tools, but more importantly it affects how we support the use of those tools. If work-arounds are part of users’ practice, we must support work-arounds. If modifying the tools is part of their practice, we must support modification. In short, the environment of use must be seen as encompassing all the work of evolution. Instead of thinking of our design work as ending when use begins, we must support evolution of our designs in the midst of use.

Getting this right will be a huge competitive advantage. It recognizes the realities of disparate, negotiated practice. Rather than denying them, it takes advantage of them. Most powerfully, it extends the work of designing to all the users. What a design workforce! Real experts! And it can lower the bar for some designs out of the gate: just start them so that they are good enough for a big enough community, and then join with that community in building both the products and the community. Tomorrow is built on today. Perpetual bootstrap.

Curating Evolution

Inevitably, users, driven by their own local needs, will tend to evolve their tools in ways that conflict with the needs of others. Indeed, they may not even know of those others or their needs. The tools are likely to evolve in diverse, even incompatible directions. As a group, users may ride off at high speed in all directions.

The role of design is to accelerate evolution. When evolution is in all directions, the role of design is to accelerate the practices of coordinating those directions, bringing coherence where necessary.

However, here again we must resist the temptation to take matters into our own hands. If coherence is needed, then it is needed by the users, so help them to create it. They will be better than we at determining where coherence is necessary. Let them negotiate it out, suiting the solutions to the circumstances at hand.

Let achieving coherence be part of the work. As the work evolves, ways of achieving coherence will also evolve. Because design accelerates evolution, we—as designers anticipating this buzzing-booming cauldron of evolution—should be supporting the designing, by everyone, of tools to achieve coherence.

Making It Happen

All very well, but in practice what will this take? A few thoughts:

Conclusion

Curating evolution is not an easy job. There are strong forces arrayed against it. All those who feel more secure with consistency (engineers, programmers, designers, managers) are likely to be appalled by the prospect of a loosely-coupled evolving design process.

Yet change will out. We argue that curating evolution is much better than trying to deny it or stamp it out. And in the end, a lot more fun.

 

Previous