Designing in Figma can be challenging. One wrong move can lead to outdated design files, broken links, and confused teams. We, as designers, must keep the design up-to-date and need to think about changes and new features. Some designed features may wait a long time for development to start, which we need to consider.

This is important for QA, developers, and clients. They need to see relevant designs. Any confusion can lead to misunderstandings, defects, and extra discussions. If the designs were clear and relevant, the issues could have been avoided easily.

Managing versions adds another layer of complexity.

In this article, I’ll share how we at Devexperts manage designs in Figma. I’ll tell you about our approach at the beginning of our project, how it evolved, and the approach we’re using now.

Also, I will tell you about our use of branching in Figma and why it didn’t work for us.

Our goals are to make design files simple to review and navigate. We want everyone involved in the review process to find them clear and easy to understand. And we need to keep Confluence and Jira links active and ensure they point to the right design versions.

If you’re a designer, lead, or part of a product team using Figma, this article is for you.

Approach №1 — Designing on a single Figma page

At the start of our trading app project, we organized all designs on one Figma page. This page displayed frames for every design in each app section, such as “Order Book,” “Watchlist,” and “Order Entry.”

Globally, we organized these frames into three categories:

• Released — implemented designs,
• Dev Release — designs are ready for implementation,
• Concept — design concepts with future improvements, not approved yet.

Every time a frame with a new feature or improvement moves from “Concept” to “Dev Release,” and then to “Released.”

Each frame had a link to a Jira task and a Confluence page with the requirements for each section of the app.

A major downside of this approach was replacing “Order Book” with “Order Book v2” after implementation, which broke existing links to the previous design.

At that time, we didn’t need to create an archive and send previous designs there.

In the beginning, it wasn’t a problem yet.

Approach №2 — Designing across many Figma pages

Over time, each frame grew, and a single Figma page was no longer enough.

To handle this, we decided to break it into several Figma pages, each covering a different section of the app.

We renamed the categories to “Released,” “Ready for Development,” and “Drafts,” which helped to clarify their purpose.

This approach worked well overall, but it had a few downsides.

The main issue was that the new feature or improvement could affect many parts of the app. That’s why we had to create a different set of frames for each page/section of the app.

That helped us keep everything organized, but it created some complications for tracking.

Checking the new feature or improvement meant jumping between many pages. This made things more complex.

Sometimes, features/improvements can be delayed for a long time, or they might be canceled. We started accumulating them in a Figma file.

If many designers work on the project, they may miscommunicate or forget things over time. This can lead to the creation of new features/improvements without considering the old ones.

The frames began to conflict with each other.

As a result, the team struggled to understand where they could find the relevant design. Comments and statuses didn’t help.

Another difficulty was component management when working on new features/improvements.

Designers began creating new versions of components or detaching original components, which caused more components to appear.

It also meant extra work to maintain them.

. . .

We realized our system needed improvement.

We decided to simplify our design process. We wanted to have only relevant (that matched with implementation) designs in Figma.

All new features/improvements were transferred to native Figma branching functionality. At that moment, we had heard about it, but we did not use it.

But we started by completely redesigning our Figma file.

Approach №3 — Redesign and Figma branching

We started by reviewing our designs to ensure they matched the implementation. Then, we fixed the inconsistency. We removed outdated frames from the main file and put them in a separate archive file.

We split the big frames into smaller frames, each focused on a specific action. For example, “Cancel Order” has focused only on the order cancellation process.

We created a “Table of Contents” with quick links to each frame, simplifying the search process.

Eventually, this helped everyone: QA, developers, and the client. They could find the right design, inspect it quickly, and not get distracted by other designs.

We refused to use the categories “Released,” “Ready for Development,” and “Drafts.” We didn’t need them because we moved them into Figma branches. We had aimed to use branches for all our future updates, bug fixes, and other improvements.

This, as we thought, would help us avoid having too many frames in one file.

But it caused a lot of other problems.

Figma branching and the nightmare

At first, we believed Figma branching was a great idea. It seemed like a perfect way to organize our design files and keep unimplemented features separate.

We moved our future improvements into Figma branches and updated the links in Jira and Confluence. After, we began working on new features and improvements directly in Figma branches.

Our flow was like Figma’s branching workflow:

Here’s how our process looked:

1. We received a change request, design improvement, or new feature request.
2. We created a new Figma branch.
3. In the branch, we updated components connected to the main file: adjusting flows, moving screens, and reorganizing sections as needed.
4. We waited for implementation.
5. We merged the branch back into the main file with all these changes.

Here, one detail about Figma branches is worth mentioning.

All updates are one-way, always from the main file to the branch. If you make changes in the Figma branch, this change only applies to this branch. When you change something in the main file, Figma will notify any branches that need to apply this update.

A modal window will show the comparison/conflict between the component in the main file and the same component in the branch. You need to choose which one you want to use in the branch: updated or original from the main.

After a while and many Figma branches, we started to receive many requests to update from the main file. Since improvement is a never-ending process, we have to make small updates to the main file on a regular basis.

And applying these small changes every time was very annoying.

Soon, we encountered an unexpected issue with the components. If a designer updates a component in the branch, they might lose those updates. This can happen if someone else changes it in the main file, and the designer agrees to that update for the branch.

We did this several times in our practice by mistake. Figma sometimes didn’t clearly show the difference between the original components in the main file and the updated ones in the branch.

Figma shows every update from the main file, even those not connected to your new branch. Sometimes the amount of conflicts was huge.

We even had a fun screenshot contest to see who could capture the biggest amounts of conflicts.

Reviewing so many conflicts is unmanageable, and unintentional overwriting becomes bound to happen.

Realizing that this approach wasn’t sustainable, we decided to update our approach a bit:

1. We receive a change request, design improvement, or new feature request.
2. We created a Figma branch.
3. We created a new page in that branch. We put all our updates on this page.
4. We waited for implementation.
5. We merged the branch back into the main file with all these changes.

With this approach, we didn’t change the main file’s components. We made new components based on the main file with the prefixes v2, v3…

This allowed us to keep the components for the update separate from the ones in the main.

When we got updates from the main file, we simply clicked “Resolve All.” We didn’t check anything, and we didn’t have to worry about overwriting anything.

Life became easier, but we still spent a lot of time applying all these updates. Sometimes, it took a few minutes every time we opened a Figma branch.

After that, we encountered another problem.

“Give it a rest,” you might ask!

The problem is… the fact that features/improvements can be postponed for a long time. It’s become a problem again. If you don’t open your Figma branch for a while, you’ll miss updates from the main file. This can lead to your branch breaking and not opening due to the updates stacking up.

Because of this, we often faced errors when syncing updates from the main file.

After weeks of struggle, we gave up and finally admitted that branching in Figma didn’t work for us.

We decided to rebuild the process once again.

I need to clarify: we base this opinion on our design experience.

For example, we build our design mockups from components. We have small components and large components composed of the small ones. Also, full screens are sometimes components, too. Changes in small components impact the larger components that they are a part of.

In our iOS Figma file, we have 1 407 components and a total of 51 043 layers.

If your system is less complex and you can quickly add features, Figma branching could be a good choice. In our case, this functionality is completely unusable.

Approach №4 — Duplicated Figma files

We decided to move away from Figma branches.

At exactly the same time, we went to production, and the client decided to have versioning. One version was in production, going through QA testing and bug fixing by developers. The second version included the upcoming release with new features and updates.

They shared the release roadmap, which listed all the new features that had been waiting to be released until then.

It became clear that we couldn’t store designs for two different versions in a single file. Especially if we wanted to have two versions, keep the relevant links, and not confuse anyone.

And we came to the following solution:

Here’s how it works:

Let’s assume that the Figma file version 1.0 is our main file, which matches the version in production. It has all the components, styles, colors, and fonts there. Designers fix bugs and add missed flows or extra screens to this file. QA checks it. Jira links lead to this file. This file is completely self-contained and is not connected to any other files.

New Features and Design Updates is a separate Figma file for new features and improvements. This file has access to components, colors, and font styles from file version 1.0.

When the Figma file version 1.0 ends its lifecycle, we archive it and create a duplicate of this file. This file will be the Figma file version 2.0, and it is our new main file.

Now, we’re working with this 2.0 file, and it will receive new features or updates in the future.

The Figma file version 1.0 has become low maintenance, where we only make minor changes. We are focusing our full attention on the Figma file version 2.0

We added tabs for each page in both the 1.0 and 2.0 files to facilitate navigation. Thus, it’s easier to switch quickly between the previous design versions and the New Feature File.

While duplicating Figma files solved many issues, it also introduced new challenges. Managing many files requires discipline, and ensuring consistency across versions demands extra effort.

Yet, for our needs, the advantages outweighed the disadvantages.

“New Features and Design Updates” Figma file

We collect all new features and design improvements in the file “New Features and Design Updates”. This is the main place where we review and discuss any updates to the design. Every page in this file contains a new feature or improvement.

Pages are sorted into three statuses: In Progress, Ready for Development, and Done.

The pages include these categories:

• Status indicates the current status of the new feature or design update.
• Design Specification provides developers with clear instructions and task details.
• New Flow contains any newly created flows, if required.
• New Components lists new components created for this feature or update. Some components may be shared across multiple features, helping to avoid duplication.
• Prototype includes prototypes, if required.

This file is connected to Figma File Version 1.0 (2.0, 3.0, …). All updates rely on the components from those Figma files. We can swap components between files without any problem.

They have the same name, so it doesn’t matter if the update uses older components or new ones.

After implementing the update, we apply it to the main file. Then we update the status and move the page to the archive section. This keeps it for historical purposes since Jira, Confluence, and Slack links refer to it.

Using this method, we can collect new features and improvements away from the main file and apply only the changes made in the code.

We can see in design what we see in production.

Conclusion

Our project has made huge progress. We began by locating all designs on a single Figma page. Now we duplicate entire files and manage new features/improvements in a separate Figma file.

Maybe we will enhance our process even more or try something new one day, but for now, this approach works for us.

As a result, our processes were impacted on many levels. Here is what we achieved:

• Removed irrelevant designs from the file, which now match the implemented version.
• Made a clear distinction between the current design and updates.
• Created a version history for each app version.
• All links in Jira, Confluence, and Slack do not break and will remain active forever.
• Organized and created a Table of Contents to provide an easier way to find designs.
• Began to receive fewer questions about how to find something in Figma.

That’s great progress.

Who knows, perhaps Figma will improve branching someday. Let users change specific parts instead of the whole file. This will make versioning easier. We’ll be looking forward to it.

Until then, we’ve found a versioning system that works for us.

If you’ve struggled with branching like we did, maybe it’s time to rethink your Figma workflow too.

Thank you for reading!

See you!

Why Branching in Figma Didn’t Work for Us, and How We Manage Design Versions Now was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most trading education platforms have a charting module. Some are basic, some are better. But nearly all of them share one thing in common: they weren’t designed with education in mind.

While trading platforms continue to evolve for professionals, adding speed, depth, and analytics, educators are often left working around charting limitations. Teaching technical analysis still too often means showing screenshots, copying candlestick patterns into slides, or jumping between a platform and external tools just to explain basic concepts.

I think it’s time charting caught up with the needs of educators.

That’s why our team at Devexperts created a short PDF: “The Future of Trading Education: Advanced Data Visualization with DXcharts”. It outlines how a smarter charting tool — built with education in mind — can solve daily pain points for instructors and enhance the learning experience for students.

The PDF introduces a set of features we’re rolling out in DXcharts, our financial charting library. All of them are designed to make technical analysis easier to teach, explore, and understand. If you work in trading education — whether you’re running your own learning platform, offering training to clients, or building a curriculum into a trading app — this is worth a look.

Here’s what’s inside:

Pattern recognition using historical data

Spotting patterns like flags, triangles, or double tops is fundamental to technical analysis. But learning to recognize them takes time and exposure. DXcharts introduces automatic pattern recognition on historical market data, so students can scroll back and study how these setups played out in real time. Educators can also use this to quickly demonstrate key patterns without building them from scratch.

Draw-to-pattern conversion

Need to explain how a head & shoulders looks on a real chart? Just draw the shape roughly and DXcharts will match it with a candle-based formation pulled from actual historical data. This makes on-the-fly explanations much easier and helps learners connect abstract shapes to real-world behavior.

Built-in lessons with real-time chart context

Instead of jumping between a learning platform and a trading interface, DXcharts lets educators embed lessons directly into the charting environment. You can explain what a candlestick means, highlight trends, or annotate live setups — all from within the chart. Content can be imported from Notion, Confluence, or Miro. If you don’t have your own materials, we offer a technical analysis knowledge base to get you started.

Collaboration mode

Learning to trade is often a solo activity, but it doesn’t have to be. With real-time collaboration (similar to Miro or Figma), students and instructors can analyze charts together, identify patterns, and even simulate trades using paper money. It’s designed to make group learning and coaching more effective, whether you’re in the same room or halfway around the world.

Stories-style market summaries

DXcharts also includes a story-like interface (think Instagram or LinkedIn Stories) that gives personalized updates on instruments a student is following. These short summaries highlight what’s been happening, what the current sentiment is, and what market data may suggest next. The goal is to keep students engaged with the market in a lightweight, habitual way, without needing to dive deep every time.

Who is this for?

This PDF is aimed at trading education providers: platforms, brokers, or independent educators who want to offer a more interactive and insightful experience. Many of Devexperts’ existing clients already offer trading functionality — our goal is to make the charting layer more useful for educational workflows.

If you’re building or running a trading education platform and want to talk shop, get in touch with Devexperts. We’d love to hear how you’re teaching the next generation of traders.

Modernizing Trading Education with Smarter Charting Tools was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.

This year our team worked hard to develop a new Figma plugin called Color Management. This plugin is an excellent tool for quickly and effectively repainting your mockups and creating new color themes in Figma. This series of four articles will take you through the complete journey, from how and why we made it to the problems we faced while building it and the final result.

Who we are and what we do

Hi there! I’m Vitaliy Voronkin, a UX/UI designer at the international fintech company Devexperts.

We create solutions for Web, Android, iOS, wearable devices, and even smart speakers that serve a global audience with trading platforms for brokers and investors, exchange software, money management platforms, and data exchange solutions with financial platforms.

Our main product is the DXtrade trading platform, which we sell on a SaaS basis. For every new client, we create a DXtrade White Label — we develop a new, unique color theme and add a client logo to the trading platform. We base the first release of a custom platform for each customer on the initial product and then slightly evolve it throughout the product life cycle.

Deep customization of our products is one of our strongest advantages — it allows us to customize all UI elements. Our clients have total control over how their platform will look and feel.

Do you want a professional platform that looks like it means business? Sure, here you go: muted colors with a focus on content. Want your users to have fun? Spice up the interface with vibrant colors and gradients.

It sounds cool on the surface, but this level of customization comes with some technical difficulties and peculiarities to make it happen. We’ll get to this a bit later.

How we do the things we do

We — the designers — work in Figma, a popular cloud-based design tool that helps us effectively develop and maintain our user interface designs. We have a design system in which all our layouts are made with components, each with its own Figma style.

A Design System is a collection of reusable components, guided by clear standards, that can connect to build any number of applications. It is the single source of truth that groups all the elements that will allow the teams to design, realize, and develop a product.

Figma styles are basically a set of variables that helps us organize the colors of UI elements. You can attach a color style to as many elements as you want and control the colors of each one with these styles. For example, whenever you change a text style’s color from red to blue, Figma will apply those changes to any objects using that style.

Now you know how we maintain our design mockups in Figma. But how do we guarantee that our final product will always match our designs? We’ve built a special tool for this purpose called Chameleon that consists of two components: the Figma plugin and web storage. The plugin allows us to export color styles to Chameleon web storage, and developers can deliver them to our products.

So, the overall process looks like this:

• We store and maintain our design layouts in Figma.
• We use a self-made Chameleon Figma Plugin to export all the color styles to web storage.
• Developers deliver data on UI elements’ colors to our products in different formats depending on the platform they work on (web or mobile).

You can read how we’ve built the Chameleon tool on Medium.

Where is the problem hiding?

With the approach described above, we can quickly update the color theme in the design and the actual products. But for every new client, we were spending too many resources on the first step — creating a new color theme in Figma for the white-label product.

That’s where our customization ability complicates things.

First things first, we make a duplicate of the master file in Figma with all the designs we need. We have hundreds, if not thousands, of color styles here, which is the exact problem we were trying to solve. The way Figma works, you have to go through four steps (clicks) to change even one style value. You must select an element, click on a color style, click on the “edit style” icon, and choose a new color. And we have hundreds of them.

When you think about how many clicks you have to make to change the value of just one style, you can see our problem. Now imagine a complex layout on several pages with 700+ styles. Do you have a headache yet?

This issue plagued us, slowing the first stage of creating a new platform to a crawl. It inflated our costs and deadlines for delivering a product to the client.

Searching for ready-made solutions 👀

We first tried looking for existing solutions that we could use to rid ourselves of this massive pain. The only tools that could help us fix our clunky change-styles-in-Figma workflow were plugins. So, we searched high and low through the Figma community, hoping to find one that fits just right. Sadly, no dice. There was no shortage of plugins for creating, maintaining, or deleting color styles, but none helped us out of our specific bind.

We also asked designers across different platforms — Reddit, UX stack overflow, Figma forum, and so on — how they are solving this problem and if they knew of any tool that could help us. We got a few responses with some plugin suggestions but nothing really suitable for our case.

At that point, the only path forward was to create the tool we desperately needed ourselves. That way, we could consider only the details relevant to our situation and, as a huge plus, end up with a plugin that fully integrates with our design and development processes.

What exactly are Figma plugins?

Well, plugins are small applications created by the design community that extend the functionality of Figma. Plugins run inside Figma projects and perform one or more user actions. They allow users to customize their experience or create more efficient workflows in Figma, which is exactly what we needed. You can visit the Figma Community and browse through a list of the available plugins to get a better understanding of the functionality they offer.

Conclusion

So, the plan was to make a plugin and integrate it into our processes as the codable paracetamol to rid ourselves of the workflow headache and speed up the development cycle. Once we decided on the development, we started working on the concept for a new tool.

Thanks for staying with us so far! In the next article you’ll see:

• What concept we had in mind when we started development,
• What went wrong during the development,
• What the MVP version was like.

See ya! 👋

How We Built the Color Management Plugin for Figma. Chapter 1. Research and Ideation was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi again! 👋 This is the second article in a series of four in which we describe the process of developing our Figma plugin. Check out the previous article if you haven’t seen it yet:

Part 1. Research and Ideation.

The idea 💡

The initial idea was very simple and went a little something like this:

Let’s make a Figma plugin that allows us to quickly change the colors of complex design layouts. It should be easy to work with multiple styles at once. Also, when using the plugin, we should always stay in context and be able to instantly see all the changes.

The first thing we did was break this idea down into separate features. This information helped us understand how the UI of our plugin should look before making any drafts. In short, we needed two workspaces in our plugin: one for displaying the color styles we’re working on, and another with a set of controls to change these styles.

You may encounter the word “token” at some points in our articles. A token is pretty much the same as the color style we were talking about earlier, except they don’t always define a color — it may be the size of an element, rounded corners of elements, font size, etc. For our purposes, we will use “token” as an alternative name for color styles.

The list of features we needed looked something like this:

• Since color styles are the main objects we’re working with, we needed a token list area in the plugin to manipulate them.
• We needed the plugin to work with a huge amount of Figma styles, so the UI should allow us to work with single and multiple styles at once.
• We should be able to sort tokens alphabetically to find specific tokens among the others.
• We should be able to group tokens by hue to make it easier to select similar colors and change them to whatever we need.
• We also should be able to filter tokens to work only with the necessary tokens in the list.
• To work with color styles, we needed some controls. We decided to add Hue, Saturation, and Brightness sliders. They will allow us to change the color by moving these separate parameters. It makes it easy for us to find the color that fits in every particular case or, for example, when we simply need to adjust the brightness a bit.
• But what if we already have a specific color in mind that we want to use? Trying to pick the right color via sliders is not exactly intuitive. So why not add a default Color Picker component as well? We would just need to enter (or copy and paste) the HEX value of a specific color from elsewhere into the plugin. It also has a color pipette tool to pick any color present in your layouts in Figma. By adding both sets of controls, we covered all the bases for entering/changing color values in the plugin.

We had our dream UI concept based on the features we defined above:

Now it was time to knuckle down and actually make a design for it.

UI Kit

Since plugins run in the Figma environment as modal windows, it’s a good idea to use components of the Figma interface itself. That way, the plugins don’t feel out of place when you use them. It also significantly speeds up development and helps you create a UI that users are already familiar with.

Figma itself doesn’t provide a UI library, but there are community-made resources you can use. For example, the most popular one endorsed by Figma is a Figma UI library built by Tom Lowry. It contains open-source plugins, resources, and tools used for Figma plugin development. There are also several Figma-like UI Kits available in Figma Community.

Once we had rough drafts of the interface and a UI Kit from Figma Community with all the elements we needed, we were able to build a design specification for the plugin. And since our developers also used existing Figma components, the UI part of the plugin was implemented in a matter of a few days. I will unveil it in just a second.

Bugs, bugs, and more bugs…

It was time to test our little 0.01 version of the plugin. Obviously, we had some bugs we needed to take care of. But frankly, the only issues worth mentioning are the ones we didn’t think through during the design specification phase.

We had the wrong color format

The sliders for editing the color weren’t working as expected due to the incorrectly selected HSB (Hue, Saturation, and Brightness) color model. The way Brightness works in HSB did not allow us to accurately change the lightness of the color.

We switched to the HSL model where we have the Lightness parameter instead of Brightness. As we wanted, the values from 0 to 100 move the color from black to white, respectively.

If you want a better understanding of the difference between color models, check out this article.

There was no sync between controls

We didn’t consider the interaction between the sliders and the color picker. At this point in our story, we couldn’t use them together. For instance, we set a specific value in the color picker for some tokens and wanted to make it a little brighter with the HSL controls. The problem was that when we used the HSL controls, the color reset to default, and only then were the changes made by the sliders applied.

Luckily, both problems were solved with a new system that was kind of similar to “masks” in design tools. For every token, we have a default “before any changes” color, and there are layers with changes on top of it. For a better understanding, look at this scheme:

Final result

Behold! We finally had the first working version of the plugin! We implemented everything we planned for an MVP and got rid of all bugs. The interface of the plugin looks pretty much like the sketches I showed you before. Let’s go through all the features we have in detail.

Launch

On launch the plugin scans the Figma file and displays a list of tokens that are present in that file. Users can edit one or multiple tokens at the same time. All the changes are shown in the list, and you can also see a preview of the color both in the Default and Changed columns.

Filter Search

Since the plugin shows all of the existing tokens in the Figma file, and we usually have a lot of them, we needed a way to narrow down the list to show only the tokens we currently need. A filter search with basic input that shows all tokens that match the defined query did the trick. In the current version, searching by name and color is supported.

Sorting

For the MVP, we haven’t implemented any sorting options other than the default one — by hue — which felt the most convenient in our case. That way, for example, all the blue colors will be grouped, allowing you to easily select them and change them to a different color.

Sync Changes

Figma is a collaborative tool, so we needed to consider the case where several people are working on the same file at the same time. It’s possible someone else could change the styles while the plugin is active. So, we added a Sync Changes Button that the user can click on the plugin and refresh the token list.

Luminosity Lock

With the Luminosity Lock feature, you can easily recolor a big set of tokens and preserve the original color contrast of the mockup for accessibility reasons. It’s no secret that different hues with the same saturation and lightness (we consider all colors in the HSL model) can look different when it comes to brightness. This feature automatically adjusts lightness to keep the perceived brightness of the changed color the same.

There are several color style types present in Figma that we needed to support. On top of basic solid colors, our plugin supports gradients (it breaks them down into separate colors) and effects styles such as shadows (although the plugin only supports colors stated in effects, not the other parameters).

Thank you for reading this one to the end! In the next article you’ll see:

• Adding onboarding,
• Implementing a real-time preview,
• Tuning plugin performance.

How We Built the Color Management Plugin for Figma. Chapter 2. Creating an MVP. was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re back! 👋 This is the third article in a series of four in which we describe the process of developing our Figma plugin. You can find all links below.

Chapter 1. Research and Ideation.
Chapter 2. Creating an MVP.

A feature we’ve been missing

In the previous article, I told you how we made the first version of Color Management. It was very cool and usable but lacked a crucial feature we needed — Live Preview, the ability to change color tokens in the plugin, and instantly see the changes directly in design mockups. Starting out, we spent quite some time brainstorming different ideas. And this storm gave us the most valuable one we had. I’d go so far as to call it a killer feature.

Although we planned to implement it since the beginning, we couldn’t add it straight away in the first version because of the complexity and amount of work it required. We needed to build a stable foundation first. And now we have it.

Problems and solutions around real-time editing

When we work on the design in Figma, we get instant visual feedback on every action, like when we create some text, a rectangle, or a frame or change the text or color of an element. Figma plugins can interact with elements in the workspace too, but there are some limitations developers have to consider:

• Strict limit to the amount of data processed. There is constant data transfer between the Figma app and a plugin, and it has a very strict limit to the amount of data that can be transferred at one point in time. This crucial aspect demanded our attention while building Live Preview. Updating mockups in real-time requires quite a vast data stream.
• Availability for mid-range PCs. While the general idea of real-time features sounds ambitious, it can cause significant performance issues for mid-range PCs. We wanted to support as many devices as possible, so performance was something we had to consider.

We spent some time discussing different ideas and approaches, but the ultimate solution for both problems was quite simple — we limited Live Preview to the user’s selection. That way, a user must select one or more elements in Figma to start editing styles and see real-time changes in that particular selection. Since a Figma file can contain many layouts, it would be very difficult to instantly update the entire design file, and only high-end computers could handle this.

We also did several tests on mid-range hardware to see how many selected elements they could handle. The result was quite good — an old laptop could easily process a large set of mockups (around 40k elements).

Working on Preview Mode turned out to be one of those cases where one change led to another and another, improving the overall experience every step of the way.

At first, we added Live Preview as an additional mode turned off by default. Our hopes and dreams became reality! Preview mode was a roaring success. It was so much better than the default one (where the plugin shows all the tokens present in the file with no real-time preview) that there was no point in keeping the default mode in the plugin anymore. So, we just cut it out completely.

Adding onboarding

Enabling Live Preview mode by default led us to introduce other changes to the way the plugin works. Since Live Preview only works with specific selections, it was important to let the user know about that. If the user didn’t have any element selected in Figma before launching Color Management, the token list in the plugin would be empty. It was important to make an empty state where the plugin would tell the user what they needed to do to start working.

Instead of a standard empty state message, we decided to add an onboarding screen with small tips for users but make it as unobtrusive as possible. If the user doesn’t have something selected in Figma while launching the plugin, they go to onboarding with the message “please select a frame you want to work with to start” and an option to swipe to see the other tips. If the user has something selected in Figma on plugin launch, they go straight to editing tokens.

I don’t think the critical importance of onboarding is lost on anyone, right? Well, okay, for the uninitiated, onboarding is a series of screens that guide users through the app’s interface and functions. It facilitates a positive user experience and helps educate the user about the functions and benefits of the plugin.

“Let the system do the work”

After implementing Live Preview mode and doing some trial runs, we discovered some insights. By adding this function, we actually changed the way people work with the plugin.

In version 1.0, the plugin was showing all the tokens at once. For the user, it was hard to find any specific token in a long list, forcing the user to use search or scroll through all the tokens in an attempt to find the one they required. By allowing us to work only with a selection, big or small, we were able to speed up the process by cutting out the time wasted on searching.

We noticed that despite our previous experience with the plugin, it’s a lot easier to select small frames and groups with up to six or seven tokens, edit them, and move to another small set of tokens by selecting the next frame. It makes the whole process a lot faster than before.

But we were hindered by the need to constantly press the “Save Changes” button before moving to the next frame. The “save” button was supposed to help avoid errors while working with the plugin, but in the end, it only complicated the process by adding one more action we didn’t really need. It was a dead weight on the whole process, so we left it on the cutting room floor.

We deleted the button and added an autosave feature to the plugin. Now every time a user switches to another selection or just closes the plugin, all the changes made are saved automatically.

Additionally, we modified the action history so that if the user made a mistake or accidentally selected something in Figma, they can undo changes by simply pressing CMD+Z.

Wrapping up

All these features really changed how the plugin works and how we interact with it. They allowed us to work so much faster and more efficiently. But wait, there’s more! In this and the previous articles, we focused on the core features of our plugin. Now it’s time to add the final touches and make the plugin as user-friendly and convenient as possible.

Thanks for making it to the end! I hope you got something from it. In the next and final article, you’ll see:

• Usability upgrade — adding final features to improve user experience,
• Adding a library of saved colors to the plugin,
• Making the workflow even faster with keyboard shortcuts.

How We Built the Color Management Plugin for Figma. Chapter 3. Version 2.0 — Live Preview Mode. was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey! 👋 This is the last article in a series of four in which we describe the process of developing our Figma plugin. You can find all links below.

Chapter 1. Research and Ideation.
Chapter 2. Creating an MVP.
Chapter 3. Version 2.0 — Live Preview Mode.

So… where are we now?

After we ensured all the main functions were there and working as intended, it was time to take care of small (but important!) stuff: fix bugs and improve usability. This was our last phase of planned plugin development. We had a design team test the plugin, which yielded a lot of valuable feedback on both bugs and missing features. You’ll learn all about what we implemented in the final phase below.

Sort tokens alphabetically

The first thing we did was add an option to sort alphabetically. Though we already discussed it in the second article of this series, we decided to delay it until all the major features were done, so until that point, the only option we had was sorting by hue.

It worked well enough, allowing us to group and work with a lot of tokens with similar hues, but some designers had a problem with finding specific tokens if there were too many in the list. Yes, they could use search, but based on feedback in certain cases, it was a lot easier for them to just scroll the tokens list until they saw the one they needed. And the sorting alphabetically option makes navigation much easier. Of course, in that case, the designer should know the name of the token to find it. But since we have a unified naming policy for color tokens, and our designers work with them basically every day, it’s not a problem for us.

Reset single token changes

Another request we received was to add an option to reset changes in one particular token. Before implementing this feature, a user could only reset all changes at once by pressing (wait for it) the “Reset” button. In a case where many changes have been made, a user could lose a lot of progress by pressing “Reset”, so the option to reset only specific tokens was absolutely required. We added an icon button that was only visible for tokens that have some unsaved changes to accentuate it a bit and keep the interface clean as possible.

Saved Colors feature

While testing the plugin, I noticed that we use a lot of repeating colors in our designs, and it’s so annoying to just manually enter them over and over again for every token needed. It applies to the black color that we use for the main text, grey for additional text, and green/red for buy/sell, just to name a few examples.

In general, every project has its own limited set of colors. Imagine making a light theme for a product out of the dark one or just making a new color theme for a White Label product. In both cases, we normally already have at least a set of main colors before we start the work.

So, we had an idea to make a separate section in the plugin to store some colors and easily apply them to tokens. These were the requirements for the feature:

• It should be quick to access. All saved colors should always be visible and accessible.
• It should be simple to use. Ideally, it would take one click to apply a color to the selected token.
• It should be easy to manage. Adding or removing colors from these sections should be simple.

After a few design iterations, we ended up with a UI that looks like this:

To add a color to the saved section, you need to enter it into the color picker and press the + icon next to it.

Applying the color to the selected token requires just one left mouse click. You can, of course, select several tokens and apply color to them all in one click.

To remove the color from the section, double-right-click. It’s not a common pattern, but that’s exactly what makes it a great choice — you can’t remove a color by accident. A user can only do it intentionally.

Keyboard shortcuts

We value the speed of our workflow, so keyboard shortcuts were an absolute must-have for our plugin. All important actions should have a shortcut to speed up the process.

First, we needed to indicate to users that there are keyboard shortcuts in our plugin they can use. It was also crucial to visibly specify to the user what keys do what. Adding this information to onboarding felt wrong because most people only see it once. After that, they might skip it or may not even remember that there is info on shortcuts even if they needed it. Our aim was to add it as closely as possible to the token list where all the magic happens.

We added keyboard shortcut info to the footer, preliminarily hiding all the controls if no tokens are selected in a list. That way, users see it directly before starting to work on tokens.

Besides the common CMD+Z/CMD+A combinations, we added Figma-like shortcuts for changing the opacity of a token. Now, instead of typing the right opacity value in the color picker, a user can just select a token and use the numbers on the keyboard. Pressing the 6 key a single time will change the opacity to 60%. Pressing it twice will set it to 66%. Just press the button once for tens or two keys for a specific value. Since it works the same way in Figma, designers will have no problem using it in a plugin once they’ve already gotten used to it.

Another important shortcut we added is resetting a single token by pressing [R]. Yes, we added it before as an icon a user can click on. But in that case, despite it being very convenient for people who don’t use keyboard shortcuts, it worked only for one token per click. With a shortcut, you can select as many tokens as you like and reset them by pressing just one button. It’s also handy when you’re using HSL controls or the Saved Colors section — just hit [R] and start over if you don’t like the result.

Wrapping up

Of course, there was no shortage of bug fixes to make the plugin’s workflow more seamless and convenient. I won’t go deeper into that, as it’s just the standard process of testing and fixing any issues that come up. At this point, we accomplished everything we wanted and have a working tool that speeds up our process of creating new color themes for our products. Personally, I was able to finish the task in one hour using this plugin. Before that, a similar task would take around 4–5 hours for me to complete. Not bad at all!

We’ve come a long way from defining a problem and looking for a ready-made solution to designing and implementing such a complex tool.

And while our team is using the current version of Color Management in their work, we are making plans for the next stage of development: discussing ideas, making concepts, and so on. We see the future of Color Management as a fully automated palette generation tool that makes changing colors in design files a one-minute task. And hopefully, we will have something great to show you in the near future. Thank you for reading our full series of articles! If you missed any, here are the links to previous ones:

Chapter 1. Research and Ideation.
Chapter 2. Creating an MVP.
Chapter 3. Version 2.0 — Live Preview Mode.

See you soon! 👋

How We Built the Color Management Plugin for Figma. was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.

When i went from Brazil to Portugal, i wanted to understand my future, what was the career path i really wanted to follow and i found Project Management.

I talked to professionals in the area and researched what would be the best courses and certifications to enter the area and this right here is all that i learned and how i learned it, so let’s start with the learning part

The Who, the What and the Why?

It is safe to say that even if you never heard of project management, you possibly did something similar to it, the easy example is planning a birthday party, you made a plan, talked to the people of interest, made a budget, made a timeline and delivered a party. Maybe it wasn’t all this steps but something similar, this in itself is already a project.

What is a project?

A project is a temporary gathering of multiple different resources for the development of something specific and unique and are constrained by time, cost and resources.

How to define and organize a project?

We have to establish the goal, scope, time, budget and the organization.

Day to day life of a project manager?

But without all the pretty words what does a project manager do in the daily basis? This answer is tricky because it varies from project to project.

A project can be building a brand new skyscraper, hosting a wine event or simply developing a new software.

Generally we can say that a project manager have some activities that will cross all of those projects:

• Planning and organizing
• Controlling the budget
• Managing tasks

Is there demand for all of this managing?

Project Life Cycle

The phases of a project

Before the project we need to understand the each step of a project, why is important and what is done in each iteration.

The first step: Initiating a project

So the first part is to initiate a project, in this part you will have to figure out the basic questions such as:

What is this project about?
Who will work on the project?
What are the costs and how long?

The main defining points in the beginning of a project are: Goals, Scope, Deliverables, Success Criteria, Stakeholders and Resources

The holy trinity of projects:

Every project have three very important factors to it, that cannot all be accomplished the same way, if you change one of this factors the others will have to be rearranged too, those factors are:

Time: How long the project will take
Scope: Requirements, qualities and specifications of the project
Budget: How much it will cost

Each one of them will interact with the other, bigger scopes means bigger costs etc.

Constrained, Optimize and Compromise:

Let’s talk a little bit about scopes:

The definition of what can be done is critical.

Think about it, the first thing we have to understand in a project is what are the boundaries of this project? What is the size? Where does it end?

This is the scope, I will give you an example.

Let’s say that the project objective is to put water in a glass.

Pretty simple right? Well it depends.

• Where is the water?
• Is it kilometers away?
• How much water?
• What is the size of the glass?
• Is there a specific way of pouring the water into the glass?

All of those small questions can severely change the scope and maybe even make the project fail

The ones who will execute:

This is your team, the people that will be hands on, performing the work. But how to choose your team? Here are a couple of useful tips to take into consideration.

• Motivation: What are their motivation and will they match with the rest of the team?
• Skills: What can they do, what tools do they bring?
• Availability: Are they available?

Organization and Stakeholders:

Last but not least, what are stakeholders?
Stakeholders are everyone how is involved and impacted by the project.
It can be the client, third party services, even directors.

Here is some quick questions you should ask yourself to understand the stakeholders of the project:

• Who will be doing the work?
• Who is the project manager?
• Who is paying for the project?
• Who will consume the product or service?
• Who are those affected by this project?

As a project manager you will need to treat stakeholders differently depending in there involvement of the project or how they are impacted by it and even their level of interest.
To help with that we have a tool that indicates how to deal with every type of stakeholder depending on their interest or power level.

Documentation and tools:

By now you understand that a project manager deals with a lot of information on a daily basis, tasks, budget, timelines and much more.
How can we keep everything intact and keep eyes on in every single progress?
Thats where we use tools and documentation, here are some tools to help you document and arrange your project:

• Jira | Issue & Project Tracking Software | Atlassian
• monday.com | A new way of working
• Capture, organize, and tackle your to-dos from anywhere | Trello
• Microsoft Excel Spreadsheet Software | Microsoft 365
• Manage your team's work, projects, & tasks online * Asana * Asana
• Project Management Software | Microsoft Project

Each one of this tools has it purpose and even different purposes, it is good to check each one of those and learn at least the basic. It will help you understand and have more practical knowledge of what the project consists.

Quite the important step: Planning

Planning was the whole plan all along?

Planning helps us to understand the project scope, to set the intentions of the project. Have ideas of how the execution will be done, who is involved and ponder what the outcomes of such actions are.
Plans generally include tasks, milestones, people, time and documentation.

Understanding what needs to be done:

Work Breakdown Structure is a tool that is used for understanding visually the scope of the project.

It works in a hierarchy of:

1. Project

1.1 Subprojects

1.1.1 Work Packages

1.1.1.1 Activities / Tasks

Work Breakdown Structure is a very effective tool to understand first your milestones and every task that has to be done to conclude each milestone.
Let’s have an example of a construction project below:

The best advice is to take the time to breakdown the important milestones and then talk to your team and figure out together task by task.

Keeping real with your timeline

After doing the task breakdown we need to understand something very important: How much time will it take?
And the answer is generally tricky, how can we be really certain of the time of a task? Well that’s the thing generally we can’t
What we can do is have a estimation of time and try to understand that this can change with the ongoing of the project.
You should always count with your team to create those estimations and remember sometimes it takes time to get better estimation aligned with the capacity of the team.

What about the critical path?

What is the critical path? The critical path is all the tasks and deliverables that are involved directly with the success of the project.
Lets imagine we are creating a ice cream truck, tasks associated with the critical path can be:

• Buying ice cream
• Checking the best truck for an ice cream truck
• Getting customers

Tasks off the critical path are:

• Adding sandwiches to the products
• Creating different flavours of ice cream
• Buying extra wheels

Time to think about the budget

Almost all of us already have done a budget to some extent, if it was to buy furniture or to buy food for the month, maybe even when buying liquor for a party, the simple way is a budget is the necessary monetary resources planned for an objective. In the case of the project that can depend in many variables, you will generally tie your budget with your milestones and schedule, specially because the schedule have all the tasks associated with the completion of your project.
Is important to note that the type of budget will be highly associated with the company your in, each company have their best financial practices.

Taking a step further: Improving the plan

Finally we have a plan!

We created the scope, developed a timeline and made a budget, everything should be okay now or at least it should be?
Well not yet, we have ourselves a plan but now its time to improve and understand that not always what is in this plan will happen.
That will be our first topic, let’s talk about risks!

What to do when the whole plan can fail? Risk Management.

So in summary this is risk management, thinking about when our plan go wrong and the concept of how can we prepare for that.
Risks are potential problems that might happen to your project in the future, when dealing with risks we have 5 phases:
Identifying, Analyzing, Evaluating, Dealing and Controlling and Monitoring

• Identifying a risk is just understanding what risk exists in your project
• Analyzing a risk is to assess the probability and potential impact of this risk in your project
• Evaluating is to gather all data of previous steps and prioritizing the risks
• Dealing is to come with a plan for every risk, your plan sometimes might just be to accept the risk and move on
• Monitoring is to keep tabs in the risks and mitigate them if necessary

Can we see those risks coming?

When thinking about risks we have to understand that there are risks that are easy to see it coming, but there those who we would never predict, here are three types of risks:

1. Foreseeable Risks: Variability, Alternative Paths
Risks that we know will happen, and we can plan and understand those while planning the project

2. Complexities: Project Tasks, Stakeholders
Risks that we can’t plan because of the complexity, we know its there but we can’t plan the mitigations

3. Unforeseen Uncertainties: Novel Technology, Novel Markets
Risks that are unforeseeable, we don’t know they will happen

Communication is key!

Another way of improving our plan is thinking ahead in communication, this is one of the most important roles of the project manager, making sure everyone is on the right track with the same information.
If communication fails the whole project can fail, how can we make sure we have good communication?

• Have a communication plan
• Understand that people are different and need different ways of communication
• Be clear when transmitting a message, be sure what you are saying is what you really want people to understand
• Get feedback constantly and improve based on it

Always have documentation!

Along the whole project you will have a lot interactions, receive information, create different material with different subjects, all of that needs to be documented in a clear way.
It is very important also that this documentation can be centralized and be available to whom ever needs it.
Documentation is very important for the current team to be able to have the information, but also for retrospective, to look back and learn from old projects. Documentation can also be requested by stakeholders, so is always good to have it available.
Having a good documentation is having a solid base for the project, something that you can always rely upon.

Time to just do it: Execution

What we as project managers do now?

Okay, we spend a long time crafting a plan, thinking about risks, stakeholders, documents, budget and a million more details, what do we do now? Do we just let the team follow the plan and lay ourselves back?
Actually execution might just be the hardest part, you will have to deal with situations, new risks and basically the unending changes that a project behold. Let’s get started with some fundamental concepts of the execution part of the project.

Not according to the plan: Change Management

How to deal with changes? It might be changing the functions of employees during a project to dealing with the client trying to get used to the new software that you delivered. So many changes in such a small amount of time. That is change management, dealing with all of this and succeeding in this adaptation, here are some core values of change management:

Getting better all the time: Continuous Improvement

One of the key concepts is continuous improvement this is basically the skill of improving the process as we go along with it.
Thinking of new ways to improve the project is a responsibility of the project manager, imagine this situation:

• A team is having to make some heavy data spreadsheets, they take 45 minutes to manually input the data.
• After checking the possibilities you identify that this is creating a delay in the project
• You create and test some automated spreadsheets that automatically input the data
• After a week of testing the time is reduced from 45 to 5 minutes
• Talking to the team and after seeing a great improvement you decided to use the automated spreadsheet as the new official tool

Congratulation you witnessed a PDCA, a methodology used for continuous improvement. Its a great tool and very simple to use, here are some details of how it work:

We have a lot of other great tool as DMAIC, 5 Why’s and a lot more other tools and techniques to improve, as more you know it is better to adapt to different projects with different needs.

Work Methodologies

While working in a go horse mode might be fun, there are ways more efficient to divide, organize and work with a good methodology.
Work methodologies will generally define what you do on a daily basis, what type of meetings you will have and even how you will measure the work done by the team, not to mention it will give you a mindset of how the project should be paced.

The most popular we have is scrum, that took the market by storm but there are others such as Agile, Kanban, Lean, Six Sigma and many others.

Knowing and mastering this working methodologies is crucial for being able to overview and monitor the project progress.

• The very first one: Waterfall
  Why don’t we go from one activity to another just like a waterfall, simply follow each step by step sequentially top to bottom and everything will be done…
  someday.
  That was the idea behind the waterfall, a simple and direct way to go about work methodology.
• The popular kid on the block: Agile
  So let’s suppose the project doesn’t go according to the plan, we need adaptation, quick changes and iterations mainly done in small pieces this is where Agile comes in.
• That one the everyone uses: Scrum
  Scrum is very popular and used in a lot of different projects, it comes from the same principle of Agile, actually even being a part of an Agile methodology but has a very unique approach and structure.

Always together: Teamwork

No matter what project you will always have a team, the team is a very important part of the project, but to understand a team and teamwork we have first to understand that everyone in the team is a individual with different motivations.
The first step to create a good team environment is to get to know each individual and what motivates them, after approaching each individual goals you can start creating a sense of objective to the team itself.
Here are some key actions the will help you create a better team work:

• Good communication and listening skills
• Having a comfortable environment
• Guiding the team to a clear objective
• Demonstrating empathy
• Motivating the team
• Celebrating successes

All of those are different methods to help you build a good team with and amazing teamwork and with this having a more efficient project.

All good things must have an end: Closing the Project

Closing a project is a fundamental part of a successful project, but even if it looks equal closing a project is not the same of finishing a project.
How so you may ask? Closing a project is completing the whole process and ensuring the final result is satisfactory for the final client.
In rule we will use three marks that must be achieved for closing a project:

• All work must be completed
• Agreed project management processes are executed
• Formal recognition of stakeholders that the project is completed

A good tip for closing the project is to check all the official documentation of the project and if it’s requirements and promises were fulfilled.

Reaching the end: Conclusion

What happens now?

There are many places you can go to further your understanding of project management, also many techniques and methodologies we did not approach. The journey is long but rewarding at the end, here is a list of courses and certifications that are useful:

• Google Project Management (PT)
• Fundamentals of Project Planning and Management
• IBM IT Project Manager
• Certified ScrumMaster (CSM) Course | Scrum Alliance
• Certified Scrum Product Owner (CSPO) Course | Scrum Alliance

You can also check https://www.pmi.org and get the certification that translates the most for your amount of experience.

Thanks everyone that got so far, every piece of feedback is appreciated in this journey and i hope for everyone a great evolution and a lot of project to manage!

A Practical Guide to Project Management was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.

Great news — we’ve finally made it open-source. Feel free to check the final results here (spoiler alert)!

Since we already have a 70%-ready grading system that’s been tested, it makes total sense to proceed with an implementation for all competencies.

Be especially careful at that stage. The most dangerous thing here is “It’s not ideal, let’s start again from scratch”.

The tasks here are the following:

• Implement standard rules, wording, and structure,
• Replace both 0/1 and 0–100% marks with something new,
• Properly separate the middle level into 3 different grades,
• Get rid of unnecessary things if needed,
• Agree with other departments (such as HR),
• Go live for the whole company (700+ engineers).

Gather a team

The hardest part of this step is to be on the same page with other competencies. As there are 5+ people involved, finding one final solution becomes crucial. And here, the facilitator’s role comes into play. It could be a role, but it’s better to invite another person who will be in charge of facilitation only. Other things that will help:

• Consensus decision. If there’s no strong “no”, then it’s considered as “yes”.
• Offline work matters. It allows saving time for discussions significantly.
• Contribution over opinion. Review suggestions from the system’s contribution, not as a battle of personal points of view.
• Cut with no regrets. Deleting can be more useful than adding.
• Treat it like a project. Conduct regular meetings, create a roadmap, etc.

So, we assembled a team of 5 competency leaders and 1 facilitator, and scheduled regular meetings. Now, let’s actually start solving issues and get closer to the release.

Create evaluation scale

Classic evaluation models like 0/1 or 0–100% are exceptionally tricky when it comes to some kind of knowledge or soft-skills. How can you assess that this person knows JavaScript or certain parts of it (1), or has entirely no clue about it (0) by the 0/1 approach? Alternatively, when you are trying to measure the same thing with a 0–100% scale, it’s also hard because there are too many shades of gray, and different people will come to totally different conclusions. You can learn more about different scales and how they affect the precision of a judgment in the book Noise: A Flaw in Human Judgment by Daniel Kahneman, I highly recommend reading it.

So, what would be the alternative solution? We’ve decided to use a T-shirt evaluation model. First of all, it’s widely used in the IT world, for example, during planning poker sessions. T-shirts give you different levels of evaluation (XS-S-M-L-XL) with a limited choice. We treat T-shirts as the following statements:

• XS — very little/very rarely,
• S — little/rarely,
• M — average,
• L — much/often,
• XL — very much/very often.

Also, there is a Not Applicable (N/A) mark, which means non-applicable or 0 (never).

Besides the evaluation scale changes, we applied a couple more tweaks. Here’s what we did:

• Deleted the upgrade approve row. Now, it remains the same for different grades: a Team Lead has the ultimate responsibility, without additional bureaucracy layers.
• Eliminated the E8 level. People of these levels are very rare. Sometimes it’s better to have a more personalized approach in such cases.
• Added examples to every row. The main issue with the system is that it should be synchronized across a lot of people with very different backgrounds. So, we added an example column to implement this approach from the beginning and see the evaluation with more details.
• Identified thresholds for reaching a certain level. To prevent this system from being a World of Warcraft game, and make the decision process more transparent and less bureaucratic, we’ve added a couple of thresholds to get a certain grade: a) Overview and regular tasks — not less than M, b) Behavior to avoid (anti-patterns in soft skills) — at least one M is considered as a blocker to get a grade, c) Tech skills — at least M.

Split the middle level

The issue with the default middle level in the companies is the following: you can be a middle almost forever but perform very different tasks with different levels of autonomy. However, the exact description of each of the 3 middle levels seemed like a tricky case. This is why it hasn’t been included in the PoC part.

What’s the easiest way to split these levels? By a) independence and b) level of task complexity. With that being said, it’s pretty easy to draw the lines: you could move from a partially dependent contributor to a person that actually helps other team members (with independence in between). All other things are auxiliary to these ones.

Assemble the system and set evaluation rules

At the end of the day, we came to the following grading system with 7 Levels from E1 (Intern) to E7 (Lead Developer). Every statement in the system is evaluated in T-shirts from XS to XL and has an example. Each of the levels has the following parts:

• Overview and regular tasks (the most important part) — “What do I usually do?”,
• Am I doing good? — “What is my progress toward the next grade?”,
• Technical skills — “Does my tech knowledge comply with this grade?”,
• Behavior to pursue — “What are my soft skills?”,
• Behavior to avoid — “What I’d better not do?”,
• Extras — “What are my English level, nice-to-have skills, and activities?”.

We created the following rules for evaluation:

• Prove your skills first to get an upgrade.
• Your hard skill set does not guarantee your level upgrade. Your impact on the project plays a more significant role.
• Different levels require different balances between skills.
• No level downgrades.
• It’s an employee’s responsibility to showcase their achievements.
• The best upgrade is the one that’s evident to everyone.
• Levels are cumulative. Each subsequent level incorporates the previous ones.

Ideally, the grading documentation should be reviewed more than once a year through recurrent one-on-ones.

Resume

The new grading system rollout brought us the following results:

• Easy and transparent process of self-assessment,
• Clear guidelines on how to get to the next level,
• The exhaustive list of tech skills for each competency,
• Unified grading system across all projects and competencies,
• A system open to external contributions;

Also, upon the creation of the grading system for engineers, we’ve assembled a similar one, but for engineering managers (team leads).

If you want to thoroughly check the final results and suggest some kind of changes — you are more than welcome to visit our opensource repository at https://github.com/devexperts/grading-system

Implementing Grading System Soup-To-Nuts. Part 2 of 2 was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I’ll shed some light on the process of creating and implementing a grading system from soup to nuts. It will help engineering managers and C-level managers understand the basic pros and cons of such systems and give them algorithms for choosing between different approaches. Also, this article will show how hard it is to implement systems of such magnitude, and which risks and obstacles one might face during this journey.

From an individual contributor’s perspective, it might be useful for a better understanding of why companies have such systems and how they are created.

The article will be separated into 2 parts: in the first one, I’ll reveal the initial stage of things, prepare a basic solution for 1 competency, and then run a test within it, to get useful insights for further implementation.

Let’s start our journey with research on the current state of things.

Section 1. Initial research

Starting point

It’s crucial to understand the context and current state of things before starting to implement any kind of system. You should know point A to reach point B (wishful state).

This example is no exception. Here is a brief initial state of things.

Devexperts is a fintech company, that operates for 20+ years. The engineering team consists of 800+ engineers from all over the world, with remote-first and hybrid work modes. There are 6 development competencies:

• Frontend: React, Typescript, GWT
• Backend: Java, C#
• Desktop: Java Swing
• Mobile: Kotlin, Swift, Flutter

The company develops its own products and takes on outsourcing projects, creating software from scratch and improving the existing ones.

Usually, developers are divided into several grades: intern/junior/middle/senior/lead developer. There were no standard evaluation forms, no criteria, and no clear path.

However, the company conducted Personal Performance Reviews each 6–12 months, creating a personal development plan based on its results.

The company attempted to implement a different grading system for at least two years, but the results were unsatisfactory because of such roadblocks as:

• Constant arguing and lack of shared vision,
• Too complex systems without proper instructions,
• Technically deep systems that lack the business side of things,
• Scope changes before release, etc.

As you can see, the reasons look pretty similar to usual software development projects’ problems. Let’s create a high-level roadmap for this project, at least for part 1.

As we understand the initial state of things, let’s start working on our goals!

Goals

When defining goals, separate them into different categories or points of view. Usually, there is more than 1 stakeholder/user group for each initiative.

Everyone wants to be praised and adequately promoted based on their achievements. Long story short, people in IT are obsessed with growth. But when it comes to a certain amount of developers in the company, it’s getting harder to provide the same context for everybody. Based on my experience, 50 engineers is a threshold, beyond which the grading system is a must-have. However, it’s always about business priorities, as time is a limited resource.

A good grading system should answer the questions and meet the expectations of all stakeholders. The engineers might want to know:

• Who is the Junior, Middle, Senior, Team Leader, and so forth?
• What should I do to reach the next level as an engineer?
• Why am I a Middle for 10 years already?
• Why do Helena and Jack from another team have higher grades?
• What goes after a senior position? Is leading a team the only way to grow?

The second point of view is business. Here are typical expectations:

• Don’t ruin the project’s work. Business should work not worse than usual with the new system.
• Create a system of adequate evaluation of performance, skills, and value for each developer.
• Establish a transparent process of evaluation.

Finally, we have team leaders, who are responsible for the performance and growth of their team:

• How can I spend less time creating a personal development plan for my teammates?
• What are the standard criteria for developer levels in the company?

Considering these 3 stakeholder groups’ questions and goals, we are ready to start. Let’s see what our colleagues from other companies did.

Solutions on the market

I consider market research before building a custom solution from scratch as a must-have pattern for almost every task. You might have a lot of useful insights, plus, there is a chance of having an out-of-the-box solution.

Basically, there are 3 approaches to grading system building:

1. Hard-skills based. Deep knowledge of a certain technology becomes crucial. The grading formula looks more or less like that:

Frontend Grade = JS + CSS + TS + React + ….

Mainly used in outstaffing/outsourcing companies, where business success is tightly connected with the ability to pass technical interviews with clients.

Seems more or less valid in case of well-written criteria and evaluation process. However, the knowledge of a certain technology doesn’t guarantee the results required from business, tech progress might be limited by a project itself, which could easily lead to a conflict of interests.

For example, one of the biggest outsourcing companies in the world — EPAM — previously had a mainly hard-skills-based system.

2. Soft-skills based. Cultural fit has a bigger meaning than engineering skill/knowledge. The grade is defined by the following criteria:

Frontend Grade = business impact + communication skills + area of impact + area of accountability + …

This approach makes sense for big product companies, where the amount of social connections is very high, therefore, the ability to communicate becomes crucial. It could be considered subjective because it’s tricky to evaluate soft skills properly. Also, the level of technical knowledge can be out of scope, which may lead to future issues (it’s engineering, after all). Perhaps, the most famous example is a Dropbox career framework. On the one hand, it’s harder to evaluate impact rather than technical knowledge, on the other, this approach is more aligned with businesses’ goals.

3. Hybrid. This approach consists of both soft- and hard-skills parts that are evaluated and calculated together. In case of the right implementation, it brings advantages of both approaches (or drawbacks in worst-case scenarios).

A good example of such an approach is a CircleCI Competency Matrix.

Let’s choose the basic approach for our system.

The best way to choose the right basic approach is to align it with company goals and needs. There is no silver bullet, as for any other kind of task.

We decided to try a hybrid approach with more soft-skills criteria. Market solutions seemed not customized enough for our needs, because they gave some grasp of the overall framework, not less, not more.

The reason we did that is pretty simple: our products and projects are very complex and require a lot of communication. Also, we do care about technical excellence, but to be fully aligned with business needs and goals, the ability to implement something is more important than bare knowledge.

Let’s finally start the creation of our new shiny grading system!

Section 2. Proof of Concept

Creating a structure

I believe that an incremental approach with several iterations is probably the only way to succeed. There is only one way to eat an elephant: a bite at a time

Having those 2 things in mind, we decided to start creating and implementing a grading system within 1 of 6 development competencies — The Frontend Department. Despite the obvious advantages of such an approach, we kept the following drawbacks in mind:

• After the first iteration, you will have to scale on other competencies. So, the proper abstraction for the scaling must be done.
• You’ll have to reach a consensus with other departments’ heads as they might have their own vision.

These 2 aspects require additional time and effort. However, I do believe that these drawbacks are bearable. I’ll reveal common approaches to it in the second part of the article.

What will be step 0? I’ve started with defining the number of grades. Given that there were some positions already, and keeping backport compatibility in mind, I’ve decided to make 8 levels:

• intern,
• junior,
• 3 levels for middle developers,
• senior,
• lead,
• principal.

We have levels, but how will they distinguish from each other?

First, define primal criteria:

• Tasks’ complexity level. The most important thing. It defines your technical skills from practical experience and proofs from real-life projects. This factor is heavily aligned with business needs.
• Independence. How often does a developer need a helping hand from other developers? What level of technical control does their code require?
• Level of influence on the team. If a person is actively mentoring, growing and onboarding other team members, this parameter should be high.
• Level of influence on other teams. It includes various kinds of knowledge sharing with developers from other projects. It can be a speech, sporadic advice, or an open-source contribution.

I considered these 4 things crucial for defining a grade. However, it’s not a full picture, so more things were added initially.

Secondary parameters to pay attention to are:

• Hard skills. They are still playing a big role in the process of growing as an engineer, no doubt. Plus, it’s always good to have some default path to gain new knowledge.
• Soft skills. Software development requires a lot of communication, so this is a key competence.
• Anti-patterns. In other words, things to avoid. No one wants arrogant senior developers or lazy juniors on the team.
• Addons. Additional nice-to-have requirements. For example, being a public speaker.

With that structure, it makes sense to start fulfilling each grade with content. Let’s check how it was done for an intern level. Currently, everything will be stored there, later on, general grading rules will be abstracted and become common for each and every level.

Let’s skip the obvious part about describing each grade and its parts. Are we ready to go?

But wait, upon completion of this simple part, we bump into the following questions:

• What will the process of grade defining look like?
• Who should evaluate a grade?
• What are the thresholds?
• Which units should be used?
• What will the results look like?

And this is not a full list of questions to answer. However, we have a fully described system without evaluation rules and final documents. Let’s create them and start our beta-testing.

Basic principles

Ground rules of assessment cover the following questions (and here is an answer for our case):

• Is a downgrade possible?

No, it’s not. There is no back power for the law, plus it makes no sense to humiliate a person by downgrading.

• Is it possible to give a grade in advance?

No, it’s not, to become someone, you should already be the one.

• How to calculate grades based on evaluations?

There is no magic checkbox, field, or formula, but rather common guidance with minimal thresholds.

• How can facts be collected and validated to evaluate performance?

A wide range of sources could and should be used to collect and validate facts on performance, for example, “360-degree feedback”, metrics from different tools, training certificates, feedback from relevant colleagues, etc

• Who will initiate an evaluation process?

Both developer and team leader should fill the same spreadsheet without knowing each other’s results, compare them, and come to a single conclusion.

• What will happen if a developer does not agree with the final outcome?

Then he/she is able to escalate an issue to a grading committee. Their solution will be final.

Let’s define an evaluation and decision-making process.

We’ve tried 2 approaches:

1. Team leader evaluates their teammate by themselves, and after that they schedule a call to make adjustments if needed. It allows a gradual introduction to the system but might miss the self-evaluation process.
2. Both the team leader and developer fill out the form separately, then they merge the results. It takes more time but gives a better understanding to everyone.

Finally, we assume that the final decision about the grade is a responsibility of a team leader.

The only missing part now is the evaluation form, let’s fill this gap. Which marks will we use for this purpose? During the first try, I decided to proceed with binary 0/1 marks for everything except main responsibilities, which were given a 0–100% evaluation.

Finally, we are fully ready to test the grading system in real life!

And here comes the tricky part about such systems:

The hardest part is not creating, but implementing the grading system and making it work.

Implementation requires a lot of communication and context-sharing, with heavily task-loaded people. However, with the right attitude and preparation, it becomes another routine task.

Beta testing

1 small but very important formula that people often forget about:

Implementing Effectiveness = Team’s engagement x Solution Quality

Where each part starts from 0 and ends with 1 (0–100%).

People care so much about the quality and tend to abandon the engagement. Don’t do that! A perfect system with 0 engagement from your team will turn into 0 very quickly.

So, the ideal scenario is to involve your team in the creation of this system sooner rather than later. Or, at least present it and ask for feedback. Also, the smaller your sandbox is, the shorter the feedback loops are.

This is my ultimate beta-testing checklist:

• Synchronize with people who will do the grading. A high-level presentation along with a thorough explanation during 1-on-1s should work.
• Have a dry run. Ask to perform a shadow-grading: evaluate someone you know pretty well. Check the results and discuss them with a team leader to find flaws in the decision-making process.
• Have the first 2–3 grading test sessions with team leaders and their developers. It might be awkward for someone, so make sure that you communicate goals properly, and set up a dry-run context.
• Check the feedback results. Proper feedback gathering is crucial. The best way to do it is to combine 2 approaches: a personal interview and an anonymous survey.

I’m sure that you will find the results interesting and surprising. So, be prepared to face the truth even if it’s not very pleasant.

The results of our beta-testing in the Frontend Department turned out to be the following:

• The overall conception works.
• No clear criteria for defining the grade were made. Team leaders were struggling to identify the proper grade.
• It’s hard to estimate something in %. The human brain works pretty well when it comes to 7+-2 marks, but there are too many shades of grey on a 0–100 scale.
• It’s hard to give a 0/1 evaluation of hard or soft skills. It’s quite the opposite to the previous point: lack of choice makes the evaluation even harder.

The results were good enough to proceed with implementation for the whole company.

Results & Part 2 Overview

As the outcome of the 1st part we have the following:

• Grading system with described levels,
• Evaluation process rules,
• Beta-tests within the Frontend Department,
• Feedback from testers: lack of criteria definitions, issues with %, and binary evaluations.

In the second part of my article, we will see how to gather a team with different competencies, why deleting might be more useful than adding, how to properly separate a middle level, and how to do a rollout on the whole engineering department.

Stay tuned!

Implementing Grading System Soup-To-Nuts. Part 1 of 2 was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this post, we’ll discuss how to use n-gram language models to detect user intent early — as they type. The actions corresponding to the top K of the most probable intents can be shown to the user. We call them intent suggestions.

The idea behind intent suggestions is similar to autofill that captures user-entered words to make predictions. But instead of predicting the next word, we try to deduce what the user really wants and serve them a list of corresponding actions.

The purpose of this feature is to save our chatbot users time and make sure they end up getting the help they need. We use a similar approach in Devexa, our smart assistant for traders.

Table of contents

1. Problem formulation
2. N-gram language models
3. Intent detection using n-gram language models

Problem formulation

Now that we understand the idea and motivation behind intent suggestions, let’s formulate a list of desired characteristics of our future solution:

1. The solution needs to be fast enough with low resource consumption. Most often it will have to make predictions multiple times for a single user query.
2. It must operate on partial phrases and even separate words.
3. It needs to reflect the statistical probability of each intent being implied. We will often have to make predictions based on phrases that don’t have enough context to derive the intent from (e.g., “I can’t” may imply multiple intents). For this reason, we want the intents most often containing an input phrase in their training data to be deemed the most probable.

The established list of characteristics, or restrictions, narrows down a set of possible solutions for us. Instead of using a neural network (which is often a go-to option), we’ll be using a simple yet powerful concept of n-gram language models.

N-gram language models

We will briefly go over the main idea and look at the training and inference processes and then move on to the proposed approach.

In general, n-gram language models calculate relative frequency counts of words that follow every (n-1)-gram found in the training data. In other words, during training it slides over texts in the data using a window of size n-1 words and remembers which words it saw going after it and how often.

These frequency counts can later be used to calculate probabilities of different words being the next word in the input sequence.

As the result of training we will have a list of all the found n-grams with their frequency counts. Or, more conveniently, a dictionary with (n-1)-grams as keys and all found nth words with their frequency counts as values.

During inference, we use the last n-1 words of the input sequence to look for the most frequent next word and return it as our prediction.

The probability of a specific word being the next word is equal to the frequency count of the corresponding word divided by the sum of frequency counts of all the words found after the given (n-1)-gram.

The beauty of n-gram models for some applications is that they don’t try to use the context of the input sequence to predict the next word. It relies solely on statistics of the training data. This is the main advantage of the model for our purpose.

Intent detection using n-gram language models

Let’s discuss the actual code now. We’ll take a look at the core pieces. The full version can be found here.

Notation. Given that we are trying to detect a user’s intent rather than the next word, we’ll use a slightly different notation. N in our case will represent the number of words used to predict intent probabilities. That is, a 3-gram (or trigram) model will use three words to make predictions.

The first step is model initialization. Notice that we also initialize a child model with n equal to n-1. Once initialized, it will create its own child model — and so forth until n equals 1.

This recursive approach allows us to take into consideration frequency counts from smaller n-grams in case there is no match for the parent model.

Recursive parameter represents the weight used with child models’ frequency counts. Smoothing parameter prevents zero-division and performs label smoothing.

The overall training process comes down to repeating the following step for every data item — label pair: we slide over the text item using a window of size n (words) and increase each n-gram’s counter of the corresponding intent. Then we run the same procedure with our child model.

That is it about training. Let’s now explore the inference essentials. Our goal is to get frequency counts from our parent and child models for the last n-gram of the input context. We start with a non-empty counter (to prevent zero-division) and update it with the parent model’s frequency counts (if any) and the weighted child model’s frequency counts.

Once we get frequency counts, we can calculate intent probabilities by dividing each intent’s counts to the sum of all intents’ counts.

The last thing to keep in mind is that you should probably pre-process your texts before both training and inference so that there are no redundant variations of the same phrase in the counters.

That’ll be it for intent suggestions. A little reminder: the full version of the code is available here. If you find it useful, consider giving it a ⭐️.

Closing thoughts

Let me know if you have any questions. You can also reach out to me via LinkedIn.

To learn more about Devexperts’ products and AI development services, visit our website.

Early intent detection using n-gram language models was originally published in Devexperts on Medium, where people are continuing the conversation by highlighting and responding to this story.