Я школьник это что-то вроде Todoist, Trello и календаря, только для школьников.
В приложении они могут пользоваться электронным дневником, следить за своей успеваемостью и получать подсказки о том, на какие предметы нужно обратить особое внимание. Все по-серьезному: job story и продуктовый подход на домашке и табелях успеваемости.


Приложение разработано в Центре цифровой трансформации Татарстана. Как все было рассказывает руководитель проектов и продуктов цифровизации Булат Габдрахманов.


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

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

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

Чтобы их проверить, мы пошли к школьникам, родителям и учителям и вовлекли более 500 человек на интервью, фокус-группы, воркшопы и usability-тестирования. Спрашивали о том, как проходит обычный день в школе: как дети добираются до нее, что делают на переменах, как возвращаются домой. А еще поговорили про нагрузку, домашние задания, олимпиады и секции.

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

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

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

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

CJM для школьников: путь от дома до успеха
После исследования мы выкатили первую версию CJM: как школьники собираются в школу, как идут до нее, чем занимаются на уроке (никто ведь не слушает все 45 минут учителя) и как ведут себя на перемене.


Вы тоже любите хвастаться, какую большую и красивую CJM вы нарисовали?

Например, мы знали что в приложении должно быть домашнее задание, но реализовать мы могли по разному: список, календарь, напоминание. Выбрать решение помогла job-story: Когда у меня есть достаточно свободного времени / Я хочу сделать много уроков сразу / Чтобы иметь больше свободного времени на неделе.

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

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


Все потребности мы формулируем так: контекст что я хочу для чего это нужно

Мы понимали, что времени у нас в обрез: мы нарисовали CJM в начале июня, а приложение должно быть готово в сентябре. Итого у нас 2,5 месяца, из которых полмесяца это тестирование, но ведь не написано ни одной строчки кода. Поехали!

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

Бороться с соблазном сделать бесполезную фичу помогала система приоритезации задач, которую мы частенько прорабатывали на командных воркшопах. Чем выше стикер и больше голосов от команды, тем приоритетнее фича.

В Татарстане есть портал edu.tatar.ru на котором ведется электронный дневник, но это web-решение, которое не всегда удобно для школьников. Подобные мобильные приложения уже были, но все неофициальные и работали плохо.

Нам хотелось сделать качественное приложение с точки зрения UX и дизайна. С этим проблем не было, но, как это бывает с подобными проектами, сложности возникли с интеграцией. edu.tatar.ru был разработан еще в 2009 году backend на PHP, API не было, поэтому пришлось попотеть.
Всего на разработку приложений для Android и IOS ушло два месяца.

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

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


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

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

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

Первые интерактивные прототипы еще в июле мы обсуждали со школьниками в зуме. Они проходили по интерфейсу, а мы делали тест-юзабилити: просили выполнить задания, посмотреть домашнее задание или расписание.

Работать со школьниками клево мы приятно удивились, насколько они вовлечены в процесс. Надеемся, что этот опыт сделает из них классных UX-дизайнеров и разработчиков или позволит лучше узнать про процесс разработки цифровых продуктов.

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


Концепция цифрового наставника Я-школьник

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

Вот какие гипотезы мы начали исследовать.

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

В бортовом журнале собираются вся информация: достижения в виде фишек, качества и навыки, которые прокачивались, опросы и советы

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

Индивидуальный дизайн. В следующей версии мы планируем сделать динамичные виджеты: если ребенок любит играть в компьютерные игры, ему покажут джойстик, а если музыкой то скрипку. Школьникам важно иметь возможность подстраивать дизайн под себя и чтобы он отражал их внутренний мир и увлечения.

Геймификация. Мы планируем внедрить еще больше игровых механик, которые сделают процесс достижения результатов в учебе максимально интересным и продуктивным. В качестве эксперта по игровым механикам для приложения Я-школьник выступил Илья Курылев, основтель студии Gamification Now!:

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

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

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

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

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

Игровые механики в приложении местами сливаются с современными приемами UI и UX. К разработке инструментов саморефлексии мы привлекаем психологов и педагогов, поэтому типичной геймификации вы там можете и не заметить. Но внимательный зритель увидит под капотом виртуальные награды, прокачку навыков и другие механики из ролевых игр. Возможно не прямо сейчас, но уже в ближайших версиях приложения

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

Использование публичных API помогает компаниям увеличивать ценность собственного ресурса, создавать уникальный контент и удовлетворять требования различных бизнес-задач. Wrike не исключение. На базе API Wrike создано уже более 30 тысяч приложений. Число пользователей продукта растет, а значит и требования к порталу возрастают с каждым днем.

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

В ходе редизайна нам удалось:

1. Создать интуитивно понятную навигацию.
2. Создать сетку для оптимального отображения контента на десктоп и мобильных устройствах.
3. Обновить дизайн портала в соответствии с текущей дизайн-системой и создать недостающие компоненты.
4. Соблюсти требования доступности уровня АА и внедрить тематизацию.

1. Интуитивно понятная навигация

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

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


Навигация на предыдущей версии портала

Чтобы оптимизировать структуру портала, мы выделили основные разделы и подразделы, а также отделили технический контент от информационного. Так, в новом портале мы выделили 5 основных разделов: Introduction, API Documentation, API Reference, BI Export и Support, а раздел API Community закрепили отдельной ссылкой в нижней части боковой панели, чтобы пользователь мог при необходимости быстро обратиться за помощью.

Размещение навигации в боковой панели помогает пользователям сразу увидеть не только главные разделы, но и подразделы. А возможность скрытия методов упрощает взаимодействие с панелью. При необходимости пользователь может свернуть ненужный раздел или, напротив, углубиться в нужный. В верхнем меню остались логотип, тогл и поиск (в разработке).



Обновление навигации на портале (было стало)

Чтобы упростить взаимодействие, пользователю лучше показывать структуру портала с уровнем вложенности не глубже двух. Дополнительные фичи (например, поиск) можно вынести в верхнее меню. Если для использования портала пользователям требуется авторизация, кнопку входа тоже можно отделить от основной навигации. Так вы обеспечите быстрый поиск нужной информации и легкое перемещение между страницами.


Навигация на новом портале

2. Сетка для оптимального отображения контента

Dev-портал Wrike состоит в основном из статичных страниц с разнообразным контентом. Таблицы и текстовые блоки занимают всю ширину сетки, поэтому количество колонок не имеет значения.

Мы уделили особое внимание странице с методами. Построить эту страницу можно двумя способами:

1. Поделить контентную часть на два блока: слева описание и таблицы, справа примеры.
2. Сделать единый блок с контентом: примеры внутри каждого метода.

На предыдущей версии портала использовался первый способ.


Страница метода на предыдущей версии портала: описание и запрос слева, а слайдер с ответом и примерами справа

Мы проанализировали методы API Wrike и решили использовать второй вариант. Он позволяет сохранить таблицы с их вложенностью в удобном для чтения виде, а также просматривать ответ и пример без переключения слайдера.


Страница метода на новом портале

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

Создайте флюидную сетку, установив максимальную и минимальную ширину контентной области. Задайте минимальные отступы от контентной части и сделайте центральное выравнивание. Контент будет меняться пропорционально ширине экрана, но при этом читать текст и таблицы все равно будет удобно.

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



Принцип работы сетки на новом портале

Большинство разработчиков используют в работе устройства с широкими экранами. Но лучше предусмотреть возможность работы с порталом и на планшетах. Открывайте боковую панель на мобильных устройствах поверх контентной области. Это позволит сохранить информацию в читабельном виде.

3. Обновление дизайна портала в соответствии с текущей дизайн-системой и создание недостающих компонентов

Сущности API портала отличаются от стандартных сущностей веб-сайта. Я выделила несколько компонентов, которые требовали особого внимания со стороны дизайна.

HTTP методы

HTTP методы (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH) одна из важнейших сущностей API. В зависимости от вида действия сущность имеет определённый HTTP метод. При дизайне HTTP методов старайтесь следовать следующим рекомендациям.

1. Присвойте каждому из 9 существующих HTTP методов цветовой идентификатор, чтобы визуально можно было отличать их, не заставляя пользователя долго фокусироваться.
2. Для большего удобства добавьте в компонент HTTP метода URL, чтобы упростить жизнь разработчикам: им не нужно будет совершать дополнительные действия для просмотра этой информации.
3. Предоставьте возможность видеть запрос и пример одновременно. В новой версии API портала Wrike примеры размещены внутри метода, а не спрятаны в слайдер, как это было ранее.
4. Не располагайте на отдельных страницах методы, которые относятся к одной сущности: в старой версии Query Tasks, Create Task, Modify Task отдельные страницы. Вместо этого разделите страницы по сущностям: Contacts, Users, Tasks и т.д. Это также упростит взаимодействие с порталом.

HTTP методы на новом портале

Таблицы

Все запросы, отправляемые на сервер, представлены в виде таблиц с большим объемом данных.

Таблица на предыдущей версии портала

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


Таблица на новом портале

Постарайтесь сделать вложенность наиболее очевидной и указать, к какому из параметров она относится. В предыдущей версии портала цветом выделялся только столбец с описанием, несмотря на то, что вложенность относилась к параметру целиком.


Вложенность на предыдущей версии портала

На новом портале шеврон относится к самому параметру и помогает пользователю понять, что внутри спрятан контент.

Стоит отметить, что столбцы вложенной таблицы лучше располагать под столбцами родительской. Это способствует более быстрому восприятию информации.

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


Вложенность на новом портале

Примеры

Пример показывает, как работать с конкретным методом и что будет возвращено при правильном запросе. Запрос формируется с применением CURL с указанием необходимых данных.

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

Для комфортной работы с примером можно добавить возможность копирования в буфер.

Примеры на новом портале

4. Соблюдение требований доступности и тематизация

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

Контрастность обычного текста, заголовков и графических элементов соответствуют стандартам WCAG.

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

К каждому графическому объекту есть описание. Так, для кнопок копирования информации в буфер, рядом с иконкой расположен текст Copy, при нажатии на кнопку текст меняется на Copied CURL example.

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

Отдельно хочу выделить предоставление пользователю выбора темы интерфейса. Оно стало большим преимуществом нового портала по нескольким причинам:

1. Это дружественное решение, которое соответствует одному из принципов инклюзивного дизайна принципу выбора.
2. Темный режим является наиболее привычным для разработчиков.
3. Темный режим регулирует яркость экрана в соответствии с условиями освещения и снижает нагрузку на глаза.
4. Обеспечение тем улучшенной контрастностью делает сайт доступным для людей с ослабленным зрением или дальтонизмом.

Тематизация на dev-портале Wrike

Подводя итог

Для создания удобного интерфейса dev-портала необходимо:

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

Посмотреть, как получилось у нас, можно на dev-портале Wrike.

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

Нравится тебе оно или нет, но при создании ИТ-продукта никак не обойти тему проверки UX на прочность. Любой специалист, которому хоть сколько-нибудь не наплевать на свою работу, хочет, чтобы результаты потраченных человеко-часов были по достоинству оценены конечным пользователем.

Часть методов UX-исследований настолько очевидны и прямолинейны, что у некоторых из ИТ-шников при первом знакомстве в классификацией тестов появится логичный вопрос А что, кто-то этого не делает? и следующий за ним Их ещё не поувольняли?.

Давайте признаемся, мы ведь все тестируем UX, иногда даже не ставя себе в явном виде такую задачу. Кто-то называет это пафосным словом исследование, а кто-то вообще никак не называет, но всё-равно тестирует втихаря.

В этой статье собран 21 метод UX-исследований. Некоторые из них простые и банальные, некоторые более изощрённые. Выбирай тот, что тебе по вкусу. Но сначала посмотрим, какими характеристиками они отличаются.

Отличия методов

Количественный/качественный. Часть исследований даёт измеримый результат, например, собранный системой аналитики или посчитанный по итогам опроса. Такие исследования мы зовём количественными. В других случаях возможна только качественная оценка, т.е. состоящая из суждений исследователя или участника (удобно неудобно, просто запутанно и т.п.).

Логичным образом это связано и с количеством исследуемых. Чем их больше (количественный метод), тем сложнее разбирать каждый случай в отдельности и проще оперировать усреднёнными цифрами. Чем меньше тестируемых (качественный метод), тем меньше смысла полагаться на цифры, так как при маленьких выборках они могут сильно разниться. Тогда приходится прибегать к качественной оценке и выяснять не сколько людей сделали или сказали что-то, а почему они это сделали или сказали.

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

Участие продукта. По степени участия продукта в исследовании выделяют методы:
с естественным использованием продукта
с использованием продукта по заранее созданному сценарию
без участия продукта
смешанные, состоящие из комбинаций выше приведённых методов

Этап создания. Давайте выделим три этапа создания продукта: планирование, разработка и подведение итогов. Исследования будут отличаться в зависимости от этих этапов.

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

Методы UX-исследований

1. Проверка концепции
2. Сортировка карточек
3. Фокус-группа
4. Этнографическое исследование
5. Привлечение к проектированию
6. Древовидное тестирование
7. Оценка предпочтений
8. Лабораторное исследование
9. Айтрекинг
10. Исследование дневников
11. Удалённое исследование
12. 5-секундный тест
13. Немодерируемое панельное исследование
14. A/B-тестирование
15. Юзабилити бенчмаркинг
16. Экспертный обзор
17. Кликстрим
18. Сбор обратной связи
19. Email-опрос
20. Исследование истинного намерения
21. Интервью

1. Проверка концепции (Concept Testing)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: смешанное
Этап: планирование

Обзор
Метод сосредоточен на выделении ключевых качеств продукта, чтобы определить, соответствуют ли они потребностям целевой аудитории. Тот, кто знаком с концепцией MVP (minimum viable product), наверняка понимает, о чём речь. Может выполняться как один-на-один, так и с большей аудиторией. Главная цель понять, есть ли хоть какая-то потребность в таком продукте.

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

2. Сортировка карточек (Card Sorting)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное
Этап: планирование

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

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

Когда использовать
На ранних стадиях проектирования продукта, в особенности не имеющего прямых аналогов на рынке. Также для выявления ошибок в уже сформированной информационной структуре.

3. Фокус-группа (Focus Groups)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: планирование, разработка

Обзор
Группа из 310 участников под руководством модератора обсуждает свои взгляды на будущий продукт. Роль модератора скорее поддерживать поток мнений, чем направлять его. Фокус-группа может ответить на несколько основных вопросов, но не должна превращаться в интервью (см. метод 21).

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

4. Этнографическое исследование (Ethnographic Field Studies)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: возможны оба
Участие продукта: естественное
Этап: планирование, разработка

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

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

Предполагает физическое присутствие исследователя и изучает не столько взаимодействие людей с продуктом, сколько взаимодействие людей между собой. Требует больше времени на подготовку и может включать пассивное наблюдение, наблюдение с участием и контекстные интервью (вопросы во время работы).

Когда использовать
Для наблюдения за аналогичными продуктами на рынке на ранних стадиях разработки собственного. Даёт важнейшие инсайты о потребностях пользователей, позволяя уточнить общую концепцию продукта.

5. Привлечение к проектированию (Participatory Design)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное или по сценарию
Этап: планирование, разработка

Обзор
Пользователям предлагают самостоятельно составить структуру приложения на бумаге или магнитной доске. Зная предназначение продукта, они стараются представить его в максимально удобном для себя виде.

В качестве материалов используются карточки с функциональными элементами, декоративные материалы и маркеры. Участвовать может как целевая аудитория, так и сотрудники клиента, руководители, акционеры и т.д.

Когда использовать
В качестве мозгового штурма при проектировании продукта. Позволяет найти неожиданные полезные идеи, которые помогут улучшить UX-решение.

6. Древовидное тестирование (Tree Testing)

Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: без участия
Этап: планирование, разработка

Обзор
Участники работают с текстовой версией сайта или приложения, вся структура которого представлена в виде дерева. Категории верхних уровней раскрываются на вложенные категории и т.д.

Задание найти тот или иной пункт меню, ориентируясь по этой схеме. Результат распределение кликов по категориям. Наглядно демонстрирует, насколько структура продукта может ввести в заблуждение.

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

7. Оценка предпочтений (Desirability Studies)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное, по сценарию
Этап: планирование, разработка

Обзор
Участникам показывают несколько вариантов дизайна. Они должны оценить каждый из них набором количественных и качественных характеристик. Например: скорость, простота, полезность, предсказуемость, свежесть, авторитетность и т.п. Характеристики предоставляются заранее, часто на карточках для удобства.

Когда использовать
Когда необходимо понять, какие субъективные ощущения вызывает у пользователей дизайн. Целесообразно проводить на ранних стадиях разработки продукта.

8. Лабораторное исследование (Usability-Lab Studies)

Качественный/количественный: качественный
Поведенческий/отношенческий: поведенческий
Участие продукта: по сценарию
Этап: разработка

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

Подробнее о том, как подобное исследование проводится, можно почитать в статье UX-исследование ДБО: наш опыт, ошибки и открытия.

Когда использовать
Во время разработки UX-решения, чтобы подтверждать и опровергать возникающие предположения. Можно провести уже на этапе прототипирования. Подходит для проприетарных приложений, недоступных большинству пользователей.

9. Айтрекинг (Eyetracking)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное или по сценарию
Этап: разработка

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

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

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

10. Исследование дневников (Diary/Camera Studies)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное
Этап: разработка

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

Реализовать это можно разными способами: с помощью бумажного журнала, приложения для заметок или аудио- и видеосообщений. Пользователей инструктируют о ведении записей и по возможности настраивают ежедневные напоминания.

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

11. Удалённое исследование (Remote Usability Studies)

Качественный/количественный: скорее качественный
Поведенческий/отношенческий: поведенческий
Участие продукта: по сценарию
Этап: разработка, подведение итогов

Обзор
Аналог лабораторного исследования, проводящийся удалённо, например, с использованием ПО для удаленного доступа. Бывает модерируемым, когда участники получают комментарии и вопросы от специалиста, и немодерируемым, когда задания выполняются самостоятельно.

Когда использовать
Чтобы сэкономить ресурсы на проведении лабораторного исследования. Позволяет пригласить больше участников и получить более реалистичные результаты, поскольку физически пользователи остаются в комфортной для себя обстановке.

12. 5-секундный тест (Five second test)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: разработка, подведение итогов

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

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

13. Немодерируемое панельное исследование (Unmoderated Remote Panel Studies)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: возможны оба
Участие продукта: естественное или по сценарию
Этап: разработка, подведение итогов

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

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

Когда использовать
Подходит при исследовании продуктов с долгим циклом использования (фитнес-приложения, мониторинг здоровья и т.п.). Также полезен для анализа отложенных событий (например, уведомлений) и при планировании обновлений.

14. A/B-тестирование (A/B Testing)

Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное
Этап: разработка, подведение итогов

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

После достижения статистической значимости делается вывод, какой вариант победил по выбранному KPI (например, покупки в приложении). Проводится в специальных сервисах, таких как Google Optimize для сайтов и Optimizely для приложений.

Когда использовать
Для оптимизации рабочей версии продукта, то есть либо на последних этапах разработки, либо после релиза. Помогает с тонкой настройкой важнейших элементов интерфейса, например, CTA-кнопок или элементов навигации.

15. Юзабилити бенчмаркинг (Usability Benchmarking)

Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: по сценарию
Этап: разработка, подведение итогов

Обзор
Лабораторное исследование, которое проводится регулярно для отслеживания изменений в UX. По методике похоже на предыдущий пункт, главное отличие в сравнении результатов. Сравнивать показатели можно с предыдущими версиями продукта или с его конкурентами на рынке.

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

16. Экспертный обзор (Expert Review)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное или по сценарию
Этап: разработка, подведение итогов

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

Когда использовать
Для получения свежего взгляда со стороны помогает заметить мелочи, на которые замыленный глаз не обращал внимания. Также подходит, когда команде UX-дизайнеров не хватает собственной экспертизы.

17. Анализ кликстрима (Clickstream Analysis)

Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное
Этап: разработка, подведение итогов

Обзор
Анализ данных о том, какие страницы и в каком порядке посещал пользователь. Легко провести с помощью системы аналитики Google Analytics, Яндекс.Метрика, Firebase, Mixpanel. Позволяет выявить проблемы, связанные с навигацией по сайту или приложению. Не помогает с поиском их причин. Для выяснения причин стоит использовать юзабилити-исследования (методы 8, 11).

Когда использовать
Когда нужно проверить, используется ли продукт так, как задумано. Исследование можно проводить на финальной или промежуточной версии.

18. Сбор обратной связи (Customer Feedback)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное
Этап: подведение итогов

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

Когда использовать
После значимого действия на сайте или в приложении, например, оформления заказа или запроса в поддержку. Появление опросника на более ранних этапах может осложнить путь к конверсии и оттолкнуть посетителя.

19. Email-опрос (Email Survey)

Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: подведение итогов

Обзор
Анкетирование пользователей по email, в отличие от сбора обратной связи, общее и не триггерное. Касается предыдущих взаимодействий с продуктом, поэтому оценивает только его восприятие аудиторией. Проще для проведения, чем интервью (см. метод 21), но выше вероятность отказа. Количество вопросов обычно не превышает 10, чтобы не отпугнуть респондентов.

Когда использовать
Для анализа эффективности действующего продукта и сравнения с конкурентами.

20. Исследование истинного намерения (True-Intent Studies)

Качественный/количественный: количественный
Поведенческий/отношенческий: возможны оба
Участие продукта: естественное
Этап: подведение итогов

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

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

Когда использовать
После запуска продукта, когда достаточный объём трафика достигнут. Чтобы узнать, отвечает ли разработка запросам пользователей, и выполняет ли задуманные функции.

21. Интервью (Interviews)

Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: подведение итогов

Обзор
Личное интервью с людьми, имеющими опыт работы с продуктом. Задача понять, какое впечатление оставляет сайт или приложение у пользователей. Поскольку речь идёт о прошлых действиях, точных численных данных получить не удастся.

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

Итог

Как видите, есть целый арсенал методов для анализа и выявления причин пользовательского поведения и восприятия продукта. Каждый подход может сыграть решающую роль в создании UX-решения, если знать, в какой момент его применить. А может и не сыграть. Надеюсь, этот гайд оказался полезным.

Спасибо Станиславу Лушину за помощь в написании статьи.
А также Елене Ефимовой за инфографику, Татьяне Китаевой за редактуру.

Список источников:
When to Use Which User-Experience Research Methods
7 Great, Tried and Tested UX Research Techniques
Five second tests
Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories

Арт-объект из проекта Неудобно греческого дизайнера Katerina Kamprani

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

Повышать насмотренность (и начитанность) можно наблюдая за топовыми чуваками из интересующей сферы. А интересует меня, как начинающего дизайнера, User Experience и с чем его едят.

Под катом список известных в сфере UX дизайна имен, от мастрида, вроде Дона Нормана, до менее знакомых широкой публике, вроде автора логотипа Firefox. Там же ссылки на их твиттеры, блоги и некоторые проекты.

Я только формируют свой твит-лист для слежки, так что порадуюсь дополнениям.

Чтобы не терять свои находки по дизайну в тоннах закладок на компе, я создала телеграм-канал Дрын Дезигн. Все клевые и полезные материалы, которые я нахожу для себя, я буду постить туда. Угощайтесь.

Хочу заметить, что это не ранжированный список.

15 человек в UX, за которыми стоит следить в Twitter

Don Norman

Дон Норман один из самых известных UX-дизайнеров в мире, именно он придумал термин user experience. Про Нормана даже есть небольшая статья в русской Википедии. Его щебет редко раздается в твиттере, зато его личном блоге можно найти ссылки на все его книги и эссе.
Дон в твитере @jnd1er.


Дон Норман позирует с фирменным кофейником, который используется в обложке книги. Иллюстрация Захари Монтейро.

Steve Krug

Стив Круг, юзабилити эксперт, написавший книгу "Не заставляйте меня думать". Она считается основным текстом для специалистов по юзабилити, и сейчас переиздается в третий раз. Стив ведет Twitter @skrug и личный блог.

Bill Buxton

Билл Бакстон занимается дизайном взаимодействия и исследованиями. Он является главным исследователем в Microsoft Research и ранее возглавлял собственную консалтинговую фирму Buxton Design. В 2001 году Билл был назван одним из 10 самых влиятельных новаторов в Голливуде. Он регулярно публикуется в Твиттере и ведет блог. Один из создателей Marking menu (круговое меню на рисунке справа).
Автор книги "Sketching User Experiences". Твиттер Билла @wasbuxton.

Irene Au

Айрен Ау бывший руководитель отдела дизайна в Google, Yahoo и Udacity. В 1996 она начала свою карьерув Netscape Communications, руководила разработкой Netscape 5.0. Ирен также является инструктором по йоге и четыре раза в неделю преподает ее в ПалоАльто. Найти ее в твиттере: @irenaeus.

Olof Schybergson

Олоф Шайбергсон ко-фаундер и CEO Fjord, одной из ведущих мировых консалтинговых компаний по дизайну услуг. Так же он CXO в AccentureActive. Он работал со всеми, от BBC до Ситибанка и Foursquare. Он часто посещает твиттер и делится своими интересами. Его твиттер @Olof_S.

Patrick Neeman

Патрик Ньюман один из самых плодовитых пользователей Twitter UX (почти 53 000 твитов и он продолжает твитить). usabilitycounts.com это его детище. Это веб-сайт с множеством советов для профессионалов UX. Его карьера проходит через такие компании, как Microsoft, MySpace, Orbitz, NewsCorp, Paramount, Comcast, Disney, Amgen и eBay. В его ленте как шутки о UX, так и более серьезные вещи.
Патрик в твиттере @usabilitycounts.

Laura Klein

Лора Кляйн написала UX for Lean Startups и Build Better Products. Она эксперт по бережливому UX из Кремниевой долины, часто делится знаниями для UX-дизайнеров в твиттере: @lauraklein.

Scott Jenson

Скотт Дженсон возглавляет проект Chrome Physical Web. До этого он работал над мобильными картами Google, Mac OS 7 и Apple Newton. Он публикует много интересных вещей в твиттере и регулярно ссылается на свои статьи. Читать его твиттер: @scottjenson.

Luke Wroblewski

Люк Вроблевский ведет личный блог. Он работал в Yahoo и eBay. Компании, которые он основал: Polar (приобретен Google), Bagcheck (приобретен Twitter). Он автор книг Mobile First, Web Form Design и Site-Seeing. Именно он придумал идею "Mobile First" (что лучше сначала разработать дизайн для самого маленького экрана, а не сжимать все с большого экрана в маленький). Вот его твиттер @lukew.

Karen McGrane

Карен МакГрейн специалист по UX и контенту. В 2006 она занималась редизайном New York Times. Она работала с Cond Nast, Disney и Citibank. Свои статьи она публикует в блоге.
Посмотреть, что пишет Карен @karenmcgrane.

Jan Jursa

Ян Джурса UX-дизайнер из Германии. Он ведет ленту Twitter о UX, выпускает два подкаста о UX, отвечает за три конференции каждый год и находит время, чтобы разрабатывать дизайн мобильных приложений. Он также создал книгу "UX Storytellers", содержащую истории более 40 специалистов по UX. Твитер Яна: @IATV.

Khoi Vinh

Графический дизайнер Хой Винь в настоящее время является главным дизайнером в Adobe. Он также постоянно твиттит и бложит по теме дизайна. Он возглавлял разработку дизайна в New York Times 4 года, после издал книгу "Ordering Disorder: Grid Principles for Web Design". Твиттер @khoi.

Daniel Burka

Даниэль Бурка когда-то был креативным директором Digg, и партнером по дизайну в Google Ventures. Ему принадлежит идея логотипа Firefox, он работал с с Mozilla в составе команды Mozilla Visual Identity Team. В настоящее время Бурка директор по продукту и дизайну в некоммерческой организации Resolve to Save Lives, где он работает над проектом Simple.org. Он регулярно пишет в твиттере на самые разные темы: @burka.

Peter Merholz

Питер Мерхольц соучредитель Adaptive Path и создатель блога peterme.com. Кстати, он в прямом смысле создатель блога, слово блог придумал он. В 2016 году издал в соавторстве книгу "Org Design for Design Orgs". Найти Питера: @peter.

Taylor Ling

Тейлор Линг из Малайзии, пишет для androiduiux.com. Он эксперт Google Developer Expert (GDE) по UX-дизайну. Он ко-фаундер и главный дизайнер The Fabulous. Тейлор в твиттере: @tailoring.


Приветствие нового пользователя в приложении для контроля привычек The Fabulous

---

Телеграм-канал Дрын Дезигн: делюсь там своими находками по дизайну (туториалы, статьи, ссылки на аккаунты клевых чуваков).

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

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

Retention метрика, на которую я смотрю чаще всего

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

Начнем с retention метрика, которая показывает возвращаемость пользователей. То есть, если сегодня наше приложение скачало 100 новых пользователей, то retention ответит на вопрос, сколько из них к нам вернется завтра, через месяц и так далее.

Допустим, что retention второго дня равен 60% это значит, что на второй день приложение запустят 60 пользователей из 100 скачавших.

Эту метрику можно посчитать на любой день жизни пользователя. Допустим, retention 7 дня равен 30% это означает, что на 7 день с момента скачивания в нашем приложении останется 30 человек из 100 скачавших.

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

В итоге мы берем каждого пользователя, смотрим на его второй день, и считаем, зашел он в сервис или нет. Затем смотрим, какой процент все-таки зашел это и будет показатель retention второго дня.

Допустим, наше приложение скачали 1000 раз за неделю. Во второй день из этой тысячи зашли 600 пользователей, а в седьмой 300. Используя эти данные, мы можем посчитать retention второго дня 600/1000 = 60%, и retention седьмого дня 300/1000 = 30%

Чем полезна эта метрика?

Она быстро даёт понять, удалось ли нам сделать продукт, который был полезен пользователю, или он пощёлкал, посмотрел и удалил.

Если retention какого-то дня составляет 0%, значит, из всех, кто когда-то скачивал приложение, никто в нем не остался, и приложение никому не нужно. Может, стоит его закрыть?

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

Но чаще всего цель разработки приложения найти пользователей, которые будут пользоваться им в течение длительного времени. То есть, с какого-то дня retention должен перестать убывать retention 90 дня должен быть равен retention 180 дня и так далее. В таком случае аналитики говорят, что retention вышел на плато.

Если у продукта большая и постоянно растущая аудитория, это свидетель того, что продукт вышел на плато retention как Facebook, Telegram, Google Maps и так далее.

Метрики роста и метрики продукта

Отойдем на шаг назад и посмотрим, какие вообще бывают метрики. Выделяют 2 типа: метрики роста и метрики продукта

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

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

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

Как думаете, retention это метрика роста или метрика продукта?

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

Допустим, мысленно сравняйте количество пользователей своего приложения с количеством пользователей Facebook. Retention приложения при этом останется неизменным. Как был 30% на седьмой день, так и останется. А значит, Retention это метрика продукта.

А что произойдет с выручкой? Выручка при увеличении аудитории заметно взлетит. Если один пользователь приносил нам 10, то 100 пользователей принесут нам 1 000 , а 1 000 000 пользователей 10 000 000 . Получается, что выручка (или revenue) это метрика роста.

Итак, метрики роста отвечают на вопросы:

Растет или падает дневная аудитория нашего приложения?

Сколько зарабатывает наш продукт?

А метрика продукта:

Сколько денег нам приносит один средний пользователь?

Какая часть пользователей остается с нами спустя месяц после установки приложения?

Зачем разбираться в метриках роста и продукта

Все дизайнерские решения каким-то образом влияют на метрики. Поэтому если в них разбираться, можно лучше понять удалось ли вам улучшить продукт или ваш новый дизайн сделал все только хуже?

Конечно, проще всего было бы ответить на эти вопросы, посмотрев на метрики роста. Мол, если мы стали больше зарабатывать значит, все не зря, а если начали зарабатывать меньше, то что-то идет не так.

Но в этом подходе кроется ошибка, которая может стоить продукта.

Чтобы лучше разобраться, почему при оценке дизайна или редизайна не стоит опираться на метрики роста, давайте разберем следующий кейс:

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

Команда выкатывает эту фичу и она оказывается неудачной. Метрики продукта то есть, retention, возвращаемость пользователей летят вниз. Продукт начинает хуже удерживать пользователей, доход на нового пользователя уменьшается.

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

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

Такой случай не редкость в компаниях.

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

Подытожим

1. Одна из главных метрик продукта это retention, то есть, возвращаемость пользователей. Найти его можно, разделив количество дневных пользователей на N-ный день на количество скачавших приложение.
2. Мы научились отличать метрики роста от метрик продукта. Достаточно мысленно увеличить количество пользователей приложения и посмотреть, увеличился вслед за этим показатель метрики или нет. Например, выручка revenue увеличится; значит, это метрика роста. А retention нет; значит, это метрика продукта.
3. Поняли, что для оценки продукта и своей деятельности нужно использовать именно метрики продукта.

Что дальше

Это была 2 статья из серии Дизайнер и метрики. В следующей статье я планирую рассказать как сравнивать изменение метрик что было до релиза и что стало после, как понять улучшили мы продукт или нет. Подписывайтесь, чтобы не пропустить.

Photo by Brooke Cagle on Unsplash

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

В этой статье речь пойдет о том, как ответить на вопрос, улучшили мы продукт или нет.

Дни после релиза

После раскатки нового функционала каждый дизайнер спрашивает себя: что изменилось? Удалось ли нам улучшить продукт?

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

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

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

Как сравнить метрики до и после

Реальное значение метрики против замеренной

У каждой метрики есть её реальное значение назовем его R (реальное), а есть значение, которое мы получили через замеры Z (замеренное).

И первое, с чем нам надо справиться это понять, что R Z.

Разберемся на примере

Допустим, перед нами стоит вопрос, сколько в России людей, которые работают в силовых структурах. Вариант загуглить и узнать не наш выбор в этой статье.

Допустим, теоретически мы могли бы опросить каждого человека в России, силовик он или нет, и получить реальное значение, то есть R.

Но поскольку практически это невозможно, мы опрашиваем столько людей, сколько смогли найти допустим, 300 человек (выборку формируем по науке), и потом просто экстраполируем эти данные на всю Россию.

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

Как из замеренной метрики получить реальную?

На этот вопрос как раз и отвечает математика. С помощью математической формулы мы можем получить промежуток значений, в котором находится R.

Вернемся к примеру с силовиками. Предположим, что после опроса 300 человек, 5 из них ответили, что являются сотрудниками силовых структур, то есть приблизительно 1,7%.

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

1. Замеренное значение метрики в случаем с силовиками это 1.7%
2. Количество выборки, на которой сделан замер 300 человек
3. Количество потенциальной выборки (не обязательно) в нашем случае наслеление России 146 млн человек.
4. Выбрать точность, с которой мы хотим получить результат. Обычно используют 90, 95 и 99%

Эти данные нужно ввести в специальный калькулятор для расчета доверительного интервала и нажать вычислить.

На выходе мы получим промежуток, в котором содержится R с вероятность 90, 95 и 99% (в зависимости от того, какой процент мы выбрали при расчёте).

Если вернуться к примеру с силовиками, то после этих расчётов можно сказать, что R находится в промежутке (или доверительном интервале) от 0% до 3,59% от всего населения России.

А значит, если умножить этот процент на население России, то получим интервал от 0 человек до 5 268 274 человек. (В этом интервале действительно содержится верный ответ в реальности это 2,6 миллиона).

Чтобы получить более точный промежуток, нам нужно опросить больше людей.

А как же все-таки сравнить метрики до и после

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

Если пересечения нет, то мы получили статистически значимые результаты и можно утверждать, что мы что-то изменили в продукте.

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

Разберемся на примере маркетинговой компании

Допустим, мы подготовили 2 креатива, и их посмотрели по 5 000 пользователей. Первый показал значение CTR 2% (это процент нажавших на креатив и перешедших на лендинг), а другой 3%. Можно ли сказать, что второй лучше первого?

Чтобы ответить на этот вопрос, нам надо собрать все данные для измерения доверительного интервала:

По первому банеру:

1. Значение метрики 2%
2. Сколько людей увидело этот банер 5 000
3. Опускаем потенциальную выборку
4. Выбираем точность 95%

Получаем, что R по первому креативу с 95% вероятностью находится между [ 1,61% 2,39% ]

Тоже самое проделываем по второму банеру (его посмотрело тоже 5 000 человек) и получаем интервал [ 2,53% 3,47% ]

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

Подытожим

1. Чтобы оценить работу дизайнера, недостаточно просто посмотреть метрики до и после, нужно сравнить их доверительные интервалы.
2. Посчитать доверительный интервал можно с помощью специального калькулятора.
3. Если доверительные интервалы до и после не пересекаются значит, работа дизайнера точно дала положительный результат.

Что дальше

Это была 3 и последняя статья из серии Дизайнер и метрики.

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

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

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



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

Зачастую юзабилити-тестирование проводится в два этапа: прохождение пользователем N-го количества задач (количественные или качественные тесты), а также беседа, заполнение опросников или глубинные интервью с пользователем (качественное исследование).

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

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

В проведении юзабилити-тестирования выделим следующие этапы:

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

Определение цели

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

• Что для вас в исследовании будет важным? Какие роли пользователей или их конкретные задачи стремитесь протестировать?
• Что надеетесь зафиксировать в заметках? К примеру, хотите использовать видеосъемку, а в протоколах помечать интересные моменты с привязкой к видео для быстрого поиска и обработки обратной связи.
• Планируете ли изучить рабочее пространство пользователей? Есть случаи, когда оно влияет на организацию интерфейса.
• Есть ли необходимость в фото- или видеосъемке в процессе наблюдения за пользователем? Возможно, какие-то сценарии проще записать на видео. Например, при проектировании мониторинговой системы скважин необходимо понять, с какими устройствами передачи данных взаимодействует Service Supervisor и какое количество мониторов он использует.
• Какие метрики будут использованы в тестировании? Количественные и/или качественные? Это зависит от того, что вам в исследовании интересно и что проверяете. Если работаете над приложением, предназначенным для рабочего процесса пользователя, вряд ли вас будет интересовать степень его вовлеченности. Вы, очень вероятно, будете заинтересованы в скорости прохождения сценариев, количестве пользовательских ошибок, выполненных сценариев и степени удовлетворенности пользователя.

Создание плана тестирования

Для формирования плана тестирования нужно прежде всего определить:

• Какой продукт или продукты планируете изучить? Например, закрытая Product Experience Management веб-платформа, обеспечивающая управление всей информацией о товаре/изделии.
• Что будет предметом тестирования? К примеру, та же веб-платформа или кликабельный адаптивный прототип ее новой версии.
• Какие типы устройств будут использованы? Например, персональный компьютер (ПК), планшет и мобильный телефон.
• Какие роли и функции пользователей будут протестированы? Допустим, роль: PDM-администратор. Функции/задачи: создание шаблона для товара или изделия, проверка шаблона товара, утверждение шаблона.

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

Для наблюдения я, как правило, готовлю документ для каждого пользователя дорожную карту, которая рассказывает, что и как делать и на какие вопросы отвечать. Документ называется UX testing plan & script и состоит из таких элементов:

• вступление;
• погружение пользователя в контекст решаемых задач;
• описание задач и список шагов с возможностью занесения комментариев по каждому из них;
• список вопросов к каждой задаче;
• заключительный раунд вопросов.

Не пытайтесь выявить все проблемы юзабилити в большом продукте сразу. Гораздо эффективнее раздробить сценарии на отдельные небольшие исследования по ролям с определенной целью в каждом из них.

Обычно при формировании задач провожу их декомпозицию. Что это такое? Я заменяю решение одной задачи на серию мелких простых и связанных между собой подзадач с конкретной целью в каждой.

Давайте рассмотрим пример. Сценарий задачи Как пользователь я могу забронировать понравившийся отель на самом деле состоит из ряда мелких подзадач:

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

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



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

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

Задача для качественных исследований: найдите на сайте отчет за первый квартал 2019 года.

Задачи для количественных исследований:

А. Используя глобальный поиск на сайте, найдите отчет за первый квартал 2019 года.
В. Используя раздел Reports на сайте, найдите отчет за первый квартал 2019 года.

В качественных исследованиях мы поймем пользовательское предпочтение user-flow, а в количественных разъясним, все ли шаги конкретного user-flow понятны пользователю. Качественные и количественные исследования должны дополнять друг друга, а не противопоставляться.

Как может выглядеть задача, связанная с авторизацией на сервере.

Пример сценария: клиент попросил вас подготовить отчет, и вы хотите начать с поиска информации в рамках сайта www.sample.com.

Задача: пожалуйста, войдите в систему, используя свой логин и пароль.

Шаги:

• Открыть браузер.
• Ввести в адресную строку www.sample.com.
• Ввести электронную почту в поле Email.
• Ввести символы в поле Password.
• Нажать кнопку Вход.

Альтернативные шаги:

• Открыть браузер.
• Ввести в адресную строку www.sample.com.
• Нажать ссылку Забыли пароль.
• Ввести свою электронную почту.
• Открыть почтовый клиент.
• Найти письмо от сервера об авторизации.
• Перейти по ссылке.
• Ввести новый пароль.
• Повторить пароль.
• Нажать кнопку Сменить пароль.

Если вы проводите количественные исследования и замеряете, например, время прохождения сценария, количество ошибок в одном сценарии, прошел/не прошел пользователь сценарий, а также уровень удовлетворенности пользователя все замеры производите исключительно на production-сервере, с реальной пользовательской нагрузкой, с реальными данными и работающими сервисами, с их валидацией и запросами к реальным базам данных.

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

Определение количества исследователей

Для качественного проведения наблюдения необходимо иметь следующие роли:

• Интервьюер проводит юзабилити-тестирование, используя UX testing plan & script. Часто такая роль достается самому проектировщику интерфейса.
• Наблюдатель уточняет детали и углубляется в них по мере протекания тестирования. В данной роли могут выступить продакт-оунер, эксперты предметной области или проектировщики интерфейса.
• Модератор должен придерживаться тайминга и следить за тем, чтобы все сценарии были воспроизведены пользователем. С этим хорошо справляются проджект- и продакт-менеджеры, скрам-мастеры. Еще приглашают на эту роль проектировщика интерфейсов.

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

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

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

Если вы проводите тестирование один, лучше всего проводить не более трех тестирований в день с максимальной продолжительностью сеанса 1,5 часа. Если же тестирование выходит за рамки указанного времени, разбейте его на две части.

Определение целевой аудитории

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

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

Определиться с целевой аудиторией помогут предварительные опросники. Их создают как в бесплатных сервисах, например Google Forms, так и в платных SurveyMonkey, Typeform и других.

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

Сопоставив план тестирования и предварительный опросник, вы сможете правильно выбрать потенциальных кандидатов для исследования.

Правила создания таких опросников очень просты:

• Точно формулируйте вопросы. Как правило, люди понимают одни и те же фразы по-разному. Используя недостаточно точные формулировки, мы не можем быть уверены, что пользователь правильно понял вопрос.
• Не спрашивайте у респондентов то, что вам заранее известно. Например, его имя, возраст или должность.
• Используйте закрытые вопросы везде, где есть возможность. Пользователям гораздо проще выбрать вариант ответа, чем писать свой.
• Убедитесь, что вы включили все подходящие варианты ответов для закрытых вопросов, в том числе Другое или Свой вариант на случай, если ни один из предложенных пользователю не подходит.
• Всегда задавайте нумерацию вопросам.
• Показывайте суммарное количество вопросов и прогресс-бар, заранее ориентируя человека, где он находится и сколько ответов ему предстоит дать.

Можно использовать дихотомические вопросы (да/нет ответы), чтобы определить, на какой следующий вопрос будет отвечать респондент. Это несложно делается, к примеру, с помощью Google Forms.



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



В случае скользящей шкалы варианты 6-9 принадлежат категории частично согласен, однако нет возможности понять, чем они отличаются. Здесь стоит избегать большого количества ответов без надобности.

Если хотите узнать, согласен или не согласен пользователь с чем-то, используйте четное количество оценок. Если же вас интересует также нейтралитет применяйте нечетное количество оценок.



Выборка пользователей зависит от многих факторов:

• вероятности появления ошибки у определенного процента респондентов;
• однородности в выборке пользователя каждой роли;
• наличия альтернативных путей прохождения сценариев;
• степени сложности выполнения сценариев.

Давайте поговорим о вероятности возникновения ошибки у пользователя. Если у всех юзеров возникает одна и та же ошибка, то для тестирования вам понадобится всего лишь один пользователь, который с вероятностью 100% обнаружит эту проблему.

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

На сегодня есть калькуляторы для вычисления количества пользователей. Они базируются на средней вероятности обнаружения ошибки в одном исследовании. Однако проблема в том, что разные исследователи получают разные показатели этой вероятности. К примеру, Якоб Нильсен в свое время получил значение, равное p=0.31, в то же время исследования Спула и Шредера приводят к результату p=0.16.

Выбор вероятности это всегда большой риск. Вы можете полагаться на свои исследования и провести расчет своей вероятности или использовать значения p=0.31 для простых сценариев и p=0.16 для сложных и разнообразных, полагаясь на исследования других.

При анализе различных исследований вытекает один бесспорный факт чем больше пользователей вы протестируете, тем более точные получите результаты. Но что делать, когда вы ограничены количеством конечных пользователей?

До сих пор в мире спорят о том, какое же минимальное количество участников подходит для тестирования. По мнению Якоба Нильсена, это 5 человек, а по мнению Лауры Фолкнер 10.

Я рекомендую начинать с 5-10 тестирований одного прототипа для проверки гипотез в качественных исследованиях и 10-20 тестирований для количественных. Если ошибки начинают повторяться, это свидетельствует о том, что выборка пользователей однородная. Также допускается использовать метод итеративных изменений RITE, когда правки вносятся в интерфейс по мере обнаружения проблем. Проводится тестирование одного пользователя.

Если группа исследователей уверена, что понимает суть обнаруженных проблем, то она принимает решение исправлять их или нет. Если же нет, она продолжает тестировать текущий интерфейс, пока суть не будет ясна. После внесения правок тестирование начинается заново. Обычно подход RITE требует 5-6 итераций.

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

Получение пользовательского согласия

Перед началом теста необходимо получить разрешение на участие пользователя в конкретном исследовании. Важно прописать абсолютно все условия, по которым оно будет проводиться (примеры условий ниже). Это будет хорошей страховкой на предмет использования всех данных, которые вы получите в процессе исследования.

Я стараюсь делать в своих наблюдениях видео- и аудиозаписи. Это позволяет максимально точно зафиксировать все ответы и реакцию пользователя на выполнение задач. Как организатор тестирования вы должны всегда уведомлять человека об осуществлении записи в письменной или электронной форме.

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

Пример:

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

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

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

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

У меня было достаточно времени для принятия решения, участвовать ли в этом исследовании.

Я понимаю, что могу принять решение отказаться от участия или прекратить участие в любое время.

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

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

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

Организация доступа

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

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

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

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

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

Проведение наблюдения

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

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

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

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

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

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

Избегайте наводящих вопросов. В них содержатся подсказки, и вы можете неосознанно влиять на результаты. Уточните все детали, если человек не понял задачу сразу.



Не спешите сразу делать выводы или записывать за пользователем. Важно уточнять, что он имеет в виду, и верифицировать с ним свои мысли, чтобы точнее зафиксировать ответ.

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

Делайте заметки с помощью предварительно подготовленной структуры. В UX testing plan & script обычно использую колонку для записи пользовательских комментариев к каждому шагу сценария. Во время выполнения задач делаю небольшие заметки в виде прошел/не прошел сценарий, возникали/не возникали сложности. Эти заметки можно привязать к соответствующим моментам видео, и вы сможете легко вернуться к ним позже.

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

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

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

Лучшим решением в данной ситуации был откат на этап определения целевой аудитории и выбор другого человека. Также предварительно стоит доработать неточности в опроснике.

Анализ

Во время анализа обращайте внимания на ситуации, когда пользователь:

• понимает задачу, но не может выполнить ее в намеченный срок;
• понимает цель задачи, но вынужден перепробовать несколько вариантов для ее достижения;
• не достигает цели задачи и досрочно прекращает выполнение сценария;
• выполняет задачу, но не ту, которая была поставлена;
• выражает удивление или удовольствие;
• выражает разочарование и замешательство;
• говорит, что ему что-то непонятно или неправильно реализовано;
• предлагает внести изменения в интерфейс.

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

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

Используя метод RBT, а также диаграмму сродства, вы сможете выявить похожие проблемы, сильные стороны интерфейса и общие предложения пользователей.

Метод RBT состоит из следующих показателей:

• Rose то, что работает хорошо или что-то положительное; зеленая карточка.
• Bud область возможностей или идей, которые еще предстоит изучить; синяя карточка.
• Thorn что-то не работает или что-то негативное; красная карточка.

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

Как это делается? Мы анализируем первую задачу одного пользователя и фиксируем конкретные замечания и цитаты на стикерах. На каждом стикере написаны имена участников. Размещаем их на стене или доске. Далее следующий пользователь вносит свои данные. После нескольких тестов появляются общие вопросы и проблемы.

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



Задайте рейтинг найденным проблемам (Thorn) по шкале:

• Критическая ошибка. Не работает какая-то кнопка, если это не исправить, пользователи не смогут завершить сценарий. Например, человек ищет отели на сайте-агрегаторе, но не может залогиниться или не отображается результат.
• Серьезная ошибка. Пользователи будут расстроены, если мы не исправим ошибку. Также есть вероятность, что они сдадутся и не пройдут сценарий. Например, выдача в поиске на сайте бронирования отелей занимает 10 секунд. Многие юзеры не заходят ждать и уйдут на другие ресурсы.
• Минорная ошибка. Пользователи будут раздражены, но это не помешает им завершить сценарий. Например, ожидание отображения результатов сократится до 5 секунд. Это продолжит раздражать, но человек, скорее всего, останется на сайте, так как он уже потратил свое время и не пойдет искать другой сайт, несмотря на то, что ожидание результатов на нем может быть немного меньшим.

Этот рейтинг поможет определиться с приоритетами в работе над поиском и валидации решений найденных проблем.

В процессе анализа также будьте готовы получить интересные факты, которые не были связаны с тестирующими сценариями. Например, при тестировании сценария создание чата в Microsoft Teams веб-версии вы поймете, что у пользователя несколько разных рабочих аккаунтов. Ему приходится быть авторизованным в системе под разными аккаунтами в разных вкладках браузера. Сделать такое в desktop-версии невозможно, соответственно, вы получите новый инсайт о том, как пользователи с разными учетными записями решают эту задачу, используя ваш продукт.

При анализе обратной связи стоит задуматься над такими вопросами:

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

Когда все продумано, нужно презентовать результаты исследования заказчику. Вы предлагаете ему варианты улучшения и объясняете последствия, если все оставить так, как есть. Далее он уже решает, есть ли ресурсы на доработку и целесообразно ли это.

Заключение

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

Анализ и обнаружение ошибок это всегда субъективный процесс. Те результаты, к которым придете, это исключительно ваше понимание ситуации. Поэтому чем разнообразней будете подбирать команду исследователей, тем разностороннее истолкуете суть проблемы.

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

Автор: Eugenia Grubaya, Senior Usability Architect
Источник: dou.ua/lenta/articles/usability-testing-guide

Однажды в деревне мой дядя Слава спросил, чем я занимаюсь. Большой, мол, уже, 25 лет. Должен же чем-то заниматься. Я ответил, что работаю в Москве дизайнером мобильных приложений. Он кивнул и помолчал с полминуты. Потом переспросил: Так это значит в телефоне там все рисуешь? Да, говорю, чтобы не распространяться. Он достает из кармана кнопочную Nokia и протягивает ее мне мол, давай, показывай, что ты из этого нарисовал. Вот эту иконку сообщения или ту, с телефонным справочником?

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

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

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

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

Первый этап. Пользователь

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

Спросите у продакта:

1. Как пользователь решает эту задачу сейчас?
2. Какой результат для пользователя мы хотим получить?

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

Но самая главная задача этого этапа отойти от готовых решений и начать думать про гипотезы и их проверки.

Второй этап. Бизнес

Этот этап самый понятный для продакта, чья главная задача в компании зарабатывать деньги и развивать свое направление. Начните говорить на его языке, чтобы понять его реальные мотивы.

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

Спросите у продакта:

1. Давай представим, что все сработало идеально. Чего мы тогда достигли? Как это отразилось на бизнесе?
2. Сколько это в цифрах?

Цель этапа собрать бизнес-составляющую кейса, чтобы при решении опираться на интересы не только нашего любимого пользователя, но и нашего работодателя.

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

Третий этап. Что происходит с продуктом?

Фундамент хорошего решения понимание продукта и его пользователей. Чтобы собрать эти данные, иногда приходится проштудировать гигантские объемы информации и поговорить с большим количеством пользователей.

Но чаще всего ответы ближе, чем кажутся у продакта. Спросите его, и он сам всё расскажет:

1. Кто наши конкуренты?
2. Где можно посмотреть продуктовую аналитику? Где можно взять события метрики?
3. Проводились ли какие-то качественные или количественные исследования? Где их можно посмотреть?

Цель этого этапа получить данные о том, что сейчас происходит с продуктом и как он развивался.

Четвертый этап. Сроки

Уточните, сколько времени у вас есть на поиск решения, чтобы спланировать работу.

Спросите у продакта:

1. Когда хотим в продакшен?
2. Когда должен быть готов дизайн?
3. Насколько это жёсткие сроки? Можно ли их двигать?

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

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

Пятый этап. Технические особенности

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

Спросите у продакта:

1. На какие фронты хотим раскатить фичу? Веб, мобилка, другие фронты?
2. Есть ли какие-то технические ограничения, о которых мне стоит знать?
3. Если процесс дорабатывается, то как посмотреть существующий процесс? Есть ли тестовые данные?
4. Если уже есть бэк, то есть ли документация ответов?
5. Можем ли мы менять бэк?

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

Контакты

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

Спросите у продакта:

1. У кого можно узнать специфику продукта? Его продуктовые особенности? Особенности системы?
2. Как достучаться до этих людей? Почта/телеграм/вотсап?
3. С кем внутри команды согласовывать драфты дизайна?
4. Как лучше согласовывать решение? Встреча? Письмо? Другое?

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

Пользователь

1. Как пользователь решает задачу сейчас?
2. Какой результат мы хотим получить для пользователя?

Продукт

1. Чего мы хотим достичь?
2. Сколько это в цифрах?
3. Кто наши конкуренты?
4. Где можно посмотреть продуктовую аналитику? Где можно взять события?
5. Проводились ли какие то качественные или количественные исследования? Где их можно посмотреть?

Сроки

1. Когда хотим в прод?
2. Когда дизайн должен быть готов?
3. Сроки жёсткие? Есть ли возможность их двигать?

Технические ограничения

1. На какие фронты хотим раскатить фичу? Веб, мобилка?
2. Есть ли какие-то технические ограничения, о которых вам стоит знать?
3. Если процесс дорабатывается, то как посмотреть существующий процесс? Есть ли тестовые данные?
4. Если уже есть бэк, то есть ли документация ответов?
5. Можем ли мы менять бэк?

Коммуникация

1. У кого можно узнать специфику продукта? Его продуктовые особенности? Особенности системы?
2. Как достучаться до этих людей? Почта/телеграм/вотсап?
3. С кем внутри команды согласовывать драфты дизайна?
4. Как лучше согласовывать решение? Встреча? Письмо? Другое?

Введение

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

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

Цель приложения, показать водителю мусоровоза список контейнерных площадок (далее КП), на которых расположены баки с мусором и зафиксировать факт очистки этих контейнеров посредством фотоотчета. Нужно всего лишь сделать фото до и после. А если мусор невозможно убрать, то оповестить об этом.

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

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

Этап 1. Подготовка и планирование деятельности

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

Структурирование хаоса и прорисовка карты боя

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

Все необходимые мне работы я сначала зафиксировал в кучу. После этого произвел декомпозицию и разнес все по смыслу. Это позволило понять объем и вид работ. Под каждой сущностью я поставил цифровые значения. Это нужно для того, чтобы создать структуру папок в облаке, в которую я будут добавляться материалы, согласно их смыслу. Ниже пример структурирования хаоса.



Например, пункт 0.4.1 Перевозчики (Интервью с пользователями). Я создам отдельную папку, куда положу следующие документы:

• Список контактных лиц и их реквизиты
• Список вопросов и ответов
• Фотографии и прочие материалы, полученные в процессе опроса

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



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

Вообще, эти цифры могут фигурировать везде, где это уместно, например в теме письма. По поиску вы всегда сможете быстро найти нужные документы.

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

Приоритезация задач

Следующим шагом будет определение приоритетности работ. Проставляется легко, цифрами от 1 до 4. Понимание цифр на ваше усмотрение. А вообще по приоритезации задач самая распространенная техника Матрица Эйзенхауэра. Можно использовать ее.

У Mindjet есть удобная функция просмотра приоритета задач, вид показать иконки.



Дела первого приоритета можете смело формировать в своем календаре. У нас почта на Яндексе. Соответственно я планирую свой день на основании работ в карте и в этом календаре и ни у кого не должно возникать вопросов, чем я занят и смогу ли я взять задачу в работу. Все видно и обоснованно. Прилетает новая важная задача, работаем приоритетами. В конце дня актуализация плана работ на следующий день.

Контроль сроков и прошивка календаря

Если Вы работаете в заказной разработке и ваша работа фиксируется сроками договора. А точнее дополнительного соглашения, то Вы можете перенести сроки из этого ДС в ментальную карту, простым щелчком Add Tast info. Тогда вы и проектный менеджер будете понимать, что и когда должно быть выполнено. Просто нажмите в разделе Обзор кнопку Показать диаграмму Ганта и ура.



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

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

Этап 2. Глубоководное погружение в мир пользователя

Моделирование работы водителя с приложением. Использование реального оборудования на демо-данных

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

Работа в реальных условиях была организована в двух видах.

• Работа в обстановке приближенной к реальной на тестовых данных
• Работа полностью в реальной обстановке с реальными данными

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

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







Работа с водителем на реальном рейсе. Реальные данные и реальная ежедневная работа настоящих мужиков.

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





Встретившись с командой мусоровоза, я сразу обозначил свое присутствие и цель Мужики, с приложением Вам придется все равно пользоваться. Это требования к перевозчикам, а не мои хотелки. Они должны передавать данные в муниципалитет. Я здесь, чтобы упростить вам работу. Сейчас приложение не идеально и с вашей помощью мы будет его дорабатывать. Поможете?. Разумеется получил утвердительный ответ. И мы поехали выполнять их повседневные задачи.







Мне было интересно все, что как-то участвует в работе водителя. Что я зрительно фиксировал.

• Где постоянно лежит телефон у водителя. На панели, в бардачке, в кармане рубахи. На солнце или в тени.
• Что еще использует водитель при работе. Как этим пользуется. Например бумажный график. Как этот график выглядит, как он по нему ориентируется. Что удобно, что неудобно.
• Как выглядит типичный день водителя. Как он ориентируется куда ехать
• Как работает с приложением. Какие привычки выработались при работе с приложением
• Как быстро разряжается батарея устройства
• Как быстро обновляются данные
• Как ведет себя приложение при разной степени мобильной связи
• Насколько водителю удобно пользоваться
• Какими экранами наиболее часто пользуется водитель при навигации, при выборе КП
• Что мешает водителю постоянно делать отчеты
• Как взаимодействуют помощники и водитель

Затем приложением стал пользоваться я. Это была роль помощника. Водитель только рулил, а я производил фотофиксацию.

Отличные мужики попались. Работают как пчёлы. У них мотивация быстрее свой маршрут очистил быстрее домой пойдешь. Поэтому, все их действия оптимизированы и доведены до автоматизма. Водитель даже приложением не пользуется, он знает все точки наизусть, что и когда убирать. А это около 40-60 адресов.

Этап 3 Анализ данных и выводы

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

Все данные я собрал в одном месте и залил на облако. Пока все было свежо в памяти, сформировал бэклог на доработки приложения, обновил CJM.

Инсайты, которые удалось получить

Вообще, инсайты я тоже приоритизирую на главные и второстепенные. Публикую только важное.

• Все основные водители знают маршрут по памяти. И знают, что и когда вывозится. А это до 40-60 адресов.
• Все подменные водители (выходят в случае болезни основного) не знают нюансов и деталей маршрута. Где-то надо заранее позвонить и взять ключ от ворот, у кого-то подъезд невозможен на загруженной машине по склону (пробуксовывает) на грунтовой дороге и нужно катить контейнер до машины.
• У водителя мусоровоза есть помощники, которые производят подкат баков. Они потенциально тоже могут работать с приложением и делать отчеты по КП, которые находятся на территории частных домов при мешковом сборе.
• Водители мусоровозов самые продуктивные люди в мире. А если у них есть помощники то это самая продуктивная команда.
• У них есть фиксированный объем работ обслуженные КП. За сколько часов успел, за столько успел. Сделал работы раньше иди домой. Поэтому все действия максимально эффективны и автоматизированы.
• При наличии помощников водитель не выходит из кабины и отчет делает по монитору заднего вида.
• Все водители пользуются видом отображения КП список, т.к. картой неудобно пользоваться. А список выстроен на основе бумажного графика, которым они ранее пользовались.

Многие эти инсайты так или иначе были задействованы в новом функционале мобильного приложение. Что-то еще готовится к релизу. Работа была проведена относительно недавно, поэтому результатов и обратной связи от нового функционала ещё недостаточно. Но мы держим руку на пульсе и работаем дальше, чтобы упростить работу людей.

Ну и вообще, декларируйте то, что делаете.

Заключение

Я ставил перед собой задачу показать на практике работу UX-дизайнера. Как она может выглядеть в действительности. Как строится ход мыслей. Не все мне удалось вместить в одну статью. Это тот случай, когда можно говорить и говорить.