Accelerating New Design System Components Through Collaboration

1. No More Single Drivers

In previous workflows, we would task a single developer to engage with design once design began to approach “complete.” This was a major slowdown in two specific areas:

1. Designers weren’t aware of what development could bring to the table, so solutions worked on for sprints would be missing critical context
2. Our developers were fantastic - but we all had our strengths and additional responsibilities. A single developers’s viewpoint and experience in these early stages was overtly impactful to the work that moved forward.

To solve these issues, I promoted and shifted our team to a new workflow where engineering was involved from day one with design to share viewpoints and capabilities of the platform. This experimentation would result in a checkpoint with both the design and engineering leads before moving forward.

This early discovery with design and development resulted in a natural inclination of sharing work, gathering feedback, and providing updates before the official checkpoint.

Now we were moving forward in a collaborative, prototype-focused discovery that allowed design and development to align quickly and with less learnings stuck within a silo.

2. Planning To Share

One issue we ran into was depending on which developer picked up the project, we weren’t always getting the most out of the codebase as we could for other teams to use. We may be up against timelines, people get distracted by meetings, your team get’s reorged in the middle of an effort - this isn’t me blaming or criticizing the engineers who did the work.

Things happen.

Rather than leave the “did we get what we could out of this” discussion for later on in our code reviews, we utilized our learning in the prototype and discovery phases to understand what will be helpful to extend outside of our components and what should stay focused on our work.

This means we would now be able to consistently discover items such as logic to export as hooks for other developers and plan shared styles and new tokens to expand our design system’s foundations.

This also gave us a head start on code reviews. Code reviews now became more consistent as this approach shifted the discussion to “did we deliver what we meant to, in the way that we want to, and what did we learn by doing it this way.” Also avoiding any re-engineering to squeeze more out of the code, allowing us to ship more consistently once we’ve hit the review process.

3. Structured and Clear Backlogs

With this new approach to planning, we were also able to better delegate the work to others.

My charge to our engineers was that smaller the card, the better you can demonstrate you understand the work. Yes, this results in more cards that the dev or lead has to write, but I’d rather pay that up front in a near pre-mortem thought process rather than pay the price of missing pieces while work is in-flight.

This shift to planning, looking to extend where we can, and writing smaller tasks in a way that others can pick up came with many knock-on effects, too:

1. More visibility of our work for leaders, stakeholders, and consumers
2. Specialists can pick up the work they’re great at
3. Education moments were easier to discover on real work
4. Less blocked work or stagnant devs with this kanban like backlog approach
5. A more true look into velocity and “points”
6. Easier discovery of conversations and past artifacts
7. Never having to answer “what are the design system devs even working on” ever again

4. Staged Releases and Early Community Feedback

The largest impact to our work in accelerating the delivery of components while maintaining quality and stability was our integration of pre-release workflows.

Before this work, we relied on internal testing and “screen-share” moments externally to get feedback on our work. We also had to support direct contributors aligned with our needs, such as an accessibility specialist, to run our systems on their own machine. Something they weren’t trained for nor do I want them to have to worry about.

To solve the needs for earlier community engagement, gathering feedback and bug reports before release, and allowing our partners to focus on their skillset, I drove our team to enable a pre-release workflow.

Our environment at the time was limited so we had to roll some of this by hand, but planned to jump this into a GitHub Actions and Jenkins supported pipeline.

What we landed on was a set of releases that are relatively standard in our industry, but our team was lacking. Each of these was planned for specific testing and various levels of access: