Библиотека сценариев и корнер-кейсов в Figma

Всем привет! На связи Галя, Саша и Аня – дизайнеры команд продуктового web‑дизайна и мобильного приложения Т2. Сегодня хотим поделиться тем, как разрабатываем библиотеки сценариев и корнер‑кейсов – и как они помогают нам в работе.

Представьте: приходит новая задачка – надо доработать какой‑то экран или даже целый сценарий. И тут начинается: ищем актуальные макеты, проверяем, не устарели ли они, соответствуют ли проду… Почему так происходит? Вот три основные причины:

1. Макеты с отдельными состояниями в разных файлах

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

2. Макеты страниц без редизайна

На проде есть страницы, которые еще не переехали на новый стиль: у них обновлены только шрифты. Макеты этих страниц существуют также разрозненно, и, вдобавок, не у всех актуализированы шрифты.

3. Макеты отсутствуют

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

Как вы уже поняли, постоянная актуализация макетов и их сверка с продом отнимали кучу времени и сил. Поэтому мы подумали: пора что‑то менять! Было решено разработать пространства для хранения актуальных макетов основных сценариев и корнер‑кейсов – как единый источник истины. Это позволяет нам тратить меньше времени на поиск и актуализацию макетов и, соответственно, сократить time‑to‑market.

Сразу решили: никаких подвигов! Не будем сразу пытаться собрать все сценарии и корнер‑кейсы всех стримов/продуктов – это же как пытаться съесть слона целиком. Вместо этого выбрали итерационный подход.

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

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

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

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

Мы собрались, разобрали разные варианты, подумали, какие сложности могут возникнуть при проектировании и использовании этих библиотек. Например:

Это помогло выработать первичные правила оформления макетов сценариев и корнер‑кейсов, которые, конечно, потом еще корректировались и дополнялись в ходе работы над библиотеками.

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

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

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

После того как все макеты были готовы, я оформила сценарии в виде screen‑flow – детализированной карты пути пользователя, показывающей последовательность экранов с их содержимым.

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

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

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

Чтобы управлять этими макетами, я использовала булевые параметры (Property - Boolean) для отображения каждого блока. Это, по сути, стало нашим спасением, потому что позволило решить сразу несколько задач:

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

Кстати, внутри команды этот наш базовый макет быстро получил неофициальное, но очень точное прозвище – «макет-Франкенштейн». Все потому, что он был словно сшит из разных частей и объединял в себе абсолютно все возможные состояния страницы сразу. Звучит немного пугающе, но именно этот «монстр» позволил нам системно проверить все сценарии. Мы смогли убедиться, что ни один кейс не остался за бортом и не был упущен, да и в будущем поддерживать такую библиотеку стало гораздо проще и спокойнее.

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

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

Создать такую библиотеку не так уж легко на самом деле, но мы это сделали. А вот как поддерживать ее, учитывая, насколько быстро меняются макеты – вот это настоящий челлендж. Поэтому вот несколько пунктов, которые нужно учитывать, чтобы библиотека была всегда актуальна и готова к использованию:

1. Правила и гайды для всей команды. Это, наверное, обязательное условие при создании библиотек. Важно зафиксировать: как пользоваться ею, как заводить новые компоненты, как обновлять старые, как называть файлы. Если вся команда будет соблюдать гайды, то порядок в вашем проекте сохранится на все 100%.

2. Описание состава компонента. А как сохранять порядок и работать с компонентами сценариев, если не знаешь, что конкретно входит в их состав, какие названия? Да, желательно бы каждому дизайнеру самостоятельно углубиться и изучить каждый блок. Но зачем, если мы можем упростить всем жизнь и описать это заранее?

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

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

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

Мы уже больше полугода пользуемся ею, в том числе наша команда дизайнеров активно делится своим мнением. И мы все чаще слышим, как смогли ускорить процесс обновления макетов, как это помогло ребятам. А иногда с нами делятся идеями, что можно было бы улучшить, поправить – это супер, потому что так мы не стоим на месте. Поэтому нужно иметь в виду, что на такую большую библиотеку нужны ресурсы и это довольно продолжительная работа, ровно так же, как и ведение UI Kit’а.

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

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

Это все части одного большого пазла. Ранее Галя уже делилась опытом и рассказывала, как наводила порядок в библиотеке блоков. Там тоже много полезного, так что если хотите увидеть полную картину того, как мы выстраиваем систему хранения макетов, – заглядывайте в ту статью.

Мы только в начале пути – это наша первая попытка создать библиотеки сценариев и корнер‑кейсов. Но первые результаты уже радуют: теперь нужные макеты находятся в два счета, а адаптировать их под задачи стало намного проще. Впереди еще куча работы! Stay tuned – продолжение следует!