Download to read offline
Uploaded byMichael Karpov
"Пользователи: сигнал из космоса". CodeFest mini 2012
Документ обсуждает важность обратной связи от пользователей в процессе разработки продуктов, выделяя роль доверительных отношений и активного вовлечения сообщества. Приводятся советы по сбору фидбэка, включая использование прототипов и бета-тестирования, а также мониторинг пользовательского поведения и метрик. Автор подчеркивает необходимость в проверке отзывов и постоянном диалоге с пользователями, чтобы избежать ошибок и улучшить продукт.
More Related Content
Similar to "Пользователи: сигнал из космоса". CodeFest mini 2012
"Пользователи: сигнал из космоса". CodeFest mini 2012
- 1. Пользователи: сигнал изкосмоса Михаил Карпов
- 2.
- 3. Нужен ли вообщефидбэк? • Есть команды, которые подстраиваются под пользователей и стараются выполнить все его пожелания • А есть команды, которые посылают это к чёрту ост рос не пр Воп
- 5.
- 6. Пре-альфа • Знаем: ничего •Понять: «Работает ли идея?» (идея) • Пользователи: команда и сочувствующие 6
- 7. • Ошибайтесь раньше!Они вам помогут • Наберите критическую массу отзывов • Диалог: правильное время/место/человек
- 8. Ещё раньше старта! •Хватит только описания идеи
- 9.
- 10. ой фи дб эк З аказн
- 11.
- 12. Бета-версия • Знаем: гипотезыповедения • Понять: «Правильно ли работает?» (фичи) • Пользователи: гики и немного нормальных людей 12
- 13. Как увеличить фидбэк? •Доверительные отношения • «Фан-группа», коммьюнити • Подарки • Обязательно отвечайте своим пользователям • Важна социальность – чтобы люди рассказывали друг другу • «Пригласите» пользователя оставить фидбэк
- 14.
- 15. Комьюнити и мониторингблогов
- 16. Массовое общение Яндекс.Карты (WP7)
- 17. Редизайн / версия2.0 • Знаем: итоги запуска первых версий • Понять: «Как бы не испортить?» (баги) • Пользователи: обычные пользователи 17
- 18.
- 19. Бета-тестирование Яндекс.Работа
- 20.
- 21. Общие замеры • Склад • Музей – есть гид – понятен порядок – изучают поведение – убирают непросматриваемое
- 22. Что оцениваем • Насколькозаметно (по доле людей, например) • Так ли используется (логи и Метрика) • Не нашли ли люди дополнительного профита, который мы не предполагали • Как запуск помог окружению (возвращаемость и пр.) • «Краевые ситуации» 22
- 23. На что смотрим? • Количество просмотренных страниц • Густота кликов • Используемость фич • Длина сессии • Количество уникальных посетителей • Время между кликами • … 23
- 24.
- 25.
- 26. Что не увидетьна приборах? • Иногда продукт «покупают» из-за каких-то крутых фич, хотя их потом и не используют • Какие-либо качественные показатели
- 27.
- 28.
- 29. • До запуска – бумажные прототипы • Первый запуск – юзабилити – внутренний запуск • Редизайн – бета-тестеры – форумы и мониторинг блогов – аналитика поведения пользователей – сплит-тесты • Текучка: формы фидбэка к хо рошо Не в с ё та
- 30. В итоге • Проверьтепросто ли с вами связаться • Фидбэк чрезвычайно важен до и во время старта • Не доверяйте слепо фидбэку, проверяйте логами • Наблюдайте за пользователем «вживую» • Учитывая пожелания важно не сделать хуже основной массе пользователей
- 31. Спасибо за внимание! Вопросы? Карпов Михаил (michail.karpov@ya.ru) pmrussia.blogspot.com @michailkarpov 31
Editor's Notes
- #3 Занимаюсь продуктовым и проектным менеджментом в Яндексе. Придумываю и провожу тематические IT-мероприятия (ProductCamp, План Б, AgilePiter). Я буду только про рынок B2C , в основном, про веб
- #4 «Идея от Олега» Есть команды, которые подстраиваются под клиента и стараются выполнить все его пожелания А есть команды, которые делают просто продукт, не записывают фидбэк и считают что если фича действительно нужна, то миллион пользоватлей просто задолбают вас этим и вы этого не забудете
- #5 95% - мелкие баги и вопросы 5% - идеи и новая функциональность
- #6 как им будет проще до вас достучаться? какой им будет профит с оставления вам фидбэка Гики? Фанаты продукта? Постоянные пользователи? Пользователи конкурентных продуктов? Люди, разово использовавшие продукт?
- #7 Польза: вполне возможно, что после первого прототипа изменится сама бизнес-идея
- #8 Очень важен фидбэк от ранних пользователей показать коллегам, показать их родным Важна команда раздать бесплатно прототипы Потом будут уже повторяющиеся вопросы или массовое недовольство/радость (что-то отвалилось или появилось новое) иногда будут советовать что-то новое-интересное, но редко
- #9 Стоимость: 0 – дизайн 1 страницы Кто участвует: руководитель – руководитель+дизайнер
- #10 Стоимость: 0 – дизайн прототипа Участники: руководитель – руководитель+дизайнер История про Tesla Motors
- #11 http://verifyapp.com/u/24696 http://www.feedbackarmy.com/ + опросы и анкетирование
- #12 Стоимость и участники: вёрстка – вёрстка+бэкенд Нужна минимальная функционаьность, возможно даже не шибко работающая. Внутренний релиз на компанию Некоторые компании делают кнопки (на них написано название функциональности) – но её нет! И только если достаточно количество людей нажимают на эту кнопку, то компания начинает разрабатывать эту функциональность + быстро получааем новые полезные фичи, на которые можно рассчитывать маркетинг и иногда они совсем не те что ожидались
- #13 Польза: сделать минимальный набор фич – быстро и с минимальными затратами
- #15 Обычно людям не нравится не весь сервис, а какая-то его конкретная часть (возможно в какой-то из моментов времени) – и нужно именно это дать передать вам как можно проще
- #16 Про «замеры волны» и мониторинг блогов в Яндексе. Пример TF2 и WoW , предлагают новое + на каждый патч собирают фидбэк через активное сообщество. Если сервис не «залипательный» (пользователь на него заходит практически ежедневно и просиживает больше 1-3 месяцев и не штырный) – то форум и не нужен. Если у вас не часто новая функциональность и суммарно её не так много, то хватит тестировщиков и особо фидбэк по багам вам не нужен
- #17 в Яндекс.Картах: http://mwp.reformal.ru/ Стоимость: бесплатно ( reformal.ru ) Участники: руководитель – руководитель+техподдержка UserVoice и GetSatisfaction платные, из доп.фич: вытаскивают данные о проблемах из постов в соц.сетях данного продукта
- #18 Польза: не устареть и не ухудшиться 3 канала связи: форма, комьюнити, бета-тестеры
- #19 Автоматические формы в Картах Суперполезных пользователей всего немного и их надо поощрять. Работа с пользователями: Техподдержка (2 человека на 3 проекта, 20 писем в день на проект (у ВКонтакте 1000), тут есть ограничение на время ответа – 3 дня, на выходе: ответы, техвопросы команде, хотелки руководителю) – Команда сервиса (4 человека ядра команды, ротируем роль еженедельно, 4-5 писем) – Руководитель сервиса (1-2 письма) +ежемесечный обзор Работа с партнёрами (для них – отдельный продукт): Менеджер по работе с партнёрами (1 человек на 2-3 сервиса) +лайки (жалобы и всё прочее) Где хранить? Как определять приоритет? Как часто проверять? Как быстро отвечать?
- #20 Более «доверительная» очередь фидбэка, можно отправлять сразу к команде сервиса. 80-90 % от сверхактивных пользователей Всегда находится в одном месте, на всех страницах сервиса и доступен из внешней сети -> быстрый фидбек из любого места сервиса, не надо искать, куда написать, переходить в почту, вообще не надо уходить со страницы (если сервис не мобильный); Писать вручную много не нужно, т.к. жучок знает сам, с какой страницы, из какого региона, каким браузером его вызвали; Основная польза именно как баг-репорты, а про функциональность мало чего полезного. После запуска беты в эксперимент мы знали про N багов (найденных тестерами и нами), через три недели после начала работы с бета-тестерами мы стали знать про 2*N багов и на тот момент это было порядка 80-90% всех багов были сверхактивные пользователи, которые заводили по 10 и больше тикетов и они писали очень подробные багрепорты, которые просто копипастились в жиру. Основная польза именно как баг-репорты, а про функциональность мало чего полезного. Пишут вкусовщину и "хочется мне потому что"на них по факту не обращаем внимание После запуска беты в эксперимент мы знали про N багов (найденных тестерами и нами), через три недели после начала работы с бета-тестерами мы стали знать про 2*N багов и на тот момент это было порядка 80-90% всех баговбыли сверхактивные пользователи, которые заводили по 10 и больше тикетов и они писали очень подробные багрепорты, которые просто копипастились в жиру. Основная польза именно как баг-репорты, а про функциональность мало чего полезного.Пишут вкусовщину и "хочется мне потому что"на них по факту не обращаем вниманиеПосле запуска беты в эксперимент мы знали про N багов (найденных тестерами и нами), через три недели после начала работы с бета-тестерами мы стали знать про 2*N багов и на тот момент это было порядка 80-90% всех баговбыли сверхактивные пользователи, которые заводили по 10 и больше тикетов и они писали очень подробные багрепорты, которые просто копипастились в жиру.
- #21 опасности: «крикуны» (пример TF2 и широкоэкранных мониторов) + думают что хотят другого (нецелевая аудитория) надо понимать до какой меры вы готовы забивать на недовольства пользователей есть не только письменный фидбэк, но и неявный как логи и действия пользователей – а он очень важен
- #22 И посещаемость и отказы и поведение пользователей Оценивать запуски, «кнопки докручивать». Сервис растёт, фич становиться всё больше и со временем он уже начинает походить на склад. Фич много, не всем пользователям они нужны, и большая часть пользователей можно спокойно не знать про какую-то полезную функциональность на сервисе. А хочется, чтобы сервис больше походил на музей.
- #23 Нужны не только ключевые показатели, но и понимание как используется запущенная функциональность. Насколько то, что мы сделали заметно, используется (по доле людей например) Насколько то, для чего мы что-то делали так и используется (мы ожидали одного поведения, оказалось ли оно таким?) Не нашли ли люди дополнительного профита, который мы не предполагали Как запуск помог окружению – если это новый функционал в сервисе, то как он помог сервису (вот тут как раз возвращаемость и пр)
- #25 Valve (Team Fortress 2) Microsoft (Word 2012) Halo3: http://www.wired.com/gaming/virtualworlds/magazine/15-09/ff_halo?currentPage=all TF2: http://www.codinghorror.com/blog/2008/02/i-repeat-do-not-listen-to-your-users.html 1,3 миллиарда сессий с момента Office 2003 352 миллиона «горячих клавиш» за 90 дней вот они эти вот самые «произошла ошибка, отправить crash - request? » (все клики и нажатия клавиатуры) http://www.microsoft.com/products/ceip/en-us/default.mspx http://blogs.msdn.com/b/jensenh/archive/2005/10/31/487247.aspx
- #26 Яндекс.Картинки – новый интерфейс Просмотры – почти вдвое Длиннее сессии с использованием фильтров Вдвое снизился процент нулевых сессий Краткое резюме: новыми вертикальными фильтрами пользуются почти в два раза больше сверхактивных пользователей и в среднем больше чем в старом интерфейсе. Фильтры на серпе и подгрузка по скроллу больше вовлекают людей во взаимодействие с интерфейсом и помогают реализировать потребность просматривать большое количество картинок.
- #29 Рассказ про нашу новую фичу на СЕРПе + о том, как складываем и как обрабатываем фидбэк после юзабилити + кейс про зарплатомер (бумажные макеты, быстрый прототип для юзабилити, внутренний релиз, пользователи, фидбэк, регионалы, новый алгоритм) + про бета-тестеров Поскольку залезть в голову мы не можем, то мы проводим юзабилити-исследования. Есть гипотезы и вопросы, которые мы не можем проверить релизом или не всегда можем их быстро понять, или просто их так много, что не понятно какую из них стоит проверять рассчётами. Поэтому делаем не только количественную проверку, но и качественную. Например, выкатывали новый элемент функциональности в Яндекс-Поиске – а люди не кликали, - это, видимо, говорило, о том, что они не видят – надобы сделать заметнее, побольше. Ан нет – оказалось, что пользователи просто не доверяли самой функциональности, принимая её за рекламу и спам.