Backstory
I joined the digital design systems team at REI in May 2018, about a month ahead of a planned MVP launch of a shiny new design system.
As Program Manager, my initial objectives were to lead communication around the launch and drive adoption of the system parts and pieces across our product portfolio. Over time, I would be responsible for helping define the roadmap for the design system and prioritize our team’s backlog accordingly, partnering with key stakeholders and the product teams that our system supported.
But first, I had lots of learning to do. 📚
While I had many years of experience with digital product development and content management systems coming into this role, my knowledge of design systems was minimal. I’d worked with style guides and design languages as part of the design process, and had been exposed to the concept of Atomic Design, so I understood the theory of design systems at a high level, but didn’t know yet what truly makes a design system a system.
There are a ton of great resources I took advantage of to ramp-up — including Atomic Design, Design Systems, articles by Nathan Curtis and the myriad system thinkers and design teams on Medium.
In my first few months on the job, I peppered my new team with questions about the history of design systems at REI, the progress the team had made so far, and the long term vision for our system.
As an internal product for other product teams, another key focus of my learning agenda was to get a picture of how design and development processes worked in my new organization — where we were today, and where we were hoping to go with a design system.
Our team has learned a lot from the transparency of other design systems, in addition to our own experiences, so I’m hoping to help grow our collective knowledge by sharing some of the insights we’ve gained from launching of our new design system.
Sowing the seeds
REI had an existing pattern library, named Cedar, that had been created as a central repo for reusable markup by a small team. That team disbanded after the creation of the library, and a sole developer struggled to maintain it and keep up with changing design standards.
From the experience with the Cedar pattern library, aka Cedar 1, we learned that we needed a more complete library of UI components that would be easy for both designers and engineers to use, and that would be maintained and enhanced with new design decisions and best practices.
A few passionate people made the case to upgrade the design system, building on what worked in Cedar 1, but envisioned as a more robust system with a dedicated team. This was before my time at REI, but needless to say, their drive and persistence paid off, and in 2018 a team was funded to bring this new system to life.
Establishing roots
Knowing that a full buildout of all the components, foundations, and patterns we hoped to include in the system would take a good chunk of time, we were eager to release an minimum viable version of the system to satisfy our early adopters, and to start gathering user feedback to help inform future product development.
To plan what would be included in the MVP release, we identified the core UI components with the greatest likelihood of reusability across our digital portfolio. Then we established a process to design, build and document each of those components, and in early August we launched the MVP of our new and improved digital design system — Cedar 2.
MVP Lessons Learned
Importance of Documentation
After a number of components started to flow through the design and build process, Nathan Curtis, the aforementioned design system guru who we hired to help plan and scope Cedar 2, impressed on us on the importance of documentation for each component — to provide usage guidelines for designers and engineers, and to create a shared reference site that teams could use as a single source of truth.
Our initial target for MVP release was a fairly robust set of 35–40 components, with synchronized design and code assets. A few months ahead of our target release date for the MVP, our development work effectively paused as we played catch-up writing documentation.
As you might expect, this increased scope pushed out our MVP release date, so we could launch a system with paired design assets, code assets, and full documentation.
In addition to writing documentation for the components that had already been built, we also had to build a website to host the documentation and establish a publishing process. Writing and publishing was a new skill for many on our team, and bringing on a technical writer helped immensely.
Ultimately, we developed a system within our system for documentation and publishing — with editorial guidelines, templates for writing articles and component docs, and a release process to update the content on our website that has continued to evolve post-MVP.
While it would have been helpful to have all of this figured out from the start, we were committed to getting a basic version out the door for our users, and dedicated time on our roadmap to go back and review our content from a holistic view, to identify and address inconsistencies.
And I’m happy to say it was worth it — since launch, we’ve found that our early adopters highly value our documentation as a single source of truth.
“Now, instead of just me pushing back [to requests off-standards], I can show them the official site. It’s empowering to have the back-up.” — UX Designer
“The documentation was super easy to figure out, using the system has honestly been very straightforward so far and has saved me a lot of time getting up to speed.” — Front End Developer
By capturing everything in the documentation, our goal is that anyone can reference it and start building with all the information they need, and know where to go to see the latest standards for our design.
Another major benefit was supporting onboarding for new colleagues, who embraced the in-depth guide as an invaluable resource as they acquainted themselves with REI. The documentation proved itself extremely useful as a reference to answer both design- and engineering-related questions newcomers might have.
See for yourself — you can check out our doc site here.