Cedar DesignOps Q2 recap
Super proud of the work our two-person DesignOps team accomplished this past quarter at Cedar (especially considering we were both also taking on feature work), and wanted to highlight some of the design system projects I had a chance to work on in Q2.
For starters, I had a lot of fun building and writing documentation for a handful of new patient components, including badges, accordions, navigation (header, footer, flyout nav), client logos, and a multi select search field. The majority of the components in our backlog were prioritized based on a curated dot voting activity with the designers during Q2 planning, but a few (like multi select search) were added organically as designers were developing their features during the quarter.
Beyond components, I also had the opportunity to collaborate with the designers building Cedar’s patient billing and engagement product (Cedar Pay) on a source-of-truth product screen library. At the time, the Cedar Pay designers were regularly being pulled away from platform work to help design client-specific features. During sprint planning, I asked the designers how DesignOps could better support them in their day-to-day and came away with a few key pain points / workflow inefficiencies:
Starting a new feature is time-consuming. You have to spend time tracking down the latest version of a flow / screen set, then compare those screens against production to make sure the screens are up-to-date.
New features can sometimes cause conflicts with existing features when it’s not obvious that the same screen real estate is being used by other features / tests. Making those other variants and states more apparent would be a huge time save when working on new features.
Editing screens is inefficient. Most of our screens at that time were being stored in feature files with broken type and color styles, inaccurate layouts, and none of Figma’s time-saving features like auto-layout.
The latest end-to-end Cedar Pay product experience isn’t visible to designers, product leads, and commercial folks who aren’t working on the product every day.
With these takeaways in hand, I spent a sprint planning and building out an MVP spec library. I scoped the buildout to just the Cedar Pay web experience (excluding emails and paper statements), and focused on creating prod-accurate versions of all key screens in the app, including common variants (e.g. bill past due, bill in collections, etc.) using auto-layout and styles/components from our design system. I then ran a four-week trial run with the product designers, starting with a kickoff and ending with a retro at week four.
Some of the key takeaways from the retro were that the spec library made it much faster to pull together accurate screens, which is especially useful for creating experiments and user tests, but searchability could be better, as even limiting the scope to key screens and core variants for mobile and desktop resulted in a few hundred screens. In the end, we came away with three top priorities to tackle in Q3, which included improving searchability within the spec file, cleaning up small mismatches between Figma and prod, and extending the library to include email and the paper statement.
Lastly, one of the interesting things about working on the spec library in tandem with new components and patterns were the many opportunities to use one to enhance the other. For example, in Q2 I worked on a project to make all of our client logos accessible as components in Figma (a total of 54 individual clients and 1154 total logo variants!). Together with a few navigation components and the spec library, designers were able to quickly assemble and rebrand entire flows for demos and client work in under a minute.