skip to content

How should a music-streaming app's design system turn one icon source into assets for the web, two native mobile platforms and a design editor?

level: middleimportance: should knowfreq 22%

answer

  1. one master, many outputs
  2. clean before you convert
  3. features every target supports
  4. strip fills so platforms can tint
  5. render and compare each output

basics

~20 s

Keep one vector master per icon, clean it, restrict it to features every target supports, then generate each output — web components or sprite, each native vector asset, the design-editor library — and verify each by rendering it.

solid answer

~40 s

I keep a single **vector master** per icon and treat every platform file as a generated output, never hand-edited. A pipeline first cleans the master: normalize the canvas size, remove hidden layers and editor metadata, flatten transforms, merge shapes, and — as many teams do — outline strokes so every renderer draws the same shape. It strips fixed fills from single-color icons so each platform can tint them, and it rejects features some targets cannot express, such as filters or masks. Then it generates web components or a sprite, each native platform's vector asset format with raster fallbacks only where needed, and the design-editor icon library. Finally it renders each output and compares it against the master, and releases all outputs together from one version.

go deeper

for a junior

Recall that one master drawing per icon feeds every platform, and that platform files are generated outputs rather than copies to edit.

for a middle

Explain the cleaning steps — canvas, flattening, stroke outlining, fill stripping — and why the source is restricted to features every target supports.

for a senior

Show how you verify conversions with rendered comparisons and release all outputs from one version, so a fix reaches every platform together.

for a principal

Discuss who owns the master, designers or engineers, and how that choice shapes review, history and the speed at which icons reach every platform.

## One master, generated outputs A design system that ships to the web, two native mobile platforms and a design editor has four consumers of the same icon. If each keeps its own copy, they drift within months: a fix to the shuffle icon lands on the web and never reaches one of the native apps. The durable model is a single **vector master** per icon — kept in the design editor or in a repository, as long as it is one place — and **every platform file is a generated output**. Nobody edits an output by hand; they change the master and regenerate. ## Clean the master before converting it Drawings that look identical in a design editor can be structurally messy. A pipeline normalizes them first: 1. **Canvas.** Every icon sits on the same canvas size with the same padding, so outputs line up. 2. **Remove noise.** Hidden layers, editor-specific metadata, empty groups and unused definitions go. 3. **Flatten and merge.** Transforms are applied to the paths and overlapping shapes merged, so each renderer sees plain geometry. 4. **Outline strokes (common practice).** Many teams convert strokes to filled outlines because renderers handle stroke joins and scaling differently; the cost is losing the ability to change stroke weight later, so the stroked source is kept too. 5. **Strip fixed fills** on single-color icons so every platform can tint them with the surrounding color; multicolor artwork is marked and exempt. 6. **Optimize path data**, reducing precision and redundant points without visible change. ## Restrict the source to what every target can express Native vector formats generally support a **subset** of what a general vector file can describe. Filters, masks, blend modes and embedded raster images may convert badly or not at all. Rather than discovering this per platform, the pipeline **rejects** icons that use unsupported features, so designers learn the constraint at export time instead of from a bug report. ## Generate each platform's output | Target | Typical output | Gotcha | |---|---|---| | Web | Per-icon components or modules, optionally a sprite | Must stay tree-shakable; see the unused-icon problem | | Native mobile platform A | That platform's vector asset format | Raster fallbacks at density multiples only if a supported OS version lacks vector support | | Native mobile platform B | That platform's own, different vector asset format | Feature subset differs from platform A | | Design editor | A library of icon components | Must be generated or synced from the master, not redrawn | Each output also carries **metadata** the pipeline produces from one table: the icon's name and keywords, whether it mirrors in right-to-left layouts, and whether it is single-color or multicolor. Names follow each platform's file-naming convention, but they all map back to one canonical name. ## Verify every output Conversion is where subtle breakage hides: a path rendered with the wrong fill rule shows a hole filled in; a stroke outlined at the wrong join looks chipped at small sizes. So the pipeline: - renders each generated output and compares it pixel-by-pixel with a rendering of the master; - fails the build on differences above a small threshold; - publishes a contact sheet — every icon on every platform side by side — for a human glance on each release. ## Release them together All outputs are produced from the same master commit and released under **one version number**, so “icons 4.2” means the same drawings everywhere. A new icon is available on every platform on the same day, and a fix reaches all four consumers at once. How each output is packaged and published is the library's distribution concern; the icon pipeline's job is that the outputs agree. ## Failure modes this design prevents - **Hand-patched outputs.** Someone fixes a native asset directly; the next regeneration silently reverts the fix. With outputs treated as generated files, the fix has to go into the master. - **Late discovery of unsupported features.** A designer uses a mask; it renders on the web and breaks on one native platform weeks later. Rejecting the feature at export makes the constraint visible immediately. - **Half-tinted icons.** One path keeps a baked black fill and the icon looks broken on dark surfaces. The fill-stripping check catches it before release. - **Editor and code disagreeing.** A designer uses an icon from the editor library that was renamed in code. Generating both from one master and one version removes the gap.

  • Should the master live in the design editor or in a code repository?
    Either works if there is exactly one. A design-editor master suits teams where designers own drawing, with an export step feeding the pipeline; a repository master suits teams wanting review and history on every change. What fails is two masters — an editor library and a repository both edited by hand — because they drift immediately.
  • Why keep the stroked source if the pipeline outlines strokes?
    Outlined shapes can no longer change stroke weight: a thicker variant, a new optical size or a style revision would mean redrawing every icon. Keeping the stroked drawing as the editable source and generating outlines from it preserves that flexibility while every platform still receives geometry it renders consistently.

saying these in an interview costs you the question

  • Each platform team should keep and edit its own copy of the icons.
  • Every native vector format supports everything a general vector file can express.
  • Raster exports at several densities are always needed on native mobile.
  • If an icon looks right in the design editor, every conversion will too.
  • The design-editor library can be redrawn by hand without causing drift.