Why a design system?
In mid-2017, I was a senior UX designer working on Vets.gov (now VA.gov) with the Digital Service at VA (DSVA). The team had an efficient workflow: daily releases to production, a distributed and collaborative development team, and a robust research and design team. What it didn't have was a single source of truth for any of the UI. This caused divergence that made Vets.gov more difficult to iterate on and maintain.
Get buy-in
Two engineers and I did a quick, functional sketch of a design system using Fractal, which we used to get buy-in from our leadership at DSVA. We already had a rough UI audit and knew where some of the problem areas were, so we could present a clear advantage to investing resources in a design system. On our team lead's encouragement, I presented the Fractal instance and a draft project plan to DSVA's lead, who gave us the resources we needed to move forward with a design system: Formation.
Get in Formation
A Fractal instance is all well and good, but if the goal was to speed up going from Sketch to production code, we needed integration with Vets.gov's codebase. Still working within our scrappy team of 3, the two software engineers focused on building that integration using NPM and our existing pipeline, while I focused on documenting and in some cases building the components inside Fractal. (I'm still one of the lead Github contributors, even though I haven't been able to work on the project since 2019.) Formation was used as the foundation for integrating Vets.gov to VA.gov, and lives on as the basis for the VA's design system.