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