Дизайн-системы внедрять сложнее, чем библиотеки компонентов потому что количество людей, которые должны договориться на порядок выше

По моему опыту, дизайн-системы появляются у существующих бизнесов, когда накопилось понимание, как выглядят интерфейсы компании
Мне кажется странным делать дизайн-систему в компании с новым или единственным продуктом. Лучше взять готовую библиотеку компонентов
И дизайн-системы, и библиотеки компонентов решают несколько продуктовых задач. Чтобы объяснить пользу бизнесу, я использовал такие аргументы:
* готовые блоки ускоряют time-to-market продукта и новых фичей
* предоставляем похожий UI во всех продуктах
* уменьшается количество багов
Без поддержки бизнеса и дизайнеров втаскивать дизайн-систему бесполезно:
*бизнес не будет выделять время, система будет недолго развиваться на морально-волевых, потом будет медленно гнить
*если дизайнеры не согласны, отрисованные интерфейсы не будут биться с готовыми компонентами
Процесс внедрения будет небыстрым. Чтобы бизнес не включил заднюю, нужно сразу показывать ценность дизайн-системы.

Тут мы подходим к вопросу, писать своё или брать готовое
Исходя из моей гипотезы, что дизайн-система появляется только в крупных компаниях, следует, что существуют десятки интерфейсов, написана куча кода.

Внедрять что-то совсем новое со стороны будет очень сложно. Поэтому мы видим столько своих дизайн-систем
В небольших компаниях нет денег на разработку своего, поэтому обычно выбирается что-то готовое. В этом случае я бы обращал внимание на лёгкость кастомизации стилей (с этим у всех проблемы) и расширения.
В обоих случаях нужно спланировать внедрение. Чтобы показать ценность, мы делали быструю миграцию маленького проекта на дизайн-систему, а затем устраивали сессии парного программирования, чтобы разработчики мигрировали своими руками, но могли задавать вопросы
Adoption дизайн-системы — самая сложная часть работы. Нужно много рассказывать публично, устраивать парное программирование, давать отпор дизайнерам, которые делают много кастомных штук
Чем больше я работаю с дизайн-системой, тем больше понимаю, что программирование — это лишь маленькая часть этого продукта

Гигантский пласт работ связан с документацией, обсуждениями, выстраиванию границ дизайн-системы. Если хотите прокачаться в коммуникациях, то вам сюда

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Человек из IT

Человек из IT Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @itunderhood

30 Sep
Есть ли у вас шаблоны, по которым вы оформляете Pull Request?

У меня пригорает от пустых пул реквестов или описаний, которые не помогают ревьюеру Image
Открываешь такой пул реквест с однострочным описанием, а там 30 файлов изменено.

«Разбирайся сам, дружок», — как бы говорит мне создатель
На фронтенде это особенно больно, потому что разницу до и после можно увидеть только запустив две версии рядом или что-то прокликав.

Чувствуешь заботушку, когда автор это сделал за тебя
Read 9 tweets
30 Sep
Я же код пишу, поэтому расскажу про тестирование. Логично? Логично
Я очень рад, что автоматическое тестирование набирает популярность и разработчики медленно, но верно начинают писать тесты.

Тесты не решают всех проблем, но если приложение будет в проде несколько лет и нужно его поддерживать, то тесты — инвестиция в стабильность
Это и главное преимущество тестов, и главный недостаток. Легко провалиться в ловушку «напишем-тесты-потом-нам-фичи-в-прод-катить-надо»

Про тесты вспоминают, когда приложение начало разваливаться от каждого изменения, но уже поздно — архитектуры, которая позволит писать тесты нет
Read 7 tweets
29 Sep
Когда я начал работать во FreeNow у меня случилось несколько историй, которые заставили меня поизучать тему работы в мультикультурных командах.
Началось всё с того, что на одной из встреч фронтендеров два испаноговорящих чувака сцепились и очень громко ругались.

Вернее я думал, что они ругались. Оказалось, что такое случается, горячее обсуждение темы и никто друг на друга зла не держит.
Потом я стал обращать внимание, что индийский коллега никогда не говорит, что чего-то не понимает даже когда мне это очевидно.

Критики и обсуждений от него тоже можно было не ждать
Read 12 tweets
29 Sep
Чтобы хоть как-то говорить про дизайн-системы, нужно определиться с терминологией. Мне кажется важным разделить два понятия: дизайн-система и библиотека компонентов (UI Kit)
Библиотека компонентов — это набор готовых строительных блоков для создания интерфейсов. Дизайнеры нарисовали, разработчики напрогали и переиспользуют.

Очень утилитарная штуковина для ускорения разработки интерфейсов
Дизайн-система — это инструмент для формирования общих подходов и паттернов проектирования интерфейсов в компании. Такой альманах, как нужно делать интерфейсы.

Она обычно включает в себя библиотеку компонентов, но может и не включать.
Read 4 tweets
28 Sep
Чтобы участники команды чувствовали себя её частью и принимали командные решения, такие решения должны ощущаться справедливыми

Справедливость во многом — это наличие явных правил принятия решений. Подходов к принятию решений много, расскажу про основные. Идеального, конечно, нет
Подходы обычно оценивают по нескольким параметрам:
* скорость принятия решения
* уровень вовлечённости участников
* прозрачность
Первый метод — автократический. Решение принимает один человек, показывая всем свою альфовость

Скорость быстрая, прозрачность околонулевая, никто обычно не вовлечён в принятие решения.

Апгрейд этого подхода — консультативный, когда есть советники
Read 7 tweets
3 Aug
Сегодня тред про то как работает бизнес пассажирских авиаперевозок ✈️ в целом и метапоиск в частности.
Сразу замечу, что это в нем могут быть неточности, не переживайте, пожалуйста, из-за этого слишком сильно.
Для начала, давайте определимся с действующими лицами всей этой истории:
Read 32 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(