Sizing Chaos: Why Your Design System's Size Scale Breaks Builds

A post titled "Sizing chaos" hit #1 on Hacker News this morning with 485 points and 250 comments. Devs and founders are venting about the same problem: products with 47 different font sizes, spacing values that make no mathematical sense, and components that look subtly wrong in every context.

If you've ever watched your developer squint at Figma and ask "is this 18px or 20px?" or "which gray is this?", you're living this chaos. And it's costing you more than you think.

We've audited design systems for 200+ early-stage startups. The sizing problem shows up in 80% of them, and it manifests the same way: development velocity drops by 20-30% because engineers spend hours pixel-pushing instead of shipping features. Your Series A investors will notice the inconsistency even if they can't articulate why your product feels "off".

The Real Cost of Sizing Chaos

Here's what actually happens when your design system sizing is broken:

Development slowdown. Your engineer implements a modal. They need to add padding. They check Figma. One modal uses 24px, another uses 20px, another uses 16px. Which is "correct"? They message Slack. You're in a meeting. They guess. Now you have a fourth padding value. Multiply this by 50 decisions per feature.

Design drift. You hire a contract designer to help with your Series A push. They don't know your unwritten rules. They use 18px font because it "looks right". Your developer implements it. Now your product has 18px in addition to your existing 16px, 17px, 19px, and 20px text sizes. Six months later, you can't remember which pages use which sizes or why.

Compound technical debt. Every inconsistent size value is a future refactor. When you finally decide to fix it (usually right before a big launch or fundraise), you're touching 200+ components across 50+ screens. We've seen startups burn entire sprints on this cleanup right when they should be shipping features.

Perceived lack of polish. Users and investors can't articulate it, but they feel it. Your competitor's product feels "tighter", "more professional", "ready for enterprise" — and half of that perception comes from consistent spatial rhythm and sizing. It's subliminal but it's real.

How Sizing Chaos Happens (It's Not Your Fault)

You didn't set out to create chaos. Here's the typical evolution:

Stage 1: MVP — You're in Figma, designing your first screens. You use 16px for body text because that's the default. You need a heading, so you try 24px. Too small. 32px. Better. You use 12px padding because it feels right. You ship it.

Stage 2: Growth — You add features. New contexts require new sizes. A compact table needs smaller text — 14px. A dashboard card needs tighter padding — 8px. A landing page hero needs bigger text — 48px. Each decision makes local sense. Globally, you now have 8 font sizes and 12 spacing values with no underlying system.

Stage 3: Scale — You have 3 designers, 8 engineers, 100+ screens. Nobody knows the "right" values anymore. Your Figma file has 23 different text styles. Your CSS has spacing values from 2px to 96px with no pattern. Someone suggests a design system. Everyone agrees it's needed. Nobody has time to build it.

This isn't a founder problem — it's a systems problem. The solution isn't "be more careful". It's "establish constraints before you need them".

The Audit: Finding Your Sizing Chaos

Before you fix it, you need to see it. Here's the 15-minute audit we run with clients:

Font size audit: Open your production app or Figma file. List every unique font size you're using. If you have more than 6-7 sizes, you have chaos. We regularly find products with 15-20 font sizes. One YC startup we worked with had 31 unique font sizes across their product.

Spacing audit: Check padding and margin values on 10 random components. Write them down. If you see values like 12px, 18px, 22px, 25px — numbers that don't follow a clear pattern — you have chaos. Rational systems use multiples: 8px, 16px, 24px, 32px. Or 4px, 12px, 20px, 28px. The specific scale matters less than the consistency.

Component sizing audit: Pick your button component. How many height variations exist in production? We see buttons ranging from 32px to 48px in the same product with no clear rules about when to use which. Same with input fields, cards, modals.

The "why" test: For each size value you found, ask: "Why this number?" If the answer is "it looked right" or "I don't remember", that's chaos. Rational systems have answers: "It's our base unit × 3" or "It aligns to our 8px grid".

The Fix: Establishing a Rational Sizing Scale

You don't need to redesign everything. You need to establish a scale and migrate incrementally. Here's the framework we use with early-stage startups:

Step 1: Choose a Base Unit

Pick 4px or 8px. That's it. This becomes your atomic unit — everything else derives from it.

4px systems: More granular. Useful if you need tight spacing control or are designing for small screens. Scale: 4, 8, 12, 16, 20, 24, 28, 32, 40, 48, 64, 80.

8px systems: More constrained. Faster to implement. Easier for developers. Scale: 8, 16, 24, 32, 40, 48, 64, 80, 96, 128.

We recommend 8px for most B2B SaaS products. It's the Goldilocks zone — enough flexibility, not too much chaos.

Step 2: Define Your Type Scale

You need 5-7 text sizes maximum. Here's a starter scale that works for 90% of early-stage products:

• xs: 12px — captions, labels, metadata
• sm: 14px — secondary text, table data
• base: 16px — body text, default
• lg: 18px — emphasized text, large body
• xl: 20px — section headings
• 2xl: 24px — page headings
• 3xl: 32px — hero text, landing pages

Notice the pattern: below 20px, we increment by 2px. Above 20px, we get more aggressive. This matches how humans perceive size differences. A 2px jump from 12px to 14px is noticeable. A 2px jump from 32px to 34px is invisible.

Marketing sites and landing pages can add 4xl (48px) and 5xl (64px) for hero sections. Product UIs rarely need sizes above 32px.

Step 3: Build Your Spacing Scale

This is where the 8px base unit shines. Your spacing tokens:

• xxs: 4px — tight inline spacing (icon to text)
• xs: 8px — compact components
• sm: 12px — default component padding
• md: 16px — comfortable spacing
• lg: 24px — section spacing
• xl: 32px — large section breaks
• 2xl: 48px — page-level spacing
• 3xl: 64px — hero sections

Notice we break the 8px rule with 4px and 12px. That's intentional. Pure 8px scales (8, 16, 24, 32) feel too rigid in practice. The 4px gives you a pressure valve for tight spaces. The 12px is the workhorse — we use it constantly.

Step 4: Component Sizing Standards

Define height standards for interactive elements. These should also align to your base unit:

• Buttons: sm (32px), md (40px), lg (48px)
• Input fields: sm (32px), md (40px), lg (48px)
• Table rows: compact (32px), default (40px), comfortable (48px)
• Nav height: 64px (product) or 80px (marketing)

The pattern: interactive elements come in 3 sizes, and they align across component types. Your sm button is the same height as your sm input. This creates visual rhythm and makes layouts feel cohesive even when you're mixing components.

Implementation Without Breaking Everything

You've defined your scale. Now the hard part: migrating existing work without halting feature development.

Don't do a big-bang refactor. We've seen teams try to fix everything at once. It takes 3 weeks, breaks 40 layouts, and creates 200 QA tickets. Your velocity craters. Investors ask why you shipped nothing this month.

Do incremental migration:

Week 1: Implement the new scale in your design system / component library. New components use the new scale. Existing components stay as-is. You're running two systems in parallel temporarily. That's okay.

Weeks 2-4: Every new feature uses the new scale. Every time you touch an existing component for a feature, you migrate it. You're opportunistically cleaning up tech debt as part of normal work.

Month 2: Schedule dedicated cleanup sprints for high-traffic pages: landing page, dashboard, settings. These are your brand moments — they deserve the polish. Lesser-used admin pages can wait.

Month 3: Audit what's left. You'll find 80% of your product is now on the new scale through normal feature work. The remaining 20% — old settings pages, edge case modals — you can tackle in maintenance sprints or leave as acceptable tech debt.

We've helped 50+ startups through this migration. The ones who succeed treat it like paying down credit card debt: consistent small payments, not one massive balloon payment.

The Developer Handoff That Actually Works

Your developer is implementing a new feature. They need to know what spacing to use. Here's what doesn't work: "Make it look like Figma." Here's what does work:

Design tokens in code: Your spacing scale should exist as variables/tokens in your codebase. Not magic numbers. This code is wrong:

padding: 24px;

This code is right:

padding: var(--space-lg);

Now your developer doesn't need to measure. They use semantic tokens. "This needs large section spacing" maps to --space-lg. No ambiguity.

Decision tree, not design police: Give your team a simple decision framework. For spacing: "Use sm for component padding, md for comfortable spacing between related elements, lg for section breaks." For text: "Use base for body, lg for emphasis, xl for section headings."

Documentation in Figma: Add a sizing reference page to your Figma file. Show the scale, show when to use each value, show examples. Your developer shouldn't need to Slack you to know if this is 16px or 20px — it should be obvious from the token name or the reference doc.

We've designed developer handoff documentation for 100+ design systems. The ones that work are specific and visual. "Use consistent spacing" is useless. "This is our 8-step spacing scale — here are 12 examples of when to use each step" is gold.

When This Actually Matters (Timing)

You're busy. You have roadmap pressure. Is this actually worth doing now?

Fix this if you're:

• Fundraising in the next 6 months — investors will notice the lack of polish, especially if you're going for top-tier VCs
• Hiring designers or engineers — onboarding velocity tanks when there are no standards
• Seeing developers ask "which size?" more than once per week — that's a velocity tax
• Preparing for a big launch or rebranding — fix the foundation first
• Noticing your product feels "off" compared to competitors — this is probably why

Deprioritize this if you're:

• Pre-product/market fit and UI polish won't affect your core metric — ship fast, fix later
• A solo founder with no design background doing everything yourself — use a template, don't invent
• Working on an internal tool where consistency doesn't affect sales — acceptable tech debt

The sizing system conversation happens at every stage, but the solution changes. At pre-seed, use a design system template and don't customize it. At seed, establish your scale but be loose on enforcement. At Series A, enforce it religiously because you're scaling the team.

What This Looks Like in Practice

We worked with a YC W23 AI startup that was 3 months from their Series A pitch. Their product had 19 unique font sizes and spacing values ranging from 3px to 87px with no pattern. Their lead engineer estimated it added 4-6 hours per feature in "figuring out what size to use and matching Figma".

We ran the audit above, found the chaos, established an 8px spacing scale and 6-size type scale. Implementation took 3 weeks of incremental migration. Their velocity impact: features that took 3 days to design and implement now took 2 days. The 30% time savings compounded. They shipped 2 additional major features before their Series A that they wouldn't have had bandwidth for.

Their lead investor mentioned in the partner meeting that the product "felt surprisingly polished for a Series A" — directly attributing it to the visual consistency and spatial rhythm. They raised $12M.

The sizing system wasn't why they raised. But it was why their product didn't create doubt.

Common Objections (And Why They're Wrong)

"This feels restrictive. Won't it limit our design flexibility?"

No. It limits your bad decisions. Every world-class design system — Material, Apple HIG, Carbon — uses constrained sizing scales. The constraint is what creates the flexibility. When you have 200 possible spacing values, every decision is hard. When you have 8, decisions are fast and consistent.

"We're too early for this level of systems thinking."

You're too early for a comprehensive design system. You're not too early for a sizing scale. This is a 2-hour conversation and a 1-day implementation. It's the highest-ROI design systems work you can do.

"Can't we just use Tailwind/Material/Bootstrap sizing?"

Yes. Please do. Those frameworks have rational sizing scales built in. The mistake is using the framework halfway — using Tailwind for some components and custom CSS with random values for others. Commit to the framework's scale or define your own. Don't mix.

"Our designers will hate being constrained to a fixed scale."

Good designers love constraints. They enable creativity. Bad designers fight constraints because they're used to pixel-pushing until something "feels right". If your designer can't work within a rational sizing scale, they're not a systems thinker — and systems thinking is what you need at scale.

Your Next Steps

Run the 15-minute audit described above. If you find more than 8 font sizes or spacing values that don't follow a clear pattern, you have sizing chaos. It's costing you velocity and polish.

Establish your scale this week. It's a 2-hour conversation with your designer and lead engineer. Use the scales we provided above as a starting point — they work for 90% of products.

Migrate incrementally over the next 6 weeks. New work uses the new scale. Touch old components opportunistically. Don't halt feature work for a big-bang refactor.

Six weeks from now, your sizing chaos is gone. Your developer stops asking which size to use. Your product feels tighter. Your velocity increases by 20-30% on UI work. And your next investor pitch deck shows a product that looks Series A-ready.

We've established sizing systems and full design systems for 200+ early-stage startups, including 50+ YC companies and 20+ unicorns. Our design systems work includes sizing scales, component libraries, and implementation guidelines that your developers can actually use. If you're dealing with sizing chaos and want an experienced team to audit and fix it without slowing down your roadmap, book a 15-minute product teardown call — we'll audit your sizing live and show you exactly what to fix first.

FAQ: Design System Sizing

Q: How do I convince my team to prioritize fixing our sizing chaos?

A: Frame it as a velocity issue, not a polish issue. Show your engineers the time spent in Slack asking "which size is this?" and pixel-pushing to match Figma. That's 4-6 hours per feature. Calculate the cost: if you ship 10 features per quarter, that's 40-60 hours of wasted engineering time. At a $150K engineer salary, that's $15K per quarter in pure waste. The sizing system pays for itself in 3 weeks.

Q: Should I fix sizing before or after establishing a component library?

A: Before. Your component library should be built on your sizing scale. If you build components first with inconsistent sizing, you'll need to rebuild them when you fix the scale. Do sizing first, then components. The exception: if you're using a framework like Material UI or Chakra that has a built-in sizing scale, adopt their scale and build components on top of it.

Q: What if our product needs sizes that don't fit the scale?

A: You have three options. One: extend the scale with a new step that follows the pattern (e.g., add 56px between 48px and 64px if you genuinely need it). Two: use a different size from the existing scale that's close enough. Three: accept that this is a special case and document the exception. We see genuine exceptions in less than 5% of cases. Most "we need a custom size" situations are actually "we're not using the scale correctly".

Q: How do I handle sizing for mobile vs desktop?

A: Use the same scale, different token values at different breakpoints. Your --space-lg might be 24px on mobile and 32px on desktop. The semantic meaning stays consistent ("large section spacing"), but the actual pixel value adapts. Same with type: your text-xl might be 24px on mobile and 32px on desktop. This is responsive design done right — the scale stays rational, the values adapt.

Q: Our design uses a lot of custom illustrations and graphics. Does sizing chaos matter as much?

A: Yes, maybe more. Illustration-heavy products live or die on spatial rhythm. If your illustrations are beautifully crafted but your spacing is chaos, the inconsistency will clash with the craft. Think of your sizing scale as the grid that your illustrations live within. The more custom visual work you have, the more important it is that your foundational spacing is bulletproof. Otherwise the illustrations feel like they're floating in an inconsistent space.