Introducing design hierarchies – moving from design systems to designing systems.

I was reflecting recently on how the nature of the things I’ve worked on over the years has changed dramatically in scale.

Much of my early work focussed on designing digital interfaces, typically web pages in wireframe form, focussing on content and functionality and whether people understood what I was trying to communicate within them.

This work then changed to designing entire digital things like websites or web applications that enabled people to do specific things. They were far more complicated but interesting because I often found myself inventing new businesses, products and services that were allowing people to do things in ways that hadn’t been done before.

The work then changed again to start thinking about we could make it easier for people to do complex things like plan holidays or buy complex financial products that involved both digital and non-digital components. 

More recently my work has moved from helping to design and improve services to thinking about how complex systems like the healthcare system can be improved.

It struck me that over the years I’ve been moving up some sort of hierarchy, slowly zooming out from working on discrete things to hugely complex systems. 

I’m thinking about is as a ‘design hierarchy’ (after discovering ‘ecological hierarchies’ after seeing parallels with hierarchy of complexity within natural systems) and am picturing it like this:

An example of a design hierarchy showing how impact and complexity increases as the nature of what you are designing increases in scale.

Thinking about it in this way this could represent an extension of Brad Frost’s Atomic Design work that uses its own natural metaphor to frame work within its own hierarchy (atoms, molecules, organisms, templates, pages) that sits firmly at the bottom left of this diagram.

I’ve realised that we have been slowly zooming out, shifting our focus from ‘design systems’ to ‘designing systems’.

It’s interesting to note how each level of the hierarchy exists within the one above it. This idea resonated with me after seeing this quote recently from Eliel Saarinen:

“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.”

As you move up the design hierarchy, the things you work rapidly increase in complexity, scale and the number of people they impact upon. 

The nature of the problems you are working on change exponentially from ‘what’s the most effective label for this button?’ to ‘why aren’t people attending their GP appointments?’ and ‘how can our organisation become more customer focussed?’ 

As a designer this can be quite daunting, resulting in vertigo induced imposter syndrome and leaving you wondering how the hell you ended up working on this stuff and how to handle the sheer complexity and size of the problems within it!

I’ve found that wherever you are working on this design hierarchy the classic user centred design process still works brilliantly. Whatever you are working on, start with trying to learn as much about the problem as possible from the perspective of the user before you begin to identify, prototype and test potential solutions with them.