Skip to content

24 ways to impress your friends

Design Systems and Hybrids

The other day on Twitter, I saw a thread started by Dorian Taylor about why design systems are so hot right now. In the thread, he made the case that they’ve been around for ages and some folks were just slow to catch up. It was an interesting thread, and not the first time I’ve seen folks discuss this. “Design systems are so hot right now” was even used recently in this very publication.

And yes it’s true that they’ve been around for ages. Design artefact collectors’ obsession with reprints of old graphic standards manuals of the past are a reminder. Sometimes old things become new again, either through a rediscovery or awakening (wow, that sounds really deep). But I think that’s definitely what happened here.

Some very opinionated answers that come to mind for me are:

  • The need for them has increased with the needs of software development. With the increasing number of devices (phones, tablets, watches, etc.), scaling design has required the need to double down on systems thinking and processes.
  • Investments with huge cost-saving returns. The time investment it takes to onboard new people as you staff up large teams (and the time it takes to fix bugs and inconsistencies) could be better spent building up a system that lets you ship at a faster pace. It also gives you more time to focus on the bigger picture instead of what color a button border is.
  • If you do have to onboard new designers, the design system is a great educational resource to get up to speed quickly on your organization’s design principles, materials/tools, and methods.

“Here’s the simple truth: you can’t innovate on products without first innovating the way you build them.”

These are just some of the reasons. But there is another answer, and a personal conclusion that I’ve reached. It relates to the way I work and what I love working on, but I don’t see it talked about much.

Hybrids Have a Home

I’m a hybrid designer. I code in HTML & CSS (with a preference for Sass). But I don’t call myself a frontend developer. I used to back in the day (I was a UI frontend developer at Apple over a decade ago, but all I wrote was HTML & CSS). I identify with designer because that’s my training and interest, but the ideas of what a frontend developer can do has changed quite a ton over the years. Setting things up in build tools and processes are not my skill. And I know a lot of designers who share this experience with me.

There are also hybrid developers who identify as developers, but have excellent design skills. Buddies like my pal Brandon Ferrua who was on my team at Salesforce is a great example of this. And we worked fantastically together.

Sometimes, companies don’t know how to deal with hybrids. I’ve been told to choose a side, and have even been made to join a development team simply because I could code my designs (and then when I couldn’t deliver the same type of code my teammates could, and I felt like I wasn’t able to use my talents in the most effective way).

There are a lot more folks out there I know of who identify as a hybrid, and many have found ourselves working on design systems. Una Kravets recently had a thread discussing this as well. At Clarity, this came up a lot in hallway conversations, breaks, and the after parties. I think that this job is a haven for folks who often find themselves in the middle.

For companies that get it, these people find joy in getting to use a wider variety of skills and being bridges; advocates that can speak to designers and developers, helping bring 
unity to an organization. They can wireframe, throw together a prototype, create color systems, architect naming conventions for design tokens. Design systems are their perfect home. I think this has contributed to the uptick in discussions and interest on this subject (in addition to the team- and company-focused reasons).

Keep Design Systems Teams Cross-Functional

Speaking of teams, something some larger companies fall prey to is creating walls and silos where they need not be. If you place all your visual designers in one place, all your coders in another, and so on, you’re not doing yourselves any favors. Meanwhile, your hybrids are caught in the middle not knowing exactly where they belong. Design systems teams should have representatives (whether on a core team, or a virtual/federated team) that bring different skillsets. Design, code, writing, accessibility, product management, and so on. You’ll have a stronger vision on where to take your design system and to make it succeed. Siloing defeats the whole purpose of what design systems are meant for.

Happy holidays, and may the force be with you.

Further Reading

About the author

Jina is a design systems advocate and community builder focused on design systems. She is currently consulting with Amazon on a design system for a new, secret project.

She organizes Clarity, the first Design Systems conference. She founded the San Francisco Design Systems Coalition (which now has chapters in New York, London, and more). She created and moderates the Design Systems Slack and the Design Systems publication on Medium. She maintains the design and website for Sass. She organizes The Mixin (a Sass and front end meet up). She also curates Sass News.

She co-wrote the Design Systems Handbook, Fancy Form Design, and The Art & Science of CSS. She was a tech editor for Sass for Web Designers (by Dan Cederholm) and Sexy Web Design (by Elliot Jay Stocks).

At Salesforce, Jina was lead designer on the Lightning Design System. Previously, she has worked at companies including Apple, GitHub, Engine Yard, Crush + Lovely, inferno, Oden, Memphis Brooks Museum of Art. Through agencies and consulting has worked on projects including W3C WAI, Mass.gov, Deloitte, and FedEx.
She has been said to be one of the most cheerful goths.

More articles by Jina

Comments