A year ago, my manager at Segment broke the news that I wasn’t meeting expectations as a Product Designer — a tough thing to swallow. In my performance review he told me I was neglecting my product work and team more than I should.
Why? I was too busy coding up new components for our React UI Library and meticulously crafting templates in Sketch, secretly readying Segment for a killer design system. As that conversation showed me, having the initiative to build one does not necessarily mean your company wants you to work on one.
I had been at Segment, a large customer data platform, for six months before that reality check. My goal from my hiring date was to redefine how Segment designs and builds products. As a designer, I knew the company was ready for a design system, but getting others on board was harder than I expected.
After that performance review, my goal shifted from building the design system to conveying the value it could provide to Segment. In the end I succeeded by hijacking a project to show the value, rather than tell it.
Deadline in sight — our first user conference
Soon after that conversation with my manager, I switched over to the Personas project team, who were designing a new product that helped drive personalization with better audiencing capabilities.
The company wanted to announce this product at our first ever user conference, with only 3 months of lead time to prepare. The idea was that our CEO and Head of Product would demo it on stage.
At that point we had only built a way to see user profiles and were still exploring options and validating solutions for the audience options. There was no way we could finish a fully-baked consumer-facing product in time. We were pivoting too often based on customer feedback.
Seize the opportunity
It seemed like an impossible deadline. Then it hit me: We could build a design system to power the on-stage demo. By creating the core design components in React code, we could experiment rapidly with the user flows for Personas. Because React would generate an interactive prototype for the demo, we wouldn’t have to take extra steps to turn final designs into production-ready code.
My primitive React UI framework (named Evergreen), served as the base of the design system and allowed me to quickly build out web layouts. For example, all buttons and form controls worked with any height I gave them — the spacing and text styles adjusted on the fly to accommodate the height. Not having to define every requirement and constraints up front saved me an immense amount of time—the components would simply adapt to my use cases.
I tested components with real constraints in the prototype. When the components took shape I added them to Evergreen and, because the project was open-source, it gave me a sense of accountability. This in turn improved the consistency of the design and code.
I was crunching away on the prototype and Evergreen at the same as we were working on the demo script and on-stage demo. Having the prototype available and easily shareable made it easier for the team as we practiced and fine-tuned the script. It was a great time at Segment; you could see the team and company grow closer while readying for launch.
The user conference was a hit
After countless iterations of the demo script and test runs with the team, we finally had something that felt polished and compelling. Our CEO and Head of Product did an amazing job presenting the product demo onstage while I was upstairs in the tech booth controlling the prototype.
The company’s first exclusive user conference turned out to be a huge success and the perfect way to announce our Personas product. We celebrated by going to Benihana where the sake and speeches flowed. Joe, a designer I had worked with on Personas, gave me a shout-out about how I had begun building out the company’s design system while simultaneously creating the demo. I felt proud that night; my teammates had validated my efforts and my hard work had paid off.
While we’d announced Personas, it was only in the early access stage. There was more product exploration to be done, while simultaneously building and maintaining the design system. Soon after the user conference we hired our first head of design. I pitched him the idea of continuing the work of Evergreen and he agreed that it was a no brainer. In fact, Evergreen quickly became one of his favorite words at Segment. ;)
Still, there were some concerns from our e-team: if we were going to actually go for this, then it shouldn’t be my side-hustle. With the head of design backing me up, I demonstrated how having a design system could help our product team rapidly iterate to reach product market fit using the Personas demo as an example. The proof was clear, so they agreed I should work on the design system full-time.
Fast forward to today
It’s been a year since my negative performance review with my manager. Things have changed — now we are putting together a team dedicated to Evergreen.
Building a design system is not about reaching a single point in time. It’s an ongoing process of learning, building, evangelizing and driving adoption in your organization.
If you can demonstrate how a design system can improve a specific project, you’ll have a better chance of getting your company ready for one. Sometimes a gentle nudge in the right direction, vis-à-vis a designer hijacking a project, is all your leadership really needs to get onboard.
Do you have stories to share about creating a design system? Maybe you’re interested in being interviewed or writing for our next issue? Email a two-sentence pitch to firstname.lastname@example.org — we’d love to hear from you.