Гипотезы. Вы формулируете их неправильно
Проверьте себя — именно от постановки вопроса зависит качество ответа, который вы получите.
Условно гипотезы в продуктах можно поделить на интерфейсные, продуктовые и бизнесовые.
Первые касаются пользовательского опыта. Вторые – клиентского. Третьи — экспериментов вокруг бизнес-модели, например.
Слово «опыт» промелькнуло здесь неслучайно. Дизайнеры валидируют интерфейсные и продуктовые гипотезы. И они всегда касаются уже существующего опыта.
И если в ваших гипотезах есть частица «бы» или используется будущее время — у меня для вас плохие новости.
Про бизнес-гипотезы и HADI-цикл мы поговорим в другой раз, а сейчас проверьте себя, не допускаете ли вы эти ошибки:
1. Гипотеза должна проверять реальный опыт
Не моделируйте нереальные ситуации или гипотезы о предпочтениях, если проводите ю-тест или интервью / опрос:
— Пользователь предпочтёт более подробный текст предупреждения в модальном окне.
Во-первых, мы понятия не имеем, как поступим в неизвестной для нас ситуации. Всё, что вы получите после такого вопроса — фантазии. Причём, зачастую, свои же — наше сознание устроено так, что ищет подтверждение своей правоты во что бы то ни стало, до последнего игнорируя рациональные аргументы против.
Во-вторых, не каждый метод позволит вам такую гипотезу проверить. Например, гипотезу выше не проверить вообще никак. Что значит «предпочтёт»? Зачем ему что-либо предпочитать? Текст предупреждения решает конкретную задачу и должен быть понятен. Вот это и следует проверить:
— Пользователю понятно, о чём текст предупреждения в модальном окне при удалении заявки.
Гипотеза должна содержать утверждение о реальном опыте, а не гипотетическом, которого никогда не было.
2. Гипотеза должна проверять одно утверждение за раз
Не «Бухгалтеры формируют отчёты в Excel каждый день».
Потому что если бухгалтеры формируют отчёты каждый день, но в 1С, или в Excel, но раз в неделю — ваша гипотеза будет частично подтверждена, частично опровергнута. А это неправильно.
Гипотезу должно быть возможно однозначно подтвердить или опровергнуть. Так вам будет проще исследовать и обрабатывать результаты.
Поэтому:
Бухгалтеры формируют отчёты каждый день.
Бухглалтеры формируют отчёты в Excel.
Это две разные гипотезы.
3. Гипотеза не должна быть общеизвестным фактом
В посте про правильный процесс исследований (доступен по Базовому тарифу) я писала, что проводить исследования на каждый чих — значит прикрывать свою некомпетентность и незнание базовых паттернов проектирования.
Поэтому, не надо проверять кнопку в углу экрана, потому что за юзабилити такого решения отвечает закон Фиттса.
Не надо проверять, что 9 вкладок — ту мач, и сделает выбор мучительно сложным. За это отвечает закон Хика.
Учите базу, товарищи — на собеседовании большинство дизайнеров не могут назвать мне ни одного такого закона.
А когда я преподавала исследования в университете и сказала об этом принципе (что известный факт не может быть гипотезой), студент для своего проекта сформулировал:
— Растения нуждаются в уходе.
Я запомнила это навсегда. Серьёзно, вы не уверены в этом утверждении, это нужно проверить на исследовании? А каким методом, простите? 😄
Бонус
Примеры адекватных гипотез, которые реально проверить на исследовании:
Интерфейсные — проверяем спроектированное решение
Пользователю понятно, как создать заявку
Пользователь не знает, в чём разница между ссылкой на Call ID и CDR ID
Пользователю не понятен термин «Плейсхолдер»
Пользователю неочевидно, что проверить правильность работы функции можно только после её создания
Продуктовые — проверяем потребности и валидируем проблемы в процессах
Бухгалтеры формируют отчёты каждый день
Бухгалтеры используют для отчётов шаблоны
Шаблоны у каждого бухглалтера свои
- Отстанем от бухгалтеров -
Маленькие IT-компании (до 100 человек) не создают матрицы компетенций
В маленьких IT-компаниях не проводится перформанс ревью
В рамках перформанс ревью средние компании (100-500 человек) проводят оценку компетенций
В оценке компетенций в средних компаниях не используется оценка 360
Забегая вперёд — бизнесовые:
Они нужны, чтобы понять, какие действия увеличат прибыль. Или другие показатели, которые, в конечном итоге, всё равно ведут к прибыли и выражаются в ней.
И вот тут-то мы и используем будущее время. Наконец-то!
Если мы запустим YouTube канал, к нам придёт 1000 новых клиентов до конца года.
Если мы внедрим функцию ИИ-ассистента, это увеличит подписки на 15% в Q1 2025.
И так далее.
И исследованиями эти гипотезы никогда не проверить. Потому что исследования отражают уже свершившийся опыт, они отражают текущую действительность.
А бизнес-гипотезы направлены в будущее, на развитие.
И проверяются они, например, по HADI-циклу.
Кстати, такие гипотезы можно легко внедрить и в повседневную жизнь, чтобы увеличить свою эффективность и проще достигать личных целей.
Об этом расскажу совсем скоро в лекции.
Оформляй подписку, чтобы стать лидером в своей нише — неважно, в найме вы или в свободном плавании.
исследования
ux/ui
ux исследования
продакт-менеджмент