Design

## Overview{overview}

**Variables are the latest addition to the functionalities of Figma. They are derived from programming languages and serve the exact purpose as their name suggests - to hold variable values. I won’t be describing the functionality in depth here; learning materials are available on the Figma website and YouTube, and many videos have been produced on this topic. I'll instead focus on how, with basic knowledge, you can utilize them to create a dark mode for your project and, in the meantime, give some tender loving care (TLC) to colors in your Design System - hopefully not a long-awaited one ;) - but we all know how it is sometimes.**

## When is the right time for a styles-to-variables switch?{id}

I’ve asked this question directly to the Figma advocate himself, and the answer was an expected 'It depends.' Actually, I cannot give any other, better answer myself. But I can give you some signs that made me decide that 'it is time'. And of course, as a disclaimer, everything depends on the nature of your project, available time and resources, the openness and willingness of the client to participate, and your interest in this topic as a designer. Of course, if you have the opportunity, I really encourage you to try starting with variables right away when beginning a fresh project. However, more often we find ourselves somewhere in between projects, jumping in at the middle stage or inheriting work from another designer. So, without further ado, here are some catalysts that started the variables reaction in my brain:

- **Out-of-date color palette in the design system** - this was the result of the ongoing design process and the recent addition of new colors. We wanted to wait until all UIs were ready and set to clean up the palette.
- **Curiosity about the feature** - pretty self-explanatory. After the release and many presentations of the feature, we wanted to try it ourselves and, of course, learn in the process.
- **Problematic and not useful style names inherited from brand guidelines** - we got the palette from the brand guidelines of the company and inherited the names as well. They worked at the beginning, but due to them being too long and Figma's limited space in the right-side panel, they were more of a burden than an assistance in the workflow.
- **Messy libraries on the frontend** - mostly due to mess in the design system palette, they needed a serious clean-up.
- **Less intensive time in your project** - when all design-intensive work is done, the UIs are handed off, and the role of a designer becomes more of a supporter/maintainer, it may be a good time for (spring) cleaning.

Request a free design consultation{contactBox}Facing design challenges? Contact us for a free consultation in just 1 step!

## Setting up part 1 - keep your project organized with styles, components, instances{id}

Before starting the process of implementing variables into an existing project, we need to do some prep work to ensure smooth and efficient (as well as effective – keep reading ;)) operation in the future. Here is a checklist of all the things we need to take care of beforehand:

- Ensure the component library is connected to your current designs and styles.
- Make sure repeatable UI elements are created as components.
- Ensure template screens are created as components and from components, and are used as instances throughout the project.
- Ensure all components are up-to-date and published.
- Check for colors without assigned styles and fix them.

![creating variables](/uploads/article_image_0744a831d0.png)

## Setting up part 2 - clean up your color palette{id}

### PRIMITIVES

Now that your project is cleaned up from an architectural perspective, we can tackle the colors themselves. Firstly, review your palette for any unused colors and styles. Maybe add new ones if they haven’t been added already and are used in your project. Next, organize them - if they aren’t already - into color groups (such as grays, neutrals, blues, pinks, reds, and so on), and also by values - lightest to darkest. You can eyeball it based on the HSL or HSB values, looking for luminance in the first one or brightness in the second. Based on this, you can group your colors and start renaming them to primitive values that will serve as a base for future semantic colors. I used the most common way and named my colors (Neutral/0, Blue/100, Red/800, and so on). This makes it rather flexible to add more colors in the future when adding a dark mode, with values that can range from 0 to 1000 (with 100 or 50-point increments).

![palette](/uploads/color_palette_32476f5284.png)

### SEMANTICS

With a primitive palette ready to go, we can now prepare the variable palette or semantic palette for better naming. This will require some thinking and planning on our part, and the semantic names need to be unique and indicative of the color's use in the app. We should avoid using the exact color name in the semantic name, as this will not serve its purpose as a variable color.

>*”Semantic naming involves giving meaningful and descriptive names to design elements, based on their function or purpose, in a way that is easy to understand and remember(...)” - quote by [Evan Reisberg](https://medium.com/@evreisberg/layer-names-who-cares-42389c2a2f93{nofollow})*

We can search the internet for many useful names, but some of them will be so specific to our project that we will need to tap into our creativity to name them. However, let’s start with something simple. Let’s divide our semantic colors into four groups: Fill, Outline, Icon, and Text. Each component, molecule, banner, input, form, or modal is constructed using some or all of these groups. Let’s take a small step and begin by creating some semantic names for Text. Here are some popular names that can be used in most projects:

- text/primary
- text/default
- text/secondary
- text/tertiary
- text/error
- text/warning
- text/success

Then, of course, we can explore less conventional and more creative names for how we use the color:

- text/decorative
- text/accent
- text/alternative
- text/inverted
- text/assistive
- text/brand
- text/inactive

Now, we need to assign primitive values to semantic meanings, although not yet as variables. This will also depend on your palette. For example, you can designate Neutral/900 as text/primary, Red/500 as text/error, and Purple/600 as text/brand.

![variables-example.png](/uploads/variables_example_fae2a6ae06.png)

Now, you need to repeat this process with Fill, Outline, and Icon. Determine the purpose of the color, name it, and connect it to a primitive value. Keep in mind that the same color in primitives can be assigned to many semantic values. This versatility is necessary to keep the library adaptable and ready to be converted into variables. For example, Neutral/900 – a dark color – can be used for text/default, icon/primary, background/accent, outline/accent, and many more.

## Creating variables{id}

### PRIMITIVES

With all the palettes ready, we can start setting up the variables. We open the 'Local variables' section in the right-side panel after deselecting everything on the canvas. Let’s begin by creating the first collection and naming it '_primitives' or '.primitives.'

>***Tip:** Prefixing the name of the component or collection with '_' or '.' hides it from being published. In our case, it's beneficial to hide it, so we can only see and use the semantic colors (which we'll create in the next step) in other files without cluttering the files with palette that is not meant to be used there.*

Next, we add each of our shades as a color value and name it the same as we decided earlier. The value of the primitive color will be a HEX value.

![all variable](/uploads/all_variable_d47cd29418.png)

### SEMANTICS

With the primitive palette ready, let’s quickly add, in a similar manner, the semantic palette that's going to be used throughout the whole project. Start by creating the next collection – you can name it 'semantic' or anything that resonates with you and your use of it. Next, we add each semantic color as a color value and name it the same as decided earlier. The value of each semantic color will now be aliased with a value from the primitive palette.

![semantics](/uploads/semantics_dbc38a419c.png)

## Assigning new colors to your interface{id}

This step can be time-consuming, depending on the scale of your project. We need to publish and assign the semantic colors to our designs to ensure everything works smoothly. I will share some tricks and shortcuts to expedite the process ;)

To start, try assigning the colors to your master component in your Design System/Style Guide or any local master components in your project files. This should address most of the color occurrences without needing to go through each screen individually. Simply publish, update, and check for any oversights. If any remain, let’s not waste time and try some clever solutions to fix them.

### TEXTS

Take advantage of the 'Edit -> Select All With -> Same Font' function. It will quickly highlight all text with the font you previously selected, and through the 'Selection colors' panel, you can efficiently assign all text/... semantic colors. Repeat this process with all fonts in the file to ensure you catch any that were not connected to a style.

![article image](/uploads/texts_7a2a7ad023.png)

### ICONS

For icons that are variants of an instance, simply select one and go to 'Edit -> Select All With -> Same Instance.' Assign all icon/... colors appropriate to their function. Alternatively, use the Search function by pressing command+F and typing 'icon.' All layers and elements with this word will be found, allowing you to quickly assign the semantic colors through the 'Selection colors' panel.

### BORDERS

For borders, you can try the same trick with the 'Edit -> Select All With -> Same Stroke' function. However, be cautious, as some borders may have the same hues but require different semantic values.

### FILLS

Fills are the most challenging to optimize. You can attempt using 'Edit -> Select All With -> Same Fill,' but here, even more than with borders, you may encounter cases where the same color needs a different semantic assignment. Proceed with caution to avoid confusion. Hopefully, there are now few unassigned colors left, and you can manually check them one by one.

You can stop there if your goal was to update your current palette to variables, but I will continue to show you how, with all this preparation now done, you can easily add a dark mode.

## Preparing dark palette{id}

The process of creating any additional palette, whether it's a dark palette complementing the default light one, or the other way around, is a creative playground. After considering our brand theming, limitations, and accessibility guidelines, we have a pretty clear circle within which we can experiment. Should we go with monochromatic grays and blacks? Or perhaps add a hint of blue to match the brand? The choice is yours. However, don't be intimidated; this process can be overwhelming, so we'll take it step-by-step together.

- **Gather a test group** - depending on your project's size, assemble around 15-20 unique screens. The more diverse, the better; include validation screens, fewer empty states, or starting points.
- **Gather color inspirations** - from sources like Mobbin, Behance, Dribbble, and Pinterest - feel free to explore everything, everywhere. We're not just looking for UX patterns; today, we're artists!
- **Start experimenting** - replace backgrounds, text, icons. Is the validation text lacking contrast? Adjust it! Are there colorful elements? Tone down their saturation to make them easier on the eyes. Try adjusting your device screen brightness to check contrast and visibility.

Once you're satisfied with the chosen colors and have checked their accessibility and contrast, it's time to assign them their respective values for the light mode.

## Adding dark mode colors and variables{id}

Let’s start with creating primitives. You may have used some shades that were already in your primitive palette, so let’s now add the ones that are new. Follow the same steps as when you were creating primitives for your default palette.

Now, the organization continues by matching the light mode colors with the dark ones in your semantic palette. The good thing is you don’t have to think of names again. Place the color value for light and dark next to each other for each semantic name to make it easier for you and the developers in the future.

![colors and variables](/uploads/colors_and_variables_81424375aa.png)


The only step left now is to alias new values in the second column of the semantic palette in your local variables. Don’t forget to publish your changes ;)

![dark mode colors and variables](/uploads/semantics2_2666289f20.png)

## Let the magic happen{id}

After successfully adding new mode and the variables being assigned to your design, you can now easily switch modes using the 'Setting' in the Layer panel. This function works on a single frame as well as on a section, allowing you to batch change many designs at once. It's truly satisfying to see how your designs automatically switch to dark mode after all your hard work. Take a moment to preview this magical transformation!

![Light-to-dark 2.gif](/uploads/Light_to_dark_2_1e7a730ac5.gif)


## Summary{id}

It's been a long journey, but the first time is always the toughest. Having now applied this process to both smaller and larger projects, I find it gets quicker each time. Keep in mind that this is just one application of variables. By following a similar workflow, you can also create modes for responsiveness. Anyway, don't limit yourself to the light side of the force - dare to explore the dark side of your project ;)

Interested in more? Learn about what we do in the field of [UI](/services/ui-design), [UX](/services/ux-design) and [UX audits](/services/ux-audits). Trust an experienced [software development company](/).




# **Dark mode made easy with variables**

## A step-by-step guide to creating scalable, structured, flexible and effective dark mode for your project.

large_dark mode.png

medium_dark mode.png

small_dark mode.png

thumbnail_dark mode.png

dark mode.png

Overview

When is the right time for a styles-to-variables switch?

Setting up part 1 - keep your project organized with styles, components, instances

Setting up part 2 - clean up your color palette

Creating variables

Assigning new colors to your interface

Preparing dark palette

Adding dark mode colors and variables

Let the magic happen

Summary

Dark mode made easy with variables

## Introduction{overview}

**Whether you are a solo designer in your company, part of a small team, have a tight budget, or lack the time to organize a professional, moderated, comprehensive usability testing - this article is for you.**

I'll be focusing on sharing how my team and I approached conducting usability testing on a small scale: limited features, a dozen or fewer testers, a few days, and no extra budget - just the regular working time.

## Project background{id}

While developing a new application for our client, we decided to conduct our first usability testing. It was during the wireframing phase that we wanted to check the reactions to some of the key features we were designing. The second usability testing occurred a few months later while designing a complicated flow. After a dozen rounds of iterating on the design, we agreed that external insights were necessary. We wanted to verify if what we thought worked actually did, and if users behaved and followed the paths we assumed they would. At this point, we were already anticipating some of the outcomes, but hard proof was needed to convince our client that a semi-radical change in design and information architecture was necessary.

Request a free design consultation{contactBox}Facing design challenges? Contact us for a free consultation in just 1 step!

## About the UseBerry tool{id}

Our attention was drawn to a tool called UseBerry. We can create a free account and use it to a limited extent, but for small-scale usability testing, it should be sufficient. The free plan allows for 10 responses from testers per month, 1 project, and 3 versions per project. After setting up an account and creating a workspace, we are ready to create a project, where all the exciting work begins. We can start a project from scratch, but pre-made templates are also available. You can find them in the Template Gallery after creating a new version of your project.

![article screen](/uploads/Image_1_2x_ea0179fc1e.png)

## Preparation phase{id}

### Preparation outside UseBerry (inside a design tool of your choice)

Usability testing is typically conducted using several prototypes, including the flow we intend to test. The first step is to prepare everything, including the prototype. The most effective way to test a feature or flow is to provide the tester with access to the entire app or a significant portion of it. This prevents scenarios where a non-clickable UI element accidentally guides the tester to our preferred execution of the task. The more paths and corners the tester explores, the more reliable the outcomes of the task execution.

However, we must be aware of the curious nature of humans and ensure that the tester understands they should focus on the task at hand rather than exploring every corner of the app. This can potentially lead to assuming that ✨*a curious wander through the meanders of a feature*✨ is actually an inability to find or execute a given task.

![article screen](/uploads/Image_2_2x_3b04102923.png)

Another preparation step is to write scenarios or tasks. This depends entirely on the nature of our project and what we aim to test. Some points to consider when preparing scenarios for testing: tasks should be written concisely and clearly, we should avoid leading or misleading the tester with our wording, and no clues should be given regarding the execution of the task. Here are some examples of how a task title can be structured:

- “Add a product to your cart”
- “Change your password”
- “Fill in information about your address”
- “Book a trip to Paris”
- “Report an issue with your order”

We should avoid providing a designated location or a specific method to execute the task. As an addition, we can actually provide instructions or a background story for the task. This may include why the task is important, how the user ended up in this situation, or additional details regarding the task. However, the title should be clear enough that even without reading the description, the user can successfully complete the task.

### Preparation inside UseBerry

Once our prototype is ready and tasks are written, we can upload them to UseBerry. The prototype can be uploaded either directly from the website or via the Figma plugin. Everything we send will be stored in our Team library.

![article screen](/uploads/Image_3_2x_672f65eb53.png)

In the side panel, we have a variety of blocks to build our testing journey. The Intro and Thank You screens serve as a good way to inform our participants about what they can expect and to express gratitude for their time and effort. Additionally, we can include rules, estimated execution time, and privacy statements if our study is anonymous. A good and concise example is provided in the template we selected at the beginning.

![article screen](/uploads/Image_4_2x_5308725e97.png)

The other blocks allow us to check a single task, multiple tasks at once, ask free-text questions, measure usability with the System Usability Scale (SUS) questionnaire, check preferences, demographics, first clicks, or ask Yes/No questions.

To fully set up our testing experience, we just need to connect the prototype to a block, fill in the title and instructions, and specify when the task can be considered completed successfully. We have two options here: when the testers follow a specific path or when they reach the selected screen. Depending on the scenario and project, both options can provide insightful results. Personally, I prefer setting up completion based on a specific screen, as it allows our testers to explore and find their own way to succeed in a task, which may differ from what the designer considers the optimal or correct way.

![article screen](/uploads/Image_5_2x_0d36ca49f7.png)

When everything is set up, we can perform one final check before publishing the test to a broad or small audience. The 'Preview' option is excellent for assessing the end tester's experience and identifying any bugs, typos, or missing connections in our prototype. These run-throughs do not collect any data, allowing you to thoroughly pre-check your usability testing. You can also invite others, who will not participate in the final testing, to identify errors and suggest improvements.

![article screen](/uploads/Image_6_2x_267680a825.png)

### Publishing

The last step of the preparation phase and also the first step into actual feedback gathering is to publish the usability testing. This is very easy and straightforward. If we're sure our testing is ready to be sent to the testers, we simply enter the 'Share' tab, which offers many options regarding the testing experience. We can enable session recording, set up testing language, capture video shots of testers, and implement protection measures such as passwords. Additionally, we can add custom variables if we want to create groups with testers from different backgrounds to better understand how different groups may exhibit varying behaviors and execution patterns. Finally, we enable the link and send it to the testers.

![article screen](/uploads/Image_7_2x_1677431692.png)

## Where to find testers{id}

Finding people willing to test the functionality may be challenging, and finding people who are willing to do so for free is even more difficult. So, what can we do with no budget, little to no time, and no group of friendly testers waiting around? 

One option may be to look closer rather than further. We cannot enlist our project colleagues to perform the test, as they may already be familiar with the feature or information architecture. However, there may still be some colleagues who have not been involved in the project and can be invited to participate in the testing. Additionally, if we have a client we're working for, it's worth asking whether people from the client's company are willing to help. Individuals from departments outside of IT, such as HR, Marketing, Operations, Sales, and Finance, can provide a range of insights and help eliminate industry bias from the testing process.

>*If your project is not under a non-disclosure agreement (NDA), you may reach out to your private friends and groups on social media. Since we're still discussing small or no-budget testing, I won't include testing agencies or other types of testers' recruitment processes.*

## How to analyse findings{id}

After all of the invited testers have finished their sessions or when we decide to conclude the testing, it's time to analyze the findings. We can approach this in many ways. In the 'Results' tab, we are provided with a range of metrics to compare each tester's session. Initially, we receive a generic overview of the number of users who completed the study, users who dropped off, and the overall average execution time. If our pool of responses is not very large, we can “theatre play” and track step-by-step how each tester attempted to solve the task. More generalized results can be observed in the User Flows section, where we obtain a visual representation of the path taken by each user, including any branching off along the way to the final screen.

![article screen](/uploads/Image_8_2x_5414a013bc.png)

The heatmap is another tool to gather metrics about our testers' sessions. It allows us to identify the most common patterns in user behavior and the elements they gravitated towards the most when navigating the interface. Each of these tools will be helpful in different ways; some may be the only thing you really need, while others may be completely useless—or anything in between. If you haven't received too many responses—could be up to 15—you can go through each tester's path in a relatively short time. The generic and average metrics can then serve as additional data. 

When reviewing the playback of sessions, it's helpful to formulate a set of questions and create a spreadsheet to document each tester's path. This allows us to identify which tasks or screens presented the most challenges for testers. Additionally, we can add comments to further describe our observations. Based on this analysis, we can easily document what we learned, what needs to be improved, and why. This serves as a foundation for iterating on the design. If necessary, we can repeat the usability testing process to validate improvements.

![article screen](/uploads/Image_9_2x_42a39e5128.png)

## Conclusion{id}

It's great when designs are based on user feedback and research. Even a small study can go a long way if executed properly. Each response can reveal the biases inherent in our decisions—biases we may not even be aware of. However, as designers, we also need to know when to rely on our experience and expertise. Users may initially resist changes to elements they were accustomed to, but in the long run, they may benefit from and become familiar with the new interface. We must use our best judgment and not be afraid to make mistakes, whether during wireframing, the high-fidelity stage, or testing. After all, errors are a fast but often unpleasant way to learn a lesson. May your usability tests produce insightful results!

Not sure what is the best approach for your project? Reach us out! We will help you choose the right [UX/UI](/services/product-and-ux-ui-design) solution. Trust an experienced [software development company](/).

Interest in another field of IT? Check our article: [Testing frontend logic with JEST](/blog/qa/testing-frontend-logic-with-jest).

# **Usability testing on a small scale**

## A guide to cost-effective, time-efficient, and resource-friendly usability testing using UseBerry.

Sharing is

Dark mode made easy with variables

A step-by-step guide to creating scalable, structured, flexible and effective dark mode for your project.

Usability testing on a small scale

A guide to cost-effective, time-efficient, and resource-friendly usability testing using UseBerry.