The early years of GRIN were marked by rapid growth and development. In its aftermath, we left a pile of technical and design debt that was difficult to unwravel due to lack of documentation and consistency in our design system. After years of getting by with a broken system, we finally paid our debts with Spark, GRIN's new design system.
￩ Back to ProjectsI was the primary designer driving this effort on my team. I rang the alarm on how big of a problem this was becoming and rallied our Spark team (made up of me and a few devs who were eager to solve the problems engineers faced with our current component library). With the support of my design team, we were able to get moving on standing up a new system. To summarize a year-long effort, we finally have a solid library of components built for Spark and a few features fully developed using the new library! Though not yet a fully realized design system, this major milestone has set us up resolve many communication & UI issues we saw in our platform.
Before Spark, one of the most difficult parts of development was handoff. Everything from component names to colors were mismatched between design & development. We had no process to keep updates in check, and the app was riddled with hardcoded colors and components. There was little technical documentation of components, and Design's library didn't match up with what was actually in code. I set out to ensure that between design + dev libraries: components were structured similarly, components shared the same names, and foundational elements like colors and spacing were in sync to create a shared language we could all align on.
31 components
built and documented in Storybook
4 major features
implemented in Spark
Active usage across
4 development pods
Also known as auditing! Standing up a brand new design system is a huge effort. Before tackling anything in earnest, I performed several audits to identify the biggest gaps in our current system. What components and patterns existed today that we'd need to have parity on? What didn't we need to carry forward? What should be revamped in our new system?
In an ideal world, we could all build our component libraries from scratch and it would do everything we needed it to. But realistically, the best path for our team was to customize an existing open-source library. After much consideration (and a migration to React to consider) we decided on Chakra UI for its customizability and breadth of components.
Redesigning the library included reskinning Chakra components to look like GRIN, rebuilding existing components that we needed but Chakra didn't provide, and laying foundations such as color variables, type styles, borders, and shadows.
Our team was strapped for resources and we couldn't justify only building components for the sake of Spark development. After much strategizing with our product and engineering leads, we decided Spark development would have to align with the product roadmap. There were pros and cons to this strategy, but in the end I believe that this decision led to a more realistic and pragmatic approach to releasing V1 of Spark.
Our first Spark components were built for a brand new GRIN feature, Curated Lists, a white glove service we offered where our experts handpicked creators for customers to recruit into their influencer marketing programs.
Research and discovery of this project was led by a mix of designers, myself included, across various phases of the project. However, I was involved in every part of the Spark development process, making sure components were used correctly and consistently, and documenting usage and patterns as design continued. Here's a peek at what our first implementation of Spark looks like!
Requests dashboard: This is where users access their Curated Lists and track pending requests.
Request form: Every 2 weeks, users are able to make another request for a Curated List through the request form.
Curated List: Once a Curated List of creators is delivered to the user, they can access it and start evaluating them for brand fit. They'll then promote creators as prospects or disqualify them from their program.
Creator insights drawer: To aid users in the creator evaluation process, we designed an insights drawer that provided valuable performance and audience metrics. With the insights drawer, users are armed with as much information as possible to make a decision on whether or not they should promote the creator.
Documentation technically isn't a "step", but we now have a fully functioning design library in Figma, as well as developed components in Storybook that match our designed components. Throughout this process, we were able to establish a real process for maintaining and updating Spark's component library.
Now that Spark's foundation is set, our focus is to transition the rest of the app to this new system. Our main challenge is balancing Spark projects with delivering user value efficiently. We have to weigh the impact of transitioning to Spark on delivery time for new features or enhancements. This project has been a significant learning experience for me as both a designer and product specialist. It required reimagining existing patterns while considering user disruptions and strategizing the rollout process. Collaborating with the product, design, and development teams, I continue to navigate challenges to ensure a smooth transition for our users.
hello@christinesiu.com 
LinkedIn
Behance
Vimeo