Anushka Tripathi

Design systems, a short tour

There's no such thing as just a button.

I build design systems the way engineers build libraries: with an API, a changelog and strong opinions about naming. This page walks through how, one idea at a time. Start with the button.

  1. 01Anatomy
  2. 02Tokens
  3. 03Theming
  4. 04Handoff
  5. 05Adoption

01 Anatomy

Every part has a name.

If a value doesn't come from a token, it's a guess. Here's the same button at twice its size, with where each number comes from. Point at a row or a part of the button.

Save changes

Shown at 2×

Button / Primary / L

8 values, all from tokens

    02 Tokens

    Name the job, not the look.

    A primitive is a colour. A semantic token is a decision. A component token is a promise. Rebrand by changing a primitive; add dark mode by remapping the semantics. The components never find out. Point at any token to trace it.

    03 Theming

    Change one token. Everything gets the memo.

    Colour, corners and density are three decisions, not three hundred. Even the card's radius follows: it's the inner radius plus the padding, so the corners stay concentric.

    Brand colourButter

    12px

    Density

    
            
    
          
    
        
    
      
    
    
    

    
    
    
      
    
        
    
          
    04 Handoff
    
          
    Fluent in Figma. Conversational in code.
    
          
    I studied IT before I studied type, so I design with the build in mind and prototype in the real material. Drag any number in the code, or the card's edge.
    
        
    
        
    
      
    
    
    

    
    
    
      
    
        
    
          
    05 Adoption
    
          
    A design system nobody uses is a very expensive Figma file.
    
          
    So I run it like a product, with users, feedback and a few numbers I actually look at.
    
        
    
        
    
          
    
            
    Coverage
    How much of the product is built from the system. Screens and components, measured, not guessed. It's the only honest answer to "is it working?"
    
            
          
    
          
    
            
    Detaches
    Where teams break a component, and why. A detach is feedback. Three detaches in the same place is a missing variant.
    
            
          
    
          
    
            
    Requests
    What's missing, straight from the teams. One public queue, a contribution model people can say yes to, and a changelog so nobody is surprised.