Некоторые дизайнеры склонны воспринимать «бережливый UX» (lean UX) и минимально жизнеспособный продукт (MVP) как результат. А ведь на самом деле это процессы, при должном исполнении которых вы получаете лучшие результаты — продукты, удовлетворяющие ваши бизнес-потребности и вместе с тем решающие проблемы клиентов наиболее оптимальным способом.
Процесс (или, как ее еще называют, «петля») бережливого UX мало чем отличается от научного метода — наблюдения, формирования гипотезы, проверки и сбора данных, анализа результатов, а затем принятия или опровержения гипотезы. Только здесь шаги обозначаются так:
- идеи (наблюдение и гипотеза)
- разработка (тестирование)
- изучение (анализ результатов и решение по гипотезе)
Либо же процесс и вовсе описывают еще более простой фразой:
«Думай, делай, проверяй».
Как и научный метод, процесс бережливого UX является циклическим и продолжается до достижения желаемого результата. Однако здесь можно начинать на любом этапе петли (большинство начинают новые проекты либо с изучения, либо с идей, но работают над устоявшимися продуктами, которые позволяют стартовать где угодно).
Концепция минимально жизнеспособных продуктов хорошо вписывается в методологию бережливого UX и, как правило, сводится к построению (или прототипам), измерению и изучению (а затем повторению на основе полученных данных). Легко заметить, что эти шаги коррелируют с петлей бережливого UX, особенно в сжатой версии.
Некоторые путают MVP с прототипом, так как первый этап разработки иногда называют прототипированием. Но MVP представляют собой готовые к работе, завершенные продукты, и в разрезе бережливого UX они так же должны быть полностью функциональными решениями.
Содержание статьи
Перестаньте думать о конечном продукте
Сосредоточьтесь на потребностях пользователя
Думайте о необходимых функциях
Построение MVP по методике бережливого UX
Вся суть в итерации
Когда MVP по методу бережливого UX считается готовым
Вместо заключения
Перестаньте думать о конечном продукте
Увидев определенную проблему, многие UX-разработчики склонны забегать наперед и сразу же думать о финальном продукте, который мог бы ее решить. Ведь если цель заключается в получении конечного продукта, почему бы не начать прямо с него?
Но на деле такой реверсивный подход лишь ограничивает инновации и креативность. Способов справиться с проблемой пользователя может быть много, и сосредоточившись на итоговом результате, вы можете запросто упустить наиболее эффективные потенциальные решения.
Напротив, отказавшись от каких-либо предубеждений насчет того, что больше всего поможет людям, можно прийти к куда более инновационным идеям. В своей книге «Бережливый UX: применение бережливых принципов для улучшения пользовательского опыта» (Lean UX: Applying Lean Principles to Improve User Experience) Джефф Готельф (Jeff Gothelf) говорит, что бережливый UX «призван как можно быстрее выявлять истинную природу продукта». Это коллаборативный процесс, направленный на формирование «общего представления о реальном опыте взаимодействия с продуктом».
Этот процесс требует понимания не только потребностей целевой аудитории, но и нужд бизнеса еще до начала работы. Именно от него разработчики должны отталкиваться на всех остальных шагах проектирования пользовательского опыта.
Сосредоточьтесь на потребностях пользователя
Когда разработчик подходит к проблеме, то зачастую считает, что знает, в чем состоит ее суть. Скажем, если идея в том, чтобы создать приложение для списков текущих дел, он может предположить, что пользователям нужно решение, позволяющее добавлять задачи в перечень, и ничего более. В таком случае их изначальный MVP по методике бережливого UX был бы нацелен на создание сервиса, обеспечивающего эту функцию.
Но является ли такое решение наилучшим?
Люди не пользуются подобными продуктами только для составления списков — с их помощью они пытаются организовывать свою повседневную жизнь. Они боятся, что без упорядоченного чек-листа могут забыть о чем-то важном. И формат списка может быть не самым эффективном способом отслеживать выполнение задач.
Но если разработчик приступает к проекту с мыслью «мне нужно создать приложение для перечня дел», он может никогда и не прийти к идее, которая бы лучше послужила людям, заинтересованным в продукте. Сосредоточившись на потребностях пользователей и забыв о своих собственных предположениях, можно найти решение, которое устранит реальную проблему, вместо того чтобы просто делать очередной сервис для списков задач.
Разработчики должны мыслить критически и стараться оспаривать свои допущения о том, что нужно пользователю. Зачастую люди и сами не знают, что им надо для решения их проблем, поэтому предполагать что-либо серьезное в этом плане без предварительного исследования аудитории бессмысленно.
Один из способов изучения потребностей потенциальных клиентов состоит в том, чтобы сфокусироваться на их болевых точках — тех аспектах проблемы, которые тревожат их больше всего. Акцентируя внимания на этом, вы можете быстрее докопаться до сути и найти уникальные решения. К примеру, в приложении для списка задач болевой точкой наверняка является страх забыть о чем-то значимом или необходимость держать в голове кучу информации.
Как только у разработчика возникает идея для решения проблемы, он должен протестировать ее на реальных людях. Тратить слишком много времени на создание готового продукта с самого начала не нужно — вместо этого, направлять усилия надо на получение пользовательского фидбека.
Первая итерация могла бы быть чем-то простым вроде набора слайдов или полуфункционального макета. То, что позволяет людям получить общее представление о предложенном опыте, является полезным предвестником создания MVP по методике бережливого UX.
Такие ранние предварительные MVP могут пригодиться для мэппинга пользовательских путешествий. Как только первоначальная обратная связь будет собрана, разработчики получат лучшее представление о том, что люди действительно хотят от продукта. Это очень полезно для определения того, как провести их от точки А (их проблемы) в точку Б (идеальное решение). При этом в процессе изучения фидбека можно выяснить, сколько шагов должно быть в клиентском пути.
Разработчики даже могут обнаружить, что на самом деле изначальная проблема, которую они пытались решить, не является реальной проблемой. В приложении для списков дел, к примеру, может выясниться, что функционал, который бы позволял людям меньше беспокоиться о запланированных делах, является более ценным конечным продуктом, нежели обычный сервис для упорядочивания задач. Без активного поиска обратной связи и создания новых итераций, нацеленных на устранение реальной проблемы, вы можете так никогда и не найти это оптимальное решение.
Анализ поведения пользователей, или 5 видов трекинга
Думайте о необходимых функциях
Большинство пользователей не понимают, что за функции им нужны. Вместо этого, они фокусируются на преимуществах, и разработчику нужно выяснить, какие именно возможности обеспечат эти преимущества. Он должен составить список таких «фич», включив в него не только хорошие, но и плохие идеи, которые в дальнейшем могут вылиться в более инновационные концепции.
Как только такой большой перечень идей будет готов, начинайте сокращать его до тех пунктов, которые технически осуществимы с учетом ресурсов проекта и наилучшим образом закрывают болевые точки клиента. После этого можете приступать к разработке MVP и тестированию с потенциальными пользователями.
Построение MVP по методике бережливого UX
Обдумывание идей — этой первый и важный шаг к созданию минимально жизнеспособного продукта, но разработку реального рабочего решения тоже лучше не откладывать.
Очень важно не пытаться внедрить все возможные функции в изначальную «сборку». Лучше сосредоточьтесь на минимальном функционале, который бы справлялся с самыми критическими «болями» пользователей. В первой версии UX нужно фокусироваться на возможностях с потенциально самым высоким показателем ROI. Но определить их реальную ценность получится, только когда люди начнут пользоваться продуктом.
Какие бы функции вы ни выбрали на этом этапе, важно, чтобы юзеры приспосабливались к взаимодействию с ними и давали вам фидбек как можно быстрее. И здесь вам определенно пригодится навигатор интерфейсов Experrto, позволяющий адаптировать людей к работе с новыми сервисами в сжатые сроки.
За счет его интерактивных подсказок пользователи смогут знакомиться с разными версиями вашего продукта и с большей вероятностью будут достигать WOW-эффекта, который имеет огромное значение для лучшего удержания.
Как измерить ROI ваших вложений в пользовательский опыт
Вся суть в итерации
Сбор качественного фидбека и количественных данных бесполезен, если вы не создаете лучшие итерации продукта на основе этой обратной связи. Помните, что MVP по методу бережливого UX представляет собой процесс, а не результат. И один из самых важных этапов этого процесса заключается в создании новых, обновленных версий продукта для более эффективного удовлетворения потребностей клиентов.
Каждая итерация MVP должна опираться на информацию, собранную у реальных пользователей. Это значит, что все версии нужно тестировать либо в рабочей среде, либо при участии небольшой группы людей. Во многих случаях имеет смысл провести тест с меньшей выборкой, а уже затем, основываясь на ответах этих юзеров, расширять масштабы тестирования.
В маленьких группах собирайте качественный фидбек. Задавайте людям вопросы о продукте, чтобы понять, что работает, а что — нет, и прислушивайтесь к их идеям по улучшению или изменению чего-либо.
В рабочей среде акцент смещается на количественную обратную связь (показатель отказов, время на странице и брошенные корзины в случае с интернет-магазинами). Отталкиваясь от этих данных, вы сможете понять, движется ли итерация в верном направлении.
Когда MVP по методу бережливого UX считается готовым
Ответ на этот вопрос может сильно варьироваться в зависимости от сложности продукта, качества тестирования, собранной информации и количества итераций, не показывающих заметных улучшений. Во многих случаях момент 100%-ной удовлетворенности продуктом для каждого пользователя не наступает никогда. Команды должны сами решать, какой уровень недовольства является приемлемым с учетом своих бизнес-целей.
Разработчикам и акционерам необходимо вывести критерии завершенности проекта (или хотя бы его готовности к релизу без продолжающегося тестирования и новых итераций). Эти критерии могут включать себя такие вещи, как:
- более высокая конверсия клиентов;
- большее время, проводимое на сайте;
- более высокая оценка качества или индекс удовлетворенности от клиентов;
- меньше количество жалоб;
- прирост клиентской или пользовательской базы;
- большее количество подписок.
Точные критерии и цели должны обсуждаться в начале проекта и регулярно пересматриваться. Поскольку итерации меняются в зависимости от отзывов клиентов и пользовательского тестирования, вместе с этим вам может потребоваться и скорректировать ваши цели.
По правде говоря, продукты редко когда считаются полностью завершенными. Даже после финального релиза многие аспекты подвергаются изменениям ввиду назревающих трендов, появляющихся новых технологий или демографических факторов. Любая из этих причин может обусловить эволюцию вашего дизайна в будущем, и вы всегда должны помнить об этом.
Вместо заключения
Разработка MVP по методике бережливого UX имеет массу преимуществ перед другими стратегиями и может раз за разом использоваться для создания оптимального продукта. Это простой и прямолинейный подход, в рамках которого разработчики могут работать как в команде, так и в одиночку. Он дает вам четкий план действий, повышает эффективность ваших решений и ограждает вас от ненужных затрат.
Прокачайте свой онбординг!
Подписывайтесь на нашу группу в фейсбуке и канал в телеграм, чтобы следить за обновлениями.
По материалам: toptal.com
