A brand’s style guide is a useful tool for defining the visual language of its digital products. A design system—which includes a style guide—is an essential resource for a brand that wants to bring stability, consistency and scalability to its omnichannel customer experience and visual strategy.
If you’re here, then you’re probably about to create a style guide or design system and looking for inspiration. While you could copy what all the big tech players like Google, Apple and Microsoft are doing, you might be surprised what you find elsewhere on the web.
There are many brands and organizations out there that have created brand style guides and design systems. So if you’re wanting inspiration on what to include in your design system or how to design it, start with this list. These examples might not be as well known, but they’re all really cool examples to check out.
The PDF style guide for b Restaurants is a great example of omnichannel branding. The style guide includes all the visual language information you’d expect to see, like:
In addition, the guide is split into two. In the first part you’ll find the visual guidelines for print (which makes sense since this is a style guide for a restaurant). In the second part you’ll find the guidelines for the web. There are also a bunch of examples at the bottom that show you the style guidelines in use—on the menu, business cards, the website, Facebook ads, etc.
If you need to bridge the gap between different channels—not just physical vs. digital, but across all your digital channels as well—this style guide is a good model to follow. It’s well-organized, simply written and easy to follow.
Duolingo’s online style guide is broken up into five sections:
Identity contains all of the information you’d commonly see in a style guide about colors, typography, logos, etc. The rest of the style guide is pretty unique when compared to the others you’ll see here.
For starters, it includes its Writing style guide along with the visual guidelines. What’s more, the Illustration section isn’t so much about the style of graphics used in the language learning app. It’s about how the designers create every illustration using three basic shapes for the sake of rhythm, simplicity and scalability.
If you have a unique visual style and you want to ensure that new designers are able to pick up on it right away, incorporating that type of information in your style guide would be beneficial. It’s also a good way to highlight how innovative your brand is.
Pajamas is the name of the design system for GitLab. GitLab is an open-source software project that has more than 3,000 community contributors. Because of this, a well-documented and well-maintained design system is critical.
This design system is beautifully designed and easy to navigate. It includes a section at the top for the style guide foundations—the logo along with the basic UI guidelines. Down below is where you’ll find the robust design system, which includes information and guidelines for:
This is a good example of why design systems aren’t just for big tech companies or large digital agencies. Any time you have numerous contributors or partners working on your digital products, a design system is needed to keep everything and everyone straight.
The Guardian’s style guide isn’t set up the way most online style guides are. For starters, there’s a hamburger menu in the top-left corner that allows users to navigate to the different sections:
Introduction
Even then, you won’t be able to discover what’s in each section until you scroll through them.
However, I think that’s intentional. The Guardian isn’t a single-column business site with a more-or-less expected or traditional format. As such, anyone trying to understand the structure and design choices of the site should consider them one by one, which the scrolling format of the style guide allows for.
This style guide is also a good example of how to take your digital product’s unique brand and apply it to your style guide. That way, the style guide feels like the living embodiment of the brand.
Workbench is Gusto’s design system. It’s minimally designed, fast to load and easy to navigate.
What’s noteworthy about this design system is that it doesn’t just stick with the typical parts of a design system. You know, the accordions and alerts, and form fields. There’s nothing wrong with including these common components and patterns. However, if your digital product contains other parts, they should be documented in your design system.
Workbench, for instance, documents things like:
It also has a robust Resources section at the bottom. So rather than only provide links to UI kits or templates, users will find all sorts of guidelines related to browser support, responsive best practices, special symbols and more.
Help Scout’s style guide is an interesting example. It starts with a whimsically designed and animated landing page that introduces users to the brand’s values and the driving principles behind its UI design. This is a crucial part of every style guide and the design of it gives users the space to really focus on it.
Once you’re inside the style guide, you’ll see that it’s pretty standard. It includes sections for the following:
There’s also a content style guide below the visual one. And below that is a section called Product Design. This section introduces users to Help Scout’s design system. Although we aren’t able to access the live, interactive design system, we catch glimpses of it and get to see how it helps the company achieve its goals.
Precor is a commercial fitness equipment company that has created this simple, straightforward style guide for its brand. It’s a single landing page that contains the typical information and presentation of visual guidelines for the logo, colors, typography, imagery and more.
A style guide like this isn’t just beneficial for the company or its designers though. Commercial retailers have lots of partners to think about. And if they’re all going to be using their logo, imagery and other branded elements within digital and physical marketing campaigns, then a style guide is the best way to ensure they use the right assets and make the right design choices.
While I didn’t include the whole page in the GIF below, the page includes lots of design examples for internal reference. It also includes logo partner lockups examples at the very bottom so that fitness facilities and even hotels know how to properly integrate the Precor logo within their own.
The Special Olympics brand guidelines page is a great one to look at if you’re wondering how to keep a huge brand with a global reach well-organized and documented. The main page breaks down the guidelines by languages, events, programs and more.
The one you see down below is the PDF of the English Brand Guidelines. This is a massive 92-page document that spends a good deal of time covering the brand’s history, mission, reputation, guiding idea, as well as how this story needs to be told visually.
While the style guide is indeed long, it’s well-organized, so users won’t have a hard time finding what it is they’re looking for. It’s not just the organization of the style guide that makes it easy to use. The table of contents at the front clues users in to what to expect. So they can skip ahead to relevant visual guide sections, examples and tips on brand management as needed.
I’m sure that Starbucks has an impressive design system that the company uses behind the scenes. Otherwise, the company wouldn’t be as well known for its consistently executed omnichannel marketing strategy in stores across the world as well as on its website and mobile app.
That said, this simplified style guide for the Starbucks brand is one that everyone should take a look at. At first glance, it appears to be your typical visual style guide with sections dedicated to:
Users will soon notice that the style guide is interactive. Not only can you play with some elements, but hover-triggered tooltips appear for each of the visual guidelines. So rather than clutter the UI with this information, it appears when users focus on the relevant elements.
What’s more, users can toggle between different design choices, like under the Logos section where they can change the color of whichever one they’re looking at. The Color section then explains when and where each color should be applied. It’s a really well-thought-out design reference.
It’s not just corporations and software companies that benefit from having a design system. National and local governments need them as well. The U.S. web design system, for instance, is meant to be a resource for designers and developers who build government websites and other digital products.
Unlike creative and commercial brands, a governmental design system isn’t going to be the most creative or attractive one to look at. That doesn’t make it a bad example to look at though. It includes everything a good design system needs:
I’d argue that, if this is your first time creating a web design system, this is the one to start with. Think of this example as a minimum viable product of a design system. You’ll get to see the simplest, most straightforward way of documenting a brand’s visual identity without all the fluff. Once you nail that down, you can add whatever pizzazz you want.
Style guides and design systems are essential parts of the modern design and development process. They serve as a single source of truth for product and marketing teams, allowing them to create consistent and scalable UI designs for anything they build.
Now that you’ve seen some cool examples, now it’s time to implement your own design system or style guide.
One way to do this is to build it from scratch, using an inspiring design system or style guide as a reference. Another option is to use the Progress Design System Kit. It’s based on Progress’s own design system, which you can see here:
With the Design System kit, you won’t have to spend time building out the foundation of your design system or style guide. Instead, leverage the UI component libraries, professionally designed themes and ThemeBuilder to customize as much or as little to your liking. Plus, you can edit it on a global or granular level.
]]>Hey there, Telerik and Kendo UI developers! We’re starting 2024 with a splash of color and innovation. Our team is excited to introduce a brand-new color system for Progress Telerik and Kendo UI Themes, which is not just an update—it’s a complete game-changer!
With Q1 2024, we’re rolling out a new Sass setting called $kendo-enable-color-system
for our dynamic new color system. You have the freedom to switch to this system whenever you feel ready. Fast-forward to May 2024, and this new system will become the default.
But don’t worry if you’re still fond of the old system—it’s just a setting away. We’re all about making transitions smooth and stress-free. That’s why both color systems will be available until Q2 2025, giving you more than a year to adapt at your own pace.
Welcome to a world where color customization becomes effortlessly unified! With our new color system for Default, Material, Bootstrap and Fluent themes, you can now manage your color schemes from a single, central location. This approach eliminates the need to juggle tens or hundreds of variables. Instead, you get a streamlined, unified control system for all color modifications.
This significant simplification means you can apply changes across various themes quickly and consistently, for a seamless design experience. Say hello to efficiency and goodbye to confusion!
Sass variables, meet CSS variables! With support for both Sass and CSS variables, now you can tweak your themes on the server or on the fly. Imagine effortlessly switching between light and dark modes—that’s the kind of flexibility we’re talking about.
Embrace the synergy of design and functionality! Our new color system for Telerik and Kendo UI Themes—encompassing Default, Material, Bootstrap and Fluent—is a boon for everyone using design systems. This unified approach to color customization aligns perfectly with design system methodologies, making it easier than ever to maintain visual consistency across your applications.
By centralizing color management, we’re simplifying the customization process and enhancing the cohesion between design elements and development practices. That is more than a feature—it’s a step toward a more integrated, design-centric development ecosystem. What team couldn’t use a more streamlined design workflow?
We’re not just changing colors but transforming how you work with Telerik and Kendo UI themes. Our goal is to get you excited about these changes, not overwhelmed. So, embrace this colorful journey with us and watch your projects shine brighter than ever!
]]>Creating modern and visually cohesive user interfaces that look and behave consistently across various platforms and devices is a challenging task. This problem can be tackled by introducing a design system that can be used as a blueprint for how interfaces should work.
In this article, we will explore the importance of a good design system and its core components. Furthermore, we will cover how to build a design system with the powerful Progress ThemeBuilder.
A design system is a detailed collection of guidelines, principles, patterns and assets. Developers, designers, product managers and other stakeholders can use it to create interfaces that are consistent visually and provide coherent behavior for all products and services across various platforms and devices.
It can have a significant impact on how users perceive products and the brand. What’s more, it can play an essential role in differentiating from competitors and establishing a recognizable identity for the brand and its offerings. A good design system can help users recognize the brand behind products and reinforce positive memories and experiences.
Besides consistency and recognizable UI and UX, a design system improves efficiency since it’s easier to avoid reinventing the wheel. The existing components can be used in new projects, so there is no need to spend time figuring out how things should look and work in a project.
Moreover, having a centralized design system helps with maintenance and reduces the risk of inconsistent UIs. In addition, it can aid the onboarding process of new team members since it can be referred to as documentation for the company’s design and development standards.
A design system can consist of several components depending on how thorough and complex it is. However, here are a few core components that design systems can comprise:
The style guide covers branding elements, such as typography, color palettes, spacing, grid layouts and more.
A component library comprise the building blocks of a design system. It should contain reusable components, such as buttons, form fields, layouts or dialogs. These components should be built based on the design system’s style guide and design principles.
UI patterns specify the solutions to common design challenges. For instance, what approach should be used to build and handle a navigation menu on mobile devices? Should an application use a top or bottom navigation bar or should the navigation links be hidden in a drawer instead? If a drawer, then how should the drawer be opened? A very common solution for this problem is the use of the “hamburger menu,” which comprises a button with multiple lines that look like a stacked hamburger. UI Patterns ensure that interfaces use a consistent approach to the same problems.
Design principles provide the basic ideas behind design choices. The principles ensure the design system has a consistent design style throughout. These might comprise focus on light, depth or size.
Documentation is the instruction manual on how to understand and use the design system. The documentation should cover how different parts of the design system should be used individually or combined to create richer experiences. These could comprise implementation details and code examples.
Desgin tools are a collection of tools that is used to create and maintain the design system. For instance, a company might use an application such as Figma, Adobe XD or Sketch for creating designs and StoryBook or Zeplin to maintain the design system in an interactive manner.
In a nutshell, a design system covers visual look and functional behavior. It speeds up product iteration, makes the design and development process faster and ensures everything works in the same manner on different platforms and devices. In the next sections, we will have a look at how to take advantage of Kendo UI to build a design system.
Kendo UI is a comprehensive bundle of UI components built by the Progress team for four major JavaScript UI libraries—React, Angular, Vue and jQuery.
Each version provides many feature-rich components with consistent API, visual styles and behavior. The components offered by Kendo UI can cover the needs of many applications, and they span various features, such as buttons, icons, grids, layouts, charts, form fields, dropdowns and much more.
The fact that Kendo UI supports multiple UI libraries means even teams that use micro-frontends and utilize different solutions can still develop user interfaces that match visually and behaviorally.
Kendo UI offers five beautifully crafted UI themes:
You can pick one and immediately start coding. Kendo UI even provides Figma UI Kits for each of the themes, which you can use to create your own styles and designs in Figma using the provided style primitives.
The default themes are excellent, but if you need more customized styles, Kendo UI has the ThemeBuilder to meet your needs.
ThemeBuilder is a powerful Telerik and Kendo UI tool that can be used to create styles for UI components. To use it, we need to create a new project and choose the base theme we want to work with.
After creating a new project, we are redirected to the ThemeBuilder dashboard. We are immediately greeted by a helpful tour guide that can walk us through various features of the ThemeBuilder.
The main content showcases a live preview of all UI components present in the theme.
On the left side of the dashboard, we have a sidebar with theme styles, such as typography, color palettes and effects. In the theme selection process, I picked the Fluent Theme, so all components utilize the default Fluent styles.
Whenever any of the styles are changed, the ThemeBuilder refreshes the UI and renders all components with the latest styles. The GIF below shows how all components change colors when the primary style is modified.
The main content, by default, shows the live preview, but we can also switch to the “Advanced Edit” mode, which will allow us to click on any of the components to get access to detailed styling customization for each component part and state.
The Advanced Edit Component View consists of three main parts:
A lot of the features in the ThemeBuilder are free, but some of them require a paid plan subscription. For instance, the “Detailed Styling Customization” we just covered in the previous section requires the ThemeBuilder Pro plan. The ThemeBuilder also offers a very useful feature that allows importing styles and fonts from Figma. You might have spotted the “Import Styles from Figma” notification at the top of the left sidebar.
The Progress team built a Figma plugin that can be used to automate theme generation by exporting styles and fonts from Figma. The exported assets can then be easily imported into the ThemeBuilder and used to style components. This feature requires the ThemeBuilder Ultimate plan. Besides the free tier, there are three plans in total—Pro, Ultimate and Enterprise. You can find a detailed pricing plan comparison here.
When your theme is ready, you can click on the big blue Export button at the top right of the application. It will download a zipped file with the following structure.
.
├── theme/
│ ├── dist/
│ │ ├── css/
│ │ │ └── theme.css
│ │ └── scss/
│ │ ├── _overrides.scss
│ │ ├── _tokens.scss
│ │ └── index.scss
│ └── package.json
└── README.md
The README.md
file describes how the theme should be added to a project. In the dist
directory, we have css
and scss
folders. If you’re using Sass in your project, then you should import the dist/scss/index.scss
file. Otherwise, you should import the theme.css
file.
Note that since those files are generated, they should not be modified directly. Instead, they should be treated as read-only files. Any further modifications should be done in the ThemeBuilder, and the theme should be exported again.
In this article, we have covered the importance and building blocks of design systems, including style guides, component libraries, UI patterns, design principles, documentation and design tools. Further, we delved into Kendo UI and its unique features, such as themes, Figma UI Kits and Progress ThemeBuilder.
ThemeBuilder, equipped with advanced customization options and a live preview, enables us to create themes that perfectly align with our requirements. Moreover, we covered practical aspects, including the pricing structure of ThemeBuilder plans and how to export a theme to integrate it in a project. Equipped with the new tools, we can enhance our design workflows and create more cohesive and efficient user experiences.
]]>You might already know about all the amazing customization options the Progress ThemeBuilder offers in terms of colors, padding, effects like border radius and drop shadow, and more. But did you know that you can also import your own fonts and icons as well, for a truly personalized look?
If your brand style guide specifies the use of a licensed font or if your design team has invested in the creation of custom icons, you can still seamlessly integrate those assets into the theming of your component library—and export production-ready code!
ThemeBuilder already includes access to a collection of standard, familiar fonts to use in your typography system. To change the default font used across the entire component library, just update the $kendo-default-typography
variable in the “Typographies” subsection of the Theme Styles sidebar.
However, if you’ve fallen in love with a beautiful Google font or invested in a specific licensed font family, you can absolutely use those as well! To import a font, just take the following steps:
Once it’s been moved from Pending Fonts to Uploaded Fonts, we know it’s ready to use in our design. Now, when we update the default font (or any other typography option), we’ll see our custom font in the Font Family dropdown options list.
We can also make use of the Upload Font process to add custom icon sets as well! Just export your custom icon set as an icon font or download the icon font for your preferred library.
For example, let’s say we want to use popular icon library Font Awesome in our project. I’ll download the free OTF files from the Font Awesome downloads page, then open up ThemeBuilder and follow the same process as above—just make sure the set the Font Type as “Icon.”
Then, to change out an icon, click on a component and open the Advanced Edit panel. In this example, I’ll change out the icons in the Slider component. Then, take the following steps:
Select the icon
from the Component Parts pane in the top right corner of the Advanced Edit sidebar.
Open the Text subsection. Click the typography icon on the right-hand side to switch to “Set Local Text Properties” if you haven’t assigned the new font as a variable in Theme Styles.
Choose your uploaded font from the Font Families dropdown.
Click the gear icon in the bottom right of the Text panel to open the icon selection menu.
Choose a new icon from the icon selection panel.
Make any necessary text size or spacing adjustments.
And just like that, you can apply your own custom icon set to change the look and feel of your components in ThemeBuilder. Here’s a before and after, showing the default Slider icons and the updated ones using the Font Awesome library.
As you can see, it only takes a couple minutes to get custom fonts and icons loaded into the ThemeBuilder and ready to use in your project! Try it yourself with our free 7-day trial, and check out our docs for more ways the ThemeBuilder can make styling your component library fast and easy!
]]>There are so many reasons why creative agencies and studios should take a collaborative approach to design and development. Collaboration within and across teams allows you to:
The key to successful collaboration is to remove the internal friction that slows things down—in particular between design and development. In this post, we’re going to look at five things your agency can do to empower each person to play to their strengths while simultaneously working faster and more effectively together.
Everyone on your team is working toward the same goal—building great products for your end users. To make your product development process go more smoothly, here are some ways to reshape your systems, tools and overall process.
If we were to simplify the product development process that some agencies use, it might look something like this:
The first part of the project is all about design. Developing the UI and hashing out the interactivity of the product. The design team then hands off their work to engineers who turn the great-looking concept into a working usable product.
Here’s the problem:
This is like bringing in a relief pitcher or backup quarterback who’s been hanging out in the locker room throughout the game. Sure, they’d have the skills and talent to participate, but they’d have no idea what happened along the way, what the pace of the game has been, what the competition has been playing like, etc.
It’s hard to jump in at that point and to participate at your level best—in any arena.
While it’s true that developers don’t need to play a major role in the early stages of a job, they shouldn’t be silently waiting on the sidelines or behind the scenes. They should be involved at key stages where their input would be beneficial. For instance:
The same goes for designers. Just because they hand off their work to the development team doesn’t mean they should completely wipe their hands of a job.
The ideal product development process should look something like this where the design and development teams work in tandem:
It’s all about bringing other teams into the process when they’re needed most. A seamless handoff is also key to the execution of this process.
So whether you’re creating a new project process or looking to optimize an existing one, go for the collaborative design and development approach. Your team members will find that things go much more smoothly along the way if they’re not waiting to be called in to address errors, emergencies and the like.
It’s not enough to create a collaborative process. Find a project management platform that your whole team (as well as clients) can use to:
Project management systems ensure that everyone on your team has real-time access to the status of any given project and their associated responsibilities. So even if the job goes off the rails at some point, team members will receive updates and can prepare accordingly.
Accountability is an important part of collaboration. And a project management system equips everyone with all the information they need to get a job done and the tools to work with others to achieve their goals, as well as empowers them to take responsibility for their portion of the job.
Notice that I didn’t say “make communication a priority.” That’s because communication without a purpose ends up being a waste of everyone’s time.
If your goal is to improve design collaboration, then you need a plan and tools to help you implement a system of high-quality communication.
The project management app will be useful in this regard as it’ll give your teams a place to discuss the project within the actual context of it. Not all of the communication between design and development can take place in a chat-like format though. Having a structured plan for meetings and real-time collaboration is important too.
As you lay down your product development process, collaborative team meetings should be included. For instance, certain occasions and milestones should call for design and engineering to come together:
Also, if the scope of the project changes at any point, everyone should be brought together to review the change request. The same thing goes for any negative feedback or issues that bring a halt to the job’s progress. Even if developers aren’t working at these earlier stages, it’s best to keep them informed.
Just be careful about how many meetings you schedule and who you invite to them. Both teams should come away from each meeting feeling like they got something out of it, that they remain clear on what needs to be done and that everyone is in sync.
One of the biggest hurdles to collaboration is language. Specifically, the language of design vs. the language of coding.
Going back to the sports metaphor once more, imagine that a baseball pitcher is sending signals to the catcher. However, the catcher has no idea what any of the signals mean. They might eventually catch on when they see how the pitcher is winding up, but it might be too late then.
That said, no one is saying that a developer needs to learn everything there is to know to be an adept UI designer. Or vice versa. However, there needs to be something that bridges the divide so that, when the two come together, they completely understand each other.
The design system is the perfect solution.
Take the Progress Design System, for example. It is a digital resource that details the following:
One reason why a design system is so beneficial is that it spells everything out. There can be no confusion about which color to use, which button style to apply or which theme to start from.
From the designer’s point-of-view, the design system gives them less to worry about in terms of building the product from the ground up. Instead, they can focus on the more creative aspects of designing an app as well as creating the perfect user experience.
From the developer’s point of view, the design system ensures that the designer works with the right components and libraries. What’s more, that they have guidelines that help them consistently use and style those components. This means less clean-up and correction needed during development.
In order for this to be the outcome, your design and development team will need to collaborate in creating and maintaining the design system. If you’re looking for an easy way to create your own, check out the Design System Kit.
In the not-so-distant past, it was up to the designer to lay out the design specs and redlines prior to handoff. This allowed the designer to translate their design work and choices into a language/format that made sense to the developer. The developer then reviewed the specifications and implemented them as they built out the app.
That whole process—the redlining, handoff and implementation—took a lot of time. And there was no guarantee that something so manual wouldn’t create additional errors during implementation.
Rather than force the design and development teams to spend all that time translating and interpreting each other’s work, it’s a better idea to use tools that simplify the handoff instead. In addition, they shouldn’t force your teams to find completely new design or development tools to work with.
For example, Progress ThemeBuilder enables designers to import their files from Figma. ThemeBuilder also allows designers to export their completed designs, components and styling as CSS or Sass files to hand off to the developer.
ThemeBuilder has other useful applications. Think of it as a living version of your design system. You’ll be able to save your theme, set global styles and customize as many components as you like from there.
In addition, let’s say that a change is needed late in the game. The developer has finished things up, the product has made it through QA with flying colors, but the client wants to tweak a color or the look of a button. There’s no need to go through the product, page by page or screen by screen, to make those updates.
With ThemeBuilder, it’s easy to update styles and values of even the most granular of components. The exported file can then be loaded into the application for automatic updating.
While collaboration might seem tricky to maneuver when it comes to design and development, the key is to stop thinking of your teams as design vs. development.
If you truly want to maximize your outcomes, then design and development must work like a unified team instead of as individuals. After all, everyone is working toward the same goal—to build high-quality digital products for your end users.
As you can see above, there are simple enough ways to improve design collaboration and handoff. Rework your processes, invest in the right tools and make sure you have systems in place that enable conversation and collaboration.
]]>You might already be familiar with some of the beautiful, pre-designed themes for Telerik and Kendo UI components, but did you know that Progress also offers an end-to-end design language for creating your own custom look and feel? The Progress Design System documentation is an indispensable resource for anyone—developer or designer—who wants to use one of our component libraries as the basis for their own design system.
Here’s what’s included:
If you’re a design beginner, fear not—the Foundation resources will guide you through several crucial design concepts that you’ll need to understand in order to build a design system.
The documentation offers high-level overviews in simple and clear language, covering everything from color and typography to globalization and accessibility. Dive into the Foundations sections and get comfortable with design terms and basics before putting them to work in your design system!
Once you’re feeling comfortable with the basics, let’s take it to the next step—theming! The Themes section covers the pre-made Telerik and Kendo UI themes as well as multiple ways to customize themes to create your own visually distinct UI. This includes everything from technical guidance (like installing the various npm theme packages) to design guidance (like accessing the Figma UI Kits) and links to framework-specific documentation.
The Telerik and Kendo UI CSS Utilities are utility classes that allow you to build custom layouts without writing CSS. Each utility class changes the appearance of the target element by applying a specific CSS rule. For example, to round
the corners of an element without writing any CSS code, we can add the k-rounded-md
class to that element and the utility will apply the styles. It’s an incredibly powerful tool that can really speed up your
development time!
All the various CSS utilities are documented here, organized by type in the left-hand sidebar.
Of course, every component in our Telerik and Kendo UI component libraries has framework-specific documentation—but that documentation primarily focuses on implementation from a development perspective. The framework-specific documentation is great for questions about component APIs, properties, data binding and the like.
The Design System Components documentation, on the other hand, brings a unique design perspective: It focuses on component appearance, user interaction states, anatomy and visual customization options. The Design System component documentation is also universal, since all of our components look and behave similarly across framework libraries—allowing you to create cohesive and intuitive applications, even if they don’t all use the same language!
For information about content beyond components, check the Resources section. This covers things like our font and SVG icon libraries, the amazing Figma UI kits, links to our free learning courses and community forums, and more! Whether you’re looking for downloadable assets or a little extra help, the Resources page has you covered.
Building a design system can feel intimidating, but with the right tools it doesn’t have to be! There’s no need to reinvent the wheel when you can start with our robust, accessible components and customize them however you like. Whether you’re working on your own or collaborating with designers, the Progress Design System empowers you to create beautiful, unique visual identities for your applications.
]]>Collaboration between designers and frontend developers is crucial for delivering successful web projects. However, communication gaps and misalignment can sometimes arise due to differences in (technical) language, tools and perspectives.
In this article, we’ll explore some practical tips and strategies from a frontend engineering perspective to improve collaboration in design-development workflows.
As a frontend engineer, being involved early in the design process can significantly improve collaboration throughout the design and development workflow. The developers on the team often have valuable technical expertise and can provide input on the feasibility and technical considerations of certain design decisions.
For example, input and additional thoughts can be provided on the performance implications of certain design elements, such as complex animations or heavy image assets. In addition, insights can be offered on topics such as cross-browser compatibility, accessibility and other technical considerations.
By having frontend engineers included in the early stages of the design process, designers can benefit from these important insights and ensure that designs are implementable while being aligned with the technical constraints of the frontend codebase.
Design collaboration tools can greatly streamline communication and collaboration between designers and frontend engineers. Tools such as Figma and Sketch allow designers to share design assets, generate style guides and provide specifications, making it easier for frontend engineers to understand and implement the designs accurately.
Design collaboration tools allow designers to create design components that can be easily shared with frontend engineers but also provide features like design versioning, design annotations and design comments that facilitate communication and feedback between designers and frontend engineers. Frontend engineers can then use these tools to inspect design assets, generate code snippets and export assets, which can speed up the development process and ensure accuracy during development.
Documenting design guidelines and best practices can help maintain consistency in design implementation. Frontend engineers can contribute to this by creating and updating design guidelines while ensuring that they align with the technical constraints and requirements of the frontend codebase.
For example, design guidelines can include specifications for design components, such as typography, color schemes, spacing and layout. It can also include guidelines on accessibility, performance and other technical considerations.
Documenting design guidelines can serve as a reference for both designers and frontend engineers, helping them stay aligned and ensuring that the design system is implemented consistently across different parts of the application or website.
Facilitating testing sessions during the development process (and before launch) can be a valuable approach to further enhance collaboration between frontend engineers and designers. Testing sessions can be done through various methods, such as regular team meetings, video conferences or collaborative tools that allow for real-time feedback and issue tracking.
During testing, designers can provide feedback on any design-related issues that may affect the user experience or overall aesthetics of the product. Frontend engineers can then identify and fix any bugs or inconsistencies in the implementation of the design, ensuring that the final product is visually appealing and functions smoothly.
Testing sessions allow both parties to identify and address any issues or inconsistencies early in the development process, ensuring that the final product meets both design and technical requirements before the project is launched to users.
Regular communication is crucial in maintaining alignment between designers and frontend engineers. Establishing clear channels of communication and encouraging regular check-ins and updates can ensure that any issues or concerns are addressed promptly, avoiding delays or misinterpretations.
For example, teams can schedule regular stand-ups, design reviews and feedback sessions to discuss the progress of the design implementation, address questions or concerns, and provide feedback. These regular communication practices can help identify and resolve any misalignments or issues early in the development process, ensuring that the project stays on track and meets its deadlines!
Practicing empathy and understanding toward other roles and perspectives is fundamental to successful collaboration. Designers and frontend engineers have different areas of expertise and perspectives, and it’s important to respect and understand each other’s viewpoints.
Designers may prioritize aesthetics, usability and user experience, while frontend engineers may prioritize technical feasibility, performance and maintainability. It’s important to always aim for a middle ground where both perspectives are considered and integrated into the final product. By finding this middle ground, teams can collaborate more effectively and create products that are both visually appealing and technically sound.
Successful collaboration between designers and frontend engineers is crucial for the effective implementation of design systems. By following the practical tips and strategies shared in this article, such as being involved early in the design process, using design collaboration tools, documenting design guidelines, communicating regularly and practicing empathy, teams can bridge communication gaps and deliver products that meet both design and technical requirements, resulting in a successful outcome for a project.
]]>When designers hand off their Figma mockups to developers, there are a few main things that developers are trying to take from those files:
The first two can usually be picked up pretty quickly as the developer explores the Figma file and plays with the prototype. It’s the third one—all those little values that need to be copied over—that’s the most tedious.
In Figma, those values are captured as “design tokens.” Depending on the scope of the design, there could be anywhere from just a handful to well over 100 design tokens in a single file! This is especially true in the case of design system documentation, where the design team will have created a great many of these design tokens to capture every possible interaction state of every single component.
For example, the Kendo UI Figma Kit includes 150 different design tokens that capture every aspect of the UI look and feel: drop shadows, gradients, colors, typography, borders, focus and hover state effects, and so much more!
We need those design tokens to become CSS variables. Moving those values manually from Figma into our stylesheets is painful … to say the least. Thankfully, there’s a better way.
Progress ThemeBuilder not only allows us to import the variables from Figma, it also gives us a real-time preview of how the components will look in the Live Preview panel! When we apply the imported design tokens to our Theme Styles in ThemeBuilder, the components in the Live Preview will immediately update to reflect those changes across the entire library. That gives us the opportunity to do a quick visual check against the Figma file and ensure that the components look the way the designers intend them to look.
To take advantage of this, we need four things:
Let’s assume that we already have an application using KendoReact. Our design team has a Figma file where they’ve created a new look and feel for the application UI. They’ve sent us the mockup, and it’s our job to implement those styles in the app.
The first thing we do is install the ThemeBuilder Figma Plugin by clicking the “Try it out” button in the top right corner of the Progress ThemeBuilder page in the Figma Community. This will add the plugin to our Figma account, so we can access it in all of our files.
Then, we open the Figma file sent by the design team. We can run the plugin by clicking on the Add-Ons button in the toolbar, switching to the Plugins panel, and selecting Progress ThemeBuilder from the list.
When the ThemeBuilder Plugin is open, click the “Run” button and select “Export Styles” from the dropdown menu. We’ll be prompted to log in to ThemeBuilder.
When we return to Figma, our available ThemeBuilder projects will be available for selection in the modal window. Choose the project for import, and click “Select.”
Then, we’ll be shown a list of every single design token in that Figma file. They’ll all be selected for export by default, but we can customize that if (for example) we only want the colors and not the typography. In this case, however, we would want everything, so let’s leave it all checked and click the “Export” button.
In just a few seconds, the export will run and we’ll see a confirmation message telling us that the export was successful!
If we follow the “Open in ThemeBuilder web app” link, we’ll be taken to our ThemeBuilder project where the Figma design tokens are now visible in the left-hand Theme Styles column. All the imported styles will have a “--figma” prefix, so we can easily tell them apart from any styles we might have created earlier.
Then, we just assign those new Figma design token values to our existing theme styles! Note how the updated color is immediately applied to the components in the Live Preview.
When we’ve assigned all the variables and are happy with how the new styles are looking, we can use the Export tool in ThemeBuilder to export application-ready CSS that captures all the changes we made.
Just like that, we updated the design of our entire component library to match the design team’s mockup—without writing a single line of CSS!
If you aren’t already using a Telerik or Kendo UI component library, you can try one out completely free for 30 days. Same goes for ThemeBuilder—try it free for a week and see just how easy it can be to theme, adjust and export styles. Each tool is powerful on its own, but together they make the perfect team for bridging the gap between design and development!
]]>In the previous post in this blog series, we discussed the first steps for implementing the groundwork of a successful design system: choosing a library, setting up our global CSS file and defining our design tokens to coordinate with the design team. Now, let’s talk about using those smaller pieces to build larger, reusable components.
What good are all those design tokens if we don’t start applying them to components, right? Ideally, the bulk of our design system implementation is done via these tokens in the form of variables that get used in the styling of the components that we build. That means that our component-scoped styles will look something like this, with the majority of the styles being imported and applied from the global CSS using the design tokens and only a few specific, unique values set manually:
.card {
border-radius: $borderRadius;
background-color: $primaryBG;
border: $border;
filter: $dropShadow;
padding: $basePadding;
max-width: 50%;
}
The component library is the part of a design system that developers are usually most familiar with already, so we won’t spend too much time here. For anyone who’s interested in a deeper dive on creating their own component library, check out this earlier series by TJ that breaks it down into some excellent, actionable steps. Not to mention, there are some fantastic tools out there, like Storybook, that offer tons of resources to make component library creation, maintenance and testing a breeze.
Instead, let’s talk about some more specific aspects of component library maintenance in relation to their position within a larger design system: coordinating with designers and building pattern libraries and templates with our components.
One of the most effective ways for developers and designers to stay in sync on component design and functionality is via Figma UI kits. A good Figma kit will include a breakdown of every single component in a library, including all design tokens and various interaction states for each component. We’re already familiar with all the ways in which a component library can be beneficial for developers: they help build in accessibility, speed up development time, offer UI and interaction pattern consistency for users, etc. With a Figma kit, designers can enjoy the benefits of all those things as well—with a few additional perks!
Developers are often most comfortable working directly in code, but designers spend most of their days working in design software. For a design system to work, we need to eliminate the barriers of access that make it harder or less intuitive to use—that means that nobody should have to learn an entirely new set of skills in order to use the design system. Designers should be able to work where they prefer to work, as should developers.
By offering an exact, one-to-one replica of the component library in the workspace that designers are most comfortable with, they’re able to take a deep dive into the components from a design perspective. This not only enhances a designer’s understanding of the components and how they function, it also makes it much easier for them to adjust the style of the components to match the design system because they can see all the components in one place.
Often, component library documentation splits up each component, allowing developers to focus in on the details of each one individually. While that makes sense for a development approach, designers more often need a birds-eye view, allowing them to see and understand how all the components look together within the shared design system styles.
With Figma kits, designers are empowered to do things like adjust design tokens and know exactly how that will map to the variables on the development side, communicate complex user interface ideas to developers via pixel-perfect mockups (and offer those mockups for developers to inspect with the Figma Dev Mode), and create new page or feature prototypes for early-stage user testing—just to name a few.
Designers can maintain the design system core files in Figma and share them with the development team via export tools. For example, the Kendo UI Figma Kit design tokens can be imported into ThemeBuilder Pro via the ThemeBuilder Figma plugin. This allows for easy translation of the design system from Figma into CSS.
Then whenever the design team needs to make an update to a design token, they can do so in Figma and just let the development team know—when the dev team re-imports the variables, it will automatically update any components those tokens were applied to in ThemeBuilder. The dev team can then simply re-export the ThemeBuilder CSS, replace the global CSS file in their app and see the design team’s updates applied across the entire component library—just like that! There’s no easier way to keep a component library in sync.
Once we have a component library with our design system styles applied, it’s time to start putting those lego pieces together into reusable chunks. Many applications and websites reuse more than just individual components—those components most often get combined to create specific interaction patterns that repeat throughout the interface. This approach is generally based on Brad Frost’s Atomic Design approach (which, if you haven’t read, you absolutely should).
For example, maybe we repeat a pattern of components along the bottom of several different types of articles on our website: a specific layout of the author photo and information, cards with other suggested/related articles and icon buttons for sharing on social. The pages for these articles might not always look the same, but that section at the bottom is consistent. That’s a pattern that we can capture and reuse in the same way that we do with the individual components themselves.
Image from https://atomicdesign.bradfrost.com/chapter-2/
In general, we want to think of these as separate to components, because they tend to be larger and more complex. The line between what constitutes a complex component vs. what constitutes a pattern can be fuzzy and is ultimately left up to the discretion of the developers and designers building the design system.
Personally, I think of components as elements with one specific goal, whereas patterns could have several. For example, I would consider a text input + button lockup to be a component since there’s only one thing a user can do with it (submit text). However, I would consider the previously described article footer lockup to be a pattern, since the user could click on a related article, contact the author or share the article on social. Once again, though, this is not a hard and fast rule—just my personal approach to building and organizing design systems. Ultimately, the only important part is that the entire team understands and agrees upon a single definition.
A page template, on the other hand, is much clearer—it’s a reusable layout of components and patterns for an entire page. These are especially useful for websites or applications that have many pages that will need to be visually similar but offer different content: documentation libraries, blogs, store product pages, and similar. While the content of those pages might not always be exactly the same, a template will ensure visual consistency across them all.
For example, a product page might not always have the same number of photos, the same length of description, the same number of product options, etc., but we still need all product pages to look cohesive. By creating a template, we can accommodate the most basic and extreme situations—and save ourselves the time and energy of recreating work/re-solving problems.
Image from https://atomicdesign.bradfrost.com/chapter-2/
Perhaps one of the greatest benefits of using a pre-made component library is being able to leverage the expertise of a whole team, without having to hire a whole team. This really shines in the world of accessibility, where not everyone feels completely comfortable or considers themselves an expert—and yet, creating an accessible application or website is truly non-negotiable.
While using a third-party component library doesn’t let you completely off the hook on accessibility testing, it does greatly reduce the workload. It’s both reassuring and a time-saver to not having to worry about doing this yourself, because someone else has put in the time and research to craft an accessible experience for your users. When you’re building with accessible core components, a lot of the accessibility work happens “for free.”
That being said, there’s more to a design system than just the components. When choosing colors for design tokens or various UI elements, it’s important to make sure they meet an accessible standard for color contrast. The WCAG (Web Content Accessibility Guidelines) defines three levels of color contrast ratios—failing, AA and AAA. AA level means the colors have enough contrast to be readable, but might still present problems for some users. AAA level means that we have achieved extremely high contrast that should be readable for the vast majority of our users. We should always aim for AAA compliance, but making sure we’re not failing is the bare minimum.
Another important aspect of accessibility and color is ensuring that we’re not communicating any information through color alone. This is a dangerously easy trap to fall into, unfortunately—especially with things like forms, data visualization and confirmation/cancellation dialogs. Make sure to review the components, patterns and templates with the design system styles applied to confirm that there’s always an icon or text supporting any color-coding.
When it comes to making accessible layouts and interactive UI elements, it’s good to leave some—literal—room for error. When buttons and other “click zones” are too small, they can be difficult to accurately target and interact with. We want to ensure that the padding we define for input fields, buttons, icons and more all make them take up enough visual space that the user isn’t working with a prohibitively small target.
Finally, consider the text styles. Setting a large enough text size is step one—16 pixels is the standard recommendation size for body copy. More important than the default size, though, is how users can adjust it. Having a built-in text adjustment in your settings is a nice touch, since that will allow a user to increase the size of the font without affecting the other elements on the page … but, since that’s rare, we also have to think about what happens when a user increases the zoom on the page via the browser tools. If zooming in breaks our components, patterns or templates, then it’s back to the drawing board.
Thankfully, Storybook has a bunch of great add-ons that will make accessibility a natural part of design system implementation and component design. I highly recommend
addon-a11y
. It’s probably the most popular and beloved Storybook accessibility add-on—and for
good reason! It’s packed with great features, and it runs on the well-known Axe Accessibility Engine.
The Accessibility panel that this component adds is one of the best and easiest ways to test as we work in Storybook. Each time the component loads, it will check it against the WCAG, and we can make the changes while still in the build phase, rather than finishing a component completely and then having to go back and try to retrospectively make it accessible. Each violation that appears will have a “more info” link to the WCAG website, where we can learn more about the guideline that your component hasn’t met, and how to fix it.
The vision simulators are also incredibly useful, as a way to literally see what our users will see when they use our UI. These are great for checking font size, density, contrast and color choices. Sometimes it can be hard to put ourselves into the shoes of our users, but this tool makes it literally just a click away.
The aria-live-storybook-addon
is also a handy one to add—it adds a new panel to the drawer called “Aria
Live Regions,” which will show any time an action triggers an aria-live
announcement, as well as whether it’s polite or assertive. This way, we can confirm that announcements are triggering correctly when
new content is added to the page, and that the correct type of announcement is being made.
Finally, storybook-addon-psuedo-states
allows us to quickly toggle through all possible element pseudo
states from the Storybook menu bar. This add-on basically duplicates the functionality of the “Toggle Element State” tool from DevTools, but without us ever having to leave Storybook.
Pseudo states are incredibly important for accessible development—especially the
focus
and focus-within
states. Any users who use a keyboard as their primary method of navigation will need a clearly visible focus in order to find their way around. Some elements,
like buttons, inputs, etc. have focus states built in—but occasionally, we’ll need to add a focus state to something that doesn’t automatically have one.
Most design systems include new styling for the focus state, since the default blue highlight doesn’t usually match … well, anything. Being able to easily design, develop and test these within Storybook is a huge advantage. This is also hugely useful for checking colors and contrast on your hover, active and visited states. Remember: if we have a button that’s only clearly readable in some—but not all—interaction states, then we don’t have an accessible button!
As I hope you’ve seen from these two articles, design systems happen just as much on the development side as they do on the design side—don’t be fooled by the word “design” in the name! For a design system to truly be integrated and applied to an application, it needs to live in the codebase as much as it lives in the design software.
Thankfully, we have lots of tools—like Figma, Storybook, the Kendo UI component libraries and the Progress Design System Kit—to help us bridge that gap and make sure we’re keeping things in sync. When we embrace the use of a design system, it doesn’t take long for both us and our users to see the benefits in our website or application.
]]>In the same way that many developers make the (incorrect) assumption that there’s nothing useful for them in design software and tooling, many designers also mistakenly assume that there’s nothing of value to them when it comes to developer-focused software and tooling. In truth, both parties will benefit if they’re willing to step outside their comfort zones and explore!
The Progress Telerik and Kendo UI component libraries are a great choice for developers and designers who are looking for ways to create unique and beautiful user interfaces. We offer a vast array of design-focused resources for designers who are either working with one of our Telerik or Kendo UI component libraries themselves or collaborating with a development team who does. From documentation to Figma resources and no-code theming software, let’s take a look at what’s on offer for designers using the Telerik or Kendo UI systems.
Many of the designers working with our component libraries are heavily customizing the component UI—and that’s fantastic! Some even take it a step further and integrate a Telerik or Kendo UI component library into their greater design system.
While some other component libraries take a strongly opinionated design approach that makes it challenging to overwrite the UI with custom styles, Telerik and Kendo UI component libraries place a primary focus on supporting unique theming and styling.
We believe that a strong component library is a flexible one—bend as much as you want, we won’t break! Reap the benefits of advanced functionality, tested accessibility and intuitive user experience … combined with a library that’s so easy to completely transform visually, your users will think you built the whole thing from scratch.
Of course, a design system doesn’t just magically happen—it takes a lot of research, planning, work and maintenance on the part of the designers. We can’t remove all of that, but we can make it significantly easier with our Progress Design System documentation.
In addition to our framework-specific technical documentation, we also offer documentation that’s intentionally design-focused. From guidelines for creating your own iconography (and then seamlessly exporting it from Figma) to detailed wireframes for component anatomy, you’ll find all the information you need to completely restyle our libraries and blend them seamlessly with your design system.
Of course, what good is an advanced component library on the dev side if design is still having to recreate everything in their primary workspace—Figma? We believe that design and development are two sides of the same coin; tools that benefit one but not the other aren’t worth investing in. A good Figma UI kit enables designers to quickly create mockups, build new custom components or create pixel-perfect prototypes for user testing.
Our Figma UI Kits are built using the atomic design system methodology and using Figma components + auto-layout. This makes them incredibly easy to work with—add layers, change alignments and more. Make changes to the base components and see it automatically versioned out across the whole library!
They also include variants for all component user interaction states, so you don’t have to guess what will happen when users click, expand, hover or tap. And, of course, the design token support to enable a flexible, consistent and easily maintainable design system.
Last, but certainly not least, Progress ThemeBuilder is WYSIWYG styling software that allows designers and developers to collaborate in the same environment—at the same time—to customize components. ThemeBuilder enables teams to style everything from top-level elements to granular adjustments (such as the padding or font size within a specific component).
To make it even more streamlined, design tokens and icons can also be imported into ThemeBuilder from Figma—and CSS / SASS can be exported from ThemeBuilder! Import tokens from the design file, assign the variables and see an immediate visual preview of the new component UI, then export application-ready stylesheets that capture all the changes … without ever writing a single line of code.
At Progress, we understand and value the crucial role that designers play in website and application development. Telerik and Kendo UI component libraries combine form and function, offering over 100 intuitive and feature-rich components that are all highly customizable and made with the developer—and designer—experience in mind.
Documentation for everyone, tools that meet you where you prefer to work, and software that makes editing, previewing, sharing and implementing design changes easier than ever before! What’s not to love?
If you aren’t already using a Telerik or Kendo UI component library, you can try one out completely free for 30 days. Same goes for ThemeBuilder—try it free for a week and see just how easy it can be to theme, adjust and export styles. Together, our tools make the perfect team for bridging the gap between design and development!
]]>So, your team has decided to implement a design system. Cool! You’ve heard the long list of benefits, the design team has sold you on how great it’s gonna be, and you’ve totally bought in. You sit down at your keyboard, ready to make things happen, but that’s when you pause … nobody has discussed how this design system will actually get implemented. You’ve seen the Figma kits, the style guide and the written documentation—it all looks great, but it’s not code.
For a design system to truly function, it needs to be an inherent part of the codebase. Making a design system easy to use is an integral part of adoption—it needs to function as a natural extension of the existing workflow. With tools like Figma, design system tokens, components, icons and more can all be built right into the flow of a designer’s primary workspace … but what does that look like for a developer? Let’s break it down.
One of the primary benefits of a design system is the way in which it can improve the cohesiveness of our user interfaces. When everything is styled the same way, it becomes easier for users to find their way around our website or application and more accurately anticipate how elements of the UI will behave.
This makes our interfaces intuitive and reduces the friction of new user onboarding and introducing new features. Not to mention, it speeds up the design and development process as well—when we can lean on a library of existing patterns and don’t have to re-invent the wheel every time we add something new, we can move a hell of a lot faster.
The heart of our design system implementation in the codebase is our global CSS file. This file will include all the basic styles required to build our components, so we can simply import it and call on our library of classes, variables, etc. when styling a page.
Any styles specific to the page, component or other element should go in a scoped CSS file that only applies to that specific part of the application. However, if we do our jobs right, those files should be fairly minimal—the vast majority of our styles will be pulled from our global CSS and reused across the entire application.
For many teams, the use of a CSS extension of some kind can help lighten the load when implementing a design system. While it is possible to use vanilla CSS (especially now that it includes math functions and custom properties/variables), there are several libraries that can still provide several useful benefits when it comes to reusing and remixing styles, doing advanced or complex computations, etc.
In general, the best option is the one the team is most familiar with and/or excited about. Adoption is one of the largest hurdles to clear when starting a design system, so anything we can do to make it easier is a step well worth taking. If the team has already been using Sass, stick with Sass! If Tailwind is your jam, go for it!
The only thing we’ll want to avoid are CSS frameworks that are tightly coupled with other design systems. For example, Bootstrap is an incredibly popular option, but it’s also very opinionated from a design perspective. Similarly, MUI is a well-known library, but it’s strictly tied to Google’s Material Design system.
If design is using one of these existing systems as a jumping-off point for their own design system (which is a completely valid thing to do—and a great way to speed up the process), then using the associated framework makes all the sense in the world. However, if they’re not, then using a framework or library tied to a different design system will only create challenges down the road.
Personally, my preference is Sass: I find that the mixins, partials and operators are hugely useful when it comes to creating reusable snippets of code for a design system. And, since it’s “just” a pre-processor and not a framework, it’s not opinionated in a design sense and there aren’t any default values (colors, spacing values, etc.) that will need to be overwritten.
The smallest pieces of a design system are the design tokens—colors, fonts, measurements and other reusable aspects that get repeatedly applied to various components. For example, we generally want the border radius to be the same across different elements. When the border radius on a button is the same as the border radius on an input, it makes the design look cohesive and intentional.
In that situation, manually defining the same border radius value in our CSS over and over again on various elements would be frustrating, time-consuming and difficult to maintain (if that value ever changed in the future). It’s only natural for us to make it a reusable variable!
Design tokens work in exactly the same way. When we get a list of design tokens as part of a design system, one of the easiest and most useful things we can do is immediately turn those tokens into variables in our global CSS file.
$primary: #FFAA00
That being said, there’s more to it than just “make some variables.” When we’re defining those variables, it’s also important for us to keep naming, hierarchy and future expansion of the design system in mind.
As the joke goes: the two hardest things in programming are cache invalidation, naming and off-by-one errors.
As we’re naming and defining the list of variables based on the design tokens, it’s important to keep in mind that design systems (especially in their early days) are not a finished project. Changes and new additions should be an expected part of the design system experience. As the brand, product line or software expands, the design system will need to expand along with it. For that reason, we need to leave room for growth in our coding of the design system as well.
For example, the list of design tokens we get from the design team might currently include three standard padding sizes: 6px
, 10px
and 14px
. The “t-shirt
sizing” naming convention is pretty easy to understand, so we decide to name those variables “padding-small,” “padding-med” and “padding-large.” Three months later, the design team sends a message to let us
know they’ve determined the need for an additional padding value—8px
. Because of the way we named the variables earlier, there’s no easy way for us to fit this new variable into our existing structure.
In general, it’s a good idea to define variables based explicitly on what they are or what they do, not their relationship to other variables. Nate Baldwin wrote a fantastic breakdown on how Intuit created a flexible design token taxonomy for Intuit’s design system that’s well worth a read and does a fantastic job explaining how they approached the same problems.
When it comes to actually defining the variables, there might need to be some slight adaptations made between what design sends over and what gets written into the CSS.
Many design programs still function on a basis of pixels. While that makes sense for prototyping and designing, we’ll want to ensure that we’re using more responsive and flexible units when we define the variables on our end. By converting
hard values to ems
, rems
, percentages and other flexible units, we can create fluid systems that not only work well on screens of all sizes, but also can be chained together to
make updates and maintenance easier.
For example, if we were to use rems for the entirety of our typography system, we can build a system where all our units are scaled relatively to the base value. We’ll set that base value at whatever design determines, then convert the rest to rems. In the future, if the design team ever needs to make an adjustment to the typography system, we can then simply adjust the base value and the rest will scale accordingly.
$base-size: 26px;
html { font-size: $base-size; }
p { font-size: clamp(1rem, 1vw, 2rem); }
h2 { font-size: clamp(2rem, 2vw, 3rem); }
h1 { font-size: clamp(3rem, 3vw, 4rem); }
Finally, it’s important to make sure that our variable names match the design token names as closely as possible, in order to ease communication between design and development. If we’ve defined a color as “primary” and the design team refers the same color as “main,” wires will inevitably get crossed—and this only increases in complexity as our list of variables/design tokens grows longer. Every name that we synchronize lowers our chances of miscommunication.
If we’re taking advantage of a component library with an associated Figma kit (more on that in the next section), then that should already be done for us! If we’re building from scratch, however, then it’s well worth keeping in mind.
Icons are one of those “small” things that can fall through the cracks when we’re thinking about putting together a design system. While they might not be quite as foundational as our design tokens, they’re still something that we’ll need almost as soon as we start building or styling components.
Of course, we have many different ways of solving this problem. Some of the most common include pre-existing third-party icon libraries (such as Font Awesome), icons bundled into a third-party component library (like the Kendo UI icons), or a completely custom set of icons designed and maintained by your design team. Obviously, going 100% custom will require more work (on both the design and dev side), but might be worth it to achieve a truly unique look—or if the UI will require icons for uncommon symbols or concepts.
My recommendation is (as always) to use whatever is most frictionless for your team—both developers and designers. For example, if you’re using a third-party component library (such as Kendo UI), then it’s smart for developers to use their icons for everything, in order to create a cohesive look and allow the components to blend seamlessly with the rest of the UI. That also benefits the designers, who have easy access to the exact same icon set for mockups and prototyping via the Figma Kits.
<SvgIcon icon={arrow-chevron-up} size="medium" />
Implementing icons generally takes one of two forms: a custom icon font or a library of SVGs. While icon sprite sheets are still an option (and some folks feel very positively about them), they’re becoming less and less common—I wouldn’t recommend going this route, simply because it’s a method less people are likely be familiar with and will therefore require more explanation and management.
Icon fonts are fonts which contain vector glyphs instead of letters and numbers. They can be styled with CSS the same way we style text. SVG icons, on the other hand, are more lightweight, load faster and are resolution-independent. Perhaps more importantly, SVG icons are (in my opinion) easier to maintain because the entire font file doesn’t need to be updated in order to replace or adjust a single icon. SVGs also offer more flexibility for UI animation, if that’s of interest. For those reasons, I recommend going with SVGs over an icon font.
But that’s not all, of course! In the next section, we’ll discuss what happens when we start to put those design tokens and icons to work in order to create accessible components, patterns and templates!
]]>In this series, we’re discussing how to ensure your user experience (UX) is as effective as possible. We’ve targeted five principles to help you create a user interface that your users know how to use:
In this final post in the series, we’ll cover those last two. Consistency and design patterns were covered in Part 1, and then Part 2 covered how to support the users’ scenario.
Once you’ve ensured that a user can navigate to the UI they need, your responsibility shifts to organizing the elements that make up each UI. Organizing the individual UIs is still driven by the user’s mental model but your goal now is to reduce the user’s cognitive load when interacting with each UI in the user’s scenario. Ideally, your UI matches the user’s mental model so closely that users never consciously think about your application and, instead, can concentrate on achieving their goals.
Reducing your user’s cognitive load comes down to using well known design patterns to implement what your users need at this point in their scenario—which means only implementing what your user needs. This comes back to why “the one screen does everything” design fails: Putting “everything” in the UI actually increases the user’s cognitive load by forcing the user to ignore much of the UI most of the time.
Once you’ve decided what elements the user needs in their UI, you can further reduce the users’ cognitive load by organizing those elements into sections tied to your user’s mental model. Essentially, each section in the UI corresponds to one of the components that make up your user’s mental model.
In a sales order application, those components might be the customer’s addresses (shipping and billing), information tied to the order as a whole (shipping date, order Id, etc.), the list of products being purchased, and the cost (product-related, shipping-related, tax, discounts, etc.).
You can leverage multiple tools from the psychology of perception to create those sections, but the three most useful ones are:
These three laws mean that you don’t necessarily have to draw a border around a set of elements for users to the see them as a section. Leveraging proximity, for example, means that if there’s more space around a set of elements than there is between those elements, then those elements will be seen as a group (especially if the elements share a common appearance).
This simple WPF screen demonstrates dividing a UI into sections using both the LayoutPanel component to define common regions and using simple
proximity (along with a similar look and feel).
Relying too much on proximity can create a new problem, however, especially on small screens. When elements are “too close,” users may not be able to reliably select the element they want. This effect is described in Fitt’s law. Putting more space between elements that belong together and creating sections by using borders (i.e., leveraging common regions) might be a better answer when screen space is tight and the user’s selection tool is large. Think of this as the “My Big Fat Thumb” problem.
But, often, not every user needs all of a UI’s sections. In a sales order application, for example, the UI that’s appropriate for the Shipping department isn’t the right one for the Billing department.
The Shipping department doesn’t need to see customer billing information and would describe a UI that includes billing information as “cluttered.” On the other hand, the Billing department is keenly interested in things like the customer’s credit rating and the customer’s payment history, but the only shipping information that Billing wants is the cost. Focusing each department’s UI on the elements the department’s users need reduces the cognitive load for the users.
However, you also need to recognize that users’ needs may vary from one interaction to another—there may be times when Shipping does need to access billing information, for example. Think of these as “variations” on the users’ scenario.
Sections that are hidden by default but can be displayed by the user when the user needs them address these issues. Hidden/displayable sections reduce UI clutter and cognitive load for the typical scenario but let users access information they only need occasionally.
Popout panels are another option for providing information when required while staying out the user’s way the rest of the time.
An expander panel (implemented using the Progress Telerik UI for WinUI RadExpander) lets you create a UI that’s initially focused on the user’s goal
(“Enter a Request”) but can be expanded by clicking on “Change Country” when the user needs more options.
An accordion control is another way to enable users to ignore information when they don’t need it but easily access it when they do.
PanelBar and PanelBarItem components from the Progress KendoReact library let you create “accordion” style interfaces with
multiple panels.
Tab-based UIs provide yet another way to create sections. A tab-based design makes sense to users when:
Multiple tabs allow users to switch between related functionality on an “as needed” basis. The Progress Kendo UI for Vue TabStrip shows
tabs in two configurations: on the left and across the top.
Initially, creating sections sounds like it will add to the cost of creating a UI as compared to creating a more static interface. However, sections have the potential to reduce development and maintenance costs by having one screen support multiple scenarios.
You could, for example create multiple UIs for users in Shipping and Billing or for big screen/small screen devices. However, with the appropriate sections in place, you may be able to create a single UI that tailors itself to the needs of particular users/devices by hiding individual sections.
In fact, hiding or moving sections in a UI is the common approach for creating a “responsive user interface” that handles both big-screen and small-screen devices. However, when supporting big and small screens in the same UI, it’s easy to fall into concentrating on “making the screen fit” rather than ensuring that users can always achieve their goals. Organizing your UI into sections based on the users’ mental model positions you to either:
An application using Telerik UI for .NET MAUI components reconfigures its display to fit in both an Android Pixel 9 screen and a Windows
desktop environment.
The only useful criteria for assessing your UX is whether “the user always knows what to do next in order to achieve their goal.” The best way, therefore, to find out if your UX is meeting that criteria is to bring users in to try your UX out. And your users’ input is worth having: Your users are, after all, experts both in using UIs and knowing how to do their job.
You can’t start too early here. If you wait “until you have something” before bringing in your users, then you’re deciding that getting to any answer early is better than finding out what the right answer is, right now.
As soon as you can pull together a paper and pencil (or whiteboard) mock-up, you can do a UI test with some of your users by asking them to try interacting with your mock-up. For these UI tests, you’ll act as the application, pulling up the sheet of paper with the “next UI,” highlighting the active control with a marker, and writing any error messages on the paper “screen” to mimic how your application will interact with the user.
There are two major benefits to getting an early start with users. First, a UI test is the surest way to discover if you actually do understand both your users’ mental model and their goals. Second, the users who are involved in testing will feel they’ve had an impact on your application’s UX. Those users will automatically like the resulting UI better than one that’s inflicted on them without their involvement. If you’re lucky, those users will also act as champions to other users for your application, giving your UX a better initial reception when you roll it out.
While visual design isn’t part of this paper, involving a visual designer can also get you a better initial reception. This is the result of the aesthetic-usability effect, which says that users believe that beautiful things are more likely to be usable.
But creating champions and having an attractive design only helps with user’s initial reaction. In the end it will be your users’ actual experience of working through your UIs that will form your users’ judgment—which is the only one that matters, after all.
As you gather feedback from your users, be aware that it can be … well, disappointing. You may, for example, just get the deflating comment, “Well, it’s very straightforward.” That may not sound like high praise, but it means your UX matched the user’s mental model so well that users didn’t have to think about how your application works.
Getting the comment that your UX is “intuitive” is more encouraging, though. It also means that you successfully leveraged both design patterns and a well-known theme so that your users always knew what to do next.
The downside of this reality is that the best feedback you’ll ever get for your UX is that your UIs are invisible to your users. And that brings up the peak-end rule. The peak-end rule says that people judge experiences based on two things: the end point and any high or low points (the peaks) along the way. This is the “Well, I loved that piece of music right up until that screeching crescendo at the end which ruined it for me” effect.
If your UX either fails at the end or if something goes very wrong before the end, users will remember those moments and not the “invisible things” in between. You’ll need to recognize that, when you get feedback that only focuses on the end or on a particular peak, it means that the rest of your UX was invisible.
And no feedback at all means your whole UX was invisible to your users—your users were just able to do what they wanted. And that’s what you want.
Get started with a Progress Telerik DevCraft Trial today! The DevCraft suite is the most powerful collection of Telerik .NET and Kendo UI JavaScript developer tools. It includes modern, feature-rich, professionally designed UI components for web, desktop and mobile applications; embedded reporting and report management solutions; document processing libraries; and automated testing and mocking tools.
DevCraft will arm your developers with everything needed to deliver outstanding applications in less time and with less effort, and with consistent theming across your applications.
With award-winning technical support delivered by the developers who built the products and a ton of resources and trainings, you can rest assured that you have a stable provider to rely on for your everyday challenges along your software development journey.
]]>While every user interface you create will have different needs and target users, these five principles will help you to create the right UI this time:
We’ll pick up where we left off the first post in this series.
Effective UIs do more than just guide users’ hand movements, though: Your users also have expectations around how they will achieve the goals your UX supports. You can think of these expectations as your users’ “mental model”—how your users think about the problem and map what they expect to your application’s UIs.
You have two choices around dealing with your users’ mental model: Your UI can support your users’ model or you can provide a new one.
If you do want to give your users a new way of achieving their goals, remember that MAYA applies here, also. (That’s Raymond Loewey’s Most Advanced, Yet Acceptable principle, in case you missed it in Part 1.) If you want to replace your users’ mental model, then your new process will have to provide something your users value enough that it will overcome their resistance to adopting something new.
And this resistance isn’t entirely unfair on your users’ part: Users recognize that there are real costs associated with adopting a new mental model (time spent in training, making errors and experimentation, for example). For external-facing apps, where users have other options than using your application, your new mental model can result in losing customers or business partners to your competitors just because your competitors’ UIs work the way your customers/partners expect.
Bottom line: If you want to get users to adopt your new mental model, you’ll need to convince your potential users that your UX will help them meet their goals in a way that your users will value more than the “old fashioned” applications will. There is a way to do this successfully, but you need to understand design patterns first.
Once you’ve decided on the model your UX will support, you can map out the series of UIs your users will interact with in achieving their goals (your users’ “scenario”). Those scenarios will vary depending on your users.
Consider two scenarios for “buying things”: customers buying products at a retail outlet and customers buying investment products through a financial consultant. If your application is targeting retail customers, then the scenario your users expect is that they will:
A typical shopping cart flow, implemented using the Stepper control in Progress Kendo UI for Vue.
The scenario is different if you’re targeting customers buying investment products through a financial consultant. In that scenario, even though the end result is still the user “buying something,” the mental model is “getting expert advice.” In this scenario:
Even the payment process follows a different scenario: In the investment products scenario, payment often flows from the customer to the investment provider, with the consultant receiving a commission from the provider, not the customer.
A typical consulting flow, again implemented using the Kendo UI for Vue Stepper component.
By the way, this kind of scenario-based design process can lead to new ways to structure your UX by swapping the design patterns from mental model that your users are comfortable with into a different scenario.
Self-serve investment sites, for example, treat the “getting expert advice” scenario like the “buying things” scenario to help users apply a familiar design pattern (the shopping cart) to a new experience (making investments). This is, of course, just another example of the MAYA principle of implementing “advanced” experiences by leveraging what your user already accepts.
Your next step is to build the UI (or series of UIs) that support the mental model you’ve decided to support. In applications with a narrow focus (many smartphone apps, for example) that UI may be a single screen. Don’t mistake the single screen design—the “a user can do anything they want from this screen” design—as your ideal design pattern, though.
To understand why a single UI isn’t optimal, imagine that you’re creating a jigsaw puzzle for a customer. That customer won’t think you’re adding value if you start to throw in “extra” pieces from different puzzles into the box. People who put together jigsaw puzzles don’t want to create “any puzzle”—for any particular puzzle, those people want to create the picture on the box.
Similarly, users never want to “do anything”—at any particular time, your users want to perform some particular task. As with the jigsaw puzzle, you’re not “adding value” if you add elements to your users’ UI that users have to ignore when performing the particular task they’re interested in. In fact, those “extra pieces” are what users are usually referring to when they say a UI is “too cluttered”: You have put elements on the screen that are irrelevant to the user’s current task.
Avoiding the “one screen” design means that, often, a key part of your UX is helping your user navigate through a series of UIs focused on part of the current “particular task.” As a result, your UX will need to support your user doing two things:
Where the series of UIs is long (more than two or three screens) or where a process is time consuming, consider providing a stepper or progress bar to exploit the goal-gradient effect. The goal-gradient effect says that people are motivated by how close to the end they are, not by how far they’ve come. A stepper or progress bar that (eventually) shows that the end of the process is near automatically enhances the user’s experience.
Again, the user’s mental model that you’re trying to reflect or mold matters here. If the user thinks of the process as a single, homogenous process that has to be “waited” through, a single bar is the best UI choice; if the user sees the process as broken into steps, a bar that’s reflects those steps will make more sense to the user; for a repetitive process that will be performed multiple times, a circle that can be redrawn communicates that to the user.
Progress bars can come in a variety of formats to support the message you’re trying to communicate. These three example (basic, chunked and circular) are from Progress Kendo UI for Angular components.
The typical design pattern for helping users find that initial UI is a menu. To build an effective menu, you first need to determine what terms/icons your users will be looking in your menu items (you can draw on your users’ mental model for those terms). Depending on the number of menu items, a single list of menu items may be all that you need.
The Menu component from Progress KendoReact supports traditional dropdown menus and can be easily swapped from horizontal to vertical layouts.
However, where the number of menu items is large (i.e., more than a half-dozen), you’ll want to create menu groups to narrow the user’s search when looking for the “initial UI.”
TreeView controls provide a way of organizing hierarchical navigation structures while “Microsoft ribbon-style” menus support complex desktop environments (these examples use Kendo UI for Angular TreeView and the RibbonBar from the Telerik UI for WinForms library).
The techniques involved in wayfinding, which describes how people find their way to a location, can help you here. For example, when people start out on a journey, they first want directions to get to the general vicinity of their final destination (e.g., “How do I get to Cincinnati?”)—those are your menu groups. When people get close to their destination, they want more specific instructions (“How do I get to Skyline Chili?”)—those are your menu items.
This is also the way Disney World supports their visitors: Direction signs at Disney World point to specific attractions, but only for those attractions in the customer’s immediate vicinity (e.g., “Dumbo’s Wild Ride”). For most distant attractions, the signs just point to the general area (e.g., “Adventureland”).
Even if your number of menu items is small, if items are grouped together in your users’ mental model, then you should consider creating menu groups that reflect that model. This may just mean organizing menu items on a single line into groups with captions.
As with the menu items themselves, when creating menu groups, it’s critical that you draw on your users’ mental model to pick the terms/icons you’ll use to identify your groups.
Progress Telerik provides a rich store of widely recognized icons that you can use in your applications (these are from the icons available for Blazor applications).
Since many goals will require the user to interact with several UIs, individual UIs are going to need links or buttons that lead to the “next UI” in the user’s mental model. Without those links between the UIs that make up a process, users are forced to return to the application’s main menu to search for the “next UI.”
Design patterns apply here, also. On webpages, for example, users typically regard links, menu choices and clickable icons as “navigation” items and don’t expect, when they click those elements, for any action to be taken (other than displaying a new page).
You can also leverage design patterns in deciding where to put your menus on a website. Users expect menu bars close to the top or bottom of the page to be static and remain unchanged as the user moves around the site. Users expect menu bars further within the page (or menus down the left side of the page when there’s a bar across the top of the page) to change as the user moves from one subsite to another subsite within the main site.
On the other hand, users typically regard buttons on a webpage as performing some action (saving the data in the current UI, for example). If a button does perform any navigation, then users see it as an “add-on” performed after the action is complete (displaying a success screen, for example).
Next time, we’ll finish up the list of five design principles for ensuring your users always know what to do next—bullet-proofing your UX. The final two principles are organizing your UIs and testing your UIs, with user involvement.
Get started with a Progress Telerik DevCraft Trial today! The DevCraft suite is the most powerful collection of Telerik .NET and Kendo UI JavaScript developer tools. It includes modern, feature-rich, professionally designed UI components for web, desktop and mobile applications; embedded reporting and report management solutions; document processing libraries; and automated testing and mocking tools.
DevCraft will arm your developers with everything needed to deliver outstanding applications in less time and with less effort, and with consistent theming across your applications.
With award-winning technical support delivered by the developers who built the products and a ton of resources and trainings, you can rest assured that you have a stable provider to rely on for your everyday challenges along your software development journey.
]]>How to know if your app’s user experience is effective: Do your users know what to do next? Here are the five design principles to ensure that answer is yes. Part 1 discusses consistency and design patterns.
There’s only one practical way to measure how effective your application’s user experience is and that’s to ask the question: “Do my users always know what they have to do next to achieve their goals?” When the answer is “yes”—even if the user’s goal is just “Get this order finished and go home”—then your users are getting something that’s still surprisingly rare: A user interface that works for them.
If the answer is “No,” then you’re incurring some real costs—in extra user errors, slow manual processes and time lost in training (though that “training” often isn’t officially recognized because it’s either being performed by other, more experienced users or by individual users training themselves by fighting through the application). If your application is external-facing, then those ineffective UIs are either damaging relationships with your business partners or costing you customers. Maybe both.
To put it another way: In the end, only the user’s opinion about the UX you’re providing matters and they’ll only consider that they’re have good experience if your UI helps them meet their goals.
It also means that the criteria for assessing an application’s UX aren’t constant across all applications but, instead, depend on your users: their goals, how they think about the problem your UI solves, and the history/experience with other applications that they bring to the table.
Your users’ UX needs are driven by their goals, experience and mental models. The five principles let you build on that to deliver a UX that works for your users.
But, having said that, there are five principles you should apply across every UI that ensure you will create an effective UX for your users:
This idea of “fundamental UI principles” is the basis of design systems like Google’s Material and Microsoft’s Fluent systems (after all, a “design system” only makes sense when there’s something that is, or should be, part of every UI). That applying these principles will also save your organization money (and save it in multiple ways) is just icing on the cake.
But, still, these are only principles: You’ll need to customize implementing these principles to meet both your users’ goals and the specific needs of your application. To keep this discussion useful, then, here are also some concrete examples both of what those principles look like in action and how to customize them both for your users and your applications.
Realtors have a joke about the three most important things to home buyers: They are “location, location and … location.” The equivalent “joke” for UI designers is: “The three most important things to end users in a UI are consistency, consistency and … consistency.” In a very real sense, users don’t really care what you do, as long as you do it the same way everywhere and every time.
Windows is a good example. If you’ve ever taught someone how to use Windows, you know Windows isn’t necessarily “intuitive.” What Windows does do, however, is enforce consistency on the applications that run on it. If you know how to print something in one Windows application, you know how to do it in any Windows application.
The first step in ensuring consistency is to apply a common look and feel across all your applications (call it your “theme”). While making similar items look alike is the primary goal when selecting a theme, you also need your theme to give you the ability to highlight UI items you want to stand out: to make different things look different.
Progress Telerik themes provide a common look and feel across server-side (ASP.NET), desktop (WPF) and client-side (React, Angular, Vue or just plain old JavaScript/jQuery) apps.
The payoff for having a common theme is that it lets you invoke your users’ “prospective memory”: the paradoxical ability for users to remember, based on past interactions, how to perform a future action.
Prospective memory is actually something you know very well—it’s the reason that you can pull out of your driveway in the morning without thinking about it … and still automatically hit the brakes when another car appears unexpectedly. In UI terms, it means your users can instantly (and almost unconsciously) start moving their mouse toward a primary button in the UI while they’re still digesting the information being displayed.
Having a consistent theme across all your applications also lowers development costs because developers don’t have to think about how to style their applications. You want, for example, to both ensure that error messages look the same on every platform and have those messages be instantly noticed by users (you want to invoke the Von Restorff effect which says that UI elements that look different from other elements are more likely to be noticed). That’s easier for developers to achieve if a consistent error message style is built into your standard theme.
While you can roll your own theme, there are at least two good reasons to adapt someone else’s theme. First, and most obviously, adapting an existing theme to meet your needs involves less work than building your own theme. The second benefit goes back to building your users’ prospective memories: Adopting a popular third-party theme means that every other site in the world that’s using that theme is training your users’ prospective memory for you.
Telerik extensions to Visual Studio and Visual Studio Code let you select themes (and variations on themes, called “swatches”) to be applied to your application’s UI based on, for example, the Bootstrap, Material and
Fluent design systems.
But, as the word “adapt” suggests, you’ll certainly need to modify the theme you pick to make it compatible with your organization’s branding. So, when picking a theme, you want to pick one that comes with a toolset that makes it easy to tweak that theme.
Progress ThemeBuilder lets you build your own themes, using one of the Telerik base themes
or your own theme.
Furthermore, your organization’s theme is going to evolve over time. To support changing your theme over time, you also want a UI design tool that can both leverage the theme you select and let you evolve that theme over time.
Progress Telerik and Kendo UI provide UI design kits for working with Figma, a web-based application that supports multiple stakeholders collaborating on UX design.
Of course, consistency goes beyond the look and feel of your apps to also include how your users interact with your applications.
Before reading any further, try this experiment: Go to a website for some large multinational retail company that has been successful on the web (Amazon leaps to mind). On that site, look for some original, unique UI component that you’ve never seen on any other site.
Spoiler alert: You won’t find one. The reason is simple: Successful UIs are all about helping users achieve their goals … and no user has “figuring out this application’s UI” as one of their goals.
Really, a user interface is like a joke—if you have to explain it, it wasn’t very good. Jakob Nielsen’s First Law of Internet Experience provides the answer here: Users spend most of their time on other sites and, when your site works like those “other” sites, users come to your site already trained—they already “get” the joke.
Those UI elements that your users already know are referred to as “UI design patterns.” And, again, you’re familiar with this concept: You (and users all over the world) automatically know how to interact with an online scheduler, provided it looks something like one of these:
Various Telerik/Kendo UI scheduling controls implement a UI that every one of your users already knows how to use (these examples are from ASP.NET,
Blazor and Angular applications).
While you may not know about Raymond Loewey, his MAYA principle (Most Advanced, Yet Acceptable) is your best guide here. You interact with Loewey’s designs every day because Loewey designed everything from the shape of a Coca-Cola bottle through to the company logos for Shell, Greyhound and the U.S. Postal Service. Loewey’s secret for well accepted designs (designs that have survived for, literally, decades) was to wrap anything new in something familiar. You want to wrap your application in a UI that looks familiar to your users (and still look like something new).
Spotify learned about the MAYA principle when they first rolled out their Discover Weekly feature. Spotify’s original intent was to provide their users with a list of nothing but new music. However, an initial bug let some familiar songs appear in the original Discover Weekly lists.
Spotify “fixed” the bug so that those familiar songs were eliminated from the list. The result? User interaction with Discover Weekly dropped off dramatically. Spotify then revised the algorithm to always include at least some songs the user was familiar with. Now, Discover Weekly is one of Spotify’s most popular features.
It’s easy to harvest the UI design patterns your application needs: Look at other organization’s sites that have users with goals to similar your users and then—without violating copyright—“steal from the best.” For more depth/direction, you can find curated guidance and direction at the UI patterns site. Mobile-specific patterns are covered on the pttrns site (though the pttrns site requires a membership).
The UI Patterns Site provides not only holds a set of curated patterns but also has downloadable document of what they consider to be the most “persuasive patterns.”
Design patterns leverage your users’ prospective memory in a way similar to having a consistent theme. With design patterns, though, the effect is referred to as “feed forward” to reflect how familiar patterns lead users on to do “the next right thing.”
Applying design patterns not only aids users but also lowers costs due to reduced errors, lower (or zero) training costs and improved productivity due to faster response times.
Stay tuned to keep reading. Next, we’ll dive into the importance of supporting the users’ scenario. And then we will get into how to organize and test your UIs.
Get started with a Progress Telerik DevCraft Trial today! The DevCraft suite is the most powerful collection of Telerik .NET and Kendo UI JavaScript developer tools. It includes modern, feature-rich, professionally designed UI components for web, desktop and mobile applications; embedded reporting and report management solutions; document processing libraries; and automated testing and mocking tools.
DevCraft will arm your developers with everything needed to deliver outstanding applications in less time and with less effort, and with consistent theming across your applications.
With award-winning technical support delivered by the developers who built the products and a ton of resources and trainings, you can rest assured that you have a stable provider to rely on for your everyday challenges along your software development journey.
]]>
Frontend engineers play a crucial role in the creation and maintenance of design systems. In Part 1 of this article series, we explored how frontend developers prepare and maintain coding style guides, component libraries and design tokens when working within a design system. In this article, we’ll continue the discussion by looking at the importance of recognizing accessibility, performance and good documentation in a design system.
Accessibility is a critical aspect of UI design that should not be overlooked. UI components should be accessible to everyone, including those with disabilities. Accessibility guidelines such as Web Content Accessibility Guidelines (WCAG) help provide detailed information on how to create accessible web content.
One important aspect of accessibility is providing alternative text for non-text content such as images, videos and audio. This allows screen readers and other assistive technologies to describe the content to users who may not be able to see or hear it. For images, this can be achieved with the use of the alt attribute which provides a brief description of the image that is used by screen readers and other assistive technologies.
<img src="cat.jpg" alt="A fluffy gray and white cat with green eyes" />
In addition to alternative text, using semantic HTML is also important for accessibility. By using semantic HTML, frontend developers ensure that screen readers and other assistive technologies can understand the content and convey it to users in an accessible way.
<!-- Non-semantic heading -->
<div class="header">
<div class="logo">Company Logo</div>
<div class="title">Page Title</div>
</div>
<!-- Semantic heading -->
<header>
<img src="logo.png" alt="Company Logo" />
<h1>Page Title</h1>
</header>
In the code example above, we can see the first code block uses a non-semantic heading that consists of a <div>
element with two children <div>
elements to display a logo and
page title. This is not an ideal structure for accessibility because it doesn’t clearly indicate which element is the main heading of the page.
The second code block, however, uses semantic HTML by wrapping the logo and page title in a <header >
element and using the <img>
and <h1>
elements to render an image and heading respectively.
Among the above points, there are many other practices that can be done to ensure good accessibility in UI components which include:
Optimizing components for performance is another crucial aspect of maintaining a design system as it directly affects the user experience. The faster a website or application loads, the more likely users are to stay on it and engage with the content. We’ll discuss a few important practices to consider to ensure UI components are built with performance in mind.
Building UI components with lazy loading can help with the overall performance of an app. Lazy loading is a technique that involves only loading resources such as images and videos when they are needed, which can improve the initial load time of a page. By only loading resources as they are needed, the browser can prioritize the loading of the most important content on the page. The concept of lazy loading can also be used with UI components themselves by having components also get loaded only when they are required.
Using responsive images that are optimized for different screen sizes can also improve performance. When building UI components that use (or expect images), we can ensure that provided images are tailored to the screen size of the user’s device. This helps the browser always download the appropriate image size which can reduce the file size and improve the overall load time of an application.
Minimizing the number of HTTP requests made to download assets for UI components can also optimize components for performance. This can be done by combining files such as scripts and stylesheets into a single file which can reduce the number of requests the browser needs to make to the server. Image sprites can also be used to combine multiple images into a single file, which can reduce the number of requests needed to load a large number of images.
Finally, frontend developers need to ensure that all UI components in a design system are well-documented. Documentation helps other developers on the team understand how to use and customize the components which can save time and reduce errors.
When it comes to documenting UI components, it’s important to provide clear and concise instructions on how to use each component. This should include details on what props or attributes are available, what they do and how to use them. Additionally, including examples of how the component should be used in different contexts can help other developers on the team understand how to use and customize the components.
Here’s an example of how the props of a certain component in the KendoReact component library is documented.
Storybook is an open-source tool that can be very helpful in the building and documenting of UI components within a design system. Storybook allows frontend developers to create a visual library of components with various use cases, and provide code snippets, examples and documentation for each component. Storybook also has a built-in development environment, which allows frontend developers to work on the components in isolation and test them in different scenarios.
You can see the Storybook for the KendoReact library here.
It’s also important to ensure that component documentation in a design system is up-to-date and reflects any changes or updates made to the component. This can help avoid confusion and errors when using the components, and ensure that everyone on the team is working with the most up-to-date version.
Building a design system from scratch can be a daunting and time-consuming task, especially for organizations with limited resources. However, using a UI component library like Progress Kendo UI can significantly simplify the process.
Kendo UI is a comprehensive library of UI components, such as buttons, inputs, grids and charts, that can be used to build web applications. Kendo UI is built with customization in mind making it an excellent starting point for building a design system. And the ThemeBuilder tool is built to help.
By starting with Kendo UI, frontend developers can customize the library to fit their organization’s specific needs. This includes defining design tokens for colors, typography and spacing, as well as creating custom components and styles that adhere to the organization’s brand and design guidelines.
For more details on how this can be done, refer to the article Building a Design System with Kendo UI written by Thomas Findlay.
In the first article of this series, we discussed the importance of preparing and maintaining coding style guides, design tokens and component libraries within a design system. Accessibility, performance and good documentation are also important aspects that frontend developers need to consider when creating and maintaining a design system. By ensuring that UI components are accessible to everyone, optimized for performance and well-documented, developers can provide a better user experience and help their team save time and reduce errors.
]]>