Making a system to create a system
When defining how a team gets work done, it’s crucial to be very intentional about every detail. Creating a “design process” can clarify the individual steps, but it can also polarize non-designers and become too prescriptive. A “creation system” brings the whole team together and adapts more fluidly based on environment and output.
What’s the difference?
A design process and a creation system might sound like the same thing. Am I splitting hairs here? Maybe. But I think the distinction is an important one that can have big impacts on how a team adopts a way of working and collaborates over time.
Traditionally, a design process maps out how a team unpacks a problem and finds the right solution to deliver. It can be a linear process or a flow chart with multiple paths forwards and backwards. There are a lot of fans (and haters) of common design processes like Double Diamond or Human-centered design.
Design process is a way of figuring out what you need to do, then doing it. Along the way you might solve one or more problems, try to achieve a goal, and/or create something specific. — Proximity School of Design
A creation system maps out a set of repeatable actions (also known as plays) in a high level strategy that can be reformatted based on inputs and outputs. Inputs include personal expertise, research and even world events or organizational changes. Outputs, or the things a team produces, can vary from changes in an overall user journey to implementing new components in a design system.
In the context of creativity, we can think of a system as the various components that come together to create new ideas and solutions. — Creativity as a system by Kazden Cattapan
My biggest process peeve
{scooting up the soapbox}… From my own experience as a small part of large teams in tech and finance, work does not get done and strategy does not become reality unless all disciplines are included all along the way. Design, Engineering, Product, Agile and whatever else your team might contain all need to be considered and included to make waves.
When designers do design thinking with other designers, the findings often get lost because they fall outside the product roadmap and miss much of what’s possible with the technology.
When a “design system” gets created only in Figma with designers in mind, the major potential benefits escape, and often the system work turns more and more into a side project.
In much the same way, if a design process is created to primarily guide the design discipline, planning becomes a constant point of friction and many benefits are missed. Defining a design process often excludes other disciplines and makes creating space for things like discovery and iteration a constant battle. The design process becomes something separate from coding practices which is separate from product planning methods. Whether intentional or merely inferred from the name, a design process often misses the mark.
How might we define process more holistically to bring together all disciplines? A lot is in a name. Defining a creation system instead of a design process includes the whole team and can result in a flexible process that opens up new ways to collaborate.
The structure-freedom balancing act
Creative problem solving needs the right amount of freedom to explore and structure to stay on track and solve the right problems. In the realm of freedom we iterate, explore and innovate. Iteration requires moderate freedom, and innovation requires a high degree of space to push boundaries. Structure ensures quality in the final pixels, sets expectations around deadlines and makes it possible to measure velocity.
Too much freedom leads to ambiguity which can cause a team or individual to stray. Or worse, teammates stray in opposite directions. Sometimes there are happy accidents in this wandering, but more likely it’s just wandering towards confusion. The right amount of structure can limit wasted time and fuel exploration in a more collaborative environment.
Too much structure causes new ideas to be quickly swept under the rug. When a team is solely focused on meeting deadlines and shipping value as fast as possible, any disruption to the delivery cycle causes anxiety and often complaints from the rest of the team. Even identifying problems can feel daunting knowing the coming stress for the rest of the team.
Improper balance can be harmful to team culture. It can also be harmful to the way a customer experiences a company’s brand. In the first chapter of Emotion by Design, Greg Hoffman unpacks how a hazardous process is felt in brand expression at the end of the day. If process is too rigid, or a team is non-inclusive and over-regulated, the experience of the brand by the consumer is uninspired. The result is a customer that feels no strong connection with a product or service that doesn’t impact in a meaningful way. Fun fact, Greg also has a top notch podcast episode with Design Better. Enjoy!
Structure needs to be complimented by the right amount of space to explore, ideate and discover. This can look something like a dual-track process that constantly plans for both discovery and delivery or regularly scheduled innovation sprints to explore new ideas (similar to Google Sprints).
Down to earth
I’d like to make this all more practical and unpack how my team created our process to guide how multiple teams build components for U.S. Bank’s enterprise design system. Now that we have process defined, this reflection could be helpful to other teams who are setting out to establish their own creation process.
Step 1 — Define goals
Trying to create a guide for multiple teams to follow opens up endless questions. The very first step in defining our process was to define what we were trying to solve (and not solve). Our team’s primary gap was how we created new components for our React library. We wanted to define how all disciplines worked together and the common steps all workstreams should go through to ensure quality and a deeper understanding of how to use what we create.
To collaboratively create this process, we intentionally labeled the work “component creation process”. This helped us share ownership and find opportunities to bring all disciplines in to the outlined steps.
It was also key to write down our goals to guide decision making throughout the journey. We had 4 main goals:
- Velocity — find and treat friction so we can move faster
- Empathy — understand our primary audience and each other more deeply as a team
- Engagement — plan more varying work to inspire teams
- Autonomy — set up teams to self-drive and verify quality
Step 2 — Embrace ambiguity
Our process started out very loosely defined as a co-creation cadence of short loops to align, diverge and converge again. Typically these loops started out short, and grew longer as the process went on. Getting aligned at the kickoff was fairly straightforward, but defining the details and getting aligned took more time as we got closer to shipping a component. Our team went through a few rounds of a less structured process to figure out the common deliverables, milestones and activities we wanted to complete to ensure quality. This was messy, but it helped us define the most important parts.
The structure/freedom balance was out of alignment during this phase. There was too much freedom that led to revisiting past decisions and over analyzing the little things. It was also difficult to understand where work was at and what was required to call it complete. The amount of freedom led to some inspiring ideas, but not enough of those ideas were getting shipped.
Step 3 — Into the weeds!
With a clearer picture of painpoints, deliverables and sequence, we dove in to a few main use cases to plot out the required steps and who was doing each task. This helped build structure, but now there was not enough freedom to pivot or explore when necessary.
Yet again, the structure/freedom balance was not quite right. If the use case changed slightly, the process would need to be reworked. If we were creating an enhancement instead of a new component, things looked drastically different. If questions popped up at the end of the process, the team had no plays other than going backwards in the linear flow.
Step 4 — Guiding framework
With the details more completely understood, the team was able to zoom out and define a dual-track process that could apply at a high level regardless of the inputs and outputs. Stepping out of the weeds, the team agreed we always wanted to spend time on 4 major stages:
- Define — research, audit, run workshops, define our own point of view
- Build — make the design asset, code and documentation and validate everything with the teams that will use our system
- Deliver — publish all that we’ve made and tell people about it
- Party — it’s good to celebrate, and also learn about how to make things better in the future
Because this is a system, it can vary quite a bit. Complexity of the task at hand determines how much time we need to spend on discovery and delivery. If we’re fixing a bug in a component, the amount of time spent on discovery work would be very minimal while most of our time would be spent delivering the change. And on the opposite side of the spectrum, if we’re creating new guidelines that apply to the entire system, there’s a ton of discovery work to truly understand what we create, while actually making the guidance might prove to be a fairly small lift.
Step 5 — Converge, diverge & converge again
With a creation process defined, all that’s left is to apply the new structure in our work. At regular intervals, we’ll gather feedback and refine the high level process or focus in on specific use cases to work through the friction points and iterate over time.
Tactically, our process relies on a close knit team diverging and converging in short loops. We connect, break for heads down work time, and converge again to make sure everyone’s aligned. Diverging is a time of chaos where each teammate iterates, forms a hypothesis and covers ground on their assigned tasks. Coming back together means bringing chaos to order. The documentation outline is compared to the Figma asset which is compared to the coded proof of concept. The structure-freedom balance is tested over time.
The benefits of a healthy system
Onboarding
The beauty of a defined process is that new designers joining the team can quickly onboard and understand where a project is at. If components get put on the back burner so the team can focus on bigger priorities, they can easily pick the work back up with a clear picture of what’s done and what’s remaining. If components change owners, the new owners can get up to speed quicker. And, since we’re all working through the same activities, we can create templates and grow our discovery practice together to hone skills and create strong tools.
Enablement
There are also benefits outside of the design system team. Product teams across our org can see the detailed process we work through when creating our design system. This builds trust in the quality, and it also arms other teams to create their own components in like fashion. Our goal is to enable and not police what others create. As teams go above and beyond to contribute to our design system, this clarity helps them check off more of the boxes so their work can more easily be reused. To rely on maxim, we want to teach our village to fish.
Thanks for reading
I’d love to know what your team’s process looks like, and if you have any feedback for me as there’s always more to learn. What’s working for my team might look very different than what works for yours. Nothing I’ve shared is perfect or done, and my goal is to always improve. Thanks!
