Providing the basic building blocks helps teams complete work faster and with greater consistency. And that’s great! But if an organization’s core problems are deeper than an efficiency boost, it might only be a bandaid to a broken bone. How might we diagnose and treat the real problem?
Don’t get me wrong, efficiency is great
If you’re reading this article about design systems, I’m going to assume you understand the effects and impacts of consistent experiences. If not, you can learn about the benefits of systems here.
If the root problem is consistency and efficiency, then the creation and adoption of a quality system will do the trick. But that’s often not the case. Deeper problems might become evident over time. When does wild chaos break out? Is work duplicated? Or even worse, are multiple solutions created in silos that aren’t even considered for reuse?
Design systems should aim to solve deeper problems for their organizations, because they can.
Bad types of chaos can bewilder design system makers. To this breed of designers and developers, reuse and systematic approaches are the knee-jerk reaction (dare I say, calling) and it’s easy to forget that reuse is not the main thing for everyone. How can we approach situations that require more than another release?
A healer’s mindset
Teams that work to create tools and reusable components for internal use really exist to solve internal problems. Approaching this mission with a healer’s mindset means treating discomfort while also working to understand the root cause of symptoms. We need to build trust with teams to get a clear, honest picture of their pain. When systems thinking is coupled with a healer’s mindset, we can really start improve lives.
First, diagnose 🩺
Like any good healer, we need to seek first to understand before we can begin to treat the underlying problem. Building understanding takes time and needs to be the first step in any good product process. Give the necessary priority, time and energy to do the discovery work and also spread learnings across the whole team. We need to understand and then figure out what tools would help set teams up for success in the market.
There are many approaches to build up understanding. Many organizations make their own frameworks (IBM’s enterprise design thinking for example), which is a testament to how crucial it is to clearly define the problem. Some would even say defining the problem is the hardest part. Looking at you, Einstein. All types of design research and customer study can uncover insights that include, but are not limited to, what hurts and why. The team will also get to learn about what is working and the balance of values in the mind of the system adopters and end customers. All of this is pure gold and serves to guide treatment.
“If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.”
— Albert Einstein
Second, treat ❤️🩹
Treatment can only be effective when guided by deep knowledge of the problem. Once we understand the problem, we can create a treatment plan. The proper treatment for a broken-bone issue might be less about component updates and more about fixing process, clarifying governance and building bridges with more teams during component creation.
Sometimes, justifying this type of work is difficult because it is not the expected norm. New and enhanced components are easy to quantify and prioritize. More conceptual projects can be harder to understand. Creating a strong plan that’s built on a deeper problem will help the team build the case and get the green light to do the work. If alignment is a struggle, fall back on the problem definition to paint a clear picture of the need.
Even if buy-in is not an issue, a strong plan will help keep the team on track and operating together on the same problem. Throughout the work of treating the problem, it’s crucial to stay focused. Other priorities will arise, and a clear problem definition will help level set what’s most important.
Third, follow up 🤝
The problems we take on in large organizations multiply and get more complex. Even when a problem is ‘fixed’, attrition and hiring cycles mean our practices might easily repeat historical patterns. Even if the people don’t change, old habits do indeed die hard. Priorities change. Acquisitions happen. Any number of factors can change over time and cause old problems to flare up or new problems to intensify.
Follow up care is the practice of monitoring trends against our desired outcomes. If we’re tackling usage of our components, we might watch the metrics to make sure more instances are happening and active projects in the repos are composed largely of design system components. Surveys and less formal conversations will keep the team tuned in to how things are going. It’s not enough to ‘solve’ problems and move on. We need to have continuous checkups to make sure health continues to improve. If it doesn’t improve, it’s time to head back to steps 1 and 2.
Application
Let’s pretend we’re in an organization that has a strong system owned by a centralized design system team. They release regular updates, prioritize components whenever possible, but do spend about half their time on maintenance and updates to keep pace with technology.
The team can’t keep pace with all the new components product teams need month to month. And that’s fine. Teams have been directed to create missing pieces and more complex components on top of the design system. But every time teams try to build new components, they go down a path of creating totally custom things that aren’t shared. Often, it becomes obvious that 2 or 3 teams were working on the same problem at the same time and landed in 2 or 3 different places. Occasionally, teams try to propose contributions to the design system, but as soon as requirement gathering starts, it becomes clear that a lack of consistency will make system intake difficult and adoption hazardous.
Diagnose
The design system team decides to address the problem head-on and take ownership. They run a series of interviews with product teams and find out that teams would take a different approach if they could, but they lack the time and aren’t sure where to even start. They also don’t have the time to keep up with what other teams are working on.
Treat
The system team begins to unpack what they learned and what they can do about it. They decide to focus on the teams who do want to do better and potentially contribute. They can’t magically give teams more time to spend on making components for the greater good, but they can own how much time it takes to make reusably and contribute. They take their definitions of done, governance process and templates and simplify them for general use and put them in the hands of potential contributing teams.
The leaders within the systems team also begin working with other leaders to build stronger bridges so work can be done more out in the open. They propose an office hours environment to bring together peers from different silos to spread visibility and best practices.
But the tools are nothing without proper training. So the team also spends some time teaching the community how to use the tools and how to think about setting up reusable things. Contributions begin in a new way and everyone’s feeling optimistic. Isn’t that nice?
Follow up
But it doesn’t stay nice (what kind of story would that be?). Contributions fizzle out and reuse isn’t there. Teams pick up the tools, use them, and then the work dies on the vine. Again, the team needs to take a diagnostic approach to figure out the problem. It’s back to step 1. The best way to address workflow is to make iterative changes with quick feedback loops. Observe what happens and adjust.
The team runs another series of interviews that are more targeted this time. They talk to the folks using the tools and find a number of friction points. The guidance is too complex and the requirements are still too rigorous. A lot of the language is written by systems designers for systems designers at the detriment of the community at large. Also, the publishing process isn’t clearly spelled out. These are all issues the design system team can own and work through.
Follow up care has brought additional, solve-able problems to light. The team can repeat the whole process any time trends don’t match desired outcomes.
Find the deeper cause
Throughout the process of diagnose, treat and follow up, problem definition is the key. Design system practitioners often love to dig in to the making and the details, but this energy is wasted unless connected to the biggest problems their organizations are facing. If there’s a disconnect, the system will just be a bandaid. Adoption will fizzle and chaos will never end. Always start by building a strong problem definition, and continue this work along the way.
Are design systems just a bandaid? was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
