Комментарии 26
Спасибо, Виктор. Супер полезная статья! Все четко и понятно.
Виктор, большое спасибо за проделанную работу. Вы супер!
Спасибо большое за статью. Как раз нужно было освежить знания в этом вопросе
И вот теперь главный вопрос. Кто должен принимать "Правильное" решение на все эти вопросы и нести за всё это отетственность?
Дизайнер? Разраб? Или менеджер?
По факту понятное и удобное решение для дизайнера, может потом превратиться в кучу часов для разраба. Но на момент принятия решения жто не будет очевидно)
О, теперь мы знаем, куда отправлять 98% всех вопросов в чате дизайн-систем.
зашел просто из-за красивого оформления превью :) но это крутой материал
Классная статья, Вить, как всегда)
Витя, а такой вопрос, у вас есть какие-то метрики конкретно для дизайн-системы? Как оценивать работу дизайнера дизайн-системы в продуктовой компании, если не метриками))
Вопрос со звёздочкой ) Зависит от того, как саму дс замеряют в компании. Можно мерить адопшен (покрытие компонентами), можно считать тайм-ту-маркет (скорость доставки до прода). Можно переводить на деньги. Но, на мой взгляд, это не говорит о качестве. Можно всё утыкать компонентами, но они будут плохо работать. Или так закрутить гайки, что дизайнеры перестанут искать лучшие решения и станут операторами Figma. При этом тайм-ту-маркет то сократится.
В моём мире показателем качества дс является, как ни странно, тишина. Когда про дс мало говорят, когда нет необходимости оправдываться перед бизнесом высосанными из пальца показателями. Когда дс просто работает.
А про дизайнера дс скажу так — если его можно назвать только дизайнером — он не справляется ) Он должен быть и инженером, и архитектором, и массовиком-затейником. И если дс работает, как сказано выше, то и он хорош.
Спасибо, Виктор, за подробный разбор и полезные ссылки 😉 Продолжаем движение)) やった ! 😃✌️
Хорошая статья, чтобы разложить все в голове по полочкам. У нас, небольших дизайн-команд, прибавляется ещё одна боль — пейвол нужных фич в фигме. Бюджеты на большинстве проектов не позволяют переехать на орг/энтерпрайз (ведь как дев мод вышел из беты, каждый разработчик теперь ест ещё 1 доп место — не будут же они с одного аккаунта сидеть), поэтому модов на переменные с гулькин нос, нет бранчинга, даже стату по компонентам не посмотреть.
Приходится держать мастер-файл (и там мудреное версионирование получилось — одновременно компонентое и библиотечное), а на каждый новый продукт форкать библиотеку и собирать тему там, и все это очень долго и неудобно получается
Виктор, благодарю. Интересно и познавательно
Очень удобный путеводитель, даже если раньше не слышал никогда про ДС, после чтения кажется, что почти всё уже знаешь о дизайн-системах!
Спасибо, как всегда под руку
Автостопом по дизайн-системе. Путеводитель с оглавлением