Буду честен, я немного опоздал на вечеринку.

Недавно я закончил читать книгу Эрика Райса The Lean Startup (она вышла в прошлом году). Дело шло туго. Сначала я отложил чтение, полагая, что это — еще одна пустая книга на тему «Как открыть свое дело». У меня есть целая полка с такими книжками, большинство из которых не прочитаны дальше первой главы.

Но теперь я ее прочитал и думаю, что эта книга из разряда «mustread!» для любого человека из сферы UX. В этой книге мне нравится то, что она ставит UX в самое сердце нового продукта — и делает это на общедоступном языке. Вот моя краткая версия прочтенного материала.

User Center Design

  • Разработка новых продуктов или услуг — рискованное дело (много неопределенности)
  • Команда дизайнеров имеет множество гипотез — о пользователях, их целях, за что они будут платить и так далее. Для снижения неопределенности эти гипотезы должны быть проверены (ставим эксперименты)
  • Мы проводим тесты на версиях продукта с минимальным функционалом, т. к. их можно быстро легко создать
  • Проектирование происходит интерактивно, в повторяющемся цикле (создание-измерение-изучение) — так мы проверяем идеи «на пользователях» как можно раньше

Ничего не напоминает?

В книге сделано больше акцентов, но этого достаточно, чтобы объяснить, насколько такой подход соответствует User Center Design (дизайну, сориентированному на пользователя).

Особенно я хочу подчеркнуть интерактивное проектирование и тестирование. В UX разработано множество методов для получения быстрой обратной связи с пользователем — давайте рассмотрим некоторые из них.

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

Эти методы имеют такие общие черты:

1. Они практически ничего не стоят и их можно сделать за несколько дней. Так что они поддерживают понятие Райса «максимально быстрая итерация».

2. Они сосредоточены на поведении пользователей, а не на их мнениях. Как говорит Райс: «клиенты зачастую сами не знают, чего хотят».

Они позволяют нам тестировать наши бизнес-идеи еще на стадии разработки — и разработчики еще не написали ни единой строчки кода.

Вот эти три способа, которые я хочу обсудить:

  • Проверка гипотез через раскадровки
  • Проверка гипотез через бумажные прототипы
  • Проверка гипотез с помощью «Волшебника из страны Оз»

Проверка гипотез через раскадровку

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

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

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

Пример: мы хотим разработать новый способ оплаты, с помощью которого люди смогут купить билеты на поезд на железнодорожной станции с помощью электронных платежных услуг, таких как PayPal или «мобильный кошелек» в телефоне.

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

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

Представим это в эскизе:

Эскиз, показывающий, как люди могут взаимодействовать с системой

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

Вот как здесь: я создал образы, а затем объединил эскизы с фотографиями, сделанными на вокзале

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

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

Но есть еще несколько серьезных вопросов:

  • 1. Будут ли люди использовать свой мобильный телефон для оплаты в киоске? Может, они предпочитают пользоваться кредитными картами?
  • 2. Есть ли в телефонах большинства людей программное обеспечение для сканирования QR-кодов? Знают ли они, что такое QR-код?
  • 3. Что люди думают о электронной доставке билета? Есть ли у людей опасения по поводу того, что у них не будет “материального” билета?

Теперь у нас есть что показать железнодорожным путешественникам: просмотр раскадровки займет у них меньше минуты, а мы сможем проверить две гипотезы:

1. Проблема (нет возможности оплатить через мобильный) достаточно серьезна, чтобы оправдать решение? Если мы приедем на железнодорожный вокзал и опросим пятьдесят человек, и только трое из них скажут, что это неудобно — мы должны взять паузу и выяснить, что является проблемой на самом деле.

2. Если проблема существует, проверяем вторую гипотезу — наше решение подходит?

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

После каждого кадра мы задаем простой вопрос: «Нужен ли шаг, который вы видите?». Здесь мы тоже можем подсчитать количество людей, которые говорят «да» или «нет» на каждом шаге.

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

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

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

Проверка гипотез через бумажный прототип

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

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

Идея состоит в том, что вы садите пользователей перед прототипом, даете им сценарий («Купить билет из Лондона в Манчестер») и говорите им, чтобы они использовали палец в качестве мыши. Как только человек делает какой-то выбор, вы обновляете «экран» липкой заметкой с описанием — как он двигается по интерфейсу.

В прошлом, когда я писал о бумажных прототипах, люди говорили — «это старомодно» и «электронные средства прототипирования более эффективны».

Лично я не вижу это как «или-или». В процессе проектирования есть место обоим видам. Тем не менее, лучше не садиться сразу за компьютер на начальной стадии идеи.

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

Проверка гипотез через Волшебника из страны Оз

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

Один из моих любимых примеров этого теста — Механический турок.

Механический турок — большая игровая шахматная машина. Построена приблизительно в 1770. Считалось, что это настоящий робот. Вы садились за шахматный столик напротив манекена в турецком костюме (отсюда и название), который перемещал шахматные фигуры в ответ на ваши действия. Турок победил многих шахматистов, в том числе (возможно) Наполеона и Бенджамина Франклина.

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

Гравюра «Механический турок» (из Википедии)

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

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

Давайте посмотрим на современный пример такой иллюзии.

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

Мы заранее записали небольшое количество ответов, которые в любом случае пришлось бы использовать (например, «Повторите, пожалуйста, еще раз?»). Но поскольку мы не знали конкретных вопросов, мы не могли предварительно записать и ответы.

Вместо этого мы использовали технологию преобразования текста в речь, чтобы создать иллюзию работающей системы. Допустим, пользователь мог задать вопрос: «Какие семейные фильмы показывают во второй половине дня?».

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

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

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

Что это означает для вашего процесса проектирования

Есть три основных принципа дизайна, ориентированного на пользователя. К ним относятся:

  • Ранний и постоянный акцент на пользователях и их задачах
  • Итерационное проектирование
  • Эмпирические измерения поведения пользователей

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

Перевод статьи: Lean ways to test your new business idea.