0:01 Дизайнер рисует картинку в фигме.
0:03 Дизайнер, пожалуйста, рассказывайте то, что у вас в голове, ту общую картину, которую вы задумали прекрасно, чтобы мы могли ее у себя отразить, и потом, когда она у вас начнет меняться, какими-то тимицами.
0:16 Мы себя в одном месте, а не в 60-ти как взяли.
0:19 Это несчастное число.
0:20 У этого динозавра мозг с грецкий орехов.
0:23 Ну, как бы было надо, теперь не надо.
0:27 Ничего себе, камень в огород Евгений!
0:30 Мы думали, что мы поняли дизайнеров.
0:32 Это подкаст не о дизайне.
0:34 Мы здесь говорим о дизайне и не о дизайне.
0:41 на связи будет Женя - это один из людей, которые занимались разработкой дизайн-системы, как он сказал, сам отец дизайн-системы Иви и арт-директор по
0:54 дизайну продукта Кристина.
1:00 Слушайте, ну, достаточно много вообще халеваров по поводу дизайн-систем.
1:05 И когда-то я помню, что было такое, что это было очень в новинку для всех.
1:09 Лет там, может быть, 7 назад, все-таки Вау, дизайн системы это что-то на дорогом, это что-то на очень много людей.
1:18 Сейчас это вообще такой
1:21 нормальный тренд, когда ты строишь какую-то крупную компанию или какой-то большой продукт.
1:26 Что такое дизайн-система для дизайнера, вообще?
1:30 Так, ну для дизайнера это свод правил - свод самых актуальных компонентов дизайн-артефактов, которые используются у нас в продукте.
1:40 Ну, вот со своей стороны, могу сказать: что действительно, это как некий свод правил, источник истины, да, и с точки зрения именно организации нашей дизайн-системы Выви
1:52 это в первую очередь не какие-то там готовые компоненты, которые ты берешь и вставляешь в свое веб-приложение.
2:00 То есть мы отдаем данные, мы отдаем Джейсон, для тех, кто понимает на программистском.
2:05 И дальше уже сами разработчики, будь то ас-разработчики, Андроид или Смарт-ТВ, они берут эти данные и превращают их в какой-то свой код.
2:14 То есть они уже на своей стороне преобразуют это в часть своего приложения.
2:19 А если вообще вот для тебя, например, что такое для тебя, как для разработчика, дизайн-системы вообще?
2:24 Для меня, как для разработчика дизайн-системы, дизайн-система - это то, что я разрабатываю.
2:28 Но в первую очередь на самом деле
2:33 вообще дизайн-система - это не только про код, это про коммуникации, потому что мы стоим между дизайнерами и разработчиками на платформах.
2:42 Платформами это как раз я называю веб, смарт-тв, а, андроид, плойку, там всякую эбобокср и так далее.
2:50 И самое главное, когда ты разрабатываешь дизайн-систему, это со всеми договориться.
2:54 Это найти общий язык.
2:55 Вот мы в некоторой степени переводчики с дизайнерского на программистский и наоборот.
3:02 Вот, и это как касается непосредственно коммуникаций, так это касается и преобразования.
3:07 То есть дизайнер рисует картинку в фигме, а у программиста должен получиться код.
3:12 Вот мы посредники на этом этапе.
3:14 Вот ты прям говоришь, как истинный разработчик, дизайнер рисует картинку в фигме.
3:20 да, чуть-чуть укололо.
3:21 Они очень красивую картинку рисуют.
3:24 Когда вы делаете дизайн-систему, вы чувствуете, что вы упрощаете кому-то жизнь, вообще.
3:31 Ну, конечно, мы упрощаем за счет того, что у нас есть база компонентов, на которых строится весь продукт, и мы ее дополняем.
3:39 Таким образом, мы продукт делаем консистентным на всех платформах.
3:42 Да, есть всякие трики и компоненты, которые сложно реализовать.
3:47 Градиенты на теликах, например, но пока что мы успешно с этим живем и все реализуем.
3:53 Ну, по факту, я могу со своей стороны сказать, что и то, и другое на самом деле.
4:00 дизайн-системы, которая запущена на минуточку 6,5 лет назад, она естественно, внедрена во все основные платформы.
4:08 Вот, их было даже больше в какой-то момент.
4:10 То есть, дизайн-система пережила некоторые платформы, которые ее использовали, чтобы вы понимали.
4:14 Вот, и, конечно, за счет того, что у них есть готовые инструменты для получения этих данных из ДС и преобразования их свой код, им проще, когда эти данные приходят из ДС.
4:26 Им нужно писать меньше кода.
4:28 С другой стороны, иногда дизайнерская мысль бурлит более громко и развивается более быстро, чем возможности самой ДС или возможности платформ.
4:39 И тогда может оказаться так, что мы получается делаем некоторые стопор на стороне дизайн-системы, когда нужно занести что-то, чего раньше принципиально не было.
4:50 Ну, я не знаю, более сложные градиенты, предположим, и тут мы начинаем думать и договариваться.
4:56 И здесь мы опять же вспоминаем, что дизайн-система - это про коммуникации.
5:00 То есть мы пытаемся найти тот компромисс, который устроит и дизайнеров, и разработчиков, и позволит в нашу структуру данных это все вписать.
5:07 Ведь нужно всегда помнить, что мы кросс-платформенная дизайн-система, а это означает, что если веб умеет делать классные флексбоксы, градиенты и все такое, это не означает, что 1кс умеет, например, это делать, или, предположим, какой-нибудь старый андроид-телевизор.
5:25 Поэтому мы должны сделать так, что либо какая-то фича, которую мы сделали, она
5:32 не критична, и те платформы, которые не смогут ее обработать, они ее просто пропустят и без нее будет работать красивенько.
5:39 Либо сделать так, чтобы это работало каким-то образом у всех.
5:42 Например, вернемся к нашему градиенту.
5:45 Градиент в каком-то случае мы заменим картинкой, которую они просто поставят, и это будет работать лучше, чем без градиента.
5:52 Слушай, ну вот, допустим, к тебе приходит Кристина, приносит тебе очередной какой-то компонент.
5:57 И как ты вообще определяешь?
5:58 И вообще, есть ли у тебя право на то, чтобы определять, нужен он или не нужен этот компонент.
6:06 Нужен или не нужен, это скорее определяет Кристина или другой дизайнер, который приносит, а мы - рабы, лампы.
6:13 Если нам принесли, значит нужно.
6:16 А вот как это сделать так, чтобы это было с минимальными болями?
6:19 Вот тут мы опять начинаем договариваться.
6:21 Например, Чуйка, которая за это время выработалась, она понимает: вот здесь заплачет смарт-тв.
6:27 И мы такие, а мы можем вот здесь вот так вот сделать?
6:31 Начинается процесс договоров каких-то, да.
6:34 И иногда, когда у нас есть сомнения, мы подключаем разработчиков самих платформ, то есть мы прямо всех заинтересованных в этом вопросе в один трейдик загоняем, и там они между собой варятся и выясняют, как сделать лучше.
6:49 Вот, иногда приходит к решению, которое для меня было неожиданным, например, или я об этом не подумал, или я думал о чем-то вообще противоположном, то есть, мы не гении какие-то, да, но мы просто некоторую определенную интуицию выработали за это время.
7:02 Интересно, а что для себя?
7:04 Не говорю, потому что я не единственный разработчик дизайн-системы.
7:06 Это не то, что какое-то мое великое самомнение.
7:09 У нас несколько человек в команде.
7:11 Да, у нас три потрясающих разработчика в команде.
7:13 А Женя, а что это за компонент такой, где у тебя было решение, на которое ты не рассчитывал.
7:21 Иногда бывает так, что
7:24 просто дизайнер договорился напрямую, без
7:29 не то, что без участия разработчиков ДС, да, но как-то лучше контакт с платформами.
7:36 Мы оказались вот лишними в этой цепочке.
7:39 А погоди, а в этом никто не идеален, а мы стараемся.
7:43 А в этом есть проблема?
7:45 Извините, мы сейчас пять секрет.
7:47 Но это просто статистика.
7:49 На самом деле, что такие кейсы тоже бывают.
7:51 Да, я просто как раз хотела дополнить, что у нас такое бывает, когда дизайнер идет напрямую к разработчику, к к клиентскому, и спрашивают: а вот тут, например, не знаю, блюр какой-нибудь есть, что там градиент, получится так сделать или нет.
8:08 Самый долгий компонент, о котором вам приходилось договариваться?
8:12 Или компонент, о котором дольше всего приходилось договариваться?
8:17 Я расскажу такую историю с самого старта.
8:20 Когда только запустили дизайн-систему в 18-м году мы описали там сначала какие-то совсем мелочи, описали там баттен, кнопку, тогда она была не такая разросшаяся, как уже сейчас, а потом речь стала об инпуте.
8:35 То есть, инпут - это штука, у которого в него можно зафокуситься, у него куда-то улетает плейсхолдер, у него что-то еще происходит.
8:44 на тот момент, по сути, я был единственным разработчиком, но некоторые там помогали со стороны.
8:48 И плюс еще там дизайнеры тоже участвовали в этом активно.
8:51 И у нас была такая шутка: что кто завтра придет последним, тот описывает инпут.
8:55 Потому что настолько сложно и неподъемно было его описать.
8:59 И на минуточку этот инпут до сих пор живет с нами.
9:01 Его ненавидят все, кто к нему как-то к нему прикасался.
9:05 И мы уже несколько раз поднимали вопрос о том, что давайте мы удалим просто инпут и все то же самое нормально опишем в новом компоненте.
9:13 Но это до сих пор никто не сделал, хотя вроде бы даже задачки заводили на это.
9:18 Это с самого старта было.
9:19 Может быть, Кристина сейчас вспомнит какую-то историю из более новых.
9:22 Я могу рассказать про задачу, над которой я лично как дизайнер довольно долго сидела и имплементировала изменения, это скругление.
9:31 Мы в этом году завозили новые скругления в дизайн-систему на платформы и все еще продолжаем.
9:36 И эта задача стояла на мне, и нужно было привести все компоненты отдельно апок, отдельно вебо.
9:43 Вот сейчас у нас на очереди телики - к единому правилу по скруглениям.
9:48 Это довольно большая дока, потому что там очень много компонентов в каждой из платформ.
9:53 Еще нужно, чтобы это было унифицировано по платформам.
9:57 Вот тут именно документация довольно много времени заняла, но в обсуждениях прям все довольно плавно.
10:03 Вообще, сейчас могут сейчас послушать люди, которые не соприкасались никогда с большими продуктами и дизайн-системами, возможно, или это были дизайн-системы такие, ну, типа типа Е-Китав, знаете, просто таких.
10:16 И они такие подумают, кнопку было тяжело описать, инпут было тяжело сделать, и это вообще наверное будет такое: типа что давайте поподробнее расскажем, почему это тяжело, почему такие компоненты тяжело заносить.
10:31 Давайте я попробую сказать про кнопку.
10:35 Чем проще кажется компонент, чем более он базовый, кнопка много где может использоваться, тем обычно больше у него вариаций, больше у него различных вложенных каких-то элементов.
10:46 Больше кучи моментов, которые нужно учесть, чтобы эта кнопка работала везде.
10:52 Даже на старте у нас уже было очень много и размеров, и стилей этой кнопки.
10:57 А во что это разрошло сейчас?
10:59 Ну, скриншот тесты компонента баттен, по-моему, три экрана вниз идут.
11:05 Это те вариации, которые мы потенциально используем.
11:08 То есть не все комбинации цветов и размеров там выведены.
11:14 А кто вообще изначально описывает это все?
11:16 Вот чья задача на самом деле описать полностью компонент?
11:20 Это задача дизайнера.
11:22 Когда дизайнер заканчивает свой дизайн-задачу, у него есть обязательное правило написать компоненты, создать компоненты для дизайн-системы, если их нет.
11:30 И, собственно, здесь мы пишем спецификации, там мы описываем цель, где используется, прикладываем макеты.
11:37 И один из обязательных пунктов - это состояние.
11:39 Ну вот, например, у кнопки есть у нас там 4 состояния: дефолт, ховер, пресс, дизэл.
11:46 И это для каждой платформы.
11:49 Но звучит вроде просто, но есть какие-нибудь сложные компоненты.
11:52 Кнопка еще в этом плане, мне кажется, чуть попроще.
11:55 А какие-то сложно-сочиненные компоненты, где внутри еще есть всякие штуки - это прям сложновато и занимает определенное количество времени, чтобы описать.
12:04 Плюс там, к всяким состояниям, есть еще спецификация по отступам, это тоже важно, по стилям.
12:11 Это делает дизайнер.
12:12 А теперь представь сложно сочиненный компонент, внутри которого кнопка.
12:15 И это все перемножается друг на друга, да?
12:18 Не, но если кнопка-то уже завезена в дизайн-систему, то кажется, что должно быть живибельно.
12:25 А что касается инпута, здесь немножко другой нюанс.
12:28 Дело в том, что вы помните, что у нас кросс-платформенная дизайн-система, и, допустим, интерфейс, ну именно взаимодействие с устройством у телевизора и у телефона и у компьютера - это абсолютно разные способы взаимодействия.
12:43 И нужно сделать так, чтобы
12:46 этот инпут работал и на телевизоре, и на планшете, и там, не знаю, на каком-то
12:53 Венус 10 устройств, предположим, это получается, что нужно описывать в таких терминах, которые будут реализуемы, интерпретируемы на каждой из этих платформ.
13:03 Вот, у телевизор - это пульт, там есть мышабельные, есть татчабельные устройства, и все это у нас лежит в дизайн-системе.
13:12 И зачастую один и тот же компонент используется для всех этих веток разработки.
13:17 Отсюда возникают дополнительные сложности в описании этого всего.
13:20 Ведь мы не для браузера делаем, только мы в браузере предпросмотр делаем.
13:26 Но эта штука должна в итоге работать на телефоне и на телевизоре с пультом.
13:29 Как минимум, два было кейса, а может быть, и больше, как-то мы описали компонент, а потом описали его еще раз, потому что полностью вся реализация абсолютно не устроила никого.
13:39 То есть, мы долго-долго-долго описывали, описывали, описывали.
13:42 Вот и так было, по-моему, с какими-то аватарными блоками.
13:44 То есть, иногда это делает один тот же человек.
13:47 Иногда один человек сделал, ушел в отпуск, второй взял это, посмотрел, блин, и просто заново все сделал.
13:53 В этом месте всегда есть шутка, что хороший компонент, почему бы не сделать два раза.
13:58 Слушайте, а если вообще бывает такое, что разработчики находят какие-то ошибки в дизайне и говорят: а вот вы здесь.
14:12 И это не всегда разработчики дизайн-системы.
14:14 Это может прийти человек с платформы и сказать: ну, во-первых, он может сказать о том, что ошибка в данных дизайн-системы - это то, что к ним ближе.
14:22 А иногда через это он понимает, что ошибка в дизайне, и такой, а так а почему здесь.
14:26 Ну, просто логически пытается мыслить и понять логику дизайнера.
14:30 Иногда понимает и лучше самого дизайнера, который реализовывает экупанию.
14:33 Бывают такие случаи, да.
14:34 Это не букор, просто я понимаю, что
14:39 почему важно, чтобы были люди разных компетенций в команде?
14:42 Потому что они мыслят по-разному.
14:44 Если бы все мыслили одинаково, мы бы не достигли такого хорошего результата.
14:48 Слушайте, но с другой стороны, есть же и вот обратная сторона - есть дизайнеры, которые смотрят на какие-нибудь платформы и говорят: ну почему здесь нельзя это сделать?
14:56 Я же, ну, давай, хоть как-нибудь придумаем и разработчики такие: нет, здесь это невозможно сделать.
15:02 Ну как невозможно, ну не бывает же, ничего невозможного.
15:05 Вот как с этой стороны тогда смотреть на это все?
15:08 Ох, да, бывает такое.
15:10 Последнее время даже немного часто такое бывает.
15:16 Вот я с одной стороны понимаю, что
15:20 тяжело понять работу другого человека.
15:23 Ну, это реально тяжело.
15:24 И ты всегда думаешь, когда что-то делается, ты думаешь, ну, это же точно хоть как-то можно реализовать.
15:30 Ну давай картинкой ставим.
15:31 Ну давай видео туда ставим, ну давай хоть что-нибудь с ВГ-шками я не знаю, какими-нибудь закидаем эту анимацию.
15:37 Как вы с этим живете?
15:39 Я предпочитаю сходить из особенностей платформы, из гайдлайнов.
15:44 Если, например, гайдлайны Андроид-ТВ говорят, что там можно успешно завести анимацию, то почему бы нет?
15:49 Давайте продумаем, как это сделать с меньшей нагрузкой на устройство, на которых она будет.
15:55 Если, например, смарты, да, они не поддерживают градиенты, даже Жень?
16:01 Да, я потом могу подробнее пояснить, почему и как.
16:06 Вот смарты не поддерживают градиенты.
16:08 Здесь мы уже начинаем думать, а что нам сделать, чтобы это внедрить.
16:13 Потому что без градиентов грустно мы, как дизайнеры, хотим, чтобы было все-таки красиво.
16:19 Тогда идем обсуждать именно с разработчиками-клиентами и ищем решения, которые нас всех устроят.
16:26 Если это сильно влияет на производительность устройства, то, конечно, мы идем отключать эти градиенты и мирно плачем в сторонке.
16:35 Но, вообще, это как сказание: путем коммуникаций, договоренностей, знаний, гайдлайнов и особенностей платформ.
16:43 А дизайнеры тоже знают все особенности платформ.
16:46 Ну, это да, да, конечно.
16:47 Они вынуждены их узнать.
16:49 Да, это как бы кор нашей работы.
16:51 Мы не можем просто спроектировать анимацию на телевизорах: градиенты, вскругление, когда есть какие-нибудь старые телики, на которых все еще есть Иви, как продукт, и где это не поддерживается.
17:05 Ну, нужно понимать, как это работает на таких слабых устройствах.
17:09 Поэтому да, мы обращаем на это внимание.
17:13 Да, здесь как раз стоит сказать следующее.
17:16 Приложение, допустим, на том же смарт-ТВ у Иви появилось гораздо раньше, чем у многих конкурентов или аналогичных приложений.
17:24 И отсюда растет проблема поддержки старых устройств.
17:30 на самом деле кажется, что телевизор такой большой, мощный, красивый, и так далее.
17:36 На самом деле начинка техническая, даже у новых топовых телевизоров, она зачастую слабее, чем у телефонов.
17:42 Потому что в основном все ресурсы при проектировании телевизора уходят на большой красивый экран.
17:49 А та начинка техническая, которая внутри стоит условный процессор памяти, видеоускоритель или еще что-то, она зачастую страдает просто от того, что туда денег уже не хватает у разработчика.
18:01 Особенно это касается, конечно, телевизоров старых.
18:04 В нашей стране было несколько моментов, когда у людей стало резко меньше денег, например.
18:10 И они оставляли у себя телевизоры, купленные в предыдущих каких-то периодах, ну, например, в 2014 году, или, например, в каком-нибудь более недавнем году, когда, допустим, вендор ушел из России, и вот телевизор - который был куплен до этого, и остается у человека натолку.
18:28 Ведь он еще висит, он еще светит со стены.
18:30 Ну и вот отсюда и берется поддержка какого-нибудь филипса 2014 года, потому что его купили, а потом после этого доллар, например, подорожал, и новый покупать уже как-то обломно.
18:39 И поскольку мы хотим все еще получать деньги с этого человека, у которого старый Филипс, вот мы делаем так, чтобы наше приложение на этом телевизоре работало и он платил нам подписочку.
18:50 Я вспомнил такую шутку, когда в каком-то фильме было, я уже не помню, затерянный мир или как так он назывался, где были динозавры.
18:59 И он говорит: у этого динозавра, ну а динозавра небольшие же такие были, у этого динозавра мозг с грецкий орех.
19:05 И тут примерно такая же история: большие телеки с маленькими мозгами.
19:11 Для тех, кто думает, что смарт-ТВ это мощные устройства, они мощные только по экрану.
19:15 Все остальное там очень-очень плохое, даже у новых телевизоров, не говоря о старых.
19:20 И то, что говорит Кристина, действительно, это речь именно идет про коммуникацию.
19:26 пытаемся выяснить, что действительно важно и что действительно просаживает производительность.
19:30 То есть, разработчики смарт-тв отлично понимают, как ухудшится производительность, если мы условно просто один блок вложим в другой или мы его не вложим в другой, и будет меньше элементов на странице.
19:42 Там каждая, каждая маленькая штучка, которая там на приоткрытии на вашем суперсовременном ноутбуке вообще ни на что не повлияет, там это все влияет на производительность, причем иногда очень жестко.
19:52 То есть, те, кто оптимизирует приложения под смарт-ТВ, действительно занимаются их оптимизацией, они фигачат все то, что они бы в браузер фигачили в обычной, те отлично понимают, как работает, например, все, как работает Джаваскрипт, какие вещи действительно занимают память, процессор и так далее.
20:10 Поэтому когда на одной стороне стоит дизайнер, которому нужно сделать красиво, а на другой стороне стоит разработчик, который понимает, что вот если в эту кнопку добавить градиент, а в эту не добавить, то в принципе, производительность уже в 4 раза вырастет.
20:25 И он предлагает это дизайнеру.
20:27 Они понимают друг друга и говорит: дизайнер решает: ну, действительно достаточно только вот в этой кнопочке, а здесь можно оставить сплошной цвет, и все, и все договариваются, все счастливы.
20:36 Так, ладно, то, что вы пряники, и вы все там друг друга любите, это я уже понял.
20:40 Что вообще, как вообще принимается решение о том, что тащить, дизайн-систему, а что не тащить?
20:46 У нас недавно было ретро, ну уже давно, очень привязанная, как раз к этому вопросу, потому что мы долгое время не затаскивали компоненты, которые для Б-тестов.
20:57 И как раз на этой ретре мы обсудили, что теперь все.
21:01 Мы затаскиваем компоненты даже для АБ-тестов.
21:04 Да, у нас есть пару АБ-тестиков, для которых мы не затащили, но просто потому, что там сильно большой функционал, и это дороже затаскивать в ДС, чем реализовывать напрямую.
21:16 Но в основном мы теперь даже для бэттестов затаскиваем все в дизайн-систему.
21:21 Это удобно для разработчиков - это удобно даже для нас поддерживать.
21:26 Вопрос для дизайнеров, наверное, в том, что как если АБТ проиграл, как выпилить, не забыть - выпилить.
21:34 Но пока что вроде бы мы справляемся.
21:36 А что-то выпили уже.
21:38 Ну вот я за свою задачку могу рассказать.
21:40 У нас была задача на градиентную кнопку.
21:43 Тоже для телевизоров.
21:45 Да, вот так вот у нас интересно.
21:48 Все градиентами мы хотим сделать.
21:50 Названием секси баттн.
21:54 И мы, в общем, увидели на об-тесте, что этот градиент проиграл.
22:00 Но мы затаскивали кнопку как отдельный вариант в дизайн-систему.
22:03 Ну, ничего, выпилили спокойно.
22:09 еще припомню, что эту кнопку мы затаскивали.
22:11 Вам кажется, что она была одна.
22:12 На самом деле их было три: некоторые из них были с картиночным градиентом, некоторые из них были с картиночной обводкой, потому что были фиксированы и не нефиксированные по ширине варианты, потому что когда ты делаешь картинку и обводки градиент и обводки в виде картинок, ты должен знать точно ширину этой кнопки.
22:30 И вот потом все эти хвосты мы искали и вычищали.
22:36 Ну, слушай, ну обсудили же, что надо затаскивать в дизайн-систему.
22:40 Даже для АБ, поэтому извините.
22:43 Все принимают решение, да?
22:45 По факту, по факту, больших проблем - это не вызвало.
22:48 То есть, именно пришли дизайнеры и сказали: что, ну, как бы было надо, теперь не надо.
22:52 Мы такие, есть, выпиливаем.
22:58 Для нашей команды заведение компонентов именно в дизайн-систему это правда сейчас важно, потому что у нас есть уй-кит, который мы стараемся поддерживать дизайнерами, но он сильно большой и поток задач довольно большой, что не всегда он в актуальном состоянии.
23:12 Поэтому важно, чтобы хотя бы что-то было в актуальном состоянии.
23:16 И это как раз-таки наша дизайн-система.
23:19 Скажем по-другому: дизайнеры не справляются себе сделать нормальный ЮА-кит и смотрят на то, что мы сделали.
23:24 Ничего себе, камень в огород Евгений!
23:29 Просто перевел на человечка.
23:32 У нас среду планирование, готовь виллы.
23:35 Фигма постоянно нам преподносит какие-то обновления.
23:41 И я, как человек, который в фигме бываю только вьюером, потому что я сейчас уже реально там очень долго не заходил, чтобы что-то делать ручками.
23:53 И я понимаю, что когда я начинаю даже там по старой своей схеме какие-то компоненты создавать, я такой, ого, ничего себе, что-то появилось.
24:02 Смотрю, какие-то штучки, какие-то, я такой: так, все, я в это, ну, я в это не полезу.
24:08 Дизайнеры сейчас наверняка переделывают компоненты под новые какие-то фишки и так далее.
24:15 Ну, наверняка это сильно.
24:17 Мы конкретно, ну, нет, мы что-то стараемся на какие-то новые обновления переводить, но, например, вот у нас там ничего пока нет на токенах, мы к этому только идем.
24:30 Так как продукт большой, у нас там много задач своих дизайнерских, и вот эта внутренняя такая продуктовая активность, на которую мы стараемся выделять время.
24:40 И я надеюсь, что как раз вот скоро мы там на токены переведем скругление, какие-то опаси.
24:46 Если говорить вообще про версионность, как это происходит?
24:52 Ну, допустим, компонента какого-то.
24:54 То есть, вот была одна версия, и вы сделали обновление, что-то улучшили.
25:02 У нас есть отдельная страница для компонентов - самых актуальных, которые мы поддерживаем.
25:07 Есть отдельные страницы по каждому из компонентов для спецификаций.
25:11 И там можно увидеть как раз-таки эту версионность.
25:13 То есть, например, у нас есть какая-то кнопка или постер, и можно увидеть все стадии развития этого постера.
25:20 Это хранится, как раз там, это не на компонентах, потому что компоненты мы меняем и тут просто бессмысленно держать это в компонентах.
25:29 Но вот в таких спецификациях библиотечных у нас есть оно.
25:33 А были какие-то большие обновления, где нужно было очень много всего заменить.
25:37 Ну вот скругление - это как раз оно.
25:40 Но вы еще не до конца это все сделали.
25:42 У нас полностью обновлены скругления на ап-веб.
25:44 И вот сейчас мы стараемся урывками, дизайнерами скруглять СТБ еще.
25:53 То есть у нас АП-платформа - это приложение, оно обновлено на скругление.
25:57 А апки, вы имеете в виду, те, которые на мобилках.
26:02 Веб тоже оно обновлено.
26:03 Вот остались телеки.
26:04 На них пока вот стараемся выкроить немножко времени.
26:08 Но они уже достаточно хорошо обновлены, там прям минимальный тюнинг будет.
26:13 Ну и в общем, вот у нас скругление.
26:15 Это была достаточно большая дока.
26:17 Она была отдельно от всего кита, потому что мы вот эту версионность в радиусах никак не поддерживали.
26:24 Но вот в этой доке мы там до-после прикладываем, описываем ту же самую спеку, только с правилами для скруглений.
26:31 Есть такой мем - когда ты надизанил, а мне теперь кодит.
26:35 Ну, как раз продолжать тему со скруглениями, когда мы начинали дизайн-систему, да, мы думали, что мы поняли дизайнеров и что мы те правила, которые у них в голове заложили куда-то в наши какие-то скрытые переменные и так далее.
26:51 А потом выясняется, когда они начинают менять, что все это, что бы о них думали, оказалось неверным в корне.
26:58 И в итоге у нас были какие-то, как раз, на нашей стороне токены, которые описывали бы разные варианты скругления.
27:06 И в момент, когда эти скругления начали меняться, вы поняли, что эти токены проще выпилить просто из-за ходкодить те значения, которые сказали дизайнеры.
27:14 Отсюда, конечно, наброс, что дизайнеры, пожалуйста, рассказывайте то, что у вас в голове, ту общую картину, которую вы задумали, прекрасную, чтобы мы могли ее у себя отразить.
27:25 И потом, когда она у вас начнет меняться, какими-то тюнится,, да мы у себя в одном месте, а не в 60-ти поменяли это несчастное число.
27:34 Потому что иначе получается странно.
27:36 То есть, как бы, ну, когда мы в прошлый раз заносили те же скругления, например, ну, вроде как предполагалось, что у постеров такие-то скругления, у баров там такие-то скругления, там у каких-нибудь там аватаров такие-то скругления.
27:47 Мы так их назвали: постер, бар и аватар.
27:49 И тут, как бы, почему-то все стало совсем по-другому.
27:53 И зависит от чего-то другого стало.
27:55 Может быть, тогда мы правильно угадали, а потом просто веяния поменялись.
27:58 А может быть, мы изначально неправильно поняли систему.
28:01 Ну, что, как бы, наша задача сделать.
28:06 А ну и как бы желательно не поссориться по дороге.
28:09 Так что мы стараемся понять друг друга, услышать, это важно.
28:13 Слушай, ну вот недавно мы завели виды состояний.
28:18 Насколько это было неболезненно для вас.
28:22 Это был эпик фейл для нас.
28:25 Давай введем в контекст, что такое виды состояний.
28:31 Давай я со своей стороны, ты со своей расскажешь.
28:33 Значит, ну, полгода назад, мне кажется, может быть, чуть больше, один из наших дизайнеров, Аня, создала докус видами состояний для унификации всех состояний по продукту.
28:45 То есть, там, постеры, кнопки, какие-то большие сущности.
28:49 Они все подчинялись определенному правилу.
28:52 И мы на своей стороне придумали для них нейминг, описали четкие правила, как что меняется по ховерам, прессам, и пошли с этим к Жене и команде Жене.
29:03 И дело в том, что в эти состояния входят различные вещи.
29:07 Например, скейт, насколько увеличивается там компонент при нажатии, как у нее меняется там фоновый цвет, какая рамочка у него появляется.
29:15 И вот эти все вещи входят в именно параметры, которые меняются при наведении, нажатии на элемент и так далее.
29:23 То есть от состояния в зависимости.
29:25 Получается, что мы попытались в техническую платформу нашей ДС вложить эти знания так, как поняли.
29:33 Но здесь произошло несколько без коммуникаций, скажем так.
29:38 Во-первых, оказалось так, что
29:42 когда задумал это один человек, а потом провел через дизайнер и попытался донести другому человеку, они могли где-то потерять какую-то информацию, глухой телефон случился.
29:53 И в итоге оказалось так, что я думал одно: дизайнер реализовали другое.
29:58 Человек, который в ДС разрабатывал, третьим образом реализовал.
30:03 И когда я увидел, что произошло, схватился за голову.
30:06 Мы долго-долго пытались это все спасти, и в итоге пришли к тому, что проще это просто выпереть.
30:10 Это будет дешевле всего.
30:11 Хотя мы потратили кучу времени, кучу ресурсов, кучу копий поломали.
30:16 И там было, с одной стороны,
30:20 идеологическое непонимание: что, например, я приведу такой пример: допустим, у нас часто какие-то компоненты при наведении, допустим, могут светлеть, а при нажатии темнеть.
30:31 То есть, лайт и даркен, допустим, происходить.
30:36 дизайнеры считали, что дизайнеры, не программисты, считали, что лайт и даркен - это функция, в которую передается исходный цвет, и любой из них - лайтеница и даркиница.
30:45 Будь то красный или фиолетовый цвет, стартовый.
30:47 То есть просто он потемнеет.
30:49 Красный, потемнеет фиолетовый.
30:51 А разработчики это поняли так, что ну здесь же нарисован фиолетовый, значит, мы только с фиолетовым работаем, никаких параметров эта функция не принимает.
31:01 И вот несколько вот таких вот моментов случилось неожиданных абсолютно, и которые ввиду
31:07 технического несовершенства, скажем так, именно кодовой базы, да, оказалось очень сложно реализовать, так как это было бы всем удобно.
31:17 И в итоге оказалось так, что эти вещи в Ките сейчас остались, а в ДС их, ну, скажем так, мы завели задачу на то, чтобы их выпилить, но, по-моему, до сих пор не выпилили.
31:28 То есть в тех местах, куда они были впилены, они до сих пор держатся, открою страшную тайну.
31:32 Но вообще они, как бы, под выпиливание, потому что это возможно на каком-то новом витке осознания, и на более совершенной, скажем так, кодовой базе мы сможем это занести по-человечески.
31:43 Пока что это действительно был блинный отказ.
31:48 Вы говорили, кстати, про нейминг кнопки секси баттн, да, вы ее назвали?
31:54 Ну, это наше внутреннее название этой прекрасной кнопки.
31:57 Мне вообще нравится все весь этот креатив, который строится вокруг дизайн-систем.
32:02 И вот мы знаем много примеров, как российские компании, да и не только российские компании называют свои дизайн-системы ласково.
32:10 Что-то может быть, они там креативят из-за цвета бренда или еще как-то.
32:14 В общем, много есть всяких вариаций.
32:18 У вас есть название какой-то дизайн-системы или какие-то названия, которые вы используете?
32:22 Наша дизайн-система называется Небуло.
32:29 Ну, у нас очень много внутри чего называется по героям Марвел.
32:37 Подождите, не был такой тренд.
32:40 При большей западоориентированности.
32:42 А сейчас мы называем Нестор, Рублев и прочие такие.
32:48 Вот видишь, ты упустила современное вейние в нейминге..
32:52 Вот Знается, теперь мы называем нитничто исконно-русским, например.
32:57 Ты подождите, не было?
32:58 Это такая штуковина, которая.
33:03 Это одна из супер злодеек в Марвеле не снимает.
33:06 Она не злодейка, она нормальная.
33:08 Но нет, она не такая уж и злодейка.
33:10 Хорошо, на самом деле ты вот сказал, что каким-то образом обыгрывают там название бренда и так далее.
33:16 Пока мы не придумали это название дизайн-система, его придумали дизайнеры когда-то, тогда - 6,5 лет назад, мне нужно было это как-то назвать.
33:22 И я ее назвал другой суперзлодейкой - то ли из Марвел, то ли из ДС, которую зовут ядовитый плющ, который - авиа.
33:28 То есть, там буквально одна буква отличается - И в конце.
33:31 И потом мне пришлось все переименовывать.
33:34 Авиа - это типа Иви.
33:39 Типа похоже, буковка там одна отличается.
33:42 Ну, про небуло, давай тоже введем в контекст.
33:45 Не было - это одна из супергероинь в Марвел.
33:50 Она была в стражах Галактики, такая синяя женщина.
33:53 Она - сестра Гаморы, вот, значит, такая синяя девушка с мозгом робота.
34:03 Я не знаю, правильно ли я вообще даю пояснений нет, но насколько я помню, да, у нее как раз часть ее - это механизированная штука, и вот это не было.
34:16 И кстати, вот Гаморы, например, тоже у нас есть внутренний сервис.
34:20 Он никак не относится к дизайн-системе.
34:22 То есть, выве, они не знакомы.
34:24 А по сюжету Стражи Галактики, видимо, да, были знакомы.
34:30 мое предположение, что именно
34:33 этого персонажа выбрали дизайнеры, потому что наш фирменный фоновый цвет очень похож на цвет именно
34:42 То есть, вот этот такой синий фиолетовый.
34:47 на самом деле, мне тут хочется сказать слово Варна.
34:51 Вот, и хотим ли мы поговорить по этому поводу?
34:54 Да, давай, расскажи: расскажи, пожалуйста.
34:58 Варна - это город в Болгарии, это мы знаем.
35:03 А, например, наш фирменный красный цвет называется Мадрид, а цвет черный называется Осака, а цвет белый называется София, что опять же город в Болгарии, и так далее.
35:15 Дело в том, что для названия цветов в свое время, еще до появления дизайн-системы, взяли
35:22 статью в Википедии, в которой перечислены древнейшие города на каждом из континентов:
35:32 Короче, очень много этих цветов.
35:34 Александрия - синий цвет, например.
35:38 - Это такой оранжевый морковный какой-то цвет.
35:41 Потому что в какой-то момент оказалось, что мы сталкиваемся регулярно со следующей проблемой.
35:48 Вот нам принесли дизайнеры цветовую гамму, и в ней есть
35:53 Скажем, мы их назвали: ну там Блю-1, Блю 2, Блю-3, Блю 4, и завтра приходит дизайнер и говорит: ага, а вот нам нужен цвет между Блю-3 и Блю-4.
36:04 Мы такие, блин, Блю-3,5?
36:09 А послезавтра приходит другой дизайнер и говорит: хорошо, а теперь они не синие, а фиолетовые или серые.
36:14 И у нас остаются переменные, которые называются Блю1 , и хранят серый цвет.
36:19 В какой-то момент мы такие просто плюнули, не выдержали.
36:22 А давайте мы будем называть все именами индейских племен, рек - вот как Икея подходит к названиям.
36:29 То есть они берут просто как некий список и, из него все шкафы именуют, вот там, не знаю, чем там, горами именуют или не знаю, чем.
36:36 И мы взяли вот этот абстрактный нейминг, концепцию, как раз для того, чтобы этих двух проблем избежать.
36:43 Первое - это воткнуть какой-то новый элемент в ряд, куда он больше не входил.
36:48 А второе - не быть привязанным к значению.
36:51 И отсюда у нас, допустим, появляются где-то герои Мортал Комта, где-то благородные газы, где-то еще что-то есть мы просто абсолютно любой список берем, главные условия, чтобы можно было прийти по какой-то ссылке и получить название нового элемента, как только он понадобился.
37:07 И в какой-то момент это всех стало настолько устраивать и радовать, что даже
37:14 получилось так, что теперь некоторые просят компоненты именовать не бат, а как-нибудь именем индейского племени.
37:24 Это причем очень классно.
37:27 Ну, я здесь могу поделиться: мы полгода назад, или даже год назад, создавали один из внутренних сервисов Уви.
37:33 И там нужно было делать тоже с нуля
37:36 типографику, колористику и задавать им как раз-таки нейминги.
37:40 И мы не смешивали внутренний сервис с основным продуктом с кинотеатром.
37:45 Я спрашиваю у разработчика: слушай, Василь, как мы будем с тобой называть все эти стили?
37:51 Он говорит: ну иди в словарь эльфийских имен, и там вводи, и рандомайзером будем с тобой выбирать.
37:58 И вот так у нас, да, действительно, в еще одном утреннем продукте живут в стиле.
38:03 Ну, такая некий свой такой прикол, фишечка, да.
38:06 Тоже интересно, когда общаешься, особенно еще.
38:09 Это, знаете, можно так разговаривать в дизайн-системе какой-нибудь и среди прочих дизайнеров, ну там не языви, например, и никто вас вообще не будет понимать, почему вы говорите какие-то странные странные имена и разные города.
38:22 И вот такие все понятно.
38:24 Ну да, вот у нас типографики у нас названы именами нимф, например, да там и так далее.
38:29 И сначала у нас, ну, то есть, мы какие-то находили просто рандомные статьи, да, в интернете, а потом я нашел такой прекрасный сайт, называется фэ фнэтензитези Нейнмрейтрс.ком, и там просто миллион всяких источников этих имен.
38:44 И в общем очень рекомендую, если у вас есть такие же странные проблемы, как у нас, велкам.
38:50 Да, кстати, можно сейчас уже использовать даже чер-дп в этом плане.
38:57 На тот момент, когда мы стартовали, этих тем просто еще не было в доступе, да.
39:02 А, у нас у нас был такой, кстати, прикол, когда.
39:06 Ну, то есть у нас же где-то в данных самой дизайн-системы, во внутренних данных метаинформация хранится источник нейминга.
39:14 А тот, кто снаружи заходит, он же не знает, откуда эти имена берутся, если мы специально ему не сказали.
39:18 И у нас был случай, когда разработчик у себя на платформе за хардкодил новые элементы, ему нужно было как-то назвать, и он просто посмотрел и какое-то похожее сам придумал.
39:28 Вот мне кажется, чат-жипти отлично с такой задачей справится.
39:31 Иногда компоненты нужно внедрять очень быстро в дизайн.
39:35 И иногда есть такие задачи, которые требуют моментального просто решения.
39:40 Как это происходит у вас?
39:42 Мы идем к нашим дорогим разработчикам и говорим слезно.
39:46 Жене, Семен, Влад, пожалуйста, нужно за два дня сделать компонент.
39:52 За два дня - это еще по-божески.
39:56 Ну, обычно мы релизимся во вторник, и во вторник утром нам говорят, что в этот релиз должна войти задача, про которую на планировании никто даже не упоминал, что она может появиться.
40:07 Это называется анархо-эджайл.
40:09 Мы вроде бы планируем, а вроде бы в спринг входит не то, чтобы в дел в планируешь.
40:14 Ну, мы стараемся со своей стороны так делать очень редко.
40:18 В основном, если даже планируется что-то архисрочное, мы стараемся предупреждать, хотя бы в начале спринта.
40:24 Хотя бы в начале дня.
40:27 Ребята, перед релизом заплатили.
40:29 Перед релизом, самое то.
40:30 Ну, вот да, у нас есть такие кейсы, когда было, что нужно что-то срочно пофиксить, и ребята, это да.
40:36 Если там было время, они это брали в работу.
40:39 Если мы понимаем перед самым стартом спринта, что будет что-то срочное, мы в процессе написания спек, то мы тоже как бы предупреждаем: говорим: вот можете почитать посмотреть, мы это придем с задачкой,
40:54 нас понимают, что это так оно и есть, и бывают действительно кейсы, когда не могли предугадать, что это возникнет.
41:01 Это, например, это произошло потому, что к ним кто-то прибежал уже в процессе спринта.
41:05 Они сами там очень-очень быстро что-то нарисовали.
41:07 Иногда в этом случае тоже хочу сказать спасибо дизайнерам.
41:12 В тех случаях, когда они говорят: к нам прибежали, мы к вам придем - типа вот сегодня через несколько часов.
41:18 То есть, мы пока сами рисуем, мы пока сами в шоке разгребаем это все.
41:22 И тогда больше шансов, что мы успеем как-то адаптироваться, перераспределить задачи, что-то выкинуть.
41:27 и так далее То есть, у нас очень гибкий подход к спринтам в этом плане.
41:32 И всегда не то, что всегда, но часто бывает возможность как-то просто между даже членами команды что-то перераспределить, что-то отложить временно, вот какую-то выложить, там следующий спринт.
41:43 И не то чтобы это каждый раз такое бывает, но иногда такое действительно бывает.
41:48 И мы стараемся справиться.
41:49 Если мы вдруг не успели в релиз, мы просто делаем промежуточный на следующий день, через два дня.
41:53 Еще как только успеваем сделать, вот, тогда оно, собственно, и приходит.
41:58 А кстати, еще бывает, когда дизайнеры приносят что-то срочное, горящее, а через неделю выясняется, что это никому было не нужно.
42:06 О, да, это вообще, кстати, это такая боль, блин, на самом деле.
42:10 Ну вот, давайте так: несмотря на то, что вот вроде бы, казалось бы, работают люди, они работают зарплату, они работают, у них есть определенные дни и часы, в которые они работают, но когда ты делаешь даже за деньги, даже свои рабочие часы - работу впустую - блин, это вот прям сильно демотивирует.
42:29 Я могу сказать, что на самом деле нет, это смотри, как мыслить.
42:32 Смотри, как подходить.
42:34 Нет, все мысли, все, мы поняли.
42:36 Мы поняли уже, что вы пряня.
42:37 Нет, я хочу выразить свое.
42:39 Если вы меня не остановите.
42:42 По факту, все это идет к некоторой общей цели, даже как это опыт - это то, что ты получаешь, не получив того, что хотел.
42:50 Иногда это действительно помогает задача, которую ты как бы сделал зря, но ты запомнил те нюансы, ты с которыми с ней столкнулся, и ты уже при выполнении следующей задачи учитываешь.
43:02 То есть ты все равно получил что-то неожиданное от этого, и ты можешь это использовать дальше.
43:07 Ну или если мыслить просто философски, ну расстраиваться сильно не будешь.
43:12 Потому что у всех меняются точки зрения.
43:14 Они могут поменяться у продукта, у дизайнера.
43:16 Может что-то неожиданное выяснится - в момент какого-то, там, не знаю, фокус-группы, об итеста, еще что-то, и ну тогда оказывается, любой бы тест - это когда ты что-то одно делаешь зря, а второе не зря.
43:28 И что теперь делать?
43:30 Я понял, вы хотите, чтобы вас схантили, да, после этого подкаста?
43:34 Да я шучу, шучу, ладно.
43:40 мне само деле, я редко вижу разработчиков и дизайнеров, которые достаточно хорошо общаются и дружат.
43:47 Такое есть определенные моментики, да, есть вот даже сердечки полетели, поэтому мне кажется, классно, что у вас получился такой тендем.
43:58 мы до этого чуть-чуть общались, и я вот говорил, что
44:03 дизайн системы выви, это что-то другое.
44:07 Вот как будто бы это что-то другое.
44:09 Мало того, что вы работаете в основном над одним продуктом.
44:13 И еще в такой любви многие позавидуют на самом деле.
44:17 Давайте так, я, наверное, не совру, если скажу, что дизайн-система просто нарисованная фигме, это не дизайн-система, это просто набор каких-то элементов, компонентов и так далее.
44:28 И как будто бы разработка здесь - это одна из важнейших частей - элементов дизайн-системы.
44:37 Какую сопричастность вообще чувствуют разработчики и дизайнеры.
44:42 Как будто дизайн-система лежит.
44:45 Можем разделить это.
44:48 Систему отдадим, собственно, разработчикам, дизайн отдадим дизайнерам.
44:53 Но как будто бы ощущение такое, что дизайн все-таки система принадлежит дизайнерам.
44:59 Но разработчики здесь являются какой-то неотъемлемой частью вообще всего этого.
45:03 Как вы живете, воспринимая этот продукт
45:07 со стороны дизайна и со стороны разработки.
45:11 Ну, я просто сейчас, сейчас 2 секунды договорю: вот ты сейчас говорил, что типа мы руки, мы делаем, мы там руки, ноги, лопаты и так далее.
45:20 А чувствуешь ли ты какую-то сопричастность ко всему, к этому?
45:25 Да, я чувствую сопричастность.
45:26 На самом деле уникальный случай: когда ты говоришь, что 7 лет начали везде появляться дизайн-системы, это было модно там, в тренде и так далее.
45:36 Чаще всего история была такая: их появление: либо разработчики сказали: хватит, это терпеть, мы хотим дизайн-систему, каким-то образом заставили дизайнеров в эту игру играть с ними.
45:49 И дальше от разработчиков произошедшей АДС каким-то образом внедрилась, выжила или не выжила.
45:56 Или дизайнеры сказали, что хватит, терпеть, попытались там как-то в это затащить, разработчиков обманом подкупом или еще как-то, и попытаться в это поиграть.
46:06 Редкие бывают кейсы, когда, а может быть, не редкие, когда бизнес услышал: а вот говорят, что есть такие дизайн-системы.
46:14 И когда их внедряют, то становится круто.
46:16 И дальше они начинают и тем, и другим это пропихивать.
46:19 Вот в нашем случае у нас был абсолютно уникальный кейс, потому что
46:24 дизайнеры и разработчики договорились между собой, что им это надо, пришли с этим к руководству и продали это руководству.
46:31 То есть ко мне, вот тогда еще
46:35 не было никакого отдела разработки дизайн-системы.
46:38 Я как фронт-эндер был.
46:40 Вот ко мне пришел наш тогдашний ардир и сказал: Вот мы хотим такое.
46:45 И потом ко мне пришел еще технир и сказал: Да, мы действительно хотим такое.
46:48 Я такой: блин, а мы реально хотим такое.
46:51 И начали тогда это все запускать, и это - то, что касается истории создания - то есть, это была общая инициатива, что очень круто, и на самом деле отсюда дальше уже растет, что все заинтересованы, и все в этом участвуют.
47:05 И разработчики ДС, и дизайнеры, и разработчики платформенные, которые соприкасаются с дизайн-системой.
47:12 Иногда даже каким-то образом бэкэннеры разоглядывают, к нам еще что-то делают.
47:17 Иногда бывает, что БКН что-то с нашей дизайн-системы забирает и себя как-то отдает, и тут начинаем еще и с ними соприкасаться.
47:23 Вот такие вот удивительные случаи бывают.
47:26 Ну, я от себя скажу, что я, например, как дизайнер не перекладываю все лавры-дизайн-системы на себя, потому что это в корне не так: мы, как дизайнеры, отвечаем за создание компонентов, какое-то описание правил, а уже дальнейшая реализация и передача действительно в клиентскую разработку - это полностью на стороне ребят, и круто, что они с этой задачей справляются хорошо.
47:51 Поэтому здесь такой тандем - очень хороший, у нас есть в компании, и меня это очень радует.
47:58 И ты сказал про то, что типа вот дизайн - это про дизайнеров, а система это про разработку.
48:02 Это на самом деле не так.
48:03 Система в первую очередь тоже в голове у дизайнеров, просто мы пытаемся ее воплотить.
48:07 Мы, естественно, ее облекаем в какую-то кодовую базу, еще что-то.
48:11 А иногда мы еще как-то немножко вторгаемся в дизайн.
48:14 Например, мы сами нарисуем какую-то страничку, идем в дизайнер и говорим: сделайте нормально!
48:18 Говорит, а у вас и так нормально.
48:19 Вы такие ой, ну ладно.
48:22 Хорошо, я вам отдам тогда вот эту черточку между ними.
48:28 Вот, кстати, дизайн-система - это реально черточка, которая передает отсюда.да ту
48:34 Что самое сложное было за время того, когда дизайн-система появилась, и вот до сегодняшних дней, что являлось самым сложным, вообще.
48:45 И давайте - в коммуникациях, в разработке, в внедрении.
48:52 Так, ну, смотрите, я вот, например, вывеви работаю два года, и за два года с чем я столкнулась, могу рассказать.
48:59 Первое - это то, что я, например, не знала особенностей платформ, и ты-то понимаешь на практике.
49:04 И это как раз к вопросу: что вот опыт, он никуда в мусорку не скажу.
49:08 А скажи, можно я тебе переключить, сколько платформ этих нужно знать?
49:12 Ну вот вообще четыре.
49:15 Давайте три: приложения мобильное.
49:19 Потому что все-таки андроид, у них разные особенности.
49:23 индроид, веб и смарты Андроид-ТВ - это как общие телеки СТБ.
49:28 Здесь такая, наверное, большая загвоздка в теликах, если никогда с ними не работал.
49:33 Но ты это познаешь на практике, и тут в целом все ок.
49:37 Для меня вот одна из сложностей была - это погружение.
49:39 Опять же, я не смотрю это как сложность, это больше как такой трики квешен.
49:44 Вот сейчас для меня сложно поддерживать наш Юайкит в таком достойном состоянии, потому что это требует достаточно много времени дизайнера.
49:56 У нас есть наши продуктовые задачи, и вот мы там пытаемся выкроить это время на внутреннюю активность, на прическу, приборку, эти все метлы.
50:06 Чтобы было актуально.
50:07 Чтобы, например, макеты в идеальном моем, например, мире макеты строились на компонентах, все, и они там были с востоянием.
50:16 На автолотах еще, чтобы все было.
50:23 Могу сказать, что не всегда было так.
50:24 И дизайнеры очень большую работу проделали для того, чтобы это было.
50:27 И продолжает ее проделать.
50:29 Я ее вижу, даже я ее вижу.
50:30 Что они видят, я боюсь представить.
50:33 Да, то есть, мы стараемся, правда, медленными шагами, но все же обновлять наш Юакит.
50:38 Это долго, но это очень важно.
50:41 Подживать не только нашу дизайн-систему - не было в актуальном состоянии и действительно, как свод правил, и дизайн артефактов содержать, но и наш кит, который мы, как дизайнеры, юзаем.
50:51 Вот для меня, наверное, это такая вот сейчас, как основная задача нетривиальная задача.
50:57 На которую нужно выделить время.
50:58 Например, вот мы недавно ввели активность у дизайнеров: если дизайнер заводит задачу на дизайн-систему, ему автоматически создается задача на заведение компонентов йойкит.
51:08 Ну, вот у нас у некоторых дизайнеров 10 задач, потому что не успевается все вовремя.
51:14 Но ничего, это разгребается, мы с этим работаем и стараемся тоже прибираться внутри.
51:23 Для меня самое сложное - это невыполняемые обещания.
51:28 Чаще всего это наше обещание, которое мы никак не можем выполнить.
51:32 Или это бывает иногда обещания дизайнеров платформам, которые скреплены нашей кровью, но в итоге почему-то не получается.
51:40 Ну, типа условно, те же самые там смарт-тв разработчики говорят: ну пожалуйста, не делайте вот так, ну вот так вот не делайте, через месяц приходят новые компоненты, в нем конечно же, сделано именно вот так.
51:51 И вот мои внутренние, которые где-то в моей душе сидят, разработчики смарт-то вчинают в этот момент плакать, и потом, когда к настоящим приходят, они начинают не просто плакать, а биться в истерике.
52:03 Но мы же договаривались на прошлом ретро - и на позапрошлом, и на позапозапрошлым, говорят, они.
52:09 Вот, но иногда бывает так, что приходится какие-то договоренности актуализировать или как-то сильнее вбивать кому-то в голову.
52:19 То есть от того, что ты напишешь документацию, ты не обязательно получишь результат в виде того, что все ей будут ей исследовать.
52:27 Но мы стараемся хотя бы, как это, лежать в направлении мечты иногда, если хотя бы так это возможно.
52:35 Вот я, кстати, еще подсвечу одну штуку, которая именно в дизайн-системе - что мне сложно, - ориентироваться и понимать, какие компоненты где используются.
52:44 Мы сейчас это никак не подсвечиваем, но вроде планируем в эту сторону двигаться.
52:49 Вот я, как дизайнер, особенно когда новый дизайнер приходит к нам в команду: не всегда понятно, если не знаешь продукт, где используется, и используется ли оно.
53:00 Хотя мы стараемся поддерживать актуальный пак наших компонентов.
53:04 Но все равно такая штука есть.
53:06 Люди такие пришли из другой компании, такие: так, блю1, блюд, блю 3, так, Варна, София.
53:15 Это ладно, если важно, София.
53:17 А вот у нас есть куча вариаций того же несчастного баттона, и
53:23 70% из них, ну, может быть, не 70%, может быть 20%, мы не знаем, где они используются, используются ли.
53:28 Хотя, казалось бы, вроде бы есть макеты.
53:31 Может оказаться, что этот макет есть.
53:34 Наверное, у дизайнеров, но, например, он не реализован или выпилен уже после какого-то бы теста, или еще что-то.
53:40 И он, и может быть, допустим, реализован в каком-то приложении, но экран, на котором он реализован, никогда не выводится.
53:47 То есть нет такого кейса, когда этот экран пользователь может увидеть.
53:51 И поэтому мы сейчас в несколько этапов идем к тому, чтобы приложение нам предоставляет статистику о том, что на самом деле используется.
54:00 И в этом мегапроекте задействованы и разработчики ДС, и разработчики платформенные, и бэкэндеры, которые хранит эти данные, соответственно, будут.
54:11 Но это в сложном варианте реализации - в простом варианте реализации.
54:15 Например, просто в момент компиляции приложения - там, например, смарт-ТВ, да.
54:22 Они из кода откуда-то берут данные о том, какие компоненты у них вообще есть, и хотя бы списком отдают название этих компонентов.
54:29 Потом окажется, что мы этот компонент не меняем, потому что будет сложно смарт-тв, а смарт-в его даже не внедрили.
54:37 Кстати, ты затронул тему По поводу того, как понять, вообще что дизайн-система работает, как это как вы это понимаете?
54:46 То есть, есть ли какая-то аналитика, которую вы получаете на какой-то постоянной основе?
54:52 Как вы понимаете, что это все работает?
54:54 Если отбросить только об тесты?
54:57 Например, к нам приходят клиентские разработчики при реализации какой-то фичей и спрашивают: есть ли этот компонент в ДС.
55:05 Если его нет, то нужно завести - то есть без компонента не заводят.
55:09 Конечно, мы встречаем случаи при рефакторингах иногда что целая страница не на компонентах, а на хард-коде.
55:18 Создаем компоненты, меняем, и все работает.
55:22 Не, а как вы понимаете, как вы понимаете, что
55:26 именно вот эти скругления они работают, что
55:29 это лучше, чем то, что было раньше, например?
55:33 Так раньше что было хард-код?
55:39 Друктовые метрики, разумеется, есть.
55:41 Этим занимается не дизайн-система и, наверное, даже не дизайнеры.
55:44 Этим занимаются аналитики, которых вывели тоже достаточно.
55:48 Это их хлеб, и естественно, а бытесты, победа того или иного варианта, она не потому, что кто-то подкинул монетку, потому что они изучали статистику на продолжение на протяжении какого-то периода и сказали: вот этот вариант норм, а этот нет.
56:06 А этот мы еще покрутим об тест, потому что мы еще не поняли, норм или нет, но это короче, это не мы делаем.
56:11 Это вы как-то получаете обратно.
56:13 Не работает дизайн-системы для нас на нас только потом в результате прилетает задача выпили второй вариант.
56:21 На вашей стороне это происходит на стороне аналитиков, которые это делают.
56:32 Есть два варианта, по которым можно пойти.
56:34 Можно создать систему самому, можно взять готовое решение какое-то, как происходило это у вас?
56:43 И вот, наверное, Женя был на заре до того, что это все зарождалось.
56:48 Ты не предлагал какие-то готовые решения?
56:50 И почему готовые решения?
56:52 Вот сейчас уже ты, потом ты расскажешь, почему готовые решения, ну, то есть, не могли бы быть актуальными.
56:59 Мне кажется, в твоем вопросе уже заложен ответ, ну ладно.
57:03 Я попробую его обосновать.
57:04 Дело в том, что ДС, который мы запускали, а к ней были такие уникальные технические требования, которые
57:11 просто не было готовых решений, которые позволили их сделать.
57:15 И я не просто не использовал готовые дизайн системы.
57:19 Я старался не использовать готовые библиотеки, какие-то там условно я не использовал реакт, потому что я не знал, подойдет ли нам реакт.
57:26 Вот, то есть, на таком уровне, это сейчас мы уже поняли.
57:29 У нас там новый превьюр на реакте, например, да, потому что мы тоже не только же, он должны отдавать мы должны еще визуал как-то показывать.
57:37 И получается, что он как бы сейчас уже норм и на реакте.
57:41 А на тот момент было вообще непонятно, как это будет работать, как это будет использовать.
57:46 То есть нам пришли и сказали: вот надо так, чтобы это работало на Виз 10 и на Филипсе 14 года, и все это было из одного файлика.
57:55 Мы такие, ну, давайте, это будет джейсон, наверное, все умеют.
58:00 А теперь давайте придумать, как у нас будут эти свойства в джесоне называться: а что умеет Венус, а что умеет Андроид, ТВ, а что и так далее.
58:07 И вот это вот из всех этих нюансов, которые нарастали, получалось, что
58:13 мы не можем взять готовое решение, потому что мы требования узнаем в процессе работы.
58:19 То есть они были непонятны с самого начала на 100%.
58:22 Именно поэтому мы сделали что-то не связанное напрямую с веб-технологиями, универсальное.
58:29 Придумали язык, на котором все могут общаться.
58:33 Я имею в виду формат данных.
58:34 И этот формат данных, кстати, на данный момент устарел, и мы его улучшаем и строим рядом новый формат, который позволит еще лучше, еще автоматизирование, еще быстрее эти все изменения внедрять.
58:47 Это мы тоже поняли в процессе разработки, когда мы на старте были, никто не понимал, как это будет работать.
58:52 А был же ты сказал, что к вам пришли изначально, к вам пришли люди, дизайнеры, продукты, да, по-моему, они сказали о том, что вот мы хотим дизайн-систему.
59:03 Они показывали какие-то примеры, или как они тебе сказали, что вот мы хотим - как вот не знаю, у Япл там не знаю, или у кого-нибудь
59:13 они писали, они писали именно, что они хотят получить в результате а вот как к этому прийти не знал никто и мы это постигали в процессе
59:23 вы были на самом зарех
59:27 прототип этого всего по сути за полторы недели родился.
59:30 И так и работает в продакшении 6,5 лет.
59:37 Да, нет ничего постоянного, очень временного.
59:39 Ну и неплохо заработает.
59:41 Ну Ну да, но конечно конечно, оно не осталось в том виде, котором оно было сделано за первые полторы недели, но некоторые концепции хранятся с тех пор, да, и часть из этих вещей давно пора выпилить и заменить другими, а часть из этих вещей прекрасно, концептуально работает до сих пор.
59:56 Ну, слушай, а вы же смотрите наверняка чужие, чужие,
1:00:01 дизайна системы других компаний.
1:00:03 Ну, бывает, подглядывайте, что там вообще происходит - интересно.
1:00:08 Подглядываем, но не так часто.
1:00:10 Я, например, смотрю, как строятся Юа-киты, потому что для меня более актуальная проблема - это построить Юай-кит, чтобы он был удобен в использовании и для дизайнеров, и для разработчиков.
1:00:23 На каждой, не знаю, конференции разработчиков или просто, когда я в жизни пересекался с человеком, который взаимодействует с дизайн-системой, я всегда начинал расспрашиваете, как у вас работать, с какими платформами, а как вы это отдаете?
1:00:35 И всегда выяснялось, что это что-то абсолютно не похожее на наше.
1:00:39 То есть мы не можем вписаться в эту концепцию, оно не удовлетворяет нашим техническим требованиям.
1:00:46 И я до сих пор не нашел ни одного готового варианта, который бы нам подошел, поэтому мы продолжаем писать свои велосипеды, естественно, используя уже какие-то готовые решения в качестве просто технической реализации, да, но не готовую цельную какую-то вещь, в которой бы просто встала и заработала.
1:01:05 Про готовые решения: Год назад мы создавали внутренний сервис - популярности контента.
1:01:13 И с того времени у нас добавилась еще пара внутренних сервисов, которые мы сейчас в дизайне поддерживаем и разрабатываем с ребятами.
1:01:22 И когда мы их начинали проектировать, у нас встал вопрос, использовать нашу небу или что вообще использовать.
1:01:29 Мы решили тогда, что мы не хотим эти внутренние сервисы пихать в дизайн-систему продукта.
1:01:33 Это должно быть все-таки что-то отдельное.
1:01:36 И тогда вопрос стоял именно в скорости разработки, поэтому мы взяли готовое решение, которое было на рынке - это андизайн.
1:01:43 Мы посидели вместе с разработчиком, поизучали, что там вообще есть, потому что один из внутренних сервисов использует графики, и нам нужно было решение, как раз-таки, которое уже есть с нативной реализацией всего этого.
1:01:57 Ну, это все интересно, конечно, но у нас там есть кастомные компоненты, и вот разработчик Василь, он с большой болью внедрял эти кастомные компоненты в эту систему.
1:02:07 Мне его жаль, но я рада, что они там есть, потому что использовать полностью готовое было не совсем удобно.
1:02:13 Я 100% согласен, что вот смотришь, когда заходишь, допустим, на тот же анд дизайн, смотришь, и ну все есть, все хорошо начинаешь внедрять.
1:02:24 Понимаешь, ну блин, надо вот здесь допереть, вот здесь не нравятся таблицы, вот здесь не нравится, как это отображается.
1:02:32 И мучительно больно.
1:02:33 Но смотреть на красоту, вот как это представляется, и описание - это здорово.
1:02:39 Ну да, в анти есть еще - мне кажется, все даже и не нужно.
1:02:42 Я к,стати, могу сказать, что по поводу подобных решений, во-первых, они часто веб-онли, то есть они не подходят для нативного аса.
1:02:50 Не могу про все сказать, но зачастую это.
1:02:54 А еще иногда и реактор,, например если у тебя ангуляр, то простите.
1:03:02 на мой субъективный взгляд, это выглядит так, как будто бы такие штуки позволяют из готовых кирпичей собрать без дизайнера какой-то дизайн.
1:03:12 А вот если дизайнер есть и у него есть мнение, вот тут начинаются сложности.
1:03:17 Вот тут Василий Флакова.
1:03:19 Слышит классно, кстати, если у дизайнера есть мнение.
1:03:23 Не, ну кстати, вот даже у джунов есть мнение.
1:03:26 Я вот недавно там один практик делали, и они такие, не, ну это фигня какая-то, это вообще дизайн-система, она какая-то не рабочая.
1:03:34 Они помню, что использовали какой-то.
1:03:39 В общем, интересно.
1:03:41 Как думаете, как будет выглядеть дизайн системы в будущем.
1:03:49 Ну, давайте я попробую сказать.
1:03:51 Не могу сказать за все дизайн-системы, но что я вижу для нашей конкретно?
1:03:55 Во-первых, я хочу, чтобы, скажем так, еще сильнее сократился тайм-то маркет.
1:04:02 То есть то, ради чего все затевалось, да, это то, что от идеи через воплощение у дизайнера это все максимально быстро попадало в приложение.
1:04:12 Что для этого нужно сделать?
1:04:13 Нужно сделать так, чтобы было как можно меньше человеческого фактора и человеческой какой-то нудной рутинной работы.
1:04:21 То есть нужно сделать так, чтобы была лучшая техническая интеграция дизайн-системы с одной стороны, с ФИГМ и с другой стороны, с потребителями данных, и мы на самом деле работаем над обеими составляющими.
1:04:36 То есть, если можно импортировать из ФИГмы там только токены, а можно сделать так, чтобы либо из фигмы как-то полуавтоматически импортировать и пытаться компоненты - это сложно.
1:04:47 Многие все, кто начинали, очень сильно мучились.
1:04:49 С другой стороны, можно сделать так, чтобы дизайнеры сами могли вносить небольшие правки в дизайн-систему, минуя
1:04:57 привлечение разработчиков для этого.
1:05:00 Что касается ускорения работы на стороне, на стыке дизайн-системы и платформ, здесь нужно сделать так, чтобы
1:05:10 максимально те данные, которые отдает дизайн системы, они были автоматически интерпретируемы.
1:05:15 То есть, все, что можно без участия человека перегнать, а потом просто проверить результат, мы должны сделать так.
1:05:20 И мы ведем работу в этом тоже направлении.
1:05:23 Поэтому мне кажется, что принципиально мысль дизайн-системы будет та же.
1:05:30 Но это все работать должно быстрее - и с
1:05:34 большей именно автоматизацией,
1:05:38 большим избавлением от рутины.
1:05:40 Потому что мы все ценные специалисты, мы не хотим тратить наши усилия, наше драгоценное время на то, чтобы делать какие-то повторяющиеся операции.
1:05:49 Мы должны творить - вот в этом смысл.
1:05:53 Я с тобой согласна.
1:05:54 Включай, что нам нужно стремиться к автоматизации процессов, и со стороны клиентской разработки
1:06:02 все внесения изменений в дизайн, все внесения изменений были бы автоматическими.
1:06:09 И какая-то ручная работа, например, хард-код - это было бы минимально.
1:06:13 Вот для меня это такой идеальный ключ развития.
1:06:16 Ну и еще к этому, конечно, отдельный превьюер для, например, Андроид-ТВ, где всякие приколюхи летающие могли бы жить.
1:06:25 Вот и наброс, который
1:06:29 Это как-нибудь обязательно появится.
1:06:33 Вот, а на самом деле, есть еще такие пары классных моментов, которые можно докинуть здесь.
1:06:38 Во-первых, вот ты сказал про хард-код, да, надо сделать так, чтобы хард-код был гораздо дороже, чем внесение через ДС.
1:06:45 Просто настолько дешевым было внесение через ДС, что хардкод был тупо не нужен.
1:06:50 Во-вторых, вообще задача разработчиков дизайн-системы - вот сейчас будет супер максимальный вброс, это чтобы они были не нужны, чтобы это все работало просто без них, чтобы они могли там как-то там поддерживать просто работоспособность всей системы, а все остальное могли делать дизайнеры самостоятельно, разработчики платформ и так далее, чтобы это была просто готовая штука, которая обеспечивала все будущие требования с минимальным воздействием специальной команды, которая над этим сейчас трудится.
1:07:20 То есть команда трудится над тем, чтобы быть ненужной, чтобы заняться еще какими-то более инте интеререснойсами, чем они занимаются сейчас.
Комментарии
Войдите, чтобы оставить комментарий.