The ABCD of Systems Thinking

A simple guide for design system teams.

By Carlos Yllobre Aleman, Senior Product Designer, Workday

This is the second in a series of articles about design systems thinking. Read Part 1 here.

The first time I heard about systems thinking was back in 2017 when my team and I started building a more complex library of components to serve developers when they updated our product. That first attempt would evolve into what we know today as a design system, but the real change didn’t come with the outcome. Instead, it came with the learning path that opened a door to a new and more rational way of approaching problems with many touchpoints in common with other methodologies, like design thinking.

With the arrival and evolution of design systems, we discovered a new way of approaching business, engineering, and design problems. Before I talk about the how, let’s talk about the what.

What Is a System?

A system is a group of interrelated parts that work together to perform multiple basic or complex functions. It is precisely this connection and interaction of the parts that makes a system work and form a single unit or entity. This simple and beautiful idea is present in many shapes and with a rich variety of purposes, from natural to artificial constructions. We can wonder about the Great Barrier Reef in Australia or learn more about the behavior of financial systems and the markets across the world using systems. We live, think, and work in systems; they are the result of complex natural processes and our capacity to understand and recreate them.

The interesting part is that this simple concept of small units interacting with each other can be applied to the way we think, organize our lives, or face new projects and challenges. This problem-solving approach can take multiple shapes based on the type of system and problem that is meant to be solved. I like to use a (simplified) scheme that explains one of the system thinking approaches when it comes to building or reorganizing system structures. Let’s learn the alphabet!

A is for Audit

This point comes with 2 parts: the first one is about understanding and defining the system, while the second one is about identifying its problems. Curiosity is a powerful tool at this stage, and I invite you to use it!

1. Defining the System

Having a map of the existing components or pieces will serve multiple purposes along the way, but the primary one is to unify our language, naming conventions, and structure, as well as to always have a source of truth across our sources that serves as a reference point when it comes to organizing, modifying, and updating our system.

We start by learning the basics about a system and identifying and defining the tiny pieces of data. The first questions are about the basic parts of the system: What are the pieces? How do they behave? How many do we have/need? How many types do we have or need?

Once we have answered these questions, we move on to other questions about the whole: How does the system work? What patterns does it follow? What results is it producing?

We can’t jump ahead and try to identify the problems or run an inventory of the things we need to fix without knowing where and what we need to look for first — that’s why this first step is key.

2. Identifying the issues

In this step, we need to identify the issues affecting the system, the areas of improvement, and the broken links in the chain. I like to think of this process as a layer we add to our map where we mark our points of interest. These could be issues or problems impacting the system or areas of improvement.

By adding this layer, we are in a better position to create a backlog of tasks we can classify based on the level of complexity, the effort involved, etc.

B is for Building

3. Planning

Producing without planning is a rookie mistake. We don’t produce to tick boxes and mark Jira tickets as done; we produce to tackle the issues or areas of improvements identified in the previous 2 steps, and all this falls under a systematic view of what building stands for: building our system or product.

Planning before producing will provide us with a unified building process that can escalate and be shared across teams and individuals. Things like the necessary steps, the desirable outcome, and quality metrics can help us avoid generating more tech debt once we move to the production phase.

4. Production

Production doesn’t equal release and implementation. It represents the phase where the core work is done and provides us with measurable results. These results need to be reviewed using the quality metrics we defined in the planning phase, and this can be translated into multiple iteration cycles happening between Step 3 and 4.

C is for Communication

Communication is an overused concept but a powerful one. People talk about how everything is sorted with communication, but like everything, for this to work you need to put certain metrics in place: when and where to communicate, what type of communication, what amount, and what type of information is shared and received. To simplify, when working on a system it is good to define 2 types of communication.

5. Internal Communication

Communication happening within the team or group of people responsible for performing the core work about building the system. It is important to mention that this doesn’t happen at a specific point in the systems thinking process, but in parallel with the whole process, focusing mainly on points A and B.

6. External Communication

Communication happening outside the core team responsible for building the system. It is important we build and maintain clear communication channels with key stakeholders but also with our end users. These 2 communication channels take major relevance in the latest stages of the process.

D is for Deployment

The deployment phase is where the core work finished in the building phase gets to see the light as a product. This point consists of 2 main steps.

7.QA

Quality assurance is the process to assure that the outcome of our work fits the defined use or purpose. When building and optimizing systems, it is critical to build a well defined QA process. This is the last filter before releasing any modifications to the parts or the whole of the system.

8. Release & Documentation

And we arrive at the last step of the process. I like to include documentation here since I believe every release must be accompanied with a summary of the whole process, a description of the release itself, and other important information covered by default in any versioning exercise.

Summing up

Systems thinking doesn’t differ too much from design thinking or other problem-solving methodologies. All of these can be used in multiple iterative cycles with similar steps, recycling themselves accordingly with the project. The main difference and where the value of systems thinking lives is in understanding the parts as a whole and translating this idea into a process where every step is linked to the previous and further ones, and the sum of all to a successful framework.

Thank you for reading! 😊