Paper summary - Design Systems for Conversational UX, by Robert Moore, et al

What I read

In this article, the authors describe the importance of a design pattern system for voice interactions, and then describe the way a pattern system has been established at IBM.

First, the authors describe the increasing presence of design systems, in order to support UX design at scale. They described the contents of a design system, that includes things related to layout, task flows, and more; they cite Elizabeth Churchill’s interactions article as the source for a description of system content. They recognize that design systems have emerged for graphical interfaces, but there has been little development of systems in the context of voice interfaces (or “Conversational UX.”) They briefly describe the value of design systems, again extensively quoting Churchill, and summarize that “design systems enable developers to scale a particular style or system of UX.”

Next, the authors indicate the components of a successful design systems. These include a design philosophy, interaction patterns, and a content format. The philosophy is the vision, made up of interaction metaphors and principles. The patterns are the “core” – they are how the agent should provide generalized solutions. And the content format “enables the content to be added to the dialog tree in an easy and even an automated way.”

The authors then describe their core contribution, the Alma Design System. They describe the same core components—the philosophy, patterns, and content format.

The philosophy of their system is that natural language is the main metaphor in use, and the goal is mutual understanding between both the user and the agent. They have named several key principles that support this, including recipient design, minimization, and repair.

The patterns of the system are provided in classes. Conversational activities represent the basic back and forth between agent and user. Five modules are “like building blocks” and can be combined. They indicate that a “design system should provide the building blocks out of which any kind of conversational activity can be built.” Sequence management handles common scenarios of ambiguity, such as when a user doesn’t understand the response provided. This provides a sense of branching, based on prompt/response. Conversational management describes the starting and stopping rules of the system.

The content format of the Alma system is based on minimization and repair. While users may speak at length, the system should response quickly, through paraphrasing in short but understandable responses. Repair is how the agent handles “misses”, such as when the user asks the system to give an example due to ambiguity, or to repeat itself.

The authors then discuss the broader implications of their work. Again citing Churchill, they indicate that the Alma system “reduces effort, scaffolds learning, and increases cross-disciplinary and cross-functional collaboration.” This is done through templates, where designers don’t have to “create activity structure or conversation management mechanics.” The materials offer a way for designers and engineers to move pieces and components around (dismantle, re-create, rearrange, extend.) And, it solidifies research from conversational sciences into its base, so that core assumptions become axiomatic.

They conclude that this type of conversational system is new, and that they have provided three requirements for such a system—an overarching philosophy, a set of interaction patterns, and a content format.

What I learned and what I think

I’m not particularly interested in conversational system design, but I appreciate the author’s contribution: that there has not been as rigorous consideration given to the way these systems are built and extended, and that the Alma system is an attempt to provide a tool for IBM, and to further offer a baseline recommendation of how others can build these systems successfully. The principles described make sense in the context of a system-approach; I appreciate that any system should start with a philosophy and that systems are made of patterns. I don’t understand what “content format” actually is; I do understand the need to “repair” based on user indications of a “miss,” but I’m not sure why that’s considered different than the patterns.

The authors describe the benefits of design systems, primarily focusing on the ability for rapid development, and for internal education of developers, designers, and others who will use the system. These are the same benefits of design systems for graphical user interfaces: speed, and the ability for someone to “ramp up” on a system quickly.

But the authors are basing all of this on a premise that speed and “ramp up” are the most (or only) important part of design, in the same way that Churchill’s article describes, and in the same way that many (all?) of the materials I’ve been reading have been describing. It is absolutely true that moving lego pieces around to make things is faster than making new Lego pieces. But when you have existing pieces, you use them, and this is where the “magic of design” disappears. This is true in the output, and is true in the process—designers have lost the magic of making new things, because assembly is not making. And when did speed become the focus of literally everything, much less creativity?

I’m really, really worried about the way user experience design (and this form of conversational design) has evolved into a service industry for software developers to move quickly, and for product owners to ship quickly. User-centricity is not gone, because the output can push through testing phases. But it’s been completely relegated to a second-class citizen, where conformity and uniformity is more important than creative thinking. Uniformity is absolutely part of a usable system, because it leads to predictability for a user; it reduces friction within a system. But it’s so boring. It’s blanding. It’s unsurprising. It’s commodity work, too, and it really is the type of thing that can be AI-iffied, because it’s so dumb-simple. Yes, it provides easy ramp-up, because it’s completely trivialized process.

Systems thinking is not design systems thinking. Systems thinking is the ability to hold complex ideas in your head, to swivel through an ambiguous and four-dimensional space, to see relationships that are invisible but necessary, to understand how a change over here shifts a thing over there, and so-on. It champions deep thinking, intellectualism, details, models, structures, and implicitly, innovation, invention, and creation. Design systems thinking is dumb thinking.

I read this not because of the conversational references, but because it’s just one of very few papers I can find that even mentions design systems in academic sources. Churchill’s work is in interactions, which is kind-of-academic, but is the primary source material for this article likely because there just isn’t very much to draw from. My assertions are my assertions; they are inductive, and based on my experiences and the broad but casual set of conversations I’ve had with my peers (many of which are in the space of managing and building these very systems.) I want more data to work with to prove or disprove all of what I’m saying. I will hunt more for primary source material on this, that doesn’t go in the Alexandar, and doesn’t reference popular culture articles.

Ps, hi Elizabeth, if you land here from Googling yourself.