8 800 500 30 94
9:00-19:00 по МСК
9:00-19:00 по МСК
* Нажимая на кнопку, вы даете согласие на обработку своих персональных данных и получение sms-, email-сообщений и сообщений в# мессенджерах от Среды обучения
«Будем только рады, если наши наработки будут задавать тренд»
Юрий Ветров, директор по дизайну Mail.Ru Group (бренд Mail.Ru), автор суперполезного Дайджеста продуктового дизайна и один из составителей каталога российских дизайн-систем, — о том, какие задачи Mail.Ru Group решила с помощью системы Paradigm, почему надо распрощаться с российской профессиональной неуверенностью и как будет меняться продуктовая разработка в ближайшем будущем.
— На недавнем Российском интернет-форуме (РИФе) вы представляли Paradigm, дизайн-систему Mail.Ru. Расскажите про это явление. Насколько я понимаю, это довольно свежая штука.
«Современная дизайн-система — это способ упростить запуск нового дизайна продукта»
— И да, и нет: мы развиваем дизайн-систему на технологическом уровне с 2012 года, первые продукты на ней и публикации появились еще в 2013-м. Летом 2017 года мы открыли наружу живой гайдлайн на сайте design.mail.ru и рассказали о более целостном видении. На РИФ мы планировали анонсировать большое обновление живого гайдлайна, но не успели выкатить его, поэтому я рассказывал словами. Современная дизайн-система — это способ упростить запуск нового дизайна продукта.
В классическом подходе с гайдлайном в PDF или вики получается цепочка «гайдлайн → макет → верстка → реализация». На каждом переходе в ней теряются детали и генерируются баги, так что единственный путь системно улучшить продукты — сократить цепочку до «гайдлайн = макет = верстка → реализация». Это возможно с технологическим фреймворком, где продукты строятся на базе единых компонентов, которые включают в себя визуальный дизайн, логику поведения, структуру данных и т. п. В итоге разработчики не верстают макеты каждый раз, а собирают их из уже сверстанных (и проверенных) блоков.
— Что входит в дизайн-систему?
«Я не устану напоминать про цепочку „гайдлайн → макет → верстка → реализация“ — современная дизайн-система должна упрощать ее целиком»
— Термин «дизайн-система», как и многие другие ставшие внезапно популярными вещи, сейчас сильно девальвировался. Этим словом называют всё что угодно: от библиотеки стандартных элементов в Sketch и странички с нарезанными скриншотами до зрелой платформы, действительно работающей на базе распространяемых компонентов со вшитым дизайном. Мы изначально строили последнее, ведь главный источник правды — это сам продукт, и нужно озаботиться тем, чтобы как задумано работал именно он. Я не устану напоминать про цепочку «гайдлайн → макет → верстка → реализация» — современная дизайн-система должна упрощать ее целиком.
Сам термин появился в середине прошлого века, когда под этим словом понималась система визуальной идентификации бренда, к которой шла красивая печатная книжка (их активно переиздают последние годы) — как раз про айдентику на разных носителях. Но тогда речь шла о физических продуктах и объектах, которые стоят на полке в магазине (или о самой сети магазинов), а мы-то с вами работаем с цифровыми продуктами, где макет ничего не гарантирует и много раз меняется перед запуском на пользователей. Так что работать надо с основным материалом этой среды ― кодом. Мы же в настоящем 2018 году, а не в ретрофутуристичном мультике «Джетсоны».
Что такое дизайн-система в нашем понимании?
Что такое дизайн-система в нашем понимании?
Визуальный язык определяет то, как мы создаем интерфейсы продуктов. Как и в обычном языке, у нас есть алфавит (переменные), слова (элементы интерфейса), предложения (компоненты) и цельные тексты (экраны и продукты). Алфавит неизменен, словарный запас постепенно меняется со временем, а вот предложения и тексты из них создаются всегда разные. Он показан на design.mail.ru/paradigm/.
Единые компоненты на технологическом уровне — единственный источник правды. Дизайн «вшит» в них, сервисы получают и обновляют их из единого репозитория. Продукты под брендом Mail.Ru, которые используют их на практике, — медиапроекты, мобильный веб, часть productivity-сервисов. Они пока доступны только внутри компании, но должны открыться наружу в ближайшем обновлении.
Шаблоны для дизайнерских инструментов — способ быстро показать идею, просто высокоуровневые скетчи. В идеальной ситуации макеты не верстают, а собирают из единых компонентов.
Одна из главных задач в ближайшие годы — связать шаблоны дизайнеров и компоненты в коде. Сейчас они поддерживаются параллельно, что не очень вяжется с идеей «гайдлайн = макет = верстка → реализация». Есть смелые эксперименты вроде React → Sketch от Airbnb, в правильную сторону движется Figma. Пока это всё сырое и слабо применимо в реальной продуктовой работе, но решать проблему нужно.
— На что вы опирались при разработке Paradigm? На опыт иностранных компаний (например, Material Design от Google), или некоторые универсальные принципы юзабилити, или на свое видение, какой должна быть система?
«Многие компании решают похожие задачи: у Material Design подсмотрели идею микро-модуля, у IBM — силу простого визуального языка, у Salesforce — токены»
— Мы озадачились проблемой унификации продуктов давно, еще в 2011—2012 году. На тот момент ни самого понятия «дизайн-система» не было, ни толком примеров ее внедрения. Толчком стала задача обновить 12 мобильных сайтов в 2012 году — вместе с фронтендом нашли технологическое решение для создания единых компонентов. Дальше платформа росла, и на нее переходили новые продукты, а в 2014 году описали целостное видение модульной дизайн-системы.
По ходу дела появлялось все больше примеров других компаний, это помогало решать проблемы масштабирования и в целом делать умнее. Например, у Material Design подсмотрели идею микромодуля (у нас это 4px), у IBM — силу простого визуального языка, у Salesforce — токены (раздаваемые переменные). Но многие компании на рынке решают похожие задачи, так что сами по себе приходят к похожим решениям.
По ходу дела появлялось все больше примеров других компаний, это помогало решать проблемы масштабирования и в целом делать умнее. Например, у Material Design подсмотрели идею микромодуля (у нас это 4px), у IBM — силу простого визуального языка, у Salesforce — токены (раздаваемые переменные). Но многие компании на рынке решают похожие задачи, так что сами по себе приходят к похожим решениям.
— С какой целью вы сделали Paradigm общедоступной?
— Мы решили этим сразу несколько задач:
Сделали инициативу более официальной (домен design.mail.ru в том числе важен). Это помогает при работе с командами внутри нашего подразделения (они больше доверяют дизайн-системе) и соседними (они начали использовать наши наработки). Обнаружили эффект «обратной тяги»: коллеги, читая про Paradigm на Хабре или vc.ru, видят признание инициативы рынком и больше поддерживают ее.
Облегчили работу с внешними командами. Мы мало аутсорсим, но периодически отдаем наружу работы по промосайтам. Гораздо проще объясняться с подрядчиком.
Сделали рывок в качестве живого гайдлайна. Чтобы было не стыдно опубликовать его наружу, пару недель шлифовали и причесывали — и это помогает нам самим.
Повысили собственную мотивацию. Мы долго рассказывали о нашей дизайн-системе и как она работает на живых продуктах, но показать наружу было нечего. За это время куча компаний показала свои наработки, а мы всё сидели внутри. Было тупо обидно :)
— Публично рассказывая и показывая, как все устроено, не боитесь ли вы столкнуться с копированием?
— Мы будем только рады, если наши наработки будут задавать тренд :) Это же профессиональная гордость для любого специалиста. Но вообще мы пока показали наружу не так много, там особо нечего копировать — на сайте Paradigm сейчас скорее основа, а из нее нужно еще собрать продукт. При этом продукты сами по себе разные у большинства компаний, так что и результат сборки будет разный.
— Все больше компаний стали публиковать свои системы. Это тренд?
— В первую очередь жизненная необходимость: в современной разработке продуктов иначе невозможно поддерживать высокую скорость обновлений и запуска новых функций и при этом иметь достойное качество дизайна. Поэтому всё больше компаний начинают делать свои дизайн-системы. Конечно, тема еще и на слуху, поэтому можно вдобавок удачно попиариться. Но на голом пиаре далеко не уедешь: если нет практической необходимости — дизайн-система быстро покроется мхом и на реальные продукты не повлияет.
— Обратила внимание, что, например, «Альфа-банк» предлагает посетителям сайта своей дизайн-системы отправлять вопросы и пожелания. Как думаете, что они рассчитывают получить и насколько это может быть действительно полезно банку?
«Дизайн-система — это, по сути, продукт, а любой продукт выигрывает от улучшений на основе обратной связи»
— Дизайн-система — это, по сути, продукт, а любой продукт выигрывает от улучшений на основе обратной связи. Ребята из «Альфа-банка» молодцы, у них одна из самых крепких дизайн-команд и давний фокус на дизайн-систему. Мы обратную связь тоже начнем принимать со временем, но пока решаем инфраструктурные задачи — то самое обновление, о котором я рассказывал на РИФ.
— Вы ведете профильный сайт DesignSystemsClub, где собираете каталог российских дизайн-систем. У него образовательная цель?
— Да, хотелось показать, что не боги горшки обжигают и начать свою дизайн-систему не так уж страшно и сложно. Любое профессиональное сообщество выигрывает от связности. Я видел эффект, который дала похожая инициатива в Сан-Франциско, — серия митапов вылилась в первую конференцию по дизайн-системам Clarity и мощное международное сообщество. Мы и так общаемся с коллегами по цеху, но если сделать это общение проще для всех заинтересованных, чтобы внедряющие могли получать советы из первых рук от внедривших, — это еще один толчок к развитию отрасли. Делаем клуб с Андреем Сундиевым.
Ну и, конечно, хотелось дать по голове отечественной профессиональной неуверенности, мол, нифига мы не умеем тут в Рунете — нет, крутые внедрения на рынке есть. Они всегда есть там, где есть реальные продуктовые задачи, а у нас тонна крепких продуктовых команд, которые их решают.
Ну и, конечно, хотелось дать по голове отечественной профессиональной неуверенности, мол, нифига мы не умеем тут в Рунете — нет, крутые внедрения на рынке есть. Они всегда есть там, где есть реальные продуктовые задачи, а у нас тонна крепких продуктовых команд, которые их решают.
— Движется ли диджитал-среда к унификации? Есть стандарты продуктов, основанные на психологии, опыте. Значит ли это, что скоро сайты и приложения будут минимально друг от друга отличаться, чтобы быть привычнее для пользователя?
«Продукты стали в разы сложнее, и важно обеспечить высокую скорость их обновления, а это ведёт к упрощению решений, в том числе в дизайне»
— И да, и нет. Да, потому что появляются привычно работающие решения в дизайне, которые проще взять за основу для успеха продукта. Да, потому что компании используют всё больше готовых фреймворков, которые дают определенный стиль из коробки. Да, потому что современный здоровый минимализм в дизайне объективно дешевле создавать, запускать и поддерживать. Да, потому что продукты за последние десятилетия стали в разы сложнее и важно обеспечить высокую скорость работы продуктовых команд по их обновлению, а это ведет к упрощению решений, в том числе в дизайне. Нет, потому что у брендов не исчезла необходимость дифференцироваться и позиционировать себя по-своему. Нет, потому что зрелая дизайн-система как раз позволяет легко делать «темы оформления» и убить двух зайцев одним ударом: и не изобретать велосипед для простых решений, и дать уникальность каждому продукту. Нет, потому что с современными веб-технологиями можно делать такую уйму уникальных вещей, что, если не лениться, можно легко найти свое уникальное лицо.
— Если интерфейс может теперь собираться из готовых, стандартных компонентов, будет ли уменьшаться количество дизайнеров? Или изменятся функции дизайнеров?
— Да, это частый вопрос применительно к дизайн-системам :) На самом деле их идея не убрать дизайнера, а разгрузить от тупой рутинной работы — в сотый раз рисовать один и тот же экран. Требования к качеству и глубине проработки продуктов растут и будут расти дальше, работы меньше не будет. Речь скорее о том, чтобы сместить фокус с производства огромного количества сопроводительных макетов на продуктовую работу: больше думать о потребностях пользователей, как их решает продукт, покрытии более редких сценариев использования и т. п. В здоровом продукте задач всегда больше, чем возможностей их реализовать, так что работы не станет меньше — она станет интереснее и глубже.
Беседовала Полина Весна
Беседовала Полина Весна
К ДРУГИМ МАТЕРИАЛАМ