Seedling Design System
design systems, Product Strategy, Product Design
Background
Greenhouse’s mission is to help every company be great at hiring. Over the years, the product has evolved and expanded through a rebrand and acquisitions. In 2018, Greenhouse grew their design team from two to six designers which prompted a need to create a scalable system which would end up becoming Seedling, Greenhouse’s official design system. The ownership of Seedling eventually transferred to an engineering team called App Tooling, but the design work was still being shared amongst individual designers thus causing friction and miscommunication.
my role
I was hired to be the first design systems designer at Greenhouse and joined the App Tooling team to lead the prioritization and implementation of all design work for Seedling. My responsibilities were to work closely with the designers to understand their use cases and create reusable components and patterns that support the growth of the system. I also worked alongside our Head of Product Design and Engineering Lead to define guidelines, documentation and prioritization of the roadmap.
Establishing a new way of working
When I joined, I learned that the design team had a shared responsibility in identifying components, building it, reviewing it with the design team, and then handing it off to App Tooling. It’s not uncommon that design system work is conducted this way, but I knew that transferring ownership from the design team to me would need a new way of working to improve efficiency and clarity.
I initially spent the first two months interviewing designers and engineers on their experiences with the Seedling processes that exist today.
For designers, their main concerns were to have more visibility on Seedling work while also needing a better way to submit requests and track progress over time.
For engineers, their main concerns were to have more confidence in the parity between what exists in Figma and Storybook.
I developed a new process for how Seedling work would flow from request to completion.
Intake
Requests or issues find their way onto our table in a few different ways: sometimes as a completely new component or replacement for an existing component, other times as an improvement to an existing component. Those requests can come formally or informally, but it was my job to capture, scope and prioritize the task according to need and complexity. I utilized story points to estimate the work based on complexity to improve how long I believe the work would take to complete.Design
The design phase usually starts with conducting an internal and external audit within Figma to understand how this component or other similar components are used. I will often cross-reference my work by looking at other design systems while also diving into any accessibility considerations I need to make. Once I’ve gathered the information, I transition into building out the component within Figma. This process usually goes through cycles of review and revisions with both design and App Tooling team to ensure we are moving in the right direction. Once the component has been built in Figma with the necessary variants and props, it will transition over to our engineers.
Develop
At this point, our Engineering Manager has already tasked a specific engineer to partner with me in the handoff. I have a 1:1 meeting with them to walk through the final component and answer any outstanding questions about functionality and accessibility. The engineer will then build the component and submit reviews via Chromatic so that I can QA the work asynchronously. During this process, we make sure that any accessibility standards are built into the component. Eventually the component will get finalized and merged into Storybook.
Document
While the engineer is working through implementation, I will write necessary design documentation to accompany the release of the component. Currently all design documentation lived within Figma and did not have a consistent format for ease-of-use. I was in the process of standardizing our content and migrating it over to Zeroheight.
Project management
The App Tooling team operated under a Kanban structure within quarters throughout the calendar year, aligning with how the rest of the product organization operates. At the beginning of every quarter, I worked with our design system leads to conduct a retrospective as well as brainstorm new ideas that would eventually become OKRs for the coming quarter. I decided to create a Jira board specifically for Seeding design work that would give visibility to what I’m currently working on and what is in the backlog.
On a daily basis, I would receive requests around needs for new components, guidance for existing components or patterns, or general partnerships to ensure proper design system usage during their projects. Normally those conversations happen via Slack or within our weekly design review meetings. However, I created a format within Jira to give designers the ability to submit a Seedling request that would then funnel into my backlog. This was another format that gave designers flexibility on how they wanted to communicate with me.
Every week, I provided a Seedling update to the design team on my work progress and ask for feedback as needed. When a designer has requested a new component, I will usually pair with them to understand its use case and then determine whether or not it should be integrated into the design system.
Working with engineers
Because the App Tooling team was made up of primarily design systems engineers, I would frequently be exposed to their work and helped answer any design-related questions when needed. I worked every week with Hayden, our Engineering Lead, to estimate and prioritize upcoming Seedling work. When a new component was nearing design completion, I partnered with an engineer to hand off and QA the implementation until its release. In Slack, I would frequently answer design-related questions from our engineers. If any questions warranted a larger discussion with designers, then I would make sure to facilitate and resolve it.
Lessons learned
Just my luck, my role at Greenhouse was unfortunately eliminated due to the company cutting 10% of its workforce. Being only 9 months into the job, I found myself starting to gain momentum and confidence in my role but sadly was unable to see many of the bigger plans through. But as I reflect on my time at Greenhouse, I learned a few valuable lessons in being designer 1 on an existing and semi-mature design system.
Earning trust is active, not passive 🤝
Because I inherited an existing design system, I often made the comparison that I moved into someone else’s house and was told that “it’s all yours, but don’t touch anything”. Coming from a startup where there was zero ownership of the design system, I came into this role wanting to make structural changes without getting the necessary buy-in from my key stakeholders. I learned quickly that any decision for Seedling, big or small, would go through rounds of deliberation, research, analysis and approvals. It took some time for me to understand the value of quality over speed, more importantly that I needed to collaborate more with other designers to ensure that Seedling addresses their needs and not my perception of their needs.
Design systems are products and should be treated like one 🧩
Design systems roles are still relatively new and for Greenhouse, this was the first time they had a dedicated resource for Seedling. Yet when I joined the team, I noticed that we did not have a dedicated PM due to the fact that Seedling work was mostly reactive not proactive. I had experience building a design systems team at my previous startup, so I quickly stepped into project planning and estimation in hopes of minimize as much reactive work as possible. Ultimately, Seedling design work lacked a product roadmap tied to company goals thus making it difficult to prove its long-term value. I know that these are growing pains of any company scaling their design system and my hope was continue to fill that role as much as I could.