The Systems of Design
Last updated
Last updated
One thing I do not shut the fuck up about when I talk about design is the idea of ‘systems’. I’m not sure if it’s my disdain for linear flows, or just the luck of the draw as to where my brain falls on the spectrum, but ‘systems thinking’ is the best way I can describe a mental process for which I’ve long searched for a moniker. While there’s a lot of shit that I’d swap about my brain, this obsession with pattern, rhythm, and a kind of surreal, existential Gestaltism is not one of them. Maybe you’re the same?
When I talk about systems in design, I’m not (always) talking about Design Systems. I’m talking more about the systems that we create, and the systems that we create on top of. If you’re designing a product right now, your product is a system. So is the browser, operating system, even the device it lives on. So are the societal systems that allow, require, negate, or otherwise impact your product’s existence.
A huge chunk of design can be described as ‘system abstraction’, or perhaps ‘system translation’. The idea that we take a system, of some kind, and translate it for humans to use. The notion is simple: you don’t have to understand how something works in order to interact with it. The path to getting there, though, is often far from simple.
One word that’s forever singed into the modern designer’s vocabulary is ‘simplify’. We’re consistently challenged to simplify our interfaces, to remove noise, to communicate more clearly, more succinctly. Another side to simplification lies in the abstraction of complex systems.
The atomic example for system abstraction is the file and folder system found in most operating systems. This is a long-held mental model (more on that later) that serves as a great initial foray into this idea of system abstraction.
What we’re seeing here is essentially metaphor as abstraction. The underlying system is plainly not a physical collection of files and folders. Data storage doesn’t work that way, and it’s quite likely (although I make no assumptions) that most people don’t believe it does. What’s just as likely, is that people kind of don’t give a fuck how data storage works in the first place. They want to achieve something. They want to create a file, or organise their Desktop, or whatever else people do with files and folders on their device. So we enter into a little role play with our device: you protect me from having to understand directories and disk space and fragmentation and whatever else, and I’ll play along and adopt this metaphor.
Oftentimes, when we talk about this kind of abstraction, we’ll use the term ‘conceptual model’ or ‘conceptual image’. When describing the underlying systems (in this case, the operating system, the directory structure, even the physical hardware itself) we might use the term ‘system model’ or ‘system image’. A dangerously simplistic heuristic for this modulation (let’s say, specific to a web app), might read: “The developers dictate the system model, the designers dictate the conceptual model.”
Now, I don’t believe there’s a thousand hard lines between all different kinds of developers and all different kinds of designers, but when we look at domain expertise, in most projects, there’s a general shift away from the actual (development) to the conceptual (design).
When we upload an image to Instagram, the actual is probably something like ‘compressing the image, uploading a few bytes at a time, making sure there’s no data lost, probably fuckin spying on you in some kind of way, associating the image with your user in our database, probably fuckin spying on you some more’. The conceptual is a progress bar with something like ‘Posting image’ in a label.
This translation of actual to conceptual contains a whole number of assumptions. We assume that people don’t give a shit about our compression algorithm (they don’t), and we assume that they don’t want an entire granular readout of the current upload process (they probably don’t). We assume that they care most about the progress of their upload and subsequently if it succeeded or failed. The system, especially for something like Instagram, is complex as fuck, but the conceptual model is not. Again; you don’t need to know how something works in order to interact with it.
This might sound as basic as a pair of fuckin Allbirds, but hear me out. Our job as designers frequently revolves around this form of simplification. We’re almost intuitively analysing these complex systems and deciding what processes, what chunks of state or underlying principles should be displayed to someone—and what format they should be displayed in. A progress bar is an abstraction of anything that happens sequentially or over time. A heart icon is an abstraction of ’send a query to a database that adds 1 to another pointless vanity metric to this fuckin photo of soup’. If this is a tacit skill of designers, a spandrel of the evolution of our craft, then how do we become more purposeful with it? How do we go from ‘our job is about simplifying systems’ to ‘our job is about choosing what systems we simplify’?
I’m not going to dwell on that point, as I’ve already done so plenty in the past. What I am going to explore in this post is the idea of making these abstractions more purposeful. How we might better document our systems? How might we ensure that our abstractions, our simplifications, translate to people who don’t—or can’t—think like us? How do we understand what abstractions might actually make sense in the problem space in which we’re designing?
The idea of ‘problem space’ is another buzzwordy fucker in the realm of product design. The general concept is that by expanding from ‘what problem are you trying to solve?’ to ‘what does an entire landscape of problems and people look like?‘ we’re able to broaden our understanding of who we’re designing for, and the situations they might find themselves in.
When I talk about problem space, I like to see it as four key things:
The people we’re designing for
The problems they face, and how they make them feel
The scenarios they might find themselves in, and the motivations behind them
The systems that they have to navigate to solve these problems
While there’s a lot more nuance to it than that (and you can buy my book to get some of it, thanks!), for a deep dive like this, it’s a decent foundation.
Before I start any design project, I want to make sure that these four key areas are documented, at least in some way. If they’re not, then that’s why we do research.
In terms of documenting people, Personas are the industry darling. They’ve been a part of every design project I’ve taken on in the past ten years. I’m not going to go into detail here. Mental Model diagrams are also a priceless artefact of design that inform things like beliefs, expectations, convention and all sorts. I’d never start a design process without understanding the mental models that exist in a problem space.
Documenting problems, and especially people’s responses or expected responses to those problems, is a little less cut-and-dry. Sometimes they’ll be part of an empathy map (especially if you follow the classic ‘Pain vs Gain’ format). Other times we’ll simply be documenting the key findings from ethnographic research (including field observations, qual interviews, surveys and user testing sessions) in a list or post-it format.
Scenarios and motivations are where we’re kinda spoiled for choice. We have empathy maps, user journeys, user scenarios, storyboarding, jobs-to-be-done, user stories, job stories, some other fuckin stories, customer support requests, user requirement specifications and fuck knows what else. Go off.
What I do think is somewhat overlooked in general, and what this post is really about, is how we might go about documenting systems.
Okay, so first, why document a system? Firstly, it shows that you understand the constituent parts of your underlying product. That’s just fucking useful from the get-go. Secondly, it gives you an insight into the various components, processes, objects and constraints you’ll be designing for, in, and around. Thirdly, and most importantly, it lets you notice areas of complexity that you’ll want to abstract out.
By having this landscape of system-level documentation, you’re able to notice areas of the system in most need of simplification, then reference your people/problem/scenario documentation to explore how you might simplify. With a strong pool of research, you can look at these system-level complexities and propose abstractions, metaphors, even obfuscations that translate. You don’t have to know how something works in order to interact with it.
Most of my early-stage design process involves jumping between documenting research and documenting systems. Every time I see a complexity or idiosyncrasy of my product’s underlying system, I want to consult research for conventions, patterns, habits, anything that might give me a nudge towards how to abstract that out.
I also strongly believe that being able to break a system down in this way is a great antidote to linear design. You move away from seeing your work as just a series of interlinked actions and linear user flow charts, and towards seeing it as an environment, full of objects, causality and opportunities. The more complex the system image (think a design tool like Figma or UX Pin), the less linear and constrained the conceptual image will usually be. Getting comfortable with the idea of a broad and often vague problem space over a neat and succinct single problem, as well as the idea of systems being open-ended and environmental is, in my opinion, a hugely rewarding and valuable experience.
So, I’m going to assume that by reading this far you’re either convinced, or bored as fuck, lessgo.
There are a few ways I feel like system documentation can play out. One of the ways you’re probably most used to is Information Architecture exercises. In fact, IA and content strategy, with their focus on hierarchy, intent and causality, are often the first stages where system abstraction occurs. By taking the system’s underlying state, the components that make it up, and the constraints it presents both to us and to the people who we’re designing for; grouping those together; presenting an initial hierarchy and structure; and generally turning complex system language into parseable human language, IA and Content Strategy provide a wonderful insight into abstractions.
A slightly less conventional way is through documenting the system’s underlying state. This is something that you’d likely expect from a developer, fitting in somewhere between a database schema and a front-end spec. However, as designers, I think understanding the raw components of your system is hugely impactful.
This is usually my starting point for understanding an underlying system. It’s dry and boring as fuck, but it’s a way of seeing some of the raw concepts, objects and data that makes up your system. Seeing things this granularly can help a tonne.
Objects are actors within a system, and represent the key reason why I believe adopting system documentation, away from ‘moment’ documentation (journey maps, storyboards, etc.), is such a valuable thing. The very core of a system is the idea that they are comprised of a whole bunch of potentially-related objects. Sounds simple as fuck, but add in a layer of interaction, and the need to understand how an interaction with any single object might affect and permeate change to many others, and only the simplest systems can really be documented at a glance.
Away from these cases, we look at splitting our systems into objects. Breaking a system down into its constituent parts allows us to understand what the key actors are within that system, how they relate to one another, any power or command one actor may have over another, what the potential implications of an ecosystem change might be. For things like apps, that’s pretty cut and dry, for things like societal systems (the overtly racist US prison system, the patriarchy, all that fun stuff) it’s anything but. Either way, developing the ability to perceive and extract the inherent objects within a system is, in my opinion, a core design skill.
The aforementioned state diagram is one way of extracting objects. But as I said, it’s fucking boring, and it’s extremely dry to produce. I do it, but I don’t exactly enjoy it. A much more interesting way is through Object-Oriented UX (OOUX) workshops.
I first learned about OOUX from a super talented colleague, quite recently, on a project that’s under NDA (if it’s ever lifted I will edit this post giving all the credit I can muster). It’s a way of documenting a system’s objects (surprise, right?) without thinking (initially) about actions, structure, hierarchy, etc.
Think in objects, in nouns, and document them first, usually by extracting them from goals
Break objects down into their underlying content and metadata
Consider how every object might potentially relate to every other object
Perform a CTA inventory against each object
A good few things happen here, that I think make the design process a lot more palatable for ‘system thinkers’:
By understanding that a system is comprised of objects (or components, or modules, or whatever else you want to call them), you’re able to interrogate the core actors within a system, as well as the various ways in which they could be related to one another. One of the main tenets of OOUX is to hold off thinking action (verb) first, and instead think object (noun) first. This, to me, is vital.
Thinking about a system this way is much closer to how we form mental models in our head. We work on categories and predictions and perception. While, semantically, we’ll usually form a statement verb-first (‘I want to pet that good as heck dog’), mentally, we love nouns (‘DOG. CUTE AS HECK. PET IT’). We notice a thing, we assess its characteristics, we infer action possibilities. By getting into this mindset of documenting objects, then considering the possibilities these objects might present, we’ll often find super interesting ideas once we’re free of thinking about action-first, funnel-style approaches.
This is hard for me to elucidate, but when I think about design, the two biggest unknowns for me are always relationships and causality. How is one thing related to another? What happens to every other thing if that one is changed in some way? With an OOUX approach, you’ll very quickly be able to elucidate such things.
Honestly. Fuck me. You could OOUX everything from a mouse trap to a piano to who’s nobbed who in Game of Thrones to your internal company dynamic to a complex video-editing app. When I think of ‘moment-based’ documentation—things like storyboards and user journeys and the like—they start to fall apart very quickly as soon as there’s a degree of ambiguity or contradiction in your work. While they’re invaluable fuckers, and I’d never ever let someone take my storyboarding away from me, they just can’t stand up alone to a complex system in a diverse problem space. Scalable frameworks like OOUX and the various Service Design frameworks we have are a fucking godsend in these cases.
Give Sophia's articles a thorough read if you're into this stuff. Honestly, I can't stress how much this has added to my process in the short time I've been practicing it.
Once you’ve documented your system, designing for it becomes an exercise in abstraction. It’s where we go from having a clear understanding of the objects, relationships and action possibilities of our system and turn it into a digital environment where cool shit can happen. It’s where we go from system image to conceptual image. Deciding how each object can communicate its action possibilities, deciding on the core metaphors and abstractions that mean a normal, fallible human being can interact with your system without ever having to understand how it works.
The one caveat to this post, that I really want to stress for a moment, is the focus on objects as parts of a system. The (often misquoted) basic tenet of Gestaltism tells us that anything (in this case a system) is fundamentally a different thing to the sum of its parts. That is, there is meaning and semantics to relationships and composition. A piece of music is different to the individual notes that form its melody, or the individual beats that form its rhythm. A football team is different to the individual players that make it up. So too are our systems infinitely more than the objects they’re comprised of.
How those objects relate, how they communicate with one another, how they are purposefully and compassionately put together are as important as how these objects exist in microcosm. Take a design system for example. When we build out a UI state from existing components, we’re creating something that is categorically different—in tone, in causality, in purpose—than the individual components we used to design this state. System documentation is not design, it just informs it in a unique and insightful way. We still need to connect the dots, to turn our complex system of actors and objects and action possibility into something else entirely.
If you’re interested in diving deeper into OOUX, I thoroughly recommend Sophia Voychehovski’s amazing ‘’ and ‘’ articles over on A List Apart, but to give the very basics:
To me, this is design. While everything around it is about informing design—about gathering the data and documenting the systems and understanding the humans within our problem space—design is all about this abstraction. There’s an entire book to be written around this kind of st…
