Привет! Меня зовут Сергей, я дизайнер в команде, которая делает внутренний инструмент для сотрудников Домклик — тех, кто каждый день работает с клиентами и помогает им оформить или сопроводить ипотеку.
Наш продукт не увидит внешний пользователь, но он напрямую влияет на скорость, точность и удобство работы с ипотекой. Если что-то в интерфейсе неудобно, то это отражается не только на работе специалиста, но и на том, как быстро клиент получит одобрение, подпишет договор и купит квартиру.
Расскажу, как мы подходим к тестированию дизайна, какие методы используем, какие сложности бывают и что из этого получилось.
Зачем тестировать внутренний дизайн?
Казалось бы, внутренний продукт используют обученные сотрудники, значит, «и так разберутся». Но это ловушка. Если интерфейс запутанный или перегруженный, то сотрудник тратит больше времени, делает больше ошибок, устаёт быстрее. В результате:
заявки оформляются медленнее;
возрастает нагрузка на поддержку;
ухудшается опыт конечного клиента.
Поэтому мы тестируем каждый шаг — от первого макета до финального экрана, — чтобы убедиться: всё работает, понятно и помогает, а не мешает.
Как мы тестируем: наши подходы
Dogfooding: пробуем всё на себе
Прежде чем показать результат задачи заказчику, мы сами проходим пользовательский путь. И не просто «посмотрели», а реально пробуем заполнить заявку, найти клиента, изменить статус сделки. Это помогает быстро выловить очевидные проблемы: не те кнопки, неочевидные действия, лишние шаги.
Usability-тестирование на прототипах
Собираем прототип в Figma и даём сотрудникам из команды продаж или сопровождения пройти реальные задачи. Мы не объясняем, что делать, просто наблюдаем и фиксируем:
Где затык?
Какие действия кажутся неочевидными?
Где человек делает шаг назад или путается?
Пять коротких сессий часто дают больше, чем неделя обсуждений в чате.
Сравнительное тестирование
Иногда есть два варианта одного экрана. Мы показываем оба и спрашиваем, какой проще, логичнее, понятнее. Иногда решения, кажущиеся очевидными дизайнерам, не срабатывают в реальности. И наоборот — простейший вариант оказывается самым эффективным.
Аналитика
После запуска мы смотрим, как пользователи реально работают:
Сколько времени тратится на задачу?
Где чаще всего возвращаются назад?
Какие поля пропускают или заполняют неправильно?
Это позволяет улучшать продукт уже после релиза — не вслепую, а на основе данных.
Отдельно хотелось бы поговорить о гемба-наблюдении. Как мы идём в поля и смотрим на дизайн в бою
В клиентских продуктах дизайнер редко может понаблюдать за «живым» использованием интерфейса. Мы видим поведение через метрики, карты кликов или обратную связь. А вот во внутренних продуктах у нас есть роскошная возможность: прийти в отдел, сесть рядом с пользователем и посмотреть, как он работает.
Как это происходит:
мы договариваемся с отделом (например, сопровождения сделок);
садимся рядом с сотрудником на час-два;
просим просто работать, как обычно, а мы наблюдаем:
где он замирает?
где использует костыли?
какие хаки применяет?
что раздражает?
где вспоминает «как в прошлый раз делал»?
Иногда одно такое наблюдение даёт больше выводов, чем пять «глубинок». Мы фиксируем проблемы, задаём уточняющие вопросы, и в итоге получаем честный, живой взгляд на интерфейс — без гипотез, прямо из поля.
Пример: во время одной из гемба-сессий мы наблюдали, как сотрудник, работая с заявкой, постоянно листал экран туда-сюда. Оказалось, что при наличии более двух участников сделки данные «уезжают» вниз, и чтобы свериться с информацией по каждому человеку приходилось всё время возвращаться в начало и обратно. На словах никто не жаловался — просто привыкли. Но на практике это добавляло раздражение и отнимало время. Мы вынесли второстепенных участников в компактный спойлер-блок, чтобы основное внимание оставалось на главных участниках, а остальные были доступны по клику.
Результат: интерфейс стал чище, а сотрудники перестали «ловить» нужные данные листанием.
Почему гемба — это не просто «сходил, посмотрел»:
мы фиксируем реальные паттерны использования;
получаем контекст работы: задачи, ограничения, сроки;
видим «боли», которые не звучат в интервью;
и просто становимся ближе к людям, для которых дизайн создаём.
Гемба — это когда дизайн выходит из макета и попадает в жизнь. И если ты хочешь сделать полезный продукт — туда идти надо обязательно.
Что важно помнить при тестировании внутреннего продукта
Даже один лишний шаг в интерфейсе — это десятки лишних часов на команду.
Сотрудники привыкают к неудобному, но это не значит, что их устраивает.
Чем ближе дизайнер к пользователю, тем лучше продукт.
Аналитика и наблюдение — лучшие друзья UX.
Вывод
Тестировать нужно не только клиентские сервисы. Внутренние продукты — это тоже продукт, только с другими задачами и другой ценой ошибки.
Мы в Домклик видим в тестировании способ не просто улучшить интерфейс, а сделать так, чтобы сотрудник работал быстрее, спокойнее и увереннее. А значит — клиент тоже получит лучший сервис.
