Verfeinerung und Anpassung des B2B-Bürolayouts: Eliminierung von CLS/LCP, Einführung in ein Designsystem und browserübergreifende Anpassbarkeit

Ausgangssituation: Es besteht ein B2B-Personenkonto für Kunden eines Logistikunternehmens (Bestellungen, Status, Dokumente, Zahlungen). Das Layout wurde bereits in das Projekt implementiert, ist jedoch in Fragmenten zusammengesetzt und verhält sich an verschiedenen Haltepunkten instabil. Auf manchen Seiten kommt es beim Laden von Daten zu Layout-Sprüngen, Tabellen „schweben“, modale Fenster und ein fester Header-Umbruch, und bei iOS Safari gibt es horizontale Scrolls. Figma verfügt über ein aktuelles Designsystem und wichtige Bildschirmlayouts, aber die aktuelle Implementierung passt nicht dazu.

Technische Umgebung: Next.js 14 (App Router), TypeScript, CSS-Module + PostCSS, teilweise Tailwind-Utilities, React-Komponenten, Assemblierung über Vercel. Die Benutzeroberfläche verwendet eine einfache lokale Bibliothek von Komponenten (Schaltfläche, Eingabe, Modal, Tabs), aber an einigen Stellen werden die Stile direkt in den Komponenten festgelegt. Daten kommen asynchron an, es gibt Skelette, Virtualisierung von Zeilen in einer Tabelle auf einer der Seiten. Repository auf GitHub, Aufgaben werden per PR angenommen.

Was getan werden muss: Das bestehende Layout in ein stabiles Anpassungs- und Designsystem überführen, ohne die Logik neu zu schreiben und ohne den Technologie-Stack zu ändern.
- Führen Sie eine Prüfung von 6–8 Schlüsselseiten durch: Dashboard, Bestellliste, Bestellkarte, Dokumente, Zahlungen, Profil.
- Anpassungsfähigkeit für Haltepunkte 360/768/1024/1440 korrigiert, ohne die Datenstruktur und API zu ändern.
- Beseitigen Sie CLS-Quellen und Flackern beim Laden: Reservieren Sie Größen für Grafiken/Tabellen/Karten, korrigieren Sie Skelette, stabilisieren Sie die Höhe der Kopfzeile und Symbolleisten.
- Normalisieren Sie das Raster und die Ränder für Design-Tokens von Figma: Bringen Sie Typografie, Abstände, Radien und Schatten auf die angegebenen Werte und entfernen Sie doppelte „magische“ Werte.
- Tabellen verbessern: feste Kopfzeile, vorhersehbare Spalten, Silbentrennung und Kürzung, korrektes horizontales Scrollen nur innerhalb der Tabelle auf schmalen Bildschirmen, Beibehaltung der Zugänglichkeit.
- Korrigieren Sie modale Fenster und Dropdowns: korrekte Positionierung, Verbot des Scrollens im Hintergrund, Fokusfalle, Arbeiten in iOS Safari ohne zu springen, wenn die Tastatur erscheint.
- Bringen Sie Stile zu einem einheitlichen Ansatz: Verschieben Sie Inline-Stile in CSS-Module, wo sie sich auf die Unterstützung auswirken, und entfernen Sie widersprüchliche Tailwind-Klassen auf problematischen Komponenten, ohne den Rest des Layouts zu zerstören.

Einschränkungen: Sie können Geschäftslogik, Routing, API-Verträge und die Komponentenbibliothek nicht radikal ändern. Sie können keine schweren UI-Frameworks verbinden. In begründeten Fällen ist es zulässig, kleine Hilfsmittel zum Messen/Fixieren von Abmessungen und zur Verbesserung der Zugänglichkeit hinzuzufügen. Es ist wichtig, das SSR/CSR-Verhalten von Next.js beizubehalten und die Build-Zeiten nicht zu verkürzen.

Ergebnis: PR mit Layout- und Stiländerungen sowie einem kurzen Markdown-Bericht über die gefundenen Probleme und ergriffenen Lösungen, damit das Team weiter unterstützen kann.

Messbare Akzeptanzkriterien:
1) Auf diesen Seiten gibt es keinen horizontalen Scroll am Hauptteil mit einer Breite von 360/768/1024/1440 in Chrome/Firefox/Edge und Safari (macOS + iOS).
2) CLS im Dashboard und in der Bestellliste ist reduziert und überschreitet nicht 0,1, wenn Lighthouse im Produktionsmodus gemessen wird, LCP wird im Vergleich zum aktuellen Wert nicht um mehr als 10 % verschlechtert.
3) Tabellen unterbrechen das Raster nicht, die Spalten sind lesbar, die Kopfzeile ist fixiert und horizontales Scrollen erfolgt nur innerhalb des Tabellencontainers.
4) Modale Fenster: Der Fokus geht nicht über die Grenzen hinaus, Esc wird geschlossen, das Scrollen der Seite unter dem Modal ist blockiert, unter iOS gibt es kein Ruckeln des Inhalts beim Öffnen/Schließen.
5) Die Stile entsprechen hinsichtlich der Grundparameter (Schriftarten, Größen, Einrückungen, Radien) den Tokens von Figma und es gibt keine Duplizierung kritischer Regeln an 2-3 Stellen für eine Komponente.

Die erwarteten Arbeitsschritte sind: schnelle Prüfung und Bearbeitung des Plans, dann iterative PR nach Blöcken (Tabellen, Modalitäten, Raster/Tokens), abschließender Durchlauf und Prüfung anhand der Akzeptanzkriterien.