Пролог
В 2024 году на рынке существует довольно большое количество экосистем цифровых продуктов: как для B2C-сегмента, так и для B2B. И если просто в поисковике вбить «как создать экосистему», вы получите кучу статей от аналитиков, продактов, бизнеса. Однако, если попробовать сформулировать запрос с конкретикой по дизайну (например, «как создать дизайн для экосистемы продуктов»), мы получаем классную выдачу, в которой экосистемой называют дизайн-систему. И это ужасная подмена понятий, так как дизайн-система является всего лишь одним (хоть и очень значимым) из ингредиентов вкуснейшего экосистемного дизайн-борща.
Когда у нас появилась задача по созданию собственной экосистемы, встал резонный вопрос: «А что мы должны поменять в своих процессах и наборе инструментов, чтобы сказка стала явью?» И ответ найти оказалось весьма непросто. Релевантные знания находятся в умах единиц, которые в свою очередь не очень охотно транслируют их в общее инфополе.
Поэтому у меня возникла идея: а почему бы не поделиться нашим опытом, набитыми шишками, принципами работы и идеями, которые мы хотим реализовать, чтобы привлечь внимание большего количества людей к этому вопросу и запустить дискуссию? Ведь только дурак учится исключительно на своих ошибках, а правильный подход — изучить опыт друг друга, чтобы учесть его в своей работе в определённом контексте.
Но прежде, чем разобрать наши процессы, копнём в теорию, которая очень важна для понимания происходящего в целом и всех предпосылок для изменений в нашей работе в частности.
🤔 Дисклеймер
Не претендую на «истину в последней инстанции». Очевидно, что все инструменты работают строго в определённых условиях. Поэтому буду крайне признателен, если закидаете нас комментариями, ссылками, «пруфами», что в дальнейшем позволит всем нам стать лучше.
Глава 1. Что такое «экосистема»?
Идём на самый достоверный источник во Вселенной — Википедию — и вытаскиваем оттуда определение. Исходное понятие «экологическая система» (основная природная единица на поверхности Земли) нас не особо интересует, поэтому опираться будем на другое — «бизнес-экосистема».
☝🏻 Бизнес-экосистема — набор собственных или партнерских сервисов, объединённых вокруг одной компании. Бизнес-экосистема может быть сосредоточена вокруг одной сферы жизни клиента или проникать сразу в несколько из них
В 1993 некий Джеймс Мур в своей публикации решил рассмотреть экономическую деятельность как аналог экосистемы, где покупатели и производство дополняют друг друга и совместно эволюционируют в том направлении, которое задают компании-лидеры экосистемы. То есть он просто применил метафору из биологического мира к экономическому. Интересным так же является его сравнение новых возникающих продуктов/бизнесов непосредственно с конкуренцией за место в экологической нише среди живых организмов.
Из этого можно извлечь весьма прикольный вывод, что продукты конкретного бизнеса должны существовать в чётком симбиозе между собой и клиентами, чтобы выигрывать конкуренцию и не пускать продукты других компаний в свою «среду обитания».
Я же формулирую для себя понятие «экосистема» следующим образом — это среда, которая построена таким образом, чтобы многокомпонентный бизнес-лидер эволюционировал вместе с потребителями за счёт создания максимально оптимальных условий для обеих сторон при учёте появления новых конкурентов. Тут важно отметить, что слово «многокомпонентный» использовано не случайно — любой успешный, но узкозаточенный бизнес рано или поздно задумывается о выходе в новые целевые аудитории за счёт всё новых и новых предложений (продуктов), чтобы занять больше места в бизнес-нише.
При этом важно понимать, что в любой чётко выстроенной и гибкой экосистеме новому игроку будет крайне трудно существовать. Экосистема становится стандартом, образом жизни, и даже если один из компонентов потенциально может выпадать, потребители экосистемы не будут из неё уходить, потому что большая часть других их процессов завязана на неё. Допустим, ты пользовался Apple Music, но вдруг у тебя появился весь такой прикольный Spotify. Да, в нём есть много классного, но из-за удобства нахождения в единой экосистеме ты трижды подумаешь, платить ли тебе за новую подписку, даже если она стоит 1₽.
В итоге мы имеем интересную историю, когда есть бизнес-гиганты, которые за счёт «подсаживания» клиентов «на иглу» своих продуктов создают лояльную аудиторию, питающуюся даже не самыми «свежими» продуктами. Ушёл ли бы ты целиком из экосистемы Apple из-за перехода с Apple Music на Spotify? Очень вряд ли. Уйти из экосистемы всегда крайне трудно, так как в ней решается очень много твоих задач.
В современном конкурентном мире каждый бизнес хочет создать свою экосистему, чтобы всё больше клиентов лояльной аудитории пользовались основными продуктами. Зачастую новые продукты не приносят прямой прибыли, а имеют менее очевидный эффект — приводят новых пользователей в уже существующие в рамках экосистемы. Да и если в рамках экосистемы вдруг появляется новый продукт, который аналогичен по функциональности локальному конкуренту, то клиенты начинают довольно бодро уходить от этого конкурента именно за счёт того, что они уже работают с другими компонентами экосистемы. Или компания-держатель экосистемы просто выкупает конкурента (та же история с mail.ru group, которые в итоге даже переименовались в VK).
Из всего вышесказанного следует, что тренд на экосистемы абсолютно обоснован не только с точки зрения ведения бизнеса, но и со стороны живой природы в принципе — конкуренция и желание завоевать «место под солнцем» являются основными драйверами эволюции всего живого. И если мы чётко понимаем, что экосистема нужна, то надо разобраться, как вообще её создавать, какие принципы в неё закладываются, и как это влияет на дизайн.
Глава 2. Принципы экосистемы
🤔 Как же всё-таки странно писать в статьях блоки теоретической информации, когда под рукой есть ChatGPT, у которого можно всё спросить…
Ну, собственно, я так и подумал и закинул в него вопрос: «Какие принципы лежат в основе создания экосистемы продуктов». Потом несколько раз потыкал «а ещё»…
Принципов очень много. Плюс ко всему, они отличаются в зависимости от контекста применения. Я выбрал 5 основных: из 20 предложенных ChatGPT 4 сопоставил наиболее значимые с моей точкой зрения и исключил те, которые относятся к любому продукту, а не только к экосистеме:
1️⃣ Пользователь в центре внимания
Исключил все, кроме одного. Этот пункт даже раскрывать особо не нужно, так как он применим и к любому одиночному продукту, а не только к экосистеме. Мы всегда говорим про потребности пользователя, так как только решение его конкретных задач позволяет продукту оставаться на плаву. Однако, важно написать этот принцип первым, потому что это БАЗА.
2️⃣ Общая миссия, интеграция и совместимость
Все элементы экосистемы должны соответствовать общей миссии, видению и ценностям бренда. Пользовательский опыт между продуктами экосистемы должен быть последователен и консистентен, чтобы обеспечить лёгкость в использовании и переходе из одного продукта в другой. Помимо понятной истории с интерфейсами тут скрыта и более глубокая технологическая интеграция (например, обмен данными между компонентами экосистемы). На этом начинает строиться доверие пользователей и укрепляется их лояльность к бренду.
3️⃣ Усиление ценности
Компоненты экосистемы должны дополнительно усиливать ценность других её компонентов, создавая уникальное ценностное предложение, которое никак невозможно получить при использовании продуктов вне экосистемы. Этот пункт частично я раскрывал выше — такая модель позволяет удерживать пользователей внутри экосистемы, а интеграция и совместимость непосредственно способствуют этому.
4️⃣ Устойчивость, расширяемость, инновации и адаптация
Соединил кучу пунктов, так как итоговый смысл один — экосистема даже в живом мире всегда выживает исключительно за счёт умения адаптироваться и принимать эволюционные изменения. В свою очередь это ведёт к устойчивости и возможности расширения. Революция же в большинстве случаев разрушает экосистему (падение метеорита, например), однако отслеживание трендов и понимание потенциальных рисков позволяет начать «перестройку» заранее и пройти этот этап с наименьшими потерями. Одна из моих любимых фраз очень ёмко описывает этот принцип (спасибо Enter Shikari за их прекрасную песню «Airfield»): «Когда ветер дует тебе в лицо, помни одну вещь — это самые оптимальные условия для взлёта птицы».
5️⃣ Открытость к сотрудничеству и партнёрствам
Ещё одна отличная фраза: «Если ты думаешь, что делаешь что-то хорошо, то всегда найдётся азиат, который делает это лучше!» И это правда! Только без привязки к расе. Невозможно всё делать лучше других. Та же Figma вместо реализации огромной пачки функциональности даёт открытое API для создания различных плагинов сторонними разработчиками. Сейчас в принципе не особо можно представить какой-то завершённый продукт, который пользователь не может адаптировать под свои задачи и нужды.
Если кратко подытожить все вышенаписанные пункты, то экосистема должна обеспечивать консистентность пользовательского опыта, создающую дополнительную ценность для пользователя, а также быть адаптивной относительно рынка и открытой к доработкам, чтобы постоянно расширяться, решая всё новые задачи клиента, и нести деньги бизнесу. Apple начинали свой путь с персональных компьютеров, потом появились iPod и iTunes, которые открыли для бизнеса новую нишу. А в 2023 году ворвались и на VR-рынок. Многие из продуктов стали революционными именно благодаря открытости к инновациям и пониманию трендов (взять тот же iPhone, который с прогиба кинул все устройства со стилусами и просто разорвал рынок смартфонов). Сейчас мы знаем Apple как самую дорогую компанию в мире (ну, или почти самую дорогую — привет, Microsoft… ой, уже NVIDIA), создавшую одну из самых крутых и продуманных экосистем.
Глава 3. Немного про сам дизайн
Искренне надеюсь, что среди читателей статьи практически нет тех, кто думает, что дизайн — это про «рисование картиночек в фотошопе». Однако, сразу подчеркну, что мы говорим про продуктовый дизайн — это и UX, и UI, и аналитика, и понимание разработки, и проведение исследований. В 2021 году на VC выкатывал статью о работе продуктового дизайнера, и в комментариях есть очень прикольные фразы из разряда (орфография сохранена): «Да они не шарят», «Продуктовый дизайнер это способ поднять зэпку соискателем а роботодателем - поднять часовой рэйт при продажи тушки заказчику», «Идеальная картина продуктового дизайнера в крупной компании, которая по каким-то причинам хочет все навесить на одного специалиста». Друзья, расстрою вас, теперь сильный продуктовый дизайнер должен уметь ощутимо больше, особенно в работе над экосистемой.
Для начала разберёмся, для чего вообще нужен дизайн. Когда преподавал в университете курс по дизайну цифрового продукта, спрашивал ребят, зачем они пришли в это направление. Слышал ответы из разряда: «чтобы делать классные штуки», «чтобы делать красиво», «чтобы делать мир лучше». Так вот мы все пришли в дизайн из-за денег.
☝🏻 Дизайн — средство повышения добавочной стоимости продукта. Дизайн, который не приносит денег — это не дизайн, а искусство, художественное произведение
Это очень фундаментальное определение дизайна. Однако, если спуститься на следующий уровень абстракции мы увидим, что дизайн — это процесс, направленный на улучшение функциональных характеристик, удобства и эстетики, что как раз и приводит к повышению добавочной стоимости продукта.
Самое важное, что я подчёркиваю для себя, так это факт направленности этого процесса на человека. По факту «пользовательский опыт» и «пользовательский интерфейс» — это масло масляное, равно как и «дизайн для пользователя». Понятие «опыт» без человека, который его проживает, просто не существует. Понятие «интерфейс» — это в принципе взаимодействие пользователя с чем-либо (аналогично если убрать пользователя, то и интерфейс существовать не будет).
И то же самое про «дизайн» — он всегда направлен на человека. Именно поэтому «дизайн ради дизайна» существовать не может (это, как мы выяснили ранее, художественное произведение), так как всегда в основе есть человек и его потребности — причём как и со стороны конечного потребителя, так и со стороны бизнеса.
С базовой базой определились. Тогда перейдём уже непосредственно к месту дизайна в экосистеме продуктов.
Глава 4. Место дизайна в экосистеме
Из вышенаписанного следует, что основной задачей экосистемы является создание уникального ценностного предложения для клиента, которое невозможно получить вне рамок экосистемы. То есть соответствовать потребностям бизнеса по расширению клиентской базы и увеличению капитала, а также потребностям конечного пользователя продуктов экосистемы. И опять же — выше мы определили, что дизайн находится непосредственно на стыке бизнеса и пользователей. Очевидно, что дизайн напрямую влияет на развитие экосистемы и создание той самой уникальной ценности, за которой придёт пользователь.
Если просто в двух словах описать сферы, за которые отвечает дизайн в экосистеме (помимо стандартных задач дизайна любого продукта), то это будут консистентность и масштабируемость.
Консистентность
Эта сфера непосредственно позволит нам соблюсти 2 и 3 принципы экосистемы («Общая миссия, интеграция и совместимость» и «Усиление ценности»). Пользовательский опыт внутри продуктов экосистемы должен быть максимально ровным и бесшовным аналогично модулям одного конкретного продукта. И вот тут скажу страшную вещь: этот самый пользовательский опыт в рамках всей экосистемы важнее, чем пользовательский опыт внутри одного продукта.
Да-да, внутри одного из продуктов могли сделать, например, суперклассную функциональность таблиц. Но пользователь будет ожидать, что таблицы станут работать в других продуктах ровно так же (если только это не какой-то конкретный узконаправленный инструмент, UX в котором кардинально бы отличался от других продуктов экосистемы). И в итоге ты 100 раз подумаешь прежде, чем внедрять новый паттерн в свой продукт, так как это может поломать опыт в других. Так что либо накатываем везде, либо отказываемся в угоду консистентности (и только за редким исключением встраиваем локально). Внедрение новых решений так или иначе должно быть чётко обоснованным.
И это просто первый попавшийся пример. Всё — от текстов до паттернов взаимодействия — должно быть согласовано друг с другом между продуктами экосистемы. Сейчас ты очень легко ответишь на вопрос, какой инструмент дизайнера решает задачу консистентности при проектировании, но про наш «джентельменский набор» мы поговорим позже.
Масштабируемость
А эта сфера как раз помогает воплотить 4 и 5 принципы экосистемы («Устойчивость, расширяемость, инновации и адаптация» и «Открытость к сотрудничеству и партнёрствам»). Дизайн экосистемы должен быть максимально гибким и адаптируемым к любым изменениям. Он не должен устареть завтра по причине некой «законченности». Любой редизайн — это всегда недёшево. Чисто косметический ещё более-менее быстро можно реализовать (в том числе и за счёт того самого инструмента, о котором ты мог вспомнить в предыдущем абзаце), но вот глобальный рефакторинг UX — это уже тяжело.
Само собой, предусмотреть вообще всё не представляется возможным. Иначе мы получим Microsoft Excel — конструктор, в котором с потом и кровью можно сделать вообще всё, что угодно (даже игры делают). Но тогда вас довольно быстро подвинут более «юркие» и чётко направленные конкуренты. В конце концов, какой крупный бизнес сейчас ведёт свои заказы в Excel, а не в специальной CRM. Но всё равно в уме нужно держать возможности для расширения пользовательского опыта при проектировании систем (появление новых модулей, добавление продуктов и потенциальные интеграции). И если в проектной работе это в принципе опциональная история, а в продуктовой — очень желаемая, то в экосистемной — критически необходимая.
Разобрав эти две сферы, становится кристально прозрачно, что 4 из 5 принципов экосистемы так или иначе поддерживаются дизайном. А оставшийся один — человекоцентричность, которая по умолчанию подразумевается определением «дизайн».
Глава 5. Как мы пришли к экосистеме
Подавляющее большинство экосистем не создаётся с нуля — есть некий основной, флагманский продукт, с которого всё начинается. Также часто бывает, что это знамя передаётся от одного продукта экосистемы другому в зависимости от потребностей рынка. Второй тезис к нам пока не совсем относится, однако первый уже довольно сильно на нас повлиял.
Сначала была Яга
В начале 2022 стартовала активная разработка продукта на замену ушедшим Jira (крупный таск-трекер) и Confluence (база знаний) — Яги. Так как замену нужно было соорудить в довольно короткие сроки, а о внешних продажах тогда ещё и речи не шло, мы взяли за базу стили Ростелекома. Мы сделали большое количество внутренних проектов и продуктов на основе этих стилей, так что практически все сценарии могли покрыть действующим набором. В такой ситуации история с айдентикой отошла на второй план, но нейминг был зафиксирован.
Однако, мы столкнулись с рядом «приколов», возникших из-за ограничений тех самых стилей. Самый яркий пример — в редакторе текста модуля «Яга.Статьи» не было возможности выбрать курсивное начертание, так как у шрифта Rostelecom Basis оно просто отсутствует.
Мы спокойно разрабатывали продукт в формате одиночного, без оглядки на потенциальное переиспользование паттернов в других системах, хоть и многие из применённых решений очень характерны для большого спектра профессиональных интерфейсов (например, навигационные паттерны типа вертикального меню).
Яга на текущий момент успешно внедрена в ряде подразделений внутри Ростелекома — даже наша команда перешла из Jira в Ягу.
Тогда никакой речи про экосистему и не было, но потом продукты стали возникать как грибы после дождя.
Восстань из пепла, Феникс
Также в апреле 2022 стартовала разработка ещё одного продукта — Феникс. Это, на мой взгляд, наиболее значимый продукт для всей разработки в РФ.
С февраля того же года из-за всем известных событий и последующего ухода зарубежных компаний-разработчиков для российских команд появилось довольно много неожиданных угроз. Сидит разработчик, пилит какой-нибудь балдёжный сервис, подключает opensource-библиотеку, а тем временем ресурс с библиотекой видит российский IP или геометку и подкладывает версию с вредоносным кодом. Или ресурс фиксирует, какую библиотеку запрашивал российский разработчик, и формирует у себя перечень уязвимостей, которые есть в библиотеке, для последующего их использования хакером. Разработчик всё компилирует, а потом внезапно падает прод, утекают данные, да и в целом творится лютая вакханалия. И вот как раз Феникс приходит на помощь разработчику — трекает все вызовы артефактов, определяет, какие можно использовать, а какие нет (или же можно использовать с ограничениями — например, не версию 1.7, а 1.6 того же ресурса), и сам загружает разрешённые библиотеки, а для опасных формирует разработчику рекомендации по безопасному использованию.
Очень много работы в этом продукте находится «под капотом», поэтому первое время ему не требовался свой пользовательский интерфейс. Да и в целом из-за своей специфичности и простоты представления базовой функциональности MVP с интерфейсом делался исключительно силами разработчиков — ребята пришли за небольшой консультацией к команде дизайна, которая показала им дизайн-систему Ростелекома и подсказала вариант реализации фильтров. В базе разработчик приходил в интерфейс Феникса, чтобы просто найти из списка нужные артефакты и посмотреть их статус, так что интерфейс ограничивался таблицей со специализированными фильтрами.
К Фениксу мы ещё вернёмся, однако необходимо отметить тот факт, что он стал нашим важным помощником в работе с 2023 года, так как и Яга, и другие продукты экосистемы используют его, чтобы обойти возможные уязвимости. Команда оперативно работает с обратной связью от пользователей и развивает продукт.
Весь Спектр эмоций
В сентябре 2022 мы всерьёз загорелись идеей создания аналога Figma (облачный векторный графический редактор). И тогда я оказался в должности продакта, совмещая эту работу с обязанностями тимлида дизайн-команды. Опять же — никаких мыслей о единой экосистеме не было, и поэтому одним из первых моих решений было отказаться всех стилей РТК, разработать собственную айдентику и компонентную базу.
За основу фронта мы взяли дизайн-систему Атомаро, которая является продуктом дизайн-студии Ростелекома. Ребята в короткие сроки по нашим концептам выполнили темизацию ДС и в дизайне, и в коде (React JS), что позволило собирать Proof-of-Concept. Команда визуальных коммуникаций соорудила для нас свой визуальный стиль, набор иконок и поддерживающих материалов.
На тему разработки Спектра когда-нибудь мы напишем отдельную статью. Это очень интересный и классный опыт, которым хотелось бы поделиться. А пока важно отметить, что с продуктом мы пережили много позитивных и негативных эмоций. Мне же в свою очередь с увеличением оборотов по работам над продуктами импортозамещения пришлось делать выбор — оставаться полностью продактом или дальше развивать дизайн-команду (которая уже на тот момент переросла в целое направление) — и я выбрал второе.
Маленькая, да удаленькая — Ёжка
При разработки Яги возник отдельный стенд с ограниченной функциональностью продукта, который внутри окрестили Колобком. Так как остальные продукты в первую очередь предназначены для установки на инфраструктуру заказчика, Колобок стал прикольным облачным дополнением, которое можно было уже пощупать и показать потенциальным клиентам. И нам настолько понравилась идея этого легковесного трекера, что он стал отдельным продуктом.
Стейкхолдеры весной 2023 обратились к подрядчику с целью разработки айдентики для Яги и Колобка, так как тогда у нас ещё не было чётко сформированной команды под будущую экосистему, да и в принципе об экосистеме речи всё ещё не шло. Так Колобок стал Ёжкой — как Яга, только поменьше. Мы со стороны UX/UI-дизайна подхватили эту идею и сделали лёгкий и игривый визуальный стиль для продукта. Получился бесплатный сервис, которым стали пользоваться люди за пределом Ростелекома. Если интересно попробовать, то вот ссылка.
Ёжка стала для нас откровением — маленький, но прикольный рабочий сервис завоевал наши сердца внутри Ростелекома и начал распространяться за его пределы.
У Лукоморья дуб зелёный…
Продукты продолжали появляться, но единой философии у них не было. И вот осенью 2023 ключевые стейкхолдеры собрали единую концепцию, указали цель, к которой мы хотим прийти — охватить весь сквозной цикл ИТ-разработки всеми необходимыми продуктами.
Так как ключевым продуктом являлась Яга, то и название экосистемы в целом лежало на поверхности — Лукоморье.
☝🏻 Как мы пришли к этой нарративной истории, и как строилась работа над айдентикой продуктов, мы расскажем в других статьях, а тут же сконцентрируемся именно на дизайне продуктов
И на этом моменте стало абсолютно очевидно, что если мы говорим про создание экосистемы, то нам необходимо продумать такой дизайн и такие дизайн-процессы, которые позволят соблюсти принципы экосистемы. В то время мы имели только ряд разрозненных продуктов с абсолютно разными процессами разработки, с суперразной айдентикой, различными паттернами, которые только предстоит связать воедино.
Очень много поменялось в структуре команды разработки продуктов. Думаю, если у коллег найдётся свободное время, они с радостью поделятся опытом. Однако, я сконцентрируюсь именно на продуктовом дизайне, изменениях, которые произошли у нас в процессах и сознании, и тех инструментах, которые позволяют нам соединить все части мозаики воедино.
Глава 6. Порядок из хаоса
Ещё раз пробежимся по тому, что у нас было на момент возникновения концепции экосистемы:
Никак не связанный друг с другом пользовательский опыт продуктов;
Разные UI-Kit’ы;
Разные процессы работы дизайнеров на продуктах.
Если третий пункт можно было настроить позже, то вот первые два требовали срочного решения.
Начало революции
Так как сама экосистема и её отдельные продукты в частности стали готовиться к выходу на массовый рынок, настало время отказаться от огромного наследия, которое было обусловлено использованием стилей Ростелекома. Они сослужили нам отличную службу, чтобы быстро собрать продукты, но теперь пора прощаться. Мы выросли, поэтому стали работать над новым концептом UX/UI продуктов.
В рассказе про Спектр я упоминал, что в нём умышленно отказался от стилей родительской компании. В том числе и наработки из его визуальной составляющей легли в основу единого дизайна экосистемы.
И тут как раз мы возвращаемся к Фениксу. Наши дизайнерские лапки наконец-то до него дотянулись! Перелопачивать огромную и сложную Ягу было бы очень опрометчиво, а вот сделать редизайн интерфейса Феникса, на котором можно опробовать наши концепты — звучит вполне реально и быстро. Спасибо большое команде Феникса за доверие и помощь в реализации наших идей.
Мы сделали несколько итераций и отшлифовали концепт, а затем попробовали раскатать его на ключевые экраны других продуктов. Стала вырисовываться стройная структура, которую мы презентовали стейкхолдерам в качестве маленького «сюрприза» на общей итоговой встрече в декабре 2023 года. Так как Феникс был изначально сделан в тёмной теме, то этот ход позволил нам затащить тёмную тему и в другие продукты экосистемы, а финальный результат пришёлся по вкусу заказчикам. Концепт помимо новых визуальных решений учитывал и новый паттерн навигации по всем продуктам экосистемы.
«Тот самый» инструмент
Когда мы говорили ранее про место дизайна в экосистеме, ты уже прекрасно понял, какой инструмент необходим для реализации консистентности и масштабируемости — да-да, вот сейчас настало время поговорить о дизайн-системе.
В дизайн-студии Ростелекома на тот момент существовало два крутых инструмента для работы дизайнеров:
Дизайн-система Атомаро включала в себя базовый набор компонентов, реализованных как на дизайне, так и в коде. При этом компоненты в Figma чётко токенизированы, что позволяло с наименьшими потерями проводить темизацию дизайн-системы под нужды заказчика;
Инструмент для проектирования профинтерфейсов — это набор проверенных и устоявшихся паттернов, которые мы используем в проектировании сложных и высоконагруженных систем. На базе этого инструмента создано большое количество проектов и продуктов: от CRM до систем прогнозирования расширения топологии сетей.
Естественно, мы решили использовать накопленный опыт и организовали с ребятами коллаборацию, чтобы в минимальные сроки дать жизнь нашей дизайн-системе:
Провели ряд воркшопов для всех дизайнеров, подключившихся к проектированию;
Засетапились с разработкой, чтобы подстроить существующие решения под наши процессы;
Построили формат ревью и периодического аудита со стороны команды профов и Атомаро.
По итогу мы в короткие сроки собрали очень классный процесс по работе над дизайн-системой, а в параллель стали тестировать её применимость на новых продуктах: замене GitHub/GitLab и маркетплейсе экосистемы.
Дизайн-система полностью токенизирована. Причём мы специально убрали токены третьего уровня из исходных компонентов Атомаро, так как нам требуется меньший уровень кастомизации, чем изначально был предусмотрен у ребят. Темы всё так же можно создавать, но для всех продуктов разом. Например, если мы ставим пакет продуктов клиенту, и он просит кастомизацию оформления, мы можем это сделать, но только сразу для всех продуктов, купленных заказчиком, чтобы сохранялась консистентность восприятия.
Однако, одной только дизайн-системы для стройной работы над экосистемой недостаточно! Важно, чтобы процессы работы дизайна были чётко выстроены во всех продуктах, чтобы всё было максимально согласовано и прозрачно. Собственно, поэтому дальше мы поговорим о чём-то большем и критически необходимом для любой экосистемы.
Глава 7. DesignOps
Нильсен/Норман Груп приводят следующее определение этому термину:
☝🏻 DesignOps — это организация и оптимизация людей, процессов и производства с целью повысить ценность и результативность дизайна с учётом дальнейшего масштабирования
К этому термину многие относятся весьма скептично. Из разряда «зумеры придумали стандартизацию». Но это действительно важная практика, которая при правильном описании и применении определённо даёт свои плоды.
DesignOps включает в себя:
Определение и соблюдение эффективных схем коммуникации как внутри дизайн-команды, так и в целом в продуктах;
Улучшение эффективности и производительности за счёт максимальной оптимизации всех операционных процессов — гайды и фреймворки помогают не отвлекаться на рутинное выполнение стандартных действий, а заниматься именно креативной деятельностью по проектированию пользовательского опыта, что неумолимо ведёт к сокращению операционных издержек и уменьшению time-to-market;
Мероприятия по соблюдению консистентности проектирования и контроль со стороны команды DesignOps.
В проектной деятельности это не столь необходимо, хоть и важно — вы всегда подстраиваетесь под требования заказчика и при переходе с проекта на проект адаптируетесь. Однако, для продукта это критично, так как согласованность действий и определение рамок позволяют оперативно реагировать на изменения требований рынка и максимально эффективно отрабатывать возникающие задачи. А уж для экосистемы, которую можно рассматривать как суперпродукт, это, ну, просто кровь-из-носа как супергигакритично! Ведь если мы теряем консистентность, то теряется и уникальное ценностное предложение, которое даёт пользователю экосистема.
Мы приступили непосредственно к сборке практики DesignOps. На рынке есть много успешных кейсов внедрения — те же AirBNB, IBM, Google — всё это можно найти в открытых источниках. Разница между компаниями состоит в том, что где-то для этого набирается отдельная команда, а где-то в конкретном продукте эту обязанность берёт на себя производственный специалист, совмещая с основной деятельностью. Мы же стараемся аккумулировать весь необходимый набор инструментов в руках той команды, которая отвечает непосредственно за самый основной (но далеко не единственный) инструмент — за дизайн-систему.
В нашем представлении DesignOps сводится к следующим пунктам:
Непосредственно дизайн-система (как UI-Kit, так и паттерны) — ну, это БАЗА, причём набор компонентов важен настолько же, насколько и правила их применимости в соответствии с потребностями продуктов и идеологией экосистемы;
Стандартизированный процесс ведения дизайн-задач — на каждом продукте фреймворк должен быть единый, чтобы как минимум при переключении ресурсов с одного продукта на другой не уходило много времени на адаптацию к новым процессам;
Фреймворк и чек-листы для подготовки материалов в разработку — да, подход единый в том числе внутри дизайн-документации, все сценарии должны учитывать необходимые состояния, чтобы минимизировать правки на этапе разработки;
Редполитика — помимо компонентов и паттернов в продуктах экосистемы одинаково должен работать и текст: все мы знаем классический приём оценки интерфейса, из которого можно убрать всё, кроме текста, и при этом ничего не должно развалиться — консистентность и тут критически важна;
Гайды по анимациям микровзаимодействий — да, сами микровзаимодействия могут отличаться от продукта к продукту, но подчиняться они должны одним и тем же законам;
Чёткая и прозрачная ролевая модель с описанными зонами коммуникации и влияния — только ленивый сейчас в ИТ-индустрии не ругается на переизбыток встреч и лишних коммуникаций, поэтому эти процессы так же подлежат оптимизации (но без фанатизма и излишнего формализма);
Контроль консистентности решений через командные мероприятия — команда-носитель практики DesignOps совершенно спокойно имеет право забраковать суперкрутое решение в рамках одного продукта, если оно не будет распространяться на другие (само собой, есть исключения, но они должны быть максимально обоснованы ради соблюдения всё той же консистентности пользовательского опыта).
В этот список я не стал включать стандартные мероприятия по повышению квалификации сотрудников и онбординг новых ребят — это важно, но, на мой взгляд, не обязательно должно быть включено именно в DesignOps, а может регулироваться на уровне менеджмента дизайн-команд.
Эпилог
Самое главное изменение, которое пришлось принять и осознать всем дизайнерам продуктов экосистемы — унификация и консистентность внутри всей экосистемы важнее креатива внутри конкретного продукта. Иногда приходится идти на довольно серьёзные компромиссы, но по большей части именно они и рождают гораздо более стройное решение в рамках интеграции между продуктами.
Само собой, мы не говорим о том, что изобретательство полностью гасится фреймворками и гайдами, а ограничения ломают творческую деятельность и трансформируют креатив в механическую работу. Напротив, многие решения можно переиспользовать и дать жизнь более сложным, которые потенциально могут качать и другие продукты экосистемы. Однако, именно пресловутая операционка должна быть сведена к минимуму, чтобы освободить время для действительно важной и комплексной проработке продуктовых и экосистемных сценариев.
Мы пока находимся только в середине пути, но дорога крайне интересная и захватывающая. Многое ещё предстоит описать и внедрить, и я искренне верю, что спустя время мы поделимся крутыми результатами и проанализируем пройденный путь полностью, сделав выводы о том, что получилось, а что пришлось видоизменить или даже исключить.
Свой рассказ я начал с тезиса, что хотел бы запустить дискуссию и не претендую на «истину в последней инстанции». И это действительно так. Критикуйте, друзья! Мы только приобретаем этот уникальный опыт, так что будем учиться и становиться лучше с каждым следующим днём!
Денисенко Никита
Дизайн-директор экосистемы «Лукоморье», РТК ИТ — tg: @nikdenisenko
