Стоит также отметить, что во время разработки могут появится вопросы. Они всегда есть) Поэтому вы проговариваете нюансы с дизайнером или разработчиком. Добавляете или изменяете описание в спецификации.
Если кратко, то зависит от анимации. Что-то можно описать словами, показать пример «как у других», сделать анимацию в Principle. В Авито сейчас самые простые анимации, но мы хотим и планируем их улучшать.
Есть ли у вас некое кладбище или архив или бэклог интерфейсов, которые не вошли в прод
Есть.
или просто был сделан классный компонент, но для той задачи, в рамках которой он был сделан, не подошел?
Мы смотрим статистику по использованию компонента. Если появился новый компонент на замену, но у старого много использований, оставляем, но делаем пометку, что компонент старый и надо использовать другой. Ещё думаю, что с такими компонентами делать. Текущее решение не устраивает, не всегда можно увидеть эту пометку, к сожалению.
Скорее у нас есть шаблон, по которому мы описываем компоненты для разработчика.
— Пишем, что это вообще за компонент и зачем он нам нужен.
— Обязательно ставим примеры из интерфейса, хорошо, когда их от 2-3.
— Проставляем все отступы, компенсации, если такие есть.
— Описываем общие случае, самые распространенные.
— Указываем сложные кейсы, даже если их сейчас нет, то в разработке нужно их учесть. Это может быть всё что угодно, большой заголовок в несколько строк, минимальные значения и т.д.
— Если это какие-то алерты, то показываем каких цветов они могут быть.
— Указываем где и как будет выглядеть hover и highlighted. Какого размера.
Т.е. вот по такому шаблону мы идём в описании, добавляя или убирая какие-то пункты, зависит от сложности компонента. Не буду лукавить, конечно же смотрим как сделано у других, что в других дизайн-системах описано. Ведь, компоненты у всех +- похожи.
Зачем описывать в спецификации? Я это делаю из-за компенсаций. Или когда много элементов с разными отступами.
… и спасибо за Zeroheight.
Есть.
Мы смотрим статистику по использованию компонента. Если появился новый компонент на замену, но у старого много использований, оставляем, но делаем пометку, что компонент старый и надо использовать другой. Ещё думаю, что с такими компонентами делать. Текущее решение не устраивает, не всегда можно увидеть эту пометку, к сожалению.
— Пишем, что это вообще за компонент и зачем он нам нужен.
— Обязательно ставим примеры из интерфейса, хорошо, когда их от 2-3.
— Проставляем все отступы, компенсации, если такие есть.
— Описываем общие случае, самые распространенные.
— Указываем сложные кейсы, даже если их сейчас нет, то в разработке нужно их учесть. Это может быть всё что угодно, большой заголовок в несколько строк, минимальные значения и т.д.
— Если это какие-то алерты, то показываем каких цветов они могут быть.
— Указываем где и как будет выглядеть hover и highlighted. Какого размера.
Т.е. вот по такому шаблону мы идём в описании, добавляя или убирая какие-то пункты, зависит от сложности компонента. Не буду лукавить, конечно же смотрим как сделано у других, что в других дизайн-системах описано. Ведь, компоненты у всех +- похожи.