Skip to content
GitHub Copilot is now available for free. Learn more
Segun Adebayo

Coding at the speed of design with Chakra UI

Part designer, part UX engineer, Segun is all about accessibility, inclusion, and empathy.

Segun Adebayo // @segunadebayo

Hi there! My name is Segun. I’m originally from Nigeria but I’m based in Dubai where I’m currently a product and UI engineer at Scribe.ai. I focus on building design systems and making sure products and websites are accessible ✨ . I built the popular (and award-winning!) Chakra UI library, which gives you the building blocks you need to build React applications quickly ⚡️. We currently have 250,000 downloads a month, more than 17,000 GitHub stars, and seven core contributors—and I’m so proud of our team! 😍

Dubai, United Arab Emirates

@thesegunadebayo

https://chakra-ui.com/

Organizations

Sponsoring

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

Six years ago, I was a freelance UI designer. I worked with different clients and teams via platforms like Toptal and Upwork. After a couple of projects, I noticed that the handoff to execution process—combined with the UI review cycles with front-end engineers—started to feel like a real challenge. Though no fault of their own, it took almost three times as long for engineers to create the output as it took for me to design it, because the tools we used didn’t work together well. This challenge happened with four different product teams and turned out to be a fairly common problem.

One of the core principles of design is empathy for your customers, the business or company, and colleagues. As a designer, I solve problems, and I wanted to use my empathy skills to help my front-end engineering colleagues. So I pulled my engineering friends together to understand why the design-to-code workflow was so challenging. They explained that the UI libraries they used weren’t as flexible, and there’s a ton of CSS they have to write in order to get things to look like the design.

I proposed we try and solve the problem, but they didn’t have the time or resources due to a backlog of tasks. So I put myself in their shoes and started by building an app called CareerLyft. I created the designs as usual, then asked my friends if I could watch them code so I could observe the problem in real time. I stopped everything else and dug in for four months, because I wanted to solve this challenge—for everyone! They were patient enough to teach me and get me started with React, HTML, JavaScript, and a couple of CSS tools. I also watched a few really helpful courses by Ryan Florence.

I built a small library of components, made sure they were accessible and flexible, and called it CareerLyft Chakra. Then my friends tested it—and after 10 minutes, there was a spark in their eyes as they turned to me and said, “This is so amazing.” They’d been in the industry for 10 years, so I knew I was onto something.

Taking the open source leap, as a designer

Photo of Segun Adebayo coding outdors on his laptop.

I started working to really understand how I could make CareerLyft Chakra more flexible, which grew into Chakra UI. With Chakra UI, I wanted to sync the speed of development with the speed of design. I wanted the developer to be just as excited as the designer to create a screen.

Two to three months later, even though my friends were a little wary, I decided to open source the project. They said people would judge me: I’m just a designer with less than six months of experience. I figured I could just take it down if it didn’t work. But it did.

When we open sourced Chakra UI on GitHub in September 2019, I was scared and unsure of what to expect. I knew I had a lot of design experience and I used my knowledge of design methodology to structure Chakra UI. But I was entering this world I didn’t know so well, and it’s pretty chaotic. I was trying to make that chaos more stable.

I targeted a couple of software and open source influencers in hopes that maybe one of them might find it interesting. A few hours later, Ryan Florence, Guillermo Rauch, and Prosper Otemuyiwa retweeted me! That felt super awesome. Then a couple of people in the Nigerian community shared the project, and it got more visibility. Within three months, Chakra UI was all over Twitter, and I had to turn off my phone notifications so I didn’t get overwhelmed.

Recruiting an active community to maintain the best project

Photo of Segun Adebayo reading a book Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal.

Shortly after launch, in February 2020, I moved to Dubai to join Tradeling, and had to figure out how to maintain a balance between Chakra UI and my job. I read Nadia Eghbal’s book, Working in Public: The Making and Maintenance of Open Source Software, which helped me learn how to balance life and open source work better.

When you start an open source project that becomes popular, you attract more attention. And the more attention you have, the more people are curious, have questions, want to associate with you, interview you, and talk to you. I remember when we launched, I spent three weeks responding to issues and DMs. I felt fatigued and it seemed like I had no life outside Chakra UI. The burnout helped me understand that what is most important as an open source maintainer is to make sure you’re in control of your life. You don’t want to be affected by the different people and expectations that they place on you, because it can really drive you in the wrong direction fast.

You can work literally every day and every single hour on open source. There’s documentation, the code base, tooling, GitHub issues, Discord questions, road maps, and timelines. So many areas beg for your attention and they can spread you out too thin. This can really harm your health, so you have to put yourself and your mental health first. That’s the only way to do valuable work.

Also, the core tenet of open source is that the project is maintained by the community, not just you “all the time.” It’s good to recruit people and share your knowledge so that even when you burn out, you know they’ll help you keep pushing everything forward.

I try to keep the Chakra UI team as small as possible and make sure they’re all well-rounded. Right now, there are seven people on the Chakra UI react team: Mark Chandler, Tim Kolberger, Folasade Agbaje, Kola Tioluwani, Lazar Nikolov, Javier Alaves and Gerrit Alex. We also have four people on the Chakra UI Vue team, led by Jonathan Bakebwa. I’m proud of our team because it’s full of diverse people from different countries and with different ideas, which helps us move forward fast. They’re awesome humans who have a sense of humor and empathy for other contributors.

Portrait of Segun Adebayo standing outdoors between plamtrees.

Prioritizing the right things, including yourself

The first challenge as an open source maintainer is managing time. When people file issues, they make it sound urgent, as though it must be fixed immediately. It takes a little while to understand that nothing is urgent. The project is open source and people can always open a pull request to fix any issues. It’s helpful to have a proper schedule to release updates and fix bugs. If there’s no schedule, you get lost in the cycle and can get burned out really fast.

At the beginning, I couldn’t find a way to balance everything. I got over that by quickly recruiting active members of the community: People who can volunteer to help triage issues, fix bugs in the codebase, improve the documentation, manage the discord community, and more. I find that having a mix of technical and non-technical contributors is very helpful. The thing to note, though, is that core members might drop off at any point for any reason. You have to understand that, respect it, and then go out there and try to find more people.

The second challenge is prioritizing what’s important and ignoring the rest. There’s constant pressure and feature requests from your active users. Everyone needs a feature added to Chakra UI. Deep down, I thought it would be great to add these features so I could make them happy and excited to keep using Chakra UI. But I knew I couldn’t. Responding to every request and tweaking code to fit custom needs will, over time, reduce the quality and architecture of the project. Now, I have weekly meetings with the core team to go over what we need to focus on and prioritize each week.

The third biggest challenge is finance. At some point, the time you put in doesn’t justify the return you get. I initially wanted to focus on Chakra UI full time, but I quickly saw that it wasn’t feasible. So I got a job to make things sustainable for me first, and maintain the project in my free time. It’s important to take care of myself, my family, and my finances first. I also drew up a plan to get more finance and funds into the project to keep the maintenance sustainable over time, by rewarding core contributors.

Now, I spend most of my Chakra UI time thinking about it on a conceptual level. How do we drive adoption over time? How do we improve the quality of the components and the quality of the accessibility of the components? How do we improve the overall usage and quality? How do we make sure that larger companies, not just small to medium companies, can use Chakra UI?

I’m proud that the project is useful to so many people. I was looking at NPM stats a few days ago, and saw that close to 1.8 million developers have used Chakra UI, which is just so awesome! I feel really good and proud when I see these numbers. People call them vanity metrics, but I see them as a metric that proves this product is useful and people get value from it. And I’m really proud of that, because that’s what I set out to do: bring a little more empathy and value to my colleagues.

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

Thank you! for subscribing