Two years ago, I started at Guild and my onboarding included meeting with our lead software engineer Stafford. Over a cup of iced americanos, I was prepared to sell the why on a design system. Instead of selling, I was elated to find that Stafford already understood the why, had worked on multiple systems, already thought through potential implementation paths and was waiting for a partner to take on the first design implementation.
Enter Recess, Guild’s design system: an ever-evolving ruleset governing the composition of one or more products.
Why Guild Needed a Design System
Guild is a company that derives compounded value from a design system. We strive for a consistent and quality experience, but are scaling fast and need to decouple work against many solutions at once.
- Many apps, one product. When I started, the majority of our applications lived in a monolithic Rails application, but we had a vision for multiple. Today, we’ve broken our product into a number of codebases that align to milestones in our student’s journey. All of these apps consume Recess.
- We’re scaling, fast. On my first day, we had less than 10 technologists. Fast forward to today, we have 10 times that number working in tech and many more across the business. We’ve launched partnerships with the biggest companies in the world like Walmart and Disney. The design team has grown from two to seven (soon to be 10 or more) within a few quarters.
- Make every employee a designer. At Guild, we have 300+ people who work with partners, students, and technology every day. By developing and deploying a design system early, we were able to empower every employee to “design” on their own, working faster and better because they have confidence that the design system has their back.
Six Lessons Learned
Below are the top lessons learned from getting a design system from zero to one. Recess’ success has led to us to hiring and developing a four-person (and growing!) front end engineering team with pros like Justin and Blake.
1. Make it a valuable resource for the entire company
Before Recess, there wasn’t a central resource for brand materials; this included icons, fonts, colors, logos, and presentation templates. Without this resource, there was inconsistency between various materials being used across the company — internally and externally. At the time, the design team only consisted of two members, me and Erin, and our days were always interrupted for logo or icon requests.
Our first goal in creating Recess was to set up all of the assets the design team used and to make them accessible to everyone. We re-created consistent assets and made them directly downloadable. I noticed the huge impact this had when people would routinely mention their love for the tool, design didn’t receive one-off requests, and people’s own assets looked more and more consistent.
At scale, we are starting to revisit if our style guide, assets, and components should all live together, but by centralizing these materials and providing easy access created strong advocates for Recess in beginning stages.
2. Don’t reinvent the wheel
In 2018, Elana, a product engineer at Guild, moved us over to Styleguidest which greatly improved our speed to launch new elements on the site and have built-in documentation. I believe we are hitting a new phase with this and will be moving all of our engineering documentation and components to Storybook.
There are several plug and play guides that designers and developers can use out of the box. These style guides are tested and designed specifically for the purpose of maintaining a library. There’s no need to re-create your own!
3. Never, ever, use basic HTML tags as selectors for style rules
In our first implementation, we made the mistake of writing CSS directly on HTML tags. By doing this, versioning became an absolute nightmare and quality assurance became impossible. There were late nights of me clicking through, updating and documenting what felt like hundreds of versions of pages to make sure things weren’t broken.
To rectify this issue, we only use CSS utilities and made sure even the small foundational elements, like buttons and links, were made into components.
4. Do extra quality assurance for each component with the design team
There is nothing worse than launching a component and finding that it’s “slightly off” across all of our applications; this leads so small and wasted version bumps. We learned the hard way a few times that it’s worth it to throw the designers in a room and go through a very thorough QA once for every component. Our IT department put together our “Da Vice Lab”, which has all of the hardware our clients use the most with the appropriate browsers. We also make sure that all of the devices are logged into our QA email, so we can email photos of needed fixes quickly.
5. Create one source of truth for assets
As mentioned, a big first task in creating Recess was to provide a consistent, organized central location for all our brand and partner brand materials. We uploaded and added all assets to our a S3 bucket, which is connected to all our products. At first, we were attempting to manage a Google Drive folder, but moving the majority of assets to the S3 bucket allowed us to have one source of truth. This centralization has allowed up to update assets swiftly; if a partner changes a logo, we update it in the S3 bucket and auto updates everywhere.
6. Seek insight and contribute to the larger design system community
Design systems are still a rather new and growing concept within the tech communities. When our teams would debate on the best way to think about something or do implementation, I found the Design System Slack incredibly helpful; this community is engaged, helpful, incredibly well moderated, and a safe place to ask any type of questions.
New Challenges Are Rising
As Guild’s design system progresses out of the zero to one stage and into the one plus, we are now encountering a new host of challenges. Please check back on a further post as we continue to work through solutions for:
- Communicating updates to product managers on multiple products/squads
- Learning how to balance and prioritize: new component creation, system infrastructure needs, and app versioning
- Having documentation for designers and developers — when to mix the two and when to keep them separate
- When engineering starts to out-speed design
- Ensuring everyone feels like they are an owner of Recess
If you are interested in learning with us and working on a platform that will help millions of working adults go back to school, check out our careers page.