Как стать автором
Обновить

Комментарии 20

Спасибо за интересный материал. Всегда было интересно как у вас все устроено.

Вам спасибо, что прочитали)
Я правильно понял? Шрифты для веба и мобилок у вас в одной библиотеке?
В разных файлах Figma. Подключаются отдельно.
Хотелось бы побольше скриншотов чтобы была понятнее реализация на практике
Скажите пожалуйста, что осталось не понятным?
В целом то все понятно. Просто интересно посмотреть как это выглядит изнутри. Но это уже скорее всего внутренняя информация.
Старалась описать достаточно подробно. Больше картинок добавлять не было смысла, они все были однотипные)

Лично мне было бы интересно увидеть как выглядит организация проекта в Фигме: какие файлы в него входят, как организованы страницы внутри них, как отслеживается версионность.

Поняла вас. Судя по комментариям и по вопросам, набирается уже на вторую статью. Спасибо)

Хотелось бы подробнее увидеть на примере более подробную спецификацию с описанием поведения, анимации компонента. Каким образом именно это описывается, создается отдельная гифка, или просто пишется текстом, или может прикрепляется ссылка на реализацию, например на codepen или иное, или все вместе?
Есть ли у вас некое кладбище или архив или бэклог интерфейсов, которые не вошли в прод, или оказались не реализуемы в данный момент, или просто был сделан классный компонент, но для той задачи, в рамках которой он был сделан, не подошел?

Если кратко, то зависит от анимации. Что-то можно описать словами, показать пример «как у других», сделать анимацию в Principle. В Авито сейчас самые простые анимации, но мы хотим и планируем их улучшать.

Есть ли у вас некое кладбище или архив или бэклог интерфейсов, которые не вошли в прод
Есть.

или просто был сделан классный компонент, но для той задачи, в рамках которой он был сделан, не подошел?
Мы смотрим статистику по использованию компонента. Если появился новый компонент на замену, но у старого много использований, оставляем, но делаем пометку, что компонент старый и надо использовать другой. Ещё думаю, что с такими компонентами делать. Текущее решение не устраивает, не всегда можно увидеть эту пометку, к сожалению.

Подскажите, у вас есть чек-лист по которому можно пройтись дизайнер или разработчик и проверить что компонент проработан полность?

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

Зачем описывать в спецификации? Я это делаю из-за компенсаций. Или когда много элементов с разными отступами.
… и спасибо за Zeroheight.

Статья давольно общая. Хотелось бы увидеть кухню изнутри. Как называете компоненты, как описываете. Как передаете дизайн-систему андроедчикам?

Спасибо за ваш комментарий. Вопросов накопилось много, в целом, думаю, что их можно осветить в другой статье более подробно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий