Пять команд.
Десятки разработчиков.
Один дизайнер.
01. ОБЗОР
Астрал Отчёт 5.0 — это мой опыт работы над продуктом в системе из пяти команд, каждая со своим бэклогом, приоритетами и дизайн-требованиями. Главный вызов это оптимизация процессов ради качественного результата.
Примечание: версия 5.0 — это не просто обновление, а полностью новый продукт, созданный с нуля. Новый технологический стек и совершенно иной подход к проектированию UX.
О продукте
Астрал Отчёт 5.0 — это облачный онлайн-сервис для подготовки и сдачи электронной бухгалтерской и налоговой отчетности в контролирующие органы: ФНС, СФР (ПФР и ФСС), Росстат, ФСРАР.
- Зачем нужен продукт: защита бизнеса от штрафов и упрощение работы бухгалтеров, включая ведение сразу нескольких компаний на аутсорсе.
- Главная фича: продвинутый интерактивный редактор отчётов, который обеспечивает удобное заполнение и автоматическую проверку отчётов на ошибки в реальном времени.
02. МОЯ РОЛЬ
Объединять противоречия
Задача стояла амбициозная: создать продукт для зрелого B2B-рынка и привлечь клиентов существующих сервисов, предложив им более удобный и современный опыт.
Я балансировал запросы продакта (фичи, конверсии), требования закона от аналитиков и технические ограничения команды разработки, трансформируя их в компромиссные, удобные UX-решения.
Что мне помогло?
Фактор: создание и внедрение масштабируемого UI-Kit в Figma с детальной документацией.
Эффект: аналитики смогли собирать до 60% типовых отчётных форм самостоятельно по готовым гайдам, разгрузив меня для работы над другими частями продукта.
Фактор: широкий кругозор за пределами UX/UI, продуктовый подход и навыки фасилитации.
Эффект: уменьшение сроков согласования решений между продактом, аналитикой и разработкой, снижение числа итераций и доработок.
Фактор: наличие юридического образования и понимание сферы в которой работает продукт.
Эффект: значительное ускорение проектирования за счёт быстрого погружения в нормативную базу и эффективного взаимодействия с аналитиками.
Критерии успеха
Чтобы оценивать эффективность дизайн-решений, определили измеримые показатели:
- Скорость выполнения сценариев: меньше времени на подготовку и отправку отчётности.
- Снижение числа ошибок: меньше ошибок при отправке форм и при последующих проверках со стороны госорганов.
- Рост конверсии в сценариях: больше пользователей подключаются к продукту с первого раза.
- Удовлетворённость пользователей: меньше обращений в поддержку, рост числа положительных отзывов.
Время на отчёт -36%
Редактор внутри продукта, автозаполнение и авторасчёт данных, быстрая проверка и улучшенная навигация сократили время подготовки отчёта.
Ошибки в отчётах -43%
Онлайн-проверка после каждого заполнения, единая система ошибок и подсказки предотвращают проблемы ещё на этапе подготовки.
Успешно завершённые заявки 58% → 74%
Упростили первые шаги, добавили степпер, автоматизировали часть данных и сократили объём информации, необходимой для подключения.
Тикеты техподдержки по работе с продуктом -55%
Подсказки и автоматизация помогли пользователям самостоятельно находить нужные функции и решать типовые задачи без возникновения проблем.
Примечание: показатели замерялись в течение квартала после релиза. Для оценки использовалось сравнение метрик с показателями продукта Астрал Отчёт 4.5
3. КЛЮЧЕВЫЕ ВЫЗОВЫ
Ограниченные сроки: как успеть больше
В чём была сложность:
Специфика отчётности привязана к жёстким законодательным дедлайнам — периоду сдачи квартальной отчётности. Опоздание релиза даже на неделю означало потерю сезона маркетингового цикла. При этом нужно было не просто спроектировать десятки экранов, но и успевать проводить исследования, чтобы решения были жизнеспособными.
Как я это решил:
Вместе с продактами всех команд согласовал чёткую приоритизацию задач по методологии RICE. Около 20% времени инвестировал в развитие дизайн-системы: компоненты, документация. Когда система заработала, команды руками аналитиков смогли собирать типовые формы как конструктор, а я сфокусировался на сложных UX-сценариях и новых паттернах.
Сделать удобнее, не ломая привычек
В чём была сложность:
Задача «сделать удобнее конкурентов» на практике означала баланс между привычным и новым. Слишком инновационный и минималистичный интерфейс вызывал у пользователей недоверие: они не находили знакомых форматов данных и сценариев, из-за чего продукт казался непонятным и неудобным.
Как я это решил:
На основе анализа конкурентов и интервью с бухгалтерами я сформулировал принципы проектирования, которые стали общим инструментом для команды. Каждую гипотезу проверяли на соответствие этим принципам — так общие UX-подходы превратились в понятные критерии для принятия решений.
Принципы проектирования:
04. ИССЛЕДОВАНИЯ
Анализ конкурентов
Провели классический анализ рынка: клиентская база, доходы, позиции игроков. Я сфокусировался на UX/UI — разбирал интерфейсы, основные сценарии и паттерны конкурентов, чтобы найти точки для улучшения и не повторять их ошибки.
Что можно улучшить:
В интерфейсе одновременно присутствует несколько проблем, которые затрудняют восприятие информации и работу с ней:
- Несистемность: одни и те же блоки и элементы дублируются на экране, в том числе действия.
- Визуальный шум: контент сливается в единый монотонный массив. Мелкий шрифт, высокая плотность элементов затрудняют быстрое сканирование и поиск нужной информации.
- Отсутствие консистентности: оформление части элементов интерфейса не унифицировано и не воспринимаются как единая система. Особенно ярко это заметно на примере иконок в одном ряду.
Что учесть в нашем продукте:
Сделать интерфейс удобным для быстрого сканирования и обеспечить единообразный пользовательский опыт.
- Система правил: одна функция — одно понятное место и действие. Не дублируем элементы без необходимости, выстраивая единую логику работы.
- Читаемость: ограничить плотность информации, разделить контент по приоритету и обеспечить достаточно визуального пространства для быстрого сканирования.
- Единообразие: использовать единую систему компонентов, состояний и визуальных паттернов, чтобы интерфейс воспринимался как целостный продукт.
Что можно улучшить:
Далеко не у всех конкурентов есть полноценный редактор отчётов. А если есть, то зачастую у него не хватает критически важных функций.
- Проверка на ошибки отдельной кнопкой: пользователю приходится либо запускать проверку после каждого ввода данных, либо проверять отчёт только в конце заполнения — оба сценария неудобны и замедляют работу.
- Усложнение навигации: в модалке появляется отдельная навигация по отчёту, параллельная навигации основной страницы. Попап с ошибками добавляет третий уровень наслоения и перекрывает сам редактор, усложняя работу с отчётом.
Что учесть в нашем продукте:
Мы изначально планировали внедрять редактор отчётов, поэтому анализ и оценка решений конкурентов в этой области были особенно важны.
- Проверять на ошибки по мере заполнения: пользователь не должен каждый раз запускать отдельную проверку вручную. Ошибки нужно подсвечивать непосредственно в процессе заполнения.
- Отдельная страница под редактор: работа с отчётами — это основной сценарий работы в продукте, переводить его в модальное окно достаточно спорное решение.
- Окно с ошибками: собрать все ошибки в одном месте — удачное решение. Такой подход позволяет пользователю быстро увидеть список проблем и последовательно работать с ними.
Что можно улучшить:
Главная страница — входная точка в рабочий процесс.
У маркетинга часто возникает желание наполнить её побочной информацией, для продажи других продуктов.
- Релизы и реклама сервисов на главной: пользователь ожидает, что формы и отчёты уже актуальны. Важные новости лучше отправлять в уведомлениях, а продвижение сервисов включать точечно, только там, где оно работает как естественный cross-sell.
- Группировка меню по ведомствам: внутри каждого ведомства одни и те же пункты: отчёты, требования, письма. Логичнее идти от общего к частному: сначала тип сущности, затем направление или ведомство.
- «Проблемы отсутствуют»: система не может гарантировать отсутствие рисков, результат зависит в том числе от полноты данных, которые предоставил пользователь. Такой блок только создает ложное ощущение безопасности.
Что учесть в нашем продукте:
Выделили несколько принципов для главной страницы:
она должна не просто показывать состояние системы, а подсказывать пользователю, что делать дальше.
- Минимизировать рекламу и новости: каждый блок должен помогать принять решение или перейти к полезному действию, рекламы минимум.
- Вынести основные сущности наверх: требования, письма и отчёты — основные рабочие объекты. Они должны быть на первом экране. Внутри них информацию можно группировать по направлениям.
- Заменить «Проблемы отсутствуют» на список дел: вместо статичного статуса показываем ближайшие задачи и рекомендации, чтобы пользователь сразу понимал, где требуется его внимание.
- Разместить основное действие слева сверху: в примере видим удачное расположение главного действия в первой зоне внимания согласно F-паттерну.
Глубинные интервью CustDev
Большая часть аудитории — консервативные бухгалтеры, поэтому мы хотели понять, какие привычки у них уже устоялись, на каких этапах сценария изменения будут восприниматься наиболее болезненно и какие неочевидные потребности стоит учесть при проектировании.
Подготовка
Прежде чем инвестировать время команды в созвоны, мы провели подготовительную работу:
- Составили портреты — сегментировали аудиторию.
- Сформулировали гипотезы — определили базовое направление диалога.
- Подготовили вопросы — составили конкретный список вопросов для интервью.
- Нашли респондентов — связались с наиболее подходящими клиентами старой версии, а также нашли тех, кто пользуется продуктами конкурентов.
Респонденты
Мы провели 12 глубинных интервью (каждое по 60–90 минут), разделив респондентов на три сегмента:
- Бухгалтеры на аутсорсе (ведение 5-15 компаний) — самый хардкорный сегмент, критична скорость переключения и массовые операции.
- Штатные бухгалтеры — привыкли к пошаговому контролю процессов работы с отчётностью и особенно чувствительны к риску ошибки.
- Самозанятые и ИП — ведут отчётность самостоятельно, легче воспринимают изменения, для них особенно важны простота и понятность интерфейса.
Вопросы и
структура
Мы не собирали абстрактные пожелания вроде «что бы вы хотели видеть в новом продукте», а делали акцент на реальном опыте респондентов. Интервью проходили онлайн с видео: пользователи показывали свои рабочие инструменты и рассказывали, как используют их в повседневной работе. Вопросы охватывали три аспекта:
- Процессы: как клиент решает задачи сегодня.
- Боли: что мешает, раздражает и отнимает время.
- Привычки: почему он работает именно так и какие барьеры к нововведениям существуют.
Гипотезы
Отчётность ведут специалисты
Не подтверждена
Предполагали, что основная аудитория — специалисты с профильным образованием и опытом в бухгалтерских процессах, которым не нужны дополнительные объяснения и упрощения.
Реальность: значительная часть пользователей сдаёт отчётность самостоятельно, без профильного образования. Среди них — ИП и самозанятые.
Интерфейс без скроллов
Не подтверждена
Часть аналитиков, проведя первичные опросы столкнулась с фидбеком от бухгалтера в нашей компании, которая не умела пользоваться колесом мыши. Предлагалось строить весь интерфейс без скроллов.
Реальность: ни в одной категории респондентов не встретили проблем со скроллом — гипотезу опровергли.
Группировка по типу задачи
Подтверждена
Предложили не выносить ведомства в основную навигацию, а группировать их внутри сущностей: «Отчёты», «Письма», «Требования». Подход подтвердился на интервью: пользователям привычнее ориентироваться по типу задачи.
Ценность редактора отчётов
Подтверждена
Встроенный редактор отчётности станет важным фактором перехода в наш продукт от конкурентов. Пользователи готовы отказаться от привычного ПО, если редактор защищает от ошибок и автоматизирует рутину.
Инсайты
Страх ошибки
Бухгалтеры испытывают стресс перед отправкой и многократно перепроверяют данные. Поэтому экран отправки должен давать ощущение контроля: понятный статус проверки, явные ошибки и чёткое подтверждение готовности отчёта.
Статусы после отправки
Для пользователя процесс не заканчивается нажатием кнопки «Отправить». Крайне важно понимать не только текущий статус, но и дальнейший путь документа. Нужно добавить детальный путь документа для каждого отчёта.
Рутина со справочникам
Поиск КБК, ОКТМО и других кодов превращается в цепочку всплывающих окон и лишних действий. Нужно добавить поиск прямо в поле — пользователь начинает вводить значение, а система предлагает подходящий вариант.
Записки как напоминания
Пользователи хранят бумажные и цифровые заметки, чтобы не забыть о сроках сдачи отчётности и других задачах. Необходимо встроить напоминания о всех предстоящих сроках и задачах прямо в рабочий процесс.
05. UX-РЕШЕНИЯ
Проектируем пространство для работы с отчётом
Создание и редактирование отчётов наряду с отправкой — один из основных сценариев работы в системе. Если с реестром документов пользователь взаимодействует несколько минут, то в редакторе может проводить значительно больше времени.
Редактор был настолько важной частью продукта, что внутри команды его воспринимали почти как отдельный продукт: у него была собственная команда, а название «Редактор» давно стало внутренним именем этого направления. И это не случайно. Здесь отчёт не просто редактируют — здесь его доводят до состояния полной готовности к отправке.
Редактор берёт на себя одну из самых критичных задач системы — помогает найти ошибки до того, как отчёт будет отправлен. Пользователь работает с данными, проверяет их, получает подсказки об ошибках и последовательно приводит документ в порядок. За счёт этого редактор становится не промежуточным экраном перед отправкой, а полноценным инструментом контроля качества.
Именно эта роль определила подход к интерфейсу: нам было важно сделать редактор не просто удобным инструментом для внесения изменений, а сильным рабочим пространством для создания и валидации отчёта.
Немного деталей
Мы превратили редактор из набора форм в интерактивную систему контроля благодаря целому ряду решений. Ниже — несколько наиболее значимых.
Модульная сборка форм
Благодаря системе компонентов и чётким правилам их применения аналитики смогли легко собирать типовые отчётные формы самостоятельно. В итоге до 60% типовых форм были собраны без привлечения дизайна.
Автосохранение и проверки
Убрали две важных боли: сомнения в сохранности данных и необходимость вручную запускать проверку на ошибки. Статус сохранения всегда перед глазами, а WebSockets позволяют проверять ошибки прямо во время заполнения каждого поля.
Центр ошибок
Собрали все ошибки в одном окне, чтобы их можно было исправлять последовательно, даже если они находятся в разных разделах отчёта. Для этого использовали сайд-модалку, которая даёт достаточно места для подробного описания каждой ошибки.
Организация работы через список дел
На главной странице вывели динамический список задач, который автоматически определяет приоритеты, подсвечивает срочное и подсказывает следующие шаги.
В первой версии главная страница строилась вокруг трёх блоков: «Срочные дела», «Входящие» и «Список отчётов». Однако только первый блок непосредственно помогал пользователю понять, что нужно сделать, а остальные скорее давали справочную информацию.
Мы объединили эти источники в единый список задач с понятным приоритетом и статусом выполнения. Теперь пользователю не нужно собирать картину дня из разных виджетов — система сама формирует для него сквозной план работы.
Единый фокус внимания
Центральное место на главной занимает Список дел. Пользователь сразу понимает, за что взяться, и последовательно закрывает задачи без лишних переходов между разделами, вкладками и внешними напоминаниями.
Прозрачный статус и приоритеты
Каждая задача снабжена актуальным статусом, дедлайном и возможностью гибкой настройки отображения. Клик по строке ведёт напрямую к целевому действию, что исключает лишние шаги и снижает риск пропуска сроков.
Упрощаем процесс подключения
Процесс подключения требовал заполнять множество полей вручную. Мы оптимизировали сценарий: автоматизировали заполнение части данных и разделили заявку на последовательные этапы.
В процессе работы заметили, что значительная часть данных для ручного ввода уже есть в открытых реестрах. Поэтому внедрили автозаполнение по ИНН: пользователь вводит его один раз, а система сама находит данные об организации и заполняет соответствующие поля.
Так мы сократили количество ручных действий и оставили пользователю только те данные, которые действительно нужно заполнить самостоятельно.
Но даже после автоматизации в заявке оставалось достаточно много информации для заполнения. Поэтому вторым решением стало разделение заявки на последовательные этапы и добавление степпера.
Было: вся заявка на одном экране
- Перегрузка информацией: пользователь заранее оценивает длинную форму как долгую и трудоёмкую.
- Сложнее ориентироваться: при большом количестве полей трудно найти конкретное поле и осуществлять навигацию.
- Труднее видеть прогресс: в длинной форме неочевидно, сколько уже сделано и сколько работы осталось.
Стало: пошаговый сценарий
- Фокус на одной задаче: каждый этап содержит только связанные между собой данные, поэтому пользователю проще сосредоточиться на заполнении.
- Понятная структура: степпер заранее показывает логику заявки и помогает ориентироваться в последовательности этапов.
- Ощущение прогресса: пользователь видит текущий шаг и понимает, сколько этапов осталось до завершения.
06. UX-ТЕСТЫ
Проверяем решения на пользователях
Чтобы не полагаться только на внутренние предположения, мы регулярно проверяли дизайн-решения на пользователях. Для каждой гипотезы проходили схожий цикл:
1. Создаём варианты: для спорных гипотез собираем несколько вариантов решения, чтобы проверить их напрямую и сравнить поведение пользователей, а также получить измеримые результаты.
2. Собираем прототипы: превращаем гипотезы в кликабельные прототипы, максимально приближенные к реальному сценарию. Это позволяет тестировать не отдельные экраны, а полноценное взаимодействие.
3. Проводим тесты: организуем встречи и наблюдаем за прохождением сценариев. Замеряем время выполнения, собираем обратную связь и фиксируем сложности, ошибки и вопросы.
4. Анализируем и решаем: собираем результаты и сравниваем варианты. На их основе принимаем решение: подтверждаем гипотезу, дорабатываем её или возвращаемся к поиску нового решения.
Баланс в методологии
80% Логика
Архитектура и ментальные модели
Основной фокус тестов — проверить, насколько архитектура и основные сценарии соответствуют реальным ожиданиям пользователей.
Что отслеживаем
Скорость прохождения сценариев, ошибки при заполнении, точки потери внимания и моменты, где пользователь начинает сомневаться в дальнейших действиях.
Критерии успеха
Пользователь самостоятельно и без ошибок проходит сценарий за оптимальное время.
20% Магия
Эмоциональный отклик и микро-UX
Оставшуюся часть внимания направили на детали, которые делают опыт более интуитивным, понятным и комфортным для пользователя.
Что отслеживали
Реакцию на микроанимации, переходы, статусы автосохранения и другие элементы обратной связи.
Критерии успеха
Пользователь чувствует контроль над процессом, не испытывает лишней тревоги и позитивно реагирует на детали интерфейса.
07. ИЗМЕРЕНИЕ ЭФФЕКТА
Отслеживаем результаты
Для мониторинга показателей продукта мы регулярно выгружали метрики с бэкенда через внутренний сервис Web-регистратор.
Мониторинг помогал не только оценивать результат внедрённых решений, но и находить новые точки роста. Если на определённом этапе сценария мы замечали аномальный отток или изменение поведения клиентов, то возвращались к этому участку, искали причину и формировали новую гипотезу.
Так аналитика становится частью постоянного цикла работы: метрика → наблюдение → гипотеза → решение → повторная проверка. Такой подход позволяет не разово оценивать результат, а постоянно находить точки для улучшения продукта.
Какие цифры получили
Чтобы оценить эффект, сравнили показатели старой версии продукта с результатами Астрал Отчёт 5.0 в течение полугода после запуска.
Было
Старый продукт
18 мин 36 сек – среднее время взаимодействия с интерфейсом при отправке типовой декларации по НДС.
86% – доля отчётов, успешно принятых ФНС с первой попытки.
58% – доля пользователей, успешно завершающих заявку на подключение с первого раза.
463 тикетов/мес – среднее число обращений в техподдержку из-за проблем с интерфейсом.
Стало
Астрал Отчёт 5.0
11 мин 54 сек – среднее время взаимодействия с интерфейсом при отправке типовой декларации по НДС.
92% – доля отчётов, успешно принятых ФНС с первой попытки.
74% – доля пользователей, успешно завершающих заявку на подключение с первого раза.
207 тикетов/мес – среднее число обращений в техподдержку из-за проблем с интерфейсом.
08. ЗАКЛЮЧЕНИЕ
Финальные мысли
Проект запомнился тесной работой с аналитиками: строгие законодательные нормы напрямую влияли на проектирование. Мы не только решили бизнес-задачи, но и создали систему правил, которые позволили масштабировать продукт без постоянного участия дизайна.
Чему научился:
- Улучшил навыки тайм-менеджмента при работе с несколькими командами: активно участвовал в планированиях, демо и дейликах разных команд, сохраняя фокус на своих задачах и сроках.
- Получил опыт проектирования в максимально формализованной сфере, где требования часто продиктованы законодательством. Если форма должна содержать 60 полей, задача дизайна — не спорить с этим, а сделать такой сценарий максимально понятным для пользователя.
- Стал лучше понимать консервативную возрастную аудиторию: привычные паттерны, причины осторожного отношения к изменениям и важность предсказуемого взаимодействия.
Что бы сделал иначе:
- Раньше подключил бы продуктовые метрики. В суете первых релизов до них часто не доходили руки, хотя чем раньше появляются данные, тем быстрее можно находить возможности для улучшения продукта.
- Больше взаимодействовал бы с маркетингом. Продвижение не входило в мою зону ответственности, но напрямую влияло на продуктовые показатели — в будущем хотелось бы плотнее связывать UX и маркетинг.
