Это вторая часть статьи про нашу дизайн-систему. Первая часть выходила раньше. В этот раз речь пойдёт о философии нашей работы, взаимодействии с дизайнерами и клиентскими разработчиками; о трудностях, с которыми сталкиваемся, и как их преодолеваем; о том, как мы развиваем нашу ДС. Если мы поддерживаем такую штуку как дизайн-система, важно не забывать, кому и зачем это вообще нужно. Разумеется, дизайн-система важна как единый источник правды о внешнем виде. Поэтому мы поддерживаем её в актуальном состоянии, и если по какой-то причине встречается расхождение между макетом и данными в ДС, по умолчанию права именно ДС. Задача ДС как сервиса — формализовывать идеи дизайнеров и отдавать их платформам. В такой парадигме дизайн-системе нужно обеспечивать удобство и эффективность работы для обеих сторон процесса. И всем в этой схеме важно открыто коммуницировать и уметь договариваться. Мы не только регулярно организуем встречи по актуальным вопросам, но и всячески стимулируем дизайнеров и платформы не стесняясь высказывать свои мысли и идеи, возникающие в процессе работы, будь то описание в стилях компонента какого-то ранее не использовавшегося свойства или дополнение формата отдачи данных. Поэтому почти всегда правильным ответом на вопрос «А мы можем как-то добавить вот это?» будет «Мы можем всё! Давайте обсудим детали». Главное — договориться со всеми заинтересованными, как это должно выглядеть в данных. Например, в новой вариации текстового бейджика для дизайнера принципиально было использовать увеличенное межбуквенное расстояние (letter-spacing), но до этого мы в ДС нигде не описывали подобное. Либо понадобилась стрелочка в ссылке, выравнивающаяся относительно последнего слова в тексте. Либо по наведению на постер нужно его скейлить, причём в одном случае от центра, а в другом от нижнего края. В этом случае мы вбрасываем в чатик дизайн-системы, что есть потребность описать такую-то сущность. В чатике присутствуют и дизайнеры, и платформенные разработчики, они рассказывают свои возможности, предлагают варианты описания, также предлагаем их и мы как дизайн-система. Если кто-то из платформ не участвует в обсуждении, вовлекаем принудительно, чтобы потом ни для кого не было неприятных сюрпризов. Опять же, если какая-то новая фича или изменение нужны одной платформе, обсуждаем идею с другими платформами, а если это затрагивает процессы дизайна, то и с дизайнерами. Таким образом, мы постоянно приучаем дизайнеров и платформенных разработчиков к мысли, что дизайн-система — это не какая-то «данность», с которой нужно смириться и страдать, а инструмент, необходимый в первую очередь для их же удобства. И если каждый будет набрасывать идеи и намечать путь, мы будем постоянно двигаться в нужном направлении. В противном случае дизайн-система вместо инструмента развития рискует превратиться в стопор. Ещё одна важная функция ДС — быть арбитром между дизайном и разработкой. При выработке решений мы следим, чтобы не ущемлялись ни права дизайнеров, ни права какой-то из платформ. По ходу работы мы агрегируем знания об особенностях каждой платформы: возможностях, ограничениях, состоянии дел по внедрению тех или иных фич, текущих проблемах. Эта информация оседает в документации или тикетах-эпиках, в некоторых случаях отражается в наших внутренних тестах, а что-то просто держим в голове и уточняем по необходимости. Когда обслуживаешь нужды большого числа людей из различных отделов, нужно делать это эффективно. В первую очередь тут важна документация, которая поможет получить большую часть ответов самостоятельно. Среди прочего у нас есть автоматически генерируемая документация по компонентам дизайн-системы, которая помогает разработчикам правильно интерпретировать данные из ДС. Документация доступна как в виде HTML, так и в виде машиночитаемого JSON. Так как фронт работ по наполнению и совершенствованию нашей дизайн-системы никогда не пустует, мы стараемся концентрироваться на важных задачах и тратить свои усилия на творческую работу, а не на рутину. Если же от какой-то рутины избавиться пока невозможно, мы стараемся её по максимуму автоматизировать — так у нас появилось автозаполнение доки по компонентам, инструменты для анализа диффов данных, напоминалки ревьюерам, автоматические переходы статусов и т.д. И, разумеется, не стоит выполнять вручную те проверки, с которыми лучше справится автоматика, поэтому валидация графики и данных (как исходных, так и клиентских) у нас включена в тесты. Наша система работает с такой творческой составляющей как дизайн. Поэтому самое плохое, что мы можем сделать — затормозить полёт дизайнерской мысли техническими ограничениями ДС. Если сейчас что-то реализовано одним образом, это не означает, что завтра не понадобится всё переделать совсем по-другому. Мы всегда живём с готовностью к неожиданным изменениям, а также постоянно развиваем процессы и кодовую базу дизайн-системы в сторону большей гибкости. Разумеется, какие-то изменения могут в текущих условиях оказаться более «дорогими» в сравнении с альтернативами. В этом случае мы оглашаем возможные варианты, но выбор остаётся в любом случае за дизайнерами. Также в этом контексте не нужно забывать про ограничения на стороне платформ. Если какая-то из них технически не может реализовать тот или иной визуал, нужно вместе с дизайнерами выработать решение. Чаще всего в таких случаях мы приходим к тому, что платформа будет игнорировать «сложные» для неё свойства, либо мы предоставляем какой-то фолбек, т.е. альтернативный визуал, более простой в реализации, чем основной. Разумеется, по ходу развития нашей дизайн-системы мы регулярно сталкиваемся с различным вызовами и трудностями. Ниже приведём некоторые примеры возникавших недавно проблем и наших решений для них. В предыдущей статье уже отмечалось, что для многих точкой входа в ДС, её основной витриной является именно превьюер. За прошедшее с запуска время мы многократно дорабатывали и шлифовали его функционал, однако на данный момент он всё равно удобен не для всех вариантов использования. Мы выявили потребности разных групп пользователей (разработчиков, дизайнеров, тестировщиков, менеджеров) и на основе этой информации строим новый превьюер рядом со старым. Основным вариантом, вероятнее всего, станет Storybook, но помимо него будут дополнительные «околопревьюерные» инструменты для некоторых специфических юзкейсов. Дизайнеры рисуют в фигме, мы заносим данные в дизайн-систему. Синхронизация этих вселенных происходит вручную, так что возможны какие-то рассогласования. Мы вместе с дизайнерами наметили несколько векторов развития для того, чтобы исправить ситуацию. В первую очередь это единообразный нейминг вариаций компонентов, чтобы прямо из макета можно было понять не только название компонента, но и значения его модификаторов. Далее мы планируем задействовать API фигмы для синхронизации части примитивов (цветов, типографики, возможно также иконок). После этого будем копать в сторону более сложных синхронизаций, например лейаутов компонентов, но это пока вызывает много вопросов и сомнений. Ещё совсем недавно при каждой выгрузке дизайн-системы формировалась огромная масса иконок во всех возможных цветах и форматах, это занимало кучу времени и места (т.к. вся эта масса ещё и версионировалась на продакшене), а с урлами к этим иконками было очень неудобно работать. Мы рассматривали несколько вариантов переработки подсистемы иконок, в итоге остановились на том, чтобы организовать её в виде статического «котла», в который сверху «доливаются» изменённые или добавленные иконки, а основная часть остаётся неизменной. При этом существует прозрачная схема для получения урла к нужной иконке в нужном цвете и формате, а значит, не требуется отдавать полный список урлов. Большинство клиентов уже перешло на прямые запросы к новой подсистеме (Solea), а старую (Painter) мы сохранили лишь как «оболочку»: теперь она фактически ничего не собирает, а лишь отдаёт чужие новые урлы вместо собственных. После перехода оставшихся платформ на Solea мы сможем избавиться от Painter как от рудимента. Формат данных ДС, с которым сейчас работают клиенты, остался практически неизменным с 2018 года. Мы тогда ещё не вполне представляли, как это всё будет работать, поэтому реализация была максимально простой — стилевые свойства каждого компонента или вариации представлены в виде плоского списка, нет явной типизации, перечня состояний и элементов, а значит, сложнее автоматизировать обработку таких данных. Постепенно «сбоку» от этого мы нарастили дополнительный набор данных, который эти недостатки компенсирует, но лишь частично. В течение последнего года мы совместно с платформами разработали новый клиентский «формат мечты», в котором присутствует жёсткая типизация свойств, значения сгруппированы по условиям (например, по вариациям и/или состояниям) и элементам, перечислены явным образом состояния, описана иерархия элементов и отсылки к дочерним компонентам и т.д. Такой формат позволяет лучше автоматизировать обработку данных на стороне платформ, а значит, изменения будут попадать в приложения проще и быстрее. На данный момент часть компонентов описана в новом формате, платформы постепенно «щупают» эти тестовые данные. Тем временем мы реорганизуем систему так, чтобы старый и новый формат генерировались из единого источника, ведь переходный период никто не отменял. Как уже упоминалось в первой части статьи, основная часть дизайн-системы IVI — это данные. Мы пишем их в виде JSON и клиентам отдаём тоже JSON, но нюанс в том, что их фактическое содержимое может отличаться. Наш входной JSON-формат снабжён дополнительными обвесами в виде отсылок, вычислений и т.д. На момент запуска такая реализация была гораздо быстрее, чем искать подходящий готовый инструментарий, к тому же всегда можно было просто написать JSON сразу в финальном виде без каких-либо преобразований. И это всё очень неплохо работало до тех пор, пока число компонентов не превысило первую сотню, но на данный момент мы уже переросли такой подход — пользоваться имеющимся инструментарием стало попросту неудобно. К тому же он не очень подходит для формирования нового клиентского формата — «формата мечты». Поэтому по мере проработки «формата мечты» мы параллельно экспериментировали и со входным форматом данных для ДС. Было несколько реализаций на YAML, TypeScript и неожиданно вполне успешный вариант на LESS (разработчики CSS-препроцессора наверняка и представить не могли, насколько нестандартным образом можно использовать их детище). В итоге мы остановились на одной из реализаций на основе YAML и TypeScript. Именно её мы начали использовать для описания значений, из которых для платформ будет формироваться как «формат мечты», так и — временно — старый клиентский формат. Несмотря на то, что ДС описывает внешний вид компонентов для отрисовки страниц и экранов приложения, логика построения этих экранов зашита частично в ответы API, а частично в код каждого из приложений. Это не позволяет управлять содержимым экранов со стороны продукта так же просто, как это сейчас происходит для стилей компонентов. Поэтому в прошлом году мы начали размышлять над внедрением подхода Server-Driven UI, в рамках которого API отдаёт содержимое экрана в некоем кроссплатформенном формате (если данные ДС сравнивать с CSS, то тут скорее будет уже «HTML» к этому «CSS»). В наших реалиях заход SDUI также помог бы более тесно интегрировать общее API и ДС, т.к. сейчас их знания друг о друге не настолько крепки и надёжны, как иногда требуется. Например, ответ API может ссылаться на название сущности, описанной в дизайн-системе (цвет, иконка, вариация компонента), но при этом не иметь информации, действительно ли такая сущность содержится в ДС. С другой стороны, описание структуры компонента в дизайн-системе может быть более простым, если закладываться на то, что часть этой структуры для конкретного случая просто прилетит в ответе API. Есть несколько внешних реализаций подхода, таких как Flutter, Beagle, Ghost Platform или Screenflow; также у нас были некоторые внутренние наработки по этой теме. Но когда когда речь заходит о кроссплатформенности на таком уровне, очевидным образом появляется масса вопросов о ресурсоёмкости, производительности и надёжности, которые нам только предстоит решить. Поэтому мы пока скорее только «лежим в эту сторону», хотя от идеи полностью не отказываемся. На данный момент не все сущности в приложениях, которые заслуживают быть компонентами, описаны в нашей дизайн-системе, — в т.ч. и потому, что пока занесение туда всего и вся время- и трудозатратны. Однако новый входной и новый клиентский формат, а также интеграция с фигмой, должны существенно облегчить эти процессы. Ну, а в случае захода SDUI повальное занесение компонентов попросту станет неизбежностью. Наша дизайн-система существует не первый год, но постоянно развивается. Мы не только постоянно наполняем её данными, но и совершенствуем инструментарий, форматы данных и другие возможности системы. В таких реалиях критически важно правильно выстроить процессы и коммуникации со всеми заинтересованными сторонами, получать регулярный фидбек и собирать идеи, иначе дизайн-система вместо инструмента развития продукта превратится в обузу. Развиваясь правильным путём, дизайн-система не только не утратит актуальности в ближайшем будущем, но и будет постоянно увеличивать наполнение и охват, а также всё глубже проникать в продуктовые и разработческие процессы компании.