Icon-System-Design: Ikonografie, die über 50 Symbole hinaus skaliert
Ein Praxisleitfaden für Icon-Systeme. Raster, Strichstärke, optische Korrektur, Benennung, Governance und die Regeln, die eine Icon-Bibliothek davor bewahren, zu verrotten, sobald die dritte Designerin sie anfasst.
Die meisten Icon-Bibliotheken in Produkten verrotten. Die erste Designerin liefert ein sauberes Set aus vierzig Symbolen. Der zweite Designer braucht drei weitere und zeichnet sie freihändig nach, in der falschen Strichstärke. Der dritte Designer lädt an einem Freitag aus einem Gratis-Pack herunter, um ein Feature rauszuhauen. Im zweiten Jahr des Produkts wirkt die Icon-Spalte auf jedem Screen wie vier verschiedene Marken, die in eine Navigation genäht wurden.
Dieses Paper ist die Arbeitsversion. Raster, Strichstärke, optische Korrektur, Benennung, Governance und die kleine Menge an Regeln, die ein Icon-System über 50 Symbole hinaus stimmig halten. Keine Icon-der-Woche-Showcases, keine Templates, die so tun, als wären sie Systeme, nur die Entscheidungen, mit denen eine echte Bibliothek ein echtes Team überlebt.
Was ein Icon-System wirklich ist
Ein Icon-System ist ein stimmiges Set von Piktogrammen, das von gemeinsamen Regeln gesteuert wird. Rastergröße, Strichstärke, Eckenradius, optische Ausrichtung, Benennung und der Prozess, mit dem neue Icons hinzukommen. Ziel ist nicht ein Ordner voller SVGs. Ziel ist ein System, das jede Designerin und jeder Engineer erweitern kann, ohne den visuellen Rhythmus des Produkts zu brechen.
Ein Haufen Icons ist kein System. Eine Figma-Datei mit 200 Symbolen und ohne Regeln ist kein System. Ein System hat Constraints, benannte Entscheidungen und einen schriftlichen Prozess dafür, was passiert, wenn jemand ein Icon braucht, das es noch nicht gibt.
Der Design-Systems-Leitfaden behandelt das größere System, in dem Icons leben. Dieses Paper geht gezielt in die Tiefe der Ikonografie-Schicht.
Warum Icons wichtiger sind, als sie aussehen
Icons sind das dichteste Stück UI in jedem Produkt. Ein einziges Icon mit 24x24 Pixeln trägt mehr Bedeutung pro Quadratzentimeter als jedes andere Element auf dem Screen. Wenn das System stimmt, wirkt das Produkt wie aus einem Guss. Wenn nicht, fühlt sich jeder Screen auf eine Art falsch an, die Nutzer nicht benennen können.
Icons skalieren auch merkwürdig. Eine Schriftabweichung zwischen zwei Screens fällt leicht auf. Eine Icon-Abweichung ist schwerer zu benennen, aber lauter im Gefühl. Das Gehirn verarbeitet Piktogramme schneller als Text, also erkennt es Icon-Inkonsistenz schneller als Textinkonsistenz.
Das Produkt, das Icons als stimmiges System ausliefert, wirkt poliert, selbst wenn der Rest grob ist. Das Produkt, das Icons als Freifahrtschein ausliefert, wirkt billig, selbst wenn der Rest scharf ist.
Das Raster ist das System
Jede stimmige Icon-Bibliothek beginnt mit einem Raster. Das Raster ist das unsichtbare Gerüst, an dem jedes Icon einrastet. Ohne es driften Icons in Größe, Strichstärke und optischer Balance, und im Code Review lässt sich Stimmigkeit nicht durchsetzen.
Das Basisraster
Wähle eine Basisrastergröße und bleib darin. Die zwei Standards, die 2026 funktionieren:
- 24-Pixel-Raster für Icons in der Produkt-UI. Standardgröße für die meisten modernen Interfaces.
- 20-Pixel-Raster für dichte Daten-Interfaces, Dashboards und Admin-Tools.
Ein Raster ist nicht nur die Canvas-Größe. Es ist auch die Live-Area innerhalb des Canvas, in der das Icon tatsächlich sitzt. Ein 24-Pixel-Raster hat eine Live-Area von 20 Pixeln, mit 2 Pixeln Abstand an jeder Seite. Der Abstand gibt dem Icon Luft und verhindert, dass es neben benachbarten Elementen gedrängt wirkt.
Keylines im Raster
Die Live-Area hat interne Keylines, die die Form steuern. Eine 20-Pixel-Live-Area bekommt vier Keyline-Formen:
| Form | Größe | Verwendung |
|---|---|---|
| Quadrat | 18x18 px | Die meisten rechteckigen Icons (Ordner, Dokument) |
| Kreis | 20x20 px | Runde Icons (Sonne, Info, Avatar) |
| Hochformat-Rechteck | 16x20 px | Vertikale Icons (Batterie, Telefon) |
| Querformat-Rechteck | 20x16 px | Horizontale Icons (Suche, Nachricht) |
Jede Keyline erzeugt bei gleicher Größe ein visuell ausbalanciertes Icon. Ein Kreis mit 18 Pixeln wirkt kleiner als ein Quadrat mit 18 Pixeln, weil das menschliche Auge Kreise als kleiner liest. Die Keylines gleichen diese Wahrnehmungsmacke aus.
Strichstärke als Token
Wähle eine Strichstärke und bleib dabei. Die meisten Produkt-Icon-Systeme nutzen am 24-Pixel-Raster Striche mit 1,5 oder 2 Pixeln. Entscheide nach der Markenstimme.
Ein 1,5-Pixel-Strich wirkt leicht, technisch und modern. Ein 2-Pixel-Strich wirkt selbstbewusst, freundlich und zugänglich. Ein 3-Pixel-Strich wirkt kräftig, kindgerecht oder printartig. Wähle einen. Dokumentiere ihn als Token. Lehne jeden Icon-Beitrag ab, der eine andere Stärke nutzt.
Das Glossar zu Design Tokens zeigt, wie die Strichstärke in die breitere Token-Architektur passt.
Optische Korrektur macht den Unterschied
Mathematische Ausrichtung ist keine visuelle Ausrichtung. Icons, die perfekt am Raster einrasten, sehen oft falsch aus, weil das menschliche Auge keine Pixel misst, sondern wahrgenommenes Gewicht und Balance.
Warum es optische Korrektur gibt
Ein Kreis mit 20x20 Pixeln und ein Quadrat mit 20x20 Pixeln wirken nicht gleich groß. Das Quadrat hat mehr visuelle Masse, weil es seine Bounding Box komplett ausfüllt. Der Kreis hat leeren Raum in den Ecken, den das Auge als kleineres Objekt registriert.
Die Lösung: den Kreis etwas größer als die Bounding Box zeichnen, manchmal um 1 bis 2 Pixel. Die Mathe sagt falsch, das Auge sagt richtig. Vertraue immer dem Auge.
Häufige optische Korrekturen
Fünf Korrekturen decken den Großteil der Icon-Arbeit ab:
- Kreise wirken größer als Quadrate. Erhöhe Kreis-Keylines um 1 bis 2 Pixel.
- Dreiecke wirken kleiner als Quadrate. Erhöhe Dreieck-Keylines um 2 bis 3 Pixel.
- Diagonale Linien wirken dünner als horizontale. Gib Diagonalen 0,25 bis 0,5 Pixel mehr Stärke.
- Die Mitten asymmetrischer Icons driften. Zentriere Play-Buttons, Pfeile und Chevrons optisch nach Augenmaß, nie nach Bounding Box.
- Spitze Ecken wirken kleiner. Runde Innenecken leicht ab, damit sie zum wahrgenommenen Gewicht der Außenecken passen.
Diese Korrekturen sind keine Meinung. Teste jedes Icon in einer mathematisch perfekten und einer optisch korrigierten Version nebeneinander in kleinen Größen. Die optisch korrigierte gewinnt immer. Immer.
Stilentscheidungen, die sich aufsummieren
Sobald Raster und Strichstärken stehen, muss jede weitere Stilentscheidung einmal getroffen und überall angewendet werden. Inkonsistenz in einer davon wirkt, als hätten zu viele Hände an der Bibliothek gearbeitet.
Eckenradius
Wähle einen äußeren und einen inneren Eckenradius. Die beiden gehören als Paar zusammen.
Ein äußerer Radius von 1 Pixel und ein innerer von 0,5 Pixel wirkt knackig und modern. Ein äußerer Radius von 2 Pixeln und ein innerer von 1 Pixel wirkt freundlich und rund. Ein kantiges Set ohne Radius wirkt architektonisch und ernst.
Der falsche Zug ist, Radien in derselben Bibliothek zu mischen. Schon ein Icon mit schärferen Ecken als der Rest wirkt wie aus einem anderen Set geborgt.
Endkappen und Verbindungen
Striche haben Enden. Endkappen können eckig, rund oder überstehend sein. Verbindungen zwischen Strichen können Gehrung (spitz), rund oder abgeschrägt sein. Wähle je eine Variante und wende sie im ganzen System an.
Runde Endkappen und runde Verbindungen ergeben ein freundliches, zugängliches Icon-Set. Eckige Endkappen und Gehrungsverbindungen ergeben ein präzises, technisches Set. Gemischte Endkappen in derselben Bibliothek ergeben ein Set, das halb fertig aussieht.
Gefüllt vs. Outline
Die meisten modernen Icon-Systeme liefern zwei Varianten jedes Icons: eine Outline-Version für inaktive Zustände und eine gefüllte Version für aktive Zustände. Die Outline-Version nutzt den Strich. Die gefüllte Version nutzt dieselbe Form mit gefülltem Inneren.
Die beiden Varianten müssen visuell ausbalanciert sein. Eine gefüllte Version in gleicher Größe wirkt oft schwerer und dominanter als die Outline. Die Lösung ist, die Fläche der gefüllten Version um 1 bis 2 Pixel leicht zu verkleinern, damit das visuelle Gewicht in gleicher Skalierung zur Outline passt.
Das Glossar zum Fokuszustand zeigt, wie der Wechsel von Outline zu gefüllt ins größere Design von Interaktionszuständen passt.
Benennung ist das halbe System
Eine Bibliothek mit 200 gut gezeichneten Icons, die niemand findet, ist eine Bibliothek, die niemand nutzt. Benennung ist die Auffindbarkeitsschicht, und schlechte Benennung killt die Akzeptanz schneller als schlechtes Zeichnen.
Benennungsmuster, die skalieren
Benenne objektzuerst, nicht metaphernzuerst. Das Icon einer Lupe heißt search oder magnifier, niemals find oder look. Das Objekt ist stabil. Die Metapher wechselt mit dem Kontext.
Nutze Kebab-Case für mehrteilige Icons: arrow-left, chevron-down, cloud-upload. Einheitliche Schreibweise lässt Engineers die Bibliothek greppen, in IDEs autovervollständigen und ohne Tippfehler ausliefern.
Nutze Richtungssuffixe nur, wenn nötig. arrow reicht nicht. arrow-left, arrow-right, arrow-up, arrow-down ist das Minimum. Dasselbe gilt für Chevrons, Carets und jedes andere gerichtete Piktogramm.
Benennung von Varianten
Wenn ein Icon mehrere Varianten hat (Outline, gefüllt, zweifarbig), hänge die Variante als Suffix an:
search(Standard, Outline)search-filledsearch-duotone
Dieses Muster erlaubt es dem Engineer, search-filled in einen Button zu ziehen, ohne in einem separaten Ordner wühlen zu müssen. Vorhersehbare Benennung ist schneller als perfekte Organisation.
Synonym-Maps
Das größte Benennungsversagen ist das Icon, das eine Designerin nicht findet, weil sie nach dem falschen Wort gesucht hat. Baue eine Synonym-Map neben die Bibliothek. cart findet auch bag, shopping. home findet auch house, dashboard. delete findet auch trash, remove, bin.
Die meisten modernen Icon-Suchtools (Iconify, Lucide, Phosphor) haben Synonym-Maps in ihre Such-UI eingebaut. Baue dasselbe in die interne Bibliothek oder akzeptiere, dass Designer weiter doppelte Icons hinzufügen, weil sie das vorhandene nicht gefunden haben.
Governance hält das System am Leben
Die technischen Entscheidungen oben kann jede kompetente Designerin reproduzieren. Die Governance-Entscheidungen trennen ein System, das lebt, von einem System, das im zweiten Jahr stirbt.
Die Single Source of Truth
Wähle einen Ort, an dem Icons leben. Entweder eine Figma-Bibliothek, ein Code-Repo mit SVGs oder ein gehosteter Dienst wie Iconify. Wähle einen. Dort lebt die Bibliothek. Jede Designerin zieht von dort. Jeder Engineer zieht von dort.
Ein System mit zwei Quellen der Wahrheit hat null Quellen der Wahrheit. Die Figma-Bibliothek und die Code-Bibliothek driften bis Woche drei auseinander, und von da an liefert jeder Screen Icons aus, die nicht zum System passen.
Der Beitragsprozess
Dokumentiere den Prozess zum Hinzufügen eines neuen Icons. Der Prozess muss enthalten:
- Zuerst suchen. Bestätige, dass das Icon nicht schon unter anderem Namen existiert.
- Die Ergänzung begründen. Schreibe einen Satz dazu, was das Icon darstellt und wo es eingesetzt wird.
- Nach Spezifikation zeichnen. Passe Raster, Strichstärke, Eckenradius, Endkappen und Verbindungen an die bestehende Bibliothek an.
- Optisches Review. Eine zweite Designerin prüft das Icon in 16, 20 und 24 Pixeln auf visuelle Balance.
- Benennen und ausliefern. Der Name folgt dem Benennungsmuster. Auslieferung an Figma und Code im selben PR.
Ein System ohne Beitragsprozess ist ein System, das umgangen wird. Beim ersten Mal, wenn ein Designer dringend ein Icon braucht, lädt er es aus einem Gratis-Pack herunter und liefert es ohne Rückfrage aus. Ab dann hat die Bibliothek einen Fork.
Der Deprecation-Prozess
Icons werden deprecated. Ein Redesign verabschiedet einen alten Stil, ein Feature wird gestrichen, ein Brand Refresh ändert die visuelle Sprache. Dokumentiere, wie Icons die Bibliothek verlassen, nicht nur, wie sie hineinkommen.
Markiere deprecated Icons in der Bibliothek mit einem sichtbaren Label. Halte sie 90 Tage verfügbar, damit bestehende Screens Zeit zur Migration haben. Dann entferne sie. Eine Bibliothek, die nie Icons entfernt, wird zum Museum, und Museen werden ignoriert.
Wie Icons in den Code kommen
Die Übergabe zwischen Design und Code ist die Stelle, an der die meisten Icon-Systeme brechen. Die Figma-Bibliothek ist makellos, die Code-Bibliothek ein Friedhof inkonsistenter SVGs, und Engineers hören auf, beiden zu vertrauen.
SVG ist das Format
Liefere Icons als SVG aus. Nicht als PNG, nicht als Icon-Fonts. SVG ist vektorbasiert, skaliert verlustfrei auf jede Größe, unterstützt das Erben von currentColor für einfaches Theming und ist klein genug, um in Komponenten inline eingebettet zu werden.
Jedes SVG hat eine viewBox passend zum Raster (24x24 oder 20x20), nutzt currentColor für Strich und Füllung und enthält keine überflüssigen Transforms oder Styles. Ein sauberes SVG ist kleiner als 1 KB. Die meisten Icon-Bibliotheken liefern Icons mit 3 bis 5 KB, weil sie mit Standardeinstellungen exportiert wurden, die Metadaten, Transforms und Inline-Styles einbetten, die niemand braucht.
Optimierung ist nicht verhandelbar
Schicke jedes SVG durch SVGO, bevor es im Code-Repo landet. SVGO entfernt Metadaten, vereinfacht Pfade, löscht redundante Attribute und senkt die Dateigröße im Schnitt um 60 bis 80 %.
Bei einer Bibliothek mit 200 Icons liegt der Unterschied zwischen unoptimiert und optimiert meist bei 400 KB bei jedem Seitenaufruf. Das ist ein Lighthouse-Treffer, eine Verschlechterung der Core Web Vitals und ein langsameres Mobile-Erlebnis ohne Grund.
Komponenten-Wrapper
Packe jedes SVG in eine typisierte Komponente (React, Vue, Svelte). Die Komponente nimmt Props für Größe, Farbe und Accessibility entgegen. Der Engineer importiert nie ein rohes SVG. Er importiert ein <Icon name="search" size={20} />, und das System erledigt den Rest.
Dieses Muster bedeutet, dass die Icon-Bibliothek ihr zugrunde liegendes Exportformat (SVG, Sprite, Icon-Font) ändern kann, ohne den konsumierenden Code anzufassen. Die Komponente ist die API, das SVG die Implementierung.
Das Glossar zum Design-Handoff behandelt die breitere Übergabedisziplin. Icons sind einer der wenigen Fälle, in denen Designer und Engineers die Verantwortung wirklich teilen.
Häufige Fehler bei Icon-Systemen
Jedes Icon-Audit findet dieselben Fehler. Wenn das System mit einem davon ausgeliefert wird, ist die Bibliothek ein Redesign von einem kompletten Neuaufbau entfernt.
Drei Strichstärken in einer Bibliothek. Heißt fast immer, dass die Bibliothek aus mehreren Gratis-Packs zusammengebaut wurde. Die Lösung ist ein erzwungenes Neuzeichnen des gesamten Sets in einer Stärke.
Gefüllte und Outline-Varianten in unterschiedlichen Maßstäben. Die gefüllte Version wirkt größer als die Outline, weil niemand das wahrgenommene Gewicht ausgeglichen hat. Die Lösung ist, die gefüllte Version um 1 bis 2 Pixel zu verkleinern, bis beide gleich groß wirken.
Uneinheitlicher Eckenradius. Die Hälfte der Icons hat runde Ecken, die andere Hälfte eckige. Fast immer, weil zwei verschiedene Designer ohne schriftliche Regel beigetragen haben. Die Lösung ist, einen Radius zu definieren und zu refaktorieren.
Benennung nach Metapher. Icons heißen find, look, discover statt nach dem Objekt, das sie zeigen. Designer finden sie nicht. Die Lösung ist die Umbenennung nach objektzuerst-Konventionen.
Kein Deprecation-Prozess. Die Bibliothek hat 350 Icons, von denen 80 ungenutzt oder ersetzt sind. Der Ballast bremst die Suche und verwirrt neue Designer. Die Lösung ist ein vierteljährliches Audit und ein 90-Tage-Deprecation-Zyklus.
Icon-Systeme unter den Bedingungen von 2026
Drei Verschiebungen haben verändert, wie Icon-Systeme gebaut werden. Das System muss sie überleben.
Variable Icon-Fonts sind real. Neue Formate erlauben es, dass eine Icon-Datei mehrere Strichstärken, Füllungen und optische Größen trägt, die weich interpolieren. Der technische Vorteil ist enorm, das Designrisiko ist, dass Teams jede Variante auf jedem Screen ausliefern, weil sie es können. Wähle die Varianten, die ausgeliefert werden. Streiche den Rest.
KI-Tools erzeugen Icons in Sekunden. Midjourney, DALL-E und ChatGPT liefern mit einem Prompt ein brauchbares Icon. Das Risiko ist, dass Designer aufhören, Icons zu zeichnen, und anfangen, sie zu prompten, was die Systemstimmigkeit killt, weil jeder Prompt einen leicht anderen Stil erzeugt. Nutze KI für erste Entwürfe. Überarbeite jedes Ergebnis, damit es zum System passt.
Lucide, Phosphor und Heroicons setzen die Baseline. Diese offenen Bibliotheken liefern über 1500 Icons mit konsistentem Raster, konsistenter Strichstärke und Benennung. Für die meisten Produkte ist es schneller und besser, von einer davon auszugehen und anzupassen, als bei null anzufangen. Eigene Icons werden nur für produktspezifische Konzepte gezeichnet, die die offenen Bibliotheken nicht abdecken.
Das WCAG-Glossar behandelt die Accessibility-Grundlagen für Icon-Kontrast und Beschriftung. Icons in interaktiven Elementen brauchen zugängliche Namen, nicht nur visuelle Labels.
FAQ
Welche Rastergröße sollte ein Icon-System nutzen?
24-Pixel-Raster für allgemeine Produkt-UI, 20-Pixel-Raster für dichte Daten-Interfaces. Das Raster hat an jeder Seite 2 Pixel Abstand, sodass eine Live-Area von 20 oder 16 Pixeln bleibt, in der das Icon tatsächlich sitzt. Wähle eines und bleib damit in der gesamten Bibliothek.
Wie dick sollten Icon-Striche sein?
1,5 bis 2 Pixel an einem 24-Pixel-Raster. 1,5 Pixel wirken leicht und technisch, 2 Pixel selbstbewusst und freundlich. Wähle eine Stärke, dokumentiere sie als Token und lehne jeden Beitrag ab, der eine andere nutzt.
Was ist optische Korrektur im Icon-Design?
Die Praxis, Icons so anzupassen, dass sie ausbalanciert aussehen, auch wenn die Mathe sagt, sie seien ausgerichtet. Kreise wirken größer als Quadrate, Dreiecke kleiner, Diagonalen dünner als Horizontalen. Optische Korrektur gleicht diese Wahrnehmungsmacken aus. Vertraue dem Auge immer mehr als der Bounding Box.
Sollten Icons gefüllt oder Outline sein?
Die meisten modernen Systeme liefern beides. Outline für inaktive Zustände, gefüllt für aktive. Die beiden Varianten müssen visuell ausbalanciert sein, was meist bedeutet, dass die gefüllte Version 1 bis 2 Pixel kleiner ist als die Outline, damit das wahrgenommene Gewicht passt.
Wie sollten Icons in einem Design System benannt werden?
Objektzuerst, Kebab-Case, bei Bedarf mit Richtungssuffixen. Search, nicht find. Arrow-left, nicht back. Nutze Synonym-Maps, damit Designer mit alternativen Wörtern suchen können. Hänge Variantensuffixe (filled, duotone) an, damit Engineers die richtige Variante mit einem Import greifen können.
Wann baut man eigene Icons und wann nutzt man eine offene Bibliothek?
Nutze eine offene Bibliothek (Lucide, Phosphor, Heroicons) als Basis. Zeichne nur die produktspezifischen Konzepte selbst, die diese Bibliotheken nicht abdecken. Ein Set mit 300 Icons 2026 von null zu bauen, ist fast immer verschwendete Mühe. Passe die offene Basis an, dokumentiere die Ergänzungen, liefere aus.
Das System zahlt sich aus
Eine stimmige Icon-Bibliothek ist der günstigste Weg, ein Produkt poliert wirken zu lassen. Eine driftende Icon-Bibliothek ist der schnellste Weg, es billig wirken zu lassen. Der Aufwand für den Aufbau des Systems sind ein bis zwei Wochen diszipliniere Arbeit. Der Preis für den Verzicht ist eine dauerhafte visuelle Steuer auf jedem Screen, den das Produkt ausliefert, für immer.
Wähle ein Raster. Wähle eine Strichstärke. Wähle einen Eckenradius. Wähle ein Benennungsmuster. Schreibe den Beitrags- und den Deprecation-Prozess auf. Optimiere die SVGs. Packe sie in eine typisierte Komponente. Und setze dann all das im Code Review durch.
Die Icon-Spalte auf jedem Screen ist eines der dichtesten Signale für Produktqualität. Mach sie einmal richtig, und sie trägt den Rest des Designs.
Wenn du ein Team willst, das Icon-Systeme als Teil der übergreifenden Design-System-Übergabe baut, beauftrage Brainy. Raster, Governance und Code in einem Projekt, nie am Ende drangeflanscht.
Weiterführende Lektüre
- Design-Systems-Leitfaden
- Visual-Hierarchy-Design
- Design-Handoff von Figma zu Dev
- Checkliste für Web-Accessibility
Want an icon library that holds up across 200 screens and four designers? Brainy ships icon systems built into the design system, with grid, governance, and code in one handoff.
Get Started
