Wenn Produktwachstum dein Interface unübersichtlicher macht

Funktionsumfang ist nicht gleich Nutzbarkeit

Ein umfangreiches B2B-SaaS-Produkt kann objektiv wertvoll sein. Es kann komplexe Prozesse abbilden und dabei sowohl mehrere Nutzerrollen als auch fachliche Sonderfälle unterstützen. Gerade im B2B-Kontext ist diese Tiefe oft notwendig.

Ein Produkt für Vertragsmanagement oder Finanzcontrolling muss mehr leisten als eine einfache Anwendung mit wenigen Standardabläufen. Es muss Freigaben ermöglichen, ohne Berechtigungen aus dem Blick zu verlieren, es muss Daten nachvollziehbar halten und sich häufig auch mit bestehenden Systemen verbinden.

Funktionsumfang ist deshalb nicht automatisch ein UX-Problem. Schwierig wird es erst dort, wo der Umfang nicht mehr klar geführt wird.
Stell dir ein fiktives B2B-SaaS-Produkt für Projektcontrolling vor. Am Anfang deckt es mit Projekten und Budgets nur wenige Hauptbereiche ab. Nach mehreren Jahren kommen Ressourcenplanung, Rechnungsfreigaben, Risikoanalysen, Forecasts, Kundenportale, Rollenrechte, Integrationen und Audit-Logs hinzu.

Jede Funktion hat einen nachvollziehbaren Grund. Mal brauchte sie ein Kunde in seinem Prozess, mal machte eine Ausschreibung sie relevant, mal meldete der Support wiederkehrende Probleme oder das Produktteam wollte manuelle Arbeit reduzieren. Das Produkt kann nun deutlich mehr.

Für neue Nutzer entsteht eine andere Erfahrung

Sie sehen eine Navigation mit vielen Bereichen, in der ähnliche Begriffe nebeneinanderstehen und oft mehrere Einstiegspunkte zur selben Aufgabe führen. Sie fragen sich, ob ein Forecast unter Berichte oder in einem Management-Bereich liegt. Was sie eigentlich suchen, ist eine Ordnung, die zu ihrem Denken passt.

Nutzbarkeit entsteht nicht allein dadurch, dass eine Funktion existiert. Sie entsteht, wenn Menschen verstehen, wann diese Funktion relevant ist, wie sie sie finden und was sie dort erwartet.

Wenn Icons zur eigenen Sprache werden

Iconlastige Navigationen wirken auf den ersten Blick sauber. Weniger Text macht die Seitenleiste kompakter und schafft Platz. Die Oberfläche scheint ruhiger zu sein, weil Begriffe verschwinden. In gewachsenen Produkten entsteht daraus oft das Problem, dass die Navigation eine eigene Zeichensprache entwickelt.
Ein Diagramm-Icon kann Bericht meinen, Analyse oder ein ganzes Dashboard. Ein Zahnrad steht für Einstellungen oder Admin-Rechte. Ein Blitz kann Automatisierung bedeuten, ebenso gut aber eine Warnung oder eine Schnellaktion. Ein abstraktes Symbol steht womöglich für ein Modul, das außerhalb des Produkts niemand mit diesem Zeichen verbinden würde.

Für das Team ist die Bedeutung klar, weil sie intern gelernt wurde. Für Nutzer ist sie oft nur scheinbar klar.

Ein Label erspart das Raten

Die Nielsen Norman Group empfiehlt im Artikel „Icon Usability“ sichtbare Textlabels bei Icons, besonders in der Navigation. Labels sollten nicht erst beim Hover erscheinen, weil dieser zusätzliche Schritt den Interaktionsaufwand erhöht und auf Touch-Geräten nicht zuverlässig funktioniert.

Das ist für B2B-SaaS besonders relevant. Viele Produktbereiche haben keine allgemein bekannte Bildsprache. Startseite, Suche, Download oder Drucken können mit etablierten Symbolen funktionieren. Für Freigaben, Datenimporte, Rollenmatrizen oder Compliance-Workflows gibt es keine universelle visuelle Konvention.

Dieselbe Quelle trennt außerdem Erkennbarkeit von Interpretation. Ein Icon kann im Entwurf sauber aussehen und im Design-Review Zustimmung bekommen. Im Nutzungskontext scheitert es trotzdem, wenn die Form zwar erkennbar ist, die Bedeutung aber geraten werden muss.

Jede Prüfung ist Arbeit vor der Arbeit

Versteckte Labels verstärken die Reibung. Nutzer fahren mit dem Cursor über ein Icon, warten auf die Erklärung, lesen den Begriff, vergleichen ihn mit ihrer Aufgabe und entscheiden erst dann, ob der Bereich passen könnte. Das ist eine kleine Handlung, aber eine vor der eigentlichen Handlung.

Wenn sich dieser Vorgang mehrfach wiederholt, wird die Navigation zu einer Abfolge von Prüfungen. Die Oberfläche erklärt sich nicht, sie muss abgefragt werden. Auf Touch-Geräten fällt Hover als verlässliches Muster ohnehin weg. Dadurch wird eine Navigation, die am Desktop gerade noch funktioniert, auf anderen Geräten weniger zugänglich.

Zentrale Navigationselemente sollten keine Rätsel sein. Dass ein Produkt fachlich erklärungsbedürftig ist, gehört zur Realität vieler B2B-Anwendungen. Wenn schon der Weg zur Funktion erklärt werden muss, kostet das die Nutzer wertvolle Zeit, bevor die eigentliche Arbeit beginnt.

Wiedererkennen ist leichter als Erinnern

Viele gewachsene Produkte verlassen sich auf Erinnerung. Nutzer sollen sich merken, welches Icon zu welcher Aufgabe gehört und an welcher Position der zugehörige Bereich liegt. Welches Symbol für Vorlagen oder Automatisierung steht, wissen dann nur die Nutzer, die es einmal gelernt haben.

Für geübte Nutzer kann das funktionieren. Nach einigen Wochen entsteht Routine, Positionen prägen sich ein und die Klicks werden schneller, bis die Bedeutung gar nicht mehr bewusst entschlüsselt werden muss. Das heißt aber nicht, dass die Navigation verständlich ist, denn sie ist nur gelernt.

Das Prinzip „Recognition rather than Recall“ aus den 10 Usability-Heuristiken für User Interface Design beschreibt genau das. Nutzer sollen Elemente und Optionen erkennen können, statt sie aus dem Gedächtnis abzurufen. Sichtbare Informationen senken die kognitive Belastung. Wiedererkennen bedeutet, dass die Oberfläche Hinweise liefert. Ein Bereich mit der Bezeichnung Rechnungen gibt Orientierung und ein Menüpunkt Genehmigungen weckt eine konkrete Erwartung. Selbst ein breiter Bereich wie Einstellungen bleibt verständlich, weil das Konzept bekannt ist.

Erinnern funktioniert anders. Der Nutzer muss eine gelernte Verbindung abrufen und wissen, dass etwa ein abstraktes Symbol oder ein interner Begriff zu seiner Aufgabe gehört.

Nicht jeder nutzt jeden Bereich täglich

In B2B-SaaS wird dieser Unterschied besonders spürbar, weil viele Nutzer nicht jeden Bereich täglich verwenden:

• Sachbearbeitung arbeitet täglich mit Datensätzen
• Controlling prüft nur monatlich Berichte
• Admins ändern Berechtigungen nur bei neuen Mitarbeitenden oder organisatorischen Änderungen
• Führungskräfte öffnen bestimmte Auswertungen vor Review-Terminen

Seltene Aufgaben sind anfällig für Erinnerungsreibung. Was nicht regelmäßig genutzt wird, bleibt weniger fest im Gedächtnis, und eine Navigation, die stark auf gelernte Zuordnung setzt, belastet genau diese Situationen. Power-User kompensieren viel durch Gewohnheit. Gelegentliche Nutzer erleben dieselbe Struktur anders. Für sie wirkt dasselbe Produkt eher erklärungsbedürftig als vertraut.

Eine gute Navigation hält beide Perspektiven aus. Sie bremst geübte Nutzer nicht und zwingt gelegentliche Nutzer nicht, interne Bedeutungen auswendig zu lernen.

Wie Funktionswachstum die Struktur schwächt

Strukturelle Unübersichtlichkeit entsteht selten aus einer einzelnen schlechten Entscheidung. Häufig entsteht sie aus einer Reihe nachvollziehbarer Ergänzungen.

Dabei kommen die neuen Funktionen aus ganz unterschiedlichen Quellen:

• Kundenwünsche und Sales-Anforderungen
• interne Roadmap-Entscheidungen
• regulatorische Vorgaben
• Erkenntnisse aus dem Support
• Enterprise-Deals mit speziellen Prozessen

Diese Herkunft macht eine Funktion nicht falsch. Sie erklärt aber, warum sie nicht automatisch einen guten Platz in der Informationsarchitektur bekommt.

Ein Kunde braucht einen Export, ein anderer eine Sonderrolle. Customer Success meldet, dass Nutzer einen Bericht manuell zusammenbauen, also ergänzt das Produktteam eine Abkürzung. Später kommt eine Integration dazu, die bald eigene Einstellungen verlangt, und schließlich sollen bestimmte Rollen nur einzelne Teile davon sehen. So wächst nicht nur der Funktionsumfang, auch die Navigationslogik wird dichter.

Wenn eine Funktion in mehrere Bereiche passt

Besonders schwierig wird es, wenn Funktionen mehreren Bereichen zugeordnet werden könnten. Gehört ein Report in Analyse oder zum jeweiligen Objekt? Gehört eine Freigabe in Aufgaben oder in den Workflow? Gehört Rollenverwaltung in Organisation oder Sicherheit? Solche Entscheidungen sind selten eindeutig. Genau deshalb sammeln Produkte mit der Zeit strukturelle Kompromisse.

Navigationen wachsen historisch, wenn neue Funktionen nach und nach ergänzt werden, ohne die Informationsarchitektur regelmäßig zu prüfen. Das ist verständlich, denn eine grundlegende Umstrukturierung kostet Zeit, sie irritiert bestehende Nutzer und verlangt Abstimmung über Bereiche hinweg.

Dazu kommt die Reibung, wenn ähnliche Dinge unterschiedlich benannt sind oder funktionieren. Ein Filter heißt einmal Ansicht, einmal Segment. Die Heuristik „Consistency and Standards“ beschreibt, warum solche Abweichungen die Lernbarkeit senken. Folgen ähnliche Elemente denselben Konventionen, wissen Nutzer eher, was sie erwarten können.

Sichtbarkeit folgt auch der Organisation

Auch interne Zuständigkeiten beeinflussen, welche Bereiche sichtbar bleiben. Teams und Geschäftsbereiche haben ein Interesse daran, im Produkt erkennbar zu sein. Sichtbarkeit im Interface wird dann nicht nur aus Nutzersicht entschieden, sondern auch aus organisatorischer Perspektive.

Nutzer sehen diese Entstehungsgeschichte nicht, sie erleben nur das Ergebnis. Eine Navigation kann abbilden, wie das Produkt gewachsen ist. Wie Nutzer tatsächlich arbeiten, bildet sie aber nicht unbedingt ab.

Einfachheit und Auswahl

Das Spannungsfeld zwischen Einfachheit und Auswahl ist im B2B-SaaS besonders anspruchsvoll. Zu wenig Auswahl blendet wichtige Arbeitsrealitäten aus, zu viel sichtbare Auswahl verlangsamt Entscheidungen.

Der Artikel „Simplicity Wins over Abundance of Choice“ zeigt, dass Funktionen mit geringem Wert für die meisten Nutzer die Informationsverarbeitung erschweren. Eine angemessene Zahl an Optionen hilft, Entscheidungen leichter zu treffen und Aufgaben schneller abzuschließen. Das richtet sich nicht gegen komplexe Produkte. Gemeint ist eine Struktur, in der viele Optionen dauerhaft um dieselbe Aufmerksamkeit konkurrieren.

Einfachheit bedeutet hier nicht, Funktionen zu streichen, damit die Oberfläche leerer aussieht. Einfachheit bedeutet, Relevanz sichtbar zu machen. Die Heuristik „Aesthetic and Minimalist Design“ zielt auf denselben Kern. Jedes selten benötigte Element konkurriert mit dem, was im Moment gebraucht wird.

Eine Funktion kann wertvoll sein und trotzdem nicht dauerhaft in der Hauptnavigation stehen müssen. Ein Admin-Bereich kann notwendig sein und trotzdem für operative Nutzer nachrangig platziert werden. Mehr Auswahl schafft Wert, wenn Nutzer sie einordnen können. Sie erzeugt Reibung, wenn sie zu früh erscheint oder ohne klare Gewichtung sichtbar ist.

Woran Teams strukturelle Unübersichtlichkeit erkennen

Strukturelle Probleme zeigen sich oft außerhalb klassischer Design-Reviews. Sie erscheinen in Support-Tickets, Onboarding-Gesprächen, Schulungsunterlagen und in der täglichen Arbeit von Customer Success.

Ein deutliches Signal sind Supportfragen, die sich um den Ort einer Funktion drehen. Nutzer fragen dann weniger nach der fachlichen Logik als danach, wo sie etwas finden. Auch lange Onboarding-Zeiten weisen auf strukturelle Reibung hin. Wenn Schulungen viel Zeit darauf verwenden, die Navigation zu erklären, trägt die Oberfläche diese Aufgabe nicht ausreichend selbst.

Customer-Success-Teams bemerken solche Muster früh. Sie erklären wiederholt dieselben Wege und korrigieren Missverständnisse, die weniger mit Fachlichkeit zu tun haben als mit Benennung und Struktur. Auch die Suchfunktion ist ein Hinweis. Problematisch wird es, wenn Nutzer suchen, weil sie der Navigation nicht vertrauen. Admins entwickeln eigene Hilfen, speichern Klickpfade in internen Wikis und schreiben Anleitungen für neue Kolleginnen. Solche Workarounds zeigen, dass Orientierung aus dem Produkt herauswandert.

Ein weiteres Signal sind Funktionen, die vorhanden sind und trotzdem wiederholt angefragt werden. Das Problem liegt dann nicht im Funktionsumfang, sondern in Sichtbarkeit, Benennung oder Platzierung. Diese Signale sind keine Beweise, sondern Hinweise. Treten mehrere zusammen auf, lohnt ein strukturierter Blick auf die Informationsarchitektur, oft von jemandem, der nicht täglich im Produkt arbeitet und die gelernte Ordnung deshalb nicht teilt.

Strukturelle Reibung ist nicht kosmetisch. Sie schlägt als Support-Last, längere Einarbeitung und höheres Abwanderungsrisiko auf die Kosten durch.

Was bessere Struktur bedeuten kann

Bessere Struktur heißt nicht, ein komplexes Produkt künstlich klein zu machen. Sie beginnt mit Priorisierung. Welche Bereiche sind häufig relevant, welche Funktionen werden selten gebraucht, und welche gehören eher in Detailansichten, kontextuelle Aktionen oder fortgeschrittene Einstellungen?

Gruppierung ist ein weiterer Hebel. Funktionen müssen in Nachbarschaften liegen, die Nutzer nachvollziehen können. Dabei sollte die Aufgabenlogik der Nutzer den Ausschlag geben, nicht die interne Teamstruktur.

Klare Labels sind oft wirkungsvoller als zusätzliche Symbole. Ein gutes Label reduziert Interpretation und sagt, was gemeint ist. In der Hauptnavigation ist sichtbare Bedeutung wichtiger als visuelle Kompaktheit.

Progressive Offenlegung zeigt seltene Optionen erst im richtigen Moment, sodass sie verfügbar bleiben, ohne dauerhaft Aufmerksamkeit zu beanspruchen. Rollenbasierte Einstiege helfen dort, wo Nutzergruppen stark unterschiedliche Ziele haben. Konsistente Muster senken den Lernaufwand, weil Nutzer weniger lokale Regeln lernen müssen.

Bessere Informationsarchitektur ist keine kosmetische Arbeit. Sie entscheidet, ob Funktionsumfang als Wert erlebbar wird oder als Belastung.

Fragen, die Produktteams stellen sollten

Diese Fragen helfen, eine gewachsene Struktur zu prüfen, bevor neue Icons oder kompaktere Menüs als Lösung erscheinen:

• Welche Funktionen sind häufig sichtbar, obwohl sie für viele Nutzer selten relevant sind?
• Welche Icons brauchen Erklärung, bevor Nutzer sie sicher verstehen?
• Welche Bereiche verstehen neue Nutzer erst nach einer Schulung?
• Welche Begriffe stammen aus der Organisation und nicht aus der Sprache der Nutzer?
• Welche Funktion wäre im Kontext besser erreichbar als in der Hauptnavigation?
• Welche Rollen sehen dauerhaft Optionen, die sie kaum brauchen?
• Welche Navigationsentscheidung ist historisch entstanden und wurde nie bewusst geprüft?

Diese Fragen sind unbequem, weil sie nicht nur das Design betreffen. Sie berühren Produktstrategie, interne Zuständigkeiten und technische Historie. Genau deshalb sind sie nützlich. Produktteams müssen entscheiden, was für wen sichtbar sein soll, und akzeptieren, dass Sichtbarkeit Kosten hat.

Fazit

Funktionsumfang ist in B2B-SaaS oft notwendig, weil die Arbeitsrealität komplex ist. Die entscheidende Frage ist, wie diese Komplexität organisiert wird.

Reibung entsteht, wenn jede neue Funktion die bestehende Struktur belastet, während die Struktur selbst unverändert bleibt. Dann wächst mit dem Produkt auch der Orientierungsaufwand.

Produktreife zeigt sich nicht allein im Funktionsumfang. Ein reifes Produkt erkennt man daran, wie wenig Orientierung es seinen Nutzern abverlangt.