Refreshing and expanding an existing design system

Everybody’s gotta start somewhere

The problems

The entire time I was a full-time designer at VieMed, I constantly found myself wishing that I had better design system tools. Our system was certainly better than nothing, but it still had a ton of issues that slowed us down and introduced unnecessary complexity for our developers.

No variants

One of the biggest issues for designers was that the original design system pre-dated Figma’s release of component variants. This meant that grabbing the correct component for my use case was often a nightmare.

No auto-layout

Our design system also didn’t use auto-layout. This meant a lot of hack-y uses of frames that weren’t very scalable and would often require one-off breaks from the existing design system.

Missing states

Speaking of breaks and hack-y implementations, our design system was also missing quite a few states for its various components, which would often leave designers having to account for those states on the fly in one-off designs, which led to inconsistency across product lines and platforms.

No real documentation

Finally, there was no documentation beyond the UI sticker sheets in Figma. No usage guidelines, no best practices, no patterns, no zeroheight or storybook to ensure that we were aligned with developers — nothing.

No way I could leave it alone in good conscience

When I left VieMed to join Divvy, it bothered me that the Design system was still in such a bad state. So, I reached out to the PM and CTO and asked if they’d be interested in me re-designing the design system as a contractor. My design backfill was swamped with her day-to-day work, so they eagerly agreed.

Taking stock before taking over

Before I moved a single pixel around in Figma, I walked through every design file across each of our 5 products on each of web, iOS, and Android. I put together an inventory of everything that was missing, and built out a database in Notion of what I thought needed to be built in order for our design system to really be considered “complete”.

The list was way longer than I expected.

How do you eat a whale design a component library? One bite component at a time

I decided to start with the component that had been one of the largest sources of frustration for me while at VieMed – the text input.

Our most-used product was our internal tool for Respiratory Therapists (RT’s), which featured lots and lots of — you guessed it — text inputs. So much of the charting and form-filling that RT’s do is based around text inputs, and it drove me nuts that we didn’t have a component set to cover all of our use cases.

For reference, this was our starting point —

Starting with atoms

I knew that I wanted to break down the component atomically, so that I could represent every state that was reasonable to expect in our web apps.

I started by creating a variant set for the captions and labels that could show up on our text inputs, so that I could expose the nested variants to designers and have them manipulate the captions and labels independent of the set of variants for the parent text inputs.

I used this component set to show the PM and the full time designers a glimpse of what I had in mind for the entire design system. They were thrilled, so I was excited to get cracking on the full set of text inputs.

Turns out, keeping track of lots of variants is hard

Even with the use of nested variants to tackle all of the different combinations of labels and captions for a text input, this component set got much bigger than I expected. This was my first real attempt at building a set of components that included more than about 20 total variants, and it was a crash course.

I had to revise the component set a few times after realized I had failed to account for some specific intersection of properties and values, which was both frustrating and time consuming.

To make sure that I was capturing every possible state, I started setting up a grid for each component set that I knew was going to be bigger than I could reliably keep track of in my head.

Setting up my components in this grid was super helpful for me, but I suspected it wouldn’t be particularly friendly for anyone else looking at it.

After a review session with the PM, designers, and engineering team, my suspicions were confirmed — they all acknowledged that they understood why I had set the components up the way I did, but they did not want that to be how large component sets were presented.

I cleaned up the layout and presentation, and landed on something that was much better received when I shared it out with the team.

Getting into a good cadence

Once I’d tackled my first big set of variants and got the engineering, design, and PM partners all on board with my vision for the design system, I was off to the races.

I got into a great cadence where I’d review the states I planned for a component, design out the variants, present to PM + design + engineers, make tweaks as necessary, then come back with an updated component set.

Over the next few weeks, I made great progress across some key components for the VieMed web apps.

Just as I felt like I was hitting my stride, the unexpected happened.

Didn’t see that one coming…

A few months after starting this project, I experienced a chain of health issues that would ultimately cut this effort short.

After having my appendix removed, having my gallbladder removed several weeks later, and then being hospitalized for pancreatitis another few weeks removed from gallbladder surgery, I decided to terminate my contract with VieMed and focus on my health.

A bittersweet ending

I was crushed to set down this project that I’d been so passionate about, but I needed to focus on recovery, improving my health, and my full-time job with Divvy.

I don’t know whether the designers at VieMed ultimately saw this effort through or not, but I’m hopeful that the foundation could serve as a springboard for some much-needed improvements to their design system.

At the very least, it was a phenomenal crash-course for me to get familiar with more advanced Figma features and functionality and become very comfortable using and contributing to design systems.