Segun Adebayo talks about how he ended up becoming a UX engineer as well as the Chakra UI design system.
Segun Adebayo was turned off of web development after struggling with Wordpress' themes and plugins, and so he went straight into UI design entirely using Sketch and Figma for quite some time. It was React that brought him back into the development fold. The way React made it so easy to create components stuck with him.
Segun is still a designer at heart, but his skillset goes beyond design. If he calls himself a designer, it limits what people want from him. By calling himself, a UX Engineer Segun can create higher expectations of his skills, and people come to him for a broader range of problems.
One of the key reasons Segun started his side-project, Chakra UI, was to learn. One of his fundamental values is learning in public. Chakra UI is a passion project for Segun. It breaks his heart that most applications aren't accessible. Accessibility is one of the three core principles of Chakra UI along with composition, and being easy to style. Accessibility was one of the other key reasons for Segun starting Chakra UI. He wanted to create a design system that would make it easier for other developers to make the web accessible.
"Why Segun Adebayo Calls Himself A UX Engineer Instead Of A Designer" Transcript
Joel Hooks: Hi, Segun.
Segun Adebayo: Hi, Joel. How are you doing?
Joel Hooks: Doing excellent. I'm really looking forward to talking to you today. We, at Egghead, started using your library, your Chakra UI, so it's something I'm really interested in.
Segun Adebayo: Awesome.
Joel Hooks: But first I wanted to ask you, just how did you get started? What has your career been like, and how did you get to the point where you're developing full design systems as open source projects? What got you to this point?
Segun Adebayo: Okay. I would say I didn't really start out as a front end developer. My journey started about five years ago, I started with UI design. Back then it wasn't called UI design, I guess it was called mock up design, with Photoshop. So I used Adobe Photoshop then, to try to create designs. And shortly after a while, most of the clients I worked with asked to convert their designs to WordPress, I should've known my first introduction to this thing called web design, or web development, because I had some issues with WordPress, struggled with themes and plugins, and I just gave up. And after that time, with anything that has to do with development on HTML, or CSS right. So I went straight into UI design fully using Sketch and Figma for quite a while.
Segun Adebayo: So I attempted to try again, To come back to front end development just to see this time it won't be as frustrating for me. And it turned out to be really good, I think one of the things that scared me back then was jQuery with all the different options, and config, and only things you have to do. So I mean that scared me. But when I came back to it about two years ago, and seeing reality on how easy it is for me to create components. I think it really just stuck for me, and it mainly helped me to really stop my journey to front end development. To be honest, I think one of the things that helped me was I tried to build an application called CareerLyft, CareerLyft is an online platform to help people create their resumes really fast. So I'm currently working on CareerLyft, building CareerLyft Really helped me to master most of the core concepts of HTML and CSS.
Joel Hooks: So you were doing design, and you're a UI designer, and you tried and PHP and WordPress just didn't do it. But then when you came back to try this you hit react, and so you're saying CareerLyft, this site that you built to help people with their resumes, it's kind of the side project, or your project that you could control and play with and felt safe to build on. Is that correct?
Segun Adebayo: Yes. So CareerLyft is my project, I started it with a couple of friends, so we built it together, and we decided to launch it to see if people would be interested in trying it out, and even paying for it. So it's been amazing so far.
Joel Hooks: And did they? have they paid for it? Has it been a success in your eyes?
Segun Adebayo: Oh yes. It has been a success. I mean quite a number of people actually pay for it. It's a subscription service. So quite a number of people pay for it and I'm quite excited about that.
Joel Hooks: Is that your full time job at this point, or are you still working outside of that?
Segun Adebayo: I'm still working outside of that at the moment.
Joel Hooks: Okay. That's cool though. And I love that, because I know the feeling when somebody is buying something that you've made, and it's useful to them, and they're actually getting the value out of it, and paying a subscription. I don't think there's anything I felt in my career quite the same as that. Just that feeling is amazing.
Segun Adebayo: Yeah, it's really amazing.
Joel Hooks: So you've stopped calling yourself a designer, and I'm really curious about that, and would love to hear more about why you stopped referring to yourself as strictly a designer.
Segun Adebayo: Yes. So I wouldn't say that I'm no longer a designer to be honest. I think I'm still a designer at heart. I changed that because I feel like I can be of help to people beyond just design. I could of help to more clients, and help them be able to engineer the applications beyond just the visual design. Because I think the scope is quite limited when I call myself a UI designer. When people reach out to me they reach out to me for mockups or sketch designs, but I know my skillset is way beyond that. So I decided to broaden the net. It'd be so people know what I'm really good at.
Joel Hooks: So what do you prefer now? What do you prefer to do you have as your job title?
Segun Adebayo: I think I will say UI engineer, if there's a role like that. I think there's a role called UX engineer.
Joel Hooks: Yeah. Use experience.
Segun Adebayo: Yeah. UX engineer sounds more like a good role.
Joel Hooks: Yeah. And to me, I'm primarily a coder, but I have a little bit of a design background, and when I think user experience, I think of the whole experience, which includes both visual design, and the code, and then a bunch of other factors as well. Do you generally recommend that other visual designers learn to code if they're interested in it?
Segun Adebayo: Yes, I do. I really recommend it. The reason why I say so from personal experience, is when I go into React, and I started working on components, it immediately mirrored how I used to create components in sketch. How I used to create symbols in Sketch, and components in Figma. And then it all made sense to me because I was really using Sketch back in the time when I needed it, to grid components with different states, and different configurations. So coming to React and knowing that I can change the configuration with props really made a lot of sense. So I think as a designer, if you're really interested in learning how to code, you would have more advantage over someone with an engineer who doesn't know how to design.
Joel Hooks: I think a lot of people are intimidated just by the thought of code, do you have any advice to them? If somebody is interested in it, but they feel intimidated. Like this isn't something they can do. What do you tell people that are trying to get into, or trying to crossover more into the development space from design?
Segun Adebayo: Okay. So one of the things I tell people when I try to teach them front end development is it's not as hard as it seems or it looks, right. Because I know sometimes people get overwhelmed by the post on Twitter, The post on Instagram by people who are doing great things, and feel like it's quite a lot of work. But I feel like once you're a designer for example, it's going to be quite easy to move over to the front end development, because you already have the mental framework you need to be able to move over. But if you don't have design background, it's not as hard as it looks. So don't be scared, just try it out. You can start with the HTML, CSS. And just try to master the fundamentals, and then try to go to advanced. Because it might scare you from going forward.
Joel Hooks: Now what about the other way? If there's a developer that is interested in learning design, because I think that's always difficult, right? It's the communication. How do we talk to each other as developers and designers. But if I'm a developer and I want to pick up some more design so I can communicate both with my customers and my coworkers, what's your advice to a developer that wants to learn more about design?
Segun Adebayo: Okay, so one of the things I would recommend is to check out Sarah Drasner's course on Design for Developers. That's a really good course to start out with. I would also recommend Refactoring UI by Adam Wathan. I think it's also going to help you as a developer learn about design. Because I know sometimes just coming from the world of development and design is a huge leap. Sometimes most developers are not patient enough to go through that phase. So I think that just taking it beat by beat, and watching course, reading book. It might just start to incline gradually towards design. And I mean just over time you start to see that you have a better taste, and you're able to make your UIs look really good with time, as you practice and watch all these videos.
Joel Hooks: So for me, and I don't know if this is your experience as well, but for me one of the biggest benefits of both design and development experience, is the ability to communicate with collaborators. Like even if I'm never going to be a design expert, I still want to be able to communicate design with designers, right? Because it can be really challenging. So if we learn each other's vocabulary, we end up being more effective as teams I feel.
Segun Adebayo: Yeah. That's a good point as well. Designers have a vocabulary by default, and same with developers. So sometimes, I mean just like you said, I'm collaborating often with the designer who helps you learn how to see design. And it also works the other way as well. So a designer working closely with the developer would also see and learn how to view design. Because I think sometimes the two views of design can be different from a developer and a designer standpoint. So collaboration really helps as well.
Joel Hooks: Yeah. And Sarah Drasner's Design for Developers is on front end masters, and it's an amazing course, and I recommend that to everybody. And I think refactoring UI is incredibly interesting because what they have created is not only that book, but the book is really fantastic, but then they're basing it on Tailwind, which is a really nice CSS framework. It allows you to make less design decisions and still create nice things. Have you used Tailwind at all as well?
Segun Adebayo: Yes, I've used Tailwind and it's really amazing. I mean it's one of the things that really inspired me when I started Chakra UI, It was just a way for me to learn Tailwind works. Having worked behind the scenes, and seeing it's possible to replicate that in React, so yes it really helped me.
Joel Hooks: So what is Chakra UI? I think this is a good time to talk about this design system, this library, the set of components that you built. Can you explain what it is?
Segun Adebayo: Okay. I think I will start with why I made Chakra UI, one of the key reasons why I started it was really just for me to learn, to be honest. I think one of the key values I have personally is to be comfortable learning in public. So the current state on my knowledge can not really go in public for people to learn from. That's one of the key values I personally follow. So what I wanted to do was to learn mostly how to create reusable and composable components. So I didn't just stumble on this idea all of a sudden, but working with other React libraries like Material UI or Ant Design, and just a couple of other UI libraries out there.
Segun Adebayo: I feel the pain it takes to styling components. I see the pain that it takes to make the component accessible. Most of all is key details are missing. I mean all of these UI libraries, even though I think quite a number of them do a lot of accessibility, but I feel it can be better in terms of the experience of using these components, styling them, making sure they're accessible, and giving developers the freedom to be able to do anything they like with the components.
Segun Adebayo: So, that's really where it started from. So take for example, if you're working in a company and a designer sends you in design in Figma, there's always some pain to take that design and convert it to code almost every single time. It feels like the developer is [inaudible 00:12:56] right? Writing in one job styles over and over again, and if it feels quite painful. So I wanted to see if I could make that process really easy, and leverage on React composition [inaudible 00:13:13], which I learned from Ryan Florence thanks to him. So I watched his React training course online, I already talked about composing components in React, I mean after that course was when I was really inspired to start Chakra UI.
Joel Hooks: Yeah. And so you mentioned... I think that his course is amazing. And you mentioned accessibility as one of the core concerns of Chakra, and making that something that we as developers can just kind of have, right? But why is that important? Why is it important to have a component set that has accessibility as a primary concern?
Segun Adebayo: Yeah, so one of the things that breaks my heart these days, is they found that most applications are not accessible. So let's start from a simple example. If I open a website and I just try to talk to the website, somehow in some websites, I don't even know where my focus is. I mean that's just from a keyboard navigation perspective. And in some other cases, I'm not able to get to some parts of the website, except by using mouse. Even for screen readers as well, If I place focus on a element, is it speaking out the correct things? Are the attributes that element, or is it just saying a generic element? So that was really the key concern for me, I thought if we could make components accessible by default, most developers will not have to think about accessibility as it comes out of the box, and they can just compose components however they like.
Joel Hooks: Do you think people avoid accessibility because it's too much work, or what's the objection, and why are people not adding this to their application?
Segun Adebayo: I don't think it's too much work, but yes, I agree. Sometimes it can be quite annoying to want to factor in accessibility, particularly for the keyboard aspect, and for screen readers. And what I think maybe we could do better, in terms of the resources out there to help people build up physical components. Because there are not many resources, like tools or videos that can help people learn about accessibility.
Segun Adebayo: So one key example I can give is: let's assume you're trying to view a tab, or a tabs component that has different tabs. And when I was learning HTML and CSS, they told us to be able to style the active tab, just pass a class name or activity, and then just style it that way. And after a while, I come into accessibility and I learn that okay, this is an HTML attribute that I can add to the tags, to let screen readers know that this is an active tab. But if I didn't check for that information, that would be lost. And I would just be using CSS to style an active tab, when there is actually an external attribute to do that.
Joel Hooks: Yeah. So you tab around and visually it would change. But if you're using a screen reader, or perhaps the design for whatever reason isn't obvious enough, then you don't notice.
Segun Adebayo: Exactly.
Joel Hooks: Can you explain some of the design principles that went into Chakra?
Segun Adebayo: Okay, so one of them would be composition. That really just means that people should be able to... Any complex rigid components should be broken down into small parts, and composed together to fund the main component. So take for example a model, I mean in a model you have the model backdrop, and you have the model content area, right? So I mean that should really be composed together as individual React components, as opposed to baking them together into one giant component that cannot be overrided or styled. That's just a common problem. So composition really just means composing all the different parts of a complex component together and giving people the ability to style, and even just extend the functionality of any component.
Segun Adebayo: All right, so that's one core principle, and obviously the second one would be accessibility, which includes adding the proper Aria attributes, as much as possible providing support for keyboard navigation. How many areas we need to trap focus, see if you can trap focus, and see how it works. I think the last would be making it easy to style a component. [inaudible 00:18:21] styling. So right now in Chakra UI we work with Styled System as the base library, thanks to Brent Jackson. I mean I think Style System is one of the... It's an amazing library. So what we do Chakra UI, we extend Style System functionalities. So it's really easy to start. So what I added to Chakra UI, which I really love, is the ability to style the interactive states of the component. So the over, the [inaudible 00:18:52], the disabled, the selected, the checked skit, are really easy to style the outcrops as opposed to trying to use the emotion style or creating in CSS.
Joel Hooks: So I think you bring up Styled System, and I think what's interesting to me about that particular approach is that it feels like it's based on kind of a specification, and it's something that we can use across various component libraries, and it gives us things like styled components, and you can use it with emotion, and you get rebase, and reflex box, and all these different pieces that at the core have the same fundamental idea about how we style components, and I think that's been a revelation. And I was wondering how was that working with Styled System for you, and what do you think about this idea of a common core that we can all use to style components.
Segun Adebayo: Yes. The Styled System specifications is really amazing. One of the things that I like is the fact that more and more people are taught in Styled System specifications, and even Styled System itself. One thing I would really love to see in the community is more of a unification of all these design systems, and component libraries. I mean for there to be some sort of uniformity across, so that it's easy for us to contribute and grow together. I mean as opposed to having different types of specifications for theme objects. So I think Styled System really does an amazing job. And more and more people I talk to use Styled System. That's why I think I made a decision to just go with it.
Joel Hooks: And it's system UI, is the theme specification that they run underneath there. But to me it's been a completely game changer across the board. And I see more and more people adopting it, and closing in on this, and it's something that's flexible, and considerate, and very very usable and lightweight. It's not a huge specification. It's a very lightweight specification too which I feel is important. What did you learn about design systems while you were building Chakra?
Segun Adebayo: So one of the key things I think I learned, before I started building Chakra, I knew about design systems, and the way I always describe it would be sort of a system that helps a company create digital products really easily and really fast. I always compare it to the human body, and we have all sorts of systems in our body, and those systems are in place and you don't even have to think about them. They just work every single day. Right? So I thought of a design system as a way to solve problems within an organization to create digital products that solve real problems. So it extends beyond just being a component library. It goes beyond, and I think I would define it as, I mean the patterns, the principles, the collaboration between teams to really make it easy to solve any problem a company has to solve. It is sort of a system of designing, of solving the problem. That's how I like to see it sometimes. Not just a UI component library.
Joel Hooks: I think people often think of it as a UI component library. I kind of feel like literally every company that's building webpages, or web applications, or whatever, has a design system? Even if it's not something that they've documented, right? It's like the human body, right? You have a body, you have systems. If you don't think about it, the systems are still there. They just might be bad. Would you agree with that?
Segun Adebayo: Yeah, I agree with that.
Joel Hooks: So, if you want to be intentional about your design system then you can build on the shoulders of those that have come before you. And I think often the kind of Holy grail, is this idea of we're going to have a component set that we can use across the entire organization. And I look at something like Atlaskit, where Atlassian has built this monumental design system. And I think, wow, that's millions and millions of dollars, and so many man years of effort to produce something like that. How do people get started if we haven't defined a design system at all. Where do we even begin? Like as an organization to start bringing together a design system that we can talk about and collaborate on?
Segun Adebayo: Okay. So one of the key things I've learned recently about this end system is, you don't just make a design system because you just like the idea of a design system. Right? So if you have an existing product, most likely you should create a design system to help that product. It's always best when you have something that already exists, and you're trying to improve it and make it look consistent, or feel consistent. Then is a good time to think about having a design system, for those that are just wanting to start the product. The design system makes sense, but then as you keep growing and adding more features to your product, or your software, you might most likely notice that you'll have to revise almost every single component as you go.
Segun Adebayo: So it works both ways. It's a lot easier when you have an existing product and you can see the need, to keep your product consistent. You can literally see that maybe two different pages of your site are not looking consistent and they look like sites from two different companies. So that's really the first place to start. And then the second one, to really identify key areas that really need help. If you have an existing product, you want to look through it, look through all the inconsistent parts, possibly take screenshots of all the inconsistent parts, and then try to sit down to list out all the things you might need for you to design the system. So you list out all the components, all the principles you have to follow to ensure that everything stays uniform.
Joel Hooks: So I think one of the interesting aspects of what you've done is you've created this open source project and I'm wondering, how has that been, launching an open source project and putting it out into the world and dealing with contributors and that sort of thing. How's your experience been on the open source side of this project?
Segun Adebayo: Yeah, one of the things I was told a while ago when I wanted to start, was not to get into the world of open source, and just keep your teams to yourself, and no one cares about your components. Just do your team by yourself. But I thought that the fastest way to learn is actually to learn it to other people. And to make your ideas available to other people, so they could possibly extend it, and even give you more perspective. So this is my very first attempt at open source. Creating chakra UI has really helped me learn about GitHub. I pull requests on issues, I mean before Chakra UI I didn't even know what this meant.
Segun Adebayo: But when I was working on [inaudible 00:26:38] we use GitLab. So I was just new to the world of GitHub, and all the issues and pull requests, initially it feel quite complex and complicated, but just looking through the systems, people submitting issues, complaining about different parts, and people genuinely contributing to it. It really made me feel good that there were other people who can take this idea and even help to evolve the idea. Some issues expanded to even work better. And so I really liked the idea and the concept of open source. I really appreciate everyone that's contributed to Chakra UI so far. It's been amazing for me.
Joel Hooks: Yeah, it's great. I think it's just amazing that it's this global experience. We can all work on this thing and make a better user experience, make the web more accessible, make our projects better, make our work better. It's really, really quite wonderful.
Segun Adebayo: Yeah.
Joel Hooks: Segun, it's been really great talking to you. Thank you for taking time out of your day. I really appreciate it. We really appreciate the work you do on Chakra. At Egghead, it's something that we enjoy, and from everybody, thank you so much for the time and effort you put into this.
Segun Adebayo: Awesome. Thank you, Joel. Thank you for having me on this podcast. I'm really excited to have the opportunity to talk about Chakra UI. I'm really happy to hear that Egghead is using Chakra UI to be honest. Awesome. Thank you.
Joel Hooks: Thank you so much.