Open DS

02 / product decisions

Product decisions that shaped Open DS.

1. the grammar

   Ask about the decision, never about a component.

   My first screen asked a question about a table, and I rejected it. A table isn't a decision. How text is set in it is. So the questions are about the decisions a system makes, in type, color, spacing and the rest, and each area answers the same five: roles, how many, how defined, values, and where it lands. Components are known patterns that receive the answers.

   trade-off

   A team can't answer a question about one component directly. Component keys cover this: one key per element, variant and state, shared by every scheme, so a component's look still traces back to a decision.

   payoff

   The grammar stays finite, and schemes can be compared. Dense data and Content first answer the same 78 questions and differ on 49 of them, and each difference shows its reason.

2. the product

   Make the decisions the product.

   An early Button page opened with a big table of keys, tokens and values. It looked like every other design system, and it hid the part that's new. So I changed the order on every screen: the question, the answer, the because, the effect on a live component. Tokens come last, as the shorthand for what was decided.

   trade-off

   Someone who only wants a value takes an extra step. The tokens stay one click away, always linked to their decision, and agents can go straight to a key with get_key.

   payoff

   Every value can be followed to a decision, and every decision to a reason. Ask why Dense data's line heights sit on the grid, and the chain runs through scanning rows, numbers and records, and a product that runs daily operations.

3. the journey

   Start from a ready-made scheme.

   The obvious choice was to start by answering questions: describe your product and get a system back. I think the reverse order has priority. You pick a scheme close to your product and deploy it, and the questions are there to read, and to change where your product differs.

   trade-off

   A scheme is written for a typical product, not yours, so some answers will be wrong for you. Each scheme says when to use it and when not to, and What moves shows what a change would touch before you make it.

   payoff

   You have a working system in one command. You only spend time on the decisions that make your product different.

4. delivery

   One engine, two ways in.

   People deploy with a CLI and agents deploy through MCP. I didn't want two implementations drifting apart. So there's one engine in the open-ds package, and the CLI, the MCP server and the site all use it. When an AI deploys a scheme, it runs the same command a person would.

   trade-off

   The MCP server never writes to your disk. Its plan tools return commands for the agent to run, so the agent has one more step. Anyone without a beta key can run the same server locally.

   payoff

   Both paths give you the same design system, and the agent also gets tools a person doesn't need, like why and when_to_use. Designers get each scheme as a Figma kit, generated from the same data.

03 / how it works

From a reason to a design system, one decision at a time.

Reasons come first and decisions follow. Tokens are the shorthand that carries those decisions through the whole design system, so one scheme renders the works: Storybook, docs, Style Dictionary tokens, fully working components, a CLI and an MCP server.

{
  "question": "typography.definition",
  "option": "ratio-grid",
  "why": "Lines stay on the grid so rows
    align, and grow with the user's
    text size.",
  "because": ["tasks.q1", "people.q2"]
}

{
  "question": "tasks.q1",
  "option": "compare",
  "why": "People scan rows and
    compare values.",
  "because": ["content.q1"]
}

$ npx open-ds why dense-data
    typography.definition

How are sizes and line heights
defined? A ratio, line heights
on the grid.
  because: Scan and compare.
    because: Numbers and records.

04 / design & interface

A design system that has to show its own thinking.

The product's one action is to pick one, so the brand is one lit cell: cream, ink and one orange, with Bricolage Grotesque and DM Mono.

• 

  brand palette

  One lit cell.

  Picking is the product's one action, so one orange marks what matters, and cream and ink stay quiet around it.

• 

  robots

  A dense reference tool can still feel warm.

  Questions and ids read like a database on their own. One robot per page adds warmth, each doing that page's job: sorting swatches, asking questions, carrying the parcel.

• 

  homepage card

  Put the reasons above the answers.

  Most design system sites open with components. I put the reasons first, with brand and voice beside them, so the answers below read as results. Orange marks the few reasons that weigh most for this scheme, and lilac marks answers only this scheme gives. Everything else stays quiet.

  The grid shows the answer in words, not values, because a number means nothing without its reason. And each scheme fills the screen with its own scenario and data. A shared sample table would hide the very differences the card is there to show.

• 

  compare

  Show only what differs, and keep the why next to it.

  A side-by-side of two design systems is usually a wall of values. I cut it to the questions where the schemes disagree, and reduced the rest to a count: 49 differences, 29 the same. The tokens are off this page entirely.

  Every row keeps the same three columns, so your eye runs straight across: question, one answer, the other. The answers are the heaviest thing on the page, and the because sits right under each one in a quieter mono, so you can scan the choices first and read the reasons when you care.

• 

  what moves

  Show the change on real components, not in a list of tokens.

  Changing an answer is the riskiest moment in a design system, so this page puts one dark band at the top with the one control and the size of the change. Orange marks only your new pick, and the old answer stays outlined, so the from and to read at a glance.

  Below it, I show a real button and table row, before and after, because people judge a change by looking at it. The after comes from the closest scheme that already answers that way, and the page says so. I chose that over faking a preview: the site only shows things that are true.

05 / outcome & next steps

Designed, built and published Open DS.

A live site, a published npm package, an MCP server and a Figma kit for every scheme, with five schemes you can deploy today. The next step is seeing how real teams use and change them.

built platform

Website, CLI on npm, Figma kits, hosted MCP server in beta, and the same server to run locally.

tech stack

Node CLI and MCP engine; Style Dictionary and DTCG tokens; components on shadcn and Radix; Storybook; a Next.js site.

Schemes: Dense data, Content first, Accessible first, Multi-brand and Brand expressive

5

Questions every scheme answers, 18 about reasons and 60 about scopes

78

Figma kits, one per scheme: variables for every theme, styles, components, and every question and answer

5