How do you choose a UI type scale for a product?
Choose a UI type scale by starting from the text people read most, which in a product is labels, table cells and form fields, not headlines. Set that base at 13 or 14px, add one smaller size for metadata and a few larger ones for headings, and stop. A product interface needs a narrow range of sizes that stay readable at high density.
This is the opposite of marketing-site advice, which favors a large base and dramatic headline sizes from a modular ratio. A dashboard with a 64px heading and 18px body text wastes the screen. The two scales can share fonts and tokens, but they shouldn't share sizes. For how type fits into a startup's wider system, see our guide to design systems for startups.
Token | Size / line height | Weight | Used for |
|---|---|---|---|
text/xs | 12 / 16 | Regular, Medium | Metadata, timestamps, badges, table footnotes |
text/sm | 13 / 20 | Regular, Medium | Table cells, secondary labels, dense UI |
text/base | 14 / 20 | Regular, Medium | Default UI text, form labels, menus, buttons |
text/md | 16 / 24 | Regular | Long-form text, descriptions, mobile inputs |
text/lg | 18 / 28 | Semibold | Card and section titles |
text/xl | 20 / 28 | Semibold | Page titles in dense apps |
text/2xl | 24 / 32 | Semibold | Page titles, empty-state headings |
text/3xl | 30 / 36 | Semibold | Dashboard hero numbers, onboarding |
That table is a starting point we use, not a standard. The pattern is what matters: small steps at the bottom where most text lives, bigger jumps only at the top, and every line height a multiple of 4.
Why does product UI use smaller text than marketing sites?
Product UI uses smaller text because users scan and act rather than read, and they need to see more at once. A table of fifty rows, a sidebar, filters and a detail panel all compete for the same screen. Text at 13 or 14px with a good UI font stays readable at arm's length on a laptop while fitting far more information.
The trade-off is readability for long passages and for people with low vision. That's why the scale still includes a 16px size for descriptions and help text, and why the whole interface must respect browser zoom. Our accessible web app UI checklist covers the zoom and reflow requirements that small base sizes put under pressure.
How do you pick fonts and weights for dense interfaces?
Pick a UI font with a large x-height, open letter shapes, clear distinctions between similar characters (I, l and 1; 0 and O) and tabular figures. Those traits matter far more at 13px than personality does. Use your brand typeface for headings if it holds up, and a dedicated UI face for everything else if it doesn't.
- Tabular figures for numbers. Columns of prices and counts must align. Turn on tabular numerals for tables, stats and anything that updates live.
- Two or three weights. Regular for body, Medium for labels and emphasis, Semibold for headings. Bold at small sizes often looks heavy.
- Slightly tighter tracking on large sizes, default or looser on small ones. Small text needs room.
- A monospace for code, IDs and keys. Developer and data products need it in the scale too.
- Test with real data. Long names, large numbers and translated strings break type choices fastest.
How do you build a spacing system with an 8pt grid?
Build a spacing system on a 4px base and use multiples of 8 for most layout spacing, which is what people mean by an 8pt grid. The 4px steps give components the fine control dense UI needs: icon gaps, chip padding, row heights. The 8px steps keep layout spacing consistent and easy to remember.
Token | Value | Typical use |
|---|---|---|
space/1 | 4px | Icon-to-label gap, badge padding |
space/2 | 8px | Gap inside controls, tight stacks |
space/3 | 12px | Input horizontal padding, list item gaps |
space/4 | 16px | Card padding (compact), form field gaps |
space/6 | 24px | Card padding, section gaps inside panels |
space/8 | 32px | Gaps between page sections |
space/12 | 48px | Large page margins, empty states |
Name spacing tokens by step, not by pixel value, so space/4 means 16px in both Figma and Tailwind. That keeps Figma variables and code in sync and lets you change the base unit later without renaming everything. The broader logic of primitive and semantic layers is in our guide to design tokens.
How do you design dense tables and data views?
Design dense tables by fixing row height to the spacing grid, using the smaller text step for cells, and offering a density setting rather than forcing one choice on every user. Most data products need at least two densities: comfortable for occasional users, compact for people who live in the table.
Set row heights on the grid
Pick row heights that are multiples of 4, for example 32px compact, 40px default and 48px comfortable. Line heights from the type scale must fit inside them with even padding.
Use the small text step for cells
Table cells use text/sm, headers use text/xs or text/sm in Medium weight. Don't make headers bigger than cells. Weight and color distinguish them.
Align numbers right and use tabular figures
Numeric columns align right so digits line up. Text columns align left. Center alignment almost never helps scanning.
Build density as a mode
Put row height and cell padding in a spacing collection with Compact and Comfortable modes, so one table component serves both.
Test with real data and widths
Fill the table with the longest realistic values, at the narrowest supported width, before signing off.
Hypothetical example: tightening a cramped dashboard
For example, suppose a startup's analytics dashboard uses 16px body text, 24px card padding and 56px table rows, inherited from its marketing site. Users complain they can only see eight rows without scrolling.
Moving cells to 13/20 text, rows to 40px, and card padding to 16px on the table view would roughly fit half again as many rows on the same screen, without touching the marketing site. Adding a Compact mode at 32px rows gives power users more. Page titles and onboarding keep the larger sizes, so the app doesn't feel cramped where density isn't needed.
How should the UI type scale relate to your marketing site?
Your product's UI type scale and your marketing site's scale should share font families, weights and color tokens, but not sizes. The marketing site needs large display sizes and generous spacing to persuade. The product needs compact sizes to work. Keep both as separate size scales on top of one shared token base.
Our guide to building a design system for a Next.js marketing site covers the marketing side of that split. For a broader look at app layout patterns, see web app UI design.
How do you turn type and spacing into tokens?
Turn type and spacing into tokens by storing each font size, line height and spacing step as a number variable, then building text styles from those variables. In code, the same names become CSS custom properties and Tailwind theme values.
Pros
- Every text style and gap in Figma has an exact code twin
- Density modes come almost free once spacing is tokenized
- Changing the base size later is a token edit, not a redesign
- Fewer sizes means faster design decisions and fewer QA bugs
Cons
- A tight scale can feel limiting to designers used to marketing work
- Small base sizes need extra care for accessibility and zoom
- Some fonts look poor at 13px, which may force a font change
- Two scales (product and marketing) need clear ownership
We set up type and spacing this way on product work because it's the layer that makes or breaks how dense a product can feel. Our brand and design sprint is $3,000, fixed: a brand refresh or redesign plus 10 website or product explorations, delivered as Figma files. See the details on our pricing.
