Checklista | Liquid Design

00 z 35 punktów

Stabilność layoutu

Każdy obraz, wideo i osadzenie ma zadeklarowane wymiary lub aspect-ratio.
Kontenery na dane asynchroniczne istnieją od pierwszego renderu i trzymają wysokość.
Fonty ładują się z font-display: swap, a fallback ma dopasowane metryki.
Hydratacja i doładowanie skryptów nie przesuwają żadnego widocznego elementu.
Długie listy używają content-visibility: auto z contain-intrinsic-size, więc scrollbar nie zmienia długości.

Każdy widok danych ma zaprojektowane cztery stany: ładowanie, treść, pustkę i błąd.
Skeleton dzieli komponent i layout z treścią, którą zapowiada.
Stan pusty prowadzi do akcji i wyjaśnia, dlaczego niczego tu nie ma.
Stan błędu oferuje ponowienie i nie zrzuca winy na użytkownika.

Projekt i implementacja powstają mobile first, od 390 px w górę.
Rozmiary tekstu pochodzą z nazwanej skali opartej o clamp().
Layout działa od 320 px szerokości bez poziomego przewijania.
Wiersze tekstu mieszczą się w zakresie od 45 do 75 znaków.
Komponenty wielokrotnego użytku reagują na kontener, nie tylko na viewport.
Cele dotykowe mają co najmniej 44 na 44 piksele.
Wysokości pełnoekranowe używają dvh lub svh, a krawędzie szanują env(safe-area-inset).

Cały interfejs daje się przejść klawiaturą, a fokus jest widoczny przez :focus-visible.
Animacje używają wyłącznie transform i opacity oraz respektują prefers-reduced-motion.
Żaden status nie jest niesiony samym kolorem, obok stoi ikona albo etykieta.
Kluczowe widoki przechodzą test skali szarości bez utraty informacji.
Dymki i menu żyją w top layer przez Popover API, zakotwiczone w CSS, nie pozycjonowane skryptem.
Wejścia i wyjścia elementów animuje @starting-style z allow-discrete i respektują reduced motion.

Zmienne Figmy nazywają się tak jak tokeny w kodzie i żadna wartość nie jest wpisana ręcznie.
Każda ramka używa auto layoutu, a pozycje absolutne mają uzasadnienie w opisie.
Warianty i property komponentów w Figmie pokrywają się z propsami komponentów w kodzie.
Plik projektowy zawiera stany ładowania, pustki i błędu razem ze slotami na komunikaty.
Widok do implementacji jest wskazany jako konkretna ramka z linkiem, gotowa do odczytu przez Claude.

Kolory, typografia i odstępy pochodzą z nazwanych tokenów wspólnych dla designu i kodu.
Komponenty mają jedno źródło prawdy, a warianty powstają przez propsy, nie przez kopie.
Review designu i kodu przechodzi przez tę checklistę przed scaleniem zmian.
Nazwy tokenów i komponentów brzmią tak samo w Figmie, w kodzie i w rozmowie.