Привет! Хочу рассказать вам о том, как мы применили продуктовый подход к исследованию опыта разработчиков при работе с Figma, чтобы создать единый стандарт оформления макетов в компании.
На Хабре уже есть несколько отличных разборов того, как разные команды наводят порядок в Figma: аннотации, стрелки, сценарии, раскладки макетов и так далее. Я видел материалы Ozon Tech, t2, Иннотех — это классные справочники правил, можно брать и пользоваться. Но, когда в 2024 году я взялся за задачу подготовки стандарта для нашей компании, то столкнулся с вопросами, о которых нигде ничего не нашел. Как разработать единый подход? Что считать правильным и почему? Как упаковать эту идею и «продать» остальным членам команды, а главное: что делать дальше?
В этой статье поделюсь нашим методом поиска ответов на эти вопросы.
Хороший дизайнер, что бы ты ни предложил, спросит тебя: «Откуда вообще эти правила появились? Какие именно проблемы они решают? Чьи именно проблемы? Почему я должен им следовать (ведь я буду тратить на это рабочее время) и какой профит?». И, что немного обидно, будет прав.
Начнем искать ответы
У каждого дизайнера со временем вырабатывается свой подход к тому, как правильно оформлять макеты. Кто-то что-то опытным путем создает сам, кто-то берет от места работы. Пока команда маленькая, это не мешает: все рядышком, перенимают подходы друг друга — происходит синергия.
Но в 2024 году мы в Cloud.ru резко выросли с четырех дизайнеров до 20+ — и наш общий подход рассыпался. Это вызывало много вопросов от новых дизайнеров и порождало трудности при совместном ревью. Договориться о едином подходе сходу не вышло — каждый был по-своему прав, у всех за плечами реальный опыт, и почти все подходы реально работали. На любой аргумент находился контраргумент, и через три часа обсуждений никто никого не переубеждал.
В какой-то момент до меня дошел главный абсурд: мы, дизайнеры, неделями спорим о том, как удобнее работать людям, которые читают наши макеты, — а самих этих людей в комнате нет. Тогда мы решили сделать то, что обычно делаем при проектировании продуктов: пошли к пользователям и спросили.
Кто вообще пользователь
Когда говорят про стандарты оформления макетов, разговор всегда крутится вокруг дизайнеров. Но дизайнер — далеко не главный читатель макета. Каждый день их открывают разработчики, тестировщики, аналитики, продакты и техлиды — и часто проводят внутри файла не меньше времени, чем автор. Разработчик разбирается в логике сценария, тестировщик ищет состояния и исключения, аналитик сверяет требования, продакт оценивает решение целиком. По сути, макеты — это интерфейс передачи знаний между людьми в команде. И если он неудобен, страдает вся команда.
Раз пользователь макета — это по сути любой член продуктовой команды, значит, и спрашивать нужно всю команду, а не только дизайнеров. Мы набрали 15 человек из разных продуктов, где исторически сложились абсолютно разные подходы к работе с Figma. Состав получился осознанно перекошенным в сторону разработки: 5 фронтендеров, 3 тестировщика, 3 аналитика, 3 продакта и 1 техлид (последнего взяли скорее на всякий случай).
Тут бы я сразу сразу хотел предложить несколько рекомендаций, которые уберегут от ада согласований.
1. Не растягивайте набор на месяцы. Иначе растеряете запал двигать эту историю так масштабно, а с ним расплывутся фокус и контекст. Соберите весь пул потенциальных респондентов сразу — напишите им и поставьте встречи в календаре. И сразу проговорите: «Я провожу исследование о том, как тебе работается с макетами в Figma. Это не проверка того, как ты умеешь с ними работать. Я хочу найти, где неудобно, и улучшить процесс. Сможешь выделить время и помочь?». Это важно: если человек думает, что его тестируют, он показывает не как работает на самом деле, а как, по его мнению, правильно работать. А нам нужно было именно первое.
2. Найдите союзников-энтузиастов, кто поможет провести интервью (потому что выделить 15+ часов быстро и в одиночку — амбициозный сайд-проект внутри компании).
3. Запаситесь ИИ-транскрибаторами и суммаризаторами. В 2024 году это не было так распространено, и я все выписывал вручную — это долго и муторно. Сейчас одна только ИИ-транскрибация снимает огромную часть рутины и по опыту некоторых коллег экономит время минимум в 4 раза.
Итак, вы выбрали сегменты, написали кандидатам, поставили встречи. Наступает день Х.
Что мы спрашивали и как общались
Важное предисловие. Чего я точно не делал и не советую — спрашивать «как тебе удобнее, чтобы были оформлены макеты?». Это плохой вопрос. Люди не знают, как им удобнее, пока не столкнутся с конкретным макетом. Спросишь в лоб — получишь либо «да норм всё», либо фантазию о макете, которого никто не видел.
Каждое интервью занимало от часа до полутора и делилось на три части.
Первая — наблюдение. Мы просили человека показать на примере последней реальной задачи, как он работал с макетами. Какая была задача, что он делал, что искал первым делом, как искал. Что за последнее время раздражало, а что наоборот — оказалось удобным. Здесь важно не сыпать абстрактными вопросами, а идти от конкретной задачи, которую человек делал буквально на этой неделе: память свежая, ответы честные.
Вторая — задания. Мы показывали разные способы организации макетов — столбиком, в виде флоу — и давали на них живые задачи: «найди экран скачивания артефакта», «объясни, как пользователь попал в это состояние», «представь, что дизайнер ушел в отпуск, — разберешься сам?». Интересовал не правильный ответ, а процесс: куда человек смотрит первым делом, по каким признакам ищет, где спотыкается.
Третья — свободный разговор и финал. Дальше я задавал вопросы: «Ты посмотрел все подходы, у тебя за плечами свой опыт — какой формат назовешь самым удобным и почему? Что зацепило, какие детали понравились больше?». Здесь нас интересовало главное: что для продуктовой команды действительно удобно, что нет — и с какими вещами они точно не готовы мириться.
Как я обрабатывал отклики
Дальше начинается работа, которую обычно пропускают в рассказах про исследования — разбор. Чтобы было прозрачно, расскажу пошагово, без «и тут мы поняли».
Сначала я разложил всё по респондентам: две категории по каждому отдельно — что понравилось и где боль. Потом провел кластерный анализ: сгруппировал все реплики, и позитивные, и негативные, по темам. Кластеры получились примерно такие — сценарии оформления макетов, структура файла, разбиение на страницы, оформление самих страниц, стикеры и аннотации, онбординг, работа с Dev-mode, прототипы и так далее. То есть это не «свалка фидбэка», а карта: вот сюда падают все реплики про навигацию, вот сюда — про статусы, вот сюда — про связь с задачей.
И уже по каждому кластеру, опираясь на боли и привычки, я выносил конкретное предложение — правило. Логика простая: вот боль → вот правило, которое её закрывает. Покажу на одном примере, чтобы был виден весь путь от реплики до правила.
Тестировщики и разработчики в один голос говорили примерно одно:
— Хочется, чтобы все статусы, допустим в таблице, были в одном месте — знать, какие вообще есть.
— Хорошо, когда отрисованы все статусы и примеры данных. Допустим, видно, будет в этом статусе заблокированная кнопка или нет.
— Иногда не хватает подробности. Например: что будет, если я нажму «отмена», — а вдруг там пропущена модалка «точно закрыть?».
Такого правила у нас не было. В качестве предложения я вынес: полный список статусов сущности размещаем под макетом, и для каждого статуса показываем, какие действия с этой сущностью в нем доступны. Не просто «вот статусы», а «вот статус → вот что в нем можно сделать → вот что в нем недоступно».
Дальше это правило само превратилось в чек-лист гигиены для дизайнера. Если, раскладывая статусную модель, дизайнер сам не знает ответа — а что доступно в статусе «Обновляется»? — это прямой сигнал: иди к продуктовой команде и уточни. А если и команда не знает — договоритесь о временном решении. Например, в неоттестированных статусах не давать никаких действий вообще, даже если технически они возможны. А позже, когда дойдут руки и ресурсы, уточняем. Так проработка статусной модели из «нарисуй красиво» превращается в обязательный этап проектирования интерфейса.
И так — по каждому кластеру. Боль → правило → проверяемый шаг для дизайнера.
Так появилась миссия
Когда дизайнеры спорят о стандарте, они спорят о консистентности: чтобы макеты выглядели единообразно и ревью шло быстрее. Это правда — единый подход реально ускоряет дизайн-ревью. Но выяснилось, что разработчиков консистентность сама по себе волнует мало. Их волнует другое: почти во всех подходах, которые мы показывали продуктовым командам, у людей была одна и та же проблема — тяжело найти нужное.
Когда мы свели все боли вместе, оказалось, что хороший стандарт должен закрывать не «красоту», а три вещи:
-
Найти. Быстро добраться до нужного экрана и состояния, не пролистывая весь файл.
-
Понять контекст. Увидеть, как пользователь сюда попал и зачем этот экран вообще существует, — отсюда, кстати, и запрос «прилинкуйте к макету задачу в Jira».
-
Не додумывать. Видеть всю картину состояний и развилок целиком, чтобы не достраивать логику в голове.
Эти три вещи и стали миссией стандарта. Осталось дошлифовать под нее правила и упаковать так, чтобы донести до всех.
Упаковка и продажа
Когда боли превращаются в конкретные предложения, их нужно донести до остальных участников процесса. Кого-то так заонбордишь, кому-то продашь идею. Я так и поступил — в три этапа: согласование с лидами, презентация команде дизайнеров со сбором обратной связи и презентация команде разработки.
Я собрал всё в презентацию по простому формату: вот такая работа проделана, вот к каким правилам мы пришли и почему. Сначала презентовал дизайнерам — чтобы собрать обратную связь и не упустить что-то ключевое. У ребят всё прошло гладко.
А следом удачно совпало: рядом была встреча фронтенд-комитета — это, по сути, группа всех фронтов компании. На ней я презентовал новые правила уже всем фронтам с прямым посылом: теперь живем так. Нравится? Требуйте от дизайнеров, чтобы оформляли именно так. Не нравится? Приходите, приносите улучшения, процесс открыт.
После выступления я провел короткий опрос — поняли ли вообще, о чем правила, насколько понятно и насколько полезно. Результат: понятность — 5 из 5, полезность — 4,5 из 5. Из того, что отметили как самое полезное: описание типов меток, виды стрелок и ссылок, общая структурированность файла.
Раскатка
С раскаткой мы договорились не ломать команду через колено. Уже собранные макеты никто принудительно не переписывал — это сожгло бы недели работы без новой ценности. Так, итерационно, за полгода мы перевели все макеты на новый подход.
Кстати, про название процесса. Систему мы назвали FigmaOps — от Figma Operations. И название не случайно делится надвое. Есть внешнее кольцо: мы регулярно исследуем, как продуктовым командам работается с Figma, и улучшаем этот опыт. И есть внутреннее кольцо — сами правила того, как дизайнер работает с Figma. Внутреннее кольцо крутит внешнее: меняешь правила — меняется опыт команды. Не разовая акция «навели порядок», а постоянный цикл.
Чтобы держать раскатку под контролем, мой лид помог выстроить систему в Jira — я видел, как каждый продукт переезжает на FigmaOps, и сводил это в аналитические таблицы. Через полгода такого подхода мы перешли полностью: новые макеты уже все делали по стандарту.
Что дальше и к чему быть готовым
Если берешь на себя миссию сделать стандарт, будь готов к двум вещам. Во-первых, ты немного ломаешь людям привычный уклад работы, а значит, когда ребята начнут находить в системе изъяны и предлагать улучшения, чинить всё это по-честному — твоя ответственность. Во-вторых, если что-то непонятно, приходить с этим будут к тебе. Таков путь.
Первые полгода изменений было особенно много — что-то прилетало чуть ли не каждую неделю. Многие не понимали, как именно переводить макеты на новый формат, просили показать и объяснить. Поэтому закладывай ресурс не только на сам перевод, но и на поддержку.
И совет, который я дал бы себе прошлому, потому что сам его не выполнил: сразу записать скринкасты и короткие видео — как все устроено и как переносить макеты. Это бы заметно разгрузило поток вопросов.
Вместо заключения
Если совсем коротко, весь метод сводится к одной мысли: дизайнерам не нужно договариваться о том, как оформлять макеты. Договариваться по вкусу — значит спорить вечно. Вместо этого можно пойти к тем, кто эти макеты читает каждый день, разложить их боли по полочкам и превратить в правила, за каждым из которых стоит конкретный человек и конкретная причина.
Система, собранная так, не идеальна и не подходит всем на свете — она сделана под наши команды и наши задачи. Но когда кто-то спрашивает «а почему так?», у тебя есть честный ответ: не «мне так кажется», а «вот данные». И это, пожалуй, единственный способ удержать стандарт живым.
К слову о живой системе
Ни один стандарт не живет вечно — и FigmaOps не исключение. Мы дополняем систему новыми правилами по сей день.
Особенно остро это стало с расцветом ИИ. Прямо сейчас мы описываем, как готовить спецификации к макетам через Claude Code, Cursor и Figma MCP — то есть буквально генерировать описания для разработчиков, общаясь с нейросетью. Год назад такого пункта в стандарте быть не могло: не было ни инструментов, ни запроса. Поэтому система обязана быть гибкой и масштабируемой, иначе устаревает быстрее, чем ты дописываешь последнее правило.
И раз уж речь о витках: мы планируем DX 2.0 — повторное исследование, чтобы снять свежий замер. С тех пор команда выросла, дизайнеров стало больше, и пора проверить, как стандарт держится на новом масштабе.
А как с этой задачей у вас в команде? Если есть свой подход к оформлению макетов — делитесь в комментариях, любопытно сравнить методы.
P. S. Больше про то, как ИИ подвинули Figma как наш основной инструмент, можно прочитать у моего коллеги Егора.
Автор: usatovw
