Designsystem-Icons aufbauen – konsistente Symbole für UI

Ein gut gemachtes Icon-System wirkt im Interface unscheinbar – bis etwas nicht passt. Unterschiedliche Strichstärken, wackelige Ausrichtungen oder fehlende Zustände machen eine Oberfläche sofort unruhig. Ein sauberes Set an Icons spart Zeit, stärkt den Markenauftritt und verbessert die Orientierung.

Dieser Leitfaden zeigt Schritt für Schritt, wie sich robuste Designsystem-Icons planen, zeichnen, dokumentieren und an das Entwicklungsteam übergeben lassen – egal ob mit Figma, Sketch, Illustrator oder einem anderen Vektor-Tool.

Icon-System im UI-Design planen

Bevor das erste Icon gezeichnet wird, lohnt sich ein klarer Rahmen. Er legt fest, wie die Symbole später aussehen, funktionieren und wachsen können.

Ziele und Einsatzbereiche definieren

Am Anfang steht eine einfache Frage: Wofür werden die Icons benötigt? Häufige Einsatzbereiche:

• Navigation (Tabbar, Sidebar, Hauptmenü)
• Aktionen (Speichern, Teilen, Löschen, Filtern)
• Statusanzeigen (Erfolg, Warnung, Fehler, Info)
• Medien und Inhalte (Bilder, Videos, Dokumente)
• Branche-spezifische Symbole (z. B. Finanzen, Gesundheit, Logistik)

Je klarer die Zielbereiche beschrieben sind, desto leichter lassen sich Umfang, Detailgrad und notwendige Zustände planen.

Icon-Stil festlegen: Outline, Filled oder Duo?

Der Stil der Icons sollte zum Rest des Interface passen. Wichtige Grundentscheidungen:

• Outline-Icons: symmetrische Linien, luftige Optik, gut für moderne Dashboards und minimalistische UIs.
• Gefüllte Icons: einfache Silhouetten, klar lesbar bei kleinen Größen, eignen sich gut für Mobile-Anwendungen.
• Hybrid-Sets (Outline + Filled): eine Variante für ruhige Zustände, eine für aktive oder markierte Zustände.

Der Stil sollte außerdem mit Typografie und Farbsystem harmonieren. Wer bereits ein Farbsystem im Designsystem hat, wie in einem strukturierten Ansatz zu Designsystem-Farben in Figma beschrieben, kann Icons direkt darauf abstimmen.

Icon-Größe und Grid bestimmen

Ein konsistentes Icon-Grid sorgt dafür, dass alle Symbole optisch gleich groß wirken und sauber in Buttons und Listen sitzen.

• Typische Canvas-Größen sind 16×16, 20×20, 24×24 oder 32×32 Pixel.
• Das Grid orientiert sich an den typischen UI-Abständen (Spacing) und der verwendeten Fontgröße.
• Innerhalb des Grids bleibt ein optischer „Safe Space“, damit das Icon nicht bis an den Rand stößt.

In Figma oder ähnlichen Tools hilft es, das Grid als Komponente mit Hilfslinien (z. B. 24×24 Pixel mit einem inneren 20×20-Bereich) anzulegen und alle Icons darauf aufzubauen.

Icon-Sets strukturieren: Kategorien, Namen, Varianten

Ein gutes Icon-Design ist nur die halbe Miete – mindestens genauso wichtig ist ein System, in dem sich Teams schnell zurechtfinden.

Naming-Konvention für Icons aufsetzen

Die Benennung der Icons ist entscheidend für Suchbarkeit und Zusammenarbeit mit Entwickler:innen. Bewährt haben sich einfache, sprechende Namen auf Englisch, getrennt durch Bindestriche oder Schrägstriche:

• navigation/home, navigation/settings
• action/add, action/edit, action/delete
• status/success, status/error

Varianten lassen sich ergänzen durch Suffixe wie „-filled“, „-outline“ oder „-16“, „-24“, wenn mehrere Größen unterstützt werden.

Icon-Kategorien und Prioritäten definieren

Nicht alle Icons sind gleich wichtig. Für den Start reicht ein Kernset, das häufige Interaktionen abdeckt:

• Navigation (Home, Suche, Profil, Einstellungen)
• CRUD-Aktionen (Create, Read, Update, Delete)
• Medien (Play, Pause, Download, Upload)
• Feedback (Check, Warning, Error, Info)

Seltene oder sehr spezifische Icons können später ergänzt werden. So bleibt das System schlank und übersichtlich.

Varianten und Zustände einplanen

Icons brauchen oft Varianten für unterschiedliche Zustände:

• Standard, Hover, Aktiv, Deaktiviert
• Gefüllt vs. Kontur zur Kennzeichnung von „aktiv“ (z. B. Herz-Icon bei Favoriten)
• Farbliche Varianten für Status (Erfolg, Fehler, Warnung)

Für komplexere Komponenten – etwa Navigationsleisten oder Microinteractions – lässt sich das gut mit einem Designsystem verbinden, wie es bei Microinteractions im UI-Design beschrieben ist.

Icons in Figma & Co. zeichnen: Praxisregeln

Wenn das Raster steht, geht es ans Zeichnen. Einige einfache, aber strenge Regeln machen das Set dauerhaft wartbar.

Pixel-Perfect: auf ganze Pixel ausrichten

Unscharfe Icons entstehen meist, weil Pfade und Formen nicht auf ganzen Pixeln liegen. Um das zu vermeiden:

• In Vektor-Tools die Pixelraster-Anzeige aktivieren.
• Konturen zentriert oder „inside“ ausrichten, damit die Linie genau auf dem Pixel sitzt.
• Koordinaten und Größen von Formen auf ganze Zahlen runden.

Gerade bei 16×16- oder 20×20-Icons entscheidet diese Präzision über die Lesbarkeit.

Strichstärken und Ecken vereinheitlichen

Konsistenz bei Linien und Ecken sorgt für einen ruhigen Gesamteindruck:

• Eine Basis-Strichstärke definieren (z. B. 1.5 px oder 2 px) und konsequent verwenden.
• Einheitliche Eckradien (z. B. 2 px für alle runden Ecken) festlegen.
• Symmetrische Formen bevorzugen, um spätere Anpassungen zu vereinfachen.

Wer bereits definierte Ecken und Radien aus dem Button- oder Karten-Design nutzt, schafft einen deutlich geschlosseneren Look im gesamten Interface.

Visuelles Gewicht angleichen

Auch wenn alle Strichstärken gleich sind, können Icons unterschiedlich „schwer“ wirken. Hier hilft eine visuelle Kontrolle:

• Vergleichszeile mit 8–10 häufigen Icons nebeneinander aufbauen.
• Prüfen, ob Formdichte, Negative Space und optische Größe ähnlich wirken.
• Bei sehr komplexen Icons Details reduzieren, damit sie nicht dominieren.

Im Zweifel gilt: Lieber weniger Details, dafür klare, wiedererkennbare Formen – besonders bei kleinen UI-Größen.

Icon-Bibliothek im Designsystem aufbauen

Ein Set isolierter SVG-Dateien ist schwer zu pflegen. Besser ist eine strukturierte Bibliothek als Teil des Designsystems.

Icons als Komponenten organisieren

In Figma, Sketch oder ähnlichen Tools sollten Icons als Komponenten angelegt werden:

• Eine Hauptbibliothek mit allen Icons, sortiert nach Kategorien.
• Benennung nach der zuvor definierten Naming-Konvention.
• Optional Varianten (z. B. Outline/Filled) über Komponent-Varianten bündeln.

Dadurch lassen sich Icons in Dateien einfach austauschen und aktualisieren, ohne jedes Layout per Hand anfassen zu müssen.

Tokens und Farbsystem verbinden

Icons sollten möglichst selten direkte Farben enthalten. Stattdessen werden Farb- und Größenangaben mit Design-Tokens verbunden:

• Primäre Iconfarbe (z. B. „icon/default“), die an die primären Textfarben angelehnt ist.
• Status-Farben (z. B. „icon/success“, „icon/error“), die an das Alert-System gekoppelt sind.
• Größen-Tokens (z. B. „icon/sm“, „icon/md“, „icon/lg“), abgestimmt auf Schriftgrößen und Spacing.

Diese Logik ähnelt dem Aufsetzen eines typografischen Systems, wie es in einem sauberen responsiven Typografie-Design genutzt wird.

Mini-Fallbeispiel: Icon-Set für eine SaaS-Plattform

Eine B2B-SaaS-Plattform plant ein neues Interface. Für den Start werden benötigt:

• 24 Kern-Icons für Navigation und Aktionen
• 4 Status-Icons (Info, Erfolg, Fehler, Warnung)
• 8 branchenspezifische Icons (z. B. Server, Datenbank, API, Dashboard)

Das Team entscheidet sich für 24×24-Pixel-Outline-Icons mit 2 px Strichstärke. Alle Icons sitzen auf einem 24×24-Grid mit einem inneren 20×20-Safe-Space. Die Namen folgen dem Muster „category/name“ und werden als Figma-Komponenten mit Varianten für „Default“ und „Active“ angelegt.

Icons für Entwickler:innen aufbereiten

Damit das Icon-System im Code genauso konsistent bleibt, braucht es eine saubere Übergabe und ein klares Format.

Export-Formate wählen: SVG, Icon-Font oder Komponenten?

Moderne UIs setzen fast immer auf SVG-basierten Icon-Export. Drei gängige Varianten:

• Einzelne SVG-Dateien, die in eine Icon-Library im Code importiert werden (z. B. React-Komponenten).
• Automatisch generierte Icon-Komponenten (z. B. über Build-Skripte), die die SVGs direkt kapseln.
• Seltener: Icon-Fonts – eher noch in älteren Projekten oder für spezielle Fälle.

SVGs bieten die beste Kontrolle über Farben, Größen und Accessibility und lassen sich gut automatisiert weiterverarbeiten.

Constraints, Padding und ViewBox sauber definieren

Beim Icon-Export führen kleine Ungenauigkeiten schnell zu Layout-Problemen:

• Alle Icons sollten dieselbe ViewBox haben (z. B. 0 0 24 24), unabhängig von ihrer Form.
• Kein zusätzliches, unsichtbares Padding im SVG – das übernimmt das Layout-System im Code.
• Linienstärken sollten im SVG absolut definiert sein, nicht relativ oder per „non-scaling-stroke“, wenn das Projekt das nicht explizit vorsieht.

Vor dem Export hilft eine kurze Kontrollrunde mit dem Entwicklungsteam, um sich auf Standardwerte zu einigen.

Dokumentation für Nutzung und Barrierefreiheit

Für ein stabiles Icon-System reicht eine Design-Datei nicht aus. Nützlich sind:

• Eine kurze Guideline im Designsystem: Stil, Do’s & Don’ts, Beispiele.
• Hinweise zur Verwendung von „aria-label“, „title“ und Alternativtexten.
• Empfehlungen zur Mindestgröße und zu Kontrastanforderungen.

So bleibt die Zugänglichkeit erhalten – ein Aspekt, der in vielen Projekten zunächst übersehen wird.

Checkliste: konsistente Icon-Systeme im Alltag pflegen

Die eigentliche Herausforderung eines Systems ist nicht der Start, sondern der Alltag. Neue Features, neue Teams, neue Anforderungen – das Icon-Set wächst mit. Eine kurze Checkliste hilft dabei, den Überblick zu behalten.

So geht’s: Icon-System laufend aktuell halten

• Neue Icon-Anfragen sammeln und regelmäßig bündeln, statt ad hoc zu reagieren.
• Vor jedem neuen Icon prüfen: Lässt sich ein vorhandenes Symbol wiederverwenden oder anpassen?
• Alle neuen Icons mit derselben Grid-Vorlage und denselben Stilregeln erstellen.
• Design- und Code-Bibliothek gemeinsam aktualisieren und synchron halten.
• Einfaches Changelog führen: Datum, Icon-Name, Kategorie, Änderung.

Vergleich: eigene Icons erstellen oder Icon-Bibliothek nutzen?

Nicht jedes Projekt braucht ein komplett eigenes Icon-Set. Manchmal ist eine bestehende Bibliothek sinnvoller. Ein knapper Vergleich hilft bei der Entscheidung.

Für kleinere Projekte genügt oft ein gut ausgewähltes Set aus einer etablierten Bibliothek. Größere Plattformen und Marken profitieren dagegen langfristig von einem eigenen System, das eng mit Komponenten, Typografie und Layout-Rastern verzahnt ist – ähnlich strukturiert, wie es beim Aufbau von Designsystem-Komponenten in Figma sinnvoll ist.

Empfehlung der Redaktion: pragmatisch starten, systematisch wachsen

Ein ausgereiftes Icon-System entsteht selten in einem Sprint. Ein pragmatischer Einstieg besteht aus:

• einem klaren Grid und Stilregeln,
• einem kleinen, sauberen Kernset,
• und einer einfachen Dokumentation für Design und Entwicklung.

Darauf aufbauend lässt sich das System schrittweise erweitern – immer dann, wenn neue Features oder Produktbereiche entstehen. Entscheidend ist, dass jedes neue Icon die gleichen Regeln befolgt wie die ersten. So bleiben UI-Icons für alle Beteiligten berechenbar: für Nutzer:innen, für Designer:innen und für Entwickler:innen.