Pace layers in experience design — Stabilise innovation by understanding people’s needs
I recently wrote about why content is more important than code, but how neither of them are as important as people’s needs.
Code serves content. Content serves people’s underlying needs.
User needs ⟶ Content ⟶ Code
In the course of writing that post, I realised that this sequence can be extended further.
It reminded me of the concept of pace layers.
Pace layers explained
In the 1970s the architect Frank Duffy posited the idea that a building is not one entity, but made up of several layers, each differing in longevity. In the 1990s that model was built on by Stewart Brand to include the following layers:
- Stuff (such as furniture)
- Space plan (interior walls)
- Services (like plumbing, electrics, ventilation)
- Skin (external elements like cladding)
- Structure
- Site (the land the building is built on)
Layers nearer the top of this list change more quickly. Layers nearer the bottom change more slowly.
This model was abstracted to apply to civilisation more generally:
- Fashion
- Commerce
- Infrastructure
- Governance
- Culture
- Nature
As Stewart Brand described it: “the fast layers innovate; the slow layers stabilise.”
He continued:
Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.
Code, content and user needs operate on different pace layers
When I said in my previous post that content is more important than code, it may have been more accurate to say that content is more fundamental than code. And that user needs are more fundamental than content.
Code serves content. Content serves people’s underlying needs.
Or, expressed diagrammatically:
Two types of code: channels and implementations
Content has to work across multiple technologies, or channels. Multiple channels can exist at once, serving the same content, and therefore the same underlying need.
For example, a webpage, mobile app, social media post, email and print document may all derive their content from a single source.
Some of those channels can come and go fairly quickly, according to changes in fashion or technology. For example, BBC News content structures were originally designed to accommodate the Ceefax teletext system, which has been obsolete for almost a decade.
Each of these channels requires its own code in order to run. For example, the teletext decoders within TV sets, or your web browser.
People can even prefer different implementations of a channel according to their own context. For example, a webpage may be accessed through your own browser of choice. Even beyond this, you may use a screen reader, or your browser’s reader mode, or an RSS reader.
Like channels, each of these implementations relies on its own code. For example a website is built using standard code such as HTML and CSS, but also often using whatever tech stack or frameworks are particularly fashionable at the moment due to changes in technology and tastes.
This is the fast-paced, innovative end of the pace layers model.
Beyond code and content
Implementation doesn’t always need to refer to code, depending on the user need we’re trying to meet. Similarly, content isn’t always what meets a user need.
For example, if someone is hungry they won’t seek to read content — they’ll want to eat food. This layer can be described as the action a person takes to meet their immediate need.
Responding to stabilising forces
Implementation is where the innovation happens. But to work effectively, this innovation ultimately needs to respond to the increasingly stabilising forces in the more fundamental, slower layers.
This is what we mean when we talk about viewing design at different zoom levels. If we focus solely on the technology, we risk losing sight of the stabilising forces that make our work relevant to people.
Finding the right connections between pace layers
There are a variety of tools that help us understand how to connect what we’re building to more fundamental user needs.
User stories are a particularly common format. But I’m increasingly seeing people struggle to apply user stories meaningfully. I think this is often because they’re not thinking about the right pace layer.
User stories connect user needs to actions. But sometimes teams are doing things that are more about the link between actions and channels, or channels and implementations. User stories don’t make so much sense here.
We see some people bemoaning user stories because they’ve seemed like a waste of time. But I think this is often the result of using the wrong tool for the wrong pace layer.
If you are not actually trying to understand a user need, user stories will make no sense. But that doesn’t mean user stories are always useless. This is when you can use developer tasks without necessarily expressing them as user stories.
Getting to underlying motivations
Another reason user stories sometimes fail is because what we often describe as a user need doesn’t actually tell us enough about the underlying motivations that drive human behaviour.
One framework that helps make this clear is jobs to be done, as promoted by Clayton Christensen. In the flagship example, it was found that people have specific reasons for buying a McDonald’s milkshake — and it’s not just to taste a milkshake.
Those reasons are: to keep themselves occupied during a long morning drive to work, and to satisfy their hunger until later in the day.
The competitors of McDonald’s milkshakes aren’t other milkshakes. They are doughnuts, bagels and chocolate bars.
The user need might be “drink a milkshake”. But this need is also serving a more fundamental purpose. The “job to be done” statement connects the user need to that purpose: “keep me awake while I drive”, or “keep me feeling full until lunchtime”. These are the person’s underlying motivations. The milkshake is a means to an end.
Going further still: physiology and principles
In this chain of needs, we can go further still.
In our pursuit of survival, human behaviour is driven by underlying physiological needs — things like “I’m tired” or “I’m hungry”.
Consumers of milkshakes want to be occupied during their long drive. But they are doing so in order to stay awake, stave off their hunger, and ultimately to stay alive.
There are many models that attempt to describe how human behaviour is informed by such underlying needs.
For example, William Powers described a hierarchy of goals. In this model, people have principles that are informed by an expression of their ideal self.
Most fundamentally, your behaviour is driven by a need to feel less hungry and tired. But you may also have your own principles that fit to your identity.
Your principles may involve eating healthily, or being a vegan. These principles begin to inform your decision-making further down the chain.
You might “drink a milkshake”, “drink a smoothie”, or “eat a bagel”, depending on your principles. This is how a bagel can compete with a milkshake.
This is how content isn’t so important
I mentioned before how jobs to be done and user needs doesn’t always translate to content.
If a piece of content doesn’t help a person achieve their goal, that content shouldn’t exist — in just the same way that if a piece of technology doesn’t help people retrieve the content, it shouldn’t exist. This is why, although content is more important than technology, it’s not that much more important.
Stabilise your innovation by understanding human behaviour
What matters is having a firm understanding of what your users need, what motivates them to need it, and ultimately the underlying drivers of human behaviour.
This is why taking a human-centred approach to technology is so important. Innovation falls flat when it doesn’t respond to a human need. Use human-centred approaches to understand people’s fundamental motivations and needs. These are the stabilising forces for innovation.
Pace layers in experience design — diagram
Addendum
I realise that what I’ve outlined bears some similarities to Jesse James Garret’s elements of user experience model. This doesn’t talk about technology specifically, but it does outline how functional requirements and content requirements both exist to serve more fundamental user needs. It is like a zoomed-in version that focuses on how user needs inform a web design.
There is also a resemblance to Don Norman’s activity-centred design, where he sees activities comprised of tasks, which in turn are made up of actions and then operations. This is like a zoomed-in version that focuses on the human interaction with a product.
When we zoom in on a particular pace layer, we often see further sub-layers. This model is like a fractal.
