Sachbearbeiter-Dashboard — Designgrundlagen

1Das Problem: Kontextwechsel ist der eigentliche Kostentreiber

Eine Sachbearbeiterin in der IHK-Carnet-Verwaltung bearbeitet 60–100 Vorgänge pro Tag über heterogene Entitätstypen hinweg — Firmen, Carnets, Prüfungen — in mehreren Kammerbezirken. Traditionelle Enterprise-UIs erzwingen Navigation zwischen diesen Typen. Die Kosten liegen nicht im Klick. Sie liegen in der Neuorientierung nach der Ankunft: Jeder Bildschirmwechsel zwingt die Sachbearbeiterin, drei Fragen zu beantworten — Wo bin ich? Was kann ich hier tun? Wie komme ich zurück? Bei hohem Volumen summiert sich dieser Neuorientierungsaufwand auf Stunden verlorener Produktivität pro Woche.

Das Designziel ist null Neuorientierungsaufwand: ein fixes Drei-Zonen-Layout, dessen räumliche Stabilität Orientierungsfragen durch das periphere Sehen beantwortet — ohne aktives Lesen.

2Drei Zonen, null Navigation

Das Dashboard ist eine Seite mit drei vertikal gestapelten Zonen. Jede Zone beantwortet eine kognitive Frage, die über alle Aufgaben, alle Entitätstypen und alle Erfahrungsstufen hinweg stabil bleibt. Die Zonen bewegen sich nie, verschwinden nie und ändern ihr Layout nie.

Designvorbild: Das Bloomberg Terminal erreicht dasselbe mit einem fixen Vier-Panel-Layout, das sich über Tausende verschiedener Datenansichten nie ändert. Die Panels sind der kognitive Anker; der Inhalt darin wechselt. Unsere drei Zonen erfüllen dieselbe Funktion mit einfacherer Geometrie.

3Das mentale Modell der Sachbearbeiterin

Die oberste Schicht jedes Verwaltungssystems ist nicht das Datenmodell oder die API — es ist das mentale Modell, das die Sachbearbeiterin an den Schreibtisch mitbringt. Eine Sachbearbeiterin denkt in Vorgängen, nicht in Datenbankzeilen. Sie denkt in erlaubten Handlungen, nicht in CRUD-Operationen. Ein System, das sein Datenmodell der Sachbearbeiterin direkt ausliefert, ist gescheitert, bevor die erste Interaktion stattfindet.

Das Kommandofeld als Interpreter

Das zentrale Kommandofeld ist kein Suchfeld. Es ist die Kommandozeile der Sachbearbeiterin — ein direkter Ausdruck ihrer Absicht über den Domänenobjektgraphen. Jedes Token verengt gleichzeitig die Entitätsmenge und aktualisiert die verfügbare Aktionsmenge. Die Sachbearbeiterin sieht keine Ergebnisseite — sie sieht eine sich kontinuierlich schärfende Absicht.

Eingabe                     Was das System zeigt
──────────────────────      ──────────────────────────────────────────────────────
„g"                    →    Günther Maschinenbau AG  ·  Gauss Metallbau GmbH
„gün"                  →    Günther Maschinenbau AG                           [Entität aufgelöst]
„gün car"              →    Günther Maschinenbau AG  ›  Carnet #2024-00456    [Relation gefolgt]
„gün car ver"          →    … AKTION: Zu anderer Firma verschieben ↵          [Methode gefunden]
„gün car ver mül"      →    … verschieben → Müller Werkzeugbau GmbH           [Parameter aufgelöst]
[ENTER]                →    Arbeitsschritt ausgeführt · Strom aktualisiert

Auffindbarkeit ohne Menü: Kategorie-Chips

Eine Sachbearbeiterin, die noch nicht weiß, dass es Carnets gibt, wird das Wort carnet nicht eintippen. Um diese Lücke zu schließen, ohne ein Navigationsmenü einzuführen, zeigt das Kommandofeld im Leerzustand Kategorie-Chips als anklickbare Maus-Affordanzen:

  [ Carnets ]   [ Firmen ]   [ Prüfungen ]   [ Verwaltung ]

Ein Klick auf [Carnets] entspricht dem Eintippen von carnet. Das Token-Modell und das Chip-Modell sind derselbe Mechanismus; die Chips sind ein nullvokabular-Einstiegspunkt für den ersten Arbeitstag. Erfahrene Sachbearbeiterinnen überspringen die Chips und tippen direkt — die Oberfläche bestraft keine Expertise und blockiert keine Anfänger.

4Der Strom — Chat als Geschichte

Zone 3 ist die Geschichte der Sitzung und aller Ereignisse auf Entitäten im Zuständigkeitsbereich. Die räumliche Metapher ist der Chat-Verlauf: das am tiefsten verankerte Raummodell der Arbeitnehmerschaft der 2020er Jahre. Das Kommandofeld ist die Nachrichteneingabe, unten verankert. Die Geschichte fließt darüber nach oben. Der jüngste Austausch ist direkt über dem Eingabefeld.

Zwei Sprecher, zwei visuelle Ausrichtungen:

• Sie: (linksbündig) — der eingetippte Befehl der Sachbearbeiterin. Was ich gesagt habe.
• Aktion: (rechtsbündig) — die Antwort des Systems. Was passiert ist.

Kollegin- oder Systemautomationsereignisse erscheinen als Aktion:-Bubble ohne vorangehendes Sie: — genau wie das Empfangen einer Nachricht in einem Gruppen-Chat. Nach einem Telefonat sieht die Sachbearbeiterin sofort, was sich verändert hat — durch Blick auf den unteren Bereich des Stroms.

Private und gemeinsame Einträge — die Trennlinie

Der Strom enthält zwei semantisch verschiedene Eintragstypen:

Die Visualisierung macht die Grenze sichtbar: Sie:-Bubbles tragen ein Schloss-Icon und beim Hover den Hinweis „Nur für Sie — nicht im Protokoll." Aktion:-Bubbles tragen immer ein Quell-Badge (Sachbearbeiterin-Name, [System], [Portal], [Allianz]). Die Unterscheidung ist visuell, nicht räumlich — beide Typen leben im selben Strom, weil sie zeitlich zusammengehören.

Vorgangshistorie — das Kassenbuch der Entität

Der Strom zeigt die persönliche Sitzung. Ein Vorgang hat jedoch einen viel breiteren Lebenszyklus: Kundenportal-Einreichungen, Kolleginnenaktionen, externe Partnerantworten, Systemautomationen. Diese vollständige Geschichte lebt in der Vorgangshistorie — einem Seitenleisten-Panel, das sich öffnet, wenn eine Entität ausgewählt wird.

Das Panel öffnet sich als Seitenleiste und überlagert den linken Teil des Stroms, verdeckt aber nicht das Kommandofeld. Es ist keine Modal-Ansicht und keine eigene Seite.

5Das Reset-Modell — git reset, nicht Strg+Z

Der Arbeitsstrahl ist der persönliche Befehlspfad der Sachbearbeiterin. Klassisches Undo (Strg+Z) arbeitet in strenger umgekehrter Reihenfolge: Aktion 5 muss rückgängig gemacht werden, um Aktion 3 zu korrigieren — auch wenn Aktion 4 völlig unabhängig war. Das Arbeitsstrahl-Modell verwendet stattdessen git reset mit automatischer kausaler Abhängigkeitsanalyse.

Die Sachbearbeiterin klickt eine frühere Sie:-Bubble. Das System bewertet, welche nachfolgenden Aktionen davon abhingen (gleiche Entität, oder Ausgabe-als-Eingabe) und welche unabhängig waren. Unabhängige Aktionen überleben den Reset automatisch. Nur kausal abhängige Aktionen werden rückgängig gemacht. Der Reset selbst ist ein Kassenbuch-Eintrag — nichts wird stillschweigend gelöscht.

6Sofortige Auflösung — der Performance-Vertrag

Das Versprechen des Kommandofelds: Jeder Tastenanschlag liefert eine sichtbare Vorschau innerhalb ~50 ms — unabhängig von der Backend-Round-Trip-Zeit. Das ist nur erreichbar, wenn der Client niemals eine Anfrage beim Drücken einer Taste auslöst. Alle sichtbaren Vorschläge kommen aus Daten, die bereits vor dem Tippen eingetroffen sind. Die Aufgabe des Backends ist es, vorherzusagen, was die Nutzerin als Nächstes braucht, und es vorab zu liefern.

7Der URL-Vertrag: Ein Bildschirm bedeutet nicht null URLs

Eine Single-Screen-Anwendung, die die URL aufgibt, verliert Teilbarkeit, Browser-History, Back-Button-Verhalten und Testadressierbarkeit. All das setzt keine Seitennavigation voraus — es setzt history.pushState() voraus.

Das Design verpflichtet sich zum folgenden URL-Vertrag:

pushState feuert bei jedem Übergang. Es feuert kein Navigation-Event — der Bildschirm wird nie entladen. Das popstate-Event wird abgefangen und als Zustand-Wiederherstellung innerhalb des aktuellen Bildschirms behandelt: Kommandofeld und Zonen rekonstruieren sich aus den URL-Parametern ohne Neuladen.

Dies löst den stärksten strukturellen Einwand gegen das Einzelbildschirm-Modell. Die Wahl ist nicht „ein Bildschirm vs. URLs" — sie ist „ein Bildschirm mit pushState" gegenüber „Multi-Route-SPA mit Seitenübergängen." Beide haben URLs. Nur eines eliminiert den Neuorientierungsaufwand.

8Barrierefreiheitsvertrag: BITV 2.0

Der deutsche öffentliche Sektor ist an die BITV 2.0 gebunden, die WCAG 2.1 AA umsetzt. Eine Kommandopaletten-primäre Oberfläche ist BITV-konform, wenn sie korrekt implementiert wird. Die folgenden Punkte sind erstklassige Anforderungen, keine Nachgedanken:

• Kommandofeld: <input role="combobox" aria-autocomplete="list" aria-expanded aria-owns="suggestion-list">. Die Vorschlagsliste ist ein korrektes role="listbox" mit role="option"-Kindern. Screenreader kündigen die Trefferanzahl und den aktuell markierten Vorschlag bei jedem Tastenanschlag an.
• Zonen-Landmarks: Zone 1 → <header>, Zone 2 → <main>, Zone 3 → <region aria-label="Vorgangsstrahl">. Screenreader-Nutzerinnen navigieren per Landmark ohne zusätzliche Affordanz.
• Kategorie-Chips im leeren Kommandofeld sind Standard-<button>-Elemente, keine Custom-Widgets — Maus- und Screenreader-Einstiegspunkt für Nutzerinnen ohne Token-Vokabular.
• Inline-Panels verwenden role="dialog" mit aria-modal="false" und aria-labelledby, das auf das aufgelöste Befehlslabel zeigt. Fokus wechselt beim Öffnen zum ersten Panel-Feld; ESC gibt den Fokus an das Kommandofeld zurück.
• Der Tastatur-Vertrag ist der Barrierefreiheits-Vertrag. TAB, SHIFT+TAB, ENTER, ESC und ↑ sind Standard-Browser-Tasten. Keine nicht-standardmäßigen Tastenbelegungen für Pflichtaktionen.

9Komplexe Formulare ohne Wizard

Der härteste Einwand gegen das Einzelbildschirm-Modell: „Wir haben ein 12-Felder-Carnet-Antragsformular. Das kann man nicht in eine Kommandozeile eintippen." Richtig — und die Antwort ist nicht „12 Tokens tippen." Die Antwort ist, dass komplexe Dateneingabe ein anderer Interaktionsmodus ist, den Zone 2 unterstützt, ohne den Einzelbildschirm-Vertrag zu brechen.

Warum Wizards existieren — und was sie eigentlich lösen

Ein Wizard löst zwei Probleme: Sequenzierung (Felder in einer bestimmten Reihenfolge ausfüllen, weil spätere Felder von früheren Entscheidungen abhängen) und kognitive Portionierung (12 Felder auf einmal überfordern; 3 auf einmal fühlen sich handhabbar an). Beide Probleme sind real. Aber die Lösung des Wizards — ein getrennter mehrseitiger Ablauf mit Weiter/Zurück-Navigation — führt drei neue Probleme ein:

Progressives Inline-Expanding

Befehl:     firma neu anlegen
Zeile 2:    ✓ Neue Firma anlegen

Unter Zone 2 (expandiertes Panel):
┌─────────────────────────────────────────────────────────────────┐
│  Neue Firma anlegen                                       1 / 3 │
│                                                                 │
│  Firmenname     [ ________________________________ ]             │
│  Rechtsform     [ GmbH ▾ ]                                      │
│  Kammerbezirk   [ Aachen ▾ ]                                    │
│                                                                 │
│  [TAB → weiter]                           [ESC Abbrechen]       │
└─────────────────────────────────────────────────────────────────┘

Nach TAB auf dem letzten Feld ersetzt das Panel seinen eigenen Inhalt:
┌─────────────────────────────────────────────────────────────────┐
│  Neue Firma anlegen                                       2 / 3 │
│  ✓ Günther Maschinenbau AG · GmbH · Aachen                      │
│                                                                 │
│  Straße         [ ________________________________ ]             │
│  Hausnummer     [ ____ ]                                        │
│  PLZ            [ _____ ]   Ort  [ __________________ ]         │
│                                                                 │
│  [TAB → weiter]   [SHIFT+TAB ← zurück]    [ESC Abbrechen]       │
└─────────────────────────────────────────────────────────────────┘

Hierarchie der Wizard-Ersatzmuster

Jede Stufe verwendet denselben Tastatur-Vertrag (TAB vorwärts, SHIFT+TAB zurück, ENTER ausführen, ESC beenden), denselben räumlichen Anker (Zone 2 expandiert nach unten, verdrängt nie die Scope-Leiste) und dasselbe Wiederaufnahme-Modell (Tokens bleiben, Entwürfe erscheinen in Offene Vorgänge).

10Was dieses Design ausschließt

Die Designentscheidung hat Konsequenzen, die akzeptiert werden müssen — sie sind nicht verhandelbar:

• Keine Detailseiten als eigene Routen. Alle Details werden inline in Zone 2 (Kommandoauflösung + Inline-Panels) oder Zone 3 (Strom-Einträge + Vorgangshistorie-Seitenleiste) angezeigt.
• Keine Einstellungsseite. Scope wird in Zone 1 gesetzt. Präferenzen sind ein Befehl: einstellungen sprache deutsch.
• Kein Onboarding-Wizard. Eine neue Sachbearbeiterin startet mit demselben Bildschirm wie eine Veteranin. Die Kategorie-Chips und der Vorschlagsmechanismus des Kommandofelds sind das Onboarding.
• Keine modalen Bestätigungsdialoge. Die Vorschau-Zeile in Zone 2 ist die Bestätigung. Wenn die Vorschau genau zeigt, was passieren wird, hat ein Modal nichts mehr hinzuzufügen.
• Keine Dashboard-Widgets oder KPI-Kacheln. Die Offene-Vorgänge-Seitenleiste ist der einzige „Dashboard"-Inhalt — und er ist handlungsrelevant, nicht dekorativ.

11Bekannte Einwände und ihre Mitigationen

Ein traditioneller Webapplikations-Designer erhebt strukturelle Einwände gegen das Einzelbildschirm-Modell. Die folgende Tabelle klassifiziert jeden Einwand nach dem Grad seiner Lösung.

Vollständig mitigiert — durch den URL-Vertrag

Teilweise mitigiert — erfordern Designergänzungen

Echte Spannungen — anerkannt, nicht aufgelöst

12Empfohlene Aufbaureihenfolge

Das Design hat eine strikte Abhängigkeitsreihenfolge. Das UI vor dem Domänenmodell zu bauen, produziert ein UI, das die falschen Abstraktionen eincodiert.

1. Die drei Konzepte benennen — Vorgang, Zuständigkeit, Arbeitsschritt — und auf Domänenentitäten abbilden. Keine UI-Arbeit, bevor das stabil ist.
2. Die einheitliche Entitätsschnittstelle definieren: resolve(), actions(user, perms), synonyms, history(). Jeder Entitätstyp implementiert denselben Vertrag.
3. Den Kommando-Interpreter als Domänen-Service entwerfen — nicht als UI-Komponente. Die Vorschlagsliste ist das Typsystem, sichtbar gemacht.
4. Autorisierung zur Anfragezeit verdrahten. Die API gibt nur zurück, was die Sachbearbeiterin sehen und tun darf. Niemals zur Renderzeit filtern.
5. Den Strom als append-only-Ledger auf Datenschicht-Ebene mit Quellenattribuierung je Eintrag bauen.
6. Das UI zuletzt bauen — drei Zonen, die das Domänenmodell rendern, nichts weiter.
7. Mit fünf echten IHK-Carnet-Sachbearbeiterinnen validieren, bevor eine Produktionsimplementierung eingegangen wird.

LitLiteratur

• Raskin, J. (2000). The Humane Interface. Addison-Wesley. — Monotone Oberflächen, Gewohnheitsbildung, null-kognitiver-Overhead-Interaktion.
• Carroll, J. M. & Rosson, M. B. (1987). The Paradox of the Active User. In Interfacing Thought. MIT Press. — Nutzerinnen wenden bekannte Metaphern an; Oberflächen mit den vorhandenen Metaphern gestalten.
• Miller, G. A. (1956). The Magical Number Seven, Plus or Minus Two. Psychological Review, 63(2). — Arbeitsgedächtnis-Grenzen; drei Zonen bleiben im kognitiven Budget.
• Sweller, J. (1988). Cognitive Load During Problem Solving. Cognitive Science, 12(2). — Extrinsische Last (Navigation) konkurriert mit lernbezogener Last (die eigentliche Aufgabe).
• Nielsen, J. (1994). 10 Usability Heuristics. — #1 Sichtbarkeit des Systemstatus, #3 Nutzerkontrolle (ESC funktioniert immer), #7 Flexibilität und Effizienz.
• Cooper, A. (2004). The Inmates Are Running the Asylum. — Perpetual Intermediates: für den Nutzer entwerfen, der über Anfänger hinaus, aber kein Experte ist.
• BITV 2.0 — Barrierefreie-Informationstechnik-Verordnung (2019). Implementiert WCAG 2.1 AA für Software des deutschen öffentlichen Sektors.

Quellen: ux/foundations/single-screen-rationale.md · ux/foundations/clerk-mental-model.md · ux/foundations/single-screen-counterargument.md · ux/patterns/instant-command-resolution.mdx · ux/screens/sachbearbeiter-dashboard/SCREEN.md