Building a consistent icon system for a product suite

smplkit has fifteen products, and each one needs an icon that works at every size: the navigation flyout, the product page header, the console sidebar, marketing materials, and eventually favicons and mobile app icons. With one product you hand-craft an icon and move on. With fifteen, you need a system — because fifteen icons designed one at a time will look like fifteen icons designed one at a time, and a suite whose icons don’t match reads as a suite that was assembled rather than designed. Consistency is a trust signal: it says the same care went into the parts you can’t see.

The rules

Every smplkit product icon follows four rules:

Monochrome line icons. No fills, no gradients, no multiple colors. Each icon is a set of strokes on a transparent background. This keeps them legible at small sizes and lets CSS decide the color in context — the same icon can be white on a dark background, orange on hover, or muted when disabled, without swapping assets.

A thin rounded-square container. Every icon sits inside an identical rounded-square boundary, which gives grid layouts (the flyout, the product catalog) a uniform silhouette and stops any one icon from looking heavier than its neighbors.

SVG. SVGs scale infinitely, weigh almost nothing, and take styling from CSS. There is no reason to use raster images for UI icons in 2026 — a PNG that’s sharp at 32px is blurry at 64px on a Retina display, and an SVG is perfect at both.

Shared geometry. Same stroke width, same corner radius, same padding inside the container, for every icon. Put any two side by side and they look related, even when the subjects have nothing in common — a bell for Alerts, a key for Secrets, sliders for Config.

The hard part is icon fifteen, not icon one

Each icon has to communicate what its product does at a glance, while obeying the same rules as the other fourteen. Some are easy: Smpl Config gets a set of adjustment sliders, Smpl Flags gets a flag, Smpl Secrets gets a key. Familiar metaphors, no explanation needed.

Then you hit the products without an obvious picture. What does “Smpl Events” look like? A lightning bolt (implies speed, not events). A calendar (implies scheduling, not an event bus). A branching arrow (implies routing — close enough). “Smpl Tenants” is worse — we landed on a building silhouette, which maps to “multi-tenant” in a SaaS context without being too literal.

The monochrome constraint turns out to help here. When you can’t rely on color or fills to differentiate icons, you’re forced to make the subject and geometry do the work. The essential form has to carry the meaning, and the icons come out clearer for it.

20 pixels is the exam

Icons in the navigation flyout render at about 20px, and at 20px detail dies. Lines that sit too close together merge. Subtle curves flatten. Negative space that reads beautifully at 64px collapses into mud.

The design rules exist for this moment. A consistent stroke width means no icon has lines too thin to survive. Minimum spacing between elements means no icon becomes a blob. The shared container means every icon occupies the same footprint regardless of how dense its subject is.

We tested every icon at 20px, 32px, and 64px. Anything unclear at 20px got simplified until it wasn’t. The 64px rendering doesn’t have to match the 20px one — larger sizes can afford more detail — but the 20px version has to be recognizable instantly.

One asset, CSS does the rest

Because the icons are strokes with no hardcoded colors, their appearance is entirely a CSS decision: one asset per product, not one per product per theme. In the dark navigation they’re white; on hover they pick up the orange accent; disabled products in the flyout get a muted tone. The SVG file never changes.

This also covers contexts we haven’t designed yet. A mobile app with its own scheme, a partner page with a specific treatment — the icons adapt without new assets, because they never had opinions about color in the first place.

What it cost

Designing the system took a few days. Each icon inside the system takes maybe an hour, because the system has already made the decisions that take the time — weight, container, padding, style. Without it, every icon is a fresh negotiation.

The system paid for itself almost immediately: when the sixteenth product ships, its icon takes an hour and drops into the grid with zero visual integration work.