Design Systems and Agile
Agile is everywhere. Almost every organization promotes how agile they are — meaning they take an iterative approach to project management through a product’s lifecycle promising more streamlined delivery and fewer headaches. I’m sorry to break it to you if you haven’t heard this before, but the reality is most organizations run waterfall under the guise of agile.
Here’s a quick refresher for everyone on the core tenants of agile:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
How many times have you been in a conversation at your organization and someone asks for help standing up a process or new tool for delivering on work that isn’t even known yet? What about creating exhaustive documentation before something is built? How about sticking to a quarterly plan so everyone can get their bonuses over uprooting that plan to solve a true customer need? None of this is agile.
We’ve all been there and it’s time to take a step back and look at how we create products with an agile approach as you can’t innovate on products without innovating how you create them — bottlenecks within a team are not the path forward. We aren’t going to focus on how to fix your ‘agile’ organization but will cover how a design system can help your organization become more agile.
Let’s Talk Goals
A design system aims to reduce the number of routine design decisions one must make to focus on complex problems facing end users.
Agile aims to quickly deliver an end user incremental value through frequent releases — and quickly respond to feedback.
These two goals have a lot in common with the most powerful being the ability to quickly adapt to your user’s needs. You may be asking how a design system enables this, so let’s dive in.
MVP Theory
I’m sure we’ve all seen the diagram pictured below where your organization is trying to solve a user’s need of getting from point A to B. You first give a user a skateboard as their MVP mode of wheeled transportation. You then upgrade them to a scooter with handlebars for steering and stability (I’m sorry for your shins), then a bike for speed, a motorcycle for even more speed, and finally a car for maximum speed and leisure. All of these modes of transportation deliver the user incremental transportation value, but the skateboard is the fastest item to build that delivers a solution to get from A to B (aka the MVP). If you want to look into how not to build MVPs countless examples are floating around the internet.
So why spend the time describing how to define an MVP?
The issue with the above diagram is in the sourcing of goods to build the said item. No one ever discusses that when thinking about this theory.
Think of a design system as the warehouse of parts used to create the skateboard, scooter, bike, motorcycle, and car. You are establishing your infrastructure to deliver value to users. The number zero in the above example is your design system infrastructure. Without the warehouse, you have an idea, not a product.
Design systems prevent your team from spending a considerable amount of time thinking about how to create an experience through wireframes when they can build one from an existing library of components. You get to your MVP version within a matter of hours as opposed to days, weeks, or months.
Individuals and interactions
Processes and tools are often thought of as necessary to gain interactions with individuals on a cross-functional team. More often than not, they function as a scapegoat behind friction points inside a team. ‘An old mockup was in Zeplin,’ or, ‘there was a broken dependency in the production design file so the wrong version was built’…the list goes on.
Yes, a design system is a tool. It’s a tool that encourages forward movement to quickly meet the user’s needs of an organization. Cutting back on the number of tools required for individuals on a cross-functional team to interact effectively is crucial. More time can be spent discussing a solution brought forward in a design system by removing the overhead of process-driven tasks such as uploading mockups to Zeplin or Jira from Figma.
It may be scary, but the process comes from individuals interacting on a team through foundational elements. A design system is a foundational element.
Working software over comprehensive documentation
Design systems provide a huge lift in not only empowering teams to deliver working software faster but also providing extensive documentation when leveraged correctly. Taking action in Figma allows a cross-functional team to log versions of a component or design and revert changes if needed. Designers will no longer spend time with PMs scratching their heads on when a change occurred or when a certain instance of the design was published for the engineering team to build.
If your team is very advanced, you’ll have a design system manager that logs not only the design changes but relevant code too. Your team documentation is created as the team delivers value to the user, not as a before or afterthought.
Collaboration
Collaboration is most effective when a team has a common language to leverage. A design system should function in this common language. Teams will focus less on who brings forward the best idea for a new form, but more on how to structure a form for optimal performance. Collaboration is enhanced by empowering teams with the necessary knowledge for what can be delivered within a cohesive experience by removing the need to explain why a design field looks a certain way, or what different states of a component are. The more comfortable a team is within a language, the more collaboration your team will participate in.
Responding to change
Design systems aim to free up time to listen, learn, and solve problems facing your users. Part of the listening and learning process is to promote change to a product based on what you’ve heard.
This change can take time if your design team needs to reimagine an aspect of an experience — take a modal for example. If this modal needs to change from a content block to form fields, a design system leveraging slot components enables designers to create this new modal version in very little time. This new version is not only quickly created, but it’s also WCAG compliant, responsive, and in alignment with all other designs.
A team’s time can be focused on addressing the change needed, not how to create the design elements required to meet a change.
Design Systems and Agile
A design system should be thought of as table stakes for product delivery inside of cross-functional teams as they are integral to moving towards agile’s core tenants and away from waterfall or pixel pushing.
Cross-functional teams should be focusing on improving the overall experience of a product through hard problem-solving. Using an advanced design system, such as Orchestra, enables mundane tasks, such as establishing and aligning on form basics, to become an after-thought as they’re readily available from the start. Now let’s get building!
