Most teams know how hard it is to align developers and designers, code and design. Keeping a Figma library in sync with the codebase is a lot of work. Developers will spend time carefully making a Storybook instance of live components, only for designers to find that what’s online differs from what they have in their design files. The back-and-forth between teams, countless screenshots, and time-consuming library maintenance all keep designers from focusing on designing new features.

But now it’s possible to get rid of this tedious task. In just a few clicks, design can be seamlessly synced from code, thanks to some new frontend tools.

For instance, story.to.design can automatically build and update a Figma UI kit or component library from Storybook. It does all the work for you.

Let’s discover in this article a few ways your design team can benefit from such a new workflow :

Fewer discrepancies between code and design

Developers and designers typically work with different sources of truth: one in Figma and one in code. This means developers and designers aren’t always seeing the same components. A change in code is not automatically rendered in Figma for designers, leading to discrepancies and confusion about which component is the latest version.

Being able to automatically update the UI kit or component library in Figma, anytime code in Storybook is updated, makes collaboration easier and allows teams to be more efficient when developers and designers aren’t wasting time discussing discrepancies between code and design.

Design with components that look exactly like production

It’s often the case that designers are using components that don’t look exactly like what is coded, and therefore aren’t what the final user sees. Because of the two different sources of truth, one in Storybook and one in Figma, developers may update or change something in the codebase that designers aren’t aware of (unless communication between teams is seamless, which isn’t always the case). Also, because design teams can’t spend hours updating Figma UI kits by hand, components become out-of-date and out-of-sync with the coded version.

It’s important to design with components that look and work exactly as they would in production. Not only is it better for communication between developers and designers, but it also means designers have the “truest” components that replicate exactly what a user will see and use, improving the quality of their design work.

Faster designing and prototyping

Let’s face it: creating and maintaining a UI library in Figma is time-consuming. Having to create each component from scratch requires time and dedication that keeps designers from working on new solutions. Being able to automatically generate and maintain your Figma UI library, can free-up designers to focus on more complex design work. Imagine having a full library done in under 2 hours?

Also, having production-replica components ready-to-go in Figma means designers can be faster and more efficient in designing screens and prototyping solutions. The same components being used by developers are also being used by designers, which means less time wasted checking whether a component is up-to-date or not. Designers can be confident they have the right UI kit, without having to create these components by hand.

Easier design system updates across tools

Design systems are costly to build and difficult to maintain. And when you factor-in maintenance across different tools and platforms, the cost and time commitment is even higher.

The possibility to sync an entire Figma UI library to the codebase can save design system teams tons of time and manual work. Designers no longer need to check Storybook in the browser to compare components, as the exact same components are inside their familiar environment. It also means a design system’s source-of-truth is more evenly spread across code and design.

Speak the same (component) language as developers

Another important benefit of using such a tool is the bridge it creates between designers and developers, especially when it comes to the language used around a design system. By importing your components from Storybook into Figma, you also bring in the same component naming and documentation. This way, when designers and developers discuss and work together on a design system, they have the same references and will be more likely to use the same names for components.

This brings important collaboration perks to the team like alignment, clearer communication, less confusion, and greater efficiency.

To give story.to.design a try, you can install the Figma plugin for free.

Originally published at https://story.to.design/ by Ardena on August 29th, 2022.

5 benefits for designers when syncing their Figma UI library with Storybook code was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

For the past few months, I’ve been working on a small UI library called A2k.

I’ve been gradually making changes when I get some time, but haven’t given much consideration to certain aspects of the library’s architecture.

For something small and scrappy, like a prototype or a proof-of-concept, testing an idea quickly is better than coding it perfectly. For other projects, it’s important to consider how the project’s architecture may positively or negatively impact the project over time.

Many small projects, like A2k, grow organically. As an organic project grows larger, some unwanted patterns start to emerge. I recognized one such undesirable pattern for how A2k handled icons.

For each icon added, I would create a file with the web component boilerplate + the contents of the SVG. I would also need to create another file to register the component. This equates to two files and a lot of shared code per icon.

Here’s the folder structure after adding the first handful of SVG icons to A2k:

Only half a dozen icons and this approach is already becoming unwieldy. Also, there’s already a lack of consistency between the naming conventions (Logo vs Icon anyone?). Thirdly, adding a new icon requires a bunch of boilerplate.

This approach not only impacts the development experience and the code complexity, but also those consuming A2k. Because each icon is a component, the consumer will need to register all of the icons they intend to use. If an icon is not explicitly imported, it will not render.

This approach didn’t feel right for A2k. I wanted:

• A simple API, one custom element to rule them all.
• End-users to not have to explicitly register the icons they wanted to use.
• All of our SVG icons served from a single file, which means we only make a single network request.
• Guaranteed constraints across all icons, as individual icons increase the possibility of entropy.

My approach? Refactor the library so that end-users only need to register a single web component. The icon they’d like to use would be specified as a property on that component.

I’m also interested in understanding how other libraries and authors have solved this. Most of these libraries have different requirements and constraints, so understanding different perspectives will help us think critically about which choice is the most appropriate for our given situation.

As a result, I’ll be splitting this article series into two parts.

Part 1 will follow the refactoring of A2k, covering concepts like:

• Using SVG’s use element
• Using ems for icon sizing
• Using import.meta to import assets

Part 2 will share alternative icon strategies used by more established component libraries and authors.

Part 1: Icon anatomy and refactor

I mentioned in the introduction that each component requires the standard web component boilerplate. As I was using Lit to write my web components, every icon component looked like this:

import { LitElement, svg } from 'lit';

export class HelpIcon extends LitElement {
  render() {
    return svg`
      <svg
	      viewBox="0 0 24 24"
	      fill="none"
    >
      {all the child SVG elements}
    </svg>
    `;
  }
}

Which renders perfectly fine in the browser:

It looks good and the code’s straightforward enough. The main problem is that the boilerplate is identical to the other icon components. So let’s begin consolidating our icons into a single component.

To do that, we’ll need to understand the tools we have at our disposal to achieve this.

SVG use

To separate our icon web component from our SVG image, we need to reference SVG images that live in an external file. We can achieve this through the use of SVG’s use element.

The use element allows us to reference an SVG image and clone it where the use element is used. It’s an excellent way to reduce duplicate SVG logic if the same image is used in several places.

For our use case, use is handy as a means of separating concerns. Our icon component is only concerned about rendering, while an external .svg file houses all of our icons.

Our refactored code looks a little something like this:

// More on this statement later
const url = new URL('../../a2k-icons.svg', import.meta.url).href;

export class A2kIcon extends LitElement {
  // More on these styles later
  static styles = css`
    :host {
      display: flex;
      align-items: center;
      justify-content: center;
      font-size: 2em;
    }
  `;

  @property({ type: String })
  icon = '';

  render() {
    if (!this.icon) {
      console.warn(
        "This icon is a missing a 'name', please specify the 'name' of the icon you want to display"
      );
    }

    return svg`
			// More on these styles later
      <svg height="1em" width="1em">
        <use href="${url}#${this.icon}"></use>
      </svg>
    `;
  }
}

You can see that we’re still wrapping our markup with a top-level svg element.

We’re then using use to clone the SVG image that lives at the href path. The value passed through to href is the combination of the absolute path to the file and a reference to the specific icons id.

We now need to move over to the a2k-icons.svg where our SVG icons live. This is what the a2k-icons.svg looks like once we’ve migrated over our SVGs:

<svg xmlns="<http://www.w3.org/2000/svg>">
  <symbol id="help" width="1em" height="1em" viewBox="0 0 24 24">
    {/*<!-- SVG nodes like <rect /> -->*/}
  </symbol>

  <symbol id="documents" width="1em" height="1em" viewBox="0 0 24 24">
    {/*<!-- SVG nodes like <rect /> -->*/}
  </symbol>

  {/*<!-- Other SVG icons -->*/}
</svg>

This file has a top-level svg element, but our individual icons are wrapped around in a symbol element. The symbol element is used to define an element that can be cloned via the use element. Luckily for us, symbol accepts attributes like viewBox, height, width, etc., making it easy for us to move over our images from the web component into the a2k-icons file.

At this point, our end-user will be able to display the icon providing the icon’s name via a property, like this:

<a2k-icon icon="help"></a2k-icon>

We can now migrate all of the SVGs from our other individual icon components to the a2k-icons.svg file. Once we’ve done that we can delete all of our unused components (which is super satisfying). This is what our folder structure looks like now:

This approach isn’t without its caveats, by bundling all the SVGs into a single file, we serve all of our SVGs to our end-users via a single network request. For libraries that export 1,000+ icons, this will result in longer loading times and a poorer user experience. As we’ll see in part 2, there are benefits and tradeoffs for different approaches.

Wait, Ems? Don’t you mean Rems?!

The consensus in the web development world is that we should generally opt to use rem units over em units. And I 100% agree. The rationale is out of the scope of this article but if you’re interested in understanding when to use the most common CSS units, then I cannot recommend Josh Comeau’s wonderful article “The Surprising Truth About Pixels and Accessibility”, enough.

These are the units we’re going to be talking about here:

• em — a relative CSS unit whose value is based on the element’s font size
• rem — a relative CSS unit whose value is based on the root’s font size

Take the following elements for example:

<div style="font-size: 21px">
  <p style="font-size: 1rem">This is rem text</p>
  <p style="font-size: 1em">This is em text</p>
</div>

Assuming that the document’s root has a font size of 16px, then our first paragraph will display at 16px, while our second paragraph will display at 21px.

The above markup will render in the browser like this: So why did I choose to use ems for the icon sizing?

This was something that I learned from the Every Layout e-book. Using em can be a particularly handy trick if you plan on accompanying your icons with text. As we saw in the above example, the second paragraph’s font size is relative to the font size inherited from its parent. This is a handy way of ensuring that two closely-tied elements’ grow and shrink in tandem.

You can see this in action by writing the following component:

export class A2kTextIcon extends LitElement {
  static styles = css`
    :host {
      font-size: 24px;
    }
  `;

  render() {
    return html`
      <div>
        <a2k-icon icon="help"></a2k-icon>
        <p>Help</p>
      </div>
    `;
  }
}

All we’re doing is creating a new component that renders our pre-existing icon component but adds some accompanying text. The use of em within the a2k-icon component coupled with the explicit font-size: 24px in the A2kTextIcon's style property, means that both the paragraph and the icon will scale relative to its parent’s size.

If you’re not interested in coupling your icon with text, then you can either set the size of the icon explicitly or have the icon take up the entire width of its container. Either is a valid option for certain use cases but beyond the scope of this article.

If you’d like to learn more about composing resilient icon layouts, the Every Layout book is a wonderful resource. It covers a lot of interesting ground, like vertically aligning your icons, perceptually matching height with text, and using logical properties to apply spacing.

import.meta

So now that we’ve created the a2k-icons.svg file, it’s important that we can reference it correctly.

You’ll find that referencing a static file via a relative URL like so…

<use href="../../svg-icons.svg" />

…won’t work.

This is because paths in web components are relative to the root document, so you’ll need to create an absolute path directly to the static file.

The wonderful folks at Modern Web dive a little deeper into this behaviour, and they recommend referencing reusable assets with import.meta.url.

So here’s how we use it in our A2kIcon component:

const url = new URL('../../a2k-icons.svg', import.meta.url).href;

To understand what’s going on here let’s break this statement into three sections:

• import.meta.url
• ../../a2k-icons.svg
• new URL(...).href

Firstly, import.meta.url returns the absolute URL of the current ES module, in this case, A2kIcon.ts.

If you run a dev server, and log import.meta.url, you’ll see something like this:

http://localhost:3000/@fs/Users/Repos/andricos-2000/packages/icons/lib/src/A2kIcon.js

Secondly, we have ../../a2k-icons.svg which is the relative path of the file we want to access. This path is relative to where A2kIcon lives in the file system.

Finally, we can use the URL() constructor to generate an absolute path to our target file, the a2k-icons.svg file.

The first argument we’ll pass to URL() is the relative path of the target file. The second argument is our base URL, which we get from import.meta.url.

The following expression:

const url = new URL('../../a2k-icons.svg', import.meta.url).href;

…gives us the absolute URL for a2k-icons.svg:

http://localhost:3000/@fs/Users/Repos/andricos-2000/packages/icons/a2k-icons.svg

So this works fine when running our site on a local server, but does it work once the package is bundled?

I can’t speak on behalf of all bundlers, but Vite supports our call to URL() out of the box. It will ensure that the URL points to the correct location even after bundling and asset hashing. Unfortunately, this approach won’t work for components rendered on the server, and won’t work for generating URLs at runtime. To learn more about these limitations, have a look at the Vite docs.

There is a known issue with Vite’s use of import.meta, which will cause headaches for developers consuming your icon library. The way Vite optimizes dependencies causes problems when running the development server, and the component no longer has access to its import.meta.url value. This will break any URLs generated using new URL(). If you come across this problem you’ll need to add the following to your vite.config.js

export default {
  optimizeDeps: {
    exclude: ['@a2000/icons'], // or whatever dependency you're having trouble with
  },
};

Is this a suitable approach?

At the beginning of the article, I shared the rationale for moving to this approach. To recap, they were:

• A simple API for a single component.
• End-users only need to register a single icon.
• All icons are served via a single file.
• Improved DX as we can guarantee the same constraints across all icons.

We achieved this through the use of some interesting browser concepts like:

• SVG’s use element
• When to use ems over rems
• Building absolute URLs using import.meta

There are also drawbacks to our approach including:

• End-users will be downloading icons that they don’t use.
• The bundle size can grow large depending on the number of icons in our library. As we’ll discuss in part 2, some libraries have a total icon count of over 1,000.
• End-users can’t use their icon libraries with our icon component.

Depending on your library, these drawbacks may be trivial, or they could result in a degraded experience for your end-users. So, how do other libraries approach this problem and what are the drawbacks? We’ll cover this in part 2. Stay tuned.

If you have an icon library that takes a novel approach to manage your different icons, then please leave a comment, or reach out to me on Twitter. I’m building a list of icon libraries to compare for part 2 and would love to learn about any interesting approaches used out in the wild.

Originally published at https://backlight.dev and written by @AndricoKaroulla on July 7th, 2022.

Level Up Coding

Thanks for being a part of our community! Before you go:

• 👏 Clap for the story and follow the author 👉
• 📰 View more content in the Level Up Coding publication
• 🔔 Follow us: Twitter | LinkedIn | Newsletter
• 🚀👉 Top jobs for software engineers

How to manage icons in your UI library (part 1) was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

No one likes changes, particularly in the tech stack, “if it’s not broken, don’t fix it” most experienced team members will say. What if the new approach doesn’t work? What if it creates new issues? Not surprisingly, the same goes for design systems. Switching from old-school design architecture to a brand new design system can bring tremendous change, not only to your product but also, potentially, to the whole organization.

However, adopting a design system can lead to tremendous benefits: from laying the groundwork for your product to encouraging strong team collaboration. Design systems force teams to develop guidelines for delivering a product to production and can help you get the most out of your team and product.

A design system is more than just a collection of components. It also offers design concepts and guidelines for using the components. It provides good documentation with templates and examples of what to do and what not to do. It includes the component library’s surrounding procedures, strategy, and vision. A design system also provides a well-defined governance scheme for who owns or contributes to the design system, as well as a consistent user experience, helping teams to deploy features more quickly, make rebranding changes more efficiently, and freeing up time to deal with complex UX challenges.

On a broader level, the benefits of having a design system can be categorized as follows:

• Reduced cost: having everything in one place reduces the amount of work done by multiple teams.
• Boosted confidence: having clear instructions on developing a given user interface gives the team more confidence.
• Elevated empathy: when everyone in the team contributes to the core design system, it elevates empathy between the teams.
• Defined principles: design systems help designers, developers, marketers, and project managers define fundamental design principles.
• Improved productivity: productivity improves immediately when everything originates from a single source.

Build consistent front-end experiences

Building a consistent front-end experience requires a well-documented, standardized set of UI blocks that can help team members to understand the basic foundation on which UI is built. It increases output speed and encourages collaboration among members to develop and implement features in time. Furthermore, because conflicts are less likely to arise, companies can ship features faster than they could without a design system.

Three important factors to keep in mind when using a design system are:

• Make use of open-source: not all companies can afford to build a design system from scratch. Instead of consistently building components from scratch, make the most of existing patterns or adopt open source libraries. Before building, ask yourself if it’s covering multiple use cases or solely focused on single-use cases? This also reduces time and encourages reusability; a more sustainable way to build a design system.

Here’s a curated selection of the most important open source component libraries that you can use as a foundation for your design system. Also, check out why you should use open-source component libraries in your design system?

• Documentation: a scattered product is always protected by documentation. If sufficient documentation is not available for reference, the reusability of components becomes problematic for a newly onboarded member. Documentation that is well-written can help new members get started. There should be examples and counter-examples provided for each section. Not only is it important to create documentation, but it is also vital to update it on a regular basis.
• Enforcement: design systems require a set of predefined rules to follow, and teams should adhere to the patterns created. Processes that aren’t necessary should be avoided at all costs because they waste time and slow down the process.

Keep quality and maintainability under control

A design system not only ensures quality and maintainability but also reduces maintenance costs and streamlines the release process. As the design system evolves, it’s essential to keep an eye out for ways to simplify around us in order to limit the number of designs that aren’t regularly used. Invest in equipment and automated solutions for testing rather than wasting money on non-essential components.

• Release process: according to a study done by Figma’s team, when designers and developers have access to a design system, they finish their goal 34% faster, increasing the pace at which a product is released to the market. Increased speed in the release cycle brings the product up-to-date with the competition. It also provides backward compatibility for teams who choose to roll back. An automated build/release procedure based on CI/CD should be implemented. Additionally, all release information should be sent across different channels to ensure that all teams are informed.
• Feedback loops: surveys should be undertaken at regular intervals within teams to determine what needs to be improved. With these surveys, we can learn about the requirements and priorities that must be addressed as soon as possible. With this well-maintained system, backlog concerns can be addressed with total attention and resolved within a reasonable time limit.

Keep developers and designers in sync

Keeping developers and designers in sync is a big challenge. Both of them should be aligned if we want to deliver a good quality product.

• Open to contributions: establishing contribution rules can be accomplished by keeping everyone on the same page. Companies with well-established collaboration strategies and high maturity across disciplines may find contribution easier. Contribution in the form of fresh ideas, analyzing consumer behavior, and expressing what is necessary is also essential. From a technological standpoint, a streamlined pipeline for processing pull requests and dashboards for bugs and features should be maintained so that everyone can view the backlogs and advanced features. Shipping a product made with a design system is not the responsibility of a sole individual. Consistent and collaborative team efforts can give tremendous results.
• Collaboration: collaboration is a must. Being on the same page and everyone knowing their goal and vision boosts team productivity. There should be room for opinions, and enough flexibility for teams to make decisions. Different opinions can sometimes create chaos, but they should never be a blocker for a team. Creating a strategic plan and timeline that everyone is aware of and following creates transparency. Furthermore, design systems are developed over time. So, if a team encounters a roadblock during development, they can modify the design system accordingly. This prevents other teams from experiencing similar problems in the future. The majority of the work is managed by standard guidelines, which address functionality and ensure that everyone is working towards a common goal.

To go further, you could check Backlight design system tooling platform, which offers multiple features to help you build your design systems: automated CI, starter-kits to lower the cost of starting a design system (React, Vue, Svelte, Web Components, and more), powerful built-in documentation support, support for Storybook’s component story format, real-time components rendering, real-time collaboration, code and visual reviews, online IDE, git integration, …

Originally published at https://backlight.dev by @soniasinglas on June 2nd, 2022. Backlight is a collaborative platform to ship design systems on the dev side.

3 pillars of a successful design system was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many of you have probably heard about the advantages of a design system by now; they can bring huge benefits in efficiency and quality in product development. However, building a design system can be hard and sometimes involves a lengthy process that can be costly to teams in both time and resources.

Not clearly defining the value or mission of our design system, ignoring how the components interact within it or avoiding collaboration with developers, can all lead to costly mistakes when developing a design system. Yet, these mistakes can be avoided if we pay attention to a few key points during the creation process.

In this article, we are going to look at 5 things to avoid when building a design system:

🦀 Building from scratch

Not all companies can afford to build a design system from scratch because it requires a lot of capital and resources. It is usually preferable, and more cost-efficient, to take advantage of existing solutions rather than beginning from scratch.

Choosing a ready-made solution on the market that meets your product needs can save tons of resources. Working from an existing system is less exhausting than completely reinventing the wheel. Starter kits, component libraries, and other pre-built features are all included in ready-made solutions, saving you time and allowing you and your team to focus on other aspects of your product.

⭐️ Backlight comes with several starter kits to lower the cost of starting a design system. We have starter kits in React, Vue, Svelte, Web Components and more on the way.

🛳 Building only for the here and now

A design system isn’t just a thing of today; it’s an ever-evolving mechanism that lasts a long time. While we’re building it, we should also be considering the future. Anticipating future features or concerns allows for a wider product variety while also ensuring scalability. Plus, a design system’s ability to scale alongside the product could make or break it. To be future-proof, using Web Components is a terrific idea, as they provide control over how to design them, allowing you to simply customize components as needed, build future-proof components, and aid adoption.

Here’s a curated selection of the most essential open-source component libraries that you may want to use as a foundation for your design system. Also, check out why you should use open-source component libraries in your design system

⛳️ Focusing only on the UI of the design system

Thinking solely about the UI of the design system is a mistake many teams make. The design system will most likely be consumed by both your product team and end-users, as both are by definition “users” of the design system. As well as UI, the UX of the design system is an important aspect to consider and is what gives users a better experience. Concentrating only on the visual aspect won’t help us make a top-notch product. Focusing on the adoption of the design system can help us to improve its UX. As per a study done by Design Management Institute (DMI), products that place priority on human-centric design get 211% higher ROI than the S&P 500.

Integrating content design into your design system can also help to improve the overall experience of using it. Websites and apps that focus on content design are often clearer and easier to use. Good content design can also make a website clear and intelligible for SEO purposes, encouraging readers to interact with it. The more visitors that interact with your site, the more search engines like it.

💡 Check out why your design system needs content design.

⛓ Building based on gut feelings

Many design systems today are so well-documented that they leave little room for guesswork. If you’re unsure of how to build your design system, a quick benchmark of existing ones can be a great place to start. There’s no longer a need to make gut-based decisions or reinvent the wheel. A lot of the work has already been done, and it’s simply a matter of taking inspiration from the best. To help you, here’s a curated list of some of the best design system documentation sites.

Collaboration is also key to building a design system. It is a team effort and few good design systems have been built by a single person. Design and development need to work together to make sure design and code are in-sync and properly documented. Other disciplines might also come into the picture, such as UX writers and product managers. To build a design system that works for the entire front-end team, it’s essential to rely on your colleagues and ask questions that could avoid costly mistakes.

Backlight, an all-in-one design system tool, offers collaborative features such as real-time previews, built-in documentation support, visual feedback, and much more. Backlight also comes with a number of starter kits to help you kick-start your design system journey.

🧰 Not picking the right tools

Building a design system is hard enough as it is. If we add inadequate tooling to the mix, the process only gets harder. Ten years ago, the tools available to build design systems efficiently were few and far between. Today, however, there is a myriad of tools that make life much easier for front-end teams of all sizes.

Automation is a big one. Wherever it’s possible to automate manual or time-consuming processes, we should. Luckily, there are now plenty of tools that automate for us, from documenting automatically to automated testing.

Tools that facilitate collaboration and alignment between design and development are also important to invest in. One of the hardest parts about building a design system is the collaboration across disciplines, and tools can help us mitigate the efforts. Tools like Backlight, for example, allow any discipline from the team to view, comment, and contribute to the design system, regardless of their technical level. To keep code and design aligned and in sync, we have story.to.design: a Figma plugin that automatically generates Figma components directly from Storybook code.

⭐️ Take a look at our curated list of the best tools for building design systems.

Originally published at https://backlight.dev by @soniasinglas on June 21th, 2022. Backlight is a collaborative platform to ship design systems on the dev side.

Finding the right names for things is an art. Speak to most content professionals and they’ll tell you that naming can be hard. Fun, but hard. Some naming exercises require creativity and originality, such as coming up with the name for a new product. However, other naming tasks come down to logic and clarity. Design systems fall into this second category. Naming components is less about originality and more about ease of understanding and standardization.

Why should we care about naming in design systems?

• Get the team to speak the same language: One of the main goals of a design system is to establish a unified design language, so different teams use a single design language when building a given product. However, if we don’t give any thought to how we name things in our design system (design tokens, components, patterns, etc.), we’re missing a huge opportunity to create synergy between designers and developers when they talk about elements in the design system. Imagine developers call a given component one thing and designers another. This not only leads to miscommunication, but can also create huge inefficiencies when it comes to updating a component from design to code, and vice versa.
• Transform abstract ideas into tangible ones: Finding good names for the elements of our design system is an exercise in taking abstract concepts and making them clear and tangible. Let’s take the example of the Accordion component (also referred to sometimes as Collapsible sections or Arrow toggle). This component is essentially a vertical stack of headings that can be interacted with to display further information. This can be quite abstract and hard for some to visualize. Giving it a name like Accordion, which describes what it looks like, allows us to more clearly visualize the component and understand what it is.
• Alignment between code and design: Many front-end teams still struggle with alignment between code and design, and vice versa. Finding common names for elements of our design system should be a joint, collaborative exercise with the goal of using the same names on the code-side (Storybook, etc.) and on the design-side (Figma, etc.). This makes it easier for everyone on the team to “speak the same language” when talking about design systems and eases collaboration.

Best practices for naming elements in a design system

When thinking of names for any part of your design system, keep in mind that they should generally be:

• Logical: Describe the component clearly, using a name that represents it. For example, the name Accordion describes the component visually and even how it works when a user interacts with it.
• Scalable: Find names that allow for possible variations or additions to the component that could come in the future. For example, when categorizing text style sizes, it’s often best to use T-shirt sizing (S, M, L, XL) as there is always the possibility of adding more sizes in the future. Typically the main size will be M, so both smaller and larger sizes can be introduced as needed.
• Simple: Keep names short and basic. 1–2 words is often enough for a component, and if more details are needed this can be done through the use of forward slashes to represent further categorization. Use names that are commonly understood and avoid long or unique names that require someone to look it up or ask what it represents.
• Standardized: The best component names are the ones used over and over again by most people in the industry. Button is a great example. It has become so standardized, it’s very hard to find any other name for this component. If you need help finding the most standardly-used component names, sites like UI Guideline or Component Gallery are great resources. They gather the most common component names used in the best design systems.

Some decisions to make when naming

States: The different states of a component need names, too. It’s important to follow the same best practices above and find names that are logical and standard, or otherwise clearly defined. The most common names for component states include:

• Enabled: An interactive component/element that the user can usually click on or interact with.
• Hover: A visual cue to show users that they are hovering over the component concerned.
• Focused: Triggered when a user has highlighted an item, using an input method such as a keyboard or voice.
• Pressed: A visual indicator for the user to confirm that the component has just been clicked.
• Disabled: The opposite of the “Enabled” state. It, therefore, indicates that the component is inactive and therefore not clickable.
• Visited: Mainly used on links to indicate which links the user already clicked on.
• Error: Concerns mainly form components to indicate input errors to the user visually.
• Validated: Indicates to the user that what they filled is correct and complete. It is a feedback on an action just completed.
• Read-only: Somewhere between an “enabled” and “disabled” state. User can’t interact with the component, but it’s essential to display the component to indicate it has been properly activated.

Colors: While it seems counterintuitive, colors should not take the name of the actual color itself (blue, red, green), but one that represents its function. If your product or company were to undergo a full rebranding, for example, it’s likely the colors will change, forcing you to rename every single color token. Plus, using the actual colors as names doesn’t give design system users any indication of when, where, or how to use that particular color. Instead, the most common names for colors include:

• Branding: primary, secondary, tertiary…
• Functional: success, warning, informational…
• Greyscale: grey-000, grey-100…

Casing: While choosing a casing style really only concerns naming on the code-side, it can still influence the structure of component names and might be reflected somewhere in documentation or in design. There are 4 common casing styles for naming on the code-side:

• camelCase: No spaces and each word is capitalized except the first one. Most commonly used for variables and functions in JavaScript.
• PascalCase: All words are capitalized including the first one and all spaces are removed. It is commonly used for C# and Java.
• kebab-case: Replace the spaces with a hyphen “-” between each word and make sure all words are lowercase. It is commonly used for CSS and HTML5.
• snake_case: Very similar to the kebab-case, the only difference being the use of underscores “_” to separate each word. It’s commonly used for database programs such as SQL databases, but also with PHP or Python.

Breaking down a component’s name: Most components typically have several types, variations, states and even themes. It’s important to clearly organize the name of components to reflect these differences, using a forward slash to break it down:

[Category] / [Component] / [Type / Variant] / [State] / [Theme]

E.g.: Actions / Button / Primary / Hover / Dark

Alignment across all design system tools/programs: More than a decision to make, this is a step to take when tackling naming. Developers and designers typically use different tools to work on a design system. Plus, there is the documentation site. It’s all too common to find components in Storybook called one thing and those same components in Figma called something else. Certain tools, like Backlight, keep code, stories, design, and documentation in one place. This makes it much easier to maintain alignment across component naming. However, it’s still a team exercise that requires consensus and alignment on names, making sure they’re consistent across all tools used to build the design system.

So, where to begin?

If you’re starting a design system from scratch, you have the perfect blank canvas to start naming components following the guidelines above. However, it’s more likely that you already have a design system in place, and that some names are unclear, inconsistent across tools or need a little attention. A great place to start is with a component naming workshop with your design system team. Do an audit of everything you have and see where these naming conventions can be applied.

Another approach is to benchmark other design systems. Here is a curated a list of some of the best design systems to turn to for inspiration. Take 2 or 3 design systems and see how they organize their categories, structure their components’ names, and reference their design tokens.

Pick a method that works best for your team and design system, and stick to it. Bonus: if you have a UX writer or content designer in your team, ask them for help! It’s yet another example of how content design practice can benefit your design system.

Originally published at https://backlight.dev by Ardena on June 16th, 2022.

Naming conventions for design systems was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building a design system that ensures a coherent user experience is only possible if the entire team is aligned toward the same goal. It has the ability to improve user experience by offering consistency and accessibility, which encourages adoption. Maintaining and scaling design systems takes time and resources. Team members must embrace a design system in order to demonstrate its usefulness. Getting people to contribute to a design system offers them ownership, which leads to wider use. In order to increase usage and obtain feedback for changes, a design system must engage with teams across the organization.

This is why advocacy is a valuable tool. Advocating for your design system doesn’t mean imposing it on teams, but rather a process of education so it can be adopted easily. It means working together with the teams who will use the design system, and learning valuable insights along the way.

First and foremost, your design system must be adopted and accepted by your own team. And, without a doubt, we must be the biggest advocates of our design system, since no one else will.

Let’s look at how to get your design system adopted by your team, advocate for your design system, and how documentation can help.

Design system adoption in product teams

Adoption of the system relies heavily on shared understanding. It will only be helpful if the individuals working on the product actually adopt the design system.

Implementing a design system is much more than just translating a design into code for the developers. They must convince other developers who are building the applications to adopt their components in order to generate and distribute components. They must lay the necessary groundwork for a standardized and collaborative component ecosystem. Over time, adding, maintaining, and updating the components to make sure everyone can use them without being blocked drives design system adoption in the product team.

Adopting some of these best practices will definitely help design, engineering, and product teams alike.

Create a living style guide

Strong documentation for a design system isn’t just a “nice to have”. A design system lives by it, it is a step-by-step guide for putting your design system into action. An excellent style guide and documentation should be easy to find, automatically updated and relevant to the whole team. It should be the go-to place for everyone looking for information, and everyone should feel confident that they will be able to find answers to their queries there.

For new developers joining the team, live previews of code or documentation can make things easier. It will help them familiarize themselves with the coding style and teach them best practices. Providing enough documentation links and resources also helps paint a clearer picture for new hires.

Adoption is the key to a design system’s long-term success, and appropriate documentation encourages it. As adoption develops, your design teams will produce consistent, high-quality work.

Reusable component ecosystem

A successful design system is, to a large extent, reusable; guided by clear standards, and assembled to build products together. The design system is a set of reusable components shared and used by everyone in the organization.

Collaboration between designers and developers is one of the most crucial aspects of a reusable component system. For example, we have two teams, A and B. Team A uses React while team B uses VanillaJS. When considering our design system, our focus should be on building components that can accommodate multiple frameworks, and provide flexibility, without restricting developers from using a particular framework. This will ultimately encourage adoption among different teams.

As a result of the Covid-19 pandemic, many companies are working remotely, increasing the need for strong collaboration. Flexible, adaptable, and reusable components allow cross-functional teams, designers, and engineers to perform their tasks effectively while using their unique skillsets. Reusable components scale the whole design system and avoid unnecessary, repetitive design decisions for the same component. The design system’s users will be able to interact with the application effectively, have a consistent experience and eventually become familiar with the company’s brand.

Automation to the rescue

Many companies want their designers to create and ship new features to development more quickly than ever. If we analyze the process of building, adopting, and maintaining a design system, we may observe that there are many areas that can be automated for greater optimization. For example, in the middle of a project, it can be difficult to identify redundant sections of code. It increases the frustration when developers with different styles collaborate and try to write in a single manner. This is where a tool like ESLint comes into play. Due to its versatility, it has become a popular component for many projects, saving a lot of time and making designers happy. To learn more about design system best practices with ESLint, check out this series.

How to advocate for your design system

You can build the finest design system in the world, but if you do not advocate for it within your organization, it will eventually fail. It is crucial to advocate for your design system from the beginning. That is why, right from the start, we must take the initiatives to advocate our own design system’s adoption. This can be achieved by building a community of advocates that promote system thinking and offer education in the form of talks and workshops.

These actions should have the same goal: to promote knowledge of the design system’s existence and educate people on how to use it.

Share knowledge at design meet-ups and conferences

Encourage members of your team to join you at meet-ups, and share your knowledge by attending and participating in seminars at conferences. These seminars provide an excellent chance to network, gain new information and become more comfortable sharing our perspectives. It is incredibly beneficial to one’s personal growth. The world gets to know about our design system and we raise awareness about how we are using it.

Create a safe space for honest conversation

It is critical to creating a secure atmosphere for people to express their genuine thoughts and ensure that everyone is heard. It is a chance for product designers to speak up about their work and obtain constructive feedback. Encourage people in the meetings to share their creative ideas and issues they face daily and provide clarity on the problems. Spot the team’s common design issues, take necessary steps and offer related resources to tackle them.

Regular updates hold the team together and provide transparency and clarity on the working status in terms of development.

Case studies, user stories, and behind-the-scenes

Use case studies to promote your own design system. This can assist in providing a clearer picture of what should and should not be done in order to adopt the greatest design system. It gives a sense of confidence within the team and can help get different perspectives and learnings from the outside world. Encourage the team to study design system articles and books, such as Brad Frost’s Atomic Design.

Encourage contribution to the design system

People want to do more than just join; they want to contribute. The contribution comes in multiple forms other than designing and coding, but also through words of mouth, such as hackathons, conferences, blog posts, and meet-ups. This promotes our design system to the rest of the globe and creates an alliance of developer advocates who will represent and sponsor your company’s design system.

Documentation — a tool for easy adoption

It isn’t a design system if no one adopts it! The design system’s advocates must communicate the benefits of their work to colleagues and ensure their help during the adoption stage. Creating an excellent style guide is one of the best ways to accomplish this. Documentation promotes adoption in several ways. Providing a clear reference for someone who has just started with the design system is one example. It can be treated as a single source to put all the set-up guidelines and resources, eliminating ambiguity or the need to look in multiple places and get confused about which rules to adhere to.

In addition, documentation should answer any “Why” and “How” questions, which will undoubtedly dispel a developer’s or designer’s uncertainties. Questions such as how to use a specific component, when and where to use it, and which color guidelines to follow. All of these questions should be addressed in the documentation. If all of this is in place, the team will find it much easier to implement the design system.

We can take some inspiration from the best design system documentation sites.

Because design systems are constantly developing, skilled governance is required to ensure long-term viability. Including a contribution and governance approach in our style guide can be very helpful. And codifying these can allow it to expand organically without breaking, which relieves the design system team of pressure.

Having documentation doesn’t guarantee a successful design system, but having it can offer numerous advantages for establishing a lasting design legacy.

To dig deeper, check out this blog post on design system documentation best practices, written by Thais Santos, Design Lead at DivRiots.

Consistent advocacy is the key

The main issue of design systems is adoption. To get others to embrace your design system means the need for regular updates, especially as the team evolves. That is to say, if you want a design system to have a long-term impact, you need to consistently advocate for it.

Originally published at https://backlight.dev by @soniasinglas on May 24th, 2022. Backlight is a collaborative platform to ship design systems on the dev side.

Advocating for your design system was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

The big question is: why are these IT powerhouses focused on web components? Are they really so important? During the last decade, the use of web components has skyrocketed, and they have become one of the most popular new web platform technologies. Web components prove to be quite valuable in a wide range of applications.

Why build a design system using web components?

Web components are interchangeable between frameworks and libraries because of their compatibility with a variety of tech stacks. They offer cross-platform development and ensure brand consistency. Web components allow us to break up a complex web app into reusable pieces that will reliably look and function the same, regardless of what they share a page with. They offer a consistent approach to interfacing with them via their attributes, and they are mainly focused on doing one thing well. Another advantage of web components is that when built on top of browser APIs/standards rather than frameworks, the JavaScript footprint of the design system is way lighter, which is key for site performance.

Easy to customize and standardize styles

One of the primary characteristics of web components is the ability to create customized pieces that may be adjusted and incorporated into the design system. Any design can be stylized and customized with web components. We can build a customizable UI component library using HTML/CSS/JS to meet brand standards.

Supported by modern browsers

All evergreen browsers, Chrome, Opera, Safari, Firefox, and Edge, support web component standards. It implies that the APIs Custom Elements, HTML Templates, Shadow DOM and ES Modules are fully functional and provide full support with these browsers. It makes developers’ and designers’ lives easier since they can write on top of customizable HTML tags without worrying about the frameworks and libraries.

Framework-independent

In big companies, different teams contribute towards various areas of a project. These teams are primarily independent, which means that they build the applications using their own tools and frameworks. However, as a business, you would want to ensure that the user experience is consistent throughout the product, regardless of what each team decides to work with. It is advisable to create a library of web components, independent of any framework. In doing so, these components can be used interchangeably by the teams regardless of the framework they are using.

However, there are caveats to using web components with some frameworks like React and Angular. The main problem while using React is React’s inability to bind the custom events from web components and its inability to pass rich data due to the lack of property binding into custom elements. The Angular framework, on the other hand, is reliant on its own web component library, which leads to plenty of issues when it comes to importing and configuring packages.

Accessibility

Web components can be made accessible. For a web component to be interactive, e.g. any UI control, it should be keyboard focusable. WAI-ARIA Authoring Practices can help with this. The states of interactive controls include focus, hover, and active. They should all be easily visible and ideally, each has a distinct look.

The page when controlled by assistive technology helps users interact with web components using a keyboard, mouse, etc.

Another way to make custom elements more accessible is by using the proper aria attributes; all we have to do is follow the WAI-ARIA definitions. Let’s take a look at an example, an accessible slider component built using a web component:

Accessible slider component built with web component

It’s not always the case that Shadow DOM will help in achieving accessibility, sometimes it can make things harder.

ARIA references through properties like aria-describedby and aria-labelledby have a value that represents the id of the element they describe or label. If there is a shadow boundary between the id and the element that references it through aria- , the reference is essentially broken and does not work. To work around that, you could project the element into the Light DOM instead, by using slots for example.

Another example is <form> and custom input elements. If there is a shadow boundary between the native form and the native input element that the custom element is wrapping, the input will not participate in the form. Form Participation API is meant to solve this problem but has not been shipped by Firefox and Safari yet. For now, this can be solved in a similar manner as the previous issue, by projecting the native inputs into Light DOM.

💡 Take a look at all the ways to make a web component.

Encapsulation

All of the encapsulation of styles is provided by the Shadow DOM. It separates your components from the rest of your document by giving them their own DOM. This means that global styles (excluding CSS custom properties/variables and inherited styles) have no effect on it, and its own styles have no effect on other elements in the parent document. We won’t have to worry about CSS leaks or naming conventions anymore because the HTML and CSS code inside a shadow DOM isn’t visible to the main DOM. Exceptions are:

• CSS Custom Properties
• Inherited styles
• ::part (shadow parts)

Shadow DOM has the opposite purpose of global stylesheets. If we are creating a reusable component that needs to use a global stylesheet like Tailwind or Bootstrap, we can turn Shadow DOM off. Though, with encapsulation, the developer has complete control over the API and which features are made available to its users. With Shadow DOM, developers can also open up DOM nodes to styling from outside by exposing them as shadow parts.

Conclusion

Web components offer more than the features mentioned above. They are production-ready, as companies like GitHub are using open source web components. You can read more here.

Writing accessible components from scratch is costly and not all companies can afford to do it. Thanks to web components, we can incorporate existing open source component libraries into our design system, or build our own using a white label-based layer like Lion. Here’s a curated selection of the most important open source component libraries that you can use as a foundation for your design system. Also, check out why you should use open source component libraries in your design system.

Originally published at https://backlight.dev by @soniasinglas and @jorenbroekema on May 19th, 2022. Backlight is a collaborative platform to ship design systems on the dev side.

5 Reasons to use web components in your design system was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Animation in Design Systems

Have you ever wondered why users dislike static objects? Motion, we believe, always draws the user’s attention. We can detect movement outside the center of our view range when reading a book. However, this means that we are sensitive to motion and are easily distracted by it. Nowadays, animation in design systems has been a hot topic for debate.

Animation has become the building block for usability among UX and UI designers due to its potential to impress people. Although there are many developers and designers who believe that animation is an unwanted feature that overburdens and complicates the user interface, others believe that it is a vital part of user interaction.

Let’s look at what motion does in design, what it brings to the table, when and when not to use, and the various aspects of documenting animation.

What Motion Does in Design

In an era with low user attention levels, visuals in the form of animations can successfully seize a user’s interest. Animation offers a convincing experience that no other form of content can match. Animation is a game-changer in delivering a clear picture of a brand’s value, raising user retention, providing feedback, building relationships with the product, and reaching a passive audience.

We’ve always thought of animations as a filler that doesn’t play a big part, but we’ve never considered its strength. Using motion in UI design goes beyond just adding visual interest.

🦄 Brand Expression

Colors, logos, and catchy taglines are the first things that come to mind when considering the aspects that define a brand. On the other hand, Motion has the same ability to become a distinguishing feature of a brand and its connected experiences. It is the most powerful medium to build the user’s trust. A well-thought-out explainer animation will assist you in emphasizing why a customer should choose your product or service. Animations must have the depth to drive your audience’s behaviour.

💡 Providing Feedback

When used effectively, motion provides essential input at crucial times in a user’s journey. This could include indicating their next steps and conveying whether or not an action was successful. With this feedback, users can work more efficiently, accomplish tasks, and find the information they need. The animation of a navigation menu moving across the page when a hamburger icon is tapped is a typical example. Because our visual systems are sensitive to movement, a brief animation helps ensure that users perceive the feedback.

🎖 User’s Retention

We are continuously bombarded with new information on the web, which is a fast-paced environment. As attention spans get shorter, the number of distractions grows. At that moment, motion stands out to be a fantastic technique for capturing user attention within interactive experiences.

✌ Build Relationships

Users can better develop mental maps to understand spatial links between content by using intelligent and consistent motion patterns, allowing them to navigate with ease. Animation can be handy when we have a complex UI as it can help the user to navigate to the content for which they are looking.

In UI design, motion serves more than just practical purposes. It can also be used to generate those tiny magical moments that thrill consumers and boost their affection for the apps, goods, and services they use most frequently. Animation makes the system more engaging and builds a strong emotional bond with the user.

📝 Documenting Animation

Documentation is undoubtedly one of the pillars of any design system, but there is no proper way to standardize the animations in terms of how they should be developed, delivered, and maintained further. But adopting some of the best practices will definitely help the design, engineering, and product team. Having animations documented is not separate but crucial for the internal team members to get them on board and follow best practices.

The initial step towards documentation involves:

• Defining Token: Design Tokens are the brand’s foundation, offering consistency and scalability to the whole system. Velocity, Trigger, Easing, Attributes are the key features that need to be documented while defining tokens.
• Building Fundamental Animation: There should be proper guidelines around building basic animations and patterns such as mouse-hover, zoom, parallax, … benefiting both the dev and design teams.
• Designing Brand Definition: well-written documentation is helpful for designers and developers to find out the vision of the brand.

You can take references from the Material Design by Google 🔖

When multiple people collaborate on a working project with different users in mind, it is easy to slip into the trap of outdated information. The aim of defining the fundamentals is to maintain consistency and easier system-wide reach. By defining some basic animation, other team members can get into the mentality that has been established as the project progresses. Everyone agrees on what to use when to use it, and how to use it.

Animation: When and When Not to Use

🤔 Is It Required?

The animation must serve a purpose. The good use of animation is always appreciated as it not only helps the user to navigate well but also to connect and indulge. Adding motion to your UI solely for the sake of aesthetics can be harmful. It creates confusion and effect on what a developer or designer aims to achieve for their app/website. However, instead of focusing solely on adding animation, we should consider the bigger picture, as it may impact our whole user experience.

⚖️ Right Balance

The animation must adhere to the key requirements to serve its purpose right. The four fundamental characteristics that can utilize the token hosting involves Duration, Delay, Timing function and Direction. The MDN docs are a good resource to learn that. Depending upon the importance of the process, and what the animation is for, the sub-properties should be decided.

For example: As per studies, a great UI animation should last between 200 to 500 ms. The duration of animation for the whole screen should be a bit longer as compared to click and hover animation.

👩🏻‍💻 Adhere to User Expectations

The majority of consumers have a preconceived notion of how things should work based on their previous experiences. They anticipate things to function in a specific way. As already described before, the animation should be simple, and it should become more simpler as users see it more often. It must also serve its purpose, and grab the user’s attention.

Did you know ? Backlight, is an all-in-one design system tool on the code side, offering features such as real-time preview environment, built-in documentation support, visual feedback, and much more. It comes with a number of starter-kits to help you jump into your design journey at no cost 💸 Isn’t it amazing? 😉

Originally published at https://backlight.dev by @soniasinglas on May 5th, 2022. Backlight is a collaborative platform to ship design systems on the dev side.

Why you should document Design System animation was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everything in today’s world is constantly evolving, including the design system. But are we absolutely sure that our design system is adaptable enough to handle new changes, reliable enough to face new problems, and scalable enough to accommodate further modifications? Because of all of these questions, the topic of Governing our Design System has gotten a lot of attention. Nevertheless, some people believe that design system governance is a barrier to rapid growth and scalability. However, the majority agrees that it boosts scalability and creativity if executed correctly with consistency.

This article will take you from the challenges that a design system faces to how design system governance can help you overcome them.

Challenges

Poor Communication and Weak Documentation

Communication is the glue that holds the design system together; however, effective communication between different departments has become a major issue for the company to address. Before investing our time and efforts into writing a design system, we need to know and understand the organization’s pain points and how can we blend them using the design system. Discuss what their needs and expectations are. It will help avoid roadblocks in the workflow.

Since communication can lead to the loss of important aspects, document the meeting notes. When communicating and documenting the vision, it’s important to be clear about the organization’s goals. To make your design system serve the needs of multiple product teams, outline the main design principles.

Backlight takes care of your documentation headache by providing support for various documentation frameworks such as MDX, mdjs, and even Astro.

Different Individuals, Different Mindsets

A design system’s full potential is often hindered by internal disputes. Sometimes, developers or designers often use their own version of tokens and components. This hesitancy can harm the product’s use and consistency and cause unnecessary disputes. Rather than following one’s intuition, follow the vision and standards set by the organization. A well-designed governance plan should be followed to restrict this behavior. It brings value to the product in the longer term.

While Backlight is a code-centric tool, designers love using it too. Figma plugin helps designers generate UI kits and maintain libraries when the code changes.

Scattered Toolkits

For a good design system, there should be a single source of truth that everyone can refer to, whether from the design team, engineering team, or the product team. Maintaining a single source is quite challenging. Also, avoid using overly complicated design system components. It should be easy to use each design system component to build more complex blocks. It will allow the system to scale. A design system is more than just coding. It facilitates the communication between cross-product trio: design, engineering, and product management.

Backlight includes several starter kits to help you get started with your design system at a lesser cost.

Establishing Design System Governance Standards

How do you define design system governance standards? How do we know we are on the right track in developing and designing? Designers rely on their own set of principles when it comes to evaluating the quality of design. But as the team expands, it becomes cluttered and difficult to accommodate different people with their own unique approaches and ideas. This is when the design system governance standards come to the rescue.

A successful design system is reusable to a large extent. Every team faces the same problem — creating components focused on a single-use case. It forces the designers and developers to develop and write new components every time. Build components that are not limited to single-use cases but can be tweaked and extended to work in various situations. Avoid having dependencies. Consider how a new component will work across multiple platforms.

Another important standard that needs to be counted is accessibility. Having accessibility in design pattern directly accelerate the growth of the product. You can read more about the importance of accessibility in design systems by Thais, Design Lead at DivRiots.

Also, there is a massive need for people who can provide honest reviews around the product design, and scheduling brain trust meetings can be very helpful. It offers people the freedom to be innovative by removing authority from brain trust meetings. As the design system evolves, we need a well-defined process to manage the contribution workflows. The system should be open, collaborative, and simple to use.

Documentation and Communication

Documentation and Communication are the two primary pillars of a well-designed system. Having roadmaps, meeting notes, and well-written scripts for the design system’s components and tokens helps accelerate the product growth. They provide a variety of functions for both the team and the stakeholders. They assist a team in planning and prioritizing the product’s subsequent rollouts.

Well-curated roadmaps improve communication and collaboration among teams and departments as they can benefit every product release. It’s a strategic plan in timeline format for team members to visualize each initiative and milestone, thus creating transparency and managing expectations. During meetings, writing critical information can help significantly to get better outcomes. Make sure to have an agenda before scheduling meetings.

Incorporating the contribution and governance model into your design system, documentation acts as a defence against a scattered product. For a beginner, component design and coding might be a subject of concern. And it can be difficult for someone to use an already built component if there is no proper documentation available to guide. Well-written documentation can help and give a head start to new members. A style guide allows you to tie everything together and develop an understanding of component usage and purpose.

Backlight: all-in-one design system solution

The purpose of design system governance is to gather all the required parts and build solutions that are consistent across the entire product. Design system teams have a lot on their plate, whether it’s designing and producing assets or writing documentation. It would be difficult to collect, prioritize, and act on comments and new ideas if there was no governance mechanism in place.

Want to speed up your design process? 🤫

Backlight empowers front-end teams to build and ship great design systems. A unique, all-in-one design system solution. For developers, loved by designers.

Backlight bridges the gap between design and code by establishing a single source of truth, ensuring that designers and engineers always use the same tools.

Backlight embraces collaboration across all disciplines. Forget tickets and manual updates. A visually-organized component library, instant sharing, and live documentation mean anyone can contribute to your design system.

Originally published at https://backlight.dev by @soniasinglas on May 3rd, 2022. Backlight is a collaborative platform to ship design systems on the dev side.

Lastlty, I published why your design system needs content design. It’s now time to follow-up with how to include content design in your design system. While there are general best practices for documenting a design system, in this post we’ll focus on those specific to content design documentation. Whether you’re starting from scratch, or already have some guidelines in place, these best practices can help make sure content design is fully integrated in your design system documentation.

Document a component’s content and design guidelines together

Many companies already have some sort of content guidelines as a part of their brand book or style guide. While it’s tempting to just add a link to these somewhere in your design system and call it a day, this isn’t enough to integrate content design effectively.

A next step might be to create a specific section for content design, and group all guidelines here. While it’s better than just adding a link, it still creates a division between “content” and everything else. It suggests that content is just a nice-to-have bonus, as opposed to a core element to designing experiences. A separate content design section can be useful for very general guidelines that apply to all writing throughout a product. However, it is not the place to reference guidelines specific to a component or pattern.

So, what’s the best way? Content design impacts a user’s experience just as much as visual, functional, and technical design. Content guidelines should be incorporated right where users are most likely to see and follow them. They should be embedded within the documentation of a component, in the same way visual design conventions are.

Use realistic copy examples in components

It’s tempting to use placeholder copy (such as lorem ipsum), or instructional copy (like “insert label here”) in documentation and component previews. However, this only creates a missed opportunity to really show what good content design looks like. Using realistic copy helps design system users to understand the context in which a component or pattern could be used, as well as indicating proper content formatting (e.g.: length, sentence case, grammar, etc.).

Guidelines should be specific, focused, and useful

Is there a rule that must be followed? Distinguish it from the recommendations. Is there a given format or structure for the copy of a particular component? Clearly outline it. Is there a specific call-to-action to use in a button for a given scenario? Indicate it (ideally in the button’s documentation).

The more precise and contextualized content guidelines are, the more useful they will be.

Create a clear list of DO’s and DONT’s

A UX writer or content designer might find the guideline “Use sentence case” to be enough to follow the rule. But we need to keep in mind that most design system users are not UX writers, and may not know how to follow this guideline. Examples are a MUST! For every guideline, it’s always best to illustrate it with a clear “Do” and “Don’t”. The more “Do” and “Don’t” examples presented, the easier it will be to follow. If we take our example above, the full guideline could look something like this:

Always follow sentence case for all titles, subtitles, and paragraph text.

DON’T ❌ : “Account Log-In” or “Design System Best Practices”

DO ✅ : “Account log-in” or “Design system best practices”

Start small and build progressively

Build on your content design guidelines as your team needs them. Not every product requires a design system as complete or advanced as Polaris, for example. While tools like Backlight can greatly speed up the process and collaboration involved in building a design system, these still require time and resources. Don’t waste them adding guidelines and documentation that nobody will ever use or read. Start with the basic rules and guidelines you see most repeatedly in your product and go from there.

Consider inclusivity and accessibility

Accessibility is something that should be embedded from the start when designing and building components. It should be for content, too. If you’re just starting out crafting the content design guidelines in your design system, it’s a great opportunity to consider accessibility and inclusiveness right from the beginning. If you already have existing content guidelines in your design system, start asking yourself how they can account for inclusivity and accessibility. What words should not be used? What words should be used instead? How can the guidelines help create content that’s anti-racist, inclusive of all genders, and anti-ableist, for example? When creating inclusive and accessible content guidelines the most important part of the process is to include, and get feedback from, the very communities you want to serve.

Get inspired by existing design systems

There’s no need to reinvent the wheel with all the amazing design systems to get inspired from. Here are a few companies who have done a great job at incorporating content design into their design systems:

Shopify’s Polaris

One of the most advanced and complete design systems, and often considered a pioneer in the content design space.

Kiwi’s Orbit

Orbit has some good examples for outlining a component’s content structure.

Adobe’s Spectrum

Adobe uses realistic copy in almost all of their component previews.

Atlassian Design System

Atlassian has an extensive section on inclusive language, with specific Do’s and Don’ts for writing inclusively.

GOV.UK Design System

One of the most thorough in documenting content guidelines for each component, specifying exact copy to use when required.

For even more inspiration, check out a list of favorite design system documentation sites.

What best practices would you add?

Integrating content design into your design system isn’t always an easy path. It requires strong collaboration and team effort to do it right. However, following these best practices will hopefully reinforce that content is an integral part of a component or pattern. They will show non UX writers what good content looks like, and help the whole team to avoid errors and inconsistencies.

Originally published at https://backlight.dev by Ardena on April 28, 2022.

Best practices for integrating content design in your design system was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.