Warum Icons einzeln nie auffallen und zusammen immer — und wie du mit Inventur, Raster, Varianten und klaren Beschriftungen ein Set baust, das in Web und App auch nach Jahren noch zusammenhält
In der Kita-Software, an der ich über Jahre mitgearbeitet habe, gab es irgendwann drei Mülleimer. Nicht im Büro — im Interface. Einer kam aus der Icon-Bibliothek, die von Anfang an dabei war, einer aus einem Bootstrap-Rest in einer älteren Teilansicht, einer war von Hand nachgezeichnet, weil der erste bei 16 Pixeln zu einem grauen Fleck zerfiel. Alle drei bedeuteten „löschen". Keiner sah aus wie die anderen beiden. Und in der Dokumentationsansicht standen zwei davon auf demselben Bildschirm, zwei Zeilen auseinander.
Beschwert hat sich niemand. Das ist das Tückische an Icons: Einzeln fallen sie nie auf, zusammen immer. Ein Set, das über Jahre aus drei Quellen zusammengetragen wurde, macht ein Produkt nicht unbenutzbar — es macht es unruhig, ein bisschen billig und an den Rändern unklar. Vor allem kostet es dich bei jedem neuen Screen eine Entscheidung, die längst getroffen sein sollte.
Ein Icon-System ist deshalb kein Ordner mit SVG-Dateien. Es ist eine Liste von Bedeutungen, eine Handvoll geometrischer Regeln und die Verabredung, wer ein neues Symbol hinzufügen darf. In dieser Reihenfolge. Dieser Artikel geht genau diesen Weg: von der Inventur über Raster, Strichstärke und Varianten bis zur Frage, wann du ein fremdes Set nimmst und wie du es davor bewahrst, wieder zu zerfallen.
Ein Icon ist kein Bild, sondern ein Zeichen. Es muss in weniger als einer Sekunde, bei 20 Pixeln Kantenlänge, aus dem Augenwinkel und in einer Reihe mit zwölf anderen Zeichen erkannt werden. Das ist eine härtere Anforderung als „gut aussehen".
Vor allem aber: Erkennen ist gelernt, nicht angeboren. Die Diskette für „speichern" versteht eine ganze Generation, die nie eine in der Hand hatte — weil sie die Form gelernt hat, nicht das Objekt. Umgekehrt ist das Hamburger-Menü nach fünfzehn Jahren Dauereinsatz immer noch nicht selbsterklärend, sondern nur sehr verbreitet. Wirklich universell sind eine Handvoll Zeichen: das Kreuz zum Schließen, die Lupe für die Suche, der Pfeil zurück, das Plus zum Hinzufügen, das Dreieck zum Abspielen. Alles andere ist Konvention — entweder die deiner Branche oder die deines Produkts.
Daraus folgt der unbequeme Teil: Die schwierige Arbeit an Icons ist nicht das Zeichnen. Es ist die Entscheidung, was überhaupt ein Icon bekommt.
In einem Bildungsportal habe ich einmal eine Liste gesehen, in der jede Zeile ein Symbol trug: Dokument, Video, Audio, Verknüpfung, Ordner, Test. Gut gemeint, aber das Ergebnis war eine gesprenkelte Fläche, auf der nichts mehr hervorstach — und die beiden Icons, die wirklich wichtig waren, nämlich „noch nicht freigegeben" und „in Bearbeitung", gingen im Muster unter. Icons funktionieren über Kontrast zur Umgebung. Wenn alles ein Icon hat, hat nichts eines.
Faustregel: Ein Icon rechtfertigt sich, wenn es eine Handlung schneller auffindbar macht, einen Zustand auf einen Blick zeigt oder eine Zeile scanbar hält. Alles, was nur „den Text auflockern" soll, ist Dekoration — und Dekoration in einer Liste ist Lärm.
Bevor du ein einziges Symbol anfasst, schreibst du auf, was dein Produkt überhaupt sagen will. Nicht welche Icons du hast — welche Bedeutungen du brauchst. Das ist eine langweilige Tabelle mit drei Spalten und das wertvollste Artefakt des ganzen Vorhabens.
Beim Ausfüllen fallen zwei Dinge auf, und beide sind Gold wert. Erstens Dubletten: drei Mülleimer für eine Bedeutung. Zweitens Überladungen: ein Stift, der an einer Stelle „bearbeiten" heißt, an einer anderen „kommentieren" und im Editor „Zeichenwerkzeug". Beides repariert du nicht mit Zeichnen, sondern mit Entscheiden.
Die Regel dahinter ist einfach und unverhandelbar: eine Bedeutung, ein Zeichen — und ein Zeichen, eine Bedeutung. Synonyme verwirren weniger als Homonyme, aber beide kosten. Wenn du in der Tabelle zwei Bedeutungen findest, die sich dasselbe Icon teilen, braucht eine von beiden ein anderes Zeichen oder gar keines, sondern ein Wort.
Ob ein Zeichen verstanden wird, kannst du nicht am Schreibtisch entscheiden — du hast es gezeichnet, also siehst du die Bedeutung darin. Der Test dafür kostet eine halbe Stunde und braucht niemanden aus der Zielgruppe im Labor.
Zeig fünf Leuten, die das Produkt nicht gebaut haben, das Icon ohne Kontext und frag nicht „verstehst du das?", sondern „was würde passieren, wenn du hier klickst?". Offene Frage, freie Antwort, nichts vorgeben. Verstehen vier von fünf dasselbe, ist das Zeichen tragfähig. Kommen fünf verschiedene Antworten, hast du keine Zeichenaufgabe, sondern eine Benennungsaufgabe: Das Symbol braucht ein Wort neben sich.
Wichtig ist die Richtung des Tests. Die Frage „Welches dieser vier Icons bedeutet archivieren?" bestätigt dir fast jedes Zeichen, weil die Auswahl die Antwort mitliefert. Erst die freie Frage zeigt dir, was jemand von sich aus hineinliest — und das ist genau das, was in deinem Interface passiert.
Tipp: Mach die Inventur nicht in Figma, sondern in einer Tabelle. In Figma beginnst du nach zehn Minuten zu zeichnen. In einer Tabelle bleibst du bei der Frage, die du eigentlich klären wolltest.
Erst jetzt wird gestaltet — und zwar nicht Icon für Icon, sondern als System. Dass ein Set „wie aus einem Guss" wirkt, ist fast vollständig eine Frage von vier Festlegungen.
Diese vier Regeln erledigen die Arbeit, für die man sonst Talent braucht. Ein Set aus dreißig Icons, die alle dasselbe Rasterfeld, dieselbe Strichstärke und denselben Eckradius haben, sieht einheitlich aus, selbst wenn die einzelnen Zeichnungen unterschiedlich gut sind.
Zwei Fallen lauern danach noch. Die erste ist das optische Gewicht: Ein ausgefülltes Dreieck wirkt schwerer als ein gleich großer Ring. Wenn beide in einer Reihe stehen, musst du am Dreieck Fläche wegnehmen, nicht an seiner Bounding-Box messen. Die zweite ist die optische Größe: Ein 24-Pixel-Icon, das du auf 16 Pixel herunterskalierst, verliert nicht nur Schärfe, es verliert Lesbarkeit. Linien, die bei 24 Pixeln drei Pixel auseinanderliegen, verschmelzen bei 16. Sets, die beide Größen brauchen, bekommen eine eigene Zeichnung für die kleine Stufe — mit weniger Details und dafür demselben Umriss.
Dazu kommen zwei Festlegungen, die unscheinbar aussehen und am stärksten darüber entscheiden, ob ein Set zusammengehörig wirkt: Eckradius und Linienenden. Entweder sind alle Außenecken leicht gerundet oder alle spitz; entweder enden alle offenen Linien rund oder alle gerade abgeschnitten. Mischt du das, kannst du geometrisch alles richtig gemacht haben und das Set sieht trotzdem zusammengekauft aus. Es ist derselbe Mechanismus, über den auch Farbrollen oder Abstandsstufen wirken: Nicht der einzelne Wert überzeugt, sondern seine Wiederholung.
Und ein technisches Detail, das viel Frust erspart: Zeichne auf ganze Pixel. Eine 1,5 Pixel starke Linie, deren Mitte auf einem halben Pixel liegt, wird vom Browser auf zwei Pixel verteilt und sieht in genau einer Zoomstufe matschig aus — meistens in der, in der dein Kunde zum ersten Mal hinschaut.
Und noch ein Detail, das in fast jedem Projekt schiefgeht: Icons neben Text richten sich nicht an der Schriftgröße aus, sondern an der Versalhöhe. Ein 24-Pixel-Icon neben 16-Pixel-Text ist fast immer zu groß, weil die Großbuchstaben nur rund elf Pixel hoch sind. Wer sich schon einmal mit der Beziehung von Schriftgrößen, Zeilenhöhen und optischer Mitte beschäftigt hat, kennt die Rechnung: Das Icon soll ungefähr so hoch wirken wie ein Großbuchstabe, nicht wie die Zeile.
Fast jedes moderne Set kommt in zwei Schnitten — als Konturzeichnung und als gefüllte Fläche. Der Fehler ist, zwischen beiden nach Gefühl zu wählen. Die Variante ist eine Information, und zwar eine der zuverlässigsten, die du hast.
Die gängige Verabredung: Kontur ist der Normalzustand, Fläche ist der ausgewählte. In der Tab-Bar einer App ist der aktive Reiter gefüllt, die drei anderen sind Konturen. In einer Seitennavigation gilt dasselbe. Das funktioniert, weil der Unterschied im Flächenanteil liegt und damit auch bei kleiner Größe und schlechtem Kontrast noch wahrnehmbar ist — anders als eine Umfärbung, die du ohnehin nie als einziges Unterscheidungsmerkmal einsetzen solltest.
Wichtig ist nur: Die Paare müssen aus derselben Zeichnung stammen. Ein Konturhaus mit Satteldach und ein gefülltes Haus mit Flachdach sind nicht zwei Zustände, sondern zwei Häuser, und Nutzer:innen merken das, ohne es benennen zu können.
Beispiel: In einer Publishing-Oberfläche hatten wir Lesezeichen als Kontur und „gemerkt" als gefüllte Variante — bis jemand für die Favoritenliste ein zweites, gefülltes Icon aus einer anderen Quelle nahm, weil es „etwas runder" aussah. Danach gab es zwei gefüllte Lesezeichen mit unterschiedlichem Umriss, und keiner der beiden bedeutete mehr zuverlässig „ausgewählt".
Was du nicht tun solltest: Fläche als Betonung einsetzen. Wenn das gefüllte Icon manchmal „aktiv" heißt und manchmal „besonders wichtig", ist die Unterscheidung verbraucht.
Die häufigste Icon-Entscheidung ist gar keine Zeichenfrage: Steht das Symbol allein oder mit Wort?
Icon plus Wort ist keine Redundanz, sondern ein zweiter Kanal: Das Symbol liefert die Wiedererkennung beim Scannen, das Wort die Eindeutigkeit beim Zweifel. In Tests mit kleinen Teams ist das der Unterschied zwischen „ich habe es gefunden" und „ich habe geraten und dann abgebrochen". Und weil das Wort die Bedeutung trägt, gelten dafür dieselben Maßstäbe wie für jede andere Formulierung im Interface: Verb statt Substantiv, Nutzersprache statt Systemsprache, ein Begriff pro Bedeutung.
Ein praktischer Nebeneffekt der Beschriftung: Sie zwingt dich zur Klarheit. Ein Icon kann ungefähr „irgendwas mit Verwalten" bedeuten und so lange unauffällig bleiben. Sobald ein Wort darunter steht, musst du dich entscheiden, welches.
Icons sind die Stelle, an der sich Barrierefreiheit am schnellsten entscheidet — und am schnellsten verloren geht. Vier Punkte decken das Meiste ab, und sie kosten in der Umsetzung fast nichts.
aria-hidden="true"), sonst hört man „Mülleimer löschen". Ein Icon, das allein in einem Button steht, trägt die Bedeutung und braucht einen Namen (aria-label="Löschen").Dazu kommt der Punkt, der in Audits am häufigsten auftaucht: Ein Zustand darf nie allein über Form oder Farbe eines Icons laufen. Das rote Dreieck in der Zeile ist ein guter Hinweis — es ersetzt aber nicht den Text, der sagt, was fehlt. Wie das zusammenhängt und was das BFSG seit 2025 für Produkte verbindlich macht, gehört ohnehin in die Grundausstattung.
Ein letzter Punkt, der selten in Checklisten steht, aber bei jedem Tastaturdurchlauf auffällt: Icon-Buttons in Tabellenzeilen oder Listen brauchen einen sichtbaren Fokusring, und der muss auch dann sichtbar bleiben, wenn der Button bis zum Hover halbtransparent ist. Eine Aktion, die erst beim Überfahren mit der Maus erscheint, existiert für die Tastatur nicht — und für den Touchscreen auch nicht.
Tipp: Der schnellste Test braucht keine Software. Geh mit der Tabulatortaste durch eine Ansicht und lies laut vor, was ein Screenreader hier ansagen würde. Jedes „Grafik", jedes „Button" ohne Zusatz und jedes doppelte Wort ist ein Fundstück.
Für die meisten Projekte lautet die Antwort: nimm ein fremdes Set. Lucide, Phosphor, Material Symbols, Heroicons — alle sind sauber auf Raster gezeichnet, konsistent in der Strichstärke, in mehreren Schnitten verfügbar und umfassen mehr Zeichen, als du je brauchst. Ein eigenes Set zu zeichnen kostet Wochen und bringt bei Standardhandlungen wie „Suchen" oder „Teilen" exakt nichts.
Der realistische Weg ist der gemischte: Eine Bibliothek ist die Grundlage, und für die zehn bis zwanzig Zeichen, die deine Domäne ausmachen, zeichnest du selbst — im Raster und in der Strichstärke der Bibliothek. In der Kita-Software waren das Dinge wie Beobachtung, Entwicklungsbereich und Portfolio; dafür gibt es in keinem Set der Welt ein passendes Symbol.
Technisch sind die Entscheidungen überschaubar, aber folgenreich:
currentColor statt fester Füllfarbe. Dann erbt das Icon die Textfarbe seines Kontexts und funktioniert in Dark Mode, auf farbigen Flächen und im Hover-Zustand ohne Sonderfall.icon-delete, nicht icon-trash. Wenn ihr das Zeichen später tauscht, bleibt der Name richtig — und niemand benutzt den Mülleimer versehentlich für „Abfallkalender".Ein vollständig eigenes Set lohnt sich praktisch nur in zwei Fällen: wenn die Marke stark über Formensprache funktioniert und das Interface ihr Hauptschauplatz ist, oder wenn deine Domäne so speziell ist, dass die Hälfte der Zeichen ohnehin selbst entstehen müsste. Beides kommt vor. Beides solltest du bewusst entscheiden und nicht entdecken, nachdem schon dreißig Icons gezeichnet sind.
Noch eine Überlegung zur Auslieferung: Ein paar Dutzend Icons als Komponenten inline einzubetten, ist völlig in Ordnung. Wenn es Hunderte werden oder lange Listen dasselbe Zeichen hundertfach wiederholen, wird daraus messbar Gewicht im HTML — dann ist ein Sprite mit <use>-Referenzen der ruhigere Weg, weil das Markup pro Vorkommen auf eine Zeile schrumpft.
Und dann der Teil, der kein Werkzeug löst: die Pflege. Ein Icon-Set zerfällt nicht durch schlechte Zeichnungen, sondern durch Eile — jemand braucht ein Symbol, findet keines, lädt eines herunter, es sieht fast passend aus, fertig. Dagegen hilft nur eine einzige Quelle, eine Person, die sie pflegt, und eine Frage im Review: Gibt es für diese Bedeutung schon ein Zeichen? Diese Frage verhindert mehr Dubletten als jede Richtlinie. Sie ist Teil derselben Pflegearbeit, die auch ein Design System im kleinen Team überhaupt am Leben hält — und sie ist dort genauso wenig beliebt und genauso notwendig.
Beispiel: Wir haben irgendwann die Inventur-Tabelle aus Schritt 2 zur Pflegetabelle gemacht: eine Spalte Bedeutung, eine Spalte Dateiname, eine Spalte „wird verwendet in". Wer ein neues Icon wollte, musste eine Zeile ergänzen. Das klingt nach Bürokratie, dauert zwanzig Sekunden und hat die drei Mülleimer auf einen reduziert.
Icons sind eine der wenigen Stellen im Interface, an denen sich Sorgfalt sofort sehen lässt — und Schlamperei auch. Die gute Nachricht: Der Aufwand liegt fast vollständig am Anfang und in der Pflege, nicht im Zeichnen.
Wenn du nur eine Sache mitnimmst: Die Inventur-Tabelle ist das Icon-System. Die SVG-Dateien sind nur ihr Ergebnis.
Transparenzhinweis: Die Bilder in diesem Artikel wurden mit KI erstellt. Die redaktionelle Verantwortung liegt bei Jannik Noe.
Jannik Noe
Product & UI/UX Designer aus Hamburg. Ich gestalte und baue Websites, Web-Apps und Software — von der Konzeption bis zum Launch — und zeige Teams im Workshop, wie KI in echte Designprozesse passt.
Mehr über mich →Design Systems
Von der Komponenten-Inventur bis zur Übergabe: Ich baue Design Systems, die Teams tatsächlich benutzen — Audit in zwei Wochen, Aufbau in vier bis zwölf.
Warum der Fehlerfall im Product Design fast immer zuletzt gestaltet wird — und wie du Meldung, Ort, Wiederanlauf und Datensicherheit so zusammenbringst, dass Nutzer:innen weiterkommen statt stehenzubleiben
Warum ein gutes Raster unsichtbar bleibt und seine Abwesenheit sofort auffällt — und wie du Spaltensystem, Abstandsskala und Weißraum so aufbaust, dass sie in Web und App auch nach Monaten noch halten
Warum das Modal das am schnellsten gezogene und am häufigsten falsche Muster im Interface ist — und wie du Dialoge so baust, dass sie mit Tastatur, Screenreader und auf dem Handy tragen
Du planst eine Website, eine App, ein Redesign — oder möchtest euer Team mit einem AI-UX Workshop voranbringen?
Ich unterstütze Unternehmen dabei, komplexe Anforderungen in klare, nutzerfreundliche Lösungen zu übersetzen.