Ideas

Design That Scales

Documentation Driven Design

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• https://gist.github.com/zsup/9434452

Unit Testing

Component Driven User Interfaces

The development and design practice of building user interfaces with modular components. UIs are built from the “bottom up” starting with basic components then progressively combined to assemble screens.

Why Components?

Modern user interfaces are more complicated than ever. People expect compelling, personalized experiences delivered across devices. That means frontend developers and designers have to embed more logic into the UI.

But UIs become unwieldy as applications grow. Large UIs are brittle, painful to debug, and time consuming to ship. Breaking them down in a modular way makes it easy to build robust yet flexible UIs.

• Component Story Format
• Component Story Format Factories
• https://webcomponents.dev/docs/component-story-format
• https://www.componentdriven.org/
• https://github.com/ComponentDriven/csf#component-story-format-csf

Links / Resources

• Mavyret Retro Items
• NOVA Helium Component Catalog
• IAE RA ISA Assessment

Features / Conventional Commits

Home

AbbVie 1 North Waukegan Road North Chicago, IL 60064

• Acronyms
• Blocks
• Components
• Design Tokens
• Element

Acronyms

Agencies

Eversana

• Rinvoq

AbbVie Ad Agency (A3)

Digitas Health

• Skyrizi

Blocks

Components

animation

icons

utilities

accordion

actions

activity-tracker

• background-container
• banner-ad
• brand-explorer
• breadcrumb
• carousel
• chart-bar
• chart-line
• chart-pie
• columns
• container
• cta
• dismiss-content
• embed
• find-a-provider
• flexbox-v2
• footer
• forms-product-grid-list
• formulary-lookup
• formulary-lookup-zipcode
• grid
• header-v2
• html-container

Design Tokens

A design token is an attribute to describe something visually. It is atomic (it cannot be broken down further). Design tokens have a name, a value, and optional attributes or metadata. The name of a token can be anything, but we have a proposed naming structure that we find works really well in the next section.

Design tokens are foundational design decisions representing a design system’s visual language. Tokens can represent colors, typography, effects, spacing, and animation. Tokens store values like colors, font styles, and font sizes, allowing the visual language to be applied across all products.They streamline designer and developer workflows, enabling the design system to scale. Tokens are platform agnostic but can be applied with platform-specific code for ultimate flexibility.

Type

A token's type is a predefined categorization applied to the token's value.

For example:

• Color
• Size
• Duration

Token tools can use Types to infer the purpose of a token.

For example:

• A translation tool might reference a token's type to convert the source value into the correct platform-specific format.
• A visual design tool might reference type to present tokens in the appropriate part of their UI - as in, color tokens are listed in the color picker, font tokens in the text styling UI's fonts list, and so on.

Group

A group is a set of tokens belonging to a specific category.

For example:

• Brand
• Alert
• Layout

Groups are arbitrary and tools SHOULD NOT use them to infer the type or purpose of design tokens.

Category/Type/Item Structure

While not exactly necessary, we feel this classification structure of design tokens makes the most sense semantically. Design tokens can be organized into a hierarchical tree structure with the top level, category, defining the primitive nature of the token. For example, we have the color category and every token underneath is always a color. As you proceed down the tree to type, item, sub-item, and state, you get more specific about what that color is. Is it a background color, a text color, or a border color? What kind of text color is it? You get the point. Now you can structure your token json files like simple objects:

{
  "size": {
    "font": {
      "base": { "value": "16" },
      "large": { "value": "20" }
    }
  }
}

The CTI is implicit in the structure, the category and type is 'size' and 'font', and there are 2 tokens 'base' and 'large'.

Structuring design tokens in this manner gives us consistent naming and accessing of these tokens. You don't need to remember if it is button_color_error or error_button_color, it is color_background_button_error!

You can organize and name your design tokens however you want, there are no restrictions. But we have a good amount of helpers if you do use this structure, like the 'attribute/cti' transform which adds attributes to the token of its CTI based on the path in the object. There are a lot of name transforms as well for when you want a flat structure like for Sass variables.

Also, the CTI structure provides a good mechanism to target transforms for specific kinds of tokens. All of the transforms provided by the framework use the CTI of a token to know if it should be applied. For instance, the 'color/hex' transform only applies to tokens of the category 'color'.

You can also add a comment to a design token:

{
  "size": {
    "font": {
      "base": {
        "value": "16",
        "comment": "the base size of the font"
      },
      "large": {
        "value": "20",
        "comment": "the large size of the font"
      }
    }
  }
}

The comment will appear in the output files, where relevant or the output format supports comments.

Element

Button

HTML Template

<button type="button" :class="classes" :style="style" @click="onClick">
  {{ label }}
</button>

JavaScript Behavior

import { computed, reactive } from 'vue'

export default {
  name: 'LmsButton',

  props: {
    label: {
      type: String,
      required: true,
    },
    primary: {
      type: Boolean,
      default: false,
    },
    size: {
      type: String,
      validator(value) {
        return ['small', 'medium', 'large'].includes(value)
      },
    },
    backgroundColor: {
      type: String,
    },
  },

  emits: ['click'],

  setup(props, { emit }) {
    props = reactive(props)
    return {
      classes: computed(() => ({
        'lms-button': true,
        'lms-button--primary': props.primary,
        'lms-button--secondary': !props.primary,
        [`lms-button--${props.size || 'medium'}`]: true,
      })),
      style: computed(() => ({
        backgroundColor: props.backgroundColor,
      })),
      onClick() {
        emit('click')
      },
    }
  },
}

CSS Style

.lms-button {
  font-family: 'Nunito Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif;
  font-weight: 700;
  border: 0;
  border-radius: 3em;
  cursor: pointer;
  display: inline-block;
  line-height: 1;
}
.lms-button--primary {
  color: white;
  background-color: #1ea7fd;
}
.lms-button--secondary {
  color: #333;
  background-color: transparent;
  box-shadow: rgba(0, 0, 0, 0.15) 0px 0px 0px 1px inset;
}
.lms-button--small {
  font-size: 12px;
  padding: 10px 16px;
}
.lms-button--medium {
  font-size: 14px;
  padding: 11px 20px;
}
.lms-button--large {
  font-size: 16px;
  padding: 12px 24px;
}

Figma

Code Connect

Code Connect is a tool for connecting your design system components in code with your design system in Figma. When using Code Connect, Figma's Dev Mode will display true-to-production code snippets from your design system instead of autogenerated code examples. In addition to connecting component definitions, Code Connect also supports mapping properties from code to Figma enabling dynamic and correct examples. This can be useful for when you have an existing design system and are looking to drive consistent and correct adoption of that design system across design and engineering.

Code Connect is easy to set up, easy to maintain, type-safe, and extensible. Out of the box Code Connect comes with support for React, Storybook and SwiftUI.

Tokens Studio for Figma

• Code Connect
• Code Connect React
• Tokens Studio - Save time, have more control, and effortlessly manage and switch between multiple themes. Control your design tokens from within Figma, all linked to one source of truth.
• sd-transforms - Custom transforms for Style-Dictionary, to work with Design Tokens that are exported from Tokens Studio

Mode

Pattern

People

Style Dictionary

Style once, use everywhere.

A Style Dictionary uses design tokens to define styles once and use those styles on any platform or language. It provides a single place to create and edit your styles, and exports these tokens to all the places you need - iOS, Android, CSS, JS, HTML, sketch files, style documentation, etc. It is available as a CLI through npm, but can also be used like any normal node module if you want to extend its functionality.

When you are managing user experiences, it can be quite challenging to keep styles consistent and synchronized across multiple development platforms and devices. At the same time, designers, developers, PMs and others must be able to have consistent and up-to-date style documentation to enable effective work and communication. Even then, mistakes inevitably happen and the design may not be implemented accurately. Style Dictionary solves this by automatically generating style definitions across all platforms from a single source - removing roadblocks, errors, and inefficiencies across your workflow.

For detailed usage head to https://amzn.github.io/style-dictionary

Style Dictionary: "A build system for creating cross-platform styles.""

Teams

Template

Theme

Variant

Diátaxis framework

• https://diataxis.fr/
• https://diataxis.fr/reference/
• https://diataxis.fr/how-to-guides/
• https://diataxis.fr/tutorials/
• https://diataxis.fr/explanation/

• Atoms
• Button
• Callout
• Carousel
• Container
• Flip Container
• Formulary
• Modal Overlay
• Navigation
• Safety Bar
• Swim Lanes
• Tabs Header
• Vertical Navigation
• Vertical Tabs
• Video

export default defineAppConfig({
  ui: {
    colors: {
      primary: 'sky',
      colors: 'slate'
    }
  }
})

Example Code preview

`inline code`

Example Code Group

pnpm add @nuxt/ui-pro

yarn add @nuxt/ui-pro

npm install @nuxt/ui-pro

bun add @nuxt/ui-pro

Example Code Collapse

@import "tailwindcss";
@import "@nuxt/ui-pro";

@theme static {
  --font-sans: 'Public Sans', sans-serif;

  --breakpoint-3xl: 1920px;

  --color-green-50: #EFFDF5;
  --color-green-100: #D9FBE8;
  --color-green-200: #B3F5D1;
  --color-green-300: #75EDAE;
  --color-green-400: #00DC82;
  --color-green-500: #00C16A;
  --color-green-600: #00A155;
  --color-green-700: #007F45;
  --color-green-800: #016538;
  --color-green-900: #0A5331;
  --color-green-950: #052E16;
}

Example Field

Example Field Group

Example Icon

Example KBD

K

Example Tabs

::callout
Lorem velit voluptate ex reprehenderit ullamco et culpa.
::

Example Steps

export default defineNuxtConfig({
  modules: ['@nuxt/ui-pro']
})

@import "tailwindcss";
@import "@nuxt/ui-pro";

Example accordion

Example Badge

Example Callout

Example Card

Example Card Group

Example Collapsible

Example Inline Code

inline code

nuxt.config.ts

pzi -m 1376,1032 -M 1376,1032 http://localhost:3000/components/button

This will use the Great Vibes font family.