An accounting product's design system ships two families in five weights, and adding Arabic and Japanese multiplies font files; how do you set a type budget?
answer
- count what the styles really use
- each weight, per script, is a file
- thousands of glyphs in Japanese
- map missing weights, never fake them
- aligned figures without a second family
basics
~20 sAudit which families and weights the text styles really use, cut to the few that carry hierarchy, and budget per script: large scripts like Japanese often use platform fonts, and weights a script family lacks are mapped, not faked.
solid answer
~50 sEvery family and weight is at least one file per script, and a Japanese family carries thousands of glyphs, so the type palette is a performance decision the design system owns. Start with an audit: which weights do the text styles actually use? Most interfaces carry hierarchy with two or three, so ten faces across two families usually shrink to three or four. Keep one family for interface text and figures unless a second earns its cost; an accounting product can get aligned ledger columns from the family's tabular figures instead of shipping a monospace family. Then budget per script: a custom Arabic family may justify two weights, while Japanese often uses the platform's own fonts rather than a downloaded family. Where a script family lacks a weight, the system maps that text style to the nearest real weight instead of letting the platform synthesise a fake bold, and new weights go through review.
go deeper
Recall that each family and weight is a file per script, that Japanese fonts are very large, and that text styles should use only a few weights.
Explain how tabular figures, per-locale font sets and weight mapping keep the budget small without losing hierarchy or alignment.
Show how you would audit text styles against real usage, cut the palette, set per-script budgets and map missing weights, and how you would report font bytes per locale.
Weigh brand expression against load cost across markets, and decide which locales justify a custom family and who approves adding any new face.
## Why the type palette is a budget Every **family** (a typeface design) and every **weight** (regular, medium, bold and so on) a design system uses has to reach the reader's device, usually as at least one file per weight. Adding scripts multiplies that: an Arabic companion family needs its own weights, and a Japanese family is in a different size class altogether, because it contains thousands of glyphs where a Latin font contains a few hundred. A system that ships two Latin families in five weights and then adds matched Arabic and Japanese families can end up with thirty font files before anyone asks whether readers can tell the weights apart. Choosing families and weights is a design decision with a performance cost, so the design system, not each product team, should own it. ## Auditing what the text styles use 1. **List every text style** and the family and weight it references. 2. **Count real usage** in the products: which styles appear on the main screens, and which weights exist only in a style nobody uses. 3. **Group weights by the hierarchy they carry**: body, emphasis, headings. Two weights that readers cannot distinguish at interface sizes, such as 500 and 600, rarely both earn their place. 4. **Record what each remaining weight is for**, so the reason survives the next redesign. ## A typical reduction | Before | After | Why | |---|---|---| | Two families, five weights each (10 faces) | One family, three weights (3 faces) | Hierarchy is carried by size and three weights | | A monospace family for amounts | Tabular figures from the interface family | Equal-width digits align ledger columns without a second family | | Arabic family in five weights | Arabic family in two weights | Regular and bold carry the hierarchy; medium maps to one of them | | Downloaded Japanese family | Platform Japanese fonts | Coverage is good on every target platform and the files are very large | **Tabular figures** are digits drawn with equal widths so columns of numbers line up; many interface families include them as an optional feature, which makes a separate monospace family unnecessary for most accounting screens. ## Budgeting per script - **Latin**: the brand family in the weights the audit kept. - **Arabic and Hebrew**: a matched family if the brand needs it, in as few weights as carry the hierarchy. - **Japanese, Chinese, Korean**: often the platform's fonts, which are already on the device; a custom family is a deliberate, costly choice for marketing surfaces rather than the default for the product interface. - **Per locale, not global**: a Japanese user should not download the Arabic family, and vice versa. The loading mechanics that achieve this belong to the platform's performance practice; the design system's job is to define which faces each locale needs. ## Weights a script family lacks Script families rarely have the same weight range as the Latin brand. When a text style asks for a weight the family does not have: - **Map it** to the nearest real weight, chosen and documented by the system, such as medium becoming bold in Arabic. - **Do not let the platform synthesise it.** Synthetic bold and slanted styles thicken or skew outlines mechanically, look different on each platform, and damage scripts with fine marks. - **Check hierarchy still reads**: if medium and bold both map to bold in Arabic, confirm headings and emphasis are still distinguishable by size. ## Governing the budget - Publish the budget: families, weights per script, and the reason for each. - Require evidence before adding a face: which text style needs it, and what readers gain. - Track the font bytes each locale downloads as a number the system reports, so growth is visible. - Review the budget when a new market or brand is added, not after files have shipped. - Re-run the audit after major redesigns, because unused weights tend to creep back in through one-off campaign styles. A tight budget also improves the system as design. Fewer weights push hierarchy onto size, spacing and color, which translates better across scripts whose families offer a narrower weight range than the Latin brand.
- Why not let the platform synthesise medium and bold for a script family that only ships regular?Synthetic weights mechanically thicken the outlines, which looks different on each platform, clogs counters and fine marks in scripts like Arabic, and breaks parity with the designed weights. Mapping to a real weight is predictable. If a script truly needs more weights, license or commission them rather than faking them.
- The finance team wants a monospace family so amounts line up. What do you propose instead?Check whether the interface family offers tabular figures, which give equal-width digits for aligned columns. If it does, a text style for figures can switch them on, keeping one family in the budget. A monospace family is only worth adding if it serves another purpose, such as code or fixed-width exports.
saying these in an interview costs you the question
- Fonts are cached after the first visit, so the number of weights does not matter.
- Every Latin weight must exist in every script so the system stays consistent.
- Synthetic bold is an acceptable stand-in when a script family lacks a weight.
- Aligned numbers in ledgers require a separate monospace family.
- Every locale should download every script family to keep one shared stack.