Skip to content
tezvyn:

All bites

The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.

4247 bites

Page 155

Storybook: A Workshop for Isolated UI Components
Design Systems2 min read

Storybook: A Workshop for Isolated UI Components

Storybook is a workshop for building UI components in isolation, separate from your app's business logic. It's ideal for developing edge cases and documenting a design system.

Package Publishing: Sharing Your Code with the World
Design Systems2 min read

Package Publishing: Sharing Your Code with the World

Publishing a package is like adding a book to a public library, making your code reusable with one command. It's essential for sharing design system components or utilities. The footgun: accidentally publishing secrets or making a private package public.

Design Systems2 min read

Figma Variables: The Single Source of Truth for Tokens

Figma variables are the central vault for your design tokens, letting you reference a name like color-background instead of a hardcoded value. Use them to build scalable themes and update spacing across an entire app.

Monorepos: A Design System's Single Source of Truth
Design Systems2 min read

Monorepos: A Design System's Single Source of Truth

A monorepo places your design system and its consuming apps in one repo. This enables atomic changes: update a component and all its consumers in a single commit. It's ideal for keeping UI consistent, but requires strict tooling to avoid becoming a monolith.

Unit Testing UI Components: Beyond the DOM Mock
Design Systems2 min read

Unit Testing UI Components: Beyond the DOM Mock

Unit tests for UI components verify individual pieces in a mocked browser environment (jsdom). This is standard for checking component logic with Jest or Vitest, but it can't test visual rendering, element sizes, or layout, creating critical blind spots.

Figma-to-Code: From Pixels to Production Code?
Design Systems2 min read

Figma-to-Code: From Pixels to Production Code?

Figma-to-code tools act as translators, turning visual mockups into code. This speeds up bootstrapping new components or prototypes, but the output is rarely production-ready and often needs heavy refactoring to be performant and maintainable.

Chromatic: Visual Regression Testing for Components
Design Systems2 min read

Chromatic: Visual Regression Testing for Components

Chromatic is a smoke detector for your UI's appearance, taking snapshots of every component on every commit to catch unintended visual changes. It's used in CI/CD to prevent visual regressions when refactoring. The footgun is relying on it for business logic.

Token Studio: Bridge Figma Designs to Production Code
Design Systems2 min read

Token Studio: Bridge Figma Designs to Production Code

Token Studio is a control panel for your design system's raw values, bridging Figma with production code. Use it to manage themes and sync design decisions to a developer-accessible Git repo. The main footgun is using it only locally for Figma styles.

Design Systems2 min read

WCAG Conformance Levels: A, AA, and AAA

WCAG levels are a tiered rating for web accessibility. Level A is the minimum, AA is the widely accepted standard, and AAA is the highest. This helps teams set clear, testable goals. The footgun: don't require AAA for an entire site, as it's often impossible.

Design Systems2 min read

Keyboard Focus Order: Navigating by Tab

Keyboard focus order is the path a user takes through your UI using only the Tab key. It must follow a logical sequence that preserves meaning, especially in forms and modals. The footgun is when CSS creates a visual layout that diverges from the HTML.

Image Alt Text: What Screen Readers Say About Pictures
Design Systems2 min read

Image Alt Text: What Screen Readers Say About Pictures

Alt text tells screen readers what to say when an image can't be seen. For a photo, describe the scene. For a button, describe its action ("Submit form"). For pure decoration, use an empty alt="" to tell screen readers to skip it.

Accessibility Linters: Automate Compliance in Your Design System
Design Systems2 min read

Accessibility Linters: Automate Compliance in Your Design System

An accessibility linter is like a spellchecker for WCAG compliance, automatically flagging component errors like bad contrast or missing labels. It runs in CI/CD to catch bugs early, preventing them from propagating. The footgun: it can't catch everything.

Design Systems2 min read

Forced Colors Mode: When the User Overrides Your Palette

Forced Colors Mode is an accessibility feature where the browser overrides your site's colors with a user-defined, high-contrast palette. This ensures readability for users who depend on it. The footgun is disabling it and making your UI invisible.

Accessibility E2E Testing: Automating User Journeys
Design Systems2 min read

Accessibility E2E Testing: Automating User Journeys

Accessibility E2E testing integrates automated checks into simulated user journeys, testing the rendered app as a user would. It's used in CI/CD to validate flows like sign-up or checkout.

Design Systems2 min read

VPAT vs. ACR: The Nutrition Label for Accessibility

An ACR is a standardized report card for a product's accessibility, based on a template called a VPAT. It's a nutrition label stating conformance facts, not a pass/fail grade.

The Design System PM: Treating Internal Tools as Products
Design Systems2 min read

The Design System PM: Treating Internal Tools as Products

A Design System Product Manager treats the system as a product, not a project. They define the roadmap and prioritize components for their internal engineering and design "customers."

Design System Intake Process: The Gatekeeper for Quality
Design Systems2 min read

Design System Intake Process: The Gatekeeper for Quality

A design system intake process is the formal "front door" for new components, defining how they get proposed, built, and approved. It's crucial for coordinating contributions across teams.

Who Can Change the Button? Design System Contribution Models
Design Systems2 min read

Who Can Change the Button? Design System Contribution Models

A contribution model defines who can change the design system, balancing consistency with evolution. It dictates whether you can fix a typo or must lobby for a new component.

Design System Governance: Preventing UI Drift
Design Systems2 min read

Design System Governance: Preventing UI Drift

Design system governance is the rulebook that stops your UI from becoming a free-for-all. It's used to manage contributions, maintain consistency, and ensure updates are intentional, preventing drift as teams and products scale.

Design System Triage: Treating Your DS Like a Product
Design Systems2 min read

Design System Triage: Treating Your DS Like a Product

Treat your design system like a product, not a static library. It requires a triage process to handle bugs and feature requests from its users—your designers and developers. This applies when a component breaks or needs a new feature.