Das Settings-Page-Problem

Die Einstellungsseite ist der ehrlichste Screen in deinem Produkt. Sie zeigt in einem einzigen Scroll, welche Entscheidungen das Team verweigert hat. Jeder Toggle ist ein versteinerter Streit. Jeder verschachtelte Tab ist ein „Das klären wir später“, das nie jemand geklärt hat.

Die meisten Einstellungsseiten sind Mülldeponien. Drei Jahre voller Toggles, abgeladen von Engineers, die nicht Nein sagen konnten, Marketern, die ein Opt-out brauchten, und PMs, die „mach es konfigurierbar“ als Ersatz für „entscheide“ benutzt haben. Das Ergebnis ist ein Screen, den das Team ungern demonstriert und den Nutzer nur ungern anfassen.

Das hier ist das Plädoyer dafür, Einstellungen als erstklassige Produktoberfläche zu behandeln. Fünf Archetypen, sechs Regeln, echte Beispiele aus Produkten, die du längst nutzt, und ein Audit, das du vor dem Release durchlaufen lässt.

Settings ist der Screen, der das Team entlarvt

Settings-Wildwuchs ist ein Frühindikator (Leading) für organisatorische Dysfunktion. Wenn ein Team sich nicht auf einen Default einigen kann, wird der Toggle ausgeliefert. Wenn sich ein Kunde beschwert und niemand widersprechen will, wird der Toggle ausgeliefert. Wenn sich der PM nicht zwischen zwei Flows entscheiden kann, werden beide hinter einer Einstellung ausgeliefert.

Sechs Monate später weiß niemand mehr, warum die Hälfte der Toggles existiert. Eine Einstellung zu entfernen erfordert dieselbe Entscheidung, die das Team beim ersten Mal vermieden hat, also sammeln sie sich an. Schau dir ein beliebiges Produkt an, das seit über drei Jahren ausgeliefert wird, und du kannst die ungetroffenen Entscheidungen im Einstellungsbaum zählen.

Die fünf Archetypen schlechter Einstellungsseiten

Schlechte Einstellungsseiten sind nicht zufällig. Sie folgen fünf Mustern, jedes der Endpunkt einer bestimmten Art organisatorischer Faulheit.

1. Die Müllhalde

Chronologische Anhäufung. Einstellungen erscheinen in der Reihenfolge, in der sie hinzugefügt wurden, nie gruppiert. Das neueste Feature-Flag steht neben einer Benachrichtigungseinstellung von 2019, neben einem Beta-Toggle, der eigentlich vor zwei Jahren hätte erwachsen werden sollen. Cursor rutscht gerade dahin ab. Jedes Release fügt dem Tab „General“ drei Toggles hinzu, und der Tab „General“ ist inzwischen ein Scroll aus 40 Zeilen unzusammenhängender Entscheidungen. Die Müllhalde ist der Standardzustand jeder Einstellungsseite, die niemand aktiv gestaltet.

2. Die Tabelle

Alphabetische Präferenzen. Das Team hat die Hierarchie aufgegeben und das Betriebssystem sortieren lassen. Jeder Toggle hat dasselbe Gewicht, jede Zeile sieht gleich aus. Slacks Benachrichtigungseinstellungen wohnen hier. Ton, Badge, Mobile, Channel, Keyword, Bitte nicht stören, Zeitplan, Benutzerdefiniert, alles plattgewalzt zu einer Wand ohne Geschichte darüber, welche davon zählen.

3. Die Sackgasse

Einstellungen, die nichts sichtbar verändern. Der Nutzer aktiviert „Kompaktmodus“ und der Screen sieht identisch aus. Er aktiviert „Erweiterte Funktionen“ und nichts erscheint. Apples Redesign der Systemeinstellungen unter macOS hat eine ganze Generation davon ausgeliefert: Einstellungen, die stillschweigend von anderen Einstellungen überschrieben werden, Einstellungen, die einen Neustart brauchen, den der Screen nie erwähnt. Die Sackgasse lehrt Nutzer, dass Einstellungen nicht funktionieren, und sie verlieren das Vertrauen in den Rest des Produkts.

4. Das Labyrinth

Zehn Ebenen verschachtelter Tabs. Einstellungen vergraben unter einer Kategorie, einer Unterkategorie, einem „Erweitert“-Aufklapper, einem Modal. Der Nutzer weiß, dass der Toggle existiert, hat ihn schon einmal umgelegt und findet ihn trotzdem nicht. Das ältere Jira hat daraus eine Karriere gemacht: Projekt, Board, Workflow, Schema, Berechtigungsschema, Benachrichtigungsschema, alles getrennte Bäume.

5. Das Museum

Einstellungen, die seit drei Jahren niemand angefasst hat. Sie existieren, weil es riskant wirkt, sie zu entfernen. Sie verweisen auf Features, die 2023 eingestellt wurden. Jedes alte SaaS-Produkt hat einen Museumsflügel, und der Preis ist das Versprechen des Teams, Codepfade zu pflegen, die schon vor zwei Refactorings hätten sterben sollen.

Settings ist eine Produktoberfläche, keine Abstellkammer

Die meisten Teams behandeln Settings als den Ort, an dem der Rest des Produkts aufgeräumt wird. Genau diese Sichtweise ist der Bug. Settings ist eine der Oberflächen mit dem größten Hebel im Produkt, und die stärksten Teams gestalten sie auch so.

Einstellungen drücken das Weltbild des Produkts über den Nutzer aus. Sie vermitteln vier Dinge gleichzeitig. Wie sehr das Team dem Nutzer vertraut. Wie viel Kontrolle das Team zu teilen bereit ist. Was das Team für die richtigen Defaults hält. Und ob das Team die Zeit des Nutzers genug respektiert, um für die 5 % zu gestalten, die Defaults ändern, ohne die 95 % zu bestrafen, die das nicht tun.

Linear hat Settings als einzelne Suchoberfläche gestaltet, gesteuert über Command-K, fast ohne verschachtelte Tabs. Die implizite Botschaft: Der Nutzer ist kompetent, die Suche ist schnell, das Team hat die Hierarchiearbeit erledigt, damit der Nutzer es nicht muss. Notion ging in die entgegengesetzte Richtung und gewann auf dieselbe Weise. Einstellungen leben neben dem, was sie beeinflussen. Seiteneinstellungen auf der Seite. Datenbankeinstellungen in der Datenbank. Kontextuelle Einstellungen verschwinden in der Arbeit.

Vercel nutzt eine Hierarchie nach Geltungsbereich: Projekt, Team und Account, jeweils klar beschriftet, jeweils auf die Ressource begrenzt, die sie steuern. Das Stripe Dashboard ist handlungsorientiert, jeder Screen heißt „mach dies“, nicht „konfiguriere diese Präferenz“. GitHubs Repo-Einstellungen treffen die Abgrenzung genau, mit sauberer Trennung zwischen Repo-, Org- und Account-Eigentum.

Die sechs Regeln, die jede Einstellungsseite entscheiden

Diese Regeln verstärken sich gegenseitig. Triffst du fünf von sechs, liest sich die Seite wie eine Produktoberfläche. Triffst du drei, rutscht sie innerhalb eines Jahres in einen der Archetypen ab.

Regel 1: Search-first

Hierarchie ist ein Fallback, kein Primärweg. Der Nutzer kennt den Namen der Einstellung, bevor er weiß, unter welchem Tab sie liegt. Linears Command-K deckt Einstellungen als erstklassigen Ergebnistyp ab. Figma hat eine Einstellungssuche ergänzt, und die Zeit bis zum Toggle sank sofort. Wenn deine Einstellungsseite keine Suchleiste hat, wettest du darauf, dass Nutzer deine Informationsarchitektur auswendig lernen. Das werden sie nicht.

Regel 2: Kontextuelle Platzierung statt zentralem Register

Einstellungen leben neben dem, was sie beeinflussen. Benachrichtigungseinstellungen im Benachrichtigungspanel. Seiteneinstellungen auf der Seite. Eine zentrale Einstellungsseite ist in Ordnung für Anliegen auf Account-Ebene wie Profil, Abrechnung und Sitzungen, und für fast nichts sonst. Notion ist der Goldstandard. Figmas rechte Leiste erledigt denselben Job für Ebenen-, Frame- und Komponenteneigenschaften.

Regel 3: Sinnvolle Defaults, die Vertrauen verdienen

Jeder Default ist eine Produktentscheidung. Er drückt aus, was das Team für die richtige Antwort für 80 % der Nutzer hält. Ist der Default falsch, ist der Toggle ein Pflaster. Slacks Benachrichtigungs-Defaults gehen davon aus, dass du erreichbar sein willst, nicht stumm. Die Wette stimmt für den durchschnittlichen Nutzer. Die meisten Teams gestalten zuerst den Toggle und lassen den Default einfach herausfallen. Diese Reihenfolge ist falsch.

Regel 4: Progressive Disclosure statt flachem Wildwuchs

Der Nutzer sollte die fünf Einstellungen sehen, die 90 % der Nutzer interessieren. Die anderen 50 gehören einen Klick tiefer, hinter eine klare „Erweitert“-Affordance. Vercels Projekteinstellungen machen das vorbildlich. Der erste Screen zeigt Domain, Umgebungsvariablen und Deployment Protection. Build-Overrides, Function-Configs und Rewrites leben unter Erweitert.

Regel 5: Keine Waisen

Jede Einstellung gehört zu einer Gruppe. Jede Gruppe hat einen Namen. Der Waisentest: Lies ein beliebiges Label laut vor, ganz ohne Kontext. Wenn ein Designer in deinem Team dir nicht sagen kann, was der Toggle tut, ist er eine Waise. Waisen sind die Keimlinge des Museums.

Regel 6: Jede Einstellung verdient ihren Platz

Eine Einstellung ist ein Vertrag. Das Team verpflichtet sich, sie zu pflegen, zu dokumentieren, zu testen und ihre Wechselwirkungen mit jeder anderen Einstellung für immer zu durchdenken. Die meisten Einstellungen können diese Miete nicht zahlen. Die Standardhaltung zu jeder neuen Einstellung sollte „Nein“ sein. Gute Teams töten mehr Einstellungen, als sie ausliefern.

Anti-Patterns, die auf etwas Tieferes hindeuten

Drei Muster töten mehr Einstellungsseiten als alle anderen zusammen. Jedes ist ein Symptom dafür, dass das Problem nicht der Screen ist, sondern das Team dahinter.

Settings als Ersatz für Produktentscheidungen. Das Team konnte sich nicht auf Opt-in oder Opt-out einigen, also wurde es als Toggle ausgeliefert. Der Nutzer erbt den ungelösten Streit. Wenn du im Standup „lass es uns konfigurierbar machen“ hörst, siehst du dieses Anti-Pattern entstehen. Die tiefere Lektüre dazu findest du in Friction mit Absicht gestalten.

Settings, die schlechtes Design kompensieren. Ein „Kompaktmodus“-Toggle, weil die Standarddichte zu locker ist. Ein „Hoher Kontrast“-Toggle, weil die Markenfarben die Barrierefreiheit verfehlen. Ein „Klassische Ansicht“-Toggle, weil das Redesign abgelehnt wurde. Jedes ist ein echter Fix im Kostüm einer Option. Die Lösung ist, Dichte, Kontrast und Ansichten gleich beim ersten Mal richtig zu gestalten.

Settings, die niemand in einem Satz erklären kann. Wenn ein Designer nicht beschreiben kann, was die Einstellung tut, was sich ändert, wenn sie umgelegt wird, und für wen sie gedacht ist, sollte die Einstellung nicht ausgeliefert werden. Mach diesen Test, bevor ein neuer Toggle in die Codebasis kommt.

Das Audit der Einstellungsseite

Lass jede Einstellungsseite durch diese sieben Fragen laufen. Wenn bei sechs davon kein überzeugtes Ja steht, ist die Seite nicht fertig.

1. Kann der Nutzer jede Einstellung in unter fünf Sekunden finden? Wenn nicht, fehlt der Seite eine Suche oder die Hierarchie ist kaputt.
2. Hat jede Einstellung eine Ein-Satz-Beschreibung, die auch Nicht-Engineers verstehen? Wenn das Label einen Engineer zur Erklärung braucht, gehört es nicht auf die Produktoberfläche.
3. Hat das Umlegen des Toggles einen sichtbaren, unmittelbaren Effekt? Versteckte Zustandsänderungen sind Vertrauenskiller.
4. Sind Einstellungen nach Nutzeraufgabe gruppiert, nicht nach Feature-Team? Eine Seite, die danach organisiert ist, welches Team das Feature besitzt, ist ein internes Artefakt, das ins Produkt leckt. Gruppiere nach Nutzerziel.
5. Sind Defaults irgendwo schriftlich begründet? Das Team sollte auf ein Dokument, eine Entscheidung zur visuellen Hierarchie oder ein Markenprinzip zeigen können. Wenn der Default „was auch immer der Engineer im Sprint gesetzt hat“ ist, ist die Seite nicht fertig.
6. Könntest du die Hälfte der Einstellungen entfernen, ohne dass ein Nutzer es merkt? Wenn ja, tu es. Das Museum ist schwerer, als das Team denkt.
7. Sieht die Seite aus und fühlt sich an wie der Rest des Produkts? Lies sie neben deinen Prinzipien für Landingpage-Design. Wenn die Marke auseinanderfällt, ist die Einstellungsseite nicht markenkonform.

Ein Team, das dieses Audit zweimal im Jahr durchführt, liefert eine Settings-Oberfläche, bei der Nutzer nicht zusammenzucken. Das Team, das es durchführt, liefert nie die Art von Einstellungsseite, die zum Recruiting-Tool für die Konkurrenz wird.

Wähle das Prinzip, dann stutze die Seite

Einstellungen sind das Weltbild des Teams, eingefroren in Toggles. Gute Teams behandeln die Seite als erstklassigen Flow, mit demselben Handwerk, das sie in Onboarding, Dashboard und Marketing-Website stecken.

Der schnellste Weg, eine Einstellungsseite zu reparieren, ist nicht, sie neu zu gestalten. Es ist, die Hälfte davon zu löschen. Entferne jede Einstellung, die den Waisentest, den Ein-Satz-Test und den Verdient-ihren-Platz-Test nicht besteht. Was übrig bleibt, ist das Rückgrat einer echten Settings-Oberfläche.

Die Verbindung zu Empty States ist kein Zufall. Beide Screens offenbaren, was das Team glaubt, wenn nichts anderes auf dem Bildschirm davon ablenkt. Dieselbe Disziplin zeigt sich in den Prinzipien des Webdesigns.

Häufig gestellte Fragen

Wie viele Einstellungen sollte ein Produkt haben?

So wenige wie möglich. Jede Einstellung ist ein Vertrag, den das Team für immer pflegt. Die Standardhaltung zu jeder neuen Einstellung sollte „Nein“ sein. Wenn das Team die Einstellung nicht in einem Satz verteidigen, den Nutzer benennen, dem sie dient, und beschreiben kann, was sich sichtbar ändert, wenn sie umgelegt wird, sollte die Einstellung nicht ausgeliefert werden.

Wo sollten Einstellungen im Produkt leben?

Neben dem, was sie beeinflussen, nicht in einem zentralen Settings-Flügel. Seiteneinstellungen auf der Seite. Workspace-Einstellungen im Workspace. Benachrichtigungseinstellungen im Benachrichtigungspanel. Eine zentrale Einstellungsseite ist in Ordnung für Anliegen auf Account-Ebene wie Abrechnung, Profil und Sitzungen, und für fast nichts sonst.

Wie räume ich eine Einstellungsseite mit Jahren angesammelter Toggles auf?

Führe das Audit durch, dann lösche. Gruppiere jede Einstellung nach Nutzeraufgabe. Identifiziere Waisen, Sackgassen und Museumsstücke. Entferne im ersten Durchgang die untersten 30 % und beobachte die Support-Tickets. Wenn sich niemand beschwert, entferne weitere 20 %.

Gestalte die Einstellungsseite wie die Homepage

Die Einstellungsseite ist kein Keller. Sie ist ein Raum, in dem deine Power-User leben und nach dem dich neue Nutzer beurteilen. Behandle sie wie die Homepage, das Onboarding, das Dashboard. Wende dasselbe Handwerk an. Liefere sie mit derselben Überzeugung aus.

Wenn du ein Team willst, das die Einstellungsseite wie den Rest des Produkts gestaltet, statt sie aus dem Backlog zu erben, beauftrage Brainy. Wir gestalten Settings als erstklassigen Flow, mit der Disziplin, die die Seite klein hält und dafür sorgt, dass die Toggles ihre Miete verdienen.