Background

About 2 years ago I was hired as a Product Designer at ThycoticCentrify. I joined a team of 4 and was excited to work at a company that put money towards design. However, it didn’t take long before I realized that’s all they were doing — throwing money at it. We had good designers, but everyone was working in isolation and patterns were “re-designed” constantly.

Realizing that my previous company was pumping out more features per month with 1 (great) designer, I knew we had to implement a design system. So I quickly became the de facto owner of the “design system”. I built out a considerable amount of components in Figma, and devs even started to codify these components. But there was no documentation, and I spent more time advocating for the design system than actually contributing to it.

Fast forward to this summer, I was hired at Trainual as their first Design Systems Designer. The fact that a company 1/5 the size of my previous had carved out a specific position for the design system meant A LOT.

At the same time, I knew this experience wasn’t going to be all rainbows and butterflies. Design systems are mysterious, unwieldy, ever-changing, and just straight-up difficult. That’s part of the reason why I love them.

Below I will share my learnings on the first 6 months of my journey.

My situation

Just to set the mood a little bit, here’s some useful context:

• I joined a team of 3 other IC designers. Since my start date, 2 other designers have joined the company👋
• 2 months into my journey the company hired my partner-in-crime — a Design Systems Developer (
  Dacey Nolan
  ) 🙌
• Pre start date, Trainual already had a component library in Figma, some stories in Storybook, and a considerable amount of documentation in zeroheight. The fact that I did not have to advocate for these tools was definitely part of the reason why I took the job 🤓
• Figma, Storybook, and zeroheight had great info in them, but not enough to rely on it, and it needed consistent love 🙏
• The designers on my team advocated for my role 💜
• Trainual’s product is not massive by any means, but they do expect desktop, tablet, and mobile screens to work for the web. There’s also a native iOS app 📱
• Like all products that aren’t brand new, there was legacy code 😀

What I learned

Not everyone is going to love the design system at first, or even know what it is

I was hired specifically to implement a design system, so I know others in my role have it rougher than me. That being said, it’s not like the whole company voted for me to join the company.

Some people won’t get why they need someone (maybe less senior) to tell them what to do and how to do it. Some designers and developers love working with little red tap. Even if they like structured work, they may just not be psyched about change or having to learn something new.

Takeaway: Sympathize for your users, a.k.a. designers, devs, QA, product, and marketing. You are going to rustle some feathers no matter what, you might as well do it in a way that doesn’t make you the most hated person at the company 🙂

Start with the foundations

Obvious, right? In order to limit rework, design systems need to lock down things like typography and color before they can work on buttons or fields.

I knew this and yet I still fell victim to it. Here’s a story:

After a couple weeks on the job I started advocating for work on our color and type systems. Turns out foundational decisions are divisive. We ended putting some of that work (and our egos) on the back-burner and shifted our attention to other components, like a product-backed Task Modal. We did eventually complete the Task Modal, but mistakes were made and rework is evident. Meanwhile typography and color continued to be our true blockers — and it turns out that “back-burner” rarely reveals insights down the line.

Takeaway: Talk to whoever you can and research your heart out on what foundational variables need to (and can) be made, given your product and tech stack. Then, make them. All of them. They won’t be perfect, but at least modifications down the line will be easy and global. For context, we’ve made:

• color variables
• type variables
• border radius variables
• border width variables
• height variables
• spacer variables

Ask for feedback wisely

Everyone needs to contribute to the design system. I truly believe in that. Nothing great is made alone. With that said, if you ask for feedback for every decision, or schedule a meeting for every component, then your work will constantly be blocked by stagnant feedback loops and you’ll spend 8 hours a day in slack.

Takeaway: Choose specific aspects of the design system to get feedback from. Sometimes you need an expert’s opinion — or you just need to reinforce that the design system it a team effort. Other times your work blocks other work and a quick (never permanent) decision is what’s best for the company.

Advocating for the design system never ends

Like I mentioned earlier, I was hired specifically to implement a design system. That doesn’t mean e.g. refactoring the type system is inherently going to get prioritized over feature work. I’ve heard every trick in the book to systematically enforce design system work, and none of them have worked.

Takeaway: The current prioritization system at most companies is just not built for design systems (or accessibility). Do whatever necessary to ethically get work into the pipeline. One tactic (that proved somewhat successful) was to make a loom video for each DS issue, discussing what the issue entails and how to complete it — basically a user story and acceptance criteria in video form. This just made each issue slightly more comfortable for the PMs.

Trust yourself

I am one of the more junior members of the greater development team at Trainual and yet I need to make a lot of decisions (or at least cast the final vote on stalemates).

That’s how it should be.

You may think that someone has X more years of experience, but they likely have less knowledge than you on making design system decisions, even if you only put in 30 min of research.

Takeaway: Design System Designers think differently than everyone else. They are realistic, holistic and systems thinkers. It’s great to learn from tech leads, but they are not working on the system 24/7. They are not constantly reading Design System medium articles. They do not know the spider web of decisions that have already been made. Trust your instinct when you have one.

You won’t be designing much in the beginning

As you can see from the lessons above, being the owner (or even the co-owner) of a design system involves more than creating a slick component library. Below is a list of responsibilities I took on in my first 6 months:

1. Owner of Component Library in Figma
2. Designing new components
3. Creating designs needed for the Acceptance Criteria
4. Restructuring current components for scalability
5. Owner of Design System in zeroheight
6. Contributor of Component Library in Storybook
7. PM of DS squad
8. Creating (JIRA) issues to be groomed
9. Co-leader / communicator of the design system
10. Manage all design system communication channels
11. QA of DS issues
12. Product copy liaison between marketing and product
13. SME of current app functionality

Only 3 of the 13 responsibilities are achieved in Figma, while only one is actually designing new components / patterns. Now some of these priorities will be taken on by others as the team grows, but that comes with time.

Takeaway: You must love working with people and on processes to be a Design Systems Designer. I’ve had maybe 3 days at Trainual where I had no meetings. If that scares anyone I’d advise you not to move into design systems, as constant communication is what is required.

Learn the expected scope of your design system

What do I mean by this?

• How many products does leadership expect the design system to encompass? Native apps? The marketing site? Internal products?
• Should the design system account for tablet and mobile experiences?
• Do the product(s) have dark and light mode?
• Do the product(s) have end-user and admin mode?

Takeaway: Don’t fall victim into thinking additional scope won’t be more work. Having to account for dark mode has been a similar amount of effort as having to support an additional product. Figure out what the expected scope is upfront and do not let scope creep trickle in without resetting expectations. Not in a design system role just yet? This is a great question to ask in the interview process to know what exactly you’ll be responsible for.

Conclusion

There have no doubt been some tough weeks during my first 6 months, and sometimes progress has been slow. That being said, I try to keep things in perspective and acknowledge that the beginning is always the hardest, and that we’ve done so much thus far. As long as you have the right mindset you’ll be able to incrementally make the lives your teammates (and users!) better.

I am supremely grateful for the patience my team has shown through this tough transition. Trainual has the best people and the best culture, and I love providing value to a company that values me every day 💜