Design System: A story about designing, developing, and changing the process
BrainPOP makes educational content for grade school kids. Formerly all Flash sites, BrainPOP, BrainPOP Jr, and BrainPOP ELL were painstakingly redesigned in HTML. As designers, we naturally asked ourselves: How do we document, maintain, and evolve design and code as we make more and more complex features while keeping the core user experience in-tact and meaningful? How can we hold ourselves accountable?
The Old Way of Doing Things
When I first started at BrainPOP, the design and front end dev teams were very small. With the HTML redesign came a static style guide.
However, components don't live in a vacuum. Information about UI and behavior patterns borne out of projects remained undocumented in the minds of individuals, and rarely was that information effectively shared. Designers were spec’ing already existing components, engineers were routinely building pages anew, and QA spent time checking these same components over and over. As the creative team grew, I realized that looking for patterns and logging bug tickets for inconsistencies were not only inefficient but completely preventable.
I became a (caveman) coder
Because our engineers were remote and hours ahead, our interactions were limited to a few hours a day. How can we make our process working with them efficient? At first I thought designers should also be coders. I rallied the CTO for dev access, but ultimately only I was given access to the codebase.
Even though I could now commit code, I just became another dependency. I was not solving our process pain points. Ultimately, we needed to modularize our collective knowledge so that anyone can come and pull the styles and code snippets they needed without going on a chase to find them. With limited time with engineering, we tried creating our first interactive styleguide using Frontify. While it was great for colors and simpler components, we quickly outgrew it needing something more customizable.
So, we made a design system
What BrainPOP needed was a design system, composed of a living style guide, a common vocabulary, and a set of guiding principles for visual, behavioral, and editorial. It was imperative that we build something scalable and future-proof. By now, our creative and front end engineering departments doubled and we needed to onboard our new colleagues painlessly.
The designers worked together to audit the sites for inconsistencies, debate the merits of certain interactive behaviors, and identify improvements. We worked with a front end engineer to clean up the codebase. Based on Brad Frost's atomic design, we built our own in-house living style guide.
Accounting for accessibility
As part of our sitewide audits, we also made sure to account for discrepancies in meeting WCAG 2.1 Level AA standards. As an education company, we are committed to making sure our work was accessible to users with low vision, mobility and hearing issues. While BrainPOP is not quite fully accessible, my key result tied to the company objective was to create an execution plan for bringing code up to Level AA compliance.
The style guide accounts for many of our accessible components, which we are constantly updating.