{"id":13473,"url":"\/distributions\/13473\/click?bit=1&hash=0230b2c9c1795327978777f68c1836f3d5cbb11c39f14294a4fd37999e00f14c","title":"\u041a\u0430\u043a Tele2 \u0441\u0434\u0435\u043b\u0430\u043b \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0430\u0436\u0438 \u043d\u0435\u0438\u0441\u0442\u0440\u0430\u0447\u0435\u043d\u043d\u043e\u0433\u043e \u0442\u0440\u0430\u0444\u0438\u043a\u0430","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}
Дизайн
AGIMA

Ещё одна статья про дизайн-системы (в продуктовом дизайне)

Привет. Меня зовут Костя, и я отвечаю за дизайн в Агиме. И да, я решил написать ещё одну статью по дизайн-системам, в довесок к 7 млн уже существующих. Я думаю, эта статья будет бесполезна для любого, кто сталкивался с ДС вживую. Но с другой стороны, мне регулярно приходится или рассказывать о ДС, или уточнять, что конкретно собеседник имеет в виду, когда говорит «надо нам тут дизайн-систему сделать». А теперь у меня будет статья, написанная почти без сложных слов.

Мы уже записывали короткое видео на эту тему, которое можно послушать, если вам лень читать. Статья ниже — это в общем всё то же самое, но по-другому (и с котиками).

Что такое дизайн-система, на примере котиков и лего

Предположим, вашему ребенку задали задачу: сделать 10 фигурок котиков.

У вас в целом несколько вариантов решения. Например, вы можете взять пластилин, глину, бумагу. И получить 10 совершенно уникальных котиков.

Но можете собрать их из конструктора лего. И сделать либо абсолютно похожих, либо немного отличающихся. Но в целом в любом случае они будут +/- квадратно-прямоугольные и с пупырышкками.

Завод где-то в Китае производит миллионами типовые кубики, шестеренки и моторчики. Совершенная логистика доставляет всё в магазины. Понятные инструкции помогают собирать космические корабли и котят. Всё это и есть дизайн-система. И котики из лего — это котики, сделанные из дизайн-системы.

И вот хорошая новость: в диджитал вы относительно легко можете создать свой заводик по производству кубиков. И начать собирать котиков, нужных конкретно вам. Не надо докупать лего за многие тысячи денег: у вас бесконечное количество копий блоков, потому что это диджитал!

Но и сталкиваетесь с теми же ограничениями: вы можете собрать только таких котиков, которых вам позволит собрать ваш заводик. Вам надо настраивать все бизнес-процессы, писать инструкции и т. д.

Почему об этом пора поговорить: кривая Гартнера и плато просвещения

Мне нравится, как Кривая Гартнера описывает жизненный цикл, наверное, любой технологии.

Лет пять назад сообщество было дико воодушевлено. Из каждого утюга бодро рапортовали о том, что «мы первая компания, которая ввела ДС», «мы первое агентство, которое сделало сайт на ДС». Появился каталог отечественных ДС. Но кажется, при этом мало кто понимал, во что они вляпываются. Иногда у меня даже складывалось впечатление, что это было больше инструмент пиара, чем инструмент снижения издержек на разработку.

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

Сейчас наконец-то на ДС смотрят как на инвестиции в сам продукт, на способ уменьшить издержки и повысить скорость разработки продукта. Это становится обычным рабочим инструментом продуктовой команды, а не хайповой игрушкой для энтузиастов. И об этом инструменте надо знать каждому приличному (и некоторым неприличным) менеджеру и дизайнеру.

Что такое дизайн-система с точки зрения производства

Самое, наверное, важное предложение этой статьи будет сейчас:

Дизайн-система — это UI kit, превращенный в код и связанный с ним, т. е. это система [UI kit] [+] [код].

Т. е. UI kit ≠ дизайн-система!

Сейчас расскажу подробнее, что я имею в виду.

Как вы, конечно, знаете, UI kit — это упорядоченный набор всех элементов вашего диджитал-продукта: кнопки, формы, типографика и т. д.

Обычно, когда говорят «надо сделать UI kit», имеют в виду «дизайнеру надо собрать все элементы в «Фигме» («Скетче»…) в одном месте, показать все состояния, добавить описания, чтобы было всё понятно и можно было сделать нормальную разработку быстро и эффективно».

UI kit для «Комсомольской правды», сделанный в «Фигме»

Реже это же говорят про фронтендеров, имея в виду, что надо сверстать все элементы в HTML, чтобы можно было их переиспользовать.

Или, иначе говоря, картинки надо превратить в код и желательно сложить в специальное хранилище (репозиторий).

Но теперь, если в дизайне вы решите, например, сменить базовый красный цвет на розовый, вам это надо сделать сначала в дизайнерских программах и потом скорректировать код, т. е. синхронизировать UI kit и код.

И вот тут вы можете это всё превратить в систему. Например, можно написать регламент переноса изменений из «Фигмы» в верстку и затем на сайт. Или можно пойти дальше. Так же системно вы можете автоматизировать синхронизацию изменений.

Представьте, что вы обновили логотип в дизайн-программе. Клац-клац, и он уже и на сайте, и в приложении в «Апсторе»…

И вот тут вы можете это всё превратить в систему. Например, можно написать регламент переноса изменений из «Фигмы» в верстку и затем на сайт. Или можно пойти дальше. Так же системно вы можете автоматизировать синхронизацию изменений.

Представьте, что вы обновили логотип в дизайн-программе. Клац-клац, и он уже и на сайте, и в приложении в «Апсторе»…

Как это вы будете делать: автоматически при помощи скрипта или живыми человеками по утвержденному бизнес-процессу, уже не так важно. Важно, что ваш дизайн-процесс систематизирован, т. е. у вас есть дизайн-система.

(Хотя, конечно, в 2022 году делать такую работу руками ну так себе идея.)

Вперед, к светлому будущему!

Ура! Давайте всё синхронизируем, систематизируем, автоматизируем!

К сожалению, пока это только мечта, но кое-что мы уже умеем. И сейчас про это расскажу самыми простыми словами.

Во-первых, самый популярный (и возможно, единственный разумный) подход к строительству дизайн-системы называется «атомарный». Тут всё просто: страница состоит из блоков (организмов), блоки состоят из форм и кнопок (молекул), формы и кнопки состоят из линий, шрифта, цвета (атомов).

Дизайн-токены могут хранить в себе базовые значения (атомы), такие как цвет, радиус скругления кнопки, параметры шрифта и т. д. Эти значения связываются с репозиторием. И теперь, если поменять значение токена, например в «Фигме», оно попадает в репозиторий и затем уже может быть автоматически синхронизировано с сайтом.

Репозитории типа Storybook, Git, NPM и т. д. помогают разработчикам организовать хранение кода и помогают с его интеграцией в различные фреймворки.

Фреймворк — это программная платформа, которая облегчает работу со структурой диджитал-продукта и помогает делать качественную разработку. Думаю, вы слышали что-то про React, Angular, Vue. Вот это оно.

Сверстанный UI kit для АльфаСтрахование в Storybook

Синхронизировали, синхронизировали да не высинхронизировали

К сожалению, не всё можно интегрировать просто и дешево. А кое-что и нельзя.

Например, сейчас, в 2022 году, не существует лёгкого способа синхронизировать компоненты для мобильной разработки. А многие интеграции для веба проще делать руками, чем автоматизировать. И параметрические вариации компонентов тоже тяжело делать (((

Например, у вас есть дизайн кнопки. И технически вы понимаете, как можно автоматически сгенерировать ее для веба, для iOS- и Android-приложения, а также для b2b- и для b2c-сайтов. Тут уменьшим, там конвертируем в rem, а здесь растянем. И вроде написали алгоритм и — пыщь-пыщь, готово… Но в реальности это будет кастомная разработка, которую надо поддерживать при помощи специального человека. А удобного WYSIWYG-интерфейса, с которым разберется любой дизайнер, для этого не существует.

И в реальности проще держать 4 разных дизайн-системы со всем фаршем: токены, репозитории и живые люди для синхронизации не только внутри ДС, но и между ними.

Но в целом всё движется к светлому будущему, когда мы сможем поменять в «Фигме» один шаблон и он автоматически и без проблем применится к работающему сайту и приложению в «Апсторе».

А пока мы карабкаемся на «Склон просвещения» и радуемся, например, тому, что ребята из Яндекса намутили плагин, помогающий компоненты из фреймворка Rеасt внести в «Фигму». Как говорится, маленький шаг для дизайнера, большой шаг для дизайн-систем!

Еще немного дегтя

Я очень люблю дизайн-системы, но у них есть довольно существенные недостатки и особенности:

  • Внедрять дизайн-систему сложно и дорого, особенно на начальном этапе. Вам нужны эксперты (которых пока мало). Ресурсы, чтобы закомпонентить компоненты и зашаблонить шаблоны. Терпение, чтобы всё это внедрить в ваш продукт. И сила воли, чтобы поддерживать системность дальше. В крупных проектах есть иногда даже целая команда «хранителей дизайн-системы». (Хотя я слышал про подход, когда эта функция распределяется между всей командой, даже у крупняков.)
  • Успешно внедрив ДС, через некоторое время вы можете обнаружить, что ваш продукт потерял гибкость: страницы сайта выглядят, как дома в районе панелек. А сделать какую-то необычную фичу трудно, а то и невозможно: пока ты внедришь в ДС новый компонент, пока протестируешь и интегрируешь, уже и не надо вроде бы. Так, ребята там сами наколхозили что-то…
  • Это не всегда дешевле. Да, расходы на дизайн снижаются. Зато появляются работы на поддержание и развитие самой ДС. Т. е. затраты просто переходят в другое подразделение. А еще добавьте затраты на создание инфраструктуры и на ее поддержание…
  • Если вы решили кардинально что-то поменять: навигационную структуру, или пришел совершенно новый брендбук, — есть риск, что проще будет всё выкинуть и начать заново. Ну, это как если бы вы с пластикового лего решили на металлические болты перейти. Всё выбрасываем и строим новый завод.

Всё на самом деле хорошо

Всё же у ДС есть очень крутые преимущества, которые уже сегодня могут продвинуть ваш проект вперед и нанести проекту много пользы.

  • С помощью ДС продуктологи и менеджеры проектов могут сами собирать простые экраны и вводить новые фичи. Скорость поставки нового функционала и проведения экспериментов резко повышается за счет того, что этап дизайна и верстки выкидывается. Нет вот этого «ой, дизайнер так видит, а у фронтендера лапки». Да и сами фронтендеры тратят ресурсы не на скучную верстку таблиц, а на интеграцию калькулятора, например. А это более интеллектуальная работа, которая обычно больше нравится профессионалам.
  • Снижаются расходы на дизайн: если ДС достаточно богатая, то всё ограничивается улучшением и обогащением текущих компонентов. А минорные изменения в дизайне типа корректировки цвета, замены лого или формы кнопок делаются почти мгновенно. «Сделать страницу нового продукта? Берем вот эти 5 блоков, меняем текст и изображения, добавляем ссылку на форму — оп, готово, на прод!»
  • Весть продукт выглядит консистентно. И минорная страница с юридическими документами, и суперконверсионный калькулятор: всё выглядит и работает одинаково. И никто не может своими шаловливыми ручками безнаказанно это испортить. Да, панельки могут выглядеть красиво)

Резюмируя, кому надо дизайн-системы

  • У вас длинный проект, который вы готовы системно развивать.

  • Вам хочется ставить кучу экспериментов, делать последовательные улучшения и планомерно развивать продукт.

  • У вас несколько команд, которые работают над одним продуктом и им нужно поддерживать консистентность.

  • Вы просто любите заводики и котиков.
0
12 комментариев
Написать комментарий...
Пуганный Аноним

"С помощью ДС продуктологи и менеджеры проектов могут сами собирать простые экраны и вводить новые фичи. Скорость поставки нового функционала и проведения экспериментов резко повышается за счет того, что этап дизайна и верстки выкидывается. Нет вот этого «ой, дизайнер так видит, а у фронтендера лапки». Да и сами фронтендеры тратят ресурсы не на скучную верстку таблиц, а на интеграцию калькулятора, например. А это более интеллектуальная работа, которая обычно больше нравится профессионалам."

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

Все потому, что менеджер видит проблему клиента и решает ее в лоб. Например, чтобы сделать определенное действие клиент нажимает на кнопку, открывает форму, там ищет еще одну кнопку, нажимает, открывается форма, где он видит, например, какой-нибудь статус чего-нибудь.
Менеджер решает, что надо добавить еще одну кнопку, которая сразу откроет вторую форму, к той, которая открывает первую форму. И, так как, формально, изначальная страница не имеет связей с той, второй формой, делает это как может - через жопу. Вместо того, чтобы задуматься, что может быть стоит просто приделать уведомление, или вообще сделать страницу с этими статусами и добавить ее в меню, или еще десяток каких-нибудь вариантов, которые менеджер просто не учел в силу того, что они гораздо сложнее, чем просто добавить кнопку. Менеджеры всегда ебашат кучу кнопок по делу и без, а потом клиент должен полгода обучаться, чтобы понимать где какая кнопка находится. Еще есть особый вид менеджеров, которые не до конца разобрались в системе и городят велосипеды, чтобы автоматизировать то, что уже и так есть, надо только спросить.

Расходы всегда растут, когда кто-то лезет не в свое дело. Именно поэтому хороших фуллстеков не существует.

Ответить
Развернуть ветку
Kostya Kisleyko

Сколько боли в вашем коменте...
Почему то сразу представил себе врача травмотолога и его мнение о топорах... «да они только и умеют что руки себе отрубать» =)
::
Но вот наш реальный опыт:
В одном случае мы научили продуктовых ребят собирать страницы из готовых блоков и поводить эксперименты. Лучшие из них команда доводит до ума и раскатывает на весь продукт.
В другом случае мы сделали для маркетосов конструктор лендосов, и они там фигячат свои маркетосные акции, меряют эффективность и при этом ничего не портят на основном еком сайте. Да еще основная команда как то умудряется рулить зоопарком исполнителей аутсорсеров и развивать собственно сам еком.
И оба проекта в своих нишах в лидерах, в том числе благодаря свому системному подходу.
::
Вобщем конечно в ваших словах есть часть правды, но мой опыт, и опыт ребят с которыми я обсуждал ДС говорит что не все так просто.
Конечно есть недостатки у дизайн систем, и предположу что вы хлебнули их по полной, не дойдя до преимуществ.
При нормально подхое к построению процессов, обучению команды, да и дизайну самой дизайн системы, все что вы написали борется достаточно эффективно. Ну и ресурсы кончно надо вкладывать
Косвенно это подтверждает что у каждой крупной конторы с которой я общался есть проекты по созданию и развитию ДС.
(И да, хорошие фулстеки редкость, но они существуют)
::
Удачи вам, надеюсь на вашем пути встретятся нормальные менеджеры

Ответить
Развернуть ветку
Пуганный Аноним

Я не говорил, что менеджеры и продавцы мудаки. Они все хорошие ребята, особенно когда хотят продукт развивать. Но тут как в армии, инициатива должна быть разумной. Собственно, ваш опыт лишь подтверждает мои слова. Менеджеры сидят в своей песочнице, в прод не лезут, иногда придумывают что-то хорошее, а специально обученные люди воплощают это в жизнь. Вариант, когда кто-то мимо разработчика лезет в прод просто неприемлем, а тем более если это не живой человек, а какая-то интеграция из фигмы что-то сама берет.

Что касается самих дизайн систем - я не понимаю зачем они нужны. Да, круто показывать в презентациях, что у нас кнопки синие, а задизейбленные - серые. Но ни одна дизайн система не может учесть варианта чуть сложнее кнопки, выпадающего списка и контекстного меню. В любом реальном продукте нужно всегда придумать список, где у каждого элемента будет выпадающий список, а для элементов какого-то конкретного типа еще и кнопка внутри элемента, описание второй строкой, счетчик рядом с дропдауном, подцветка недавно редактированного элемента, но только вот в этом списке. А еще возможность перетаскивать элементы в этом списке и свой особенный вид для драгндропа. Все это учесть заранее крайне сложно, а унифицировать так, чтобы в каждом конкретном случае использовать общие, заранее придуманные компоненты - попросту невозможно. Код таких элементов разнесет от миллиона условий и сотни настроек конфигураций. Достаточно посмотреть в документацию к кнопке в каком-нибудь Ext JS https://docs.sencha.com/extjs/6.2.0/classic/Ext.button.Button.html#configs где придуман почти любой вариант. Но использовать такую кнопку в проекте как-то не очень хочется. Имеем тыщу человекочасов, потраченных на дизайн систему и продукт, дизайн которого релевантен с этой дизайн системой примерно неделю, после того, как ее утвердили.

Ответить
Развернуть ветку
Kostya Kisleyko

Ну случаи разные бывают, и потребности тоже. например какая нибудь ERP для банка - у нее вполне понятные функции ограниченные их бизнес процессами. Условно, если надо ввести еще одну ветку по документообороту, то не надо особо замороченных компонентов использовать и собрать прототип а то и интрефейс для всегй ветки процесса может человек средней квалификации.
::
Вот полуреальный пример: страховому агенту в личном кабинете надо отрабатывать новое требование регулятора, а именно загружать новую справку. Для этого нужен какой то алерт, тектовый блоки и кнопка загрузки файла. Не нужно городить космический корабль чтобы сделать эту фичу. Менеджер легко может собрать страницу и привлечь разработчика только чтобы разобраться куда складывать файлы.
Та ДС которую мы делаем для Альфастраха (есть в статье скрин), к примеру, легко позволяет это сделать.
::
Ну и ещё раз, случаи и потребности бывают разные, не всем надо новый сейлзфорс собирать, комуто надо просто инструмент сборки лендосов, а комуто — делать десятки однотипных форм для эйчар запросов.
Да и инструменты развиваются, сейчас ДС на детском уровне в основном. Но профит от них ребята на рынке чуствуют уже сейчас

Ответить
Развернуть ветку
Пуганный Аноним

Насколько я понял пример со страхованием - это вопрос конфигурирования системы, нужно просто добавить поле на форму. Это должны делать админы системы, но точно не разработчики и уж тем более не менеджеры.

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

Но дизайн система - это вовсе не зло, дизайнеры балуются, иногда чет прикольное придумывают, руководство смотрит красивые картинки, радуется этой параллельной вселенной, где все вроде как упорядочено и платят деньги. Я, как дизайнер интерфейсов несказанно счастлив такому положению дел. Настоящее зло - это попытки обойти разработчиков и просто положить сгенерированные чем-то файлы в репозиторий. Экономя два часа джун-разработчика мы закладываем в систему существенный долг по рефакторингу всего этого говна. И вот там уже бездонная пропасть из тысяч часов, только не джунов, а дорогих синьоров. Но это же потом будет. А пока ребята чувствуют профит.

Ответить
Развернуть ветку
Ishxan Aslanyan

Спасибо за статью!

Ответить
Развернуть ветку
Nanon Trit

Интересно!!🌿

Ответить
Развернуть ветку
Евгений

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Kostya Kisleyko

мне кажется вы зря ограничиваете определение дизайнерами

Ответить
Развернуть ветку
Kate Pantiukhina

Спасибо большое за статью! Очень кстати нашлась <3

Ответить
Развернуть ветку
Алексей Осипенко

Статья отличная, спасибо)
Мир цикличен. А дизайн так или иначе возвращается к конструкторам и блокам) Унификация - это же нормально и логично для масштабирования и развития систем и не только диджитал.
Правда сейчас рассказывают про молекулы, атомы, организмы ( года 3 как)... Которые переводят в токены для html, css, js фреймворков (1,5 года назад услышал первый раз)
Но по сути переизобретаются те же фронтенд конструкторы, коих сейчас легион и они развиваются семимильными шагами.Да и многие из них уже имеют так же возможность простой верстки из фигмы.
Забавно в этой истории смотреть на дезигнеров которые "осуждают" фуллстаков на конструкторах, но надувая щеки с искренней радостью рассказывают как с помощью токенов они могут сами на проде кнопки менять без версталы, прям магия))

Ответить
Развернуть ветку
Kostya Kisleyko

ДС - это не инновация, это эволюция. Берем то что работает и делаем это лучше, системнее, технологичнее и вот это все. Конструкторы тоже можно назвать ДС (а можно и не называть).
Ну а хейтеры и фанаты — это ж прекрасно. Разные мнения двигают прогресс вперед

Ответить
Развернуть ветку
Читать все 12 комментариев
null