Process for growing Seedling into an internal product
Background
This was not the first time we had attempted to make a component library. At one point, we even had a dedicated engineer to build one. This first version was a great start, but lacked ownership, organization, and scalability to allow the project to really thrive. And, on top of that, our newer product teams were unable to use the components themselves, leading them to build their own versions and throw consistency by the wayside. Our application was growing in complexity, which was making it harder for design to have a point of view, engineers to build things quickly, and our customers to understand how our application works.
In 2018, after growing our design team from two to six designers, we realized we needed to get organized. A few engineers also expressed interest in fixing our process and creating a scalable system that can work for both design and engineering. We decided to create an internal task force for creating our official component library, Seedling.
The Taskforce
Seedling started out as a small group of eager members all with different viewpoints on what a component library should be. We spent a lot of time talking. We talked about our dreams and created a long list of goals that we didn’t feel able to accomplish.
It included:
- defining what it means to be a component
- migrating components into their own repo
- creating a beautiful designed external facing website
- setting rules for our system with definitions and statuses
- updating outdated design styles
- auditing old features and find things to componentize
- creating a playground to build things quickly
- setting statuses on features that are in purgatory state
and the list went on and on…
In each task force meeting, would continue to add to the list of tasks, but never crossed anything off.
Getting Organized
It was really important for us to get together and talk in circles and spin our wheels — it helped align us all to what we wanted Seedling to be in the long term. We realized that Seedling was simply a product for our internal product team, and if we mimicked our team organization and product cycle, maybe we’d finally start making the headway we were looking for.
The First Goal
After talking about our grand vision, it was important to ground ourselves in an attainable goal. We all agreed that our first instance of Seedling should be to:
Migrate all of the existing components from the old library into Seedling.
What this meant:
- We will audit our current components and move those that qualify into the new repo
- We will set rules on how to use these components
- We will make it easier for all products to use the components
- We will use storybook, a 3rd party tool to host stories of each component for internal use
What this didn’t mean:
- We will not go back and update all instances of the component
- We will not make large sweeping changes to our current design system
- We will not make an external facing website
To begin this work, the design team started by auditing the entire existing library to figure out what we needed to migrate, and how that could be organized in Seedling.
We then began to organize ourselves — who would meet, how often, what would we talk about, what would happen next.
The Meeting Lineup
- The Main Event: a 45-minute long meeting, every-other-week, to talk about strategy and progress.
- Design time: on the off-weeks, the design team met to talk about how we wanted the external site to look, what our rules and design patterns were, and what larger-vision work we could focus on next.
- Standup: a quick meeting every-other-week, allowing us to have face-time with each other and accountability to Seedling to keep the work moving.
The Technical Stuff
- Jira Epics: a Seedling Jira epic was created to dual-track along with our corresponding product team. It allowed engineers to prioritize the Seedling work alongside their own product work, as well as follow the normal process to track and deploy cards.
- Jira cards: a card was made for migrating each new component to Seedling.
- Checklist: within each Jira card, we added a checklist containing the steps to be taken to complete the task. If an engineer picked up a card, they became the owner of that component and it was their job to investigate the work involved, sync with the designer assigned to the component, and break it down into manageable tasks.
Next Steps
Our process has not been perfect but once we realized that we didn’t need to reinvent the wheel, and could follow a normal product cycle, things became a lot more clear. We have come a long way to get Seedling off the ground and accomplish our first goal. It’s exciting to see the progress and how the team is starting to adopt usage.
We couldn’t have done this without a few important articles and inspiration from our fellow designers and engineers
http://bradfrost.com/blog/post/atomic-web-design/
https://www.carbondesignsystem.com/
https://primer.style/components
And last and most important, thanks to all the members of seedling task force. We couldn’t have gotten this far without you all. It’s amazing to be a part of a team of dedicated members for a self-organized and voluntary project.
Learn more about what a component library is and why we built it. Seedling: Planting Components for Later.
Interested in working on projects like this? We’re hiring.
