Это вторая часть статьи про нашу дизайн-систему. Первая часть выходила раньше.

В этот раз речь пойдёт о философии нашей работы, взаимодействии с дизайнерами и клиентскими разработчиками; о трудностях, с которыми сталкиваемся, и как их преодолеваем; о том, как мы развиваем нашу ДС.

Философия дизайн-системы

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

ДС как источник истины

Разумеется, дизайн-система важна как единый источник правды о внешнем виде. Поэтому мы поддерживаем её в актуальном состоянии, и если по какой-то причине встречается расхождение между макетом и данными в ДС, по умолчанию права именно ДС.

ДС как «стыковочный сервис»

Задача ДС как сервиса — формализовывать идеи дизайнеров и отдавать их платформам.

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

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

Поэтому почти всегда правильным ответом на вопрос «А мы можем как-то добавить вот это?» будет «Мы можем всё! Давайте обсудим детали». Главное — договориться со всеми заинтересованными, как это должно выглядеть в данных.

Например, в новой вариации текстового бейджика для дизайнера принципиально было использовать увеличенное межбуквенное расстояние (letter-spacing), но до этого мы в ДС нигде не описывали подобное. Либо понадобилась стрелочка в ссылке, выравнивающаяся относительно последнего слова в тексте. Либо по наведению на постер нужно его скейлить, причём в одном случае от центра, а в другом от нижнего края.

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

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

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

ДС как арбитр

Ещё одна важная функция ДС — быть арбитром между дизайном и разработкой. При выработке решений мы следим, чтобы не ущемлялись ни права дизайнеров, ни права какой-то из платформ.

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

Концентрация на важном

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

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

И, разумеется, не стоит выполнять вручную те проверки, с которыми лучше справится автоматика, поэтому валидация графики и данных (как исходных, так и клиентских) у нас включена в тесты.

Всё будет изменяться

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

Разумеется, какие-то изменения могут в текущих условиях оказаться более «дорогими» в сравнении с альтернативами. В этом случае мы оглашаем возможные варианты, но выбор остаётся в любом случае за дизайнерами.

Также в этом контексте не нужно забывать про ограничения на стороне платформ. Если какая-то из них технически не может реализовать тот или иной визуал, нужно вместе с дизайнерами выработать решение. Чаще всего в таких случаях мы приходим к тому, что платформа будет игнорировать «сложные» для неё свойства, либо мы предоставляем какой-то фолбек, т.е. альтернативный визуал, более простой в реализации, чем основной.

Трудности, решения, перспективы

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

Превьюер, удобный для всех

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

Мы выявили потребности разных групп пользователей (разработчиков, дизайнеров, тестировщиков, менеджеров) и на основе этой информации строим новый превьюер рядом со старым. Основным вариантом, вероятнее всего, станет Storybook, но помимо него будут дополнительные «околопревьюерные» инструменты для некоторых специфических юзкейсов.

Мир дизайна vs мир ДС

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

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

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

Очень. Много. Иконок.

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

Мы рассматривали несколько вариантов переработки подсистемы иконок, в итоге остановились на том, чтобы организовать её в виде статического «котла», в который сверху «доливаются» изменённые или добавленные иконки, а основная часть остаётся неизменной. При этом существует прозрачная схема для получения урла к нужной иконке в нужном цвете и формате, а значит, не требуется отдавать полный список урлов.

Большинство клиентов уже перешло на прямые запросы к новой подсистеме (Solea), а старую (Painter) мы сохранили лишь как «оболочку»: теперь она фактически ничего не собирает, а лишь отдаёт чужие новые урлы вместо собственных. После перехода оставшихся платформ на Solea мы сможем избавиться от Painter как от рудимента.

Клиентский формат

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

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

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

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

Входной формат ДС

Как уже упоминалось в первой части статьи, основная часть дизайн-системы IVI — это данные. Мы пишем их в виде JSON и клиентам отдаём тоже JSON, но нюанс в том, что их фактическое содержимое может отличаться. Наш входной JSON-формат снабжён дополнительными обвесами в виде отсылок, вычислений и т.д.

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

И это всё очень неплохо работало до тех пор, пока число компонентов не превысило первую сотню, но на данный момент мы уже переросли такой подход — пользоваться имеющимся инструментарием стало попросту неудобно. К тому же он не очень подходит для формирования нового клиентского формата — «формата мечты».

Поэтому по мере проработки «формата мечты» мы параллельно экспериментировали и со входным форматом данных для ДС. Было несколько реализаций на YAML, TypeScript и неожиданно вполне успешный вариант на LESS (разработчики CSS-препроцессора наверняка и представить не могли, насколько нестандартным образом можно использовать их детище).

В итоге мы остановились на одной из реализаций на основе YAML и TypeScript. Именно её мы начали использовать для описания значений, из которых для платформ будет формироваться как «формат мечты», так и — временно — старый клиентский формат.

Server-Driven UI

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

Поэтому в прошлом году мы начали размышлять над внедрением подхода Server-Driven UI, в рамках которого API отдаёт содержимое экрана в некоем кроссплатформенном формате (если данные ДС сравнивать с CSS, то тут скорее будет уже «HTML» к этому «CSS»).

В наших реалиях заход SDUI также помог бы более тесно интегрировать общее API и ДС, т.к. сейчас их знания друг о друге не настолько крепки и надёжны, как иногда требуется. Например, ответ API может ссылаться на название сущности, описанной в дизайн-системе (цвет, иконка, вариация компонента), но при этом не иметь информации, действительно ли такая сущность содержится в ДС. С другой стороны, описание структуры компонента в дизайн-системе может быть более простым, если закладываться на то, что часть этой структуры для конкретного случая просто прилетит в ответе API.

Есть несколько внешних реализаций подхода, таких как Flutter, Beagle, Ghost Platform или Screenflow; также у нас были некоторые внутренние наработки по этой теме.

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

Не всё описано в ДС

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

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

Резюмируя

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

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

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