The Cynefin Framework

I’m keen on frameworks that help us deal with change in complex systems. The Cynefin framework is particularly illuminating. Here’s an excellent, succinct introduction by its originator, Dave Snowden:

The framework posits that causal differences in systems categorize them into four domains or “spaces”:

  • Simple: Cause and effect relationships between elements in the system can be determined in advance.
  • Complicated: Cause and effect relationships exist, but aren’t self-evident.
  • Complex: No causality; agents are able to modify the system.
  • Chaotic: Cause and effect relationships can’t be determined.

“Dependent on which space you’re in,” Mr. Snowden says, “you should think differently, you should analyze differently.” In other words, each of the domains calls for a different response. Therefore, knowing which domain you’re acting within is key to making effective decisions. That said, in some cases, you may not know which domain you’re acting within. The framework defines this fifth domain as “disorder,” a situation that lends itself to idiosyncratic responses that can be ineffective or worse.

You can learn more about the Cynefin framework in the Harvard Business Review or in Cognitive Edge, Mr. Snowden’s consulting company.

Cynefin Framework Introduction

Four Types of Prototypes

Prototypes are central to the design process; they’re the means by which designers establish the feedback loops that allow artifacts to evolve. But there’s a pitfall when discussing prototypes: there are different types and uses of prototypes, but only one word (“prototype”) to describe them. This unacknowledged variety can cause confusion and false expectations. Talking about prototype resolution and fidelity is as far as many designers go, but often that’s not far enough.

In a paper (PDF) published in the Handbook of Human-Computer Interaction (2nd Ed) (1997), Apple designers Stephanie Houde and Charles Hill resolve this issue by identifying four categories of prototypes, based on the dimension of the design project they’re meant to illuminate:

  • Role prototypes
  • Look and feel prototypes
  • Implementation prototypes
  • Integration prototypes

(Following quotes are from the paper.)

Role prototypes

Role prototypes are those which are built primarily to investigate questions of what an artifact could do for a user. They describe the functionality that a user might benefit from, with little attention to how the artifact would look and feel, or how it could be made to actually work.

In other words, this dimension is meant to cover the “jobs to be done” angle of the product or system. How will people use it? Would it be useful in its intended role? What other purposes could it serve for them?

Look and feel prototypes

Look and feel prototypes are built primarily to explore and demonstrate options for the concrete experience of an artifact. They simulate what it would be like to look at and interact with, without necessarily investigating the role it would play in the user’s life or how it would be made to work.

This dimension doesn’t require much explanation; these are prototypes that are meant to explore UI possibilities and refine possible interaction directions. (I sense that many people focus on this aspect of prototyping above the others; look and feel is perhaps the most natural target for critique.)

Implementation prototypes

Some prototypes are built primarily to answer technical questions about how a future artifact might actually be made to work. They are used to discover methods by which adequate specifications for the final artifact can be achieved — without having to define its look and feel or the role it will play for a user. (Some specifications may be unstated, and may include externally imposed constraints, such as the need to reuse existing components or production machinery.)

These prototypes often seek to answer questions about feasibility: Can we make this? What challenges will we face in producing such a thing? How will a particular technology affect its performance? Etc.

Integration prototypes

Integration prototypes are built to represent the complete user experience of an artifact. Such prototypes bring together the artifact’s intended design in terms of role, look and feel, and implementation.

As its name suggests, this final category includes prototypes that are meant to explore the other three dimensions. Their comprehensive nature makes them more useful in simulating “real” conditions for end users, but it also makes them more difficult and expensive to build.

The authors illustrate all four categories with extensive examples. (Mostly charming 1990s-era software projects, some of them prescient and resonant with today’s world.) A running theme throughout is the importance of being clear on who the audience is for the prototype and what purpose it’s meant to serve. A prototype meant to help the internal design team explore a new code library will have a very different form than one meant to excite the public-at-large about the possibilities afforded by a new technology.

The paper concludes with four suggestions for design teams that acknowledge this empathic angle:

  • Define “prototype” broadly.
  • Build multiple prototypes.
  • Know your audience.
  • Know your prototype; prepare your audience.

Twenty-plus years on, this paper remains a useful articulation of the importance of prototypes, and a call to using them more consciously to inform the design process.

What do Prototypes Prototype? (PDF)

An Example of a Semantic Environment Map

I’ve had folks ask me for examples of a semantic environment map. Here’s one for the confessional, a semantic environment within the broader environment of the Catholic Church:

Did I get it wrong? It’s likely. If you can spot problems, the map is serving its purpose: to help us have discussions about contextual issues that often go unnoticed or unexpressed.

If you want to create a map of your own, you can download a PDF of the Semantic Environment Canvas.

The Ladder of Abstraction

You may have heard that dogs and cats only see in black and white. That’s wrong; these animals are dichromatic, which means they have limited color vision. What is true, however, is that their vision is different from ours. Other animals, such as some bats and rodents, are indeed monochromatic: they only see in black and white and shades of grey.

Before you start feeling smug, consider the limitations of your own sensory system. Some other animals, such as boa constrictors, can see infrared light, which is invisible to you and me. And you know about dogs’ sense of smell, which is much more refined than ours.

The point is that we don’t perceive the world as it is, we perceive it as our senses allow us to see it. Our sensory system presents to us an abstracted view of reality. (This suits me fine; our sensory system has evolved to allow creatures like ourselves to survive and thrive in environments like ours.) And on top of this already abstracted view, we layer another abstraction: language.

Continue reading