The Alarming Truth

When systems become complex, safety becomes a challenge. Alarms are the guardrails that help prevent disaster from striking. Yet poorly designed software creates an alarming reality.

Disasters rarely happen because of a lack of alarms. They happen because there are too many.

In control rooms, alarms are everywhere. And maybe that’s the problem. Alarms fire so often that users stop noticing them. They mute the sound just to make it through the shift. And when they do notice an alarm, it’s often nonessential or even a false positive.

When everything seems urgent, nothing is. When alarms fire constantly, people stop responding.

We like to think having alarms equal safety. We overestimate. Mistrust. And bad alarm design leads to fatigue, overload and inactivity.

Designing alarms means designing for the human in the loop. Because when the alarm goes off, it’s not the sensor that solves the problem. It’s the responsible person inside the system.

Classification Clarity

If you want alarms people can trust, you need alarms people can understand. That starts with clear, consistent alarm classification.

An alarm is not just awareness. It’s a signal that something needs attention.

But systems are becoming more complex. Staff is reduced. Workload increased. This cognitive context demands crystal-clear communication. Alarms with the right priority, and the expected reliability.

You need a common classification system across your platform—one that spans code, UI, processes and people.

That means aligning on two key dimensions: priority and reliability.

Priority

Priority tells you what to focus on—what truly requires your attention.
It reflects a combination of urgency × severity.

• Urgency is how much time you have. Do you act now, or do you have a buffer?
• Severity is the consequence. What happens if you miss this?

Reliability

Reliability tells you whether the alarm can be trusted. It depends on two factors: probability × accuracy.

• Probability is about trusting the event. Is this likely to happen?
• Accuracy is about trusting the source. Is the data reliable?

Consistent classification creates clarity.

I have seen systems used by the same operator. One used low, medium, high priority with green, yellow and red color-coding. Another used lo-lo, lo, mid, hi, hi-hi. A third used normal, critical and urgent. This kind of inconsistency makes it difficult for operators to judge.

But labeling an alarm is just the start. The real challenge is what happens next. What is the next step in the alarm lifecycle?

The Alarm Lifecycle

Alarms are not just event messages. They’re part of a loop. You want users to respond. To resolve an issue or prevent a disaster.

That’s the job of the alarm lifecycle: a continuous system that helps teams manage risk.

I use a simple model to describe this: the alarm lifecycle triangle

Manage → Monitor → Event → Trigger → Notify → Respond → Manage

When you design a system, you’re facilitating this lifecycle with user interfaces. You can leverage existing UI components to design each step with a greater experience.

Manage

This is your start and end. Before an alarm ever fires, someone has to define it. What triggers it? Who owns it? How should it escalate?

You need alarms in an overview, a list or a dashboard. A place where teams configure, control and store alarms.

Common components:
Datagrid, listview, card, form.

Monitor

This is the activity between Manage and Event. Monitoring means watching the data, the patterns, the signals. Until something happens, you’re anticipating what might happen.

Common components:
Chart, timeline, gauge, listview.

Event

This is the moment of truth. A condition is met. A rule is broken. Or a system forecasts that something will occur.

You can see these events unfold through visuals. Noticing anomalies, spikes or drop-offs in the data.

Common components:
Chart, gauge, diagram.

Trigger

This is where logic turns into action. The system makes a decision: raise the alarm.

Triggers need to be clearly defined. Not just what happened, but what matters enough to notify. Good trigger design avoids false positives and misplaced thresholds.

Common components:
Popup, badge, conditionally styled rows.

Notify

This is the handoff. The alarm moves from system to user.

But how? To whom? Through what channel? That’s where UX matters most. Alarms must reach the right person, with the right context, at the right time.

Common components:
Alert, badge, toast, modal, notification panel, chatbot.

Respond

This is the moment of action. The user sees the alarm. Now what? Acknowledge. Escalate. Or Fix? Maybe even dismiss or snooze it.

You’re not just designing for reaction. You’re designing for decision.

Common components:
Button, dropdown, chip.

Alarm, Alert or Action?

A common misconception is that alarms and alerts are the same. But alerts are just one type of notification—used by alarms.

An alert tells you something happened. An alarm tells you to do something about it. That action is what actually matters.

Too many systems stop at notifying. They fire off popups and badges and call it a day. But if you want real safety, you need to go further.

You need to design for different types of response:

• Passive – “I saw it.”
• Reactive – “I’ll act now.”
• Proactive – “I’ll prevent it.”

If you want people to act, you have to design for it—with proper classification and a well-managed lifecycle.

From out of control, to in control.

In June 2025, Apple announced Liquid Glass. This new glassmorphic digital material has changed the way components look and feel on all its operating systems and devices.

Because of how drastically the Apple UI has changed, is it reasonable to expect that designers and developers will have to start mirroring their app and website designs to fit? And if they do, will these adaptations be minor or will it transform the way the entire web looks in the coming years?

In this post, we’re going to look at the new Liquid Glass UI and the changes it’s bringing to Apple’s operating systems. We’re also going to look at the similarities between Liquid Glass and Google’s original Material Design concept, and what this means for anyone designing digital interfaces in the near future.

What Is Apple’s Liquid Glass UI?

On June 6, 2025, Apple announced the new Liquid Glass software design.

Alan Dye, the VP of Human Design for Apple, says that goal of Liquid Design is to:

“Make something purely digital feel natural and alive—from how it looks to how it feels as it dynamically responds to touch.”

In the promotional video released with the announcement, we get to see what Liquid Glass looks like and what makes it different from previous Apple interfaces:

Let’s have a look at these changes in more detail:

Universal Design for All Platforms

It’s not just macOS or iOS that’s getting this Liquid Glass UI. All platforms have been redesigned with this new material. This includes:

• macOS
• iPadOS
• iOS
• watchOS
• tvOS

In addition, Apple apps have been reskinned with Liquid Glass elements, like Safari, Camera, Apple Music and more.

Essentially, everything went from looking like this:

Here we see how flat and ultra-minimalist something like a toolbar looked prior to Liquid Glass. The toolbar gives off the appearance that it’s part of the phone’s hardware instead of part of the screen or software.

The icons looked touchable simply because of their illustrated appearance and because they were confined to a toolbar container, not because they looked like buttons or stuck out in any other way from the interface.

Fast forward to June 2025, and here is how this toolbar now looks:

The icon designs are the same. However, the toolbar no longer appears to be part of the hardware. Nor is it separated from the content area and contained within a thick opaque space. Now, it sits within a semi-transparent component that hovers over the content.

This component (and all Liquid Glass components) also has rounded edges. This is something that Apple was intentional about when coming up with Liquid Glass as they wanted these hovering components to naturally nest within the rounded edges of Apple’s devices.

Reskinning of the Fundamental Elements

Unlike some design trends or brand redesigns that reenvision how every part of the UI looks, Liquid Glass only affects the fundamental elements. As Apple explains to developers and designers wanting to adopt it for their own purposes:

“Liquid Glass seeks to bring attention to the underlying content, and overusing this material in multiple custom controls can provide a subpar user experience by distracting from that content. Limit these effects to the most important functional elements in your app.”

So, which parts of the UI have changed exactly?

If we’re talking about Apple’s operating systems specifically, then Liquid Glass has transformed quite a bit of it.

On the lock screen, for instance, these elements are Liquid Glass:

• Date and time
• Notification bars
• Audio/video controllers

The home screen is majorly transformed as well. For example, these elements are now skinned using Liquid Glass:

• App icons
• Calendars
• Weather tracker
• Docks
• Sidebars
• Search bars
• Cards
• Navigation/screen slide controls

Here’s what the home screen of an iPhone looks like with Liquid Glass components:

Unlike previously where the background graphic or design would’ve been masked by all the icons, Liquid Glass allows us to see through them. So the content is no longer hidden by the components that sit atop it.

Now, here’s what a larger screen might look like if someone were to search for something to watch on a streaming service:

This has a much different appearance than the iPhone example above. In part, because the background is darker. But also because the Liquid Glass components don’t appear as see-through. (I’ll talk about that in the next section.)

These are just examples of how the Apple operating systems have changed. But their apps look different too.

For example, here’s what the controls look like when watching a movie or video in one of Apple’s apps:

You can see that the content is untouched. However, all the controls and settings in the layered foreground now have the distinctive Liquid Glass frosted look. These include:

• “X” exit button
• Screen sharing options
• Volume control
• Video player controls
• Closed captioning controls
• Video timeline bar
• Info buttons

Essentially, buttons, toolbars, sidebars, navigation and controls will now take on the look of Liquid Glass.

Translucent and Fluid Layers

Liquid Glass was designed to be a digital material that looks and acts like glass does in our physical world. So, these components are translucent and also refract light. If you watch the video above, you’ll see how moving an iPhone back and forth makes it look as though light is shining on the “glass” of the time displayed there.

Now, Liquid Glass can’t be completely transparent as it would create a readability and accessibility nightmare for Apple users. So, these elements have more of a soft glazed or foggy glass appearance than anything.

Refraction, however, does work a lot like it does in the real world. For example, here’s what the address bar and other navigational components might look like on an iPhone:

There are pink flowers in the center of the background. On top of this section is where you’ll find the address bar. You can see how pieces of the flower (the yellow and pink) still poke through.

That said, refraction doesn’t work equally the same way for all components.

For smaller, less intrusive elements like the address bar, it does. For larger elements that cover more of the content, it does not.

Here we see how clicking open a menu of controls gives us a more frosted Liquid Glass layer. Yes, we can still see some of the content and colors beneath it, but not as much as we do with smaller layers.

Without this extra-frosted effect, it would be very difficult to read the image editing settings in this menu.

We can’t forget that Liquid Glass is called “liquid” for a reason. This is something that we didn’t see much of in the above video (which is where these image stills come from), but it’s an important part of the new Apple user experience.

In terms of how this plays out, there are a couple of new effects to be aware of. One is the illumination effect. When touched or clicked, Liquid Glass components glow. Depending on the flexibility of the component, it may also flow beneath your finger or cursor if you move it.

The video quality here isn’t the best, but you’ll get a good sense for how this fluidity “feels” around the 4-minute mark.

Intuitive Adaptions

Something else that makes Liquid Glass different from what we’ve seen before is how it adapts to the environment as well as to user interaction.

To start, Liquid Glass components change color based on what’s behind them. We saw the example earlier of the pink flower behind the address bar. In the following example, we see how the blog interaction toolbar and back button change color as a user scrolls down this blog post.

The frosted glass starts out red at the top of the page:

As the user scrolls over the main content where the white background is, the Liquid Glass color changes to match it:

It’s not merely changing the background of the “glass” layer though. Liquid Glass will alter the color of the icons or text, too. For example, when these components pass over a darker section, the glass goes black while the icons turn white:

Ultimately, the color of your glass adapts to whatever content is behind it.

The shadow behind the glass will change, too. What we’ve seen so far is what happens when images and sold color blocks appear beneath Liquid Glass layers. However, if large swaths of text happen to show up behind them, then a shadow will appear to keep the text or icons on the Liquid Glass layers readable.

Another way in which Liquid Glass has been designed to adapt has to do with its size.

Liquid Glass is meant to have a minimal footprint. For starters, Apple has taken these components out of the content areas of the screen and layered them on top. By making them translucent, they feel lighter and less cumbersome, too.

But not every component is going to be small or stay small. For example, this is a search bar for Apple Maps:

It sits at the bottom of the phone screen, allowing the user to focus on the map. When clicked, though, it doesn’t just enable you to type a query into the field.

Instead, it opens up a panel with helpful search options.

This panel will disappear and shrink down to the minimal search bar if the user engages with the map outside of it. The same thing will happen with other small components that expand. The second a user disengages, scrolls, clicks away, etc., the Liquid Glass component shrinks down to its minimum size.

At the same time, the opacity of components changes based on their size. So, when you’re seeing the smaller version of them, they’ll be more translucent. When the larger menus or additional options appear, the component will take on a more opaque appearance. This is to improve readability as well.

Comparing Liquid Glass to Material Design

For those who don’t remember, Material Design was Google’s design system and UI framework that went mainstream in 2014.

As Ina Tontcheva explained:

“The team chose to use a metaphor of paper surface as the unifying principle because people have a long history of interacting with paper and surface and because they are physical and exist in the world. The team relied on the tangible metaphor that users understand intuitively to accelerate the understanding of their UI.”

At the time, Material Design was a breath of fresh air. It offered a much-needed shift away from skeuomorphism and the flat design trend that followed it.

The thing is, it didn’t just change the appearance of all of Google’s products, it went on to become the hottest design trend. It altered the face of the web for a couple of years—but not entirely for good. Many websites and apps looked and felt the same because they’d all followed Google’s specific guidelines (and even color palettes).

This era of design made it difficult to stand out visually. It also had its flaws when it came to usability and accessibility.

Why do I bring this up? Well, I suspect we’re about to see something similar happen with Liquid Glass.

There are some key differences, though, that may keep Liquid Glass and the glassmorphism trend as a whole from taking over the web. Or even from sticking around too long within the Apple ecosystem.

Google’s Reach

Right now, Liquid Glass is strictly for Apple devices and apps. Google’s Material Design, on the other hand, was for all Google products, which could be accessed on any device. (Not to mention the sheer popularity of Google Chrome and Search.)

So, unless Android, Google and other operating systems decide to follow suit, we may only see this trend within the Apple ecosystem.

That brings up an important question: Will these other tech giants make the move to a frosted glassy effect as well? What’s in it for them if they do? And how long will it take before they’re all in sync with this glassmorphism trend?

UI vs. Functionality

Material Design completely changed everything within the UI—the colors, fonts, components, backgrounds, layering and shading, animation, etc. Liquid Glass, on the other hand, is only concerned with functional components.

Because of this, Liquid Glass might not be something that designers and developers decide to adopt for their websites and apps.

Glassmorphism isn’t the kind of look that melds well with a lot of brands visually speaking. It’s a tricky medium as its glossiness and futuristic feel doesn’t work for many brands. Material Design had its limitations, too, but it didn’t have as exclusive of a feel to it. Plenty of brands were willing to play with the vibrant color palettes and paper-like layers.

If Liquid Glass were transforming the entire interface, some brands might be able to make that transition. But if we’re just talking layered components, most won’t be able to make that switch seamlessly.

Practicality

While Material Design may have been groundbreaking compared to the design trends we had before it, it still felt grounded. Basing the redesign on paper helped with this. It’s a simple and practical medium.

On the other hand, Liquid Glass reminds me of the kinds of things you see in sci-fi movies like Minority Report.

I think Apple was thinking many years ahead when it decided on glass as its medium. Right now, our hardware is still too solid and clunky to blend with glassmorphic UIs. Perhaps in three, four or maybe 10 years from now our devices will resemble those of Minority Report. But, for now, Liquid Glass doesn’t feel natural.

So, unless our tech catches up, I’m not sure it’ll have staying power.

Will Liquid Glass Be the Next Big Trend?

Apple has gone all in on Liquid Glass, changing the look and feel of all its products and proprietary apps.

Do I think we’ll see widespread adoption of it across the web? Not likely.

The one thing that may change this trajectory is what developers and designers do with it.

Let’s say that developers and designers feel pressured to add glassmorphic components to their apps for their Apple users. Without a Liquid Glass app icon or in-app components, the experience might not feel as seamless anymore.

But unless those developers and designers are working for a major enterprise with massive resources and budgets, can they afford to create a Liquid Glass-inspired experience for Apple users and a completely different one for everyone else? What’s more, do they want to have such a huge disparity between the user experience for these user segments?

We’ll have to see how things go with Liquid Glass in the next year or two. If popularity wanes, if it causes massive problems for accessibility (which there are rumblings of) or if Apple decides to revert back to the old design, then things will stay as they are. However, if Liquid Glass succeeds and wins the support from the huge user base that is Apple users, then non-Apple operating systems and devices will have to go all in on glassmorphism.

With more than 100 components in each version, Progress Telerik and Kendo UI component libraries have done a pretty good job of anticipating … well, just about every component you’ll ever need.

Still, every now and again you may find yourself in need of something truly custom—the kind of component that just isn’t possible for a third-party library to offer. We get it, and (more importantly) we don’t think that using a third-party library like Telerik or Kendo UI should ever make it harder for you to do your own thing.

In fact, we’ve created tools that make it easier: like the ThemeBuilder Figma-to-HTML import plugin, which empowers you to create your own custom components and add them to ThemeBuilder where they can be tweaked and styled (either by editing the code or using our no-code tools) alongside all the Telerik and KendoUI components. By doing this, you can create a single source of truth for all your design decisions—a place where designers, developers, product managers and more can all come together to see the design system implemented across your full suite of components.

Sounds like something that might be helpful for your team? Let’s dig in!

Using the ThemeBuilder Figma Plugin

The ThemeBuilder Figma plugin can do a few different things; you might have already read one of our earlier blogs about importing design tokens with it. But did you know that you can also import full components?

Just install the plugin for your Figma account, launch it, sign into ThemeBuilder, and you can choose the “Components” option from the “What Do You Want to Export?” screen.

Then, you’ll be prompted to choose a ThemeBuilder project to add your custom component to. Once you’ve picked your project, select a component in Figma. It’s important to note here that you need to have actually created a component instance within Figma—we’re not just using “component” as a general term here!

Once you’ve selected a component, you can start doing the really cool part (at least, in my opinion): mapping subcomponents. After all, most custom or complex components are still made up of smaller, more basic components, right? That’s the whole idea behind atomic design! We want to help keep that structure intact, so you can always leverage Telerik or Kendo UI components to build your unique custom components.

To map subcomponents, just click the “Map” button, then start matching up the listed components with any Telerik or Kendo components you might have used. For example, this custom header could use our AppBar component, and my clickable icons could be Buttons that use SVG Icons!

After getting everything mapped and ready, just click “Export.” You’ll see a confirmation notice; when you open up your ThemeBuilder project, the new component will be there under the “My Components” tab.

Best Practices for Your Best Exports

To get the most out of the ThemeBuilder component export, here’s what we recommend:

• Use clear and unique names for components and nodes to generate meaningful CSS classes.
• Create lean components; avoid unnecessary layers wherever you can.
• Embrace composition: build your custom components with Telerik or Kendo UI components whenever possible (super easy if you’re also using the Figma UI Kits), and use the mapping function to keep everything connected.
• Leverage styles and variables; these export as reusable tokens, making updates easy and centralized.

Ready to Try?

This workflow flips the traditional handoff cycle: no more do developers have all the say in how custom components get interpreted and built. Designers now have the capability, using the ThemeBuilder Figma plugin, to define which components are used to build more complex custom UI elements—and then to make any small adjustments and confirm that they look and behave exactly how they expect, thanks to the ThemeBuilder live preview.

Avoid re‑coding visuals, eliminate manual syncing and shorten time-to-production—all while preserving design fidelity and maintainability. What’s not to love?

We spent two years building it. With one of the best agencies. A design system that looked like it could outlive us all.

Then the budget vanished. The agency walked. A polished Figma file—and a codebase starting to fall apart.

The code was unmaintainable. Designers got stuck. Adoption stalled. The backlog exploded.

So I kept the Figma file and swapped the code. I turned to Kendo UI. Paid for the license because I needed something stable, well-documented and fast to implement.

And it worked. We shipped again.

Now? That same React kit has a solid free version!

That’s when it clicked: “Free” isn’t always better—but sometimes, it’s exactly what gets you back on track. And if adoption is the real goal? Free just might be your smartest move. How better to see if a library will work for you than to sample it first?

What Designers Often Miss

Designers love the crafting of design systems. We dream of the beautiful product we’ll build once our ideal design system is in play.

But decision-makers don’t buy aesthetics. They buy speed, clarity, predictability. To make a real case, speak their language. And that means knowing the tradeoffs.

Procurement & Approvals

Before you push a single pixel, you’ll probably hit:

• Budget cycles
• Procurement reviews
• Legal red tape
• Maybe a security audit

Even a relatively inexpensive tool might take months to get approved.

If your company already uses a toolkit from a known vendor like Progress Kendo UI, lean into that. Stick with a system that’s already passed legal, compliance and procurement.

That shortcut might be the reason your proposal gets approved.

Tech Stack & Documentation

A design system doesn’t live in Figma—it lives in code.

If your engineers can’t use it, or if it clashes with your stack, you’re not choosing a system. You’re creating a future headache.

You might use Angular today, but you’re one reorg away from React. Big orgs don’t run on a single strategy.

I’ve seen managers actively push Angular because their C and C++ devs could get up to speed faster. Meanwhile, another project was locked into React—by top-down mandate, no discussion.

You won’t control every decision. Pick one that supports multiple frameworks.

And don’t forget documentation. No dev adopts what they can’t debug. Docs win.

Change & Risk Aversion

Enterprise teams avoid change. Not out of laziness, but out of self-preservation.

The safest move? Stick to the status quo. And that means ignoring your proposal.

So when you introduce a new system, you’re not just bringing in components—you’re introducing risk. A existing toolkit lowers that barrier. Skeptics trust what they’ve seen before. A known name helps.

And if it comes from a vendor with a track record? Even better. If it’s already used inside the company? That’s your foot in the door.

Maintenance & Cost

Design systems need love. Someone has to update, support and maintain them. That takes time, money and often, it won’t be you.

Before pushing for something custom or new, ask:

• Who owns it six months from now?
• Will developers support it?
• What if funding disappears?

Getting stuck with a beautiful, broken system happens more often than you think. I’ve been there. That’s why I choose tools that cut overhead, not add to it.

Closing Framework

When leaders review a design system proposal, they don’t ask how it looks. They ask:

• Do we want this?
  Does it solve a real problem—or just add complexity?
• Will it work?
  Can we actually adopt it? Will our stack support it?
• What’s the risk?
  What could go wrong—and who deals with it?
• What will it cost?
  Not just money—time, resources, attention.
• What’s the return?
  How does this move the business forward?

Getting buy-in isn’t about visual polish—it’s about business alignment. Free is the hook. Adoption is the catch.

Long-term success doesn’t come from picking the prettiest system. It comes from picking the one your team can live with, ship with and grow with.

Try KendoReact Free now, and explore the Progress Design System Kit.

You never forget your first design battle. Mine? A dragon.

Not a medieval beast, but a tiny, pixelated icon squeezed inside a bloated toolbar of a 3D modeling application. It wasn’t even supposed to be a dragon—it was just a 16x16 blob of green and red pixels, hand-crafted by a passionate or maybe careless developer in Paint. Instead of resembling the structural builder it was meant to represent, it looked more like a beast that is usually tamed by knights in shining armor.

The name stuck. No one called it by its function. Instead, people said: “Click the dragon.”

And the wild part? Everyone knew exactly what that meant.

Now, I had to redesign 750+ of these little legends—each with its own strange, nostalgic history.

The Toolbar Tyranny

The dragon was one icon in a labyrinth of toolbars. Over time, new features meant new buttons. More buttons. More clutter. The toolbar wasn’t a neat row of helpful shortcuts anymore. It had turned into a UX landfill, stacked high like the old versions of Microsoft Word, where functions disappeared into an icon abyss.

So, we decided to get rid of toolbars and moved to ribbons.

I redesigned the UI with smarter workflows, contextual actions and cleaner navigation. No more pixelated dragons, no more guessing games.

Or so I thought.

The Redemption

For years, toolbars in older software were a chaotic mix of actions and navigation.

A single row of tiny icons could hold anything from a direct command to a menu that reshaped the entire interface.

This inconsistency made toolbars confusing. As design systems matured, the industry began shifting away from them—favoring new navigation models. I was part of that shift.

When I started designing and implementing modern UI systems, my team embraced menus, ribbons and larger labeled icons—patterns that brought clarity and improved navigation.

As software evolved into web-based SaaS applications, navigation became even more structured, layered and nuanced. We moved toward on-demand actions, contextual UI and interfaces that guided users instead of overwhelming them.

It worked.

The experience improved. But then, something unexpected happened.

I missed the toolbar.

Not the old, bloated version, but a well-structured, well-grouped and well-positioned set of actions—a true toolbar component designed with clarity and context. In many cases, I found myself recreating toolbars without calling them that—grouping icons in a menu bar, placing action buttons together, designing around what was missing.

Eventually, I brought it back—deliberately and thoughtfully.

Taming the Dragon

Toolbars were never the problem. How we used them was.

So instead of eliminating them, we need to design them better:

Actions should be contextual. Instead of scanning icons and guessing, users should see what they need, when they need it.

Icons should be recognizable. Monotone icons and branding challenges aside, a well-placed, well-designed icon can serve as a familiar anchor in complex workflows.

Efficiency should drive the experience. Enterprise and industrial software often requires fast, precise actions. Toolbars, when designed right, accelerate productivity rather than slow it down.

With AI-driven interactions—such as predictive commands, voice-driven actions and prompt-based workflows—some might argue that traditional UI elements are becoming obsolete. However, icons and contextual action bars still play a critical role in bridging the gap between automation and user control. Clicking an action you instantly recognize, at the right moment, in the right spot? That’s powerful.

This dragon may be gone, but the lesson stays: Good UX doesn’t always mean kill it—but tame it.

What is your dragon that needs to be tamed?

If you haven’t worked with a design system—or a component library—before, the terms can be a little hazy. What’s the difference between them? The short answer is that a component library is just one part of a larger design system.

It is possible for component libraries to stand alone without integration into a design system, or for design systems to exist without a component library. However, most of the time a full-featured design system will include a component library.

Let’s take a closer look at what each of these terms means and what they typically include.

Component Library

A component library is a collection of reusable, modular components that developers can use to speed up the creation of user interfaces. They include everything from simple components (like buttons, dropdowns and checkboxes) to really complex ones (like data grids, spreadsheets and data visualizations).

Component libraries can be built in-house, but most of the time it’s more efficient to leverage a preexisting one (like Progress Kendo UI). When developers use a component library, they can spend less time building components from scratch and more time combining them into unique and useful applications.

Using a component library is especially helpful for creating consistent interfaces—and consistent code! When a team of developers is dividing up the work, sometimes two developers might build the same element (like a button) in slightly different ways when working on different features in the app. Over time, this creates an interface full of components that all work a little bit differently, both for the user and the developer. This makes the UI hard for users to learn, and the code challenging for developers to scale and maintain.

In general, it’s better for everyone if the same component is reused across the entire application; by collecting the commonly reused components all in one place and documenting how they should be used, component libraries make that goal much easier to achieve.

A component library is primarily used by developers, but designers will often reference it as well during the early stages of feature ideation and design. When designers know what components the developers will be using to build out their designs, they can get aligned early in the process. This lowers the amount of iteration (and frustration) during the handoff phase. Think of it like knowing which Legos you have available in your kit. Once you understand what you have, you can start to think about how to use the pieces in different ways to build what you want!

Design System

A design system is intended to be much broader—a collection of interconnected visual elements, organized and documented for easy reference. You can think of it as a library of all the design resources and assets you could ever need, customized specifically for your application. As you might guess, that can (but doesn’t have to) include components. Some of the most common elements that you’ll find in a design system include (but aren’t limited to) design tokens, grid systems, icons, components, style guides and brand language or tone-of-voice guides.

Much like component libraries, you can build a design system in-house or leverage one that already exists (like Material or Fluent). Which option is the right fit often depends on company size and design vision. For small companies without many resources who aren’t particularly focused on creating a unique look and feel, a preexisting design system can save a LOT of time and effort.

However, for a larger company—especially one with a dedicated design team that either needs to coordinate among many different departments or is highly invested in a custom brand—the upfront investment of creating an in-house design system will pay off in spades.

Design systems are also hugely useful because they make sure that everyone is speaking the same language. Have you ever been in a situation where two people thought they were disagreeing on something, only to discover they were actually describing the same thing the whole time—just with different words?! Maybe one was calling it a “toast notification” and the other was calling it a “snackbar”? Or maybe your idea of “sky blue” was different than what your designer envisioned? When you’re using multiple different libraries, frameworks or languages, it can be incredibly easy to get wires crossed; design systems can help uncross them.

Unlike component libraries, design systems are referenced widely by lots of different people across different teams and departments: designers (of course), but also developers, product managers, copywriters, social media managers and more. Honestly—pretty much everyone benefits from having access to the design system.

Which Does Your Team Need?

If you don’t have anything right now and are trying to figure out where to start, my recommendation is to begin with a premade component library. By beginning with a collection of prebuilt resources, you can start seeing those consistency and design benefits without having to invest a lot of time in setup to get things up and running.

If that’s working well, then you can start thinking about expansion. Maybe you want to start customizing the look and feel of those components, or documenting specific ways you want to use those components within the scope of your app. Maybe you can look at your CSS color variables (or Figma design tokens) and turn those into more formal brand guidelines. Maybe you mostly use a preexisting icon library, but you had to create a couple of custom ones—so you create a repo where they can all live in one place.

Before you know it, your component library is growing into a design system. In fact, we even offer a Design System Kit to help you intentionally expand Kendo UI components into a full custom design system!

Of course, it’s also possible to sit down with intention and create a design system completely from scratch. If you’ve got a team of talented designers at your company, that’s probably even the best way to do it—the ideal.

However, realistically, a lot of folks aren’t working with the ideal, and I think it’s good to remember that it’s also OK for design systems to grow organically. Start with what you’re using now, get it all collected in one place and document how you use it. As you add new components, colors, UI patterns, fonts—or anything else—add it to your collection. That’s a design system, too!

You wouldn’t write the same function over and over again in your code; you’d export it once, so you could import and call it wherever you needed it. Component libraries and design systems are exactly the same—component libraries help you standardize and reuse UI components, and design systems help you standardize and reuse visual assets. They’re two great tools that are even better when they’re combined and used together!

Ever thought about kickstarting your design system with Progress Kendo UI components? We’ve talked about it a little bit on the blog before, but now it’s easier than ever thanks to KendoReact Free—no trials, signups or logins required! Combine that with the powerful features of Progress ThemeBuilder (which, by the way, also offers a free tier) and you could have a design system proof of concept (POC) up and going with no spend and very little time … which is just what Ryan Spencer and I demonstrated in our recent webinar. That’s right, we teamed up with Bitovi to talk about how to leverage these powerful tools to create a super-fast design system POC.

Now, let’s be honest here: will the design system you create in mere hours be the perfect end solution for your team? Of course not—design systems are meant to grow and change with your product. They need maintenance and documentation, and they should (ideally) integrate more than just your component library and design tokens. In our example, things like tone of voice guidelines, different logo versions, common patterns and page templates, usage guidelines, etc. weren’t included—but for a complete, robust design system you’d almost certainly want to add them.

However, getting buy-in can be one of the most challenging hurdles to jump when it comes to starting a design system. That upfront investment of time and effort can be daunting when you’ve got other projects to balance. By putting together a quick example that offers immediate value, like Ryan and I did here, you can demonstrate the long-term benefits without the big investment. After all, if this is what you can get from a quick POC, imagine all the ways you could benefit from a full design system!

Tools for Our Design System POC

To speed up the creation of our design system POC, Ryan and I reached for a handful of tools that helped us skip repetitive tasks, handle automatic imports/exports and more.

1. Kendo UI Figma Kits: By starting with the Figma UI Kits, we could see all the components available as part of the KendoReact library—including all the various interaction states and small design details. Perhaps more importantly, in our situation, the Figma Kits also included a full list of design tokens that could be adjusted to suit our brand requirements.

   With the Figma Kits updated and customized, we were able to add them as a powerful piece of our design system. In the future, designers will be able to use those Figma Kits to create mockups and interactive prototypes with pre-styled, design-system-compliant components—not to mention, of course, importing the design tokens into ThemeBuilder.

2. ThemeBuilder: Speaking of which, ThemeBuilder was one of the most helpful tools we reached for, because it was what bridged the gap between the design and development sides of our design system. Despite the name, a design system isn’t just for designers—developers need to be able to leverage it, too!

   Because we could import all the work we did in Figma and then export ready-to-use CSS/Sass files, ThemeBuilder became a natural point of overlap and collaboration. We imported the styles, made small adjustments and tweaks, shared it with others on the team for approval, created and managed version history, and exported finished code—it was a perfect single source of truth between the two “sides.”

3. Storybook: What did we do with that CSS we exported? Well, we put it into a Storybook instance and applied it to our KendoReact components!

   If you’re only creating a single application, you can drop the ThemeBuilder generated CSS/Sass files right into that app. But if you’re managing a suite of applications, it’s better to have just one place where you style the components and pull everything from that—your own custom component library. It reduces the possibility of small changes creeping in, makes it easier to manage different versions/updates of the components (and design system), and allows you to write specific usage documentation just for the components your app is using. Think of it like creating your own custom version of KendoReact—just the components you need, in the version you’re using, styled how you need them, with instructions on how and where they should be used in your app. Plus, it’s super handy for visual regression and accessibility testing!

Curious How All Those Tools Fit Together?

Want the full, beginning-to-end walkthrough on how to seamlessly integrate all these tools (and more) into a design system POC? Check out the full webinar recording (also included below)!

After you’ve got a solid start, check out the Progress Design System Kit for more resources on growing and building out your design system.

Over the last several years, design systems have enjoyed their time in the sun—there’s been a lot of attention and hype around them, and for good reasons! They can solve a myriad of problems for both designers and developers. They’re not magic wands, though; they can’t fix everything and it won’t happen automatically. Let’s take a look at what design systems can do for us … and be realistic about what they can’t.

Design Systems Are Great Shared Documentation

One of the main selling points of a design system is being able to collect and document all the disparate parts of a user interface. It’s not just about listing the brand colors—it’s also for describing when to use each one, what they represent, how they should (and shouldn’t) be combined, and so much more. Multiply that across every UI element in your application, and all of a sudden, you’re looking at a seriously hefty piece of documentation.

This is especially helpful for sharing resources across teams. For example, many developers use a component library, though designers don’t always have access to it. If components are added to the design system, developers can document where and how they get used, what features they include, what can (and can’t) be customized, and so much more! This reduces the back-and-forth that can happen during the handoff process, because everyone was aligned on the capabilities and limitations early in the process.

… But They’re Not a Single Source of Truth

However, despite being shared across teams, it’s unlikely that the entire design system will be located in a single shared place. By nature, different parts of the design system will need to live in different places—for example, design tokens and logos might live in Figma, while components and templates might live in a codebase, and tone-of-voice and language guidelines might live in a text file or PDF.

While there are places where we can expose that information to collaborate (like Progress ThemeBuilder), in reality a design system is—in and of itself—a collaborative effort that requires specialist work from different teams. Anytime we need specialists, we also need specialist tools. We can share the output from those tools (like loading components into a Storybook instance or exporting logos as PNG files), but we’ll always need to manage and maintain the core elements in their respective original “homes.”

Design Systems Speed Up Design and Development

I’ve seen design systems described like building blocks before—small pieces that can be easily combined in a multitude of ways to create cohesive and visually interesting interfaces. Because all those pieces have been designed to go together, it removes a lot of the friction from both the design and development processes, allowing us to move from idea to product a lot faster!

… But They Don’t Mean We Can Skip Testing

However, sometimes I see people make the mistake of assuming that because they’re pulling from a curated, vetted library, they no longer need to worry about testing. After all, each component has been unit tested in isolation, so we don’t need to worry about QA, right? Each page was designed from our collection of approved resources, so no need for usability testing, right? Unfortunately … wrong.

Just because each element works individually doesn’t mean they’ll all work as intended when brought together into a final product. Design systems don’t remove the need for usability testing, accessibility testing or quality control. The good news: with all the time you saved during the build phase, you have plenty of time to test thoroughly and still hit deadlines.

Design Systems Empower Developers to Make Small Design Decisions

One of the (perhaps most useful) perks of a design system is that it enables non-designers to make informed design decisions. Especially as products and teams grow larger, it’s not realistic for developers to ask designers for guidance on every minute decision—designers have bigger fish to fry than choosing button colors! Often, developers are asked to “just” add something to the page real quick—a form, an announcement bar, a confirmation dialog, etc. Rather than having to begin the design process from scratch, they can grab UI elements from the design system and know that they’ll look professional, polished and visually cohesive.

… But They Can’t Replace the Work of a Skilled Designer

However, as the scope of the work grows, those quick-fix, pre-made elements may not be enough. That’s where designers come in. Design systems are meant to grow and expand with their products. They’re guidelines, not hard-and-fast rules that can never be broken. A skilled designer will know when new elements need to be added, old elements need to be revised or new solutions created entirely.

A design system can’t think about the user flow of an application. It can’t listen to user feedback and adjust layouts. It can’t balance UI elements on a page, understand user priorities or rework existing systems to incorporate new features. For all that—and so, so much more—there’s just no replacement for a designer.

Design Systems Save Time, Overall

One of the main reasons that teams create design systems is for the time they can save—we even mentioned it earlier in this very article, when talking about how design systems speed up design and development! That gives us time back to work on all sorts of other things, from innovation to bug testing and beyond. They enable us to create faster, iterate faster, ship faster—but to get there, we have to be willing to put in a little time, as well.

… But They Still Require Time for Creation and Upkeep

Design systems don’t come out of nowhere. The creation process requires an upfront investment of time and effort that is (speaking frankly) fairly significant. After all, you’re basically building a foundation that you want to set your application on top of—why would you skimp on that? For a design system to be adopted by the various teams and actually used, it needs to be thoughtfully created—not just thrown together quickly.

It also needs to be maintained. The maintenance process isn’t as time-consuming as the initial creation process, but it isn’t nothing either. A design system that isn’t kept up will eventually be set aside. It becomes a burden, rather than a help. Think of it like owning a car. It will help you get from point A to point B a lot faster than walking, but if you want to get the most out of it, you need to keep up with regular oil changes, inspections, tire replacements, etc. Without those regular check-ins, it will become a pain point instead of a help. Design systems are the same way.

Do You Have a Design System?

Thinking of starting one? Already working on it? Check out the Progress Design System Kit to see our collection of resources that can reduce some of that time investment for creation and maintenance. Start from the basis of our beautiful, accessible Kendo UI components and build your full design system on top!

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.

Progress ran a State of Designer-Developer Collaboration 2024 Survey aimed at shedding light on the design handoff process, and the role design systems play in addressing the inherent challenges. Thanks to our readers for all your input! Download the survey results at the previous link, or check out some highlights in this blog post: Developers Are from Saturn, Designers from Neptune: Survey Results.

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.