Vector Versus Raster for a Scalable Icon System
A team is building an icon set for a dashboard that renders at multiple sizes: 16 px in dense tables, 24 px in toolbars, and 64 px in empty-state illustrations. A junior designer exported each icon as a 512 px PNG and is scaling them down in the interface. At 16 px, several icons look blurry and their thin strokes disappear; at 64 px, edges look slightly soft. The design lead wants crisp rendering at every size with minimal maintenance, and the front-end team wants small file sizes and simple theming (changing icon color via CSS). There are about 120 icons. The team debates redrawing everything as vectors versus improving the PNG pipeline. Time is limited, and some icons include subtle gradients.
1. Compare the vector and raster approaches for this icon system against the stated requirements. Which should the team choose, and why?
Read the worked answer
The requirements are crispness at 16, 24, and 64 px, low maintenance across 120 icons, small files, and CSS-based recoloring. Raster PNGs scaled down blur because downsampling averages pixels, and thin strokes at 16 px fall below a pixel and vanish; scaling up softens edges. A PNG pipeline would need multiple hand-tuned exports per icon and per size, multiplying maintenance. Vectors (SVG) store geometry, so they render sharply at any size, and color can be controlled with CSS fill or currentColor, satisfying theming. File sizes for simple icons are small. The main caveat is the subtle gradients: SVG supports gradients, but very complex effects can bloat files or render inconsistently. The team should choose vectors, converting gradients to SVG gradients where feasible and simplifying any effect that does not survive at 16 px. For 120 icons, a vector source of truth minimizes maintenance and meets crispness and theming.
2. Describe how to handle the small-size legibility problem and the gradient icons within a vector workflow.
Read the worked answer
Small-size legibility is a design problem, not only a format problem. At 16 px, thin strokes and fine detail cannot resolve, so the team should create optical variants: a simplified 16 px version with thicker strokes, aligned to the pixel grid, and fewer details, while the 24 and 64 px versions keep more detail. SVG allows this via separate symbols or a size-aware set, and stroke widths can be tuned so edges land on pixel boundaries to avoid blur. For gradients, keep them as SVG linear or radial gradients so they scale cleanly; test rendering at each size, since subtle gradients may band or disappear at 16 px, in which case a flat fill is preferable at that size. Establish a consistent grid and stroke system, document the variants, and validate in the actual browser at target sizes. This preserves crispness, theming, and manageable maintenance across all 120 icons.