“Look deep into nature and then you will understand everything better.”
— Albert Einstein
All my life I’ve loved spending time in nature. As a child, much of my time was spent playing on my grandmother’s farm sneaking down to the creek with my siblings, climbing trees and finding secret hiding spots in the surrounding woods. And even now, nothing makes me feel more relaxed than fresh air and the sound of wind blowing through the trees.
As an artist and designer, I’ve always looked to nature for inspiration. I love finding patterns in nature, from the macro to microscopic level. Leaves and animal tissues show off the same striations and clusters under a microscope, in the same way that a tree looks like the bronchial tubes in our lungs. And it isn’t just how these things look, they all hold similar functions as well.
Did you know… the cross-sectional area of a tree trunk is the same as the sum of the cross-sectional areas of all the tiny branches at the end of the network (the petioles)? It’s called area-preserving branching and it also occurs in the vasculature of all mammals — a natural pattern.
It’s been easy translating inspiration from nature into my art. I love using nature-inspired motifs and patterns in my work.
But translating inspiration from nature into my work as a user experience designer hasn’t come quite as… naturally.
When I first started working in enterprise software a few years ago (after working in publishing for many years) I discovered this crazy world of scrum teams, agile, waterfall, jira, stories, user testing and APIs. It all just felt kind of hectic to be honest, and like there was this obsession with breaking things down — work, effort, time — into smaller and smaller parts. How small is too small? How many story points is it?
As an artist, I looked at technology as a new medium to work with. And I felt that my job as a user experience designer wasn’t just to do research and then ask user’s if they like red or blue better, it was to make complete, creative use of all of the tools and technologies available to me in order to provide better experiences for our users whenever they find themselves interfacing with our systems in order to get some job done.
It’s difficult to be creative with a set of tools if you don’t understand the tools very well, so in order to develop a deep understanding of how things worked, I started looking for patterns. Finding patterns helps me to start break things down into first principles — it lets me see what are the key ingredients needed to make something, and what are the variables. Overtime I began seeing natural patterns emerge in more and more areas of technology, and I think these patterns can teach us something about how to build maintainable, flexible, adaptive systems that scale.
The Patterns Emerge
The patterns started emerging for me when my team began work on a design system. I knew of design systems and had used them in publishing in the past, but honestly didn’t think much of them aside from appreciating how much easier they made my work as a designer. When the final destination of your design is the printed page, you can trust that the intended design gets replicated in the printed medium. But when the final destination of your design is the web, you know that there are layers of systems interacting with your designs, throwing out variables that can significantly alter the experience of the user. To design for this complexity, you need to design interfaces that are flexible and adaptable. Design systems are a key enabler to achieve more flexibility and adaptability in the design of the user interface.
I first became aware of atomic design at this time, and really loved the paradigm of breaking down designs into their constituent or atomic parts.
For example: A single button is an atom, and an input field is an atom, but combine these together with a label atom and you have a search form molecule.
Combine the search form molecule with a navigation menu molecule and add in a logo atom, and you have a header organism.
Of course actually creating a design system based on this philosophy is much easier said than done! This design system had to work with intersecting technologies and needed to stand up to multiple variables from the user, the underlying technology, and the environment.
So, we knew there were going to be some things that we could only assume or take an educated guess at — like what type of problems a user might encounter as they’re filling out a mortgage application online. But there were other things that we could get a better understanding of, like the underlying technology that produced the interfaces we were designing. In order to create a design system that works, it needed to work with the functionality and services running behind the scenes… and as I learned, they too mimic these molecular patterns.
Objects = Atoms
Back in the 60s, computer scientist (and professional jazz guitarist) Alan Kay pioneered work on object-oriented programming, which was a new approach to how computer code was structured.
Early computer code was linear, written like a novel, and ran on a single timeline, one action after another. The code would start being executed at the top and ran down line-by-line to the very end. This resulted in very large chunks of code.
As complexity of our software increased, hundreds of lines of code became thousands, becoming more difficult to develop and maintain. Even worse, when code failed it was difficult to detect why and where because the code package was like a black box. Programmers would have to wade through thousands of lines of code to find problems.
So, to tackle this increasing complexity, object-oriented programming was born. The idea was simple, yet genius, and was inspired by Kay’s background in microbiology.
“Alan Kay imagined software running on a giant, distributed computer (the internet), where individual computers acted like biological cells, operating independently on their own isolated state, and communicating via message passing.”
— Eric Elliott, The Forgotten History of OOP
Breaking code down into ‘objects’ or ‘cells’ meant that you could separate functionality out into separate distinct packages. For example, on a website you might see a video player, the video player itself will be made of objects including the play button and progress bar, and the video will be streamed using a microservice dedicated to streaming video.
This deconstruction of computer code and capabilities made complex systems more understandable, structured, replicable and easier to maintain. Creating objects and services in this way meant that you could reuse hours of work in other projects by reusing the objects and services. It’s exactly the same principle as the atomic design system: produce your assets once and then you’re free to mix, match and reuse those assets over and over.
The Natural Laws of Scaling
So, to grasp the value and importance of microservices, it’s important to understand the basic principles of object-oriented programming. Microservices provide services, like streaming video, as objects through connections called APIs. Atomic design systems are a further evolution of object-oriented thinking, bringing ‘cellular’ thinking to the interface itself.
The common properties of these elements, functions and services is that they are all made up of constituent parts that can be rearranged to create different user interfaces and experiences. We see this in nature, where atoms merge to create molecules, molecules merge to make cells, cells to organisms, organisms to ecosystems, etc. We see nature scale itself with these patterns — single-celled organisms to blue whales; villages to metropolises — and we know that we can scale technological solutions with the same patterns.
So what does this all mean?
It means we have a heuristic, a rule of thumb, to hold our designs to if we want to build systems that scale. It means we can look to nature for some of our most complex problems, and from it we can learn more about how to design systems that are flexible, adaptable and scalable.
When it comes to delivering experiences through software, particularly at the enterprise level, we need to think carefully about our intersecting mediums and how we work with our mediums and tools in order to craft good experiences on the interface. We can use these patterns to build components and frameworks that can transition from one state to another, supporting multiple use cases through a common architectural paradigm.