The Trouble with Systems

systemsMuch virtual ink has been spilled in the last year or two over the importance of thinking about information design in terms of systems as opposed to thinking of it as a set of carefully laid out maps.

In a 2012 blog post on Embodied Responsiveness, Andrew Hinton observed that “rather than trying to pre-program and map out every possible scenario, we need systems that respond intelligently by the very nature of their architectures.” Stephen Hay (Responsive Design Workflow, 2013) and Sara Wachter-Boettcher (Content Everywhere, 2012) have likewise called out the need to stop thinking about web design in terms of pages and start thinking about it as a system, as a cohesive, interrelated whole.

As each of these authors state in turn, we no longer get to decide who consumes our content on the web, where it is consumed, or in what context it appears. The fixed-width honeymoon of predictable browsers on stationary desktop behemoths is over. Our content and our carefully designed information hierarchies are now popping up everywhere: desktop, phones, treadmills, refrigerators, third-party readers and aggregators, watches, Glass — the list goes on.

Hinton illustrates the impact of system design on this scenario with a comparison of Honda’s Asimo robot to the “Big Dog” robot created by Boston Dynamics. Asimo calculates its every move with the aid of advanced processors … and then pathetically tumbles down a very short set of steps before an audience of thousands. Big Dog noisily lunges over uneven terrain, a pile of bricks, and ice — keeping its footing even when viciously kicked in the robot ribs by some ill-tempered luddite.

Asimo’s scenario-mapping brain is expensive — in research, resources, and efficiency — yet still only responds to its environment poorly at best. Big Dog, on the other hand, leverages the totality of an embodied system, what in Supersizing the Mind (2011) Andy Clark calls “ecological control” or “soft assembly” (4, 157). This allows Big Dog to negotiate perturbations (and outright physical violence) ostensibly unplanned for in its design.

There is an analogue here for information design in the mobile era: as designers, the iPad mini is our pile of bricks. Android is our ice. The iWristwatch (or whatever horrible name Apple gives it) will be our rib-kicking luddite. The rigidly-mapped information design approach of circa 2005 is Asimo on a poorly tuned elliptical machine. Sad, sad robot.

Of course we must approach these design scenarios with smart, responsive, holistic systems. This much is clear.

But here’s the problem: As a species, we suck at systems. The way we think about complex ideas is structured by language. Language is linear (i.e. syntactical) and bounded by frames of reference (i.e. contextual). Systems contain non-linear relationships and are ultimately unbounded (i.e. they’re all connected — there is, properly speaking, only one system).

This is why systems continually surprise us. In her brilliant systems theory overview Thinking in Systems (2008), Donella Meadows writes that “systems surprise us because our minds like to think about single causes neatly producing single effects. We like to think about one or at most a few things at a time. But we live in a world in which many causes routinely come together to produce many effects” (100). While we can often get away with, for a time, focusing on the particular sub-system in our immediate frame of reference, it is inevitable that this system will eventually register the influence of the larger structure.

We tend to find this annoying, alarming, or infuriating. Sometimes all three. Web design for the pre-mobile internet could, for a time, mimic the constraints and limitations of the printed page. Eventually the rest of the system began to catch up with us. Stephen Hay notes that “the responsive web is the web as it was intended” (4). The challenges of responsive web design were always inherent in the web; we were simply able to ignore them for a time.

The good news is that while we might suck at systems, we absolutely rock when it comes to narrative. This is where our single track thought process — abetted by the linear structure of language — excels. From a single word our brains pull in and mash together scores of associations, memories, and emotions. Threaded together, words (and the concepts they signify) create rich worlds of experience — experiences that motivate, inspire, and drive us to action.

This contrast between systems and sentience raises an important corollary to the ecological control system design strategy outlined above: as much as we now need a systems approach to information design, we equally need an approach to systems design informed by human experience and perception. This is especially true if our final goal is to make systems intelligible to end users who simply want to check their email, the weather, or their social feeds. The world of systems is a square hole; our linear sentience is a round peg. This is the trouble with systems.

As an initial stab at defining an approach to systems informed by the way we think, I submit that information architecture is in a unique position to act as a shim between systems and sentience. IA is where we create information from data and structure that information with narrative. We use IA to wend a deliberate path through the wilds of content at large.

In practice, I suspect that thinking about the intersection of systems and sentience this way will involve some subtle changes to how we approach information design. To begin with, we’ll have to get better at embracing ambiguity. We’ll need to let go of the control that comes with the printed page (which, let’s be honest, we haven’t in reality had for years).

We’ll also need to more deeply incorporate design thinking into our architecture and design process. Forging narrative paths through nonlinear feedback systems will likely rely on proposing and testing hypotheses based on best-case heuristics as we understand them at the moment. Each solution will better inform the problem, which will in turn propose a more refined solution. (For more on design thinking in IA and the hypothesis model, see Jason Hobbs & Terence Fenn and Jeff Gothelf respectively).

Finally, we’ll need to embrace the strength of narrative to structure information-based experiences. This means focusing on the way we understand things as linguistic animals — not on the structures that make smart systems smart. Narrative in this sense goes well beyond “story” as we traditionally think of it: narrative is the rich, multifaceted process we use to assemble meaning from discrete elements over time and across contexts. We may not be constitutionally capable of fully understanding the collective systems we create; this need not, however, keep us from using them to meet our goals and enrich our lives.


  1. I think you’re dead on in identifying narrative as the foundation for UX design in the modern Internet. It’s a necessary bridge from the old page metaphor.

    For awhile now, I’ve been advocating that “conversations” be the foundational metaphor on which multi-device, contextual systems be designed. Conversations between individuals are contextual and can be transferred from one environment to another (we can speak in person and then continue the conversation by email). I think this is a good way to model how an organization’s web presence should interact with individuals.

    Here’s my original post on the subject, back from 2011 (on my old blog):

  2. I’ve been presenting on this exact problem, and have my own two-part article coming out (someday) on it as well. While I robustly agree with the premise of systems making everything impossibly complex, I am not sure I get how thinking in narratives helps.

    For many years we’ve relied on use cases, and similar processes that analyze by what are basically user/system narratives. To accomplish Y, go through screens A, B, C… To accommodate the complexity of the layered systems, and as you realize the complexity, you end up needing more and more use cases to cover all the variations. As I read your discussion above, you admit that it just gets closer to covering more complexity, but doesn’t try to address the full scope.

    Our systems are not very complex, but /arbitrarily/ complex. Only designing to a few dozen use cases leaves many unaccounted for. In a few past projects where the variation has been plausible to roughly calculate, I have determined it would take the life of the universe to date to work through them all. In other words: this way lies madness.

    So, I’ve been proposing some alternatives. Embrace complexity and failure. More specifically, design by component. Very often, most components have a very easy-to-handle number of variations. A site search (for example) can be performed against a few domains, has empty and pre-populated states, can have a couple auto-suggest functions, and 2-3 errors conditions. Add in a few display/interaction variations for a handful of platform class variations (touch/mouse, scale) and you can bang out a design specification for the search widget in an afternoon.

    The system will combine to make that complex, but every condition in which that widget operates has been covered, so — if you get the implementation team to buy into this basically object-oriented approach — you can approach zero unexpected conditions across the system as a whole.


  1. […] have written elsewhere in more detail about challenges posed to linguistic thinkers by systems. To put all of that in a nutshell, complex systems baffle us because we have a limited capacity to […]

Speak Your Mind