Ivo Anić

Start with UI Kit creation with our straight-talking guide. Learn from the trenches – what you need, how to start, and why it matters for your design system

Building a UI Kit: A No Frills  Guide to Kickstart Your Design System

Many designers are familiar with design systems, what they are, why we use them, and how we use them, so I’ll fast forward to the juicy part.

Okay, so this article is about creating your design system, but there’s a twist. Before there is a design system, you should probably create a UI kit (since we’re UI designers). And that’s what the topic of this article actually is, creating your very own and shiny UI kit.


Why a UI kit? What’s that?

The UI kit, IMHO is the foundation of any design system (used in product design), and as such it’s important to start right. In the following paragraphs, I’ll try to post my experience with creating UI kits. I’m no expert, but let me give it a shot.

First things first. Let’s decide on what components we need to use. At PROTOTYP we have a basic “UI kit” called Forward that is usually the starting point for almost all projects. Forward evolves into a tailored design system based on the project's purpose and type, with components that are scaled, updated and improved as needed. The Forward UI kit provides a foundation that can then be customized and expanded on for each unique design system as requirements evolve over time.



What you need

Forward has a lot of components, but as a starting point, you don’t need everything — yet. To get started, focus on including the following core components:

 * Buttons
 * Type scale
 * Forms Elements
 * Colors

Now, let’s dive deeper into each of these core components in more detail.


Buttons

Buttons are usually the main interactive element on interfaces as we use them for actions. Let's start our exploration of core components with buttons. We all know how they work, but what do we need for a UI kit is widely discussed. I’ll try to cover our Forward button set and explain the reasoning why they exist as such.

Creating primary and secondary button styles is essential. The variations needed depend on use cases, but at minimum include primary and secondary buttons in small and normal sizes. This helps achieve a better visual hierarchy.

You'll also want to account for different states as well - you’ll have 5 states for each size and type. In the end, you should probably have something like this:

 * Primary button small x 5 states
 * Primary button normal x 5 states
 * Secondary button small x 5 states
 * Secondary button normal x 5 states
   

That's 20 basic buttons to start. Many design systems also include variants like outlined or ghost styles. When you factor those in, the total button count can grow quite large. For example, our Forward UI kit contains over 240 button styles to cover a wide range of needs


Type scale

A solid type scale is essential for any good UI kit. Our scale ranges from Micro to XXXX Large, with 10 sizes to accommodate varying text needs.

Depending on the chosen typeface, you may need to include additional weights like regular and bold.

Example type scales could include:

 * Regular (Micro to XXXX Large)
 * Labels (Tiny to Large)
 * Inputs (depends on how many sizes of input fields you’ll have, but let’s say Small to Large)
 * Buttons (also depending on the number of button sizes you’ll want to include; for our example, it’ll be two - Small and Normal)
   




Your scale may grow as your project expands. For example, our Forward UI kit contains over 7 scales to thoroughly cover usage across products. While this sounds complex, well-structured type ensures every element has a clear purpose and place.


Form Elements

This section may not be something basic that’s needed in a starter UI kit, but almost every product has some inputs, checkboxes, and even radio buttons. The starting point could be the following:

 * Input Field (multiple sizes and states, usually aligned with button sizes)
 * Radio button (with states)
 * Checkboxes (with states)
   

For radio buttons and checkboxes, use a single size to avoid unnecessary complexity.

Be sure to include all relevant states for each item. For example, you may end up with over 20 basic form elements to cover common interactions.

Larger kits like our Forward UI contain additional styles, sizes and states to accommodate more use cases out of the box. But this provides a good foundational set of form components to start.


Colors

Maybe we should’ve started the list with colors as colors are widely used across the entire UI kit. The reason behind having color last on the list is just to have a list of things you’ll need colors for - nothing more than that.

If you turn to things written before this section, you’ll see that you roughly need a color for each item, -ish. In the end, you end up with a list of colors that may look something like this:

 * Text Color
 * Primary color
 * Secondary color

But remember that we have multiple states so you’ll need shades. A good starting point is having at least 5 shades of each color. That’s 15 colors to start with. You can easily expand that list by adding utility, background, border colors, etc. Forward has more than 50 colors as it stands today.


Wrapping things

This covers the core components to include in a starter UI kit. There’s always more that can be added and implemented. Every part can be expanded with states, sizes, styles, shades, etc. You can add elements such as icons, grids, modals… But as this was just to cover the basics, we’ll leave you with these ideas for expanding your own UI kit.

Also, be sure to use master components, variants, variables, styles, and other awesome things at your disposal if you work with Figma.

In summary, prioritizing a well-planned UI kit lays the foundation for a comprehensive design system tailored to your unique product requirements. As your project grows, your living style guide will adapt seamlessly while maintaining consistency. Start by gathering the essentials covered here, then continue expanding your vibrant and functional UI ecosystem.


Design

Creating your first UI kit

Find out how can you practice your design skills and become better at creative thinking, problem-solving, reviewing, and on-the-spot thinking. 

Become a better interface designer in 20ish minutes - Prototyped 

Here at PROTOTYP we always strive to create better and better interfaces. Each project has to be better than the last one. Well, not just better, it has to outshine every project before. And one of the steps in doing so is regular exercise. You know the good old saying, practice makes perfect, and you could say that we live by it?

So once a week our whole team rallies up, usually at the end of the day, and we have a design exercise. There are multiple products of this exercise, such as quick on-the-spot thinking, learning how to give and receive constructive criticism while reviewing something, power of observation practice, presentation and storytelling skills, general problem solving, and overall, a team that handles problems quickly and efficiently.


The exercise

So the format is this:

 * A task that needs to be done
 * Time limit
 * 1-minute presentation of your solution
 * 1-minute review from each team member

After we’ve covered the basics of the exercise, we can get into details. So let’s start with the task.

A task for our design exercise can be anything. We usually solve both UI and UX problems, typography-related tasks, graphic design stuff, you name it. For example, someone can use an app and recognize it has poor UX and decide that’s a good problem for our team to resolve. So the problem gets presented before the team, in as much detail as possible and we get to work. Note that you can’t exactly set a task to design something complex, as it needs to be doable in the set period.

After a presentation of the problem, a time limit for solving the problem needs to be set. It’s usually something within 20 to 25 minutes, varying of the task complexity. We set a timer to the time limit at hand and after it runs out, everyone stops with their work and gets ready to present their solution.

The presentation of each team member's solution is “restricted” to only one minute. So you have to “sell” your solution in only a minute, which is a good way to practice your presentation skills and your storytelling. After the presentation, every team member has a minute to review the solution by looking at all the aspects of the design, from typography, UX, color choice, etc. The person reviewing is urged to be as harsh as it gets, so everyone gets a proper “in-depth” review.

After every team member's solution presentation and review, we usually pick the ones that have potential and more opportunities to turn their designs into Dribbble shots or something similar.


A few examples

Let’s show a few examples of the exercises we did at PROTOTYP.

Redesigning a complicated table

 * Time limit - 25 minutes
 * Output - each team member has to rework the given table, using best practices for UX and UI.



News portal article page

 * Details - Redesign a news portal page to make it look modern and more user friendly
 * Time limit - 15 minutes
 * Output - each team member has to design a blog post style page.



Dating app

 * Details - The team is presented with a dating app screenshot that needs to be reworked
 * Time limit - 25 minutes
 * Output - design and present one screen of a dating app.



Smart TV UI redesign

 * Time limit - 25 minutes
 * Output - each team member has to redesign the given UI and make it presentable compared to the starting screenshot.


What do you get from all of this?

So, after I’ve explained the whole process and given some examples you may be wondering what’s in it for you and your team? Let’s start with the time available to solve the set problem.

You have only 20ish minutes to solve the task at hand, meaning that you need to come up with a solution to the set problem, design it, and after all, present it to the team. So if you’re designing something like an app screen, you need to pick a typeface, find content, choose colors, set a grid, a type scale, etc. That’s a lot of ground to cover in this short period, but with each exercise, you get faster and better at it and that’s the whole purpose.

The presentation section may only be one minute long (or short) but you get the idea why it’s like that. Having only one minute available makes you get to the point faster and think faster about how to “sell” your design. You may choose to talk about the color choice, the typeface and why you’ve decided on it, and so on. The idea behind it is to make you think quickly and get straight to the point. And that will, in the end, make you a better storyteller.

The review part works great in both directions. If your design is getting reviewed by a colleague with more experience, you’ll get to hear a lot of constructive criticism about your solution, which is always a good thing. You can always learn how someone else thinks and passes on quality feedback about identical things.

The same goes for when you’re giving feedback to a colleague. You have limited time to review the whole thing, so you need to be precise, direct, and comment on things that you think are great or poor. That directly works on your capability of observation and your ability to explain why something is excellent or wrong.


Are you a better designer after only 20 minutes?

As someone wise, and also me at the beginning of this article, said, practice makes perfect. You can’t expect to see results after only one exercise, but after a few, it gets pretty obvious that you’re doing something right. With each exercise, you and your whole team get a bit better in everything mentioned above, as well as in teamwork and communication.


TL;DR?

Let's recap and end the article with a nice little TL;DR:

 * Have a dedicated day for design practice.
 * Pick an appropriate format for the exercise.
 * Create an “easy” task and set a time limit.
 * Think fast. Design faster. Present confidently. Review constructively.
 * Dribbble famous?
 * Become a better designer just by practicing regularly.

As I’ve mentioned before, practice makes perfect and this is a great example. Be consistent and see your and your team's skills become better. Not will you design better, but you’ll learn each week how to grasp problems in moments, how to spot issues, and how to tell a greater story to your customers.


Thank you for taking the time to read this post. Feel free to share your thoughts and drop us an email at hello@prototyp.digital. 😄








Become a better interface designer in 20ish minutes

Find out how to use Figma Mirror in real-life projects, and how to most accurately transfer your designs to a device on your desk. 

Make Figma previews look great on any device - Prototyped

Ever since I’ve started as a UX/UI designer (on a professional level, at least), I’ve “struggled” with previewing my designs/mockups/prototypes on devices I was designing for. I remember exporting screens and opening them in the gallery app, manually zooming to fit them on the screen, and assuming it looked as it will on a real device. But then Figma announced its Mirror application and basically flipped the whole thing, and after, real-time prototyping in Figma became a thing.

Figma Mirror is a neat app (available for Android devices and that other phone) that lets you preview your work in real-time on a physical device. It looks like the future is now (old man) and Figma has created something that is a must-have for every designer or someone that likes to think that they’re one.


Setting up the “environment”

It’s straightforward to get started with the Mirror app. Just download it from the store of your choice (Google Play or App Store; there’s even a web app that allows you to do the same) log into your Figma account (the one you’re designing in) and that’s it, you’re good to go.

We’ll be using a design that was created as a part of our internal design practice in 25 minutes (when the article comes out we’ll insert the link to that blog post here), but you can use whatever you want to preview on your device.

So, after we’ve chosen our project and opened the app on the device, using our desktop app we pick the desired frame by clicking on it, and like magic, our frame is visible on the device.


Notice how the frame automatically scales to the width of your device?

That could be an issue, as the content is not showing in the resolution of the device, it’s just scaled to fill the width. That means that the buttons are a bit bigger, the text is not 1:1 as in the design, and so on. To tackle this problem you’ll need to tweak your frame a bit and in the next few paragraphs, I intend on teaching you how.


What are "dp" and why must I learn about it?

Okay, before we learn how to get our Figma design to appear 1:1 on the actual device, we need to brush up on a few “new” things, but I’ll guess that’s the reason you’re reading this, so from now on, be prepared to expand your brain hole.

"Dp" or density-independent pixels are a virtual unit of measurement. One "dp" is a virtual pixel that’s roughly equal to one pixel on a medium density screen (160 dp) that’s considered to be the baseline density. So, if you intend on viewing your design on a device, you’ll need to calculate your device pixel density. Here’s how you do that:

dp = (width in pixels * 160) / screen density

Width in pixels = Just enter your phone name into Google, open the specs (best and most known source is gsmarena.com) and copy your device screen width and paste it into the formula above

Screen density = Also use Google and the same exact source to find the exact density and copy it into the formula.

This means that the width of your frame in Figma needs to be the same as the calculated dp.

So let’s say you own a Nexus 6P (or you just happen to have one on your desk). After a quick Google search, you'll find out that the screen width is 1440 px, and screen density is 518 ppi. After you insert the required data into the formula, you get something like this:

dp = (1440 * 160) / 518

dp = 444.79

So for our Figma frame width, we’re going to use 444 (rounded to a number divisible by 4). You can also calculate the height using the same formula if you want to preview the entire frame on the whole screen, but generally, we just need the right width to remove Figma’s auto-resize on device width as height is not the most important here.


After you’ve adjusted the width to match your device, that’s it, you’ve got a correct preview on your device as in your Figma file.

From here, you can tweak the file to adjust the grid and get the components to fit right on the screen.


That's a wrap

Let's recap and also help out our TL;DR audience with a nice rundown:

 * Download Figma Mirror to your device
 * Decide on a frame you want to preview on a device
 * Find out the "dp" of your device
 * Set Figma frame to correct width for your device
 * Voilà
 * World domination?

With this method you'll be able to translate your Figma designs onto the device in the correct ratio.

In conclusion, this is a great way to test your design for readability, contrast, and other industry requirements on a real device. For bonus points, you can go a step further and use this to prototype your design on an actual device and show your clients how your design will look on a device they’re holding in their hands.

Thank you for taking the time to read this post. Feel free to share your thoughts and drop us an email at hello@prototyp.digital. 😄

AuthorIvo Anić

Start a Project