Как мы завалили фичу и чему научились за это время, или Почему идеи без исследований — это домыслы

Всем привет. Меня зовут Яна Степаненко, я руководитель команды дизайна AI-сервисов Т-Банка. Сегодня хочу рассказать об одном провальном кейсе: как мы до конца не исследовали аудиторию, положились на свои знания об их болях, потратили полтора года, признали ошибку и начали с начала. 

«Без исследований ваши гипотезы — это домыслы»: исследовательская культура Т-Банка в двух словах

Успех Т-Банка зависит от многих факторов, но один из них — то, что нашими сервисами удобно пользоваться. Это удобство создавали в том числе дизайнеры, поэтому у нас большое влияние в компании — не меньше, чем у аналитиков и продактов. Если клиент говорит, что ему неудобно, мы меняем это. 

В изменениях важную роль играют исследования. Они помогают нам, дизайнерам, не терять контакт с пользователем, не воспринимать его как цифру в метриках и подбирать весомые аргументы, чтобы обосновать команде необходимость каких-то доработок.

Но что может случиться, если ты — опытный дизайнер, знаешь свою аудиторию и продуктовая команда тебе доверяет, а ресурсы ограничены и хочется быстрее и больше? 

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

В продукте были две аудитории, об одной мы забыли

В декабре 2020 я пришла в Т-Банк на позицию продуктового дизайнера на проект «Речевая аналитика», или TQM. На этом проекте я занята до сих пор, но последние два года совмещаю его с работой руководителя команды дизайнеров. 

Платформа работает на внешнем рынке как B2B-решение и в нашей компании — мы пользуемся ею с 2018 года. С ее помощью можно за час проанализировать тысячи коммуникаций и понять, где что-то пошло не так и на что стоит обратить внимание. 

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

В TQM много ролей и разных подразделений, но, грубо говоря, всех можно поделить на две глобальные: те, кто задает стандарт, — специальные отделы развития качества продукта или сервиса (продажи, обслуживание на линии и так далее) и те, кто ему следует (операторы на линии и руководители групп операторов).

В первые годы команда, отвечавшая за TQM, старалась дать как можно больше аналитических инструментов для того, чтобы «задающие стандарт» могли понять, где с сервисом все в порядке, а где что-то западает. Появились классные технологичные фичи: ML-модель, которая умеет находить негативные эмоции в речи, разнообразные отчеты, поиск звонков/чатов, на которые стоит обратить внимание.

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

В середине 2021 года мы с командой решили проработать проблему с обратной связью и начали проектировать для операторов и их руководителей экран метрик и рекомендаций. Хотелось, чтобы каждый пользователь получал персонализированную информацию о работе и четко понимал, где он хорош и как исправить западающие зоны. TQM как платформа научилась бы быстро генерировать полезные сотруднику данные, доступные 24/7. Руководители операторов смогли бы увидеть сводную информацию по сотрудникам и лучше представлять уровень компетенций команды. 

И вот мы вместе с аналитиком пробежались по потенциальным пользователям. Но совершили серьезную ошибку. Мы прошлись только по «задающим стандарт» — по тем самым специальным отделам развития качества всех подключенных к платформе продуктов — и не провели ни одного вдумчивого интервью с операторами или их руководителями.

Из-за большого количества ролей и бизнес-линий подобрать универсальные показатели не вышло бы. Нужны были некие конструкторы: отдельно под метрики, отдельно под рекомендации, где коллеги могли бы кастомизировать все под себя, отсылая нам JSON-ы через DWH. Это само по себе становилось технически сложной задачей. Добавим к этому ограниченность ресурсов и желание быстрее запуститься. Еще мы были уверены, что знаем, что нужно «операционке». Уже понимаете, чем закончится история?

Пока со всеми всё обсудили, пока нарисовали макеты, пока разработали… Ушло месяцев пять. Раздел метрик и рекомендаций сделали стартовым. Конструктор рекомендаций сделали быстро, с метриками пришлось повозиться. 

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

Жизнь шла своим чередом. Метрики заработали, рекомендации заработали, все отправляется, считается, отображается — и хорошо. 

Провели исследование и поняли, что наша работа не решает проблему до конца

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

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

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

История со счастливым концом

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

Пользователи позитивно восприняли доработки: они стали пользоваться разделом и увидели в нем пользу. К сожалению, я пока не могу показать сам макет, так как функциональность не раскатана на B2B-решение, но могу показать реакцию коллег.

Выводы

Если бы мы сразу поговорили со всеми заинтересованными, не потратили бы так много сил. 

До сих пор считаю этот кейс своей ошибкой. На момент старта работы в Т-Банке у меня уже было больше пяти лет опыта работы, из которых почти три — в продуктах. Моя задача как дизайнера была охватить все роли, несмотря на ограничения, сложности и желание поверить на слово.

Исследования — это важно, ими нельзя пренебрегать. Да, возможно придется подключать к ним пару коллег и настраивать процесс планирования фич так, чтобы у вас было 2—4 недели на полноценный анализ. По моему опыту, лучше потратить время нескольких человек, чем зря выкинуть результат работы всей команды за полтора года. Время на исследования — не расход, а инвестиция в надежность и пользу ваших решений.