Influence Through Systems

The most scalable way to improve quality is to change the system people work within.

My strongest design systems work changes behavior through tooling, process, documentation, migration paths, and platform decisions. The goal is not to manage people into consistency. The goal is to make consistent decisions easier to make.

These systems supported Pine's adoption across 40+ engineers and 6 product teams.

40+
EngineersUsing Pine
6
Product TeamsSupported
40
ComponentsMaintained
Pine MCP
AI Workflow LayerDesign system context
Migration Tooling
Sage -> PineIncremental adoption
Lint Enforcement
Build-Time GovernanceEarlier feedback

How Influence Scales

Change the workflow and behavior changes with it.

  1. Decision
  2. Docs
  3. Tooling
  4. Automation
  5. Behavior Change

Evidence Artifact

Migration guidance as governance

Sage to Pine guidance translated common legacy habits into Pine standards, then connected those standards to tooling and AI validation loops. The point was not just to document the new system. It was to change what teams and assistants reached for while converting real product UI.

Legacy habitPine standardSystem lever
Bootstrap row / col-md-* gridspds-row + pds-box size-*Migration guide + layout validation
Margin and padding utility classesgap, padding, and margin propsComponent API guidance
Inline styles and hardcoded hex colorsPine props + semantic design tokensToken rules + lint enforcement

Tooling loop

  1. get_pine_context_for_generation
  2. generate
  3. validate_ui_generation
  4. fix_layout_issues

Evidence Artifact

Semantic token linting moved review to build time

Token enforcement made color quality a workflow property instead of a reviewer memory test. The rule stayed strict where the mapping was deterministic and kept an explicit escape hatch for legitimate alpha values such as shadows and overlays.

Problem

Hardcoded color

A hex value or core token looks fine in light mode, but it bypasses semantic theme behavior and can break dark mode later.

Enforcement

Stylelint failure

The lint rule flags hardcoded colors and core token usage at build time, before a reviewer has to catch it by scanning the diff.

Outcome

Semantic token fix

The implementation moves to a semantic token that describes product intent and resolves correctly across supported themes.

Migration Strategy

Migration Strategy

Migration is a product adoption problem. The system has to meet teams where they are and still move them toward the standard.

No-Sage linting

Problem
Legacy Sage patterns continued to appear in new or changed UI, slowing Pine adoption.
Behavior Before
Reviewers had to manually catch old component usage and explain migration expectations repeatedly.
System Change
No-Sage linting turned legacy usage into a visible workflow signal.
Behavior After
Teams could see when new work was carrying old patterns forward and correct it earlier.
Impact
Migration pressure moved closer to implementation and reduced repeated review conversations.

FormikPine

Problem
Form migration required teams to connect product form patterns with Pine components and existing form state conventions.
Behavior Before
Teams had to hand-roll bridging patterns or delay migration until form work could be revisited more deeply.
System Change
FormikPine created a bridge between existing form workflows and Pine component usage.
Behavior After
Teams could migrate form UI incrementally while preserving familiar implementation patterns.
Impact
Pine adoption became more practical for real product surfaces with active delivery needs.

Design System Governance

Design System Governance

Governance works best when it changes the path teams follow, not when it creates another document people have to remember.

Semantic token linting

Problem
Hardcoded colors and low-level token choices made interfaces harder to theme and maintain.
Behavior Before
Engineers could ship one-off color decisions that looked right locally but drifted from system intent.
System Change
Semantic token linting moved color rules into the implementation workflow.
Behavior After
Teams were guided toward intent-based tokens while building, not only during review.
Impact
Color decisions became more consistent, easier to review, and better prepared for theming.

Component lifecycle labels

Problem
Teams needed clearer signals about which components were stable, changing, deprecated, or preferred.
Behavior Before
Engineers had to infer component maturity from docs, examples, or tribal knowledge.
System Change
Lifecycle labels made component status visible inside the design system documentation.
Behavior After
Teams could choose components with a clearer understanding of stability and migration expectations.
Impact
Adoption decisions became less ambiguous and easier to align across teams.

AI-Assisted Development

AI-Assisted Development

AI-assisted development adds a new design system consumer. The assistant needs access to the same rules a senior reviewer would apply.

Pine MCP

Problem
Generic AI assistants generated plausible UI that often ignored Pine components, tokens, accessibility rules, and layout expectations.
Behavior Before
Engineers had to catch design system drift after code had already been generated.
System Change
Pine MCP exposed component guidance, token rules, accessibility expectations, and layout review to AI-assisted workflows.
Behavior After
Generated UI could start closer to Pine and be reviewed against system rules earlier.
Impact
Design system governance moved into the generation process instead of waiting for code review.

Build-Time Quality Enforcement

Build-Time Quality Enforcement

The most useful quality checks happen before review. Build-time enforcement turns repeatable feedback into the system itself.

Semantic token linting

Problem
The same color and theme issues could reappear after standards were documented.
Behavior Before
Reviewers had to keep checking whether implementation matched the token guidance.
System Change
Build-time checks reinforced the same token rules introduced through governance.
Behavior After
Engineers got faster feedback before the work reached review.
Impact
Review time shifted away from repeatable corrections and toward higher-value product and UX decisions.

No-Sage linting

Problem
Legacy migration could stall when old patterns depended on human review to catch.
Behavior Before
Teams could accidentally preserve Sage-era UI decisions in new product work.
System Change
The migration signal from No-Sage linting became part of the development loop.
Behavior After
Migration feedback became faster, more consistent, and less dependent on one reviewer noticing it.
Impact
The system helped teams move forward without relying on memory or manual policing.

Reducing Decision Overhead

Reducing Decision Overhead

The best system documentation turns repeated debate into self-service decision making.

ADRs

Problem
Important system decisions could get lost once implementation moved on.
Behavior Before
Teams had to rediscover context through conversations, old tickets, or scattered history.
System Change
Architecture decision records captured the decision, tradeoff, and reasoning behind system choices.
Behavior After
Teams had a durable reference for why the system worked a certain way.
Impact
Decision velocity improved because the reasoning stayed visible and repeatable.

Component lifecycle labels

Problem
Component docs needed to communicate adoption guidance, not only API details.
Behavior Before
A component page could show how to use something without making its recommendation status clear.
System Change
Lifecycle labels added decision context directly to documentation.
Behavior After
Engineers could connect API usage with system direction and migration timing.
Impact
Docs became a self-service adoption surface instead of another place to look up syntax.

Related Work

The same pattern shows up across Pine, Pine MCP, and dark mode.

The work is different, but the leverage is the same: change the workflow so teams can make better decisions with less repeated review burden.

View PineView Pine MCPView dark mode