Они копятся в темных уголках бэклога — тикеты, которые никто не решает. Сначала их было десять, потом сто, а через год вы с ужасом понимаете: это уже кладбище. Команда боится туда заглядывать, пользователи злятся, а продукт медленно тонет под грузом нерешенных проблем. Спойлер: чтобы спасти проект, не понадобятся ни святая вода, ни экзорцист. Только системный подход и наши инструкции.
Меня зовут Катя Орешкова, и я работаю над Mailion — корпоративной почтовой системой от компании МойОфис. Основное ядро продукта написано на Go, но в целом технологический стек включает множество языков и технологий: Go, Java, Python, PHP, C++, C# (бэкенд), а также JavaScript/TypeScript с React (фронтенд). Продукт состоит из десятков модулей, предоставляет сотни функций и поддерживает до миллиона пользователей, что требует глубокой проработки архитектуры, разработки и интерфейсов.
В своей роли ведущего дизайнера-аналитика я работаю с дизайн-долгом и обратной связью от пользователей. Наша команда сформировала системный подход, который помогает превратить «кладбище тикетов» в четкую и полезную систему. В этой статье — план спасения в части UX: универсальный и способный к масштабированию на любое направление. Под катом рассказываю, как собирать обратную связь так, чтобы ею реально можно было пользоваться, приоритизировать без боли и вовлечь команду в процесс.
В прошлой статье — "Как спроектировать базу данных регулярного UX-исследования. Полный гайд на примере одного продукта" — я разбирала систему организации данных пользовательских исследований для долгосрочного анализа. Мы создали инструмент, который помогает структурировать результаты исследований, отслеживать проблемы в динамике и принимать обоснованные продуктовые решения.
Продолжая тему хранения и использования данных, я хочу рассказать о своём опыте работы с дизайн-долгом и обратной связью от пользователей. Словосочетание «кладбище тикетов» может звучать пугающе, но я уверена, что описанный мною подход поможет вам избежать подобной ситуации и сделает работу с UX-улучшениями в дизайне продукта позитивной и организованной.
Общая схема нашей работы
Команда UX-исследований, проектирования и дизайна видит продукт как систему с множеством нелинейных и взаимосвязанных пользовательских сценариев. Развитие текущих и появление новых функций рано или поздно приводит к накоплению дизайн-долга — набора проблем в дизайне или реализации, которые влияют на пользовательский опыт. Наша задача — замечать эти проблемы, фиксировать, планировать их исправление вместе с техническим долгом и внедрять улучшения в системный процесс разработки.
Когда пользователи получают очередную версию обновленного продукта, мы собираем обратную связь из разных источников: исследований, обращений, отзывов. На их основе мы планируем улучшения UX. Параллельно идёт основной продуктовый процесс: планирование и реализация задач от бизнеса — так в продукте появляются новые функции. В итоге эти два потока сходятся: мы выпускаем функциональность, передаем ее пользователям и заходим на очередной круг в нашей рабочей схеме.
Накопление обратной связи
Работа с дизайн-долгом начинается с важной инструментальной задачи: накопления обратной связи для дальнейшего к ней обращения. Важно понимать — копить информацию не означает просто записывать всё подряд. Речь идёт о системном подходе: аккуратном и грамотном фиксировании данных из разных источников (исследований, фидбека, экспертных оценок). Это помогает в будущем не теряться в хаотичных заметках и бесконечных списках, а быстро находить нужную информацию и использовать её по делу.
Почему важно продумывать это заранее? Потому что именно то, как мы потом будем обращаться к нашему бэклогу, дизайн-долгу, и определяет, как нужно его собирать уже сейчас.
Инструменты для работы с дизайн-долгом
Разметка по сценариям
Дизайн-долгом может считаться общий список недоработок, которые нужно устранить «когда-нибудь». Однако такой подход часто приводит к непоследовательному накоплению задач без четких приоритетов. Cо временем списки могут значительно разрастаться, что потребует отложенного ручного труда в будущем.
Анализ долга в разрезе пользовательских сценариев, в свою очередь, помогает держать накапливаемый долг под контролем и изучать его порционно. Когда вы используете посценарную разметку, то становится понятно, какие недочеты критичны для ключевых пользовательских задач, какие можно отложить, какие требуют доисследования. Такой подход трансформирует дизайн-долг из «чёрного ящика» в эффективный инструмент принятия решений, помогая создавать прозрачную систему для работы.
При этом важно чётко понимать, какие потребности или проблемы остаются нерешёнными в рамках каждого сценария. Такие вопросы возникают, когда к дизайнерам обращаются коллеги — продакт-оунеры, аналитики, другие команды — или когда сами дизайнеры и исследователи возвращаются к теме, чтобы проанализировать имеющиеся данные по конкретной пользовательской задаче.
Чтобы иметь возможность быстро найти нужную информацию, мы структурируем данные такой посценарной разметкой, как, например, «написать письмо». Это позволяет видеть проблемы в контексте конкретных задач пользователей. Так мы получаем ясное понимание каждой проблемы и полное представление о незакрытых вопросах внутри сценария.
В основе нашего подхода к разделению сценариев лежат реальные пользовательские задачи — то есть действия или функции системы, которые человек регулярно выполняет в своей работе. Важно соблюдать баланс в детализации: мы не спускаемся до уровня отдельных интерфейсных элементов (например, «свернуть/развернуть панель»), но и не пользуемся слишком абстрактными формулировками (например, «работать с письмом»).
Дополнительным критерием для включения сценария в разметку является его смысловая переиспользуемость — например, в пользовательских исследованиях или при анализе UX-метрик. Чтобы обеспечить единообразие, мы договорились о стандартных названиях для всех сценариев.
Как мы работаем с деревом сценариев
Для удобства навигации и визуализации мы ведем дерево сценариев в Figma. Оно отражает пользовательские задачи, которые мы используем для разметки тикетов в дизайн-долге. Каждая карточка сценария структурирована: разбита на логические части для удобства работы, содержит фильтр для поиска связанных тикетов (UXTickets) и включает ссылки на соответствующие дизайн-проработки.
Этот подход особенно полезен, когда дизайнеры начинают работу над новой задачей. Перед созданием макетов обязательно проводится UX-анализ, включающий изучение всех накопленных данных, в том числе старые исследования и дизайн-долг. Это помогает не только избегать повторения ошибок, но и параллельно решать смежные проблемы, даже если они относятся к другой задаче. В результате в дизайн-долге поддерживается постоянное движение, что делает процесс более динамичным.
Разметка дополнительными признаками и приоритизация
Фильтры и метки
Иногда нужно быстро оценить состояние бэклога, например, перед исследованием или внутренней встречей. Такие ситуации возникают, когда у нас нет времени и других ресурсов на погружение в весь массив накопленных данных. Тут нас выручает предварительная разметка тикетов и фильтры. Последние можно настроить один раз и пользоваться в течение многих лет. Эти фильтры динамически обновляются и остаются актуальными со временем, а ещё ими удобно делиться с коллегами. Они позволяют быстро находить нужные задачи по разным параметрам и их комбинациям: раздел системы, сценарий, роль пользователя, источник обратной связи.
Гибкая система фильтров и меток позволяет не только структурировать бэклог, но и работать с дизайн-долгом порционно — делать точечные выборки: например, по проблемам определённого сценария для юзабилити-тестирования или задачам, связанным с конкретной ролью пользователя. Особенно полезны пересекающиеся выборки, где анализируется сочетание нескольких параметров. Как показано на скриншоте ниже, простая двумерная таблица, где по осям отложены приоритет и направления продукта, создает наглядную «тепловую карту» проблемных зон. Такой подход превращает массив накопленных задач из сумбурного списка в управляемую аналитическую систему.
Приоритизация задач
Когда речь заходит о приоритизации и разметке тикетов по степени критичности, первое, что приходит на ум, — инструменты для расчёта приоритета. Такой расчёт становится необходимым уже при появлении первых записей в дизайн-долге — без него сложно определить, за какие задачи браться в первую очередь.
В МойОфис мы используем систему, которая учитывает пять параметров:
Сколько пользователей сталкивается с проблемой.
Как часто это происходит.
Как регулярно, стабильно воспроизводится проблема.
Как проблема влияет на поведение пользователя — на его удовлетворенность и возможность выполнить задачу.
Какое влияние это оказывает на бизнес — например, влияет ли на решение о покупке или продолжении использования продукта.
Независимо от выбранной модели расчёта приоритета, важно интегрировать её в систему управления задачами. Это обеспечит технологичную работу: каждый новый тикет будет автоматически получать необходимые параметры, а накопленная обратная связь останется прозрачной и понятной для всей команды.
Нейминг, описание и оформление
Последний по порядку, но не по важности момент – вопросы наименования и описания данных.
Иногда, когда мы сосредоточены на сборе обратной связи, такие детали просто забываются. Кажется, что можно просто по-быстрому записать проблему в свободной форме — лишь бы тикет был создан. А разобраться, что мы имели в виду, успеем потом, когда начнем решать. Но на деле это может обернуться серьёзной проблемой: если, например, тикет дойдет до команды через полгода, понять, что имелось в виду, будет уже сложно. Эта проблема особенно актуальна на ранних этапах запуска работы с фидбэком.
Мы формулируем названия тикетов через призму конкретных пользовательских проблем — так, чтобы даже при беглом просмотре списка можно было сразу понять суть каждой трудности, не вникая в детали.
Это же касается и описаний. В них мы не только подробно указываем, что произошло, но и добавляем оригинальное обращение пользователя или ссылку на первоисточник (например, тред во внутреннем чате обратной связи). Это помогает будущему читателю не только быстро понять суть проблемы, но и при необходимости восстановить полный контекст — без лишних уточнений у автора. Строгих шаблонов рекомендаций мы не даем, но исходим из здравого смысла. Главное — оформлять информацию так, чтобы она была понятна и полезна даже через несколько лет, упрощая работу себе и будущим пользователям системы.
Долгосрочная работа с дизайн-долгом
Работа с дизайн-долгом — не разовая задача, а долгий процесс, в который вовлечена вся команда. Один из инструментов, который мы используем — догфудинг: сотрудники МойОфис сами пользуются нашим продуктом и делятся обратной связью.
Чтобы такой подход действительно приносил пользу команде разработки и помогал развивать продукт, у нас организовано командное дежурство — в нём участвуют все члены команды. Мы, как дизайнеры, тоже включены в этот процесс на своем участке. Мы разрабатываем инструкции и внутренние материалы, чтобы сотрудники в команде точно знали, как работать с тикетами: от заполнения полей до решения сложных ситуаций. Это помогает избежать путаницы и сделать так, чтобы все находились в одном информационном поле и действовали согласованно.
Может возникнуть вопрос, зачем вовлекать дизайнеров, ведь это сложно организационно и дополнительно нагружает специалистов? Мы исходим из того, что такие процессные вещи, как работа с обратной связью, нельзя замыкать на одном человеке. Поэтому решили разделить эту ответственность между участниками команды.
Помимо очевидного долгосрочного результата — закрытия UX-тикетов и улучшения пользовательского опыта — вовлечение команды дает и другие положительные эффекты. Это помогает дизайнерам и исследователям:
Выходить за рамки привычных разделов системы и сценариев, а также смотреть на пользовательские проблемы под другим углом. Это значит проанализировать реальное использование продукта: выявить точки затруднений пользователей и глубинные причины, стоящие за их ошибками.
Развивать эмпатию не только через понимание реальных проблем пользователей и причин, которые к ним приводят, но и через попытки помочь людям разобраться с этими проблемами.
Развивать навык размышления, отталкиваясь от пользовательской задачи и проблемы, а не бизнес-постановки. Это полезно как для проектирования, так и для исследовательской работы.
Резюмируя:
Главное — системность
Работа с дизайн-долгом требует дисциплины, но окупается. Начните с малого: внедрите метки, подходящие вашему продукту и команде, и простую приоритизацию. Постепенно команда привыкнет к процессу, а бэклог станет не кладбищем, а дорожной картой для улучшений.
Используйте метки и справочники
Это поможет структурировать данные и работать с ними в долгосрочной перспективе более технологично, минимизируя ручной труд.
Включайте приоритизацию
Даже простая модель поможет упорядочить задачи на ранних этапах, а на более поздних она станет необходимой.
Не забывайте о важности нейминга
Формулируйте названия тикетов от проблемы и подробно описывайте суть — так, чтобы в будущем и вы, и ваши коллеги без труда поняли, о чём речь. Придерживайтесь здравого смысла: делайте так, чтобы самим потом было проще с этим работать.
Взлёты и падения
Важно помнить, что работа с дизайн-долгом — это процесс, требующий времени и терпения. Скорее всего, на каком-то этапе вы столкнетесь с разочарованием или ощущением, что это никому не нужно. Но при последовательной работе со временем всё начнет выстраиваться: система станет понятной и прозрачной, появятся содержательные тикеты, которые постепенно попадут в работу, а улучшения достигнут продакшена. Главное — не бояться начинать и постоянно совершенствовать процесс.
Все описанные методы — часть нашей ежедневной рутины. Если вы ищете возможность применять системные подходы к управлению в масштабном проекте и готовы предотвращать накопление «долгов» в разработке — присоединяйтесь к нам. В МойОфис мы ищем руководителя отдела разработки Mailion — менеджера, который ценит чёткие процессы учёта и приоритизации задач, налаженное взаимодействие между командами и выстроенные циклы постоянного улучшения продукта.
