Lessons Learned from a UX Engineer

Jun 18 2021 · 4 min read

TL;DR

Less is more

Measure, measure, measure

Don't be an asshole


Four years ago, I started work on what would become a fully grown design system. Little did I know, my tiny CSS library would evolve into a system of over 50 components, built by a team that I now lead. I won't tell the whole story, but wanted to share a few lessons I've learned along the way – sometimes, the hard way.

Crawl before you walk

Start small. Don't jump into large, complicated organisms before you've sorted out and are confident in your atoms. And especially don't do it just because you see other established design systems in the wild do it. Remember that just because something works for someone else doesn't mean it's the best solution for you.

A handful of primitive, but powerful components can go a very long way. Smaller components are easier to maintain, test, and understand how to use. Think of something like Box or Stack. (Our Box component is so popular that its used two times more than our Button component)

Pay extreme attention to your component APIs. Components change over time to support the needs of your actively growing product or brand. Release each component with this in mind, stick to standards, and keep them consistent with each other. The engineers using your tools will thank you for it, and save time by not having to refactor in the long run.

Check your pulse, often

Don't run around with your head in the sand. Have a plan to measure and evaluate where your design system stands. Without knowing how much impact you are making, it'll be difficult to get your team the visibility and buy-in from others across your organization.

Chart your course and set OKRs. Having something measurable gives you visibility into what your design system lacks, where it struggles, and how you can improve. It also gives you a north star, a strategy, or goals to reach.

Play nice

Remember to listen to your customers – your engineers, designers, and product people. Make yourself available to others. If you close yourself off from your organization, don't expect your tools to gain adoption. Outline how your team works with others:

  • Create communication channels to get in touch with your team, whether that's through Slack, Confluence, Github, whatever
  • Make it easy to give feedback
  • Empower others to jump in by guiding them through contribution
  • Set up office hours or pairing sessions to discuss feedback and to answer questions
  • Plan on how to regularly keep others in the loop with what you are working on
  • Announce your metrics, your goals, and your wins

Make friends

Your work will have an impact on many teams. Design systems inherently sit at the crossroads of design, engineering, and product. You'll need stay in tune with what others are working on, and keep your work aligned as it relates to everyone else's – all through the relationships you develop and nurture across teams.

Without building trust with those around you, you'll find it difficult to gain the cross-team communication, collaboration, and camaraderie needed to make an impact.

My advice

Be patient. Design systems are hard. You'll make mistakes along the way – try to learn from them.

My experiences may be unique to my time at SparkPost, but I hope this advice helps you wherever you are in your design systems journey.

If you have any questions, comments, or just want to chat about design systems, feel free to reach out to me on Twitter, or find me on the Design Systems Slack group.


Resources

Copyright © 2000–2021 Jon Ambas. All Rights Reserved.