Why Design Systems Are Important And How To Use Them

January 09, 2020

I just gave a talk at a meetup last night on design systems — why you need to know what they are, how to use them, and how to build them with React. It was something of a high-level overview, given the time constraints of the talk (it ran about 37min) but we were able to get some good info packed in there.

And the slides for this presentation:

A quick note about recording — this was filmed on my iPhone X at 4K, with audio captured by the Airpod you can see me wearing in the video. Unfortunately, the iOS’s default video recording app isn’t actually able to capture audio from Airpods (believe it or not) so I had to buy a $15 app to record with (Filmic Pro). It’s good value for the money though because I was able to easily record the whole talk and then upload it to my Mac with Airdrop almost instantly.

Transcript

Elliot: Hey guys, if you guys wouldn’t mind, I think we’re going to go ahead and try and get started with the talk now. So the chairs are pretty comfy. They’re reasonably comfy chairs. Please find out how comfy they are, for yourself. Thank you.

Elliot: All right, well first things first. Thank you all so much for coming to the kickoff for this event. This is going to hopefully be the first of many of our React RI Meetups. And I’m really impressed by the turnout. There’s a lot of folks, so hopefully this is going to be something that everybody gets something useful out of and that you guys all enjoy. As you may have read on the meetup description, we have a keynote main presentation, and then we’re also going to have just a couple of shorter talks after that, just so we cover a little bit of a range of interests and hopefully levels of skill and all that.

Elliot: So yeah, I’m going to start off the first talk. It’s going to be called, well, I mean you can read it right there. I’m going to be talking about design systems. I don’t know how many of you guys are familiar with design systems, but it should be about 30, 40 minutes. So settle in, buckle up. There’s going to be some time for Q and A after as well. So I would just encourage you, if you have a question, hang onto it until the end and then I can answer them all then.

Elliot: So, from a developer’s perspective, I am not a designer. I don’t think we have many designers in the room. So I’m going to talk about more of implementation and how to use a design system as a developer, than I am going to be talking about how to make one from a design standpoint. So let’s jump in.

Elliot: So we’re going to talk about what design systems allow, and why they’re important. So basically, how they came to be, why are design systems a thing? How did they come to be? And also what are they made out of? What’s the design system actually, and we’ll talk about a really small one and show how that scales up to the really big design systems.

Elliot: So a design system, if you’re not familiar with the term, it’s a system of … What’s a good way to put it? Well it’s a lot of stuff. It’s actually, it’s really hard to explain, but that’s kind of coming in another slide. And I’m going to tell you really quickly why I’m able to speak to design systems. So I’m a react developer, like a lot of the folks in the room, I like to work with new projects. So I’ve worked on three different design tools over the last four or five years in the design space. Some of them are targeted at closing the gap between design and code. So allowing designers to develop and allowing developers to design. And you’ll find more and more of that, it’s kind of a key component of design systems.

Elliot: One of the tools I worked on Marvel App back in 2016, Marvel App is a competitor to tools like Invision and Figma that allow you to build out prototypes and wire frame a app or website when you’re in the design phase. So these are tools that are really heavy into the design space. And Marvel App back in 2016, was brought a speaker in to do a talk on what design systems are internally, because they were going to inform how we were going to go about our work in the development of our tool. And so that was really where I was first introduced to design systems.

Elliot: So to answer my question from before or my confusion from before, “Oh what the heck is the design system?” It turns out that a design system is actually really hard to define. There’s a lot of different … If you Google what’s a design system? There’s a ton of different definitions and pretty much everybody disagrees on something. There’s some people that call it a contract between the designer and the developer. The designer says, “I want my font to be 24 pixels or 16 pixels.” The developer says, “You want me to type that in every time? How am I going to keep that straight? How am I going to keep my junior developers using 24 and 16 pixels from my font sizes?”

Elliot: So this is one of the things, so well is it a set of JSON data then that maybe we said font size one, font size two. Is it like a compilation of values? No, that’s not really what it is either. People have no idea what the heck the thing is. It’s not a style guide. It’s not a pattern library. It’s not even just like a collection of components. You might have libraries of inputs and dropdowns and scroll bars and all things like that. It’s not that either, because there’s really more to it.

Elliot: So I mean, what is … if you look at all the different example design systems, there’s all sorts of different things. It’s philosophy about how to design. There is actual font sizes and gutters and spacing sizes and different components which use those. There’s so much. And it’s really not, when I was writing this talk, there’s no way to define what one actually is. So I think it’s better to actually describe it in terms of the challenges that it was created to solve.

Elliot: So what are those challenges? And to talk about the challenges is to actually talk about where design systems came from. So unfortunately, we do need to talk about design, because that’s what give rise to design systems. So design is, it solves a couple of things. It’s about a couple of things. It’s about branding and it’s about usability. I mean there’s probably other stuff too, but what the heck do I know? I’m not a designer. But these are the two primary things.

Elliot: So brand. Good design will tell you about the company and it’ll allow you to recognize that company anywhere. Usability. You obviously want your tool or website or whatever to be able to be navigated, to be used, to allow somebody to go from point A to point B. And that’s what your users want to do. So you’ve got these two things.

Elliot: When you get a large company, one of the challenges with doing these two things, is keeping your design consistent and coherent. And the reason that’s important is, you want to have a consistent brand so people know who you are, wherever they see you. And so people can use your app wherever it shows up. So you might be targeting a lot of different devices, portals, platforms. I mean if you are, let’s say you’re Hertz, the rental car company, you’re going to have a phone app, you’re going to have a website, you’re going to have a tablet size version of your website for the business guys with the iPads. And like I said, a mobile app, and you might have an Android mobile app, you might have an iPhone mobile app. So how do you keep your design language consistent across all of these different platforms?

Elliot: And this is a problem that people are having as web is becoming more and more complicated. Used to be you just called a guy if you wanted to rent a car, now you can do it all through a website. And that’s been enabled by the technology that is growing and the web that’s growing. You also have, if you’re a company like Hertz, a lot of different developers and a lot of different designers working on your application. So you need to have some way for them all to agree on what the design is going to be. And if you’re a smaller company, or if you’re a startup or if you have a lot of different ventures, you also need to be able to keep up your iteration speed to. You need to be able to say, I want it to look like this, and I want it tomorrow, if you’re a corporation, because that’s what they like to do to us, right?

Elliot: So I guess if you look at it in light of the challenges, the design system is actually a tool. It’s a tool that allows a company to maintain consistent brand identity and good design at scale. And so what’s in a design system? Suddenly it’s kind of easy to define. It’s anything that helps you do just that, helps you keep all this stuff consistent and usable. And that might contain a style guide, it might be designed theory and philosophy and principles, and things that the company wants to say, this means the me. I mean maybe one company likes the color blue, and they say blue is important because it enables user trust and it makes people relaxed. Or maybe you’re a company that’s a bit more aggressive and we want to be red so that our competitors are afraid of us or something like that. So design system will have all those different shades of red or all the different shades of blue, because you might have your primary color, but then you’ve also got a bunch of other colors that you just need to have a usable design.

Elliot: You might also have a set of design tokens. Design tokens. What the heck is the design tokens? It’s up there on the board. But basically it just means a set of values that represent your design, that are platform agnostic, system agnostic. So you have your font size is going to be 24 pixels across iPhone, Android, web, tablet, website on a mobile phone. So you got these design tokens. You also need a way to use those tokens, because if they’re stored in the system agnostic data structure, you need some way to transform that into system specific data structures. Because you can’t just say iPhone and you can’t define the font size on an iPhone and an Android with the same piece of code. You need some way to transfer that 24 pixel value into pixels and points and whatever the heck … I’m not an iPhone developer.

Elliot: So you need a way to consume those. And then also, if you’re a really big company and you want to enable that fast developments, be that high iteration level, you want a component library or libraries that consume those values, and just present a button and a scroll again, and a dropdown and a text input and whatever else people use your website to do.

Elliot: And then sometimes there’s a lot more also with bigger companies you might have Sketch and Figma designs you also need to use this stuff. You have lots of icons and pings and SUG’s to contain those icons and you probably also have a lot of literature that your designers have written up over time about why it’s so important to have 24 pixels instead of 22 pixels. And that’s a really big deal if you’re designer apparently.

Elliot: And then, you might extend all the way up to having entire libraries for incorporating this. So Material UI, I’m sure a lot of you guys have use or heard of Material UI. Google has built a way to allow you to consume their system and design tokens across all the different platforms that they want to support. Windows as well; Windows fluent, that’s a design system that Windows developed. You can use that same design system across iPhone and Android and all the other platforms, like I mentioned. It’s the exact same set of values and you can do it by importing your library, so easy.

Elliot: So some other ones, Carbon. IBM is doing a system called Carbon. GitHub Primer is their development, their design system. Shopify has Polaris. So as you can see, there’s a ton of these, and all the big players are building and using design systems to solve those big problems. So they’re here for a long time, they’re not a fad, and they’re not going away anytime soon unlike Angular 2.

Elliot: So we probably need to learn this stuff. And that’s why this is a useful subject to talk about in my humble opinion. So where did they even come from? So the design … They rose to solve these challenges as the web grew more and more complex. We used to be able to just write HTML and CSS. I’m sure some of you remember the good old days where it was just start typing some stuff in, saves the HTML file and put it up on the server with FTP. That’s not the case anymore. If you want to be industry standard, you’ve got to have like a bazillion different libraries in a three mile long development and deployment pipeline. And there’s a lot.

Elliot: So pattern Libraries, Sketch symbols that you’re exporting from Sketch into whatever kind of design system that you have. These things slowly began to become more and more sophisticated as the challenges grew as well. And there was always like a little bit of a lag, which is why you have crappy looking websites. But hopefully they’re going to be gone soon.

Elliot: So, and then there’s also this trickle down effect, and this is why it’s important for not just the corporate guys to be using this stuff. Us like starter developers, it’s like I said, I worked at a lot of startups. Startups now are adopting this kind of stuff, and why? Well it’s like I said, it’s this trickle down effect. As the industry standards are getting higher, higher and things are becoming more sophisticated, we actually are going to be able to take advantage of that. It’s driving tool development and it’s driving all this stuff forward and it’s trickling down to where, now we don’t have to develop this whole huge system. We can just grab the Google’s Material UI and start pulling the components out. It takes like 30 seconds and you have a professional looking design, so easy.

Elliot: So it’s because these large scale tactics are usefuler at smaller scales, that we’re going to end up doing it, even if you’re not working at Microsoft. But it might be, maybe it’s a less complete system, it’s not quite as sprawling and massive, but you’re still going to have a lot of the benefits really and allow the philosophy that’s been developed at this really high scale, it’s kind of shrink down, become compact really, really well. And we’re starting to see that with the rise of some different libraries and tools that are trending ahead of adoption, but they’re going to be used soon.

Elliot: And I’m speaking as somebody who is working on a design tool as of last year, which is really like trying to close that design and development boundary and it’s probably going to become big soon. One of them or is one of its competitors. And it takes this sort of design system thing and it puts it in an application that allows designers to export react code. But that’s just still for presentation. So no worries, we’re still going to have to write logic. But that’s coming though, just so we know, and it’s coming on the back of all of this stuff that we’re talking about, all this development of these standards climbing, pushing these huge design systems.

Elliot: So that’s really what I have for the history of design tools and what do we want to look at next? It’s really how do we do the designs of something at a smaller level? I mean I’m not going to sit there and build Material UI. I’m not a huge team of designers and developers, but if I want to take advantage of these advances in methodology and principle, what are the things that I need to do?

Elliot: So I’m going to talk a little bit about what building a small design system might look like just with React. There’s a few different pieces to it and I already mentioned it, but we’ll talk about it in just like a smaller scenario in a kind of, a little bit of a use case. And I mentioned some of the libraries too that are becoming more popular. So I’ll kind of point out a couple of those. And then if we have time we’ll talk a little bit about how we can make it more comprehensive and start building it out still from that really small. Like if you’re a developer at a startup, you and two other guys, how can we build a design system for our marketing website and for our app.

Elliot: So the anatomy of a design system, I went over this really briefly earlier, but it’s more in talking about the challenges. So just to come at it from the actual use case angle, what are the three things that make up a basic design system? Well, we have those design tokens that I was talking about. You have some sort of a system for consuming those design tokens. So anything that would be able to translate the design tokens from a static set of data into your web values. So your CSS, he might have PX, or you define your font family, Courier, Menlo, whatever. And you’ll have your spacing, how do you incorporate like 20 points into 20 pixels on your web platform and all that. And then you’ll also have components which use those design tokens which take whatever ability you’ve made to convert those tokens into platforms, specific values and actually build some components with them that make it easier for your developers.

Elliot: So that’s where the designers can really get involved, because they can say, “We want these tokens, we’re going to have this, these colors. This is our primary color this is our secondary color and you know, develop a sophisticated color scale. And then just hand it off to the developers and then work together to build the components. And then once those components and everything is implemented, a developer only, all they have to do to make the designer happy is say I’m going to use this button and that button. And we already made it together. So I know you’re going to be happy. So that’s where this idea of a contract comes from.

Elliot: But I’m getting a little bit off script here. So we’ve talked about these and so they’re often defined, you can find them in JSON or just raw JavaScript object format. Brent Jackson is somebody who is doing a lot of work on this lately. And he has developed a specification which covers pretty much the entire range of different values that you might see and all of the big design systems like Microsofts and GitHubs like Primer and Fluent and Polaris. A lot of them are using these same variable names and everybody’s trying to arrive at an industry standard.

Elliot: So he’s pretty much covered them all, font sizes. You might have 12 14, 16, 20, 24 I’m not going to read that out, it’s dumb. And color scales. So if we scroll down, you can see breakpoints. Okay. So for your media queries, for your website, if you’re going to make it fit, a phone versus a tablet versus your full desktop, you have different values at which to define. At the phone, this is how wide a phone can be before it turns into a tablet layout. And this is how wide a tablet layout can be before it turns into a desktop. So you wanted to find that in one place.

Elliot: And then so talking about all of the keys, you can see them all right here, just run your eye down. There’s a lot that goes into a font, sizes, colors, font and font weights, line heights, there’s … I don’t want to be a designer, I’m happy as a developer because there’s so much here to consider. But I do do some design unfortunately. Anyway, so those are design tokens and those are just values that are associated with all those different keys.

Elliot: Now I’m talking about actually using those values. You can roll your own sort of system just does like import JSON, add picks to end of every number of value, add … just transform all these different values for your web. And then like I said, I’m not an iPhone developer. I don’t know exactly what that would look like to bring it into an iPhone or an Android context. But that’s what this step is. You need some way to transfer that raw data.

Elliot: And you might be asking, well, why not just … or you might be thinking about asking and being good and waiting till the end, but why not just make this all in CSS and then duplicated or something into your phone values. And the answer is simply you want a single source of truth. You don’t want to have two different values for the same variable, because when you do, there’s going to be inevitably a conflict. Some designers and they think he’s better than the other designer and change it in one place and nobody’s going to see the change go through. And then suddenly your Android looks different from your web.

Elliot: So you really want to keep it to where you only have one place where all of these values are defined. And that’s really where we see from the development standpoint, these challenges being met and addressed square on. You have a single source of truth, and you have different tools which convert that source of truth into readable values for all of your different platforms, portals, systems, you name it.

Elliot: So there’s some libraries that are doing this now. We’re React guys, so I’m going to focus on Style System and Style UI. Style System is a library developed by, you guessed it, Brent Jackson again. That actually will allow you to feed it a set of JSON values and then refer to those with numbers. Which doesn’t make a lot of sense now that I say it out loud. But so I mean you might have all your different font sizes in an array, right? Like two, four … Or you’re not going to have a two pixel font. But 16, 24, 32 and then you … so arrays, your index is every font, so zero, one, and two. So you might say, “I want my header to have a size zero font, or a size two font. And want my body to have a size zero font, because everything is zero index. And then it’ll just, the system will automatically go and transform that number. It will just go and fetch the correct value out of the array automatically.

Elliot: Then it actually foists some of that work off onto React, because if you specify, in your React style object, if you specify a number without a suffix, it’ll add the PX for you. So it works. So Styled System works alongside React to help you, and that’s why it’s really more of a web based platform.

Elliot: And then if you want something for a little bit more comprehensive of a tool, you also have System UI. And System UI is a bit more complicated, it approaches really an entire design system as you might guess just from the name. Style System really just does that one thing. It’s really that one key component that helps you transform your values, your system agnostic values into platform specific values. System UI, you can just plug those values in and it’ll give you a ton of different tools for using that and making it really simple to distributed across your system. I actually really liked this one.

Elliot: And then as you can see here using it Modulz. So Modulz is one of the tools that I was working on back in the day. So they lean pretty heavily on tools like this tool here. So it’s kind of a more comprehensive thing, but maybe if we have some time, we can swing back around to that.

Elliot: So yeah, and then building components, I mean this isn’t really that complicated. You take your system, your values and your system to get the values and you build all your different components out of it. Commonly this is done in a separate repository from your main app, your components. You might have web components and you have your Android components and your iOS components, but they’re usually stored separately from the core source code. And that’s to make sure that when you update any part of that library, it can roll out to the different systems which use those components all at once.

Elliot: So typically your component library is going to be versioned using semantic versioning SemVer and you bump it whenever you update something in there. And that way, any other repositories or any other projects which pull that in, they all get updated automatically with that change to whatever component. And you might have all of your components being developed in some sort of a system that would allow you to view each component and also document that component so that you can understand all the different use cases that it has without having to go read the source code. This is really, really key for, again, that fast iteration.

Elliot: So Storybook is a common tool that’s a lot of people are using these days and it looks like this. So you might have your components and you’ve got a list of components on the left, and this is all defined in the source code. What Storybook forces you to do is describe your components in comments right in the source code, which is great because then your components are sitting right next to all the instructions on how to use them and there’s never going to be any confusion or any lack of clarity on how they can be used, the options that they support. And this really again just enables that fast development speed, especially in the larger organizations. So a lot of folks that are turning to storybook and equivalents to document and display their components in one place to then be able to quickly integrate them with their other systems.

Elliot: So wow, that’s a lot. And this is the end goal of a design system is to have something like this that you can just grab and plug and play. So what is an example of a component library? Well, I’m not going to make you read source code, but Radix is the component library that drives Modulz, which is again that one of those cutting edge design tools that I was telling you about. And this is the one that I was fortunate enough to work on at the beginning of, jeez, was it last year? I think it was last year already. Yeah because it’s 2020, the beginning of last year. So it’s a design system and a component library. And if you go into these packages, you can see you have your system. You know what? I have no idea what the heck this is.

Elliot: The components are all stored in Radix here. And you can see a Storybook, a file, which configures all of your Storybook stuff because you need to configure it. And then your components are all here. You got your box, your button. You might have a car just to display a sample. What does a car do? We can look at the Storybook and you realize why this is so useful. If we can find the Storybook, which maybe we won’t look now, maybe we can pull it up again towards the end. I should have had a link to that, but that’s my bad. But that’s one of those tools that people are using. And that’s an example of people using that tool.

Elliot: So a living, breathing design system has some tokens which are really describing the design in a very system agnostic way. Tokens are transform to consumed. And like I said, to update the design you might update a token, you might update a font size, might change the font name, and then you need to update your component library update. Typically, that library that consumes these values also distributes them as well. So you would just import that library, which converts your agnostic values and desistance specific values. I’ve said it a million times. And then, if you wanted to access those values directly without using a component library, it’ll let you do that. And then all you have to do after you’ve upgraded your, after you’ve published an update to your library out to NPM or publish your component, your component library up to NPM, you just pull it into the app with NPM, upgrade your package and then it’ll be live.

Elliot: And this again, it’s just that elaborate system. Why don’t we just write HTML and CSS? That’s what gives us the advantages to deploy a single design change across your entire suite of applications with a 100% consistency immediately, without having to change a single line of code in any one of those other systems. You can do it all from one source of truth. So that enables this iteration speed. It enables consistency everywhere. It allows a lot of developers and a lot of designers to work together at speed. And it’s the way of the future really. So I would encourage you all if you haven’t already dive into some of these, I mean go back to the examples, just even taking a look at Primer GitHubs design system is that these things have amazing documentation because there’s some people that are really passionate about developing and building this stuff.

Elliot: So you can just go in there and read it yourself and really get to come to grips with this really, this way of the future, like I said. And I think it’ll make you a stronger developer and hopefully just a little bit of a designer. I know I said I don’t, unfortunately I designed actually I enjoy it. It’s not the most horrible thing.

Elliot: Oh I did have one more slide, and this is actually pretty important too, because I’ve given you this, I don’t want you to shoot your foot off. There’s also some really good times not to use the design system, to not use this complicated quite sprawling tool. And it’s in the early cases. If you’re early prototyping phase of some sort of a startup or if you have an app, don’t go out there and get a design system. Because if you do, you end up, maybe you get stuck. Actually, you know what? I should clarify, don’t build a design system. It’s fine to grab Material UI that will accelerate you. That’s what it’s for. Or if you grab Primer or if you grab Fluent, Microsoft’s Fluent, these will enable you to build more quickly than doing all the design itself.

Elliot: Just don’t try and build one early on until you have a team. Maybe it’s better used for when you’re doing version two of your application and you’ve got an investor or you’re making money off your users, your bootstrap because you can get really, and I’m speaking from experience here, you can get really kind of locked up in package maintenance because there’s not even dealing with dependencies, and you have to update this, and pull that in over there. And if you do that, if you go down that route too soon, you’ll end up getting really just stuck in the development phase and not just get your products shipped.

Elliot: And that’s really the key here is get the product shipped. And we know design systems, the point of it is to make you faster. If it’s not making you faster, if it’s not making you better, just don’t use it. Because if you do, like I said, you’ll shoot yourself in the foot. So yeah, so use the existing design systems. If you’re a solo developer, if you’ve got a couple of people on a project. But once you get to a team, you start to see some growing pains with that, then reassess and maybe that’s the time to use the design system. But yeah, it’s just done really well by these larger companies and it’s definitely the way of the future. Just make sure you don’t misuse it. So thank you very much for I’m sitting through how long has it been? 30 minutes of just an information dump. Is anybody have questions at this point? I must have explained myself really well. That’s awesome.

Speaker 2: Yeah. I was going to ask how do you feel about a-

Elliot: Don’t ask.

Speaker 2: Setup such as Bootstrap or Foundation, which is a little different than [inaudible 00:30:44] also gives you a user set up for [inaudible 00:30:45]?

Elliot: Bootstrap is great. I mean it’s not a design system it’s one of those predesigned system tools that came along. You had some CSS frameworks and like the package libraries and stuff. I think it’s definitely worth using, especially for that view one, just to get something out the door. Because you don’t necessarily want to be worrying about gutters and margins and how to have your components stack or go mobile or whatever. It takes a lot of that and abstracts that away, which is definitely useful in the early stages. Go ahead, [inaudible 00:31:16] yeah go for it.

Speaker 3: I was just wondering if you could talk a little bit about [inaudible 00:31:21]. Just like the functions that developed this right when, like you’re talking about the guy who created that [inaudible 00:31:34],

Elliot: Style System.

Speaker 3: Right? So based on codes.

Elliot: Yeah.

Speaker 3: That seems like a cool thing.

Elliot: It’s super cool, man.

Speaker 3: And I didn’t know if [inaudible 00:31:44].

Speaker 2: No, I would definitely encourage you to read the documentation, but I’ll see if I can kind of sum this up in a quick way. So how it works, I mean, I might just read this off. So I’m not going to read it off. So it comes with a default set of values, it comes with a default set of design tokens just behind the scenes, and then you can extend that yourself. But, is there an easy way to sum this up? No, there really isn’t, man. I would encourage you to just go to this website. I’m going to publish the slides for this on my blog, and then you can just go there and just follow the links, because this documentation really is pretty self explanatory. Wesley, did you still have a question?

Wesley: I was just going to ask, how do you [inaudible 00:32:34] Style Components, but you might’ve answered that with the first question.

Elliot: Style Components sort of, and I know I include it in one of my slides. It doesn’t fit right into a design system. It’s a parallel, but slightly unrelated tool. You can build a design system completely without using style components, or you can build one that really heavily relies on styled components. For those who don’t know Style Components is a CSS in JavaScript Library, meaning it lets you write your styles directly in JavaScript next to your components, and then you can actually use your app logic to apply CSS styles in a clean and fast way. It’s a great library and it can definitely be used for transforming those values. In fact, I would say, Style Components, Style System and even System UI kind of all fall under that bracket of tools that translate your design tokens into values that you can then apply throughout your application.

Wesley: Makes sense.

Elliot: Nat.

Nat: So is that like numbers? Is it like header tags in HTML?

Speaker 2: Very much so that’s actually, yeah, that’s a really interesting observation. I hadn’t even thought of that before. Yeah, I mean that’s essentially what H1 H2 and H3 are attempting to do, only they didn’t let you define the values that they were pulling for their styles. But it’s really the same thing. You can think of it as it’s the same sort of system.

Nat: And do they allocate the type script support to see-

Elliot: Yeah, Style System does. I can’t speak to all the libraries. I know that actually I’ve contributed some typing’s to Style System myself. So yeah, it’s pretty well supported.

Speaker 6: I saw you have like Emotion vibe thing, like Emotion. [inaudible 00:34:23].

Elliot: Yeah, I mean-

Speaker 6: From my understanding, that you basically do the same thing.

Elliot: They do.

Speaker 6: What’s the driver for one versus the other?

Elliot: I think it’s whichever one you saw first. I saw Style Components first and so that’s my first love. I would never use Emotion ever. Actually I did one time, but they’re really equivalent and I really hope that the two creators of those two libraries kind of get together and really start working on the same product, because I think that would be really helpful. But no, I mean they’re really pretty much functionally equivalent. In fact, I was working on one project where I was helping a dude out. He was stuck with Style Components, he switched over to Emotion. All he had to do was change the import. He didn’t even have to change anything else of his code. The API is identical between the two libraries.

Speaker 6: Fair enough.

Speaker 7: Sorry, can you talk a little bit about your experience with startups in developing their brand, identity? And choosing a system.

Elliot: Design system?

Speaker 7: Design system, excuse me.

Elliot: So to talk a little bit about … I’m not a designer. Like I said, I’m mostly the guy that sits in front of the computer muttering under his breath all day. So I never actually was involved in the creation or selection of a brand. I would encourage you if you’re looking for what is the best design system to use for my product or my little my prototype or whatever it is you want to work on. There’s a lot of them out there. I think Material UI has great React integration, and that’s pretty much one of the most common ones. But if you don’t like the decisions that their designers have made, the other ones will also work fine. Like Primer, Primer looks different from Material UI. And Fluent looks different from both of those.

Elliot: So, but it’s really up to you. I mean any one of them will speed you up massively for sure. Rather than writing all the styles by hand or yourself. It’ll also end up looking more professional too, because these guys have had, I mean for any developer, not you specifically, but like developers, or me specifically, but designers have had a long time to mull over these published really big design systems and there’s a lot of good thinking that goes into them. So more than you might expect. Going, going gone. Thank you everybody. I appreciate it so much.

Speaker 7: How do we follow you?

Elliot: I’m on Twitter as @elliotbnvl. And my blog is also elliotbonneville.com. I have a link in the meetup if you want to … the meetup description. That’s just the link to my contact form, but you can find my website through there. And then everything else through my website.

Speaker 8: Did you design your website?

Elliot: Actually no, Alena Maria back there in the corner; my wife designed my website. Because I’m not a designer. All right.