On Theme: Design Systems in Depth

When Design Systems became A Thing with Jina Anne — #02

• Elyse Holladay • Season 1 • Episode 2

Share episode

📲 Text the show your thoughts!

Jina Anne gives us a history of the journey from early style guides to widespread industry adoption of design systems, and the challenges and successes. We explore how tokens came to be, how it feels when the engineering team just starts using your work before it's ready, the separation of HTML/CSS/JS concerns, and how ClarityConf got started. Plus, the origin of the phrase "design systems" (maybe?), and  what the NASA Graphic Standards Manual has to do with ClarityConf.

💖 On Theme is a brand new podcast, so if you like what you're hearing, please hit subscribe and sign up at designsystemsontheme.com!

Links & References


🎨🎟️ Into Design Systems is May 25-28
Get your ticket at intodesignsystems.com/ontheme

Into Design Systems is back with their annual virtual conference, May 28-30, 2025. Get your ticket now for three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. 

Jina Anne:

Suddenly we noticed the production engineers were copy-pasting our code. And we were like, wait, so they do want our code! Okay, so that changed our roadmap because we were thinking, oh, we'll build this for us, and then we'll address some production development later, and we had to be like, okay, we need to go all in on supporting production development, because they're already copy-pasting our code, and that's not how we want them to use this it just became real at that point. that's when our team pivoted to working on this new design system, which would end up becoming the Lightning Design System.

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. We can't look forward without knowing where we've been, though, so we're kicking off season one with a journey back in time to how design systems as we know them today came into being. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28 30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket at intodesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show.

Elyse:

Today I'm so excited to have Jina Anne on the show. Jina, who I'm sure you definitely know, is a Bay area based Design Systems advocate, and a designer who codes and no codes, and of course she is extraordinarily well known and influential in the design system space. Jina founded Clarity, like the design systems community conference, they manage the Design System Slack, which has been I don't know, something like thirty thousand members or something like that. Jina co-chairs the Design Tokens Community Group amongst a million other things in Jina's bio that we don't have time to go into. At Salesforce, Jina was the founding designer on Salesforce Lightning Design System, helped create design tokens, which has completely transformed the way that we talk about design systems. And she has worked on design systems at Amazon, Google, Microsoft, and Asana, a truly astounding set of big name companies. Of course, she's a regular conference speaker, podcast guest and all that good stuff. Jina, I could not imagine starting this podcast and not having you come on as a guest. Thank you so much for coming to hang out.

Jina Anne:

I'm so excited you did this. I remember when you were doing your Clarity talk, everybody was like, you need to start a podcast, and so I'm so excited to see you do it.

Elyse:

The peer pressure. It's real, I know. I'm excited too, and you know I think it's going to be a lot of fun. I think we are at a very interesting place for design systems as an industry, and there's so much that I want to talk about and so much that I want to hear from people about, where are we going, where can we go from here? And, that's really why I wanted to have you on the podcast, because, you know, Brad Frost and I talked about the very early era. We were trying to work on this problem that was like, oh, if I need to update a button, I have to update the hex color on 80 pages, literally 80 files, you know, this is like pre React, pre design tokens, pre like all of this and obviously, design guidelines, style guides, all of that, had been around a really long time in the design space, but, I really wanted to chat with you about, you know, kind of what happened next. Like how did design systems become a thing? How did it become a thing that has its own conference and, you know, it's its own little like niche cottage industry, like inside the design and development industry. So let's, yeah, let's go back to the beginning. How did you first hear about and kind of start in on design systems in your work?

Jina Anne:

Yeah, where to start? Yeah, so, like I'll start first with, like, before I knew to call them design systems, like I'd heard so many terms for them, but, like, the first, I guess, foray into this was I was calling in the agency I was working for, I was calling it a style guide and you know, I was still documenting the CSS but I was doing it as a printed document designed in Quark.

Elyse:

Quark, wow.

Jina Anne:

Yeah, remember Quark?

Elyse:

No, I don't. I don't!

Jina Anne:

Well,

Elyse:

I

Jina Anne:

I remember.

Elyse:

I don't think I ever

Jina Anne:

actually

Elyse:

worked in Quark.

Jina Anne:

Yeah. I think a lot of people skipped Quark I did not, but yeah, so I was an intern at a design agency and I was working on this project and I was initially just supposed to help out with some, CSS. The agency contracted another agency that was supposed to write most of the CSS, and they didn't really have a good grasp of modularity or maintainability or anything like that, and honestly, I was new to it too, but at some point they just asked me like, do you think you can take this on? And I was like, I'll give it a try. Sure. And so, yeah, I was like writing a lot more CSS for that project and then documenting it and then documenting the brand, documenting the layout, and all that, I really enjoyed the process of it, but none of the other projects I'd ever worked on had that as part of it. And so I was always kind of like thinking about that project and other projects I was doing and fast forward, I guess not too long after that, I moved to the Bay Area and I was working for Apple, and there I was doing CSS mostly for the online store, but I was wanting to document the architecture of it, the organization, like all of that. And so this time around I was using WordPress instead of a Quark. But you know, still not quite calling it a design system yet, I was just kind of calling it a style guide. And then, you know, I saw I think YUI had come out sometime around then, so, like, that was, I think the first that was the Yahoo UI library, which I think everybody was using the phrase pattern library around that time.

Elyse:

Mmhmm.

Jina Anne:

So I saw that and there were a few other things like that, that I was like, Oh, that's cool. But I guess I wasn't really thinking about these two things as like the same thing. Like, I kind of saw them as like, two different assets, efforts. I don't know, whatever you want to call them,

Elyse:

I think the design and code was very separate then. I mean, I came from the CSS side, so, you know, I was doing a lot of the same stuff. It was like document the CSS architecture, like define these, you know, we didn't have variables in CSS, we didn't have Sass, we didn't have, you know, you could barely, you could like split things into different files, like that was about the extent of it, your global styles, your individual component files, like we were starting to develop those ideas in CSS land, then I think on the design side, we were doing the same thing, you know,

Jina Anne:

Right.

Elyse:

it was like, okay, Photoshop, here's kind of like a sticker sheet in Photoshop, or like a

Jina Anne:

Yeah.

Elyse:

visual set of like here's what all of the, you know, cards and buttons and inputs are supposed to look like, but there was zero connection between those two things. And I think I have the same experience where it was like, they all just felt like one off things we were doing on projects. It was really just turning into like a capital T thing.

Jina Anne:

Yeah. And so I think what kind of, made me start to combine those two things was actually the same time that I got into Sass, and that was when I was working at Engine Yard, they told me like, if you're going to contribute to CSS, you have to use Sass, and initially I was like, I don't need Sass, I write great CSS, I don't need it, and then I fell in love with Sass. I think a lot of people had that. So then I was documenting instead of using a third party thing, like WordPress, I was just doing it straight on the app, like as a separate page. And that was the first time I was doing it as like, you know, what I think I was calling back then, like living style guides. And somebody that was at my talk referred to it as style guide driven development, which I thought was hilarious. Everybody's always trying to give it some name like that. And then it wasn't too long after that, that, yeah, I was contributing to the Sass project cause I loved it so much, I wanted to help out with the design, and so I did a style guide on that site. And that was actually the first time that I took YAML data to store my name and values for colors, spacing, type, and I was converting them into variables and classes and stuff like that cause I was using Middleman and it had a really easy way to do that. And that's actually what I presented to my team when I started at Salesforce and that ended up spawning Theo, which was the first design token generator. So it's kind of funny how it all just like connects. You know.

Elyse:

Yeah totally. So when, what year was that? When did you start at Salesforce?

Jina Anne:

That, so that was around 2014 and I think we were still kind of calling it a style guide around then, and then once we really started launching like design tokens into our platform, it's just something in our language changed, we started calling it a design system. And there's also design tokens that was based on how we were implementing design in the product. So it's a very Salesforce centric term that we were using, and it just kind of surprised me that the whole industry just latched on to that same terminology. But yes, so have you ever had to, like, tokenize data for, like, localization? Yeah. So like you want to pass in, so they didn't use anything like Sass, so they were actually using token strings in the code and then passing in XML data, and so we were storing XML data for font sizes, colors, like all that stuff. And so then we created Theo, cause we wanted to continue using Sass on the design team, but then we also had partner teams that were working in, you know, Angular, React using Less, Stylus, like every time we would acquire a company, we had to inherit whatever stack that they were on.

Elyse:

I feel like you're just name dropping a bunch of tools that like, people just don't even know about anymore, this is such an amazing throwback. Stylus!?

Jina Anne:

Yeah. I mean, I don't even know if anyone uses Stylus anymore, but

Elyse:

but the one person listening to this that still use Stylus, call me!

Jina Anne:

Yeah. But yeah, so we were generating our stuff to all those different platforms, which is basically, why we started doing tokens at that point, when we were, rebranding our team, we used to be a visual design team, and then we were coming up with the name, initially we were calling ourselves creative systems, and then that didn't really stick, and then we were just systems, but then people had no idea what that meant. And then at some point, we're like, okay, we're the design systems team. That was the first time actually being on an official team doing design systems.

Elyse:

I wonder if, was that, do you think that was like the origin of that phrase?

Jina Anne:

I have no idea. I, I, I don't like to try to take claim to phrases like that, cause I always feel like there's somewhere that that had to have been used before, but I do think it helped popularize it. So I will, I will say that.

Elyse:

Yeah.

Jina Anne:

Yeah.

Elyse:

I mean, I think, one of the themes, Brad Frost and I talked about this, and I feel like it's coming out really strongly in our conversation now, is how much of these concepts were just kind of in the air, you know? You were talking about it, you were talking about it at SassConf, you were talking about it at Clarity Conf. Theo, the design tokens thing got popular, but lots of agencies were doing things like this, lots of people were doing style guides. I was talking about Brad Frost and Anna Debenham doing Pattern Lab, styleguides.io, I mean, it was just very much in the in the air with. Us but I also think it's really interesting to kind of try to track that etymology, not for like a credit reason, but just like somebody was the first person to say that, you know, to like, put the Yeah. concept and those words together, and it might've been your team at Salesforce, which I think is kind of amazing.

Jina Anne:

That would be cool if it's true, I won't make that claim cause I don't know it to be true, but it would be cool if it was.

Elyse:

Yeah.

Jina Anne:

Yeah.

Elyse:

OGs, if you know yeah,

Jina Anne:

Yeah.

Elyse:

And I, you know, I think Theo looking back, it feels like Theo as a design token tool to, take the structured data for, for any non technical designers listening, you know, when she was talking about localization, right? You're taking a structured data where you have, you know, an ID and a value pair, and you're just saying, you know how tokens work now, it's a variable. It's like the name, the ID, and then the value. But this was really kind of for use in a design way, and especially for use in a multi platform, multi language way, was actually really kind of ahead of its time. I mean, I,

Jina Anne:

Yeah.

Elyse:

Multi-platform is one of the big challenges facing design systems now, like how do we do, Android, iOS, React, Angular, Vue, you know, like all of these different things well, and yeah, I mean, y'all were thinking about that almost a decade ago, which is—

Jina Anne:

It was a decade ago. We hit our 10 year anniversary last year, and it cracks me up, cause I still see people say like, oh, design tokens are like this new thing. I'm like, no, it's literally over 10 years old.

Elyse:

Let's go on a little design token tangent. How do you feel about the chokehold that tokens have on the design system industry right now? Oh! Okay. That was a leading question. How do you feel about design tokens these days?

Jina Anne:

Well, obviously I'm still a fan of tokens, and I'm working on token stuff right now at work, I love it, but sometimes I do think, people are tokenizing when they don't need to tokenize and they're overcomplicating things, and sometimes I'm like, I think we created a monster. Yeah, Yeah

Elyse:

I, I wonder sometimes if the idea of having, it's a special thing, it's tokens. I'm like, really, they're just fancy variables, know? And like, in a lot of cases for a lot of teams, like at Salesforce with Theo, you really were taking something else, YAML data or JSON data or whatever, and turning that into variables in lots of different languages. And so there was an abstraction token, but I think for a lot of design system teams, they're just writing variables.

Jina Anne:

Exactly. Like they're just writing CSS custom properties or Sass variables. And so it's like, just, just do that.

Elyse:

We've turned it into something like supposedly very magical. Um, but it's, I love, I love that the design space has picked up on the power of variables, you know, from the engineering side. I mean, obviously variables have been around in code for ever. Yeah,

Jina Anne:

it's actually, it's exciting that design tools are implementing this now and I look forward to seeing that advanced further. I don't think it's fully there yet, so I can't go all in quite yet, but I think it's promising,

Elyse:

Going back to our, going back to our story early Salesforce days, we've coined this design system team. Tell us about like, what were early days of developing that as a system as a thing? Where did Lightning come from? What kind of work were y'all doing then? What did that early design system look like?

Jina Anne:

Yeah. So initially when I joined the team, they had already built a beautiful looking style guide and it's actually what attracted me to join the team. I was on another team at Salesforce that they were planning to sunset, and so I needed to pick a new team anyway, but coincidentally, I was actually already in talks with this team because I was like, Ooh, I want to do this. So the timing all worked out. But they had like so back then they were using Sketch so they had a Sketch sheet that was like visually laying out all the colors and you know, they even named them. So it's almost like a visual representation of what would become the tokens at some point. And they had the style guide that was built on Angular And using I guess these days we call it atomic classes, but back then we were calling them single purpose classes, but it's basically like if you're familiar with tailwind or there's, there was what's the one Adam Morris did I'm blanking on it.

Elyse:

Umm,

Jina Anne:

it'll come to me later.

Elyse:

Not nicole Sullivan and OCSS?

Jina Anne:

No, it came after that, but he had written his own, there were a few libraries that had come out like this, but he was on the team actually, and so that's why they had gone with that approach. Anyway the thing that was interesting, a lot of the production engineers that I was talking to just were like, yeah, we look at it for like, knowing the direction that the team is going in, but this isn't code that we would use, and so we don't use any of this code, so only the design team is using this code for, like, prototyping or whatever. And so I was wanting to fix that. So we had the design tokens initiative stuff happening, I was working with production engineering to, like, refactor the code to use the tokens. And then at the same time you know, I was really hoping that we could actually have a CSS library that people actually wanted to use. And so I was, like, pushing the idea of that, and then I actually had a lot of pushback initially. People were like, either

Elyse:

Really?

Jina Anne:

would we, yeah, it was like, why wouldn't we just use Bootstrap? Or I also heard like, oh, it'll be like five years before we even implement the button. And so finally like my team and I, we were just kind of like, let's just build it anyway for us, and maybe one day others will start to use it. So we started to build it and we actually hired a CSS developer to be the main architect on it, like I had started it out, but then we wanted somebody who would like just like lead the CSS part, and then Brandon and I were like kind of focusing on some of the other aspects, like I was a little bit more design centric, he was more dev centric, so he was helping with some of the like wiring up components to React and like that kind of stuff. Anyway, suddenly we noticed the production engineers were copy-pasting our code and we were like, wait, so they do want our code! Okay, so that basically changed our roadmap because we were thinking, oh, we'll build this for us, and then we'll address some production development later, and we had to be like, okay, we need to go all in on supporting production development because they're already copy-pasting our code, and that's not how we want them to use this you know, it just became real at that point. And then that's kind of when our team, pivoted to like working on this new design system, which would end up becoming the Lightning design system. Initially we were codenaming it landmark I chose that cause first of all, it's the name of the building that we were working in landmark is like up on Market. But second of all, I was thinking like a lot of the libraries I was looking at, like Bootstrap, Foundation, they sound like starting out. I wanted something that was more aspirational that you're trying to drive towards, so I was like, I like landmark cause it's like, you're looking ahead. And so, yeah, we were calling it at landmark for awhile. And then at some point we knew that we probably wouldn't be able to launch with that. And so we were actually just going to be the Salesforce design system. And so little known fact, the design system isn't called Lightning, like as a title of the design system. A lot of people think that, you know, they named the product Salesforce Lightning. So we were the design system for Salesforce Lightning.

Elyse:

The more you know!

Jina Anne:

Yeah, so a lot of people think, oh, Lightning is the design system. Like, no, Lightning is a lot of things. The design system is just one piece of that.

Elyse:

I found Adam Morris[css library]' it's Tachyons.

Jina Anne:

Tachyons! Thank you. Yes, that was it.

Elyse:

I did have to look it up.

Jina Anne:

There's a, if you look at Tachyons, it's basically the old school version of what Tailwind is now. Same concept.

Elyse:

I think it's so interesting when you were just talking about that, thinking about modern design system discourse, and this whole conversation around adoption, I just really want to call out what you just said about, you know, we started doing this thing, and then we discovered that the production developers were using it we were ready, kind of without our knowledge in a way that was probably a real pain in the ass for them. And I don't even know if I have anything profound to say. I just think it's so important to realize and remember that that is the value that a design system really should be bringing. It should be something that is helping your designers or your developers in a way that makes them like, yes, I would so much rather be using this. And, you know, the tools in the industry have changed a bunch, not just within design systems, but without, right, like the development ecosystem. But, you know, I think, when we, especially in these early days, we're solving these problems, we were really solving a pain point that developers were like, oh my God, you mean I don't have to try to figure out how to style this myself, you mean I can just use this and it will look like how my designer intended it to be. That was really powerful. That's really cool. And I, and I think we get so distracted these days about like, what is a design system, and how do I make a design system, that we've forgotten that that's what it's supposed to be like, that you're supposed to be making something that your team is like, oh my God, give it to me now.

Jina Anne:

It's funny that you say that because the two people I mentioned before, the one that said, oh, it'll be like, five years before we implement, he ended up becoming one of our biggest, supporters and partners and champions on the production engineering side and yeah, he was just wonderful to work with. The other guy who was like, oh, why wouldn't we just use Bootstrap? Like fell in love with the design system so much that he ended up inheriting the team under him, so he ended up becoming the VP over it at some point.

Elyse:

Eat your words, man.

Jina Anne:

Yeah. And so it's just like, Oh, feel differently now, huh?

Elyse:

Yeah. Yeah. I was like, look at this cool thing that we made.

Jina Anne:

Yeah.

Elyse:

That's so cool. I, if I remember correctly, this is probably, you said 2014, so this is kind of like 2014, 15, 16. Tell me how ClarityConf got started. How, how did we get to this moment where design systems was enough of a thing in the whole industry that you were like, I'm going to have an in person event,

Jina Anne:

Well, yeah, it's funny. So I bought the domain name actually in 2014, but it didn't actually launch the first event until 2016. So initially when I was like, I think I put up like a little, like newsletter signup page for more info. I think I actually called it initially a style guide conference instead of a design system conference. Now I'm curious if we can find that version of it up still. But yeah, so I I had pushback in the community, I remember somebody on Twitter, it was like, really, you're gonna have a whole conference just about style guides. And I'm thinking like, well, there's whole conferences dedicated to specific, you know, libraries or specific tools, like why not? But yeah, so I was doing meetups. You know, I had the Sass meetup, which you had spoken at at one point and I also had around that time was like starting up a design system meetup as well. I'd been speaking at conferences and then I'd volunteered at a couple of them. And then, when both of us helped out with SassConf, I helped out with some swag stuff, and so I kind of got the taste of like what organizing might be like, and one of my meetups actually had like 200 people show up and I was like, this is conference size. Yeah, it was because the speakers was Nicole Sullivan and Mark Otto.

Elyse:

Oh,

Jina Anne:

So,

Elyse:

that's a OG CSS people, Bootstrap creator. Yeah. No wonder. No wonder.

Jina Anne:

Yeah, it drew a big crowd, but I was like, okay, maybe I could try my hand at organizing a conference. And so, yeah, as I mentioned, I bought the domain name and I was like, figuring out the plan for it. Just chatting with various people about it. But I still was like, really nervous about doing the that first one because I, as far as I know, I had never seen any other conference dedicated to this particular topic. And so I just kind of, at that same time the Alamo Drafthouse in San Francisco had just opened and I was like, Ooh, how cool would that be? And was surprised to find out that it was a rate that like, I would be able to afford with the ticket sales and all that. And so I was like, well, let's give it a go. And it was kind of a nice place to start at because when you book a day event like that, they come with food and AV, and so that takes care of two major parts of running a conference. And so it did make it a lot easier starting out there. But yeah, it went surprisingly well. Lots of really good feedback.

Elyse:

Yeah it was one of my, it is one of my biggest biggest career regrets, that I wa s getting married that week and didn't didn't make it. I'm still like,

Jina Anne:

But we brought you on the second year.

Elyse:

know, I know, I know. But still, I was just like, go to my own wedding or go to ClarityConf. It was a really hard choice.

Jina Anne:

Yeah, well I think you probably made the smarter choice.

Elyse:

My husband would probably agree with you. What do you remember from those, that first year of talks? I mean, obviously you can go look at the ClarityConf site, you keep up all the old talks which is amazing, all the old talk abstracts, but you know, what do you remember content-wise from those early 2016, 2017, the early content that we were diving into.

Jina Anne:

Yeah. You had some people that were already pretty knowledgeable about it, but a lot of people were just kind of like getting into things, and so having Brad Frost give that first talk, which is kind of sort of set the tone of like, it was that the thing is design systems, the time is now, you know, and he goes into, like, breaks down, like, all the bits and pieces of like, what a design system is, why you need it. And then I was like, okay, now that talk is done, don't need any more talks like that. So everything else can like dive in. And I knew that I didn't want every single talk to be about design systems, because I wanted there to be extra content that would be useful. So things around accessibility or whatever just seemed like might be important to know as a design systems person. I had a lot of and I hate to say it, but usually dudes that would reach out wanting to speak, and they all wanted to kind of do like a show and tell of their latest design system that they launched, and I had decided, I don't really want this conference to be a show and tell. I want everything to be like everyone can take something away, and like, we've all seen a design system. So if you're up there saying, we just launched this design system, here's our colors, here's our buttons, yawn, so that's why I never really and if you're one of those people that submitted that, I'm so sorry, but it's just not the approach I wanted to take, so.

Elyse:

No, I love, I love that that was very intentional for you, because I think that's one of the things that made Clarity so great as an event, was there was very little to no content that was like, let me pitch you on this thing that I created, or like, let me just show you the thing that I did. I think the content was, start to finish, inspiring or theoretical in a good way, right? Like, what is the concept, the philosophy or just kind of like eye opening, like, oh, how do I actually do this thing, rather than just like look at a thing?

Jina Anne:

And then I liked the idea of having like sort of a inspirational keynote to end on. And so I was really excited because right around that time, the NASA Graphics Standards Manual, had just been re released and all the design, like nerds were like collecting this manual. And I just like cold emailed the guy, I was like, would you be interested in speaking at my conference? And he got back to me. I was like, yeah, I would love that. And it's cool. Cause he, he actually just released his memoir, like a month or two ago, and Clarity is mentioned in there, and it's really cool, cause he, it basically, this guy's like at the time, I think he was like 84. And so he was still a practicing designer, but this like kicked off more speaking, and so he was just like speaking everywhere, and he actually yeah, like the fact that he's still practicing and his work is still going into space and stuff is like really cool.

Elyse:

That's amazing.

Jina Anne:

So anyway, everything was kind of like stuff that I was interested in the moment. I had to talk about motion design, because that was something that we were currently trying to tackle at work. Claudina was giving a talk around organizing components and stuff. I used to always put my CSS in one place, my JavaScript in another place, and she was the first person that made me start changing to where I wanted all my component folders to have everything related to that component in that folder.

Elyse:

Pre React, pre component, pre-JSX. And I was like, this was like a big deal, you know, and I

Jina Anne:

Yeah,

Elyse:

just can't emphasize enough to people who are, you know, either new in your career or new into design systems. If you've come into this landscape, in the last couple of years, with React, with JSX, it is so self evident to you that you make a component and all of the stuff goes together and the functionality and the tokens and the variables and the CSS and like, whatever. It was so different at that time. when you started Clarity Conf, most companies were not fully on board with the React train, right, you basically started a new project or were migrating your project to use React, you maybe started on one little part, or like one new area. It was like a big migration. And so these conversations that we were having around oh my God, let's put the style part and the code part, the CSS part and the JavaScript part, and functionality and the HTML, like this was shockingly novel,

Jina Anne:

yeah,

Elyse:

is so funny to, you know, looking back now, it's like, well, of course.

Jina Anne:

Because I come from especially having worked at companies that were really into like Sass and Ruby you know, everything was like very organized, there was literally a folder called stylesheets, and like all the styles would go in there, and then it felt foreign to me to have things not in that folder, It's kind of funny because like 2016 is a long time ago, but it's still not that long ago, but so much has changed since then. it's wild. Like a lot of my thinking and how I approach things has changed since then. But there's still things that hold true.

Elyse:

Yeah, absolutely. I think a lot of the foundational, the concepts right that we were really establishing then about, you know, what is the component? What should it do? How do we, you know, put these concerns together? How do we keep them separate? How do we abstract things? What's too much abstraction? What's overcomplicating? What's too genericizing, I think a lot of that still holds really true when we think about, you know, a piece of any size that can be reused.

Jina Anne:

Right.

Elyse:

So, thinking back to that time, what were the changes that you started to pick up that made you feel like, oh, this is going kind of, mainstream, in the minisode for this podcast, I was talking about Gartner, in the fall of 2024, they actually put design systems on their hype cycle graph and it's not even fully peaked yet. So obviously we're coming from inside the niche, you know, where 2016, we were early adopters before design system would have even appeared on the Gartner hype cycle graph. but I still think that there was a lot of movement in 2017, 2018, 2019. I feel like suddenly design systems became like, companies were like, we need a design system. We need to hire a design system team. And it feels like it happened really fast. what were you picking up on then that was making you go like, Oh man, this is like a thing.

Jina Anne:

There were a couple of different things. First of all, watching the Slack blow up from like 12 people to thousands of people in a very short time span was wild. So there's that one indicator. But then also, you were just seeing so many people starting to put theirs public that used to be it something not too many companies would want to do because they're always worried about proprietary, you know, confidential, whatever, but I think it started to become popular to do that. And so it felt like almost every day somebody was launching a new one. And it was really, really cool to see that. And then also just the number of design systems tools as a product that were starting to come out. I think a lot of us were custom building stuff because none of this stuff really existed. And now it was like, oh, now you've got this tool or that tool or that tool.

Elyse:

Storybook

Jina Anne:

Knapsack,

Elyse:

zeroheight

Jina Anne:

Yeah, zeroheight. All of that.

Elyse:

Yeah, and I mean, those are kind of the winners, those are the big ones but there were all kinds of smaller tools. There's

Jina Anne:

so many.

Elyse:

First it was Sketch, you know, Invision was really big, and Figma came out and I, I think you're right, the way that we created and grew tools for ourself

Jina Anne:

Mm Mmhmm.

Elyse:

was a flywheel for also being able to do the thing. It became easier to do the thing, it became faster to do the thing. Once we got to another little kink, we were like, Oh, let's build another kind of tool, and those things were growing and there really was an audience for it, and it was really cool to see just, how fast that was. I mean, I think it was like, five years.

Jina Anne:

Yeah, it was really fast. I really wish I had a time machine sometimes, I think it was like 2012 ish, I was actually pitching the idea of a style guide product to somebody, it was basically a tool that would help make it easy to document and organize, you know, your styles and all that stuff, and the devs I was talking to said it was too niche, and it wouldn't sell. And so we didn't do it. And now I see all these like million and billion dollar companies, and I'm just like, Damn, we would have been early.

Elyse:

Too, too early, Jina.

Jina Anne:

Yeah, that's the thing. I was too early, but yeah, I kick myself about that sometimes.

Elyse:

Well, when you, when you get your time machine, let us

Jina Anne:

know. Yes. Okay. Will do. But yeah, and then the other thing I think was, you would see like some key people doing a lot of stuff for the community, but then there was this explosion of so many people were contributing to the community. So that was another big thing where I'm like, wow, this is really like. You know, it's so hot right now. So, I mean, the fact that there's been design system awards, there's been, you know, there's a university, there's, there's just like everything that you can imagine, there's a design system thing for it.

Elyse:

think for me, the moment that I realized, oh, like this is a capital T thing and this is more recent, this might be like more 2019, 2020 kind of era was realizing there are new grads, like, first job, being like, I want to get into design systems.

Jina Anne:

Yeah.

Elyse:

And I'm just like, whoa, that was not possible, even couple of years prior to that. That really blew my mind.

Jina Anne:

Yeah. A few weeks ago, I was a guest speaker at CCA, which is an art school here. Josh Silverman's like one of the chairs of the design program there, and so he invited me to his class and yeah, they were like asking me about getting started in design systems, and it just like blew my mind. Cause it was like, when I was in art school, like this wasn't even a topic.

Elyse:

Yeah. What did, what did you tell them? Because I'm kind of of the mind that you can't and shouldn't do design systems if you've never built any products.

Jina Anne:

I was real with them, I was like, look, like I've enjoyed my career in this, but I will tell you, it's kind of hard, and I told them some of the realities, of like you being seen as like doing the supporting work and not leading the work. And so, you know, growing in your career sometimes can be more challenging depending on where you land. I was like, I'm not trying to scare you in this, but I'm just being real, you need to love this to go into this.

Elyse:

Yeah. Truly, I think every product designer, and, many engineers would really benefit from spending some time thinking about how components and systems work. And how these processes work, and how you actually standardize the, building of UI. And I think a lot of people who are in design systems or less permanently really benefit from product. Like I took a couple of years off. I built my own business. I actually did some product work. I freelanced for a year and built an entire product, like design and dev, and coming back into design systems, I was like, oh, right, building a product made me remember all the benefits of having a design system are, and like why it's actually useful. I think these days, it's so easy to think of a design system as, I made a Figma kit and I made a couple of React components, I made my own little, you know, miniature material UI, like done, I'm done. I did it. I made a design system. And you know, it's like, well, that's a nice portfolio project that you just did, but the reality is a lot more complicated.

Jina Anne:

Yeah, exactly, and that's the whole like thinking of design systems as a thing, versus thinking of it as a practice. And I always try to remind people to stop thinking of it as a thing, and think of it as a practice, because there's more to it than just the thing that you ship.

Elyse:

Yeah, but that's hard, Jina, we don't wanna

Jina Anne:

Yeah, do I know.

Elyse:

That's like people work and process, and talking, sales, and like, man, that stuff's hard can't we just make components?

Jina Anne:

Believe me, like there are times where I'm like, I miss when I would just push pixels, but then I'm like, do I really want to go back? Grass is always greener, I guess.

Elyse:

So when would you say was like peak design system? have we not even reached peak design system yet? Or is that still to come?

Jina Anne:

I saw a leader that works in the previous organization that I worked in, I won't name which one, but the posts that he posted on LinkedIn, felt like, yeah, we did all this design systems work, but was this really the right work kind of attitude, and I feel like a lot of people are taking sort of a negative view of design systems.

Elyse:

A lot disillusioned, like, the broken promises of design systems, like

Jina Anne:

Yeah, I'm seeing a lot of that kind of stuff, and, you know, I'll be honest, I'm also, burnt out and jaded from doing this for like 20 years, and I have my own cynical views, but, I definitely don't think that this was a mistake or broken promise or anything like that. It kind of comes back to balance, which I think I touched on earlier, people going too far into this, that they're focusing on the wrong things, and then, yeah, of course you're, not reaching the goals that you wanted to achieve, because you're focusing on the wrong things. I was going to save this for the spicy take, but I'll just talk about it now.

Elyse:

No,this is a spicy take podcast, we love it

Jina Anne:

Okay, cool. Great I kind of jokingly said earlier, like, created a monster thing, but I do wonder if we've kind of I hate to use this phrase, but I can't think of a replacement, but shot ourselves in the foot, where we've taken on too much as practitioners. We're basically maintaining product quality, we're making sure it's efficient, but these are things everybody should be doing, and everybody should be working on that works on the product. But like, what I have seen, and especially in some of the organizations I've worked on, the design system team kind of becomes too responsible for things, and they become a bottleneck, like all the quality reviews are going through the team, and then the team can't ship at a rate that they want to ship at, because they're, constantly having to pivot as the company objectives are pivoting. And then the company looks at the design system team, it's like, well, what have you really done for us? And it's like, are you kidding me? Like we've done everything for you.

Elyse:

Yeah, yeah.

Jina Anne:

So when I have my own jaded feelings, it's really around that. It's like, I feel like, we have taken on too much and it maybe has hurt us. it's like, how do we balance this out better, where we're sharing, we'll help guide the work, but we should be sharing this responsibility.

Elyse:

Yeah, I don't think there's any maybe about it. I feel like you just summed up the whole reason that I wanted to start this podcast and the kind of conversations that I want to be having on this show, because we design systems practitioners and design systems teams, and you know, if there are broken promises around design systems, like it's been us making those promises. It's been us saying, yeah, we'll take that on. Yes, we'll increase our scope. Yes, we will, review every design, we will become the design police. We'll be responsible for all of this stuff, and, then we wonder why our execs have this idea that a design system is supposed to be 100 percent of your front end code. And, know, it, it's absolutely appalling that you think a design system team could and should be reviewing all of the designs especially as a team gets bigger or like an organization gets bigger, like that is such a misunderstanding, I think of the value that a team like this can bring.

Jina Anne:

And it's and it's not just reviewing designs, but what I've seen is like, you basically become the frontend shop for the whole company. Like everybody just assumes all component.

Elyse:

Oh, I need this feature, it's a component, put it in the system and then we'll build it.

Jina Anne:

And you become this component request machine and it's just, yeah, I've seen it in all sorts of different forms and factors at various companies, and we need to find a way to like, have a more realistic impact that isn't burning us out and having us take on too much.

Elyse:

One hundred percent agree. I mean, there, this, is what I think of as peak design systems, right? I think this was like twenty nineteen to twenty-two, was the era of that, of like, we're going to have this massive design system team, we are going to build any component that any feature team might need so that it can be in the system. And then we're blocking their releases. I really, really hope that we can, I don't want to say get back on track, but I really, really hope that we can adjust the way that we talk about design systems in organizations to ourselves within our niche but especially within organizations and to teams. Going back to, you know, 2013, 2016, like we were so excited. I say, we design system practitioners, were so excited because we were seeing things like, we started working on something and all the engineers were like, Ooh, gimme. Ooh, can I have that? The designers were like, ooh, I want that. Ooh, make me one.

Jina Anne:

Yeah.

Elyse:

It was so exciting because we were actually really providing efficiency or consistency. In the podcast episode with Brad Frost, he said something that has really stuck with me, and he said you know at the time, efficiency was about respect. Efficiency was like, it is not a good use of your time and your expertise and your intellect to be updating the hex value on 800 pages. Like we can automate this we can find a better way to do it and efficiency is such a capitalism buzzword now, he just called out like, that was a problem. Like that was a thing. We were solving a really different problem then. And I think it's 2025 like what problems are we solving now and how do we do that in a way that makes more sense?

Jina Anne:

You know, one of the things I was concerned with at one of the previous roles that I had where I was managing a team. One of the leaders that was trying to help give us like our mandate, basically like what he wanted from us, and it was accelerate. And I was just like, Oh my God, we're already trying to champion, efficiency, like how much faster can we go?

Elyse:

And like, all right, we're running. Oh, well, since we kind of naturally got here, I'm curious where do you think design systems as an industry, a practice, where do you think we need to go in the future? What are some of your hopes or wishes you know, that you think would be an improvement?

Jina Anne:

I have given a couple talks about this, but with everybody talking about, AI and all that, usually they're talking about, generating components or code and stuff, but I'd really like to see us find ways to potentially use AI or machine learning to actually deliver a really custom experience to our end users. That's what's really interesting to me. And it's like, yeah, we've been designing buttons and cards and tabs, but how can we actually deliver, the best UI that that person needs in that context, in that time, in that place, all of those things. This wouldn't be something only on design systems, it would obviously be a collaboration with product, but I'm really excited about the potential of what could be done

Elyse:

It's such a natural fit, I think, for design systems, though, because if you think about even at a simple kind of component level, like to be able to say like, oh, you know, it's not just a primary button or a secondary button or, a card like this or a card like that. It's like, oh, can we pick up what's happening in their browser? You know, dark mode, light mode is a really, really simple one, but you know, I'm just thinking about very, very simple things that could be in a design system that have nothing to do with business logic.

Jina Anne:

Right. but parts of it could be based on personalizing, so it's like, am I left handed? Am I right handed? Can we change the UI to make it more comfortable for left handed people? I haven't really seen anyone really explore that fully. And obviously, you know, people are really into like consistency, the button's always in the same place. I'm like, well, does it have to be in the same place for this other person? You can have consistency for each person, but maybe it doesn't need to be across all people. So I'm excited about that. The other thing that I think is more of a community thing that I'm hoping for is just to see us help support each other in our careers more, as a community, because I feel like design system teams are often hit during layoffs, and obviously I was hit by one not long ago and you know, obviously we want to share tools, we want to share products and things, but I'd love to see us share more like helpful resources so we can grow in our careers. I feel like that was such a, like, Miss America type answer, but I just really feel that way. You know, I want to see more of that.

Elyse:

Well, you know what? We'll allow it. We'll allow it. You can, you can be our design system queen for all the whole time, really. No, it's true though, because design system work can be, there's a lot of words people use, right? It can be lonely. I'm a team of one. you know, I have an amazing team, I love my team, I love my company, they're fantastic. There's a couple designers and engineers who, I really do get to spend time with, thinking about, components and processes and systems. I'm still the only one who's responsible for this in my company. Even when you have a team, you have a team of three, five, I don't know, 10, somewhere big, but you're still so small in comparison to, your whole organization. And, you touched on this with the layoffs thing, like, you're not necessarily the work that's getting really highlighted or, you know, shown in all hands or, you know, connected to a KPI or, you know, conversion metric or a dollar metric. And so I think a lot of us in the design system space have had this experience where we're like, individual people may be telling you like, oh, this was really helpful, or I learned a lot, or I'm so glad to have this tool. But it can also be very hard to justify your work or talk about it in a way that really shows the value of what you're bringing. And especially as again, in that peak design system era, where it was like suddenly like design system teams were responsible for like the entire design quality of the entire product, and you're just like, at least I need somebody to gripe with who understands my complaints, And not like product and feature designers and engineers don't have their own frustrations, but you know I think there are a lot of really, really great spaces and I would love to see more. Obviously Design Systems Slack is a good one. You know, Ben Callahan has been doing The Question, which is a really, really, really great community space. Sil at Into Design Systems is making some really cool events and really cool meetups that they're bringing back. So I think there are a number of, of them, but I, yeah, full support. Like, I want to hang out in person with design leaders. Knapsack was doing those Design Leadership Summits, that was a great, really small group. I want more of that in, the future.

Jina Anne:

Yeah, me too.

Elyse:

Are meetups back? Can we bring meetups back?

Jina Anne:

I would love to find a way to bring meetups back. I just got to figure out location.

Elyse:

Let us know. We're, we're, we're, we're so excited. Jina, this was so fun. It was such a fun little like walk back through history. You know, I think it's so important to understand where we've been when we think about where we need to go in the future. And I think you really hit the nail on the head earlier when you were talking about some of the really negative, you know, pessimistic, like, did we screw up with design systems? Like, did we, was this a terrible, terrible idea? I think the future of design systems is really bright. I think that this is, you know, this is a thing that I totally stole from you, but you know, this is just how we build UI now. This

Jina Anne:

is the

Elyse:

way that we are doing things. We're using components. We're reusing things. We've got design and code tools that make that easy. And I don't think you can put that back in the box. Like, this is just how we're going to do it. So how do we do it in a way that is valuable and shows that value and isn't an absurd scope that burns the design system team out and doesn't actually do what they wanted. So thank you so much for taking us through it all.

Jina Anne:

Yeah. No problem. Thanks for letting me blab on! Back in my day!

Elyse:

Get off my lawn, kids these days with your tokens. Okay. To wrap up, I am asking everybody who comes on the show to give us a Jina spicy take on design systems, no notes, just tell us like the spiciest take you got.

Jina Anne:

Oooh, I might get some hate for this, but, I'm just gonna say it.

Elyse:

See

Jina Anne:

it wouldn't be a spicy

Elyse:

take if it wasn't going to make somebody kind of like, pissed.

Jina Anne:

People at Figma, please don't be mad at me, but I don't think any of our design tools are there yet. I still look at, design tools as like a communication tool and not the source. And it makes me sad that I see so many people spending so much time in these design tools, like getting it pixel perfect, when it's just going to get rebuilt. And I don't see it really truly connecting to code yet, so I'm not a fan of current design tools.

Elyse:

I'm a hundred percent here for this take. no apologies. There are zero apologies for spicy takes. You know, I think you're so right. Design, we're making a picture. It's not a true representation of the actual product, which is built in code. As I've been talking to guests on the show, like, this topic actually has been coming up a bunch because it is a communication tool and we're doing all this work to generate code off a picture, and I'm like, yo, we already have the code.

Jina Anne:

Yeah. Do it in the code.

Elyse:

Yeah. I think there are some big changes that are gonna happen over the next, let's say, three to five years. Obviously Figma is doing a ton of work. I was actually checking out Penpot, which is doing a ton of cool things.

Jina Anne:

Oh yeah. So Penpot actually uses CSS grid and flexbox instead of just, you know, vector layouts.

Elyse:

Say more.

Jina Anne:

I want to play with it because when I heard that, I was like, Ooh,

Elyse:

Ooh.

Jina Anne:

But yeah, and you know, I do want to shout out Webflow, I think they do a good job with their product and I wish our product design tools could be more like Webflow, where it's actually code behind the scenes. That would be amazing.

Elyse:

I think we're gonna get there. I we're going to get to a place where we are really working much closer, you know in, in the medium, I think it's inevitable. I don't know what that looks like, but I'm really eager for that future too, because I think a lot of design system work right now is like replicating stuff in Figma. And to be clear, I don't think it's Figma that's the problem.

Jina Anne:

Yeah. And that's why I kept saying design tools. I didn't want to put all the, you know, aim at Figma and I do love, you know, you guys, Figma, if you're listening, I love you.

Elyse:

I mean, it's a really incredible tool, and, regardless of what tool it is, man, if we say the words bridge the design and dev gap one more time, like we still haven't really bridged that gap.

Jina Anne:

Like, get rid of the gap. Don't bridge it. Just get rid of it. No more gap.

Elyse:

Oh, well, amazing. On that note, Jina, thank you for your time, your work in this space, your influence of over the last 10 plus years, 20 years. Just such a pleasure. Thank you so much for coming on the podcast. And I can't wait to talk to you again in the future and see what has changed.

Jina Anne:

Yes. Thank you so much.

Thanks for listening to On Theme. This is a brand new podcast, so if you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!