Lessons Learned from a UX Engineer
Jun 18 2021 · 4 min read
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.
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
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.
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.
- Matchbox – SparkPost's Design System
- Atomic Design – Brad Frost
- Measuring Design System Success – Nathan Curtis
- Guide: Set goals with OKRs – Google
- Design Systems Handbook
- Getting Executive Buy-in For Your Design System – Invision