Introducing Okapi – A Lightweight Design System

The first question that comes to mind is why bother creating your design system if there are literally hundreds of others available online? Well, the simple answer is that we are picky, and we all have our own way of working. If you want my long answer, find a comfortable chair and continue reading.

Why did we decide to work on our own design system?

A couple of months ago, we asked around UX studio to see how our fellow designer teammates approach a new project. It turned out that 99% of the time, they start from scratch. If you’ve ever had to build a product from the ground up, you know how much nitty-gritty work goes into those pretty design files: coming up with a naming system for your components, defining the 254 button states, form fields, paddings, grid systems, etc. — it’s a lot of effort to build the final screens AND to build up a component library at the same time.

To save some time, UX studio designers often went back to their previous projects to see how they’ve built something or adapted a component type to fit the new project. This made us think: what if we identified those common UI components that are always needed on client projects, collect them in one place, and reuse them in the future?

Some designers also told us that building components is a crucial part of the UI design process because it helps them think in systems and identify the main patterns throughout the product they are building, and just to be consistent in general.

DS -Testimonial-Simi

To summarize, when it comes to creating new design systems, we need our creative freedom to follow our logic, but we don’t like the repetitive and time-consuming tasks at the beginning. That is why we decided to create a base UI kit that will eliminate some of the “boring” tasks at the beginning of the project.

Design System-Testimonial-Sanyi

What is the Okapi design system? (And why is it called that?)

It’s a Figma UI kit with basic web components that are needed in every UX design project. 

In this first iteration, we concentrated on creating an “MVP.” The file includes:

  • Color styles
  • Text styles
  • Grid system
  • Iconography
  • Buttons
  • Input fields
  • Selection controls
  • Cards
  • An additional file with naming conventions.

Each component type has documentation that explains how and when to use it, what are the dos and don’ts you need to learn, and some examples. And the name? Okapis, or forest giraffes, are highly adaptable animals, and we wanted our design system to be just that: a great starting point that you can customize to your needs.

DS - Testimonial-Vica

Documentation or UI kit? Can it be both?

There are basic elements and patterns in UX that work the same way in every product, such as toggles or radio buttons, so it can be a pain to write documentation for them every single time. We don’t want to reinvent the wheel, right? It is still important to have some guidelines written inside the system, just to make sure everyone understands how a component should be used exactly. 

We also felt that the collective experience of our designers of various projects is something worth documenting, so in addition to the components, we gathered a lot of best practices, suggestions, and some further reading.

Okapi Design System documentation
A screenshot of our documentation in Okapi

To be clear, our goal was not to rewrite Google’s material guidelines but to document our best practices to improve our processes as a team and as a design community. We used a simple documentation template for each component:

  • A general description of the topic
  • Further reading (blog posts, books, cool websites, etc.)
  • Dos and don’ts
  • And last but not least, the component itself.

And the good part is: from now on, we can not only reuse components in our projects but the documentation as well!

Working as a team

To create a guideline for the documentation, first, we had to gather all the necessary elements that a design system should include. We went through our already existing Figma files to find all the must-have components that are always needed in a project. From those, we defined eight topics that we mentioned above, and then we distributed these topics between the team, so everyone had their task to focus on and go into details. This method let us work parallelly, with feedback sessions once a week where everyone could present their work. We picked only the most important elements to create an MVP. Our future goal is to use this file as a base when newbies arrive in the team, and they could extend it with new components. It’s a win-win situation since the design system could grow, and the new team members can practice and reuse a detailed system.

Design system-Testimonial-Andi

The team’s most important learnings

Working in a remote team is not always easy. We all know this, so I’m not going into details. Communication and respecting each other’s time and work are really important to create something great and to work together smoothly.

What we’d like to highlight here, is more about design system learnings and how to work on them with teammates. Let’s start with prioritization.

Our first and biggest learning was that we should have set up some kind of order at the very beginning. What do I mean by that? As we mentioned, all of us in the team had our own topic, so after some discussions and research, we all started working on them individually. After a few weeks, we realized that we should have started with colors and typography since those are the basic elements of the design system. You cannot design a button or the input fields without the final colors and fonts. I mean, you can, but that’s just some extra work for you. So we can say that defining color and font styles before anything else is crucial.

Our next problem was the different preferences of every designer. We were ideating a lot together, and each teammate had their own visions and custom needs regarding design systems. A few examples – do we want to choose a button’s state or type from the right panel in Figma, or should we merge all of them in one component, so then we can just switch on and off the layers? Do we want to use only auto layouts, or should we create buttons with fixed width as well? How should we name the layers and components? Letter cases, dashes, or slashes, it doesn’t really matter, we just have to agree on them at the beginning of the project.

Of course, a lot depends on the product that we are working on, but the learning here is pretty simple. Start using your system, and you will know how it fits your needs and what is best for you! Like usability testing, right? We all know the importance of it, so we should have applied that earlier in the process. It can help a lot.

And that’s really our plan with Okapi: First, we would like to see how it performs in practice. Using it on real projects will be a great way to test it in practice, identify problems, and collect a list of components we would like to include in the future. We ask you to do the same and let us know how you like it. If you feel like it, suggest some components you think we should include. We can’t wait to see how it will evolve in the future!

DS-Testimonial-Fru

Conclusion

When we started working on Okapi, our own design system, the initial idea was to create a template that all of us in the team could reuse anytime. Also, newbies in the team could learn a lot from using and contributing to this file because it would help them understand our processes faster. This would ultimately result in better knowledge-sharing practices.

Thinking back on the last few months, I can say we already gained a lot from Okapi as individual designers and as a team. We had great conversations about design systems, worked together on a pet project we were all interested in, collected a lot of great articles and books on the topic, and some of us already used Okapi on real client projects. And we don’t want to stop here!

We also want to hear your opinion! No matter where you are in the world, good design practices should be international.  That’s why we officially published Okapi in Figma Community, hoping to get some feedback from you. Please feel free to duplicate it with this link, have a look, start using it, and get in touch with us. We are looking forward to hearing your ideas and starting a discussion about design systems. 🙂Okapi button

P.s.: Send us some suggestions on what to include next, we definitely want to continue working on Okapi in the future!

Searching for the right UX agency?

UX studio works with rising startups and established tech giants worldwide.

Should you want to improve the design and performance of your digital product, message us to book a consultation with us.

We will walk you through our design processes and suggest the next steps!

Our experts would be happy to assist with the UX strategy, product and user research, UX/UI design, etc.

Niki Szosznyák

I’m a Product Designer always open to learning, passionate about cooking, long walks, and love exploring new places. Also crazy about dogs and coffee.

Zsófia Paszternák

I'm a UX/UI designer who is passionate about visual communication.
I also love greyhounds and pizza.