Ну база, что дизайнер проектирует не страницы, а системы логических состояний. Классический Hand-off это на самом деле 20%, а всю остальную работу ты отдал фронтенду и вот это ты зря сделал.

Кротовая нора Ready For Dev ведет на три уровня глубины.

1. Уровень данных. - Initial. То есть плейсхолдер “холодного старта”. Если данных нет - это ошибка фильтрации или пустая база? - Skeleton Flow. Вместо дефолтных спиннеров проектируем скелетоны, повторяющие структуру целевой страницы, в идеале конечно иметь просто инструмент для тестинга отзывчивости этих самых скелетонов. Это минимизирует пролаг пользователя и системы и кратно улучшит пользовательский опыт. - Error Handling. Обязательно иметь уже заранее проработанные системные ошибки и валидационные. Как ведет себя инпут при предварительной валидации, если юзер еще не закончил ввод? Да, я понимаю, что разработка, как такие же носители дизайн системы, должны заранее иметь ответ на этот вопрос до получения макета, но обязательств с дизайна никто не снимал, особенно если кейс для фичи уникальный.

2. Уровень взаимодействия - Focus. В сложных интерфейсах навигация с клавиатуры — мастхэв. Обязательно продуманная навигация + спроектированные Focus Ring (с учетом офсетов и контрастности) - Disabled vs Read-only. Важнейший нюанс. Disabled - компонент выключен, Read-only - данные доступны для чтения, но не для правки (возможно копирование контента) . У них разный визуальный вес и разные события по курсору.

3. Пограничный уровень. - Content Overflow: Что будет, если в ячейке таблицы прикатит строка на 500 символов? Транкейт, перенос или расширение ячейки? Заложенно ли такое поведение в библиотеку? Это разовая акция или надо идти от команды дизайн системы и увеличить кратно стоимость фичи?

Ваши спроектированные макеты - это ТЗ для разработчика и в них не должно оставаться слепых пятен. Обнял