Фреймворк FAST или как Zoe Dimov за неделю сделала проект для британского правительства
https://www.smashingmagazine.com/2018/05/fast-ux-research/
Это статья особенная, и у меня было для неё две затравки.
Во-первых, она о том, как заставить заказчиков сделать половину работы по исследованию самим. В ней описан фреймворк, который позволяет решить вечную проблему - вовлечь в исследования продуктовую команду, что позволяет делать сложные исследования в два раза быстрее, быстрее внедрять изменения по результатам, и в целом быстрее внедрять культуру исследований в компании.
А во-вторых она о том, как один исследователь попал в ад. Его (на самом деле её, Zoe Dimov) наняли в central UK government department, чтобы определить user requirements for a very complex internal system. Он никогда не работал с командой раньше, команда никогда раньше не работала с ux исследователями в принципе, все стейкхолдеры супер занятые, ничего не понятно, ааааа. И у него была неделя на проект. И он смог.
Пересказать это в нескольких пунктах сложно, выделю, как всегда, новое для меня.
1. Все говорят, что важно завлекать стейкхолдеров на само исследование. Но сидеть в тёмной наблюдательской скучно, и уже через пол часа все отвлекаются на телефон. В статье предлагаю выделить три типа активности для наблюдателей на каждую сессию - задавать доп вопросы в специальном чате, клеить стикеры с находками по ходу сессии, и суммировать находки по итогам. И назначать ответственного за каждую активность, ответственных менять.
2. В конце каждой сессии, в конце дня и в конце всего исследования проводить суммирование результатов с командой. Важно - это должен делать участник команды, которого вы назначили ответственным, исследователь только направляет и добавляет от себя. По итогам к концу исследования у вас уже есть список наблюдений и проблем, сформированных командой, и валидированный вами. На презентации вы не сообщаете ничего нового, и люди гордятся и топят за исследования, ведь они сами это выделили и нашли.
3. Решения тоже создаются командой - собираете воркшоп, команду делите на маленькие группы, каждая группа должна нагенерить решения, на выходе продакт получает много решений, согласованных в команде.
Что в итоге - ощутимую часть работы делают стейкхолдеры, они же по ходу становятся евангелистами исследований, и с большей готовностью принимают формулировки проблем и рекомендации (потому что это они их сами сформулировали). Удобно.
___
Ещё по теме:
https://t.me/uxread/17 Google Ventures про свой Research Sprint фреймворк (тоже тестирования без исследователя, тоже за неделю)
https://t.me/uxread/35 Airbnb реализуют FAST - вовлекают команду в исследования, заставляя наблюдателей писать протокол самостоятельно (модерация backroom)
Больше про способы организации исследований #Processes
https://www.smashingmagazine.com/2018/05/fast-ux-research/
Это статья особенная, и у меня было для неё две затравки.
Во-первых, она о том, как заставить заказчиков сделать половину работы по исследованию самим. В ней описан фреймворк, который позволяет решить вечную проблему - вовлечь в исследования продуктовую команду, что позволяет делать сложные исследования в два раза быстрее, быстрее внедрять изменения по результатам, и в целом быстрее внедрять культуру исследований в компании.
А во-вторых она о том, как один исследователь попал в ад. Его (на самом деле её, Zoe Dimov) наняли в central UK government department, чтобы определить user requirements for a very complex internal system. Он никогда не работал с командой раньше, команда никогда раньше не работала с ux исследователями в принципе, все стейкхолдеры супер занятые, ничего не понятно, ааааа. И у него была неделя на проект. И он смог.
Пересказать это в нескольких пунктах сложно, выделю, как всегда, новое для меня.
1. Все говорят, что важно завлекать стейкхолдеров на само исследование. Но сидеть в тёмной наблюдательской скучно, и уже через пол часа все отвлекаются на телефон. В статье предлагаю выделить три типа активности для наблюдателей на каждую сессию - задавать доп вопросы в специальном чате, клеить стикеры с находками по ходу сессии, и суммировать находки по итогам. И назначать ответственного за каждую активность, ответственных менять.
2. В конце каждой сессии, в конце дня и в конце всего исследования проводить суммирование результатов с командой. Важно - это должен делать участник команды, которого вы назначили ответственным, исследователь только направляет и добавляет от себя. По итогам к концу исследования у вас уже есть список наблюдений и проблем, сформированных командой, и валидированный вами. На презентации вы не сообщаете ничего нового, и люди гордятся и топят за исследования, ведь они сами это выделили и нашли.
3. Решения тоже создаются командой - собираете воркшоп, команду делите на маленькие группы, каждая группа должна нагенерить решения, на выходе продакт получает много решений, согласованных в команде.
Что в итоге - ощутимую часть работы делают стейкхолдеры, они же по ходу становятся евангелистами исследований, и с большей готовностью принимают формулировки проблем и рекомендации (потому что это они их сами сформулировали). Удобно.
___
Ещё по теме:
https://t.me/uxread/17 Google Ventures про свой Research Sprint фреймворк (тоже тестирования без исследователя, тоже за неделю)
https://t.me/uxread/35 Airbnb реализуют FAST - вовлекают команду в исследования, заставляя наблюдателей писать протокол самостоятельно (модерация backroom)
Больше про способы организации исследований #Processes
Smashing Magazine
Fast UX Research: An Easier Way To Engage Stakeholders And Speed Up The Research Process — Smashing Magazine
UX professionals are constantly pressured to reduce the time they need to conduct UX research. Find out which techniques and ideas can make the user research process more transparent and collaborative. In this article, Zoe Dimov will take a closer look at…
Аня Булдакова про то, какие исследования менеджер может делать сам, а для каких нужен исследователь
https://goo.gl/q21qUv
Аня Булдакова разделяет способы получения обратной связи от пользователей на две группы: "базовое общение с пользователями" - это то, что менеджер может сделать сам, быстро и без больших затрат: чтение логов поддержки, переписка со sponsor users в чате и "полноценные исследования" - юзабилити-тестирования, включенные наблюдения итд. Они уже требуют лаборатории, ресурсов и квалификации.
"Базовое общение" как стетоскоп в работе врача - не всегда даёт достаточно данных, зато всегда под рукой. "Полноценные исследования" как ретген - более дорогие и длительные, не всегда нужны, зато позволяют разобрать более сложные случаи.
Почему это разделение кажется мне полезным:
1) Если исследований нет вообще, то можно начать внедрять их с "базового общения" и с него постепенно переходить к полноценным исследованиям. Это то, с чего может начать, например, консультант по исследованиям.
2) Исследователи часто видят свою задачу в том, чтобы проводить "полноценные исследования". Но я думаю, что у них также есть задача подсаживать менеджеров на "базовое общение" и учить их смотреть в логи поддержки, общаться с ключевыми пользователями итд, если продакты почему-то этого не умеют.
3) И ещё одна из задач исследователя или менеджера исследований, на мой взгляд, делать "полноценные исследования" базовыми, то есть создавать процесс и инфраструктуру, которые позволят делать полноценные исследования быстрее, дешевле, и доступней, создавать "компактный ретген". Тут тебе и удалённые исследования, и способы быстрого рекрута, и fast фреймворк из прошлой статьи, и готовые шаблоны сценариев и отчётов, которые позволяют менеджерам самим модерировать.
___
Ещё по теме исследований без исследователя:
https://t.me/uxread/8 Как Mesosphere (b2b) настроили процесс ежеденедельных UX тестирований без выделенного исследователя
https://t.me/uxread/17 Google Ventures про свой Research Sprint фреймворк (тоже тестирования без исследователя, тоже за неделю)
https://goo.gl/q21qUv
Аня Булдакова разделяет способы получения обратной связи от пользователей на две группы: "базовое общение с пользователями" - это то, что менеджер может сделать сам, быстро и без больших затрат: чтение логов поддержки, переписка со sponsor users в чате и "полноценные исследования" - юзабилити-тестирования, включенные наблюдения итд. Они уже требуют лаборатории, ресурсов и квалификации.
"Базовое общение" как стетоскоп в работе врача - не всегда даёт достаточно данных, зато всегда под рукой. "Полноценные исследования" как ретген - более дорогие и длительные, не всегда нужны, зато позволяют разобрать более сложные случаи.
Почему это разделение кажется мне полезным:
1) Если исследований нет вообще, то можно начать внедрять их с "базового общения" и с него постепенно переходить к полноценным исследованиям. Это то, с чего может начать, например, консультант по исследованиям.
2) Исследователи часто видят свою задачу в том, чтобы проводить "полноценные исследования". Но я думаю, что у них также есть задача подсаживать менеджеров на "базовое общение" и учить их смотреть в логи поддержки, общаться с ключевыми пользователями итд, если продакты почему-то этого не умеют.
3) И ещё одна из задач исследователя или менеджера исследований, на мой взгляд, делать "полноценные исследования" базовыми, то есть создавать процесс и инфраструктуру, которые позволят делать полноценные исследования быстрее, дешевле, и доступней, создавать "компактный ретген". Тут тебе и удалённые исследования, и способы быстрого рекрута, и fast фреймворк из прошлой статьи, и готовые шаблоны сценариев и отчётов, которые позволяют менеджерам самим модерировать.
___
Ещё по теме исследований без исследователя:
https://t.me/uxread/8 Как Mesosphere (b2b) настроили процесс ежеденедельных UX тестирований без выделенного исследователя
https://t.me/uxread/17 Google Ventures про свой Research Sprint фреймворк (тоже тестирования без исследователя, тоже за неделю)
Medium
Как и почему надо общаться с пользователями
Меня уже много раз просили рассказать про общение с пользователями и работу с обратной связью. И тут я неожиданно услышала историю, которая…
Как Mozilla исследовали использование закладок в браузере, запрещая ими пользоваться
https://blog.mozilla.org/ux/2012/10/save-for-later/
Статья 12-го года, и всё равно крутая: исследователь mozilla изучал, как люди сохраняют интересные материалы на потом, и как ним возвращаются, чтобы сделать в файрфоксе удобные закладки. Редкий наглядный пример exploratory study, когда исследуют не готовый интерфейс, а поведение, чтобы придумать интерфейс под него.
Из интересного:
1) Он сделал bookmark deprivation: просил людей на протяжении дня сохранять нужную им информацию и возвращаться к ней без использования закладок, и описать свой опыт. Классная идея, попросить клиентов выполнить работу, для которой обычно используют ваш продукт, без самого продукта. Я никогда такого не делал, и теперь хочу.
2) В целом же обычное дневниковое исследование: он просил людей несколько дней отмечать, что, когда и почему хочется сохранить, и также почему и когда хочется к сохраненным материалам вернуться, потом заполировал это интервью и веб-аналитикой.
3) Ещё классно, на интервью после дневников люди делали карточную сортировку своих же дневниковых заметок - выделяли общие триггеры для сохранения и возвращения к информации, контекст и все такое. Никогда не думал, что часть обработки дневников можно переложить на респондента, очень удобно :)
4) На выходе получил карту того, как люди сохраняют нужную информацию в интернете. "Внезапно" самый популярный способ - прислать мне ссылку по почте. И ещё карту того, что люди делают с сохраненным софтом на разных устройствах. Спустя шесть лет выглядит все ещё убедительно.
___
Другие забавные исследования:
https://t.me/uxread/36 как gov.uk тестируют понятность текстов с помощью highligther testing (маркерных тестов) (хайлайтер тестинг)
https://t.me/uxread/82 Как headspace повышали вовлечённость по habit formation loop (по пути проведя опрос и дневники)
https://t.me/uxread/23 - Deliveroo про полевые исследования у людей дома
Больше по тегу #Cases
https://blog.mozilla.org/ux/2012/10/save-for-later/
Статья 12-го года, и всё равно крутая: исследователь mozilla изучал, как люди сохраняют интересные материалы на потом, и как ним возвращаются, чтобы сделать в файрфоксе удобные закладки. Редкий наглядный пример exploratory study, когда исследуют не готовый интерфейс, а поведение, чтобы придумать интерфейс под него.
Из интересного:
1) Он сделал bookmark deprivation: просил людей на протяжении дня сохранять нужную им информацию и возвращаться к ней без использования закладок, и описать свой опыт. Классная идея, попросить клиентов выполнить работу, для которой обычно используют ваш продукт, без самого продукта. Я никогда такого не делал, и теперь хочу.
2) В целом же обычное дневниковое исследование: он просил людей несколько дней отмечать, что, когда и почему хочется сохранить, и также почему и когда хочется к сохраненным материалам вернуться, потом заполировал это интервью и веб-аналитикой.
3) Ещё классно, на интервью после дневников люди делали карточную сортировку своих же дневниковых заметок - выделяли общие триггеры для сохранения и возвращения к информации, контекст и все такое. Никогда не думал, что часть обработки дневников можно переложить на респондента, очень удобно :)
4) На выходе получил карту того, как люди сохраняют нужную информацию в интернете. "Внезапно" самый популярный способ - прислать мне ссылку по почте. И ещё карту того, что люди делают с сохраненным софтом на разных устройствах. Спустя шесть лет выглядит все ещё убедительно.
___
Другие забавные исследования:
https://t.me/uxread/36 как gov.uk тестируют понятность текстов с помощью highligther testing (маркерных тестов) (хайлайтер тестинг)
https://t.me/uxread/82 Как headspace повышали вовлечённость по habit formation loop (по пути проведя опрос и дневники)
https://t.me/uxread/23 - Deliveroo про полевые исследования у людей дома
Больше по тегу #Cases
Firefox UX
Save For Later
Firefox and “save for later” All browsers support two functions: searching and revisiting. My research questions whether constructs like bookmarks really are the right model to support revisiting. I worked ...
Майкл Марголис из Google Ventures написал статьи по исследованиям для начинающих
https://www.stitcher.com/podcast/inside-intercom-podcast/e/51156336?autoplay=true
Послушал интеркомовский подкаст с Michael Margolis, исследователем из Google Ventures, я выкладывал его фреймворк для планирования исследования "start at the end" выше, а тут словил ещё несколько деталей.
1) В GV около трёхста компаний, и он - единственный постоянный исследователь там. Поэтому он знает, как работать очень, очень, очень быстро.
2) Половину времени Майкл (Майкл? Мишель?) делает исследования сам - около 50 проектов в год (неделю на проект в рамках research sprint, который он тоже хорошо описывает), половину учит людей проводить самостоятельно. Каждую неделю есть office hours, когда ребята могут пройти к нему и вместе подумать дизайн исследования. Часть про обучение не менее важна.
3) Одна из фишек, спрашивать не "когда вам нужно это исследование" (всем нужно было ещё вчера), а "когда последний день, когда я могу дать результаты, так, чтобы они ещё были полезны". Кроме более реалистичной оценки сроков это заставляет команду заранее думать о том, зачем они делают исследование, и как будут использовать результаты.
4) Он собрал маленькую библиотеку статей про lean ux research http://www.gv.com/library/, подчеркивает, что это не для взрослых исследователей, а для начинающих стартаперов, но статью о "Rapid user research: how to survey 400 users and interview 10 in three days" я все равно прочитаю и перескажу, если она ок.
5) А, ещё он много рекрутит через крейглист. Стоит ли рекрутить через авито/юду?
От себя добавлю, что всё чаще слышу запрос от дизайнеров "научите нас тестировать, дайте нам шаблоны артефактов и помогите все придумать, проведём мы сами" , поэтому эти его статьи весьма в кассу.
___
Ещё про исследования для начинающих:
https://t.me/uxread/29 - Аня Булдакова про то, какие исследования менеджер может делать сам, а для каких нужен исследователь
https://t.me/uxread/17 Google Ventures про свой Research Sprint фреймворк (тоже тестирования без исследователя, тоже за неделю)
https://bit.ly/3iUF9vo Эмилия Городовых из Контура про то, как провести исследование самому
#Processes
https://www.stitcher.com/podcast/inside-intercom-podcast/e/51156336?autoplay=true
Послушал интеркомовский подкаст с Michael Margolis, исследователем из Google Ventures, я выкладывал его фреймворк для планирования исследования "start at the end" выше, а тут словил ещё несколько деталей.
1) В GV около трёхста компаний, и он - единственный постоянный исследователь там. Поэтому он знает, как работать очень, очень, очень быстро.
2) Половину времени Майкл (Майкл? Мишель?) делает исследования сам - около 50 проектов в год (неделю на проект в рамках research sprint, который он тоже хорошо описывает), половину учит людей проводить самостоятельно. Каждую неделю есть office hours, когда ребята могут пройти к нему и вместе подумать дизайн исследования. Часть про обучение не менее важна.
3) Одна из фишек, спрашивать не "когда вам нужно это исследование" (всем нужно было ещё вчера), а "когда последний день, когда я могу дать результаты, так, чтобы они ещё были полезны". Кроме более реалистичной оценки сроков это заставляет команду заранее думать о том, зачем они делают исследование, и как будут использовать результаты.
4) Он собрал маленькую библиотеку статей про lean ux research http://www.gv.com/library/, подчеркивает, что это не для взрослых исследователей, а для начинающих стартаперов, но статью о "Rapid user research: how to survey 400 users and interview 10 in three days" я все равно прочитаю и перескажу, если она ок.
5) А, ещё он много рекрутит через крейглист. Стоит ли рекрутить через авито/юду?
От себя добавлю, что всё чаще слышу запрос от дизайнеров "научите нас тестировать, дайте нам шаблоны артефактов и помогите все придумать, проведём мы сами" , поэтому эти его статьи весьма в кассу.
___
Ещё про исследования для начинающих:
https://t.me/uxread/29 - Аня Булдакова про то, какие исследования менеджер может делать сам, а для каких нужен исследователь
https://t.me/uxread/17 Google Ventures про свой Research Sprint фреймворк (тоже тестирования без исследователя, тоже за неделю)
https://bit.ly/3iUF9vo Эмилия Городовых из Контура про то, как провести исследование самому
#Processes
Airbnb вовлекают команду в исследования, заставляя наблюдателей писать протокол самостоятельно
https://airbnb.design/moderating-the-back-room/
Airbnb пишут про модерацию back room. Так они называют комнату, из которой наблюдатели следят за исследованием, давайте назовём её обсерваторией (это ведь лучше, чем наблюдательская). Что говорят в Airbnb:
- Не услышанное исследование не считается сделанным (Research that doesn’t get heard, didn’t happen), поэтому от того, как заказчики наблюдают за исследованием зависит так же много, как от исследовательской части в самой лабе.
- Это значит, что поведение наблюдателей в back room/обсерватории тоже нужно модерировать, и для этого тоже нужен сценарий.
- Сценарий, который предлагают airbnb прост, изящен и похож на кусочек FAST подхода (https://t.me/uxread/27): вы вместе с заказчиками перед началом исследования выписываете ключевые вопросы/гипотезы исследования на реальную или виртуальную доску. В виде таблички: строки - вопросы, столбцы - респонденты. Во время исследования наблюдатели выписывают замечания по каждой из гипотез на стикер и приклеивают в табличку, т.е. по сути сами заполняют качественный протокол.
- Как и в FAST в конце каждой сессии и каждого дня вы выделяете минут десять и обсуждаете/добавляете наблюдения.
- К концу исследования у вас есть качественный протокол, сделанный вместе с заказчиками, который вы уже несколько раз обсудили.
___
Ещё про вовлечение заказчиков и респондентов:
https://t.me/uxread/27 это по сути реализация FAST фреймворка от Zoe Dimov
https://t.me/uxread/17 у Google Ventures есть свой Research Sprint - тестирования за неделю с сильным вовлечением заказчиков
https://t.me/uxread/30 Mozilla частично отдали обработку результатов самим респондентам
#Processes
https://airbnb.design/moderating-the-back-room/
Airbnb пишут про модерацию back room. Так они называют комнату, из которой наблюдатели следят за исследованием, давайте назовём её обсерваторией (это ведь лучше, чем наблюдательская). Что говорят в Airbnb:
- Не услышанное исследование не считается сделанным (Research that doesn’t get heard, didn’t happen), поэтому от того, как заказчики наблюдают за исследованием зависит так же много, как от исследовательской части в самой лабе.
- Это значит, что поведение наблюдателей в back room/обсерватории тоже нужно модерировать, и для этого тоже нужен сценарий.
- Сценарий, который предлагают airbnb прост, изящен и похож на кусочек FAST подхода (https://t.me/uxread/27): вы вместе с заказчиками перед началом исследования выписываете ключевые вопросы/гипотезы исследования на реальную или виртуальную доску. В виде таблички: строки - вопросы, столбцы - респонденты. Во время исследования наблюдатели выписывают замечания по каждой из гипотез на стикер и приклеивают в табличку, т.е. по сути сами заполняют качественный протокол.
- Как и в FAST в конце каждой сессии и каждого дня вы выделяете минут десять и обсуждаете/добавляете наблюдения.
- К концу исследования у вас есть качественный протокол, сделанный вместе с заказчиками, который вы уже несколько раз обсудили.
___
Ещё про вовлечение заказчиков и респондентов:
https://t.me/uxread/27 это по сути реализация FAST фреймворка от Zoe Dimov
https://t.me/uxread/17 у Google Ventures есть свой Research Sprint - тестирования за неделю с сильным вовлечением заказчиков
https://t.me/uxread/30 Mozilla частично отдали обработку результатов самим респондентам
#Processes
👍1
Как gov.uk тестируют понятность текстов с помощью highlighter testing (маркерных тестов)
Ребята из gov.uk предложили интересный способ тестирования контента (предложили ещё 4 года назад, но я то не знал): https://userresearch.blog.gov.uk/2014/09/02/a-simple-technique-for-evaluating-content/
Для меня исследование текстовых интерфейсов - большая боль, я часто сталкивался с запросами на тестирование лендингов, смс, текстов договора, интерфейсных подсказок и всего такого, и всегда казалось, что юзабилити-тестирования дают маловато фидбека и не помогают редактору написать хороший текст (и ощущаются как-то нелепо).
Этот способ называется Highlighter testing, и он лучше:
- Кусок текста распечатывают на бумаге (во всех описаниях метода подчёркивается, что надо печатать, а не с экрана, но думаю, это не так важно)
- Просят респондента разными цветами разметить слова и фразы, которые вызывают разную эмоциональную реакцию. В данном кейсе оценивали доверие сервису, поэтому просили зеленым маркером пометить слова, которые повышают доверие, и красным - те, что снижают. На деле признаки могут быть другими, можно добавить маркер для непонятных слов, для раздражающих слов, суть одна.
- Прогоняют несколько респондентов и строят общую цветовую карту, которая позволяет лучше понять язык, который понятен и удобен для клиентов.
- В комментариях есть лайфхак - прогнать такое исследование сначала на заказчиках, а потом на клиентах. Во-первых само задание заставляет заказчиков думать о тексте по-другому, а во-вторых цветовые карты заказчиков и клиентов интересно сравнивать, так как наглядно виден разрыв между ними.
___
Другие забавные исследования:
https://t.me/uxread/47 Google в 2011 поменяли поисковую выдачу на основе experience sampling (и это опять был Tomer Sharon)
https://t.me/uxread/23 - Deliveroo про полевые исследования у людей дома
https://t.me/uxread/89 Как проводить Кано
https://t.me/uxread/41 как парные юзабилити-тестирования (с двумя респондентами одновременно) позволяют глубже понять ментальную модель пользователя
Больше кейсов #Cases
Больше методов #Methods
Ребята из gov.uk предложили интересный способ тестирования контента (предложили ещё 4 года назад, но я то не знал): https://userresearch.blog.gov.uk/2014/09/02/a-simple-technique-for-evaluating-content/
Для меня исследование текстовых интерфейсов - большая боль, я часто сталкивался с запросами на тестирование лендингов, смс, текстов договора, интерфейсных подсказок и всего такого, и всегда казалось, что юзабилити-тестирования дают маловато фидбека и не помогают редактору написать хороший текст (и ощущаются как-то нелепо).
Этот способ называется Highlighter testing, и он лучше:
- Кусок текста распечатывают на бумаге (во всех описаниях метода подчёркивается, что надо печатать, а не с экрана, но думаю, это не так важно)
- Просят респондента разными цветами разметить слова и фразы, которые вызывают разную эмоциональную реакцию. В данном кейсе оценивали доверие сервису, поэтому просили зеленым маркером пометить слова, которые повышают доверие, и красным - те, что снижают. На деле признаки могут быть другими, можно добавить маркер для непонятных слов, для раздражающих слов, суть одна.
- Прогоняют несколько респондентов и строят общую цветовую карту, которая позволяет лучше понять язык, который понятен и удобен для клиентов.
- В комментариях есть лайфхак - прогнать такое исследование сначала на заказчиках, а потом на клиентах. Во-первых само задание заставляет заказчиков думать о тексте по-другому, а во-вторых цветовые карты заказчиков и клиентов интересно сравнивать, так как наглядно виден разрыв между ними.
___
Другие забавные исследования:
https://t.me/uxread/47 Google в 2011 поменяли поисковую выдачу на основе experience sampling (и это опять был Tomer Sharon)
https://t.me/uxread/23 - Deliveroo про полевые исследования у людей дома
https://t.me/uxread/89 Как проводить Кано
https://t.me/uxread/41 как парные юзабилити-тестирования (с двумя респондентами одновременно) позволяют глубже понять ментальную модель пользователя
Больше кейсов #Cases
Больше методов #Methods
userresearch.blog.gov.uk
A simple technique for evaluating content
I've been working with our content designers to refine content that explains the Identity Assurance service. We wanted a simple way to understand if our content inspired confidence in users or not. A simple technique and how it works At …
Светлана Ратнер из Контура про рекрут b2b пользователей по конкретным темам через почту для обратной связи
Светлана Ратнер из Контура рассказала о том, как находит замотивированных и релевантных респондентов для исследования.
(Отдельное спасибо Руслану Крючкову за организацию митапа и и запись с него).
- у Контура есть "юзер эхо" - почта, куда каждый клиент может написать свои впечатления или вопросы.
- когда нужно больше узнать о конкретном сценарии или исследовать прототип нового решения, Светлана находит релевантные отзывы в почте юзер эхо (как я понял, просто поиском по ключевым словам), и связывается с теми, кто их оставил (в форме обратной связи есть контакты).
- для клиента это выглядит не как исследование, а как сеанс персональной техподдержки - ему помогают решить проблему или рассказывают лучший способ решить задачу, а заодно расспрашивают о работе с продуктом и обсуждают с ним возможные варианты нового решения (тестируют прототип).
- такое исследование может дать более полные результаты, чем обычное "представьте, что вы оказались в такой ситуации...", респондентам важна проблема и они больше вовлечены в исследование, хотя результаты могут быть скошенными (в форму обратной связи пишут не все).
Я это к чему, большинство компаний, особенно больших, завалено обратной связью. Отзывы от продаж, тикеты поддержки, регулярные опросы клиентов, комментарий того парня на реддите, отзывы в Фейсбуке и ВКонтакте, отрывки личных бесед продакта с клиентами, всё это раскидано по разным табличкам, презентациям и письмам, и до дизайнера, например, доходит не всегда. Как это нормально исправить, насколько я знаю, никто пока не придумал, но можно начать хотя бы с рекрута - следующий раз, когда будете тестировать сценарий, попробуйте собрать у SMM, саппорта и продаж контакты людей, которые оставляли отзывы на релевантную тему (иногда отзывы можно найти полнотекстовым поиском по ключевым словам в их базе).
https://youtu.be/Mj6dG_cRJXY
___
Ещё про рекрут:
https://t.me/uxread/4 Как рекрутить респондентов через фейсбук
https://t.me/uxread/15 - IBM про рекрут sponsor users для кодизайна в b2b
https://t.me/uxread/46 Томер Шарон про автоматизированный рекрут в WeWork
https://t.me/uxread/60 Как Athenahealth (b2b, it системы для больниц) перекроили весь процесс дизайна
https://t.me/uxread/39 - процессы исследований в Atlassian
Больше про рекрут по тегу #Recruitment
Больше про b2b исследования по тегу #b2bResearch
Светлана Ратнер из Контура рассказала о том, как находит замотивированных и релевантных респондентов для исследования.
(Отдельное спасибо Руслану Крючкову за организацию митапа и и запись с него).
- у Контура есть "юзер эхо" - почта, куда каждый клиент может написать свои впечатления или вопросы.
- когда нужно больше узнать о конкретном сценарии или исследовать прототип нового решения, Светлана находит релевантные отзывы в почте юзер эхо (как я понял, просто поиском по ключевым словам), и связывается с теми, кто их оставил (в форме обратной связи есть контакты).
- для клиента это выглядит не как исследование, а как сеанс персональной техподдержки - ему помогают решить проблему или рассказывают лучший способ решить задачу, а заодно расспрашивают о работе с продуктом и обсуждают с ним возможные варианты нового решения (тестируют прототип).
- такое исследование может дать более полные результаты, чем обычное "представьте, что вы оказались в такой ситуации...", респондентам важна проблема и они больше вовлечены в исследование, хотя результаты могут быть скошенными (в форму обратной связи пишут не все).
Я это к чему, большинство компаний, особенно больших, завалено обратной связью. Отзывы от продаж, тикеты поддержки, регулярные опросы клиентов, комментарий того парня на реддите, отзывы в Фейсбуке и ВКонтакте, отрывки личных бесед продакта с клиентами, всё это раскидано по разным табличкам, презентациям и письмам, и до дизайнера, например, доходит не всегда. Как это нормально исправить, насколько я знаю, никто пока не придумал, но можно начать хотя бы с рекрута - следующий раз, когда будете тестировать сценарий, попробуйте собрать у SMM, саппорта и продаж контакты людей, которые оставляли отзывы на релевантную тему (иногда отзывы можно найти полнотекстовым поиском по ключевым словам в их базе).
https://youtu.be/Mj6dG_cRJXY
___
Ещё про рекрут:
https://t.me/uxread/4 Как рекрутить респондентов через фейсбук
https://t.me/uxread/15 - IBM про рекрут sponsor users для кодизайна в b2b
https://t.me/uxread/46 Томер Шарон про автоматизированный рекрут в WeWork
https://t.me/uxread/60 Как Athenahealth (b2b, it системы для больниц) перекроили весь процесс дизайна
https://t.me/uxread/39 - процессы исследований в Atlassian
Больше про рекрут по тегу #Recruitment
Больше про b2b исследования по тегу #b2bResearch
Mailchimp сделали базу инсайтов о пользователях в Evernote в 2013-м году
На самом деле конечно есть системы для централизованного сбора обратной связи из кучи каналов, например https://nomnominsights.com, но одно дело инструмент, а другое - налаженные процессы, которые позволяют всё это поддерживать в нормальном состоянии, не превратить систему тегов в кашу, и не забывать использовать при работе над продуктом.
Mailchimp сделали базу инсайтов о пользователях в Evernote в 2013-м году когда-то (в 13-м году) писали, что у них такое есть, база фидбека хранится в Evernote (не шучу, так и пишут), и все ей пользуются, пополняют и купаются в чистом полезном юзер фидбеке, но что-то я не знаю.
___
Ещё про базы инсайтов
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/44 Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
https://t.me/uxread/127 как мы в Acronis вели базу 2 года, и почему разочаровались
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#Bases
На самом деле конечно есть системы для централизованного сбора обратной связи из кучи каналов, например https://nomnominsights.com, но одно дело инструмент, а другое - налаженные процессы, которые позволяют всё это поддерживать в нормальном состоянии, не превратить систему тегов в кашу, и не забывать использовать при работе над продуктом.
Mailchimp сделали базу инсайтов о пользователях в Evernote в 2013-м году когда-то (в 13-м году) писали, что у них такое есть, база фидбека хранится в Evernote (не шучу, так и пишут), и все ей пользуются, пополняют и купаются в чистом полезном юзер фидбеке, но что-то я не знаю.
___
Ещё про базы инсайтов
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/44 Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
https://t.me/uxread/127 как мы в Acronis вели базу 2 года, и почему разочаровались
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#Bases
Процессы исследований в Atlassian
Во-первых статья о том, как проводят UX-исследования в Atlassian (ребята, которые делают Jira и Confluence).
Всё как у людей:
- тестируют каждую фичу на прототипах
- до прототипах валидируют на интервью: "Prototyping actually comes quite late in the process for us, once we’ve validated a solution, and we’ve got a clear idea of what we want to do".
- делают быстрые итеративные исследования
- организуют воркшопчики с клиентами (стикеры, вайтборды, кодизайн, вот это всё).
Я всё надеюсь, что ссылка на джиру примирит с исследованиями самых лютых скептиков (тем более, что ощутимая часть продактов вышли из разработки и любят джиру нежной любовью), но пока не проверял.
https://www.justinmind.com/blog/how-atlassian-took-over-enterprise-software-qa-with-senior-ux-researcher/
____
Про процессы в других компаниях:
Mesosphere https://t.me/uxread/8,
LinkedIn https://t.me/uxread/121,
Spotify https://t.me/uxread/104,
Facebook https://t.me/uxread/71,
Ableton https://t.me/uxread/123,
Lyft https://t.me/uxread/11
IBM https://t.me/uxread/13 (чуть невнятно)
Больше про исследования в компаниях #Companies
Отдельно про b2b #b2bResearch
Во-первых статья о том, как проводят UX-исследования в Atlassian (ребята, которые делают Jira и Confluence).
Всё как у людей:
- тестируют каждую фичу на прототипах
- до прототипах валидируют на интервью: "Prototyping actually comes quite late in the process for us, once we’ve validated a solution, and we’ve got a clear idea of what we want to do".
- делают быстрые итеративные исследования
- организуют воркшопчики с клиентами (стикеры, вайтборды, кодизайн, вот это всё).
Я всё надеюсь, что ссылка на джиру примирит с исследованиями самых лютых скептиков (тем более, что ощутимая часть продактов вышли из разработки и любят джиру нежной любовью), но пока не проверял.
https://www.justinmind.com/blog/how-atlassian-took-over-enterprise-software-qa-with-senior-ux-researcher/
____
Про процессы в других компаниях:
Mesosphere https://t.me/uxread/8,
LinkedIn https://t.me/uxread/121,
Spotify https://t.me/uxread/104,
Facebook https://t.me/uxread/71,
Ableton https://t.me/uxread/123,
Lyft https://t.me/uxread/11
IBM https://t.me/uxread/13 (чуть невнятно)
Больше про исследования в компаниях #Companies
Отдельно про b2b #b2bResearch
Justinmind |
How Atlassian took over enterprise software: Q&A
Atlassian’s enterprise applications have changed the way teams work. Senior UX Researcher Georgie Bottomley tells us how If you work in tech today, it’s a fair bet...
Uber Eats сняли 360 видео про работу курьера чтобы вовлечь команду
Во-вторых, статья от исследователя из Uber Eats под громким названием "Using virtual reality to build empathy in distributed organizations".
Ron Goldin исследовал работу курьера Uber Eats в Токио (он сам сел на велосипед и развозил еду). Чтобы передать команде гнёт нависающих небоскрёбов и бесконечных эскалаторов, он записал своё путешествие на камеру 360, выложил в ютуб (ютуб сам склеивает видео 360) и разослал всем участникам команды гугл по картборду.
Потому что фотки и видеонарезки это хорошо, но ничего не передаст боль респондента и контекст деятельности лучше, чем видео 360.
- вот само видео (там две минуты всего https://www.youtube.com/watch?v=z86xTrMHU3c&feature=youtu.be)
- Вот камерка за 200$ для съёмки видео 360
https://www.amazon.com/Insta360-Nano-Degree-Seamless-Stitching/dp/B01FY8CHIA (статья годичной давности, сейчас мб и подешевле есть).
- А вот сама статья https://medium.com/uber-design/using-virtual-reality-to-build-empathy-in-distributed-organizations-8cb70b138c6c
____
Ещё про вовлечение команды:
https://t.me/uxread/35 Airbnb вовлекают команду в исследования, заставляя наблюдателей писать протокол самостоятельно (модерация backroom)
https://t.me/uxread/27 - Фреймворк FAST тоже предполагает вовлечение команды
https://t.me/uxread/71 - Facebook рассказывают про другие способы презентации результатов
Про другие способы презентации результатов #Presentation
Во-вторых, статья от исследователя из Uber Eats под громким названием "Using virtual reality to build empathy in distributed organizations".
Ron Goldin исследовал работу курьера Uber Eats в Токио (он сам сел на велосипед и развозил еду). Чтобы передать команде гнёт нависающих небоскрёбов и бесконечных эскалаторов, он записал своё путешествие на камеру 360, выложил в ютуб (ютуб сам склеивает видео 360) и разослал всем участникам команды гугл по картборду.
Потому что фотки и видеонарезки это хорошо, но ничего не передаст боль респондента и контекст деятельности лучше, чем видео 360.
- вот само видео (там две минуты всего https://www.youtube.com/watch?v=z86xTrMHU3c&feature=youtu.be)
- Вот камерка за 200$ для съёмки видео 360
https://www.amazon.com/Insta360-Nano-Degree-Seamless-Stitching/dp/B01FY8CHIA (статья годичной давности, сейчас мб и подешевле есть).
- А вот сама статья https://medium.com/uber-design/using-virtual-reality-to-build-empathy-in-distributed-organizations-8cb70b138c6c
____
Ещё про вовлечение команды:
https://t.me/uxread/35 Airbnb вовлекают команду в исследования, заставляя наблюдателей писать протокол самостоятельно (модерация backroom)
https://t.me/uxread/27 - Фреймворк FAST тоже предполагает вовлечение команды
https://t.me/uxread/71 - Facebook рассказывают про другие способы презентации результатов
Про другие способы презентации результатов #Presentation
Парные юзабилити-тестирования - два респондента обсуждают полученный опыт, выкладывая исследователю ментальную модель
Hossein Raspberry из UX Matters рассказал про парные юзабилити-тестирования.
- Он собирал пары из новичков и опытных пользователей, так, чтобы они проходили сценарий вместе.
- Пока они проходили сценарий, новичок задавал глупые вопросы, а опытный объяснял ему, как всё устроено. Это помогло вытащить ментальные модели обоих гораздо лучше, чем классический think aloud.
- Это позволило во-первых вытащить больше юзабилити-проблем при том же количестве респондентов (несмотря на сдвоенность), а во-вторых гораздо лучше понять причины проблем неопытных пользователей (например то, что они не понимают какие-то базовые концепции).
- Есть проблемы с доминированием опытных пользователей, но реже, чем можно было подумать.
Со своей стороны думаю, что это здорово подходит для профессиональных интерфейсов, где разница между новыми и старыми пользователями велика - CRM там, весь внутренний софт для операторов. Уже представляю, как в своём Акронисе сцеплю матёрых сисадминов с юными.
https://www.uxmatters.com/mt/archives/2018/09/case-study-adapting-a-software-development-technique-for-usability-testing.php
____
Про другие забавные методы
https://t.me/uxread/131 про разные стили модерации интервью - NNgroup и probing technics
https://t.me/uxread/89 Как проводить Кано
Больше методов #Methods
Hossein Raspberry из UX Matters рассказал про парные юзабилити-тестирования.
- Он собирал пары из новичков и опытных пользователей, так, чтобы они проходили сценарий вместе.
- Пока они проходили сценарий, новичок задавал глупые вопросы, а опытный объяснял ему, как всё устроено. Это помогло вытащить ментальные модели обоих гораздо лучше, чем классический think aloud.
- Это позволило во-первых вытащить больше юзабилити-проблем при том же количестве респондентов (несмотря на сдвоенность), а во-вторых гораздо лучше понять причины проблем неопытных пользователей (например то, что они не понимают какие-то базовые концепции).
- Есть проблемы с доминированием опытных пользователей, но реже, чем можно было подумать.
Со своей стороны думаю, что это здорово подходит для профессиональных интерфейсов, где разница между новыми и старыми пользователями велика - CRM там, весь внутренний софт для операторов. Уже представляю, как в своём Акронисе сцеплю матёрых сисадминов с юными.
https://www.uxmatters.com/mt/archives/2018/09/case-study-adapting-a-software-development-technique-for-usability-testing.php
____
Про другие забавные методы
https://t.me/uxread/131 про разные стили модерации интервью - NNgroup и probing technics
https://t.me/uxread/89 Как проводить Кано
Больше методов #Methods
Uxmatters
Case Study: Adapting a Software-Development Technique for Usability Testing :: UXmatters
Web magazine about user experience matters, providing insights and inspiration for the user experience community
Смотрите, как здорово, Mark Hurst 10 лет назад придумал метрику, которая позволяет оценить, насколько команда и каждый из её участников customer-centric. Она проста, прозрачна, и её можно всем запихнуть в квартальные цели.
Он назвал её tesla (Маск ни при чём): time elapsed since labs attended, т.е. "сколько дней прошло с тех пор, как человек был на исследовании/говорил с пользователями".
Забавно, что она отражает не просто количество исследований, а именно вовлечённость заказчиков: если вы делали исследование две недели назад, и дизайнер был на нём, tesla=10.
Если делаете каждый день, но дизайнер заходил только две недели назад, tesla=10.
А у кого тесла ниже, тот самый эмпатичный молодец.
http://goodexperience.com/blog/2008/11/one-number-to-grade-a.php
Он назвал её tesla (Маск ни при чём): time elapsed since labs attended, т.е. "сколько дней прошло с тех пор, как человек был на исследовании/говорил с пользователями".
Забавно, что она отражает не просто количество исследований, а именно вовлечённость заказчиков: если вы делали исследование две недели назад, и дизайнер был на нём, tesla=10.
Если делаете каждый день, но дизайнер заходил только две недели назад, tesla=10.
А у кого тесла ниже, тот самый эмпатичный молодец.
http://goodexperience.com/blog/2008/11/one-number-to-grade-a.php
Простите, не могу удержаться от бессмысленной метафоры, у Сьюзен Зонтаг (американская писательница, философ и критик) есть книга "Regarding the Pain of Others" (смотрим на чужие страдания) и поразительно, что точно также мог бы называться учебник по модерации юзабилити-тестирований.
Развивая тему - книга Зонтаг написана о том, как менялась военная фотография от гражданской войны в США до конца 20-го века, как менялось изображение страданий, и как это повлияло на восприятие войны мирным населением.
Это напоминает статьи о том, как доносить до продуктовой команды проблемы пользователей - отчёты по результатам исследования можно сравнить с газетными сводками (которые влияют не слишком сильно), видео с исследований, понятно, с документальными фильмами, а воркшопы по дизайн мышлению и sponsor users с выступлениями беженцев на сессиях ООН.
И, конечно, нам есть чему поучиться друг у друга. У журналистов есть постановочные фотографии (на следующее тестирование с вице-президентом обязательно позову специально подготовленного страдающего респондента), а у нас - вовлечение заказчиков в сессию исследования (не знаю, с чем сравнить. Стримы с места боевых действий?)
Развивая тему - книга Зонтаг написана о том, как менялась военная фотография от гражданской войны в США до конца 20-го века, как менялось изображение страданий, и как это повлияло на восприятие войны мирным населением.
Это напоминает статьи о том, как доносить до продуктовой команды проблемы пользователей - отчёты по результатам исследования можно сравнить с газетными сводками (которые влияют не слишком сильно), видео с исследований, понятно, с документальными фильмами, а воркшопы по дизайн мышлению и sponsor users с выступлениями беженцев на сессиях ООН.
И, конечно, нам есть чему поучиться друг у друга. У журналистов есть постановочные фотографии (на следующее тестирование с вице-президентом обязательно позову специально подготовленного страдающего респондента), а у нас - вовлечение заказчиков в сессию исследования (не знаю, с чем сравнить. Стримы с места боевых действий?)
Как Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся (а ещё про демократизацию исследований)
WeWork рассказывают про свой подход к исследованиям Atomic Research: они отказались от отчётов по исследованиям (совсем) и заменили их живой, постоянно пополняемой базой атомарных инсайтов. Тут идея такой глобальной базы описана лучше, чем где-либо ещё.
Обычно я шарю тут статьи десятилетней давности, но Atomic Research весьма свеж - 2018 год.
Сейчас расскажу:
1) Концепция отчётов и глобальных исследований устаревает - отчёты оседают мертвым грузом, их не читает никто, кроме исследователей, найти нужную информацию в старом отчёте сложно, результатов нет под рукой.
2) Чтобы изменить ситуацию, WeWork предлагают хранить research knowledge не в виде исследований, а в виде atomic unit of a research insight, который они называют nugget. Nugget это наблюдение (что мы узнали) + свидетельство (кусочек видео, аудио, скринкаст на 30 секунд) + система поиска (теги, которые позволяют найти наггетс по сценарию, контексту, паттерну итд). Все эти кусочки хранятся в единой базе.
3) По результатам исследований база пополняется, сейчас таких кусочков у них около 4000, туда попадают не только результаты юзабилити-тестирований, но и результаты маркетинговых опросов, a/b тестов.
4) Если отчёты оседают мёртвым грузом, то база живёт - любой участник команды может обратиться к ней и найти нужную информацию, в том числе из старых исследований.
5) Самое чудесное - можно составлять "плейлист" из таких кусочков и шарить с другими участниками. Плейлист позволяет смотреть данные в любом разрезе - если вы делаете чекаут, вы делаете плейлист из всех кусочков с исследований чекаута и шарите на всю команду, возможность собирать такие плейлисты юзер фидбека сильно влияет на качество дизайна.
6) Цель, которую они ставят перед собой - сделать базу источником эмпатии по нужной теме в том числе для топ-менеджмента и CEO, т.е. в идеальном сценарии он может не просто просмотреть отчёт по теме, но и увидеть живые видео и отрывки интервью, связанные с проблемой, которая для него важна в данный момент.
Вот базовая статья по теме https://medium.com/@tsharon/democratizing-ux-670b95fbc07f
Вот некоторые пояснения:https://medium.com/@tsharon/the-three-most-popular-questions-about-atomic-research-56a5414d3d17
Ещё немного подробостей и некоторые рекомендации по системе тегов https://medium.com/@tsharon/foundations-of-atomic-research-a937d5da5fbb
___
Ещё про базы инсайтов и распространение результатов исследований:
https://t.me/uxread/38 Mailchimp сделали базу инсайтов о пользователях в Evernote в 2013-м году
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/127 как мы в Acronis вели базу 2 года, и почему разочаровались
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#Bases
WeWork рассказывают про свой подход к исследованиям Atomic Research: они отказались от отчётов по исследованиям (совсем) и заменили их живой, постоянно пополняемой базой атомарных инсайтов. Тут идея такой глобальной базы описана лучше, чем где-либо ещё.
Обычно я шарю тут статьи десятилетней давности, но Atomic Research весьма свеж - 2018 год.
Сейчас расскажу:
1) Концепция отчётов и глобальных исследований устаревает - отчёты оседают мертвым грузом, их не читает никто, кроме исследователей, найти нужную информацию в старом отчёте сложно, результатов нет под рукой.
2) Чтобы изменить ситуацию, WeWork предлагают хранить research knowledge не в виде исследований, а в виде atomic unit of a research insight, который они называют nugget. Nugget это наблюдение (что мы узнали) + свидетельство (кусочек видео, аудио, скринкаст на 30 секунд) + система поиска (теги, которые позволяют найти наггетс по сценарию, контексту, паттерну итд). Все эти кусочки хранятся в единой базе.
3) По результатам исследований база пополняется, сейчас таких кусочков у них около 4000, туда попадают не только результаты юзабилити-тестирований, но и результаты маркетинговых опросов, a/b тестов.
4) Если отчёты оседают мёртвым грузом, то база живёт - любой участник команды может обратиться к ней и найти нужную информацию, в том числе из старых исследований.
5) Самое чудесное - можно составлять "плейлист" из таких кусочков и шарить с другими участниками. Плейлист позволяет смотреть данные в любом разрезе - если вы делаете чекаут, вы делаете плейлист из всех кусочков с исследований чекаута и шарите на всю команду, возможность собирать такие плейлисты юзер фидбека сильно влияет на качество дизайна.
6) Цель, которую они ставят перед собой - сделать базу источником эмпатии по нужной теме в том числе для топ-менеджмента и CEO, т.е. в идеальном сценарии он может не просто просмотреть отчёт по теме, но и увидеть живые видео и отрывки интервью, связанные с проблемой, которая для него важна в данный момент.
Вот базовая статья по теме https://medium.com/@tsharon/democratizing-ux-670b95fbc07f
Вот некоторые пояснения:https://medium.com/@tsharon/the-three-most-popular-questions-about-atomic-research-56a5414d3d17
Ещё немного подробостей и некоторые рекомендации по системе тегов https://medium.com/@tsharon/foundations-of-atomic-research-a937d5da5fbb
___
Ещё про базы инсайтов и распространение результатов исследований:
https://t.me/uxread/38 Mailchimp сделали базу инсайтов о пользователях в Evernote в 2013-м году
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/127 как мы в Acronis вели базу 2 года, и почему разочаровались
https://t.me/uxread/118 что класть в базу инсайтов, а что - нет
https://t.me/uxread/148 полнотекстовые транскрипты интервью через связку zoom+otter как замена базе инсайтов
#Bases
Medium
Democratizing UX
I’m excited to share Polaris, a new tool WeWork UX has launched to help WeWork become a better listening organization.
👍1
А, ну и важно, это не абстрактная концепция. База есть, сделана в airtable, вот шаблон, можно посмотреть: https://airtable.com/universe/expShuhNMi0Oc0xpb/polaris-ux-nuggets
Airtable
Polaris UX Nuggets - Airtable Universe
Tomer Sharon, the head of User Experience at WeWork and author of the books Validating Product Ideas and It's Our Research, considers Polaris "one...
Tomer Sharon угорел по nocode и автоматизировал все процессы исследований, какие можно (рекрут, scheduling встреч, составление отчётов)
https://blog.airtable.com/how-to-build-a-ux-research-system-that-runs-on-autopilot/
Ещё одна статья от WeWork "how to build a UX research system that runs on autopilot", на самом деле про то, как автоматизировать максимум рутины, если у вас маленькая команда исследователей в большой компании и вас разрывает от проектов.
1) Автоматизация рекрута: у ребят фоном работает НПС-опрос на клиентов. При низкой оценке клиенту автоматом отправляется второе письмо с просьбой поучаствовать в интервью (результаты НПС записывают в airtable, второе письмо шлют через https://customer.io/, всё без разработки на существующих интеграциях).
2) Автоматизация расписания: во втором письме (с просьбой участвовать) приходит ссылка на calendly со слотами для интервью, так что пользователи автоматом записываются в удобное для них и исследователей время. После выбора времени пользователю автоматически высылается письмо с приглашением и ссылкой на встречу в gotomeeting, а его контакты добавляются в airtable (смесь экселя и базы данных) в отдельную табличку (всё тоже настроено без помощи разработчиков, через интеграции в zapier).
3) Снижение затрат на обработку и отчёт: протокол ведут в том же airtable, в привязке к каждому из респондентов. Позже записи там же обрабатываются и превращаются в nugget из прошлой записи, база фидбека хранится в том же airtable.
4) В конце месяца из обнаруженных nuggets собирается письмо на команду с основными находками по разным проектам. Т.к. хранится всё в одной базе, собирать по презентациям не нужно, легко вытащить все данные за последний месяц по конкретному проекту.
Сам подход является продолжением идеи WeWork про continuous user research, когда вместо чётко очерченных исследовательских проектов постоянно проводятся open-ended сессии исследований без чётко структурированных сценариев. Подготовка к таким исследованиям почти не занимает времени, а результаты доставляются команде не в виде отчётов, а в виде постоянных пополнений базы инсайтов (о которой я писал в прошлой записи), плюс иногда делаются срезы (например, на скрам-митинге исследователь может рассказать, что нового узнал за прошедшие две недели).
Мне кажется, это здорово подходит для плотной команды с двухнедельными спринтами, и это, наконец, способ вписать исследования в аджайл.
https://medium.com/@tsharon/continuous-user-research-in-11-6-seconds-57c27d1595c5
#ResearchNocode
#Operations
https://blog.airtable.com/how-to-build-a-ux-research-system-that-runs-on-autopilot/
Ещё одна статья от WeWork "how to build a UX research system that runs on autopilot", на самом деле про то, как автоматизировать максимум рутины, если у вас маленькая команда исследователей в большой компании и вас разрывает от проектов.
1) Автоматизация рекрута: у ребят фоном работает НПС-опрос на клиентов. При низкой оценке клиенту автоматом отправляется второе письмо с просьбой поучаствовать в интервью (результаты НПС записывают в airtable, второе письмо шлют через https://customer.io/, всё без разработки на существующих интеграциях).
2) Автоматизация расписания: во втором письме (с просьбой участвовать) приходит ссылка на calendly со слотами для интервью, так что пользователи автоматом записываются в удобное для них и исследователей время. После выбора времени пользователю автоматически высылается письмо с приглашением и ссылкой на встречу в gotomeeting, а его контакты добавляются в airtable (смесь экселя и базы данных) в отдельную табличку (всё тоже настроено без помощи разработчиков, через интеграции в zapier).
3) Снижение затрат на обработку и отчёт: протокол ведут в том же airtable, в привязке к каждому из респондентов. Позже записи там же обрабатываются и превращаются в nugget из прошлой записи, база фидбека хранится в том же airtable.
4) В конце месяца из обнаруженных nuggets собирается письмо на команду с основными находками по разным проектам. Т.к. хранится всё в одной базе, собирать по презентациям не нужно, легко вытащить все данные за последний месяц по конкретному проекту.
Сам подход является продолжением идеи WeWork про continuous user research, когда вместо чётко очерченных исследовательских проектов постоянно проводятся open-ended сессии исследований без чётко структурированных сценариев. Подготовка к таким исследованиям почти не занимает времени, а результаты доставляются команде не в виде отчётов, а в виде постоянных пополнений базы инсайтов (о которой я писал в прошлой записи), плюс иногда делаются срезы (например, на скрам-митинге исследователь может рассказать, что нового узнал за прошедшие две недели).
Мне кажется, это здорово подходит для плотной команды с двухнедельными спринтами, и это, наконец, способ вписать исследования в аджайл.
https://medium.com/@tsharon/continuous-user-research-in-11-6-seconds-57c27d1595c5
#ResearchNocode
#Operations
For The Record
How to build a UX research system that runs on autopilot
Develop faster user insights by automating your research.
Google в 2011 сделали experience sampling, чтобы понять, чего добавить в поиск (и это опять был Tomer Sharon)
Так, у меня есть запрос на маленький нишевый инструмент для исследований, а ещё у меня для вас опрос, но начнём мы с кейса How Google Plans to Find the UnGoogleable:
Что делал Гугл? В 2011-м они захотели понять, в какой информации люди повседневно нуждаются, но не запрашивают её в поиске, чтобы понять, куда поиск развивать, и использовали experience sampling.
1) Experience Sampling выглядит так - вы берёте группу респондентов и через определённые промежутки времени задаёте им один и тот же вопрос, например "Что последний раз расстроило вас при посещении супермаркета?"
Вопрос стоит задавать в пару раз реже, чем происходит само поведение, например, если респондент заходит в магазин раз в день, вопрос про супермаркет задавать раз в два дня.
На выходе получается хороший
список "срезов опыта" - проблем или потребностей, их можно разбить на группы, ранжировать по частоте и радоваться. Такие дневниковые исследования на минималках.
2) Гугл делали esm несколько лет подряд ежегодно, каждый раз охватывая около 1000 человек и получая около 20тысяч семплов опыта.
3) Всем участникам 5 раз в день на телефон присылали вопрос: "что вы недавно хотели узнать?" (What did you want to know recently?) Для сбора заметок использовали приложение Paco.
4) На выходе получили большую таблицу daily information needs, которые затем сгруппировали и приоритезировали.
5) На основе групп daily information needs придумали новые виджеты для поиска и для google now.
Вот тут Tomer Sharon (дада, это тот самый, что продвигал в WeWork atomic research,а сейчас раскачивает Goldman Sachs) рассказывает подробней https://goo.gl/w6Hrop
Вот приложение Paco, через которое они проводили, но оно не очень https://www.pacoapp.com
____
Другие кейсы исследований:
https://t.me/uxread/57 Как Superhuman научились оценивать достижение product-market fit опросником
https://t.me/uxread/24 - Ребята из Playstation тестируют VR игры
https://t.me/uxread/103 ИКЕА классно спрашивают про human experience
https://t.me/uxread/30 как Mozilla исследований использование закладок в браузере, запрещая ими пользоваться (и про то, как люди сохраняют нужную им информацию в интернете)
Другие кейсы исследований #Cases
Так, у меня есть запрос на маленький нишевый инструмент для исследований, а ещё у меня для вас опрос, но начнём мы с кейса How Google Plans to Find the UnGoogleable:
Что делал Гугл? В 2011-м они захотели понять, в какой информации люди повседневно нуждаются, но не запрашивают её в поиске, чтобы понять, куда поиск развивать, и использовали experience sampling.
1) Experience Sampling выглядит так - вы берёте группу респондентов и через определённые промежутки времени задаёте им один и тот же вопрос, например "Что последний раз расстроило вас при посещении супермаркета?"
Вопрос стоит задавать в пару раз реже, чем происходит само поведение, например, если респондент заходит в магазин раз в день, вопрос про супермаркет задавать раз в два дня.
На выходе получается хороший
список "срезов опыта" - проблем или потребностей, их можно разбить на группы, ранжировать по частоте и радоваться. Такие дневниковые исследования на минималках.
2) Гугл делали esm несколько лет подряд ежегодно, каждый раз охватывая около 1000 человек и получая около 20тысяч семплов опыта.
3) Всем участникам 5 раз в день на телефон присылали вопрос: "что вы недавно хотели узнать?" (What did you want to know recently?) Для сбора заметок использовали приложение Paco.
4) На выходе получили большую таблицу daily information needs, которые затем сгруппировали и приоритезировали.
5) На основе групп daily information needs придумали новые виджеты для поиска и для google now.
Вот тут Tomer Sharon (дада, это тот самый, что продвигал в WeWork atomic research,а сейчас раскачивает Goldman Sachs) рассказывает подробней https://goo.gl/w6Hrop
Вот приложение Paco, через которое они проводили, но оно не очень https://www.pacoapp.com
____
Другие кейсы исследований:
https://t.me/uxread/57 Как Superhuman научились оценивать достижение product-market fit опросником
https://t.me/uxread/24 - Ребята из Playstation тестируют VR игры
https://t.me/uxread/103 ИКЕА классно спрашивают про human experience
https://t.me/uxread/30 как Mozilla исследований использование закладок в браузере, запрещая ими пользоваться (и про то, как люди сохраняют нужную им информацию в интернете)
Другие кейсы исследований #Cases
YouTube
Google I/O 2014 - Don't Listen to Users, Sample Their Experience!
Tomer Sharon
Uncovering user needs is one of the most challenging aspects of product development. Oh-so-many organizations develop beautiful products and services nobody needs. The Experience Sampling Method is a simple research technique for uncovering…
Uncovering user needs is one of the most challenging aspects of product development. Oh-so-many organizations develop beautiful products and services nobody needs. The Experience Sampling Method is a simple research technique for uncovering…
🔥1