Breaking Down Systems

January 2, 2017 •  design

When Donald Trump became the president-elect and I spent the following weeks reading about how we got here, I thought about a book I read last year. “The Systems Bible” by John Gall[1] has been pivotal in how I look at complex problems, or, what he calls systems.

The book details the theory behind small and large systems and how they display “system antics,” which was a very fun way to describe what we would likely call “unexpected behaviour.”


THE UNIVERSE IS LIKE A VERY LARGE SYSTEM

We like to build systems. This is true of every culture on earth. Democracy is a system. Local governments are systems. Garbage collection is a system. Banks are systems. All of these things are components of the much larger system, the universe. You get the point. We build systems to help us deal with problems in hopes that the system will then solve it for us.

There are many fundamental theorems worth reading about in the book, but I’ll defer to it to explain them all to you. The important takeaway is within the first ten pages,

SYSTEMS IN GENERAL WORK POORLY OR NOT AT ALL.

Horrible examples can be found throughout the book, although I have compiled some here from the appendix to better illustrate the ideas:

Mental retardation research project produces mental retardation in retardation researcher.

An austerity budget, proposed and implemented by a Conversative administration, results in the largest deficits in U.S. history.

Nuclear Power Plants produce electricity for thirty to fifth years, radioactive poisons for five hundred thousand years.

African nation builds medical school and hospital, now has no money for health care.

How are you supposed to take this?

Reading this book is an exercise in patience as the book itself is, ironically, a complex system of rules. It’s mission as stated in the beginning is to avoid approaching a system without being aware,

Our purpose is to help the Systems-student to minimize such experiences; to become aware of the many opportunities of incurring such a shock; and to be mentally prepared, so that the shock will at least not be unexpected.

For any Designer who wants to spend time working in a large complex system, they must be aware that every system will inevitably fail. We all can’t create To Do list apps.

How do I apply this information?

After a couple of years in observing people build products, people manage people who build products, and people build systems which build products, I have come to the conclusion: every Designer’s job must be to dismantle the system.

The thing is, humans aren’t naturally very good at this. Psychologically, we have brain curtains which come down when things aren’t working. Hence, we have to develop design thinking but that term is abstract and ill-defined. I’ve put together a couple of examples of how this type of thinking plays out in real life:

Building apps

Most applications and websites are a small-large exercise in information management. Junior Designers think in terms of user flows, which is actually more of a side effect of good information management. This is a fairly simplistic summary, but I’ve applied this to an example of a food delivery app:

  1. What information: Cuisine, Restaurant, Menu, Prices, Item Description, Food options, payment
  2. Type of information: Read (restaurant, menu, prices, item description), Write (cuisine, food options, payment)
  3. In What Order: cuisine, restaurant, menu, item description, price, food options, payment OR payment, cuisine, restaurant, menu, item description, price, food options

These three questions set up a strong hypothesis for what the user flows should look like.

Developing career goals

Once a job turns into a career, one of a manager’s core responsibilities is to ensure that their reports are happy with the trajectory of their career. Look at education as a system.

Identify the components of the idealized knowledge base. Find educational courses to teach theory and opportunities to practice application. Add frequent checkpoints to course correct to avoid overall system malfunctions. Do deep-dives twice a year just in case the checkpoints don’t catch everything.

Managing efficient teams

Companies typically start with a small group of people. At the beginning, every person will have a specific job. They will all be building the thing. As the organization grows, another layer is required to help manage the people building the thing. This continues perpetually, until the majority of the people are not building the thing.

To help manage the complexities of this system, break down the size of teams, eliminate dependencies, encourage ownership, and give the power of decision-making to each team member.

The rules of dismantling

  1. ACKNOWLEDGE THAT THE SYSTEM WILL PERPETUALLY GROW UNTIL DISMANTLED
  2. IDENTIFY WHERE THE SYSTEM BREAKS
  3. BREAK THE SYSTEM INTO COMPONENTS
  4. ELIMINATE THE COMPONENTS OF THE SYSTEM WHICH DO NOT NEED TO EXIST
  5. DESIGN SIMPLER PROCESSES FOR ANY LEFTOVER COMPONENTS

You won’t get perfection, which is what user testing will tell you inevitably, but you can get closer with each step.


↩︎ [1] John Gall, The Systems Bible↗︎, 1925

Recent

Mailing List

Join the Mailing List and I’ll let you know when I publish something new. You can also use my Rss Feed or catch the most popular on Medium.