For any web-based application (and “any” platform means Angular, React, Vue, ASP.NET, Blazor or plain old JavaScript) it’s easy to style the Progress Kendo UI components using the pre-defined Progress Telerik styles (and, thanks to Progress’ use of SCSS, it’s also easy to customize those styles).

If your organization is using the Bootstrap, Material or Fluent design systems (from Bootstrap, Google and Microsoft, respectively) to style your webpages, then you’ll probably find that the Progress Telerik and Kendo UI components blend pretty seamlessly into your pages, just by picking the matching Progress themes. But, if your organization has its own style rules that don’t follow those design systems, you may have to do a bit of customizing.

The easiest solution to that is to use Progress’ visual editing and preview tool, ThemeBuilder to create a custom theme for your Kendo UI components that does match your organization’s styles (ThemeBuilder is also, by the way, a good choice for creating/managing your own stylesheets).

If you’ve already created stylesheets to style your Kendo UI components, there’s more good news: You can import those styles into ThemeBuilder and avoid having to start from scratch.

Creating Your Own Theme

To start integrating your styles with your Kendo UI controls, first surf to the ThemeBuilder site and click on the Create New Project button.

First, from the menu that appears on the left, pick one of “Start from Kendo Theme” and “Start from Scratch.” The “from Scratch” option is a good choice if you’re using ThemeBuilder to create your own stylesheet (the “starter” project even comes with some basic features, like padding and font settings, already set up for you).

If, however, your goal is to integrate with your organization’s style with your Kendo UI components, then you’re better off with picking the “from Kendo theme” choice. Once you pick that and give your project a name, you’ve got a couple of choices to make.

SVG or Font Icons

One of the benefits of using the Kendo UI components is that they come with access to the Progress icon library. If you’re already using icons, you can mix your icons with the Telerik icons but you’ll need to configure your theme based on whether you’re using SVG or font icons.

If you’re not already committed to a set of icons, you’ll need to pick between SVG and font icons as part of creating your project (this is an either/or choice for most platforms—the one exception being Blazor, where you can intermix SVG and font icons). Don’t panic! Your choice isn’t irrevocable—you can change this choice in your project’s settings later if you need to.

When making your choice, the primary distinctions between the two types of icons are:

• Accessibility: SVG icons provide better compatibility with W3G accessibility guidelines than font icons.
• Color: Font icons are single color only; SVG icons can have multiple colors.
• Download time: Font icons are lighter weight which, if you use enough icons, can reduce download time.

Progress Telerik and Kendo UI Themes

After that choice, you can pick one of the Kendo UI themes as a start point for your project’s styles (or import any existing stylesheets you’ve already created—see the section on Migrating to ThemeBuilder, below). Obviously, picking a theme that’s closer to your organization’s existing styles will reduce the number of changes you’ll have to make later.

Probably the easiest way to determine which theme to use as your start point that is try out some of the likely looking candidate themes with one of your existing Kendo UI–enabled applications. In fact, it’s probably a good idea to pick an app to use to test your custom theme as you make changes.

In both Visual Studio and Visual Studio Code, swapping between styles can be done easily using the Telerik extensions to both of those editors. For many platforms, just tweaking the URL for the CDN version of the styles will let you try out various styles on a single app. This is all that’s required to use the current version of the default Kendo UI theme in a JavaScript app, for example:

<link rel="stylesheet"
  href="https://kendo.cdn.telerik.com/themes/10.0.1/default/default-main.css" />

Tweaking Your Theme

Once you have your project created and picked a starting theme, your project will display, giving you what may, initially, seem like an intimidating set of items that you can use to create your custom theme. Down the left-hand side of the page, for example, are all the CSS rules and settings, while the middle of the page is occupied by mockups of all the Kendo UI components (and Kendo UI has a lot of components).

Managing Components

To get your options under control, you can reduce the number of components displayed to just the components that you’re currently using in the app where you’ll try out your custom theme (this assumes that you’re not using every Kendo UI component in that app). To reduce the number of components in your project, in the upper right corner of ThemeBuilder, click on the “checked list icon” to get a list of all of the components available to ThemeBuilder.

Once you have that list, uncheck the Select All checkbox in the upper left corner of the dialog, and then check just the components that you’re going to use for your sample app (finding the component you want can be daunting—use the search box on this form to find your app’s components quickly). Once you’ve picked the components you want to work with, click the Select button in the bottom right to return to ThemeBuilder with just those selected components displayed.

Fonts

If you’re using a font file in your sample app then, before you start tweaking your components’ settings, add that file to your project from the Project Settings panel (available from the cog while in the upper right corner of the ThemeBuilder page).

Once you’ve opened Project Settings panel, just select Fonts from the settings menu on the left of the panel and upload your font file (ThemeBuilder supports TTF, OTF, EOT and WOFF/WOFF2) files. The fonts in the file(s) you add will be automatically added to the list of fonts available in ThemeBuilder.

Modifying Component Styles

Your next step is to start modifying the default style you picked when creating your project. You’ll begin by modifying one of your selected components.

First, set the toggle at the top of the ThemeBuilder page to Advanced Edit and then select the component you want to change. If you want, you can just modify that component’s default style to create your custom theme. That approach does make it more difficult to return to that style, if you ever need to. If you have the Ultimate plan, after selecting a component, you can click on the three dots in the component’s upper right corner and pick Duplicate. That will create a copy of the style that you can modify, leaving the original style untouched.

Beginning in early 2024, some components support an Add Configuration option from that same menu (adding a configuration is being extended to more components as ThemeBuilder evolves). Add Configuration lets you create and style a new component configuration (Add Configuration is only available under some licenses:

Clicking on a component (duplicated or original) or a configuration will open an editing page for modifying a component’s style settings. The main part of the page shows the component in all of its states. Down the right-hand side, a Component Parts panel holds all the style settings that apply to this component. You can change the settings in Component Settings (usually by picking from a list) and see the result immediately in the main window.

Many settings let you select from several predefined Kendo UI settings. Having said that, if the default setting isn’t right for you, it’s unlikely any of the other’s will be, either. In addition, picking a different predefined style in the Component Parts panel on the right will affect only the currently selected component’s appearance.

However, since the Progress team has used the style rules and metrics in Styles list on the left of screen consistently across their suite of components, it probably makes more sense to change the settings for the default rule already selected in the Component Styles list. Changes made in the Styles list on the left will propagate the change to every other component in your project that uses that style.

Regardless of where you make a change, you’ll notice the impact of change immediately in the main window of the live edit page. If you changed the style in the Styles list on the left, when you return to the list of all the components in your project, you’ll see the impact of changing that style on all of the components.

And of course, as you add more Kendo UI components to the inventory of components you’re managing in this project, at least some (and perhaps all) of the settings on those components will pick up the changes you’ve made to the predefined styles. Furthermore, when you use your customized stylesheet in another app, your changes will affect all the Kendo UI components in that app, not just the components referenced in your project.

Presumably (and eventually), you’ll find that your custom theme covers enough styles that adding a new component to an app doesn’t require any additional changes to your custom theme.

Migrating Existing Kendo UI Styles

To include any existing styles you’ve created outside of ThemeBuilder to style your Kendo UI components, first click on the settings cog in the upper-right corner of the ThemeBuilder window. That will open the Project Settings panel; in that panel’s left-hand menu, select External Styles. You can then click the Upload External Styles on the right to browse to your organization’s CSS files and upload them.

There are a few limitations with uploading an external stylesheet. You can’t, for example, upload a CSS file that uses URLs (as you might to load an image).

Once you’ve uploaded a style, you can assign it a new name (might be necessary if you have multiple stylesheets with the same name) and then click the checkmark to the right of the file name to add the stylesheet to your theme.

Deploying Your Style

Once you’ve finished with your changes, deploying your changes is easy: Click the Export All button in the upper-right corner of ThemeBuilder to generate a ZIP file with the CSS and SCSS files for your theme. You can now add those to your web app.

Set your expectations appropriately! Recognize that it’s good that deploying your custom theme is relatively easy because, odds are, you won’t get a match you’re completely happy with on your first pass. But, with ThemeBuilder, you do have all the tools you need to get your Kendo UI components to blend seamlessly with the rest of your page (or as seamlessly as you want, at any rate).

Try Progress ThemeBuilder

Poke around in ThemeBuilder with the free trial. Or explore the Telerik DevCraft bundle for a more inclusive package.

Design systems are so hot right now—but hey, I don’t have to tell you that: you already have one! It took some serious time, effort, and cross-team collaboration, but now you can put your feet up, sit back and reap the benefits … right?

Much of the content around design systems is (rightfully) focused on getting a design system started: getting buy-in, building components, organizing Figma files, etc. What there’s less of is information on “what’s next”—life after the design system kickoff.

In fact, some devs and designers even worry that the creation of a design system will actually make their jobs worse by taking away the kind of work they currently do. While there’s a very small grain of truth in that, I firmly believe that design systems only remove the repetitive and tedious work from your workload, freeing you up to do the more interesting, engaging work. Let’s take a look at what that work could look like.

Design System Upgrades and Maintenance

OK, we are admittedly starting out with the most boring one here by far, but we have to get it out of the way. Design systems are not one-and-done; they should evolve with your team and the work you’re doing. While there is quite a bit that can stay static (hopefully your brand colors aren’t changing every year), things like components, patterns and documentation (to name a few) should be updated regularly. As your application or website grows and expands, you’ll have new things to add to the design system.

Thankfully, this is significantly less work than creating the design system; it won’t take nearly the same time or effort to maintain as it did to get off the ground. I’ve found that the best approach here is to build in some time for a tune-up each cycle, whatever a “cycle” looks like for you. Maybe that means once a quarter, once every other sprint, once after each release—pick whatever makes the most sense for your team and will fit most naturally into your regular flow. Ideally, this shouldn’t take more than a day or so; if things are changing more rapidly than that, you might need to take a step back and look at how the design system is (or isn’t) being used.

Obviously, the specific work will depend on what’s included in your design system, but here’s a general checklist to give an idea of what “maintenance” might look like:

• Were any new patterns established? Add them to the library.
• Were any new components created or new features added to existing components? Add them to the library and document.
• Did you use an existing component in a new way? Update the documentation.
• Did brand content (colors, fonts, logos, etc.) change? Update the library.
• Did you get any feedback about the design system (either internal feedback about design system usage or external user feedback about the design)? Now’s the time to address it.
• Is the design system being used? If not, speak to folks about what could be improved.
• Are the technical elements of the design system (Figma files, third-party libraries, etc.) using the latest version? If not, time for updates.

User Research & Testing

Having that extra time back means that now we get the opportunity to re-prioritize some of the important work that often gets cut because it’s not a shippable feature—and one of the most common things on the chopping block is (unfortunately) user research and testing.

Talking to users is time-consuming, but highly rewarding. With a little extra wiggle room in your schedule, you can start thinking about things like user surveys, one-on-one interviews, focus groups and observation sessions. There are a wide variety of ways in which you can learn more about your users’ goals, processes, workflows and opinions—which one you pick will depend on what you’re trying to learn and what you plan to do with the data. For example, surveys are great for high-level data comparison and analytics, while interviews can help you dive deep into a specific use case or pattern. Hey, maybe you can even put together some personas.

While user research is focused on getting to know the user, themselves, usability testing is great for getting to know your own product a little better. Sounds backward, right? After all, who would know a product more than the people who built it? In fact, you might be surprised what you can learn about your application by observing and talking with the people who use it. Whether you’re testing new or experienced users, there’s a ton to uncover by doing some good old fashioned usability testing. Consider testing areas where you know there are pain points so that you can invest some time in cleaning them up—or new features, even while they’re still in the earlier design stages.

Architecture & User Flow

Legacy software often develops a life of its own, in many ways. As goals and user requirements change, new features are added on wherever they fit in the existing structure while old features get de-prioritized and left to rust. The flows, patterns, menus and architectural choices that made sense when the app was new may not be the right fit for the product in its current state.

Every now and again, it’s important to take a step back and look at the application as a whole—but that’s often work that’s set aside in favor of shipping the next hot new thing. With the time you have now, it might be a good idea to look at the overall architecture of your app and think about whether the structure right now makes the most sense for what your users are trying to achieve with it. Not sure what the users are trying to achieve? Good news—that’s where all that user research and testing will help fill in any knowledge gaps.

Accessibility

Of course, in an ideal world, accessibility would be a natural and fully integrated part of the design and development process. I’m a huge advocate for accessibility first—making sure that accessibility is considered as part of the minimum viable product.

However, for a variety of reasons, that’s not always what happens. Maybe, despite your best efforts, you were overruled and something had to be launched without the level of accessibility testing you would have liked. Maybe your team is doing a great job with accessibility in new features, but haven’t looked at some of the older stuff. Maybe you’ve just never had the time to do a full accessibility audit. Maybe a feature was in compliance when it was built, but standards or laws have changed since then. Maybe you’ve achieved WCAG A-level compliance but would really like to kick it up to AAA.

Whatever the reasons may be, if you have parts of your product that you know are lagging a little in the accessibility category, those are great places to focus your attention. We already know that design systems can offer significant help in implementing accessibility: when the building blocks are all accessible, it’s a lot easier to create a finished product that’s also accessible. However, “easier” doesn’t mean “automatic”; even if every individual piece is accessible on its own, it’s still very possible to use those pieces to create something that’s not accessible as a whole.

Accessibility isn’t a trend and it’s certainly not going away—this is a great place to invest that extra time and effort to level up the user experience of your app for all your users.

Innovation

This is the big one: the main goal of most teams creating a design system. They want to free up all that time and refocus it on new ideas—brainstorming, building new things. After all, this is what got most of us into the game in the first place, right? At least speaking for myself, this was the addicting part; the feeling of connecting the dots, solving problems and creating something from nothing. It’s the part that scratches the itch, makes the long days and weird client feedback all feel worth it. Unfortunately, it’s also often the first thing to go when you’re slogged down with the day-to-day work of maintaining a website or application.

Design systems give us the freedom back to think big. Not only is there time saved on that regular maintenance work, but also time saved on implementing future features, pages and ideas. Design systems make work faster, which lowers the stakes on trying something a little different. If it’s not right the first time (and let’s be honest, when is it), iteration is faster. And if it’s just not working at all, the investment of time and effort was lower and having it be “wasted” stings less. Of course, I’d argue that if you learned something, the effort wasn’t wasted … but that’s another article, entirely.

Time to Get to Work!

Design systems are valuable not in and of themselves but as a means to an end: freeing up time for work that’s more interesting and (hopefully) more valuable—both to us and to the end user. While some may argue that design systems reduce creativity, I actually say it’s just the opposite: they enable creativity by reducing the risk level and time investment of trying something new.

Whether “new” for you looks like adding fresh components to your component library, scheduling some user feedback sessions, re-working the application nav structure, increasing your WCAG compliance level or brainstorming a big new feature—it’s all important work that can now come to the forefront because you don’t have spend time building that 6th login widget. I don’t know about you, but that sounds like seriously good news to me.

If there’s one thing we can feel pretty safe assuming about React developers, it’s that they prefer to do things their own way. After all, one of the main perks of the React approach is the fact that it’s a library, not a framework—the less prescriptive, batteries-NOT-included approach allows devs to pick and choose their tech stack as they wish.

The nice thing about Progress KendoReact is that it can meet you were you are, regardless of your personal preference. If you like to keep things light and run with Vite, KendoReact can do that. But if you prefer to use a full React framework, we do that too! And now, that extends to styling as well.

Some prefer the grab-and-go approach of a CSS library like Tailwind or Uno, while others like to write their CSS by hand … OK, maybe that’s just me. Whichever one you prefer, the new KendoReact Unstyled mode allows you to leverage all the power and functionality of the KendoReact components you know and love—without having to work with (or around) our default CSS classes.

What Is Unstyled Mode?

KendoReact Unstyled mode removes the default KendoReact CSS classes from the components. That allows you to:

• Apply your own custom styles using whatever naming convention you prefer for your CSS classes
• Avoid conflicting styles or having to overwrite KendoReact defaults (no more !importants)
• Reduce your bundle size by only including the exact styles you need

You can even use a mix of our pre-made Themes and Unstyled components, if there are only a few that you want to style differently. It’s super adaptable, incredibly flexible and—of course—easy to implement. Let’s take a look.

How to Use Unstyled Mode

To use components in Unstyled mode, all you have to do is wrap the component in the UnstyledContext provider and pass the predefined CSS classes object in as a value.

<UnstyledContext.Provider value={customStyles}>
    <Button>Learn More</Button>
</UnstyledContext.Provider>

That makes it a piece of cake to combine KendoReact with your favorite third-party CSS library. In fact, there’s a great sample app our dev team created to show off just how simple it is to integrate Tailwind. Check it out or fork it as the basis for your own project!

Why Use Unstyled Mode?

We’ve already talked about the perks of being able to leverage a third-party CSS library, but why else might you reach for Unstyled mode?

• You’ve already invested time and energy into creating a design system. Now, you don’t have to “translate” values and names between your own system and the KendoReact system—no more naming conflicts, or remembering that you call it “main” while we call it “primary.” Get everyone speaking the same language and unified between code and design.
• There’s that one pesky component that you’re having trouble overwriting the default styles on. Sometimes, there’s some little tiny thing that you just want to adjust, but it’s baked into the default theme. And sure, you can write some nasty CSS to get at it ... or, you could just toggle off the default classes for that component and save yourself the trouble.
• Bundle size and performance is a top priority. Look, the hard truth is that it takes a lot of CSS to style 100+ professional, beautiful, accessible, responsive components—that means that our themes can be kinda chunky. If you’re in a situation where bundle size is a big deal, it can be helpful to not import the default theme.

What KendoReact Components Support Unstyled Mode?

Right now, the following components can be used with Unstyled mode:

• Animations
• Button
• ButtonGroup
• DropDownButton
• SVG Icons
• DateInput
• DateTimePicker
• TimePicker
• Form
• Input
• TextBox
• MaskedTextBox
• RadioButton
• RadioGroup
• Label
• FloatingLabel
• Hint
• Error
• Popup

We’ll keep adding to this list, so keep an eye on our docs for all the latest info. And if you have a component that you’d like us to prioritize, let us know via the KendoReact Feedback Portal!

The “State of Designer-Developer Collaboration Survey 2024” results are in! This global survey ran between July and September this year and aims to shed light on the way designers and developers work together in the context of web development, and the role design systems have in this collaboration.

You can find the data at the Designer-Developer Collaboration Survey Report 2024 page. For a deep-dive into all the insights and fascinating cross-sections, you can download the free report analysis. It surfaces everything we learned about the relationship between designers and developers, including ideas for making it more efficient and satisfying—all beautifully presented and laid out for your reading pleasure.

The survey represents professionals working in both design and development roles, plus other stakeholders in the designer-developer handoff. The respondents come from 50 countries, work in 20 major industry categories and are employed in businesses ranging from one-person shops to small- and medium-sized companies and enterprises with 5,000+ employees.

You will find a lot of information that paints a current picture of how designer-developer collaboration is set up. For example, we learned that the most prevalent team model involves two to five developers and one designer; however, one in four developers we surveyed doesn’t have a designer assigned to their current project.

When it comes to hiring outside help, most companies seem reluctant—72% count exclusively on their internal specialists to get the job done. Still, 22% assign a mixed bag of internal and external specialists to their web projects.

We learned 46% of all teams collaborate daily or at least a few times a week. On average, each professional uses 2.3 different communication channels. However, 4% of collaborating designers and developers never communicate directly; rather, they use a mediator. A further 7% collaborate very rarely—just once a month or less!

Unfortunately, there’s a high price to pay for overcorrecting and not having meetings at all. Turns out at least 65% of respondents experience challenges with their design-to-development process. Visit the designer-developer collaboration report to see what the most common challenges are and how the frequency of communication correlates with the quality of designer-developer collaboration.

In the downloadable report, you’ll discover the most interesting cross-sections we explored. We were surprised to find out that, while working for internal vs. external stakeholders did not correlate with the relationship quality between design and development, the number of projects per year did. Teams working on 10+ projects are mostly fine, teams working on a single project are also fine and those working on 2-10 projects are least likely to have a positive relationship.

Perhaps people working on 10+ projects are forced to establish a structure and processes that enable them to be at their most efficient so as not to drown in deadlines? If you have real-life experience that helps shed light on this dynamic, please share it in the comments below!

Some good news from the design systems section: the top three benefits listed by web development teams who have a design system match the top three goals people who don’t yet have a finished design system set: better user experience, improved consistency and faster design to dev time. A rare situation in which expectations match reality, isn’t it?

Enough with the spoilers, friends! It’s clear that the crossroads of design and development is a bustling, beautiful and, yes, sometimes a bit of a bumpy place. It’s definitely worth exploring for anyone seeking to become a better, happier professional. Check out the report and clear away the fog.

In the digital landscape, consistency is not just a principle for user interface design but can also be a fundamental requirement in coding practices. Coding style guides represent an essential framework within software development, particularly for frontend developers engaged with design systems. These guides offer a standardized approach to writing code, so a team or organization can maintain uniformity, readability and scalability in its codebase.

In this article, we explore the significance of coding style guides, some popular methodologies and how they contribute to a cohesive development environment.

What Are Coding Style Guides?

Coding style guides are comprehensive sets of rules and conventions that dictate how code should be written and organized. They serve as a blueprint for developers, enabling them to write code that not only functions efficiently but is also easy to read and maintain. This consistency is especially crucial in large teams where multiple developers collaborate on the same project, as it prevents discrepancies that can lead to errors or complicated merges in version control systems.

Coding style guides can cover various aspects of coding, including but not limited to:

• Naming conventions: Establishing rules for naming variables, functions, classes and other code elements, promoting clarity and consistency.
• Code formatting: Defining standards for indentation, whitespace usage, line breaks and other formatting rules to enhance readability.
• Code organization: Providing guidelines for structuring code files, directories and modules, improving maintainability and scalability.
• Commenting practices: Establishing conventions for writing clear and concise code comments, facilitating collaboration and knowledge sharing.
• Language-specific conventions: Addressing language-specific coding practices, such as bracket styles, variable declarations and control flow structures.

Why Are Coding Style Guides Important?

For design engineers, coding style guides are more than just rules; they can be a pivotal tool for translating design systems into functional code. A well-defined style guide helps keep the implementation of design tokens and systems consistent across various parts of an application, which is crucial for maintaining the integrity of the design throughout the development process.

In addition to streamlining collaboration among team members, a coding style guide lets all developers follow the same design principles, which is crucial when implementing UI components.

Consistency in code leads to consistency in user interfaces, making the application more intuitive and user-friendly. When every part of an application adheres to the same design guidelines, it creates a more seamless experience for users, reducing the learning curve and increasing user satisfaction.

Popular Coding Style Guides

While coding style guides can be tailored to the specific needs of an organization, there are several popular methodologies that have gained widespread adoption in the software development community. To illustrate how coding style guides can be applied and used, we’ll discuss a few below:

BEM

As an example, one popular coding style guide that many use when structuring CSS classes is the BEM methodology. BEM stands for Block, Element, Modifier and it’s a naming convention that helps developers create modular and reusable CSS classes.

Consider a scenario where CSS classes are named spontaneously without a clear system:

/* CSS without clear structure */
.card {}
.featured {}
.title {}
.description {}
.link {}

In the above simple example, the class names are generic and could easily overlap in style properties across different sections of a website. This can lead to styles being accidentally overridden and makes the CSS difficult to maintain, especially in larger projects.

Now, let’s contrast this with BEM methodology. Using BEM, class names are structured like the following:

.block {}
.block__element {}
.block--modifier {}

The block is the main component or container, the element is a part of the block and the modifier is a variation of the block or element. Each of these serves a clear purpose and reduces the risk of style conflicts.

Contrasting with the poorly structured example, BEM offers a clear and systematic way to name CSS classes, which helps in avoiding conflicts and enhances modularity:

/* BEM structure for the card component */
.card {}
.card__title {}
.card__description {}
.card__link {}
.card--featured {}

Here, each class has a specific purpose:

• Block: .card acts as the foundational class for the card component.
• Element: .card__title, .card__description and .card__link are elements that belong to the .card block, indicating their specific roles within the card component.
• Modifier: .card--featured is a modifier that represents a different version of the .card, specifically styling it as a featured card.

To show how these BEM classes are applied in HTML, consider the following example:

<div class="card card--featured">
  <h2 class="card__title">Featured Product</h2>
  <p class="card__description">
    Lorem ipsum dolor sit amet, consectetur adipiscing elit.
  </p>
  <a href="#" class="card__link">Learn More</a>
</div>

This structure clearly separates the styling concerns, making the CSS easier to manage and extend.

For more details on BEM, be sure to check out the official BEM documentation.

Google HTML/CSS Style Guide

Coding style guides encompass more than just CSS organization; as mentioned earlier, they can also cover aspects like naming conventions, indentation, formatting, and commenting. For example, Google’s HTML/CSS Style Guide provides comprehensive guidelines on formatting and style rules for HTML and CSS. It covers best practices for accessibility, like having alternative content always be provided for multimedia:

<!-- Not recommended -->
<img src="spreadsheet.png" />

<!-- Recommended -->
<img src="spreadsheet.png" alt="Spreadsheet screenshot." />

Using valid HTML:

<!-- Not recommended -->
<title>Test</title>
<article>
  This is only a test.

  <!-- Recommended -->
  <!DOCTYPE html>
  <meta charset="utf-8" />
  <title>Test</title>
  <article>This is only a test.</article>
</article>

And writing semantic HTML where possible:

<!-- Not recommended -->
<div onclick="goToRecommendations();">All recommendations</div>

<!-- Recommended -->
<a href="recommendations/">All recommendations</a>

For a more detailed list of guidelines, be sure to check out the Google HTML/CSS Style Guide documentation.

Airbnb JavaScript Style Guide

The Airbnb JavaScript Style Guide is another widely recognized coding standard that emphasizes clarity, predictability and organization in JavaScript coding practices. It advocates for modern JavaScript syntax and idiomatic expressions, promoting best practices that lead to clean and understandable code.

This style guide is particularly meticulous about variable and function naming, the use of arrow functions and structuring components in React applications. For example, it prefers constants over let and var for variables that do not change and provides certain guidelines when using components and props in React.

Here’s how the Airbnb JavaScript Style Guide would suggest structuring this piece of JavaScript code:

// Bad
function handleThing() {
  return true;
}

// Good
const handleThing = () => true;

In React, as an example, the guide encourages the use of PascalCase for React component names and camelCase for instances of these components:

// bad
import reservationCard from "./ReservationCard";

// good
import ReservationCard from "./ReservationCard";

// bad
const ReservationItem = <ReservationCard />;

// good
const reservationItem = <ReservationCard />;

For a list of coding style guides for different programming languages, check out the GitHub repository awesome-guidelines by GitHub user Kristories.

Tailwind

When developing your own design system, your team can either create these guidelines from the ground up or adopt widely recognized frameworks and conventions from the broader development community.

One such popular framework is Tailwind, a utility-first CSS framework that has become a favorite in the development scene. Unlike traditional approaches like BEM, which focus on structured naming conventions, Tailwind provides a set of utility classes that can be applied directly to HTML elements to style them efficiently.

<div class="p-3 bg-white shadow rounded-lg">
  <h3 class="text-xs border-b">font-mono</h3>
  <p class="font-mono">The quick brown fox jumps over the lazy dog.</p>
</div>

Tailwind’s design philosophy aims to offer a flexible and customizable method for designing interfaces. Its utility-first approach reduces the amount of CSS developers need to write, fostering a more consistent and scalable design. Each class in Tailwind specifies a particular style or a set of CSS properties, for example:

• p-3 denotes padding: 0.75rem
• bg-white denotes background-color: white
• rounded-lg denotes border-radius: 0.25rem
• And so forth

Wrap-up

In conclusion, coding style guides are essential tools in the realm of software development, especially for design engineers who bridge visual design and technical implementation. These guides provide a structured approach to coding that enhances collaboration, promotes consistency and elevates the quality of the final product.

Whether adopting established standards like Google’s HTML/CSS guidelines, BEM for CSS structuring or the Airbnb JavaScript Style Guide, or creating customized guidelines tailored to the specific needs of a project, the benefits are significant. For design engineers looking to enhance their team’s efficiency and output quality, integrating a comprehensive coding style guide can be important in achieving these goals.

We’ve always been interested in developer feedback, but this year, we’ve been trying a little something new at conferences with the Progress booth—we’ve been talking to developers about their experience with the design-to-dev handoff.

With a jumbo pack of sticky notes, a whiteboard and a dream, our goal was to capture three different aspects of the design to development workflow: what tools people were using, what they liked about their process and what they wished was different.

The response was incredible! Hundreds of developers shared their opinions and experiences with us. We commiserated over common pain points, celebrated wins and brainstormed what an ideal dev/design workflow could look like.

As you might imagine, developers and designers directly working together was an often-recurring topic across these thousands of sticky notes—it’s almost impossible to talk about the handoff without talking about cross-team collaboration. So let’s take a look at the main things developers wish designers knew when it comes to building websites and applications.

1. Developers Want to Be Involved in the Design Process

The developers we spoke with expressed a strong desire to be included in all phases of the project creation process. There were a great many responses related to cross-team collaboration and developer involvement—even (and especially) in work that isn’t traditionally considered development work.

Developers are eager to participate earlier in the process and work together during the planning and design phases. They want to be able to help catch potential issues early and provide deep technical knowledge that can help shape the product or feature set long before any code is written.

That might look like being included in scope definition calls, UX brainstorming, or other product planning meetings. In a wide variety of ways and across all different points in the process, devs want to be (as they said in the sticky notes) “involved,” “included” and “collaborating.”

If you’re a developer looking to get more involved in the design process, check out our free ebook Foundations of Design for Developers.

2. Developers Want to Share ‘the Same Language’ with Designers

That first wish for developers to be more involved did come with a request: that the people they collaborate with also invest the time to understand technical requirements and “speak the same language.”

Many responses mentioned the value of non-developers who understood the basics of the development process, as well as the challenges of designs and feature requests that were created without understanding the underlying technical requirements. For those developers already lucky enough to be working with designers, there were several mentions of wishing that those designers understood the development and implementation process more deeply—especially relating to the availability and limitations of components in a component library (when one is being used).

3. Developers Want to Reduce Mid-project Changes as Much as Possible

Lots of teams struggle to define project requirements accurately. There were tons of responses related to the need for clearly defined requirements at the beginning of the project (this included both sticky notes that mentioned liking clearly defined requirements and disliking poorly defined requirements).

But it’s not just the kickoff phase of the project that’s challenging. It won’t surprise anyone to hear that scope creep came up quite a bit in the “dislike” category. In fact, several responses specifically mention the difficulties of scope/requirements changing mid-project. Whether those changes come from the product team, the design team, the client or the developers themselves, they inevitably cause significant slowdown and frustration for everyone involved.

4. Developers Value Designers and Want to Have More Designers on Their Teams

Many developers are working on under-resourced teams and (rather than focusing on software or other tooling) are wishing primarily for more designers—or any designers at all! Several sticky notes specifically mentioned hoping for some kind of design specialist to be hired (those wished-for roles included UI designers, as well as UX designers and researchers).

What Does This All Mean?

In our opinion, that involvement and cooperation between the teams is what’s really going to move the needle, more than any hot new library or fancy new process. The end product can truly shine when there’s a shared space for designers and developers to create together. That also means that both parties have put in the work to learn and respect the other’s expertise, process and workflow.

Building a culture of respect and shared responsibility won’t happen overnight—especially if the design and development departments at a company have historically been isolated. It takes a lot to change the status quo from throwing a design file over a metaphorical wall and hoping for the best, to true synchronicity and collaboration at all stages of the process.

How Can I Be Involved?

One of the best ways we can start to shift that is by learning more and gaining a more thorough understanding of what all parties are looking for. By identifying those communication gaps, knowledge gaps and expectation gaps, we can begin to bridge them together.

Want to help with that process and learn more about the current state of the industry? Share your experience and take the State of Designer-Developer Collaboration 2024 Survey we just launched. It’s a global survey that aims to shed light on the design handoff process, and the role design systems play in addressing the inherent challenges—and we need your input!

Take the Survey

In the world of user interface (UI) development, consistency is king. Users often expect a product to feel cohesive and familiar, no matter which part they interact with. This is where design systems come in—collections of reusable components, guidelines and assets that help you provide a unified user experience across an entire product or product suite.

Design tokens are fundamental building blocks to design systems that offer a unified and consistent user experience across different parts of a product. In this article, we’ll delve into what design tokens are, why they are crucial and how they can be effectively implemented to uphold consistency throughout a product.

What Are Design Tokens?

Design tokens are essentially the smallest parts of a design system. They are named entities that store specific visual design attributes (like colors, typography, spacing and more) within a design system. These tokens act as a bridge between design and development, providing a single source of truth for these attributes. This means that instead of hard-coding values directly into our code, we reference design tokens, which can be updated centrally.

For example, a design system might define a set of color tokens:

// Colors
$kendo-color-primary: #ff6358;
$kendo-color-secondary: #666666;
$kendo-color-tertiary: #03a9f4;
$kendo-color-info: #0058e9;
$kendo-color-success: #37b400;
$kendo-color-warning: #ffc000;

In addition to colors, design tokens can also define other aspects of design, such as font sizes, font families, line heights, spacing and more.

// Font sizes
$kendo-font-size: 0.875rem;
$kendo-font-size-xxs: 0.5rem;
$kendo-font-size-xs: 0.625rem;
$kendo-font-size-sm: 0.75rem;
$kendo-font-size-md: $kendo-font-size;
$kendo-font-size-lg: 1rem;
$kendo-font-size-xl: 1.25rem;

In the above examples, we’re defining our design tokens as Sass variables assuming the Sass preprocessor is being used in the project. We could also use CSS custom properties, which offer similar benefits for maintainability and scalability within modern web projects.

/* CSS Variables */
:root {
  --kendo-color-primary: #ff6358;
  --kendo-color-secondary: #666666;
  --kendo-color-tertiary: #03a9f4;
  --kendo-color-info: #0058e9;
  --kendo-color-success: #37b400;
  --kendo-color-warning: #ffc000;

  --kendo-font-size: 0.875rem;
  --kendo-font-size-xxs: 0.5rem;
  --kendo-font-size-xs: 0.625rem;
  --kendo-font-size-sm: 0.75rem;
  --kendo-font-size-md: 0.875rem;
  --kendo-font-size-lg: 1rem;
  --kendo-font-size-xl: 1.25rem;
}

When it comes to using these tokens in a project, developers have different methods for referencing them in their code. One of the most common ways to access these design tokens in CSS is by using the var() function to retrieve custom properties. This method is especially beneficial for maintaining a consistent design across a large-scale application and makes it easier to make global changes.

For instance, in a CSS file, we can apply design tokens to elements like this:

.button {
  background-color: var(--kendo-color-primary);
  padding: var(--kendo-font-size-sm) var(--kendo-font-size-md);
  font-size: var(--kendo-font-size);
}

.header {
  color: var(--kendo-color-info);
  font-size: var(--kendo-font-size-lg);
}

Here, the var() function is used to insert the value of a custom properties where they’re referenced. This allows us to easily switch themes or adjust styles by simply changing the values of these tokens at the root level.

Different Types of Design Tokens

Design tokens can be expansive, encompassing a variety of types that cater to different aspects of a design system. The Progress Design System showcases a helpful structure of design tokens ranging from global values to very specific ones tailored for particular components.

Global Design Tokens

Global design tokens are foundational values that form the cornerstone of a design system. They represent tokens that are:

• Context-agnostic, meaning they don’t pertain to a specific component or context.
• Generic, allowing them to be reused across various parts of the design.

For instance, a color palette might include tokens like $purple-100, $purple-200, $purple-300, etc., establishing a scalable and reusable color system. Though these tokens can be used directly, they’re often used as building blocks and are referenced by other design tokens.

Alias Design Tokens

Alias design tokens are a step more specific than global tokens. They are named in a way that suggests their intended use, helping to apply consistent styling across different UI elements while maintaining clear and meaningful connections to their function within the design system.

For example, $kendo-color-info might be specifically used for informational messages or alerts, signaling its purpose through its name.

Component-Specific Design Tokens

Component-specific design tokens take specificity even further. These tokens are directly tied to particular components within the design system, defining properties such as colors, borders and typography specific to that component.

For instance, the $kendo-button-border might define the border style for all buttons within a system. This level of detail helps each component to behave and appear as expected, no matter where it is used within the application.

Application-Specific Design Tokens

Application-specific design tokens are crafted to address the particular needs of individual projects or a series of related projects. They provide the flexibility needed to adapt the overarching design system to specific functional requirements, aesthetic preferences or brand guidelines. They often encompass several types of properties:

• Color design tokens: These are used to establish a color identity specific to an application, adjusting for various UI elements like backgrounds, text and borders for visual coherence and brand alignment.
• Typography design tokens: These tokens manage typographic details tailored to specific applications, balancing readability with style, including defining sizes, weights and spacing for text across different UI components.
• Space design tokens: While many design tools don’t yet support space tokens directly in their UI editors, they are crucial for defining the spacing rhythm within an application. These tokens help maintain consistent margins and paddings that align with the spatial and structural design principles.
• Effect design tokens: Used for adding depth and dynamics through visual effects like shadows, blurs and overlays, these tokens help enhance the aesthetic appeal and user focus on specific elements within the application.

Good Practices for Implementing Design Tokens

Implementing design tokens in certain ways can be helpful for maximizing their benefits and ensuring the consistency and scalability of a design system. Drawing from the guidelines provided by the Progress Design System, here are some practical do’s and don’ts to follow when working with design tokens.

Use Global Design Tokens Cautiously

Global design tokens serve as the foundation of a design language. They are versatile and can be applied across different parts of your project without being tied to specific UI components.

Do:

• Utilize global design tokens as foundational elements within your design system. They are ideal for establishing basic colors, typography and spacing that are common across multiple components.
• Consider the broad applicability of these tokens when integrating them into your designs. They should enhance consistency without restricting flexibility.

Don’t:

• Overuse global tokens for specific applications where component-specific tokens are more appropriate. Relying too heavily on global tokens can lead to a lack of specialization in your designs, which might not meet the nuanced needs of individual components.

Choose the Right Component-Specific Tokens

Component-specific design tokens are tailored for specific elements within the UI, such as buttons, input fields or navigation bars. They help give components a consistent appearance and behavior across different parts of your application.

Do:

• Use component-specific tokens to define properties that are unique to particular components. This could include button border thickness, hover state colors or specific typography for headings within a component.
• Select tokens based on their intended use, as their names often provide clear indications of their application.

Don’t:

• Substitute component-specific tokens with global tokens if the specific tokens provide a better fit. Misapplying tokens can lead to inconsistencies and unexpected behaviors in the UI.
• Use tokens intended for one component in another unless they are explicitly designed to be cross-component. This helps maintain the integrity and purpose of each design decision.

Strategically Implement Application-Specific Design Tokens

Application-specific design tokens are designed to meet the unique stylistic requirements of a particular project or suite of projects. These tokens allow for the customization of designs to align with specific branding guidelines and functional requirements.

Do:

• Create and utilize application-specific tokens to address unique design challenges and requirements of your project. These might include specific color schemes for branding purposes, custom typography settings or unique spacing that aligns with the overall layout of the application.
• Make sure that these tokens are clearly documented and understood by both the design and development teams. This clarity will facilitate easier updates and modifications as project requirements evolve.

Don’t:

• Ignore the broader design system guidelines when creating application-specific tokens. While it’s important to customize, it should not come at the expense of overarching design consistency and usability standards.

Wrap-up

In conclusion, design tokens are not just tools for maintaining visual consistency—they are strategic assets in a design system that enhance collaboration across teams, align detailed design elements with broader brand narratives and adapt gracefully to the ever-changing requirements of modern digital projects. As such, proper implementation and management of design tokens are essential for any organization that values design quality and coherence across its product suite.

For more details, explore the helpful guidelines provided by the Progress Design System and their documentation on Design Tokens.

A brand’s style guide is a useful tool for defining the visual language of its digital products. A design system—which includes a style guide—is an essential resource for a brand that wants to bring stability, consistency and scalability to its omnichannel customer experience and visual strategy.

If you’re here, then you’re probably about to create a style guide or design system and looking for inspiration. While you could copy what all the big tech players like Google, Apple and Microsoft are doing, you might be surprised what you find elsewhere on the web.

10 Lesser-Known Design Systems and Style Guides for Inspiration

There are many brands and organizations out there that have created brand style guides and design systems. So if you’re wanting inspiration on what to include in your design system or how to design it, start with this list. These examples might not be as well known, but they’re all really cool examples to check out.

1. b Restaurants Style Guide

The PDF style guide for b Restaurants is a great example of omnichannel branding. The style guide includes all the visual language information you’d expect to see, like:

• Brand overview
• Logo design and usage
• Colors
• Typography
• Photography
• Textures
• Design elements

In addition, the guide is split into two. In the first part you’ll find the visual guidelines for print (which makes sense since this is a style guide for a restaurant). In the second part you’ll find the guidelines for the web. There are also a bunch of examples at the bottom that show you the style guidelines in use—on the menu, business cards, the website, Facebook ads, etc.

If you need to bridge the gap between different channels—not just physical vs. digital, but across all your digital channels as well—this style guide is a good model to follow. It’s well-organized, simply written and easy to follow.

2. Duolingo Style Guide

Duolingo’s online style guide is broken up into five sections:

• Identity
• Writing
• Illustration
• Marketing
• Resources

Identity contains all of the information you’d commonly see in a style guide about colors, typography, logos, etc. The rest of the style guide is pretty unique when compared to the others you’ll see here.

For starters, it includes its Writing style guide along with the visual guidelines. What’s more, the Illustration section isn’t so much about the style of graphics used in the language learning app. It’s about how the designers create every illustration using three basic shapes for the sake of rhythm, simplicity and scalability.

If you have a unique visual style and you want to ensure that new designers are able to pick up on it right away, incorporating that type of information in your style guide would be beneficial. It’s also a good way to highlight how innovative your brand is.

3. GitLab Design System

Pajamas is the name of the design system for GitLab. GitLab is an open-source software project that has more than 3,000 community contributors. Because of this, a well-documented and well-maintained design system is critical.

This design system is beautifully designed and easy to navigate. It includes a section at the top for the style guide foundations—the logo along with the basic UI guidelines. Down below is where you’ll find the robust design system, which includes information and guidelines for:

• Foundations
• Components
• Patterns
• Objects
• Data visualization
• Content
• Usability and interaction
• Accessibility

This is a good example of why design systems aren’t just for big tech companies or large digital agencies. Any time you have numerous contributors or partners working on your digital products, a design system is needed to keep everything and everyone straight.

4. The Guardian Style Guide

The Guardian’s style guide isn’t set up the way most online style guides are. For starters, there’s a hamburger menu in the top-left corner that allows users to navigate to the different sections:
Introduction

• Grids & spacing
• Brand use
• Typography
• Colour palette
• Graphic elements

Even then, you won’t be able to discover what’s in each section until you scroll through them.

However, I think that’s intentional. The Guardian isn’t a single-column business site with a more-or-less expected or traditional format. As such, anyone trying to understand the structure and design choices of the site should consider them one by one, which the scrolling format of the style guide allows for.

This style guide is also a good example of how to take your digital product’s unique brand and apply it to your style guide. That way, the style guide feels like the living embodiment of the brand.

5. Gusto Design System

Workbench is Gusto’s design system. It’s minimally designed, fast to load and easy to navigate.

What’s noteworthy about this design system is that it doesn’t just stick with the typical parts of a design system. You know, the accordions and alerts, and form fields. There’s nothing wrong with including these common components and patterns. However, if your digital product contains other parts, they should be documented in your design system.

Workbench, for instance, documents things like:

• Elevation
• Responsive breakpoints
• Panel
• Popover
• Skeleton
• Toast

It also has a robust Resources section at the bottom. So rather than only provide links to UI kits or templates, users will find all sorts of guidelines related to browser support, responsive best practices, special symbols and more.

6. Help Scout Style Guide

Help Scout’s style guide is an interesting example. It starts with a whimsically designed and animated landing page that introduces users to the brand’s values and the driving principles behind its UI design. This is a crucial part of every style guide and the design of it gives users the space to really focus on it.

Once you’re inside the style guide, you’ll see that it’s pretty standard. It includes sections for the following:

• Logos
• Color
• Typography
• Illustration
• Graphic elements

There’s also a content style guide below the visual one. And below that is a section called Product Design. This section introduces users to Help Scout’s design system. Although we aren’t able to access the live, interactive design system, we catch glimpses of it and get to see how it helps the company achieve its goals.

7. Precor Style Guide

Precor is a commercial fitness equipment company that has created this simple, straightforward style guide for its brand. It’s a single landing page that contains the typical information and presentation of visual guidelines for the logo, colors, typography, imagery and more.

A style guide like this isn’t just beneficial for the company or its designers though. Commercial retailers have lots of partners to think about. And if they’re all going to be using their logo, imagery and other branded elements within digital and physical marketing campaigns, then a style guide is the best way to ensure they use the right assets and make the right design choices.

While I didn’t include the whole page in the GIF below, the page includes lots of design examples for internal reference. It also includes logo partner lockups examples at the very bottom so that fitness facilities and even hotels know how to properly integrate the Precor logo within their own.

8. Special Olympics Brand Guidelines

The Special Olympics brand guidelines page is a great one to look at if you’re wondering how to keep a huge brand with a global reach well-organized and documented. The main page breaks down the guidelines by languages, events, programs and more.

The one you see down below is the PDF of the English Brand Guidelines. This is a massive 92-page document that spends a good deal of time covering the brand’s history, mission, reputation, guiding idea, as well as how this story needs to be told visually.

While the style guide is indeed long, it’s well-organized, so users won’t have a hard time finding what it is they’re looking for. It’s not just the organization of the style guide that makes it easy to use. The table of contents at the front clues users in to what to expect. So they can skip ahead to relevant visual guide sections, examples and tips on brand management as needed.

9. Starbucks Style Guide

I’m sure that Starbucks has an impressive design system that the company uses behind the scenes. Otherwise, the company wouldn’t be as well known for its consistently executed omnichannel marketing strategy in stores across the world as well as on its website and mobile app.

That said, this simplified style guide for the Starbucks brand is one that everyone should take a look at. At first glance, it appears to be your typical visual style guide with sections dedicated to:

• Logos
• Color
• Voice
• Typography
• Illustration
• Photography

Users will soon notice that the style guide is interactive. Not only can you play with some elements, but hover-triggered tooltips appear for each of the visual guidelines. So rather than clutter the UI with this information, it appears when users focus on the relevant elements.

What’s more, users can toggle between different design choices, like under the Logos section where they can change the color of whichever one they’re looking at. The Color section then explains when and where each color should be applied. It’s a really well-thought-out design reference.

10. United States Web Design System

It’s not just corporations and software companies that benefit from having a design system. National and local governments need them as well. The U.S. web design system, for instance, is meant to be a resource for designers and developers who build government websites and other digital products.

Unlike creative and commercial brands, a governmental design system isn’t going to be the most creative or attractive one to look at. That doesn’t make it a bad example to look at though. It includes everything a good design system needs:

• Design principles
• Components
• Patterns
• Design tokens
• Utilities
• Templates

I’d argue that, if this is your first time creating a web design system, this is the one to start with. Think of this example as a minimum viable product of a design system. You’ll get to see the simplest, most straightforward way of documenting a brand’s visual identity without all the fluff. Once you nail that down, you can add whatever pizzazz you want.

Wrapping up

Style guides and design systems are essential parts of the modern design and development process. They serve as a single source of truth for product and marketing teams, allowing them to create consistent and scalable UI designs for anything they build.

Now that you’ve seen some cool examples, now it’s time to implement your own design system or style guide.

One way to do this is to build it from scratch, using an inspiring design system or style guide as a reference. Another option is to use the Progress Design System Kit. It’s based on Progress’s own design system, which you can see here:

With the Design System kit, you won’t have to spend time building out the foundation of your design system or style guide. Instead, leverage the UI component libraries, professionally designed themes and ThemeBuilder to customize as much or as little to your liking. Plus, you can edit it on a global or granular level.

Hey there, Telerik and Kendo UI developers! We’re starting 2024 with a splash of color and innovation. Our team is excited to introduce a brand-new color system for Progress Telerik and Kendo UI Themes, which is not just an update—it’s a complete game-changer!

The Big Reveal: A New Color System Is Here!

With Q1 2024, we’re rolling out a new Sass setting called $kendo-enable-color-system for our dynamic new color system. You have the freedom to switch to this system whenever you feel ready. Fast-forward to May 2024, and this new system will become the default.

But don’t worry if you’re still fond of the old system—it’s just a setting away. We’re all about making transitions smooth and stress-free. That’s why both color systems will be available until Q2 2025, giving you more than a year to adapt at your own pace.

Why You’ll Love the New Color System

Unified Customization Across Themes

Welcome to a world where color customization becomes effortlessly unified! With our new color system for Default, Material, Bootstrap and Fluent themes, you can now manage your color schemes from a single, central location. This approach eliminates the need to juggle tens or hundreds of variables. Instead, you get a streamlined, unified control system for all color modifications.

This significant simplification means you can apply changes across various themes quickly and consistently, for a seamless design experience. Say hello to efficiency and goodbye to confusion!

Dynamic CSS Variables Over Sass

Sass variables, meet CSS variables! With support for both Sass and CSS variables, now you can tweak your themes on the server or on the fly. Imagine effortlessly switching between light and dark modes—that’s the kind of flexibility we’re talking about.

Seamless Integration with Design Systems

Embrace the synergy of design and functionality! Our new color system for Telerik and Kendo UI Themes—encompassing Default, Material, Bootstrap and Fluent—is a boon for everyone using design systems. This unified approach to color customization aligns perfectly with design system methodologies, making it easier than ever to maintain visual consistency across your applications.

By centralizing color management, we’re simplifying the customization process and enhancing the cohesion between design elements and development practices. That is more than a feature—it’s a step toward a more integrated, design-centric development ecosystem. What team couldn’t use a more streamlined design workflow?

Your Toolbox for the Transition

• Dive into our detailed documentation here.
• Our migration guide makes switching a walk in the park. It will be available for the Q2 release when the new system becomes the default.
• ThemeBuilder Ultimate user? You get an automatic transition. How cool is that?

Wrapping Up

We’re not just changing colors but transforming how you work with Telerik and Kendo UI themes. Our goal is to get you excited about these changes, not overwhelmed. So, embrace this colorful journey with us and watch your projects shine brighter than ever!

Creating modern and visually cohesive user interfaces that look and behave consistently across various platforms and devices is a challenging task. This problem can be tackled by introducing a design system that can be used as a blueprint for how interfaces should work.

In this article, we will explore the importance of a good design system and its core components. Furthermore, we will cover how to build a design system with the powerful Progress ThemeBuilder.

What is a Design System and Why Do We Need One?

A design system is a detailed collection of guidelines, principles, patterns and assets. Developers, designers, product managers and other stakeholders can use it to create interfaces that are consistent visually and provide coherent behavior for all products and services across various platforms and devices.

It can have a significant impact on how users perceive products and the brand. What’s more, it can play an essential role in differentiating from competitors and establishing a recognizable identity for the brand and its offerings. A good design system can help users recognize the brand behind products and reinforce positive memories and experiences.

Besides consistency and recognizable UI and UX, a design system improves efficiency since it’s easier to avoid reinventing the wheel. The existing components can be used in new projects, so there is no need to spend time figuring out how things should look and work in a project.

Moreover, having a centralized design system helps with maintenance and reduces the risk of inconsistent UIs. In addition, it can aid the onboarding process of new team members since it can be referred to as documentation for the company’s design and development standards.

What are the Components of a Design System?

A design system can consist of several components depending on how thorough and complex it is. However, here are a few core components that design systems can comprise:

Style Guide

The style guide covers branding elements, such as typography, color palettes, spacing, grid layouts and more.

Component Library

A component library comprise the building blocks of a design system. It should contain reusable components, such as buttons, form fields, layouts or dialogs. These components should be built based on the design system’s style guide and design principles.

UI Patterns

UI patterns specify the solutions to common design challenges. For instance, what approach should be used to build and handle a navigation menu on mobile devices? Should an application use a top or bottom navigation bar or should the navigation links be hidden in a drawer instead? If a drawer, then how should the drawer be opened? A very common solution for this problem is the use of the “hamburger menu,” which comprises a button with multiple lines that look like a stacked hamburger. UI Patterns ensure that interfaces use a consistent approach to the same problems.

Design Principles

Design principles provide the basic ideas behind design choices. The principles ensure the design system has a consistent design style throughout. These might comprise focus on light, depth or size.

Documentation

Documentation is the instruction manual on how to understand and use the design system. The documentation should cover how different parts of the design system should be used individually or combined to create richer experiences. These could comprise implementation details and code examples.

Design Tools

Desgin tools are a collection of tools that is used to create and maintain the design system. For instance, a company might use an application such as Figma, Adobe XD or Sketch for creating designs and StoryBook or Zeplin to maintain the design system in an interactive manner.

In a nutshell, a design system covers visual look and functional behavior. It speeds up product iteration, makes the design and development process faster and ensures everything works in the same manner on different platforms and devices. In the next sections, we will have a look at how to take advantage of Kendo UI to build a design system.

What is Kendo UI?

Kendo UI is a comprehensive bundle of UI components built by the Progress team for four major JavaScript UI libraries—React, Angular, Vue and jQuery.

Each version provides many feature-rich components with consistent API, visual styles and behavior. The components offered by Kendo UI can cover the needs of many applications, and they span various features, such as buttons, icons, grids, layouts, charts, form fields, dropdowns and much more.

The fact that Kendo UI supports multiple UI libraries means even teams that use micro-frontends and utilize different solutions can still develop user interfaces that match visually and behaviorally.

Kendo UI offers five beautifully crafted UI themes:

• Default Theme
• Bootstrap Theme
• Material Theme
• Fluent Theme
• Classic Theme

You can pick one and immediately start coding. Kendo UI even provides Figma UI Kits for each of the themes, which you can use to create your own styles and designs in Figma using the provided style primitives.

The default themes are excellent, but if you need more customized styles, Kendo UI has the ThemeBuilder to meet your needs.

ThemeBuilder—Creating a Design System with Kendo UI

ThemeBuilder is a powerful Telerik and Kendo UI tool that can be used to create styles for UI components. To use it, we need to create a new project and choose the base theme we want to work with.

After creating a new project, we are redirected to the ThemeBuilder dashboard. We are immediately greeted by a helpful tour guide that can walk us through various features of the ThemeBuilder.

The main content showcases a live preview of all UI components present in the theme.

On the left side of the dashboard, we have a sidebar with theme styles, such as typography, color palettes and effects. In the theme selection process, I picked the Fluent Theme, so all components utilize the default Fluent styles.

Whenever any of the styles are changed, the ThemeBuilder refreshes the UI and renders all components with the latest styles. The GIF below shows how all components change colors when the primary style is modified.

Detailed Styling Customization

The main content, by default, shows the live preview, but we can also switch to the “Advanced Edit” mode, which will allow us to click on any of the components to get access to detailed styling customization for each component part and state.

The Advanced Edit Component View consists of three main parts:

• The component states preview in the middle, which shows how a component looks like in a default state, when it’s hovered, focused and more
• The live preview section at the bottom, which renders an interactive component that can be interacted with
• The sidebar that can be used to configure the component’s text, background, spacing and more

ThemeBuilder Plans & Pricing

A lot of the features in the ThemeBuilder are free, but some of them require a paid plan subscription. For instance, the “Detailed Styling Customization” we just covered in the previous section requires the ThemeBuilder Pro plan. The ThemeBuilder also offers a very useful feature that allows importing styles and fonts from Figma. You might have spotted the “Import Styles from Figma” notification at the top of the left sidebar.

The Progress team built a Figma plugin that can be used to automate theme generation by exporting styles and fonts from Figma. The exported assets can then be easily imported into the ThemeBuilder and used to style components. This feature requires the ThemeBuilder Ultimate plan. Besides the free tier, there are three plans in total—Pro, Ultimate and Enterprise. You can find a detailed pricing plan comparison here.

Exporting a Theme in ThemeBuilder

When your theme is ready, you can click on the big blue Export button at the top right of the application. It will download a zipped file with the following structure.

.
├── theme/
│   ├── dist/
│   │   ├── css/
│   │   │   └── theme.css
│   │   └── scss/
│   │       ├── _overrides.scss
│   │       ├── _tokens.scss
│   │       └── index.scss
│   └── package.json
└── README.md

The README.md file describes how the theme should be added to a project. In the dist directory, we have css and scss folders. If you’re using Sass in your project, then you should import the dist/scss/index.scss file. Otherwise, you should import the theme.css file.

Note that since those files are generated, they should not be modified directly. Instead, they should be treated as read-only files. Any further modifications should be done in the ThemeBuilder, and the theme should be exported again.

Summary

In this article, we have covered the importance and building blocks of design systems, including style guides, component libraries, UI patterns, design principles, documentation and design tools. Further, we delved into Kendo UI and its unique features, such as themes, Figma UI Kits and Progress ThemeBuilder.

ThemeBuilder, equipped with advanced customization options and a live preview, enables us to create themes that perfectly align with our requirements. Moreover, we covered practical aspects, including the pricing structure of ThemeBuilder plans and how to export a theme to integrate it in a project. Equipped with the new tools, we can enhance our design workflows and create more cohesive and efficient user experiences.

You might already know about all the amazing customization options the Progress ThemeBuilder offers in terms of colors, padding, effects like border radius and drop shadow, and more. But did you know that you can also import your own fonts and icons as well, for a truly personalized look?

If your brand style guide specifies the use of a licensed font or if your design team has invested in the creation of custom icons, you can still seamlessly integrate those assets into the theming of your component library—and export production-ready code!

Custom Fonts

ThemeBuilder already includes access to a collection of standard, familiar fonts to use in your typography system. To change the default font used across the entire component library, just update the $kendo-default-typography variable in the “Typographies” subsection of the Theme Styles sidebar.

However, if you’ve fallen in love with a beautiful Google font or invested in a specific licensed font family, you can absolutely use those as well! To import a font, just take the following steps:

1. Click the gear icon in the top navigation bar to open Project Settings.
2. Open the Fonts tab from the Project Settings sidebar.
3. Click the Upload Font button to add any font files from our system.
4. Customize font details, such as type, weight and style. The “Font Type” detail is required, but the others are optional.
5. Click the checkmark icon to add the new font to the theme font options!

Once it’s been moved from Pending Fonts to Uploaded Fonts, we know it’s ready to use in our design. Now, when we update the default font (or any other typography option), we’ll see our custom font in the Font Family dropdown options list.

Custom Icons

We can also make use of the Upload Font process to add custom icon sets as well! Just export your custom icon set as an icon font or download the icon font for your preferred library.

For example, let’s say we want to use popular icon library Font Awesome in our project. I’ll download the free OTF files from the Font Awesome downloads page, then open up ThemeBuilder and follow the same process as above—just make sure the set the Font Type as “Icon.”

Then, to change out an icon, click on a component and open the Advanced Edit panel. In this example, I’ll change out the icons in the Slider component. Then, take the following steps:

1. Select the icon from the Component Parts pane in the top right corner of the Advanced Edit sidebar.

   

   
   

2. Open the Text subsection. Click the typography icon on the right-hand side to switch to “Set Local Text Properties” if you haven’t assigned the new font as a variable in Theme Styles.

   

   
   

3. Choose your uploaded font from the Font Families dropdown.

4. Click the gear icon in the bottom right of the Text panel to open the icon selection menu.

   

   
   

5. Choose a new icon from the icon selection panel.

   

   
   

6. Make any necessary text size or spacing adjustments.

And just like that, you can apply your own custom icon set to change the look and feel of your components in ThemeBuilder. Here’s a before and after, showing the default Slider icons and the updated ones using the Font Awesome library.

As you can see, it only takes a couple minutes to get custom fonts and icons loaded into the ThemeBuilder and ready to use in your project! Try it yourself with our free 7-day trial, and check out our docs for more ways the ThemeBuilder can make styling your component library fast and easy!

There are so many reasons why creative agencies and studios should take a collaborative approach to design and development. Collaboration within and across teams allows you to:

• Reduce redundancies, miscommunications and errors
• Build higher quality products
• Get those products into the market quickly
• More effectively scale your business

The key to successful collaboration is to remove the internal friction that slows things down—in particular between design and development. In this post, we’re going to look at five things your agency can do to empower each person to play to their strengths while simultaneously working faster and more effectively together.

5 Tips for Improving Design Collaboration and Handoff

Everyone on your team is working toward the same goal—building great products for your end users. To make your product development process go more smoothly, here are some ways to reshape your systems, tools and overall process.

1. Develop a Collaborative Process

If we were to simplify the product development process that some agencies use, it might look something like this:

The first part of the project is all about design. Developing the UI and hashing out the interactivity of the product. The design team then hands off their work to engineers who turn the great-looking concept into a working usable product.

Here’s the problem:

This is like bringing in a relief pitcher or backup quarterback who’s been hanging out in the locker room throughout the game. Sure, they’d have the skills and talent to participate, but they’d have no idea what happened along the way, what the pace of the game has been, what the competition has been playing like, etc.

It’s hard to jump in at that point and to participate at your level best—in any arena.

While it’s true that developers don’t need to play a major role in the early stages of a job, they shouldn’t be silently waiting on the sidelines or behind the scenes. They should be involved at key stages where their input would be beneficial. For instance:

• During the onboarding call (with the client as well as internally)
• While developing the information architecture, wireframes and mockups
• After receiving feedback and any major change requests from the client

The same goes for designers. Just because they hand off their work to the development team doesn’t mean they should completely wipe their hands of a job.

The ideal product development process should look something like this where the design and development teams work in tandem:

It’s all about bringing other teams into the process when they’re needed most. A seamless handoff is also key to the execution of this process.

So whether you’re creating a new project process or looking to optimize an existing one, go for the collaborative design and development approach. Your team members will find that things go much more smoothly along the way if they’re not waiting to be called in to address errors, emergencies and the like.

2. Use a Project Management Platform

It’s not enough to create a collaborative process. Find a project management platform that your whole team (as well as clients) can use to:

• Define the project’s goals.
• Store all project-related documentation and guidelines.
• Divide the project up into smaller stages and individual steps.
• Lay out each task.
• Set deadlines.
• Assign tasks to specific team members.
• Manage collaboration and handoffs.
• Provide visibility into the project’s progress.
• Schedule meetings.
• Allow for real-time communication.

Project management systems ensure that everyone on your team has real-time access to the status of any given project and their associated responsibilities. So even if the job goes off the rails at some point, team members will receive updates and can prepare accordingly.

Accountability is an important part of collaboration. And a project management system equips everyone with all the information they need to get a job done and the tools to work with others to achieve their goals, as well as empowers them to take responsibility for their portion of the job.

3. Make High-Quality Communication a Priority

Notice that I didn’t say “make communication a priority.” That’s because communication without a purpose ends up being a waste of everyone’s time.

If your goal is to improve design collaboration, then you need a plan and tools to help you implement a system of high-quality communication.

The project management app will be useful in this regard as it’ll give your teams a place to discuss the project within the actual context of it. Not all of the communication between design and development can take place in a chat-like format though. Having a structured plan for meetings and real-time collaboration is important too.

As you lay down your product development process, collaborative team meetings should be included. For instance, certain occasions and milestones should call for design and engineering to come together:

• Client onboarding call
• Internal kickoff meeting
• Milestone check-ins (like after the completion of the user research phase)
• Design-development handoff
• Client offboarding call
• Project post mortem

Also, if the scope of the project changes at any point, everyone should be brought together to review the change request. The same thing goes for any negative feedback or issues that bring a halt to the job’s progress. Even if developers aren’t working at these earlier stages, it’s best to keep them informed.

Just be careful about how many meetings you schedule and who you invite to them. Both teams should come away from each meeting feeling like they got something out of it, that they remain clear on what needs to be done and that everyone is in sync.

4. Create and Maintain a Design System

One of the biggest hurdles to collaboration is language. Specifically, the language of design vs. the language of coding.

Going back to the sports metaphor once more, imagine that a baseball pitcher is sending signals to the catcher. However, the catcher has no idea what any of the signals mean. They might eventually catch on when they see how the pitcher is winding up, but it might be too late then.

That said, no one is saying that a developer needs to learn everything there is to know to be an adept UI designer. Or vice versa. However, there needs to be something that bridges the divide so that, when the two come together, they completely understand each other.

The design system is the perfect solution.

Take the Progress Design System, for example. It is a digital resource that details the following:

• Foundational styles for color, typography and iconography
• Design themes
• CSS utilities
• UI components and guidelines
• Resource repository that includes UI kits, icon sets, additional themes and more

One reason why a design system is so beneficial is that it spells everything out. There can be no confusion about which color to use, which button style to apply or which theme to start from.

From the designer’s point-of-view, the design system gives them less to worry about in terms of building the product from the ground up. Instead, they can focus on the more creative aspects of designing an app as well as creating the perfect user experience.

From the developer’s point of view, the design system ensures that the designer works with the right components and libraries. What’s more, that they have guidelines that help them consistently use and style those components. This means less clean-up and correction needed during development.

In order for this to be the outcome, your design and development team will need to collaborate in creating and maintaining the design system. If you’re looking for an easy way to create your own, check out the Design System Kit.

5. Use Tools That Simplify Handoff

In the not-so-distant past, it was up to the designer to lay out the design specs and redlines prior to handoff. This allowed the designer to translate their design work and choices into a language/format that made sense to the developer. The developer then reviewed the specifications and implemented them as they built out the app.

That whole process—the redlining, handoff and implementation—took a lot of time. And there was no guarantee that something so manual wouldn’t create additional errors during implementation.

Rather than force the design and development teams to spend all that time translating and interpreting each other’s work, it’s a better idea to use tools that simplify the handoff instead. In addition, they shouldn’t force your teams to find completely new design or development tools to work with.

For example, Progress ThemeBuilder enables designers to import their files from Figma. ThemeBuilder also allows designers to export their completed designs, components and styling as CSS or Sass files to hand off to the developer.

ThemeBuilder has other useful applications. Think of it as a living version of your design system. You’ll be able to save your theme, set global styles and customize as many components as you like from there.

In addition, let’s say that a change is needed late in the game. The developer has finished things up, the product has made it through QA with flying colors, but the client wants to tweak a color or the look of a button. There’s no need to go through the product, page by page or screen by screen, to make those updates.

With ThemeBuilder, it’s easy to update styles and values of even the most granular of components. The exported file can then be loaded into the application for automatic updating.

Wrap-up

While collaboration might seem tricky to maneuver when it comes to design and development, the key is to stop thinking of your teams as design vs. development.

If you truly want to maximize your outcomes, then design and development must work like a unified team instead of as individuals. After all, everyone is working toward the same goal—to build high-quality digital products for your end users.

As you can see above, there are simple enough ways to improve design collaboration and handoff. Rework your processes, invest in the right tools and make sure you have systems in place that enable conversation and collaboration.

You might already be familiar with some of the beautiful, pre-designed themes for Telerik and Kendo UI components, but did you know that Progress also offers an end-to-end design language for creating your own custom look and feel? The Progress Design System documentation is an indispensable resource for anyone—developer or designer—who wants to use one of our component libraries as the basis for their own design system.

Here’s what’s included:

Foundations of Design Guidance

If you’re a design beginner, fear not—the Foundation resources will guide you through several crucial design concepts that you’ll need to understand in order to build a design system.

The documentation offers high-level overviews in simple and clear language, covering everything from color and typography to globalization and accessibility. Dive into the Foundations sections and get comfortable with design terms and basics before putting them to work in your design system!

Documentation and Recommendations for Theming

Once you’re feeling comfortable with the basics, let’s take it to the next step—theming! The Themes section covers the pre-made Telerik and Kendo UI themes as well as multiple ways to customize themes to create your own visually distinct UI. This includes everything from technical guidance (like installing the various npm theme packages) to design guidance (like accessing the Figma UI Kits) and links to framework-specific documentation.

A Detailed Guide to the Telerik and Kendo UI CSS Utilities

The Telerik and Kendo UI CSS Utilities are utility classes that allow you to build custom layouts without writing CSS. Each utility class changes the appearance of the target element by applying a specific CSS rule. For example, to round the corners of an element without writing any CSS code, we can add the k-rounded-md class to that element and the utility will apply the styles. It’s an incredibly powerful tool that can really speed up your development time!

All the various CSS utilities are documented here, organized by type in the left-hand sidebar.

Design-Oriented Component Documentation

Of course, every component in our Telerik and Kendo UI component libraries has framework-specific documentation—but that documentation primarily focuses on implementation from a development perspective. The framework-specific documentation is great for questions about component APIs, properties, data binding and the like.

The Design System Components documentation, on the other hand, brings a unique design perspective: It focuses on component appearance, user interaction states, anatomy and visual customization options. The Design System component documentation is also universal, since all of our components look and behave similarly across framework libraries—allowing you to create cohesive and intuitive applications, even if they don’t all use the same language!

Additional Helpful Resources

For information about content beyond components, check the Resources section. This covers things like our font and SVG icon libraries, the amazing Figma UI kits, links to our free learning courses and community forums, and more! Whether you’re looking for downloadable assets or a little extra help, the Resources page has you covered.

Don’t Go It Alone—The Progress Design System is Here to Help!

Building a design system can feel intimidating, but with the right tools it doesn’t have to be! There’s no need to reinvent the wheel when you can start with our robust, accessible components and customize them however you like. Whether you’re working on your own or collaborating with designers, the Progress Design System empowers you to create beautiful, unique visual identities for your applications.

Collaboration between designers and frontend developers is crucial for delivering successful web projects. However, communication gaps and misalignment can sometimes arise due to differences in (technical) language, tools and perspectives.

In this article, we’ll explore some practical tips and strategies from a frontend engineering perspective to improve collaboration in design-development workflows.

Be Involved Early

As a frontend engineer, being involved early in the design process can significantly improve collaboration throughout the design and development workflow. The developers on the team often have valuable technical expertise and can provide input on the feasibility and technical considerations of certain design decisions.

For example, input and additional thoughts can be provided on the performance implications of certain design elements, such as complex animations or heavy image assets. In addition, insights can be offered on topics such as cross-browser compatibility, accessibility and other technical considerations.

By having frontend engineers included in the early stages of the design process, designers can benefit from these important insights and ensure that designs are implementable while being aligned with the technical constraints of the frontend codebase.

Use Design Collaboration Tools

Design collaboration tools can greatly streamline communication and collaboration between designers and frontend engineers. Tools such as Figma and Sketch allow designers to share design assets, generate style guides and provide specifications, making it easier for frontend engineers to understand and implement the designs accurately.

Design collaboration tools allow designers to create design components that can be easily shared with frontend engineers but also provide features like design versioning, design annotations and design comments that facilitate communication and feedback between designers and frontend engineers. Frontend engineers can then use these tools to inspect design assets, generate code snippets and export assets, which can speed up the development process and ensure accuracy during development.

Document Design Guidelines

Documenting design guidelines and best practices can help maintain consistency in design implementation. Frontend engineers can contribute to this by creating and updating design guidelines while ensuring that they align with the technical constraints and requirements of the frontend codebase.

For example, design guidelines can include specifications for design components, such as typography, color schemes, spacing and layout. It can also include guidelines on accessibility, performance and other technical considerations.

Documenting design guidelines can serve as a reference for both designers and frontend engineers, helping them stay aligned and ensuring that the design system is implemented consistently across different parts of the application or website.

Facilitate Testing Sessions

Facilitating testing sessions during the development process (and before launch) can be a valuable approach to further enhance collaboration between frontend engineers and designers. Testing sessions can be done through various methods, such as regular team meetings, video conferences or collaborative tools that allow for real-time feedback and issue tracking.

During testing, designers can provide feedback on any design-related issues that may affect the user experience or overall aesthetics of the product. Frontend engineers can then identify and fix any bugs or inconsistencies in the implementation of the design, ensuring that the final product is visually appealing and functions smoothly.

Testing sessions allow both parties to identify and address any issues or inconsistencies early in the development process, ensuring that the final product meets both design and technical requirements before the project is launched to users.

Communicate Regularly

Regular communication is crucial in maintaining alignment between designers and frontend engineers. Establishing clear channels of communication and encouraging regular check-ins and updates can ensure that any issues or concerns are addressed promptly, avoiding delays or misinterpretations.

For example, teams can schedule regular stand-ups, design reviews and feedback sessions to discuss the progress of the design implementation, address questions or concerns, and provide feedback. These regular communication practices can help identify and resolve any misalignments or issues early in the development process, ensuring that the project stays on track and meets its deadlines!

Be Empathetic

Practicing empathy and understanding toward other roles and perspectives is fundamental to successful collaboration. Designers and frontend engineers have different areas of expertise and perspectives, and it’s important to respect and understand each other’s viewpoints.

Designers may prioritize aesthetics, usability and user experience, while frontend engineers may prioritize technical feasibility, performance and maintainability. It’s important to always aim for a middle ground where both perspectives are considered and integrated into the final product. By finding this middle ground, teams can collaborate more effectively and create products that are both visually appealing and technically sound.

Wrap-up

Successful collaboration between designers and frontend engineers is crucial for the effective implementation of design systems. By following the practical tips and strategies shared in this article, such as being involved early in the design process, using design collaboration tools, documenting design guidelines, communicating regularly and practicing empathy, teams can bridge communication gaps and deliver products that meet both design and technical requirements, resulting in a successful outcome for a project.

When designers hand off their Figma mockups to developers, there are a few main things that developers are trying to take from those files:

1. A general understanding of which elements should go where on the page
2. Any planned user interactions (i.e., “What happens when they click this button?”)
3. Specific values for the CSS (hex colors, font sizes, border radii, etc.)

The first two can usually be picked up pretty quickly as the developer explores the Figma file and plays with the prototype. It’s the third one—all those little values that need to be copied over—that’s the most tedious.

Dealing with Design Tokens

In Figma, those values are captured as “design tokens.” Depending on the scope of the design, there could be anywhere from just a handful to well over 100 design tokens in a single file! This is especially true in the case of design system documentation, where the design team will have created a great many of these design tokens to capture every possible interaction state of every single component.

For example, the Kendo UI Figma Kit includes 150 different design tokens that capture every aspect of the UI look and feel: drop shadows, gradients, colors, typography, borders, focus and hover state effects, and so much more!

We need those design tokens to become CSS variables. Moving those values manually from Figma into our stylesheets is painful … to say the least. Thankfully, there’s a better way.

Progress ThemeBuilder not only allows us to import the variables from Figma, it also gives us a real-time preview of how the components will look in the Live Preview panel! When we apply the imported design tokens to our Theme Styles in ThemeBuilder, the components in the Live Preview will immediately update to reflect those changes across the entire library. That gives us the opportunity to do a quick visual check against the Figma file and ensure that the components look the way the designers intend them to look.

How to Use the ThemeBuilder Figma Plugin

To take advantage of this, we need four things:

1. An application using one of the Telerik or Kendo UI component libraries
2. A Figma file with design tokens defined. We can use the associated Telerik or Kendo Figma Kit for this, but we don’t have to—any Figma file will work!
3. The Progress ThemeBuilder Figma Plugin
4. ThemeBuilder

Let’s assume that we already have an application using KendoReact. Our design team has a Figma file where they’ve created a new look and feel for the application UI. They’ve sent us the mockup, and it’s our job to implement those styles in the app.

The first thing we do is install the ThemeBuilder Figma Plugin by clicking the “Try it out” button in the top right corner of the Progress ThemeBuilder page in the Figma Community. This will add the plugin to our Figma account, so we can access it in all of our files.

Then, we open the Figma file sent by the design team. We can run the plugin by clicking on the Add-Ons button in the toolbar, switching to the Plugins panel, and selecting Progress ThemeBuilder from the list.

When the ThemeBuilder Plugin is open, click the “Run” button and select “Export Styles” from the dropdown menu. We’ll be prompted to log in to ThemeBuilder.

When we return to Figma, our available ThemeBuilder projects will be available for selection in the modal window. Choose the project for import, and click “Select.”

Then, we’ll be shown a list of every single design token in that Figma file. They’ll all be selected for export by default, but we can customize that if (for example) we only want the colors and not the typography. In this case, however, we would want everything, so let’s leave it all checked and click the “Export” button.

In just a few seconds, the export will run and we’ll see a confirmation message telling us that the export was successful!

If we follow the “Open in ThemeBuilder web app” link, we’ll be taken to our ThemeBuilder project where the Figma design tokens are now visible in the left-hand Theme Styles column. All the imported styles will have a “--figma” prefix, so we can easily tell them apart from any styles we might have created earlier.

Then, we just assign those new Figma design token values to our existing theme styles! Note how the updated color is immediately applied to the components in the Live Preview.

When we’ve assigned all the variables and are happy with how the new styles are looking, we can use the Export tool in ThemeBuilder to export application-ready CSS that captures all the changes we made.

Just like that, we updated the design of our entire component library to match the design team’s mockup—without writing a single line of CSS!

Ready to Try it Out?

If you aren’t already using a Telerik or Kendo UI component library, you can try one out completely free for 30 days. Same goes for ThemeBuilder—try it free for a week and see just how easy it can be to theme, adjust and export styles. Each tool is powerful on its own, but together they make the perfect team for bridging the gap between design and development!