Как я проектировал интерфейс для оптимизации взаимодействия Оператор-клиент в Тинькофф
Или коротко — тестовое задание в для отбора на стажировку
В качестве задачи нужно было продумать и сделать сценарий взаимодействия Оператора и клиента и показать интерфейс
Что было сделано
- User Story Map на основе user-stories
Почему? USM инструмент для работы с User Stories - Выписаны и продуманы проблемы на пути оператора
Почему? Чтобы оптимизировать интерфейс и уменьшить количество проблем - Структура интерфейса
Почему? Чтобы не упустить какие-либо функции интерфейса - Userflow — пользовательский сценарий
Почему? Показать пошаговое взаимодействие с интерфейсом — сценарий - Прототип для интерактивного взаимодействия с разработанным интерфейсом
Почему? Для тестирования интерфейса на какие-либо возможные проблемы
Сколько времени я инвестировал в проект?
5 дней работы и изучения материалов. Около 12 человеко-часов работы и изучения.
Возможно, будет вопрос — почему инвестировал?
Эта задача познакомила меня с одним из самых используемых инструментов в UX дизайне — User Story Mapping и научился работать с ним.
И не забываем о сложностях на пути.
Если тяжело идти, значит ты двигаешься вверх 🐺
Как все началось
По окончании новогодних праздников, листая инстаграм я наткнулся на рекламу Тинькофф о начале стажировки. К сожалению, скриншот не сохранил. Я помню, что несколько месяцев назад видел подобное объявление, но для программистов и думал “было бы здорово попробовать, если добавят отбор для дизайнеров”. Я был услышан :)
Я сразу зарегистрировался на edu сайте Тинькофф и мне было доступна анкета и тестовое задание
За работу или день 0
Первым делом я изучил тестовое задание:
Задача — представить оптимальный сценарий взаимодействия оператор-клиент в интерфейсе
Были даны user-stories, а информация о том, что только когда карта готова, Оператор совершает звонок.
Это означало, что оператор в любом случае звонит клиенту для подтверждения данных и оформления заявки
Запомните эту информацию.
*СПОЙЛЕР* я не вчитался в нее и запомнил :)
Первый день — первые сложности
В первый день работы я решил разобраться в материале и инструментах, которыми предстоит воспользоваться.
Я знал, как работать с Job stories, но не было опыта с user stories(US). Это означало, что мне предстоит понять, что такое US и как с ними работать. Предварительно я понимал, что инструменты похожи.
Но так как инструмент не был мне знаком я опасался того, что неправильно понял задачу.
Итак, я сформулировал задачу:
У нас есть user story, нужно проверить каждую историю, найти барьеры и преграды и подумать над оптимальным сценарием, то есть — user flow с элементами интерфейса. Все нормально, логика есть, думал я.
ИНСАЙДЕРСКАЯ ИНФОРМАЦИЯ:
Прочитал задачу — прочти ее еще раз, а потом сам сформулируй то что понял по шагам, подумай о сложностях, которые могут быть.
User story
Я решил изучить в чем же отличие user story от job story. Итак, мои выводы:
User story — мы фокусируемся на пользователе и его целях или мотивации использования продукта
Job story — мы фокусируемся на ситуации, в которой пользователь использует продукт. Причем Job story может дать больше деталей о мотивации и ситуации пользования продуктом.
На этом моя работа на день была закончена из-за того, что меня попросили уменьшить сроки выполнения проекта и я решил использовать время следующих двух дней, чтобы после него до 18 числа заниматься заданием.
Ввиду работы в команде поддержки Tilda время у меня было только вечером, поэтому и сроки выполнения по дням были дольше, чем могли бы быть.
Надеюсь это не звучит как оправдание, ведь какой в них толк :)
Твои действия — твоя ответственность.
На следующий день, несмотря на то, что я перенес работу над тестовым, в голове у меня была одна мысль — правильно ли я понял задачу.
Ох, уж эта интуиция
Так как это жизнь, а не университет я решил спросить у коллег по обучению, правильно ли я понял задачу и написал вопрос в чат, где мои выводы подтвердились.
В будущем, чтобы окончательно подтвердить гипотезу о процессе работы я читал статьи и видео по инструментам, поэтому был уверен в правильности постановки задачи
ИНСАЙДЕРСКАЯ ИНФОРМАЦИЯ:
Не бойся спрашивать опытных коллег — это помогло мне сократить время на обработку информации, ведь я смог быстрее подтвердить свои выводы.
Второй день работы — интервью и user story map
Мои задачи:
- Первым делом нужно понять, какие проблемы есть на пути и выписать эти преграды
- Нужно подготовить вопросы и позвонить операторам, чтобы узнать у них о процессе взаимодействия с интерфейсом и коммуникация с клиентом. Возможно, их слова помогут сгенерировать идеи.
Держите в голове то, что на тот момент я еще не додумался о том, задача в проектировании сервиса с 0, а не улучшение текущего
Интервью
Во время изучения процесса оформления мне позвонили и я решил провести небольшое интервью с оператором.
Итак, представляю вам интересные идеи и выводы из интервью с оператором:
- Если что-то незаполненно или оператор видит дубли — происходит звонок для уточнения деталей. Чаще у иностранцев
ИДЕЯ: добавить тултипы для иностранцев(или для всех), где будет отмечено, что нужно вводить, чтобы уменьшить количество некорректных данных - Если звонят, то для подтверждения данных.
- Если все корректно, то звонка нет
- Если документы не успевают подготовиться, то звонят и предупреждают и переносят
ИДЕЯ: добавить статус готовности документов ( но для кого? если документы не готовы, то оператор позвонит) - Если карта куда-то не доставляется, то тогда звонят и просят приехать по ближайшему доступному адресу
ИДЕЯ: Показывать зону доставки. Если такая возможность есть, то можно показывать карту с зонами, наподобие покрытия связи - Люди часто забывают о заявках и при звонке сбрасывают
ИДЕЯ: добавить напоминание о заявке пользователю по типу “некоторые данные заполнены некорректно, в ближайшее время вам позвонит оператор Тинькофф, чтобы исправить и назначить встречу”
Оператор звонит сразу после отправки заявки, если какие-то проблемы - Лучшая коммуникация — ее отсутствие.
ИДЕЯ: Для этого нужно минимизировать некорректные заявки. То есть оптимизировать форму заполнения заявки - Из неудобств отметили общение с вышестоящими коллегами для передачи обращений. Деталей не уточнил
Надеюсь, информация выше пригодится вам в проектировании удобных интерфейсов!
ИНСАЙДЕРСКАЯ ИНФОРМАЦИЯ:
Интервью — хорошая вещь.Важно заранее подготовить вопросы и обозначить проблему, чтобы не ходить вокруг.
Будем считать, что звонок оператору — изучение конкурентов и часть исследования :)
Работаем дальше!
User Story
Как я написал выше, мы фокусируемся на пользователе, его целях и мотивации при использовании продукта
Имея перед собой user story следующий мой шаг найти общее в целях и действиях пользователя, чтобы на их основе сгенерировать идеи по функционалу интерфейса
В этом случае на сцену выходу инструмент User Story Map(USM)
В user story map мы можем спланировать функции продукта, который можно внедрить в проект или записать в бэклог для будущих обновлений, на основе мотивации или целей пользователя.
Вводные User Story я объединил на несколько клюевых этапов или целей:
- Связаться с клиентом
Первичная цель, так как без нее не будет отработки нужного сценария - Проинформировать пользователя об оформленном продукте
Чтобы напомнить человеку, что он оформил, ответить на вопросы, которые могут возникнуть - Оформить доставку
Конечная цель сценария —оператор передает информацию по клиенту в отдел доставки для последующей передачи продукта в руки клиента.
Кто-то может спросить, почему не CJM?
USM подойдет больше чем CJM в виду того, что у нас будет связь с user story напрямую. CJM подойдет для клиента, нежели для оператора, так как в CJM мы рассматриваем точки контакта пользователя с сервисом и в ней мы описываем его взаимодействия и проблемы.
Резюмируем
Меня посещали мысли, что я что-то делают не так. Как мы узнаем позже — не зря!
Вот какие мысли и идеи были у меня в голове:
- Немного нервничаю из-за того, что не пользовался инструментом и боюсь ошибиться. Но понимаю, что это лишь небольшие преграды.
- Меньше теории больше дела. Этот пункт выходит из первого — я все читал и читал, но никак руки в дело не пустил. В итоге просто записал все, что понял в свою базу знаний и набросал небольшой скелет USM
- Взаимодействие оператора с клиентом чаще всего возникает из-за каких-либо недочетов в заявке. Значит нужно сделать так, чтобы вероятность заполнения заявки правильно была выше.
- Частая проблема — клиент сбрасывает трубку или не отвечает. Думает, что звонят мошенники. Нужно подумать, как решить данную проблему.
Для меня оптимальный вариант взаимодействия оператора и клиента, когда его нет. То есть пользователь заполняет все корректно, видит мгновенный фидбек от системы, что заявка в работе и будет доставлена тогда-то и в такое-то время — ожидайте звонка от курьера. Поэтому в будущем взаимодействие Оператор-клиент можно будет делать только для проблемных заявок
Наступил третий день работы — озарение
При составлении USM я понял, что я могу не видеть полноценной картины, поэтому я решил позвонить в поддержку и задать вопросы, которые я выписал. Пока ожидаю обратный звонок решил поработать с той информацией, которая есть.
А вот и ошибочка
Спустя несколько часов работы я решил отдохнуть и подумал, а что, если мне не позвонят. В моей голове было предположение: если я не узнаю ответы на свои вопросы, то не смогу сделать задание. Это означало одно — тут что-то не так и мне надо изменить направление движения
Я перечитал задачу и тут мне пришел вполне возможный вывод — мне не нужно спрашивать операторов, потому что я не пытаюсь улучшить текущий продукт, а должен предложить свой вариант.
Также спустя время я понял, что акцентирую внимание на результатах ответа оператора — они звонят только по некорректным заявкам.
В задаче же у нас в любом случае есть звонок оператора. По этой причине нужно было немного по другому обдумать USM
Но, у меня в запасе еще два дня, поэтому все нормально. Черновой USM у меня есть, нужно было пройтись по ней и исправить косяки.
Наверное, большее наслаждение я получил не от выполненной работы, а от осознавания своей ошибки и корректирования результатов. Для меня это была уже победа!
Доработку USM я оставил на следующий день, чтобы со свежей головой пройтись по работе.
День четыре — финалим работу
Передо мной есть видение того, что нужно сделать, значит осталось обозначить задачи и hard work!
- Исправить USM
Отобрать те функции, которые максимально повлияют на процесс назначения встречи - Составить структуру
Структура поможет увидеть сверху будущий прототип - Составить userflow
Сценарий взаимодействия пользователя с интерфейсом
USM
USM была доработана, убрал функции, которые были неактуальны, обозначил проблемы и идеи по их решению.
Сторис были объеденены в под общую цель этапа и расписаны на детали и функционал.
Структура
Структура помогла мне увидеть, что не все функции нужны: что-то можно убрать, что-то обобщить и выводить единый результат
Я решил сделать интерфейс наподобие работы с тикетом, как это сделано в системе Intercom, чтобы пользователю автоматически приходили заявки, он видел список, нажимал и попадал на подробную страницу с информацией, где справа закреплена основная информация, включая кнопку, а слева то, что ему предстоит сделать
Также была мысль о том, а что если пользователь захочет выбрать другой продукт. Сначала я думал добавить возможность смены продукта, но потом решил, что лучше сделать это позже, если будет спрос
Userflow
Так как фрейм получился объемный, то прикрепить изображение не получится, поэтому вот ссылка для ознакомления
Я показал сценарий взаимодействия Оператор-клиент после того, как карта готова к доставке.
Интерфейс был спроектирован в соответствии с USM и структуре. Во время проектирования от некоторых идей я отказался, например, добавить другой продукт в заявку или отправлять СМС пользователю о том, что заявка на доставку оформлена — пусть это сделает система автоматически.
Задачи на день были выполнены. Оставалось привести все в порядок и можно отправлять.
Перед тем, как пойти спать я решил пересмотреть user-flow спустя несколько часов после окончания, так как взгляд был свежее.
Я исправил некоторые несостыковки, по новой продумал выпадающее меню и календарь.
Также пришла мысль, что стоит сделать интерактив, чтобы подробнее раскрыть идею и, заодно, провести тестирование — все ли будет понятно.
Поэтому в течении 30 минут я собрал интерфейс так, чтобы было удобно сделать связи и интерактив был готов. Я дал его на тест девушке с задачей оформить заявку в соответствии со сценарием.
Так как я до этого ей на словах рассказывал видение интерфейса она справилась без каких-либо недопониманий.
ИНСАЙДЕРСКАЯ ИНФОРМАЦИЯ:
Очень полезно брать перерыв в работе и отвлечься на что-то другое. Я провел время с девушкой, мы погуляли, посмотрели кино и отдохнувший мозг придумал идею — интерактив и исправил недоработки
Резюме
На тот момент я видел две проблемы, которые могут быть в прототипе — наличие адресов и кнопка Завершить звонок.
1. Адреса
Откуда у нас может быть информация по рабочему и домашнему адресу. Это может получиться только после оформления заявки и последующего пользования банком. Если подобные данные не будут собираться в форме, то, в таком случае, в интерфейсе будет только две возможности:
1) Увидеть адрес, котоыре пользователь предоставил в форме
2) Добавить новый адрес
2. Завершить звонок
Я проектировал кнопку с расчетом на то, что будет предварительное ознакомление Оператора с интерфейсом, чтобы оператор вместо Оформления доставки не нажал завершить.
Суть кнопки в том, что, даже если пользователь отключился, Оператор все равно должен нажать завершить — тогда произойдет сброс разговора и появится попап с выбором причны завершения. Это задумано с той целью, что при завершении оформления доставки пользователь может отключиться, а Оператор не нажмет на кнопку Офомрления доставки.
Поэтому, даже после прощальных слов, Оператор будет иметь возможность Оформить доставку
Если первую проблему можно решить путем добавления соответствующих полей в форме, либо удалением элементом, то вторую можно оптимизировать путем инстурктажа Оператора, либо, самый вероятный — убрать кнопку Оформить доставку и после нажатия на Завершить звонок будет вторая нопка “Оформить доставку”
День пятый — отправляем!
Я прошелся по своим мыслям, чтобы исправить недочеты в словах, написать свои мысли в P.S. и сделать Резюме проекта, чтобы вы увидели Что было дано, Что использовал, Как сделал и Почему.
Ссылка на фигму была прикреплена, кнопка Отправить была нажата…
Теперь оставалось ждать месяц в ожидании результатов.
Рефлексия
Оглядываясь на проделанную проекту я понял, что это была отличная практика, не важно, получится у меня или нет.
Сначала я хотел написать статью, а потом результат, но решил, что будет лучше оставить последнюю часть до провозглашения результатов.
К сожалению, я не прошел, но я не расстроился. Ниже в выводах я напишу возможные причины, по которым я мог не пройти.
Самое лучшее, что я могу сделать в этом случае — порефлексировать.
Я протестировал свои skillz, попробовал тестовое задание, а сам кейс впишется в портфолио.
Вместо полотна текста я выделю положительные моменты и моменты, которые нужно будет проработать. Не вижу смысла искать минусы, ведь задание я делал для себя.
Итак, плюсики:
- Я попробовал себя в тестовом задании и перешел границы комфорта.
- Этот пункт выводится из пункта выше — страх. Я боялся начинать, думал, что опыта недостаточно и мне еще рано. Но после проделанной работы я укрепил текущие навыки, изучил новое.
- При проведении исследований нужно абстрагироваться от своего видения и смотреть конкурентов. Благодаря работе в поддержке Тильды, я на своем опыте прочувствовал возможный вариант интерфейса. Я изучил наш интерфейс и нашел идеи, которые можно принять в работу.
А теперь к тому, что нужно доработать и изучить
- Figma. Мне кажется это одна из основных причин, по которым моя работа могла отлететь.
Я не пользовался авто-лейаутами, не создал UI kit, а делал все во фреймах и группах внутри фрейма.
Почему так не нужно делать?
Опытные дизайнеры сразу ответят на этот вопрос, а для таких же новичков как я объясню:
У интерфейса есть несколько состояний и копировать и что-то вручную изменять долго. Функции граф. редакторов позволяют автоматизировать этот процесс — auto-layout, компоненты, привязки(constraints).
ИНСАЙДЕРСКАЯ ИНФОРМАЦИЯ:
Изучайте продвинутые возможности ваших инструментов, ведь они могут показать ваш уровень.
- UX инструменты. Не уходить спать, пока не узнаешь что-то новое, лучше всего из твоей сферы.
Я познакомился с новыми инструментами, но во время обучения/изучения я увидел, сколько еще предстоит изучить. - Опыт. Хотя бы 1–2 раза откликаться на вакансии и пробовать себя в тестовых заданиях. Они помогут определить слабые стороны, которые можно будет доработать
На этом все?
Я надеюсь, описание моей работы будет полезно всем начинающим ребятам и буду рад, если более опытные коллеги укажут на мои недочеты — я открыт к любым предложениям :)
Не останавливайтесь, не думайте, что вы все знаете, пробуйте и действуйте.
Закончу на цитате великого тренера великой команды Сэр Алекс Фергюсон
Никогда нельзя думать, что ты лучший в своем деле.
Высокомерие — не качество, а препятствие на пути к успеху
Спасибо за внимание!
Пишите, звоните. Лучше пишите :)
vk
tg
inst
tenchat
что-то наподобие CV(скоро будет годно, честно честно)
