…and with great power, or great agency, comes great responsibility.
Keep that in mind as I start to unpack this talk.
This talk started over a year ago as a way for us to better explore and articulate what it meant for us to be a design firm in the 21st century. An advisor of ours challenged us, and told
us that we needed to have our Martin Luther moment, and this was the start of a conversation we’ve been having internally, and increasingly externally for the last year, which we call
“Design for the Network”.
Essentially, Design for the Network, of DFTN, is the shorthand we use for our emerging thesis of design, the idea that I’m going to talk about today, which is what it means to be
software designers in the early days of the 21st century.
I want to talk with you today about networks, software and systems, and what these ideas mean for us as designers. We’re at a very important point in time both as a society and as
designers, and we should be excited, but also thoughtful and respectful of the responsibility we hold in our hands.
The story of the network is the story of society; it’s the story of civilization.
I want to start with a network we’re all familiar with - the railroad.
This is a railroad map from 1910. It’s a comprehensive network that provides coverage for much of the physical area of the United States.
The network, and the trains that operated on it provided an infrastructure for moving physical things from place to place. Stealing from some Canadian guy who’s name I can’t recall,
this thing was really good at collapsing time and space.
We all understand how the rail network changed the nature of business; bringing the hierarchical structure of the corporation to life. What gets lost is the software that enabled this to
happen. Without the software of the train schedule, the new culture of the organization doesn’t emerge. The software that kept the trains on time, and kept them from crashing was
what made the network of the railroad really valuable. With out the schedule, it’s just a bunch of metal strips lying on the ground.
The point that I’m making here is that software is what matters, and not software as code. I’m talking about software is a feedback-driven rule set; a self-regulating system, a program
actually, which had to be designed.
Networks become magical when you add software to them.
There’s a great word for magical networks, it’s “systems”. Whether it’s physically connected like a railroad, or connected in a more nuanced biological way like an ecosystem, the
connectedness of the network is brought to life with software.
The feedback and feedforward capabilities of software are what make the magic happen - whether it’s centrally controlled like a train schedule, or distributed like flora and fauna in a
marsh ecosystem. The marsh doesn’t have a human hand at the tiller, but it’s a fully functioning system, full of feedback loops, all seeking sweet, sweet equilibrium!
I’m a partner at a company called Normative in Toronto. We design software, so we call what we do “Software Design”.
We love our work. Complex software, simple software, we don’t discriminate. If it’s software, and it’s connected to the internet, we’re in a very happy place
One of my partners at Normative, Matt Nish-Lapidus, loves talking about roads, and the evolution of the road network. He makes some great points about the roman road system, and
how it lead to things like standardization so that carriages could work across the system. This is packet transfer, but with extra horses. Networks love standards. It’s one of the things
that allow us to build creative kinds of software capability on top of network infrastructure.
The Roman Empire was literally built on a network; a network of roads. These roads were standards-driven, extensive and consistent. They were the platform on which the Roman’s
projected their strength and capability, through the invention of logistics and supply chain - the software that ran on their network.
One of the things that’s fascinating is that sometimes we can become the software. The 20th century road network had all kinds of software in it, but for the longest time, the only
software you’d find in the car itself was the the software we had in our heads, software that was influenced by other software, like motoring laws, traffic signal infrastructure and road
signs. We’d interact with this software ecosystem, bump it all up against our own software, like not crashing, and use it to get from place to place. Essentially, our software created
behavior, like driving, which resulted in millions of people driving all over the place. When you have behavior at scale, you get the emergence of culture, and there’s no question that the
car, and more importantly, driving cars led to an incredible amount of cultural change in the last 100 years.
One of the amazing things about culture is that it has the power to shape environments, and in many cases, you get untended consequences at the environmental level. The idea of
driving led to the development of new urban forms, including the the suburb. Without really thinking about it, we ended up with an environment where driving, a behavior we used to
control, became something we were required to do in order to get around. We got so focused on designing “things" like cars and suburbs that we forgot to to keep working on
software, with some arguably undesirable environmental consequences.
Think differently about networks
So one of the things we need to start to do is think differently about networks, and what they represent to us. Networks are platforms, platforms give us the standards to create and
change capability, behaviour, culture and environments.
Think differently about software
This also means that we need to think differently about what software is, and how it changes behaviour, and creates culture.
I’m a Canadian who’s spent a significant amount of time in the US, and it’s interesting for me that our constitutions, our software for rights management, don’t have to be the same to
play a part in producing similar effects. There’s other “software” of course that makes these two countries different, but sometimes the code doesn’t have to be the same to get
similar outcomes. You just need to think about how the software you create interacts with other software, and gives agency to actors in a system.
I’m digressing here a bit, but the founders who programmed the operating systems for these two great countries really understood that they were doing more than designing the
experience of being “Canadian” or “American”, they were creating the trans-generational ability for a nation, to survive and be successful on its own terms.
Think differently about systems
And, finally, we need to think differently about systems: and specifically, how we learn more about their nature, without ever understanding their true nature.
Working with systems isn’t something where you can just prescribe an action and expect an outcome. The more complex the system, the less likely we are to ever understand it. We
need to become comfortable with learning more and more about the nature of a system, while at the same time, never ever getting to a point where we truly have the system mapped
and understood. There will always be things we don’t know about systems, especially “soft” systems, and that’s why we need to think about them as being magical.
Steward Brand has this concept he’s called pace layers, which a number of individuals have talked about here over the years, including Stewart Brand himself. Pace layers are a way of
thinking about the speed, or pace of how things change over time: fashion and art move incredibly fast, commerce slower, infrastructure and governance chance even more slowly
still, and culture is the slowest human-created effect to change, or at least, that’s what the model is suggesting. Nature, well, that changes at a glacial pace - pun intended.
There’s two things here I want to point out here which I find really interesting. The first is the notion that nature or environment changes more slowly than culture. There’s a pretty
fierce argument about climate change going on right now where people are essentially debating that nature *can* be changed faster than culture.
The second thing I want to point out is actually an idea. I’d like to propose that making things, and specifically the intentional making of things, or design, is the most effective way to
hack pace layers. The things we make that create behaviour, the stuff we design, allows us to short circuit the pace layer model. Just like the Nam Shub in Neal Stepenson’s book
Snow Crash, designed things can rewrite code and culture in a literal instant.
As designers, we have the tools to help rewrite culture, and environments too. This is a lot of power and a lot of responsibility.
If design is a hack, and maybe the ultimate evolutionary hack, then what’s actually happening? There’s many different ways that people describe what design is, and what design
This is the current wikipedia definition, which is pretty decent, and certainly falls into a place where the language and activities feel comfortable: things like planning, architecting and
Today, I’m not interested in discussing how design gets done, although you’re welcome to debate that among yourselves during the break.
What I do want to talk about a bit more is “what design does”, and that’s to drive behavior change at the level of individual actors, and culture change at scale.
If the value of design is to influence or invent culture by creating an encounter between an artifact and an entity,
then graphic design creates culture with symbols…
And Industrial design create culture with objects…
And the emerging design practice we’re interested in creates culture with systems.
Software = Systems
And I believe that in a networked world, software and systems are the same thing.
Systems are made up of other systems, and an increasing number of these systems are are shaped with the programs and rule sets that we’re designing.
“… we are no longer
interfacing to a
computer but to
culture encoded in
digital form …”
Lev Manovich, The Language of New Media (2001)
I’ll go a step further, and suggest that our environment has become software, or maybe more appropriately, it was always software; we just started adding our own software to it.
Maybe Mark Andreessen was right, software is eating the world, or in terminology that I prefer, subsuming it.
It’s certainly becoming a significant influence on our culture.
As a side note for those of you who are asking, “where’s” information in all of this? Only the most incomplete software doesn’t have built-in information primitives, and the work that
Stephen Wolfram’s been doing over the last 30 years is a fascinating rabbit hole that we can dive into some other time.
Let’s step away from the discussion of design and systems for a few minutes, and talk about some more specific things, like what the design of software does for actors in the system,
actors like us.
Software is augmentation, like any other kind of tool, and it helps us do things. It’s a very sophisticated type of augmentation, and we’re still wrapping our heads around what the point
of software is.
I’m going to go on a bit of a rant here, and challenge that our community has is at risk of missing the boat when it comes to software. We’re out to lunch, and we seem to have missed
the point. It’s not enough to care about what it is, we need to be obsessed about what it does.
Our responsibility is not to make software more usable. Making things easy to find isn’t good enough.
I don’t even think it’s about making things easy to understand. This stuff is gravy.
We need to focus on the meat: the point is augmentation, the point is making us more capable.
Or more appropriately, creating more capability.
Software Gives You Superpowers
The purpose of software is to give us superpowers.
Of course having a superpower that’s easy to use is nice, but if you remove the need to learn a superpower, you limit an individual’s exploration of that superpower. They’re going to use
it based on how you prescribed it, and they’re less likely to get creative with it and use it in new an interesting ways in the environment.
Software gives you superpowers.
When we’re working in our design practice at Normative, we’re acutely aware that at one level, our job as designers is augment people in ways that are quite frankly, magical.
Something like the Google search box, is magical. It’s like super memory. You can remember things you never even knew to begin with. The most successful software gives incredible
This is an early conceptual prototype of an augmented reality application that we’ve been working on for almost a year. It’s probably the most technical complex thing we’ve ever
worked on: imagine if you took all of the computer vision and information analysis capability of spy satellites and drones and packed it into a mobile phone - what do you do with that?
What we realized over an endless number of iterations is that what we’re dealing with is not the precise positioning of geospatial imagery.
What we’re doing is giving people the ability to travel through time. That’s the superpower we’re giving people.
Now I want to be clear that I’m not suggesting that giving people superpowers isn’t without it risk or challenge.
Power can be abused, and used for everything from creating grief to enabling tyranny.
The ethics of modelling is something we’re going to need to spend a lot more time talking about in the very near future.
Getting back to slightly more tangible, I want to touch on the idea of software containers.
I love this sketch that Dave Gray made to bring this great quote by Mike Kuniavsky to life.
Fantastic on so many levels.
What’s really exciting is that the stuff that software can be held in, containers of software as you will, has exploded in scope and variety.
Software containers can include physical objects (like a wearable device), virtual objects (like a web browser), organizational objects (like a business), or cognitive objects (like brains,
feedback loops, etc).
This computational power that’s emerging on top of the internet is simply amazing.
This network context includes a lot of things, many of which aren’t human, but have agency or what I’ll call proto-agency. These “information entities” come in a myriad of forms: Bots,
API’s algorithms, smart objects, etc.
I think we could even build an argument that hyperlinks have agency, but I’ll need a beer or three before talking to Andrew Hinton about that.
Interweb O’ Stuff
All of these objects and entities, live and interact on the network we call the internet.
It’s more than just the web now - this is an emerging environment in which this broader swath of interconnected “stuff” can live, grow and evolve, and we’re part of it.
The superpowers aren’t just for us anymore.
So at Normative, we design software systems that live on the network, sometimes as programmed agents, sometimes as interfaces for actors like people, and increasingly as
systems themselves that are augmenting both human and non-human capability.
We’re designing for the network.
When we meet new clients, one of the first things we end up talking about is how the design challenges they’re facing are much bigger than just creating a great user experience.
A question I like to ask is:
“ What can you do when you have the computational power of 1 million browsers, and 1 million people pointed at your network infrastructure.
“What capability to create for those actors, and what capability do you create for your organization?”
Our job is to help them answer those questions:
“what problem are we solving, and how do we solve it?”
We have all of this amazing connectivity, and the ability to connect so many actors, and create so much agency.
What software should we create?
We’ve become really good at making better shopping carts,
but is this really the extent of our ability to improve the agency of actors in the systems we design?
I don’t think so - we have to be capable of more.
We explicitly created Normative as a tool, a design, to generate and test hypotheses about the future of design, and our focus right now is on understanding “What are we designing
Our answer appears to be “the Network”, but in all honesty, we’re still unpacking this, and expect to be for some time.
While I don’t have all the answers, I will share with you our directions, or signals, and in particular, three signals, themes, or theses that are becoming increasingly strong and
influential in how we think about design for the world.
Design for the network is more than just an activity, perspective, or mindset.
To design for this world, we
need a new aesthetic.
To design for this world, we need a new aesthetic,
A network aesthetic.
Network aesthetic means that things that happen in and to networks have their own beauty;
We’re just starting to grasp what this looks like - judging how beautiful or compelling something is by it’s topology, connectivity, spiky-ness and agency.
Design for the network is about pursuing this aesthetic.
We’ve started using new language that’s helping us put our arms around what’s essentially a dark matter problem…
And for those of you who didn’t get that reference, I’m going to stop for 30 seconds and let you all make a note of this book…
got it? great, let’s go back to that new language for a second.
Agency is the capacity to act - we’re using this in the context of both human and non-human actors.
Texture describes the connectivity of interfaces, and not just screens, everything from API’s to physical things
Opacity describes the clarity of connections, how clear or comprehensive is the model that an interface can expose to us.
Reflexivity helps us talk about quality and richness of cause and effect loops, essentially, what’s the feedback like…
This language isn’t complete or carved stone by any means, but we strongly believe that new language helps regenerate organizations, practices, communities and cultures.
To be clear this isn’t about create an entirely new language; we don’t need the design equivalent of Esperanto. What we do need is language that changes how we think.
Talking about this is good. Doing this is even better.
Getting back to the idea of dark matter for a second, there’s something that you have to accept when you’re dealing with complex systems.
You’re never going to fully understand that system, and assuming that you can begin to develop a model of a system without ongoing feedback is just plain crazy.
We’ve been heavily influenced in our design practice by a systems inquiry practice developed over the last 40 years by a number of individuals including Peter Checkland and Brian
Not the Beach Boy…
This practice, called soft systems methodology, is based on the idea that you use conceptual models to inquire about the nature of a system, and that feedback gives a slightly better
understanding of the system. You turn this into a feedback loop and becomes an ongoing process that continually inquires into the nature of the system, helping you improve your
What excites us is the idea of the model as software. Essentially, every time you design software, you have the opportunity to have it engage in the modelling process.
We already do this is very rudimentary ways with things like analytics and tracking on web sites and mobile devices, but I get excited about the idea of pointing a software at a
networked system, not to surveil it, but to learn from it, so we can understand it better.
Design for the network is really about this: every piece of software we create needs to help us with this inquiry. Planning is good, but learning is better.
Finally, I’d like to return to the point of software.
It’s to give people super powers, right?
Actually, we need to consider if it’s more than that.
Some of you may have seen, or own a Little Printer? It’s a fun little toy.
I think it’s also a genius design direction by the folks at BERG to get us comfortable with interacting with non-human things as if they’re humans.
Conditioning us to deal with a wider range of actors, with super powers.
The challenge is that environments and systems do best when they serve all actors to maintain a state of equilibrium.
Systems tend to go crazy, unpredictable places when they are rigged to prioritize one actor at the expense of others.
We need to start thinking about the whole system, not just people. We need to move beyond design as an anthropocentric practice.
I think we need a new target for design, and people aren’t it.
This emerging design practice we’re talking about, might be the first design practice that isn’t purely human centered.
We can’t design for just one class of actors, we really do need to “design for the network”.
I believe that the network, and all that actors in it, including us, but more than just us, is what we need to design for.
Yes, we want software to give us superpowers, to give us capability, but we can’t just keep it to ourselves, we need to distribute it to the network; that’s what we really need to focus on
So software give everything superpowers; especially networks.
That’s a lot to absorb, and I appreciate you letting me share this thinking with you as we’re exploring and learning.