Поясню:
1. Без гипотез непонятно, что именно проверяем, а следовательно, непонятно, какие задания давать (тип и формулировки). Без них также неясно и как формировать выборку, поэтому конечно всё начинается именно с вопросов и гипотез, на которые ищем ответы (конечно, после целей бизнеса и задач исследования).
2. Про задания и вопросы есть абзац «Ошибки в сценарии исследования».
Спасибо за развёрнутый комментарий, отвечу по пунктам.
Здесь «типичность» ошибок — условная. Если описана какая-то ошибка, то это не значит, что она была абсолютно у всех. Но вынесена сюда, потому что встретилась у нескольких человек и показалась нам важной для разбора.
По поводу критического отношения к тому, какие фичи нужно «запилить» — разумеется, это то, что должно быть у опытного специалиста. Но, проверяя тестовые задания, мы понимали, что у ребят ещё нет или маленький опыт работы в бизнесе, поэтому это нормально, что стажёры не думали об этом, а выполняли конкретное задание и предлагали решение, как проверить необходимость той или иной фичи. Собственно в этом и была цель задания — показать, как это проверить, а не рассказать, как запилить.
Тестовые задания не используются для сбора аргументов для инвесторов, поэтому тут не может быть что-то решённое, для чего кандидаты должны собрать нам эти аргументы.
То же самое справедливо и для конкретизации заданий. У них нет цели решить наши проблемы, более того, это кейсы из прошлого, поэтому мы знаем, и как мы это проверяли, и как это сработало.
В целом, по поводу конкретных или общих заданий — думаю, это зависит от задачи. В данном случае конкретика в заданиях позволила нам проверить и увидеть всё, что нам было нужно не только в мышлении, но и в навыках кандидатов.
По поводу юзабилити-тестирования и терминологии. Соглашусь, что нет смысла отбирать людей по принципу «выучил весь словарь терминов или нет», в частности, были ребята, которые знали слова и посложнее, но этот факт не помог им пройти отбор. Тут было критично, потому что дело не в терминах, а в разных методах, стоящих за ними. Строго говоря, если человек называл юзабилити-тест опросом, но по сути решал задачу правильно — это было ок.
То, что мы ищем стажёра, всё-таки не повод брать людей совсем без знаний. В разработчики ведь тоже не возьмут с ходу человека, который не может написать ни одной строчки кода? Так и тут — если человек учился на психолога/социолога, а плюс к этому, копал в специфику UX или продуктовых исследований, то он не допустит все вышеперечисленные ошибки (часть из них — возможно, но все — точно нет). Сейчас по этой теме появилось много курсов/книг/статей, да и по общему уровню тестовых заданий мы видели, что ребята подготовлены хорошо.
В конечном итоге, цель статьи была не устроить разнос кандидатам, а скорее подсветить проблемные места и повысить уровень ребят в последующие годы.
В целом можно проходить эксперимент с айтрекером, имея очки или линзы, но это снижает вероятность успешной калибровки. Чтобы исключить этот риск, не стали приглашать респондентов с не очень хорошим зрением.
Поясню:
1. Без гипотез непонятно, что именно проверяем, а следовательно, непонятно, какие задания давать (тип и формулировки). Без них также неясно и как формировать выборку, поэтому конечно всё начинается именно с вопросов и гипотез, на которые ищем ответы (конечно, после целей бизнеса и задач исследования).
2. Про задания и вопросы есть абзац «Ошибки в сценарии исследования».
Спасибо за развёрнутый комментарий, отвечу по пунктам.
Здесь «типичность» ошибок — условная. Если описана какая-то ошибка, то это не значит, что она была абсолютно у всех. Но вынесена сюда, потому что встретилась у нескольких человек и показалась нам важной для разбора.
По поводу критического отношения к тому, какие фичи нужно «запилить» — разумеется, это то, что должно быть у опытного специалиста. Но, проверяя тестовые задания, мы понимали, что у ребят ещё нет или маленький опыт работы в бизнесе, поэтому это нормально, что стажёры не думали об этом, а выполняли конкретное задание и предлагали решение, как проверить необходимость той или иной фичи. Собственно в этом и была цель задания — показать, как это проверить, а не рассказать, как запилить.
Тестовые задания не используются для сбора аргументов для инвесторов, поэтому тут не может быть что-то решённое, для чего кандидаты должны собрать нам эти аргументы.
То же самое справедливо и для конкретизации заданий. У них нет цели решить наши проблемы, более того, это кейсы из прошлого, поэтому мы знаем, и как мы это проверяли, и как это сработало.
В целом, по поводу конкретных или общих заданий — думаю, это зависит от задачи. В данном случае конкретика в заданиях позволила нам проверить и увидеть всё, что нам было нужно не только в мышлении, но и в навыках кандидатов.
По поводу юзабилити-тестирования и терминологии. Соглашусь, что нет смысла отбирать людей по принципу «выучил весь словарь терминов или нет», в частности, были ребята, которые знали слова и посложнее, но этот факт не помог им пройти отбор. Тут было критично, потому что дело не в терминах, а в разных методах, стоящих за ними. Строго говоря, если человек называл юзабилити-тест опросом, но по сути решал задачу правильно — это было ок.
То, что мы ищем стажёра, всё-таки не повод брать людей совсем без знаний. В разработчики ведь тоже не возьмут с ходу человека, который не может написать ни одной строчки кода? Так и тут — если человек учился на психолога/социолога, а плюс к этому, копал в специфику UX или продуктовых исследований, то он не допустит все вышеперечисленные ошибки (часть из них — возможно, но все — точно нет). Сейчас по этой теме появилось много курсов/книг/статей, да и по общему уровню тестовых заданий мы видели, что ребята подготовлены хорошо.
В конечном итоге, цель статьи была не устроить разнос кандидатам, а скорее подсветить проблемные места и повысить уровень ребят в последующие годы.