Редизайн без кошмара: как мы избавились от старых процессов

Привет, VC! Меня зовут Ксюша, я продакт-менеджер в команде КРИТ. Недавно мы полностью обновили интерфейсы модульной платформы КРИТ ТОРО – системы со встроенным ИИ для управления всем циклом технического обслуживания и ремонта (ТОиР) на промышленных предприятиях.

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

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

В департаменте разработки у нас больше 60 человек, мы развиваем несколько продуктов, и основной фокус сейчас на платформе КРИТ ТОРО для централизации данных и стандартизации операций ТОиР. Система поддерживает работу как на стационарных, так и на мобильных рабочих местах

До редизайна картина была классической, зоны ответственности часто размыты, а синхронизация между продактами, аналитиками, дизайнерами и разработчиками слабая. Аналитик две недели писал подробное ТЗ, дизайнер исчезал на месяц и выдавал макеты, разработчик смотрел и говорил: «API так данные не отдает, это нереализуемо». Задача уходила в переделку, мы теряли еще две недели, и цикл повторялся.

В результате мы столкнулись с тем, что задачи затягиваются, установленные сроки сдвигаются, а интерфейс нравился разве что дизайнеру.

Когда мы запустили полномасштабный редизайн всей системы, эти проблемы обострились до предела. Теперь мы работаем иначе, и вот что сработало.

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

Раз в неделю собираем дизайнеров, разработчиков, аналитиков, тестировщиков и иногда реальных пользователей. Жесткой повестки нет. Показываем наработки, собираем гипотезы, смотрим на проблему с разных сторон. Разработчик сразу говорит, что будет долго, а пользователь, что «тут эта кнопка вообще не нужна».

Когда идея утверждена, собирается только три человека: дизайнер + аналитик + разработчик. Митап длится 15–20 минут, и разбираем только конкретные вопросы. Никаких лишних участников, а только те, кто будет делать задачу.

На одной из таких встреч разработчик глянул в API и сказал: «Данные для этой таблицы грузятся 3 секунды. Если мы ее поставим на главную, пользователь уйдет». Прототип переделали за час, а не переписывали бэкенд через месяц.

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

Лайфхак: не берите всю команду на обсуждение нюансов. Для идей собирайте всех, а для деталей только тех, кто будет этим заниматься.

Раньше мы давали дизайнеру задачу: «нарисуй личный кабинет» и прикрепляли набор вайрфреймов от аналитика. Дизайнер оказывался в клетке, ему говорили не только ЧТО рисовать, но и КАК примерно это должно выглядеть. Мы тратили время на отрисовку этих скелетов, а потом дизайнер тратил время на то, чтобы вписать в них нормальный UX.

Сейчас мы с первого дня сажаем дизайнера слушать звонки клиента и читать обращения в поддержку с платформы КРИТ ТОРО. Когда пользователь жалуется: «Я каждый раз ищу этот отчет в недрах меню», дизайнер сразу предлагает вынести его на главную и добавить уведомление о новых данных. Аналитик даже не тратит время на описание сценария.

Раньше мы теряли 2-3 дня на подготовку аналитиком ч/б макетов и еще столько же на переписку, почему дизайнер от них отступил. Дизайнер рисует сразу живой интерфейс, опираясь на реальные боли пользователей.

Теперь мы берем сотрудника не из разработки, сажаем перед интерфейсом, даем задачу и просим комментировать вслух. Записываем экран и все.

Один такой тест показал, что кнопку «Экспорт отчета» пользователь ищет 40 секунд и кликает в три неверных места (она пряталась в выпадающем меню). Вынесли кнопку отдельно, и время выполнения упало до 3 секунд.

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

Мы перестали влюбляться в самый первый макет. Теперь дизайнер рисует минимум два варианта:

Вот тут дизайнер подготовил варианты главной страницы мобильного приложения для КРИТ ТОРО.

Первый экран заточен под быстрое создание заказов и сканирование меток (удобно для инженера на объекте).

Второй – под управление заказами.

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

А вот тут мы тестировали модальные окна назначения функционала на странице «Оборудование». Сделали два варианта с похожим функционалом, но разными возможностями. Показали пользователям и выбрали тот, где использование понятнее всего.

Лайфхак: тестируйте варианты не только на внутреннем заказчике, но и на конечных пользователях. То, что кажется дизайнеру «слишком», часто оказывается самым удобным.

Мы переосмыслили подход к ИИ в команде. Теперь используем нейросети не для генерации красивых картинок, а для жесткой проверки: контрастности, читаемости, размера шрифта.

Так, ИИ подсветил, что текст в футере имеет контраст 2.8:1 вместо требуемых 4.5:1. Поправили и сразу улучшили доступность для людей с нарушениями зрения. Заодно нашли еще три подобных недочета по всей системе.

Лайфхак: не спрашивайте ИИ, красивый ли у вас дизайн. Используйте Contrast Checker от WebAIM или просите ChatGPT/Grok проанализировать цвета по стандартам. Это бесплатно и экономит часы правок.

Весь наш процесс превратился в короткие циклы: прототип → тест → правки. Мы не ждем идеала с первого раза, и стараемся ловить ошибки, когда они стоят копейки (на бумаге или в Figma), а не миллионы (в продакшене).

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

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

Вот теперь все, спасибо за внимание, VC! На вопросы и комментарии с удовольствием отвечу :)