A restaurant point-of-sale app's logo looks blurry on high-density tablets and slightly off-color between screens, because teams copied cropped screenshots; how would you fix the logo supply in the design system?
answer
- one source of truth artwork
- derived exports, never hand-edited
- every lockup, version, size, density
- hand-tuned artwork at tiny sizes
- distribute from the system, remove copies
basics
~20 sMake one vector master per lockup and color version the single source, generate every raster export from it at each size and screen density, distribute that set from the design system, and replace the screenshot copies teams made.
solid answer
~40 sThe root cause is that each team made its own raster copy, so resolution and color drifted with every re-export. The fix is a **vector master** for each approved lockup and color version, owned by the brand and design-system teams, from which every **raster export** is generated at named sizes and at each screen density the platforms need. Very small sizes, like a launcher icon, get hand-tuned artwork because automatic downscaling blurs fine details. The set ships through the design system's asset package with its usage rules, the ad hoc copies are found and replaced, and a review or lint check flags logo files that did not come from the package.
go deeper
Know the difference between a vector master and a raster export, and that you take logo files from the design system's package, never from a screenshot.
Explain why rasters must derive from the master, how the export matrix of lockup, version, size and density is built, and why tiny sizes need tuned artwork.
Run the cleanup: inventory the copies, recover masters from the brand owner, script the export, publish it with rules, replace the copies and add a guard so drift cannot return.
Decide who owns the masters and how brand changes flow into products, and balance a lean export matrix against the placements every platform and printed surface actually needs.
## Why the logo drifted The scenario is common: a product team needed the logo, took a screenshot of the marketing site, cropped it and dropped it in the tablet header. Another team scaled that copy up for the idle screen; a third re-saved it after a color adjustment. Each step introduced loss: - **Resolution loss** - a raster image is a fixed grid of pixels. Scaling it beyond its native dimensions invents pixels, so on a high-density tablet the edges go soft. - **Color drift** - every screenshot and re-save can pass through a different color conversion, and hand-adjusted copies wander further from the brand values. - **Version confusion** - nobody can tell which copy is canonical, so the next team copies whichever it finds first. ## The model: one master, many derived exports | Asset | What it is | Who edits it | |---|---|---| | **Vector master** | Resolution-independent artwork made of paths and shapes, one per lockup and color version | Brand owner, through a controlled change | | **Raster exports** | Fixed-pixel images generated from the master at named sizes and densities | Nobody by hand - regenerated from the master | | **Small-size artwork** | Hand-tuned versions for tiny renderings | Designer, reviewed like the master | A vector master can be rendered at any size without compounding loss, so every raster is **derived** from it rather than from another raster. When the brand changes, the master changes once and the exports are regenerated; nothing is patched in place. Which file format each platform should receive, and its byte cost, is the image-performance owner's decision; the design-system decision is the source-and-derivation model. ## Building the export set The export matrix is the product of four axes: 1. **Lockup** - horizontal, stacked, symbol-only. 2. **Color version** - full-color, monochrome black, monochrome white, single-color. 3. **Size** - the named sizes surfaces actually use, such as header, splash, receipt and launcher icon. 4. **Density** - each screen density the target platforms render at, so a high-density tablet receives an export with enough pixels. Not every combination is needed; the set is driven by real placements. A point-of-sale product might need the symbol at header size for three densities, the horizontal lockup for the idle screen, and the monochrome black version at receipt width. ## Tiny sizes need their own artwork Automatic downscaling of a detailed master at very small sizes blurs hairlines, fills in small counters and turns the wordmark into noise. Brand teams therefore often provide **optically tuned** small-size artwork - thicker strokes, simplified details, sometimes the symbol only - for launcher icons, tab indicators and similar placements. It is still approved artwork with its own master, not a local tweak. ## A trade-off: clear space in the asset or in the layout Exports can either include the logo's clear space as transparent padding, or be cropped tight to the artwork with clear space applied by the layout. - **Padding baked in** makes crowding harder, but complicates alignment, because the visible mark no longer sits on the asset's edge. - **Tight crop plus a layout rule** aligns cleanly, but relies on each placement honouring the margin. Either is defensible; what matters is choosing one, documenting it and applying it to the whole set. ## Rolling out the fix 1. **Inventory** every logo file in use across the apps, printed templates and customer-facing displays. 2. **Build or recover the vector masters** from the brand owner; never trace them from a screenshot. 3. **Generate the export set** with a repeatable script so the matrix can be rebuilt on demand. 4. **Publish** it through the design system's asset package, with the lockup, version and clear-space rules beside it. 5. **Replace** the ad hoc copies and remove them from the repositories. 6. **Guard** the result: a review checklist item or an automated check that flags logo images not sourced from the package. ## What a native mobile team recognises Nothing in this model is specific to the web. A native tablet app also receives raster exports per screen density, a launcher icon set with its own tuned artwork, and printed or embedded surfaces such as receipts. Whether a platform renders the vector source directly or takes pre-rendered images, the ownership rule is the same: one controlled master, derived outputs, no hand-edited copies. The outcome is that a blurry or off-color logo becomes a bug with one place to fix, instead of a dozen copies to hunt.
- Why not ship only the vector master and let every platform render it at runtime?Rendering from a vector source is often a good default, but it does not remove the need for derived assets: tiny sizes still need hand-tuned artwork, some surfaces such as receipt printers or launcher icons expect fixed-size images, and the master still needs a controlled owner. The source-and-derivation model applies either way.
- How do you keep the export set from drifting again after the cleanup?Make regeneration the only way exports change: a scripted export from the masters, published as a versioned asset package, with a check in review or in the build that flags logo images not coming from that package. A brand change then becomes one master edit plus one regeneration.
saying these in an interview costs you the question
- Upscaling a small raster export is fine on high-density screens
- A vector master renders perfectly at tiny sizes without tuning
- Recoloring an export by hand is quicker than regenerating it
- Tracing a screenshot is an acceptable way to recreate the master
- Each product team should keep its own copy of the logo files