В свою первую стажировку я проработал продукт-менеджером и UX-дизайнером всего лишь два месяца, однако узнал о проектировании куда больше, чем за время работы разработчиком.
Технические навыки — это must-have, когда речь идет о технологиях. Но большинство людей считает, что про алгоритмы и реализации можно просто нагуглить. Нельзя сказать, что проектирование сводится к банальному копипасту — настоящее проектирование сопряжено с выявлением причин, как и почему мы создаем продукты.
Несмотря на обилие опыта, полученного при стажировке по разработке ПО, наиболее полезным, с точки зрения саморазвития и общего накопления знаний по проектированию, я считаю именно непродолжительный стаж пребывания продукт-менеджером.
1. Начните с MVP
Есть у меня дурная привычка — с головой погружаться в создание навороченных функций, на которых можно опробовать свои технические навыки.
Очень много времени в своей первой стажировке я тратил на написание кода полюбившихся мне функций, которыми никто и никогда не смог бы воспользоваться. Все работало, но я не выстраивал нужной фундаментальной базы проекта, которая помогла бы людям воспользоваться написанной функцией.
В первую очередь пользователям важна реализация базового функционала. В противном случае, зачем они будут тратить свое время на продукт, который не делает того, что им нужно?
Нельзя продать кому-то несуществующий дом, даже с самыми красивыми окнами и шедевральной плиткой. Все равно людям нужен именно дом.
Другими словами, не важно, что именно вы создадите, если этим все равно никто не воспользуется.
Сначала выпускайте MVP (минимально жизнеспособный продукт) — так пользователи увидят, что получат именно то, что им нужно. И только потомдобавляйте туда навороченный функционал.
2. Говорите с людьми.
Зачем вам нужно беседовать с пользователями?
Знаю, звучит глупо. Но как разработчик я не раз задавался таким вопросом, ведь единственное, чего мне действительно хотелось, — это поскорее приступить к написанию кода.
Мне казалось, что я и сам вполне подойду на роль пользователя, и усилием мысли смогу разобраться во всех пользовательских потребностях.
Но даже если вам кажется, будто вы знаете, чего именно пользователь хочет и ждет, вы гарантированно заблуждаетесь. Особенно, если сами вы не являетесь пользователем.
Однажды кто-то сравнил этот процесс с виртуальной реальностью. Вы, разработчик, надеваете гарнитуру, и с помощью виртуальной реальности начинаете видеть все глазами пользователя.
Да, вы можете притвориться пользователем, но как подобрать нужную среду? Кто-то должен будет создать эту среду и опробовать то, что вы получите при подключении гарнитуры. А если сценарий тоже пишите вы, то он будет ограничен вашим воображением и пониманием. И все это будет кардинально отличаться от того, как другой пользователь продукта опишет собственный опыт.
Вы не узнаете ничего нового о продукте, который сами же и создали.
Одних мыслей и умозаключений здесь будет мало, ведь ваш процесс мышления выстраивается на основании собственного знания и опыта. Вам потребуется другой человек, который покажет и разъяснит структуру проекта — так вы сможете увидеть его глазами других и прочувствовать тоже, что и они.
Вы — не они. Причем, скорее всего, продукт вы создаете не для себя, а для других.
3. Выбросите опросники. Вам нужны интервью.
Нам казалось, что более широкую группу пользователей можно охватить рассылкой опросников, а не личными встречами.
Конечно же, опросники намного дешевле, занимают меньше времени и позволяют обратиться к большей аудитории.
К сожалению, большинство людей не тратят время на вдумчивое заполнение опросников.
Особенно, если вы лично не знакомы (а ведь нас не знает никто, кроме парочки новых стажеров), или они не испытывают ярко выраженной потребности в том, что вы продаете (обычно так и бывает).
Даже когда мы пытались продавать продукт с наброском проекта до создания опросников, то получали минимальные отклики. Большинство людей никак не реагируют на письма, если в них отсутствует срочность, они не знают отправителя или письмо не проходит через фильтры почтового сервера.
Каким образом заставить потребителя как можно быстрее купить что-то, не особо ему нужное от вас — незнакомого человека, до которого пользователю нет никакого дела?
В итоге мы потратили почти две недели, проводя личные встречи с потенциальными пользователями, которые при положительном решении о покупке, могли бы рассказать о нас другим. Мы встретились с каждым персонально, представили наш проект, получили обратную связь, и обрели в их лицах наших первых пользователей. Коэффициент конверсии возрос после того, как мы заставили людей потратить время на вдумчивое изучение нашего предложения, и убедили их в ценности продукта, потребности в котором они не ощущали ранее.
Было ли это затратно по времени? Конечно.
Оказались ли интервью более ценными, чем опросники? Еще как!
А еще некоторые кандидаты принесли с собой всякие интересные технические примочки и сюрпризы, что сделало само интервью куда более занимательным.
4. Хороший пользовательский опыт ведет к успешной разработке.
Наибольшую гордость от написанного кода я испытываю тогда, когда после завершения работы он может выполняться самостоятельно.
Если код может поддерживать себя сам, то я победил.
Если все работает без моего участия, то продукт можно пускать в дальнейшую реализацию (то есть, я создал нечто ценное), и мне не придется лишний раз нянчиться с кодом. То есть, я смогу взяться за следующую интересную разработку.
А если пользователи постоянно путаются в программе и допускают ошибки, то вас ждет целый шквал вопросов и запросов по электронной почте. И даже если работа над самим кодом уже завершена, то корректировка наборов данных и общение с разъяренными и отказывающимися от вашего продукта пользователями еще впереди.
Я понял одну вещь: очень многого негатива можно избежать продуманным дизайном и описанием.
1. Спрячьте все ненужное пользователю. Если человек чего-то не видит, то он не станет там кликать и совершать разные ошибки. Не оставляйте серых полей, потому как пользователи захотят узнать, почему этим нельзя пользоваться, даже если им оно совершенно не нужно.
2. Выделяйте цветом главный функционал и все важное для пользователя.
3. Анимация загрузки— это НАШЕ ВСЕ. Если пользователи не видят прогресса происходящего, то им кажется, будто ничего не происходит. Тогда ждите многочисленных кликов и неожиданных поворотов, к которым код может оказаться не готов. Просто покажите пользователям крутящийся спиннер!
4. Ссылка на документацию с FAQ. В 80% случаев пользователи спрашивают об одном и том же. Перенаправление их на страницу с FAQ значительно экономит место в моем почтовом ящике.
5. Доступность — это ключ, открывающий двери ко многим потенциальным пользователям, которые смогут опробовать ваш сайт (и для них он не покажется трудным!)
Хороший дизайн позволяет пользователям научиться работе с продуктом самостоятельно. Это крайне важно, т.к. никто не хочет возиться с документацией.
Сэкономьте собственное время и избавьтесь от головной боли, дав пользователям нужные инструменты, и они полюбят ваш продукт за продуманную структуру.
Перевод статьи Allison Chow: Want To Be a Better Developer? Work in UX
