Разработка платформы для интервью и исследований на основе искусственного интеллекта — Invi AI

Aleksei Mikhalev
DesignSpot
Published in
10 min readAug 22, 2019

или как сделать интервьюера чуточку счастливее. Часть 1: Низкий старт

[UX Сase Study]

Это статья из серии рассказов о проектах в DesignSpot School 2019.
Проект разрабатывался в рамках
летней менторинг-программы командой студентов школы и менторов из сообщества DesignSpot.
Задачей команды было разработать цифровой продукт или сервис для решения конкретных задач реальных заказчиков.
О всех трудностях дизайн-процесса, созданных артефактах и поиске решений, вы узнаете из этого лонгрида.
! Добавьте статью в закладки, так как информации очень много и за раз все полезное не запомнить, и не забудьте похлопать :)

Автор: Nata

Привет тебе, интересующийся дизайн-процессами и продуктовой разработкой читатель! В этой статье ты найдешь взгляд со стороны project-manager-а на процессы работы дизайн-команды в рамках этапа менторинга в DesignSpot School (далее — DSS).
Так как хочется рассказать очень много, а за одну статью не получится, то вся история и ее последствия разбиты на несколько частей. Финальная часть выйдет после 24-го августа, когда наша команда презентует итоговый проект миру. В них вы узнаете как проходил процесс поиска дизайн-решений, полный разворот концепции, анализ конкурентов, тестирование идеи и прототипов. А также узнаете, как получилось сделать рабочий прототип реального продукта и что из него вышло спустя время после завершения DSS. Поэтому, подписывайтесь, будет еще много интересного и полезного:)
Ну, со вступлением закончили. Теперь переходим к делу!

Разрешите представиться! Меня зовут Алексей, можно просто Лёша. Я являюсь членом крутой команды под кодовым именем invi, она же во младенчестве interview_platform, куда входят еще студенты-дизайнеры Ната, Ира и Денис и наши менторы Nikita Zenchenko и Коля Булава. А также неотъемлемая ее dev-часть, которая пополнила наши ряды немного позже, в лице Пети, Лизы и Димы. Я уверен, они обязательно поздороваются с тобой в комментариях к этой статье.
Приятно познакомиться! :)

Слева направо: Ната, Денис, Ира и ваш покорный слуга :)

Итак, наше знакомство с командой состоялось 10 июня на установочной встрече DSS. Встреча получилась очень крутой и насыщенной! Себя показали, на других посмотрели, с планом на ближайшие 2,5 месяца познакомились. Но по ее окончании, особенно глядя на учебный план, было какое-то нехорошее предчувствие… И ведь не подвело нутро! Но об этом позже.

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

Очень быстро стало понятно, что работать по такой системе нам не представляется возможным по различным причинам. Основной косяк — это эстимации. По некоторым задачам промахи были не на 20–30%, а в 4–5 раз! Обычно понимание объема и сложности типовых задач приходит к 5–7 спринту, но не в нашем случае, т.к. однотипных задач в нашем кейсе-то и не было. О опыт, сын ошибок трудных… Второй момент был в том, что у нас не подразумевалась как таковая итеративная разработка. Но с помощью менторов пощупать своими руками, как это работает на живых проектах, было очень интересно и полезно! Потом был переход на обычный canban в Trello. Задачи выполнялись не хуже, экономилось время, затрачиваемое на scrum-процессы. Ну и прекрасно!

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

Вот и началась работа! “Ура, товарищи”, кричали мы радостно в тот момент. Глупые! Тогда мало кто представлял, во что ввязался…
Ведь все активности DSS приходилось совмещать с кучей других, мешающих творческому и исследовательскому процессу дел: дети, семья, личная жизнь, работа, в конце концов! :)
Но тогда все были очень воодушевлены и с рвением взялись за дело.

В результате мини-брейшторма было придумано кодовое название проекта — invi (ну не нравилось нам название interview_platform) и нарисован логотип.

Автор логотипа и слогана: Denis

Составлена цветовая схема.

Автор: Nata

В качестве фирменной была выбрана шрифтовая гарнитура Segoe UI.

Но, конечно, самое интересное происходило в исследовательском процессе. Для начала нужно было посмотреть, а что же из инструментов уже есть на рынке. Анализ проводился по трем принципиальным направлениям: умные диктофоны (Otter, Voicea и др.), инструменты для исследователей (Morae, Userfeel, Noldus и т.п.) и платформы для HR-интервью (Tazio, EasyHire, Skeeled, Sparkhire и еще десяток разных). Проанализировав функционал и используемые технологии конкурентов, получив весьма развернутую информацию от заказчика (ну ладно, менторов) был составлен дизайн-бриф.

Actual Design Brief

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

Project background (why)

Автор: Nata

Интервью — один из наиболее популярных методов исследования, который доступен каждому проекту и дает хорошие результаты. Его часто комбинируют с другими методами исследования для проведения юзабилити-тестирований, аудита продукта, сбора мнений, маркетингового анализа, социальных исследований.
Однако несмотря на его популярность, в самом процессе подготовки, проведения и обработки результатов интервью много трудностей, которые делают процесс долгим, дорогостоящим и неэффективным, в особенности на больших проектах, где нужно проводить десятки или сотни интервью.
Часто это ведет к потере доверия со стороны бизнес-стейкхолдеров, которые предпочитают не выделять время и ресурсы на исследования в целом, направив их напрямую в разработку, что приводит к частым случаям, когда дизайнеры работают вслепую, руководствуясь только требованиями заказчика и не имеют возможности проверять свои решений на пользователях. Как правило, результатом такого подхода являются многократные переделки, изменения требований “на лету”, удорожание проекта и увеличение времени разработки, неудовлетворенные пользователи и демотивированная команда.
На сегодняшний день нет эффективного и доступного широкому кругу исследователей комплексного инструмента и способа решения проблем исследований, которые позволяют подготовить, провести и обработать интервью.
Мы хотим усовершенствовать этот процесс и разрабатываем сервис, который поможет максимально быстро и эффективно провести исследование на основе интервью, позволив команде любого масштаба чаще общаться с пользователями и создавать более успешные проекты.

Problem Statements

Для исследователей:

Автор: Nata
  1. Интервьюер не может эффективно вести полноценный протокол во время интервью: проблема наиболее остро касается маленьких команд (team-of-one), когда интервьюер ведет сессию в одиночку и обрабатывает результаты сам. В ходе самого разговора невозможно вести полноценный протокол, фиксируя всю важную информацию, так как интервьюер быстро потеряет фокус беседы и внимание респондента. Поэтому исследователям приходится многократно переслушивать записи и восстанавливать скрипт после сессии;
  2. Постобработка результатов интервью занимает в 2–3 раза больше времени, чем сама сессия: обработка результатов интервью часто занимает слишком много времени: до 3–4-ех часов на одночасовое интервью. При этом, увеличение количества людей для обработки не позволяет существенно сократить это время из-за линейности процесса и ограниченности возможности распараллелить процесс;
  3. Сведение протоколов от ассистентов при командной работе занимает времени и ресурсов больше, чем при одиночном протоколировании: разные люди ведут протокол в разном формате и потом сложно объединять их в один итоговый документ.

Для бизнеса:

Автор: Nata
  1. При большом количестве сессий интервью, время на проведение исследования может превышать допустимые лимиты проекта или спринта, и от исследований могут отказать вообще;
  2. Большие затраты по времени и ресурсам для проведения больших (комплексных) исследований: при увеличении количества исследователей, добавлении ассистентов или наблюдателей (в том числе представителей заказчика), которые могут вести свой протокол во время интервью, получается собрать больше разноплановой информации, но это сильно усложняет процесс и требует высококвалифицированных специалистов, а исследование становиться дорогим и долгим, недоступным для продуктов с ограниченными бюджетами.

Итоговая формулировка

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

Picture of Success

Автор: Nata

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

Ключевой критерий успеха — время на постобработку интервью не превышает время на саму сессию интервью.

Requirements (what)

Для обеспечения Picture of Success продукт должен предоставлять собой All-in-one платформу с ключевыми компонентами:

  1. инструменты подготовки к интервью и созданию скриптов (написания гипотез, вопросов, описание профилей респондентов);
  2. возможность проведения и протоколирования сессии одним модератором или командой из исследователей и наблюдателей;
  3. возможность проведения очных и удаленных интервью;
  4. инструменты обработки результатов: сведения наблюдений, заметок и записей от всех участников в единый протокол;
  5. защита и конфиденциальность всех данных.

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

6. сведения нескольких протоколов в один отчет или базу данных по исследованию;

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

8. архива записей сессий и протоколов;

9. шаблоны исследовательских фреймворков для разных типов задач, гипотез, скриптов;

10. синхронизация и работа через облачные технологии технологии и web-клиент;

11. возможность работы в закрытых корпоративных сетях на локальных серверах (как продукты atlassian).

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

Audience (who)

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

1 ) Team of one — исследователи, которые проводят исследование и обрабатывают результаты в одиночку.
Это могут быть дизайнеры, бизнес-аналитики, HR-специалисты, product-owner-ы, социологи и все, кто использует интервью как исследовательский метод сбора информации;

Автор: Nata

2) Небольшие команды из 2–3 человек, которые распределяют роли модератора и ассистента в процессе проведения исследования.

Автор: Nata

Дополнительными группами могут быть:

3) Исследовательские студии со специализированными командами и уникальным исследовательским процессом.
Ключевое их отличие от основных групп в характере предоставляемых артефактов и невключенности в процесс разработки;

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

Design principles

  1. Единая среда для всего процесса исследования — All-in-one;
  2. Доступ и возможность работы с любого устройства (телефон, планшет, компьютер);
  3. Кастомизируемые решения для каждой задачи и каждого типа пользователей;
  4. Отсутствует порог вхождения. Чтобы пользоваться системой не нужно читать/смотреть мануалы;
  5. Система помогает начинающим исследователям и не мешает профессионалам;
  6. Интерфейс позволяет работать долго и эффективно в приложении, не вызывая усталости и напряженности глаз. Необходима цветовая тема для работы в темных помещениях.

Business values and project details, expectations from designer’s work

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

Blockers and restrictions

  1. Малая и специфическая выборка респондентов для тестирования. Страховка — просить менторов об увеличении кол-ва респондентов и/или интервьюеров;
  2. Ограничения во времени, людях. Страховка — выделение времени на research за счет visual;
  3. Политика безопасности в ЕПАМ (или др. компании) может наложить ограничение на функционал или архитектуру продукта. Защита данных. -?

Planned design activities and project roadmap

Чтобы достичь поставленных целей, мы планируем:

  1. Провести комплексное исследование самого процесса подготовки и проведения интервью у разных групп пользователей;
  2. Описать процесс для каждого типа пользователей, выделить отличия и определить барьеры, чтобы разработать эффективное решений для всех;
  3. Сформировать функциональный беклог и приоритизировать их на основе требований пользователей и бизнес;
  4. Разработать прототип сервиса и детализировать прототипы ключевых функций и сценариев работы;
  5. Протестировать концепцию и ранние прототипы, доработать дизайн-решения на основе фидбека;
  6. Сделать визуальных дизайн и интерактивный прототип сервиса;
  7. Описать итоговую концепцию, подготовить презентацию и запитчить так, чтобы нам дали миллион долларов на разработку!

/// В брифе детальный роадмэп делается для приблизительной эстимации проекта. В нашем случае это неактуально.

Сейчас это писать легко, а в тот момент бриф переписывался бесконечное число раз (примерно 12 :) )! Он уже почти победил, когда в дело настойчиво вмешались менторы и заступились за нас. С их помощью, и с опозданием по графику чуть больше 2 недели, бриф был побежден! В последующем он подвергался небольшим корректировкам, но основная идея осталась та же. И после того, как мы смогли четко обозначить задачу, границы проекта и ожидания от результата, работать стало понятнее и легче. Поэтому, настоятельно рекомендуем вам всегда начинать проект или задачу с очень четко проработанного брифа, который станет фундаментом ваших дизайн-решений. Без хорошо прописанного брифа путь будет непрост.
Хотя, нам и с брифом было нелегко. Но об этом вы узнаете из следующих выпусков.

Не прощаемся! И, как говориться, продолжение следует…

invi team

Читайте другие статьи из серии UX Сase Studies проектов DesignSpot School 2019

Сообщесво и школа в сети:
- DesignSpot на Medium
- Сообщество DesignSpot на Facebook
- Бесплатная школа дизайна от DesignSpot на Facebook
- DesignSpot в Telegram
- DesignSpot в Instagram #dsgnspot

--

--