This post is about my personal experience implementing a design system at Wayfair. I was given the opportunity to work on the team that started the process of implementing the Design System across Wayfair. During this time I became a go-to designer for all questions related to the Design System, it's rules and implementation.
The Pattern Library
The first large project I was given at Wayfair was taking on a role in management of the Design System (internally called the Pattern Library). It was a perfect early project, I was able to learn all of Wayfair's patterns early on, work with multi-disciplinary teams, and was able to see first hand how to implement global design components.
In my first few weeks at Wayfair the team was in the process of setting up a Pattern Library. The leads at the time we're in the process of finalizing colors and some of the initial thoughts and rules. My team was chosen to help with the first push to get full pages mocks in the new styles for final review.
After completing these early mocks we went through a few additional reviews and edits to the rule system. By this time we had a preliminary Pattern Library in the works, and my team members and I played a vital role in helping set those up.
By this time I was familiarized with Wayfair enough to help take on a larger role in the management, upkeep and setup of the library.
I setup templates for the pattern library that included notes and examples of in use patterns. I did a clean sweep of the symbols in the sketch file, setup the naming convention of those symbols, and implemented some sketch nesting techniques for easy management of the symbols and styles down the road. Our Sketch Pattern Library now relied heavily on overrides to change text styles / colors / or card types out. This allowed for multi-level sketch patterns to be used so that a design could swap out any piece of the symbol with any text style or color.
This sketch library acted as a starting point for designers in their projects, and the documentation around use is what our Frontend Engineers used to setup the codebase's component library.
As we went further along in the management of the pattern library, and we started to implement on the Wayfair site (and our Lifestyle Brands as well), we worked closely with the Frontend Development team to insure alignment across all the teams (Wayfair design teams range from 3 - 10 designers per team). Our Pattern Library primarily used components that would be reused across all sites. A single component would need to work in multiple areas of the site for various implementations, across many brands.
Implementation & Management
My team created new tickets (tasks) for the development team to implement new components and patterns to the codebase that could be used. We worked with them on updated styles in the code base, and wrote release notes for new components that were in the pipeline.
We held a weekly Pattern Library office hours for designers to have work reviewed. This helped designers on all teams come to understand the Pattern Library rules and where they could be flexible and where they could not be.
However, we ran into some road blocking issues that led to discontent from designers. The road blocking was caused by our team trying to mediate between development, design, and upper management, and in turn, the other designers mediating between us and their Project Managers. Basically one large communication break down. The designers & PM's needed to hear why they could not break the rules, and they needed to hear it from the developers or their design leads, not another designer from a different team.
The office hours we're a good idea, but hindsight, could have been managed better. Things we could of encouraged earlier would have been:
- Having the designer bring a developer and the Product owner to these review sessions.
- Having open office hours that any person, not just a design.
- Having the reviewers be multi-disciplinary, or have the library itself be managed by stake holders from multiple teams.
That way our developers could of facilitated the conversation, other teams could of had insight to new patterns or problems, and Product Owners would of had direct contact with the people giving the recommendations.
After managing the Pattern Library and being the "go to" team for roughly 4 months we stopped all management and handed over to the Design Team Leads & Frontend Platforms team. The Leads had finally seen the discontent from the other designers feeling a lack of ownership over their parts of the site, and had decided to take another approach on having group ownership over the Library.
We setup nested symbols so that any designer could customize the component to match their needs.
Release into the Wild
Our team had succeeded in getting the initial library out the door and into the wild, by this time most the designers had a good grasp on the rules and guides for the library.
The design teams were each given the ability to now make their own updates and edits to the library, with a short approval process from all the team leaders and the frontend development lead.
My team held a training session to help teach the designers how to add new patterns to sketch, and how to get those new patterns into the code base. We encouraged everyone to contribute to the library and now have a checkout system for pattern updates to the base file. We are still used as experts on the Pattern Library history, but it is a much more informal. We still answer questions from other teams on decisions and usage from the initial setup, and we are still adding our own new patterns to the library.
A recent update was a guide for our Responsive Grid System! Which, myself and my team mates not only organized a design training on, we also presented the update across all of Wayfair's Storefront team.
The Design system is an ever evolving project at Wayfair and continues to grow and progress forward.
I originally wrote this in the Fall of 2017, and the process above is where Wayfair was at during that time frame.
Now (early 2018), I'm proud to say Wayfair was able to improve upon our early problems in the Design System management, in part this was able to happen due to open and honest communication from my team to our Upper management and to the Frontend Platforms Engineering team.
We were able to communicate effectively about our short comings, and retrospective change it going forward. Being apart of any bootstrap project in a company, you know it might not go it perfectly the first time around. But having the experience can help you do better in the future.
My approach on design systems derives from Brad Frost's, "Atomic Design" principals. Of course, still a work in progress, but language used my reflect that education on the subject.