Как UX дизайнер, я слышал множество причин, почему не нужно проводить пользовательское исследование. Обычно, я слышу классические варианты, вроде «у нас не хватает на них времени», и «не позволяет бюджет», но иногда говорят «пользователи сами не знают, чего хотят», или «ты же UX специалист — вот и реши».
…и так далее.
Дилемма:
Что делать, когда вы сталкиваетесь с подобными возражениями?
Ответ:
Не проводить пользовательское исследование — не вариант.
Более тактичный ответ:
Как только кто-то вне команды разработки начинает использовать продукт — он его тестирует.
Каждый раз, когда кто-то использует ваш продукт, он формирует мнение, теряется, сбивается, и делает еще много такого, что было бы вам интересно. Только вашей команде решать, будет ли она прислушиваться к поведению пользователей, или нет.
Настоящий вопрос должен звучать не «должен ли я проводить пользовательское исследование?», а «когда и как его проводить?».
Тестирование юзабилити происходит с вами или без вас
- Пользователи покупают ваш продукт (или нет)
- Пользователи используют ваш продукт чаще (или реже)
- Пользователи рекомендуют ваш продукт другим (или не делают этого)
- Пользователи не испытывают (или испытывают) затруднений, используя ваш продукт
- Пользователи видят (или не видят) в нем ценность
- Пользователям нравится ваш продукт (или нет)
Эти вещи происходят вне зависимости от того, есть у вас план исследований, или нет, и какие-то из них довольно просто отследить. Например, если никто не покупает ваш продукт, то вы знаете, что его никто не покупает; а если никто его не использует, то вы знаете, что его никто не использует. Не знаете вы только того, почему его не покупают или не используют. Вы знаете «что», но не знаете «почему». Поверьте, вашему менеджеру или клиенту ответ на этот вопрос будет очень важен.
В этом и заключается ценность UX исследований, и того, почему нанимают исследователей. Чтобы узнать «почему».
Итак, если вы не можете выбрать не проводить исследование, то какой выбор остается?
Вот четыре самых распространенных решения. Два из них одинаково хороши, и два одинаково плохи.
Неправильный выбор №1
Создать что-то большое, выпустить это, а затем игнорировать пользователей.
Это происходит сплошь и рядом, и это всегда неправильно. Как только вы выпустите продукт, то увидите, что его покупает и использует меньше людей, чем вы надеялись, но бюджета на то, чтобы понять почему так происходит уже не будет.
Если кто-то рассказывает вам об успешном проекте, для которого не проводилось пользовательское тестирование — им просто повезло. Это, как если бы победитель лотереи, давал вам совет по инвестициям. Ему повезло, но вам повезет вряд ли.
Неправильный выбор №2
Потратить слишком много времени на исследования до фактического выпуска продукта.
Такое редко, но случается. Чтобы быть футболистом, вы должны уметь играть в футбол. Вы должны тренироваться как на поле, таки в спортзале, но иногда нужно играть — и начать играть лучше раньше, чем позже.
Так же и с разработкой программного обеспечения. В какой-то момент, продукт нужно выпустить. Время, потраченное на исследования сделает ваш продукт сильным, но, как и в спорте, выпустить его лучше раньше, чем позже.
Правильный выбор №1 — MVP
Создать что-то небольшое, выпустить, и наблюдать.
MVP — Minimum Viable Product (минимально жизнеспособный продукт). По сути, это значит, что вы создаете нечто небольшое, выпускаете это, и наблюдаете за происходящим.
Это значит, что можно не проводить тестирование заранее, но нужно будет обязательно провести его тогда, когда продукт уже будет на рынке, и его начнут использовать.
Затем вы, в тесном сотрудничестве с первоначальными пользователями, добавляете функционал, и со временем улучшаете продукт. Вы создаете то, что им нужно, а не то, что им нужно по их словам.
Правильный выбор №2 — Сначала исследование
Исследование. Разработка. Повторить.
Понимание того, с какими проблемами сталкиваются ваши пользователи, а затем сопоставление этих проблем с тем, что ваш продукт в состоянии решить — отличный способ начать работу над проектом.
Тестирование одного пользователя в начале проекта лучше, чем тестирование 50 ближе к его окончанию. — Стив Круг
Каждый день, ваша команда принимает сотни небольших решений о дизайне, структуре, рекламе и разработке продукта. По отдельности, эти решения не кажутся последовательными, но вместе, они составляют разницу между успешным, и провальным продуктом.
Итак, очевидно, что нет смысла проводить исследование по каждому небольшому вопросу. Тем не менее, в начале проекта, можно уделить время тому, чтобы понять своих пользователей. Таким образом, ваша команда будет помнить о пользователе постоянно, принимая эти самые небольшие решения.
Заметьте, что единственная разница между первым (MVP) и вторым (Сначала исследование) подходом заключается в том, что в первом, вы сначала создаете, а потом тестируете, а во втором наоборот. По поводу того, какой вариант лучше, мнения расходятся, но в действительности, всё зависит от вашей команды, бизнес-целей, и пользователей.
Перевод статьи Бена Ральфа
