Александра Савельева написала для начинающих статью о метриках.

— Метрики дают фактические знания, помогают более осознанно развивать продукт и трезво оценивать эффективность работы дизайнера. Цифры — отличный аргумент в споре;
— Считать их нет смысла, если продуктом пользуется 100 человек, так как каждый такой пользователь сильно влияет на показатели;
— Большое количество «Пользователей в день» или «Заказов в день» не всегда означает успех. Поток новых пользователей может быть вызван рекламой;
— Метрики можно разделить на а) метрики бизнеса (количество пользователей и заказов в день, выручка), которые зависят от сезона, инфляции, мировых трендов и рекламы, б) метрики продукта, которые обычно измеряются в процентах и не зависят от количества пользователей;
— Пример типичной продуктовой метрики — конверсия с одной страницы на другую. Важно знать её для всех магистральных сценариев;
— Важная продуктовая метрика — retention — показывает, какой процент пользователей возвращается в течение выбранного периода времени;
— Выбор периода зависит от продукта. В приложении для знакомств важен ретеншн в короткие периоды, в сервисе для путешествий — от месяца до года, так как большинство путешествует не каждую неделю;
— Дизайнеру лучше ориентироваться на метрики продукта. Выручка и количество пользователей зависят не только от его работы.

Илья Бирман написал, как подойти к созданию дизайн-системы, чтобы она принесла пользу благодаря систематизации, но не мешала развивать продукт.

— Иногда о создании дизайн-системы задумываются просто из-за моды;
— Сначала соберите в один документ компоненты и стили, которые давно используются в вашем продукте и доказали свою нужность и универсальность. Может оказаться, что это всего несколько кнопок, иконок, стилей текста и один попап;
— Детально проработайте их поведение (с длинным текстом, в тёмном режиме, на маленьком экране). Вместе с разработчиками внедрите везде их эталонную реализацию;
— Если после этого перекрашивание кнопок и замена шрифта во всём продукте занимает больше минуты, к следующему шагу переходить рано;
— Развивайте библиотеку, постепенно переводя продукт с несистемных компонентов на системные. В одном месте есть кнопка с иконкой — добавьте иконки в библиотечные кнопки, тестируйте, внедряйте;
— Заниматься развитием библиотеки самой по себе неэффективно. Развивайте её вместе с продуктом, когда строите в нём что-то новое;
— Может оказаться, что до каких‑то частей продукта систематизация не дойдёт ещё несколько лет. Значит вы просто их не трогаете, потому что они не важные.

Станислав Хрусталёв собрал чеклист, как использовать QR-коды для создания позитивного клиентского опыта. Вот часть рекомендаций:

— Если это возможно и уместно, QR-коды использовать стоит, значительная часть людей к технологии готова;
— Сопровождайте код пояснением: что клиент должен сделать и что получит взамен. Также можно уточнить, что для считывания кода надо навести на него камеру телефона (или использовать специальное приложение, как в Ашане);
— Размещайте в QR-кодах лого компании, с брендированием они выглядят профессиональнее;
— Если код будет на офлайновом носителе, при выборе размера учитывайте дистанцию, с которой его будут считывать;
— Размещайте коды на поверхностях, с которыми клиенты не контактируют. Поверхность может начать стираться, и код перестанет работать;
— Убедитесь, что в месте его размещения хороший мобильный интернет или есть вайфай, иначе полезность такого кода устремится к нулю;
— QR-код на десктопной версии сайта может вести на мобильное приложение компании, чтобы пользователь мог легко зайти в магазин приложений со своего телефона (используйте deep linking). Такой же код на мобильной версии сайта вызывает вопросы;
— Чтобы у клиента не рябило в глазах, не размещайте рядом несколько разных кодов для разных целевых действий. Сделайте один код, за которым будет страница с меню из нескольких действий;
— Проверяйте, что целевая страница оптимизирована для просмотра на телефонах.

Bang Bang Education опубликовали киноальманах «Лепота» на Ютубе — бесплатно и без регистрации.

3:00 Fuckyou Digital
5:27 CLAN
8:30 Алексей Ивановский
11:05 Оля Панькова, Владимир Шипилов
13:40 Дима Корниенко, Ваня Корниенко
16:50 Макси Шилов
19:40 Алена Лебедева
21:35 Регина Турбина
23:30 Ждан Филиппов
25:45 Владислав Деревянных и «Восход»
28:50 Вова Аюев
32:00 Денис Башев
34:25 Роман Ерохнович
37:00 Mishka Luganski
39:20 Олег Пащенко
41:50 Сергей Гуров
45:35 Electric Red
48:15 Holystick
51:00 Саша Ермоленко
54:00 Александр Загорский
56:50 Антон Горбунов
59:35 Дима Родионов
1:02:00 Sila Sveta
1:04:35 Just Be Nice
1:07:15 Александр Сметанка
1:09:10 Кирилл Глущенко
1:13:00 Жи-Ши
1:15:45 Татьяна Егошина
1:17:50 Сергей Серов, Катерина Терехова
1:20:10 White Russian Studio
1:23:15 ONY
1:25:30 Андрей Зубрилов
1:28:10 Анатолий Беликов
1:32:45 MAGIC CAMP
1:35:20 Антон Шнайдер
1:37:40 Александр Васин и группа «Ижица» (есть отдельное видео)

Гонсалу Диас написал, почему надо отказаться от бесконечного скрола.

— Он эффективен для просмотра большого объёма информации с небольших устройств, так как устраняет трение: пользователю не надо ничего нажимать, чтобы получить новый контент;
— Он идеален для соцсетей: контента много, а пользователь не особо вовлечён и ничего конкретного не ищет;
— С ним пользователи могут теряться на сайте, медленнее находить что-то конкретное, им недоступен подвал. Об особенностях бесконечного скрола писали Михаил Букин и Кристиан Холст;
— Но основная проблема заключается в эксплуатации синдрома упущенной выгоды (FoMO), истощении человека стимулами и накоплении ненужного контента;
— Разделение на страницы — наиболее понятный способ организовать информацию, востребованный в электронной коммерции. Количество элементов на каждой странице ограничено, пользователи это понимают и могут оценить объем просмотренного и оставшегося контента, вспомнить, где видели понравившийся товар;
— Размещение в конце списка с контентом кнопки «Загрузить ещё» предполагает, что пользователь не обязательно захочет ещё. Плюс, появляется доступ к подвалу;
— Соцсети должны взять на себя ответственность за информационную перегрузку и уходить от высокоскоростного контента к идеально подобранному персонализированному, анонсы которого пользователь просмотрит в две прокрутки;
— Сейчас, в мире бесконечного количества информации, мы можем разве что следить за своими привычками и использовать ограниченные возможности своего внимания в первую очередь для достижения своих целей.

Владимир Белов написал о тултипах (всплывающих подсказках).

— Тултипы помогают обучать пользователей и объяснять интерфейс;
— Тултип отображается при наведении курсора на элемент интерфейса. Если рядом находятся несколько элементов с тултипами, отображайте его, когда пользователь задерживает курсор на одном из элементов;
— Их стоит использовать с кнопками без текста, так как метафоры иконок могут быть непонятными;
— В них можно показывать сочетания клавиш для взаимодействия с элементами интерфейса, требования к вводимому паролю, дополнительную информацию (но только если она не занимает половину экрана);
— Также — полный текст, который в интерфейсе отображается сокращённым (например, слишком длинное слово в узкой ячейке таблицы);
— С их помощью можно объяснять, почему кнопка у пользователя заблокирована;
— Чтобы появление тултипа было приятным, достаточно стандартного transition 0.3s;
— Чтобы добавить подсказку к тексту, на который пользователи редко наводят курсор, можно рядом разместить иконку (i) или (?) с тултипом. Например, так можно пояснить подпись к полю, включающую незнакомый термин.

Ещё о тултипах писал Викалп Кошик.

Сэм Айронс написал о дизайн-долге — дизайнерском аналоге технического долга: как классифицировать, измерить и погасить.

— Это накопленные проблемы с дизайном, решение которых отложили на потом;
— Варианты разумного дизайн-долга: а) Преднамеренный: команда понимает, что дизайн не очень, но решает его реализовать и планирует доработки на следующие итерации; б) Непреднамеренный: команда реализует хороший дизайн, но со временем он перестаёт быть таковым, так как меняются обстоятельства;
— Безрассудный преднамеренный дизайн-долг отличается от разумного тем, что команда делает «быстро и грязно», не оценивая трудозатраты на доработки и не планируя их (хакатоны, инновационные спринты);
— Безрассудный непреднамеренный дизайн-долг появляется из-за некомпетентности и отсутствия опыта;
— Кто создаёт продукт, тот и должен его обслуживать, в том числе устранять дизайн-долг;
— Время на обслуживание надо закладывать в план. В Atlassian на это уходит четверть рабочего времени;
— Можно выявлять отдельные баги в UI (неправильный отступ, опечатка) или UX (проблема с сообщением об ошибке, стандартное пустое состояние);
— Можно искать способы: а) Снизить сложность сценария, уменьшив количество ответвлений или пользовательских действий, необходимых для его прохождения; б) Уменьшить количество отдельных сценариев, которые надо последовательно пройти в продукте для достижения цели; в) Упростить концептуальную модель, сократив количество сущностей и связей между ними;
— Появление дизайн-долга можно предотвращать, внедряя лучшие практики вроде проведения исследований, поиска нескольких решений, вовлечения клиентов в процесс, сквозного тестирования существующих продуктов, анализа клиентских отзывов и так далее;
— Возвращайтесь к компромиссным решениям и планируйте их доработки. Принимая такие решения, старайтесь сразу включать доработки в план;
— Сделайте дизайн-долг прозрачным: ведите бэклог, измеряйте его размер;
— Зафиксируйте обязательства по регулярному погашению долга;
— Стандартизируйте процедуры выявления и погашения долга (Брейден Ковиц упоминал день исправления UI-багов).

Егор Камелев и Эдвард Чечик написали (отдельно друг от друга) о проектировании тултипов. О всплывающих подсказках недавно было, так что эта заметка дополнит и на какое-то время закроет тему.

— Тултип может отображаться также при фокусе на элементе интерфейса с помощью клавиатуры, длительном нажатии на него (на мобильных устройствах) и разглядывании (в VR-шлеме с трекингом взгляда);
— В нём можно показывать обратную связь, например, что нажатие на контрол привело к копированию текста в буфер обмена;
— Примеры дополнительной информации, которую часто показывают в тултипах: числовые значения для отдельных частей графика или диаграммы; значение, выбираемое с помощью ползунка; ответ на вопрос «что это за непонятное число»;
— Стрелка тултипа указывает на связанный с ним элемент интерфейса. Полезно, когда таких элементов много рядом;
— Не размещайте в тултипе важную информацию;
— Поповер ≠ тултип. Поповер появляется при нажатии на элемент и может включать несколько абзацев текста, ссылки и кнопки;
— Если вы не используете фреймворк вроде Бутстрапа, то при создании тултипа надо будет ответить на не самые очевидные вопросы (примеры ниже);
— Если два элемента стоят рядом, и пользователь сместил фокус с одного на другой, как должны вести себя тултипы (например, меняются мгновенно, игнорируя правило задержки)?
— Где должен появиться тултип, если связанный с ним элемент находится близко к краю экрана?
— Максимальный объём текста в тултипе и максимальная ширина контейнера?
— Как отделить тултип от остального интерфейса? Цвет (в Бутстрапе по умолчанию белый текст на чёрном фоне), прозрачность, тень;
— Не стоит уменьшать размер текста в тултипе и усложнять его читаемость (борьбы за пространство в этом сценарии нет), да и в целом добавлять ради него новый стиль.

Александра Савельева написала об уровнях развития цифрового продукта (о них писал также Аарон Уолтер в книге «Эмоциональный веб-дизайн»).

— Функциональный продукт (решает задачи) → Надёжный (работает стабильно) → Удобный (им легко пользоваться) → Приносящий удовольствие (вызывает улыбку);
— Каждый продукт стоит на своей ступеньке;
— Нельзя перескакивать через уровни. Даже написанное лучшими UX-редакторами сообщение об ошибке не спасёт, если приложение ошибается слишком часто;
— Функциональные продукты: выполняют специфические задачи, иногда не имеют графического интерфейса и почти никогда не нуждаются в дизайнере;
— Надёжные: многие профессиональные и излишне сложные продукты, у которых просто нет более удобных конкурентов; стартапы на этапе проверки гипотезы;
— Удобные: большинство продуктов;
— Приносящие удовольствие: продукты на конкурентных рынках;
— Чтобы разработка не упрощала ваши задумки до полной неузнаваемости макетов, надо понимать, на каком уровне находится ваш продукт;
— Если продукт на низком уровне, в макетах должно быть что-то бюджетное для разработки. Это повысит их шансы на реализацию.

В «Собаке Павловой» написали о подготовке макетов профессиональных интерфейсов к тестированию.

— Их пользователи чаще сталкиваются с ситуациями, для которых нет чёткого сценария;
— Такие интерфейсы могут включать векторы взаимодействия: 1) Педагогический (новичок ищет подсказки в интерфейсе); 2) Непосредственный (опытный пользователь работает без подсказок, знает популярные идиомы); 3) Невидимый (эксперт использует шорткаты);
— Они ориентированы на специалистов, знакомых с терминами и неочевидными идиомами, проходящих обучение;
— На макетах проблематично тестировать 3-й вектор взаимодействия, но он есть не во всех профессиональных продуктах;
— Если респондент не справился с задачей, это не всегда ошибка проектирования. Заказчик интерфейса может планировать изменение текущего процесса и рассчитывать на дальнейшее обучение;
— Соберите макеты в прототипы, в которых можно протестировать отдельные сценарии и ситуации. Вместить все ситуации в один прототип не получится;
— Одно задание — один рабочий процесс или ситуация;
— Все элементы, относящиеся к сценарию, должны быть интерактивны. Если пользователь нажал на неактивный элемент, можно обсудить, почему он это сделал;
— В прототипе можно выделить несколько основных процессов, но охватить всё многообразие возможностей не получится. Отчасти помогут Framer, Axure и Anima, но тестирование профессиональных продуктов на этапе макетов всегда немного условно.

Эдвард Чечик написал о панелях свойств (боковых панелях), которые часто можно встретить в профессиональных продуктах.

— Вкладки в верхней части панели позволяют разделить её на отдельные секции;
— Панели часто делятся на блоки — группы свойств, которые пользователь может скрывать и раскрывать;
— Обычно редактируемый объект меняется сразу после изменения его свойств на панели, но если изменение требует времени — после нажатия на кнопку подтверждения;
— Также отдельные кнопки обычно используют для загрузки файлов и экспорта;
— Часто ползунки сопровождаются числовыми полями;
— Некоторые числовые поля позволяют менять единицы измерения;
— Многие особенности панели свойств обусловлены необходимостью экономить место: частое использование раскрывающихся списков (вместо групп радиокнопок), модальные окна с дополнительными возможностями, расположение подписей к полям сбоку (расположение сверху увеличивает скорость заполнения всей формы, но на панели свойств этого не требуется), частое использование сегментированного переключателя (segmented control) с иконками;
— Иногда подписи располагаются под полями, состоят из одной буквы или иконки;
— При неправильном заполнении поля приложение не отображает сообщение об ошибке и может удалить некорректный ввод. Ожидается, что пользователь профессионального продукта знает, какие значения вводить;
— Визуализируйте редактируемые свойства. Пример: блок Constraints в Фигме;
— Дайте скрыть и показать панель свойств, если пользователю потребуется больше места на экране.

In English.

Александр Ревенок написал о таком методе исследования как Fake door.

— Это симуляция наличия в продукте какой-либо функции;
— Позволяет проверить необходимость фичи в рабочих условиях, выяснить предпочтения аудитории, найти релевантных респондентов для интервью;
— Пользователь встречает в продукте якобы готовую фичу (триггер), пытается ей воспользоваться (возможно, проходит небольшой опрос) и видит слова благодарности с сообщением, что фича ещё в разработке (и предложение поучаствовать в интервью или стать пользователем бета-версии);
— Например, триггером может быть баннер о скором появлении инструмента для управления клиентами, предлагающий добавить первого клиента и получить ранний доступ. Пользователь нажимает на «Добавить клиента», вводит его данные и отвечает на вопрос о взаимодействии с клиентами. На шаге с благодарностью указывает, готов ли получить ранний доступ, поучаствовать в интервью, и хочет ли сохранить данные клиента для дальнейшей работы;
— Так можно проверить и предпочтения в дизайне: предложить выбрать другие формы отчёта вместо табличной, посмотреть, что выбирают пользователи, и решить, надо ли делать редизайн;
— Не стоит проводить такие эксперименты слишком часто и затягивать надолго. Сегментируйте аудиторию, чтобы в эксперимент попали наиболее релевантные пользователи.

Наталья Стурза написала о чек-листе проектирования, который помогает не упускать детали, создавая сложные продукты.

— Недочёты проявляются после того, как продуктом начали пользоваться. Но их будет намного меньше, если позаботиться о мелочах на этапе дизайна;
— Продумывать надо и экраны интерфейса, и остальное взаимодействие с продуктом (текст ошибок, имейлов и смс, прерывания, валидацию), проработка которого обычно падает на разработчиков и маркетологов;
— Начните с информационной схемы (для более-менее статичных страниц, когда ответвлений в сценарии немного) или бизнес-процесса (для разветвлённых сценариев со множеством альтернативных и негативных путей);
— Покажите в них места начала и окончания сценария, наборы данных, ограничения и условия в отношении данных и действий над ними, логику движения по сценарию в зависимости от условий и пользовательского выбора;
— Проработайте альтернативные и негативные сценарии (например, чтобы открыть счёт для юрлица и ИП, нужны разные документы), а также нулевые, минимальные и максимальные состояния элементов интерфейса;
— Продумайте разные места начала и окончания сценария. Один и тот же процесс может стартовать из разных точек с разным набором первоначальных данных. Например, выставить счёт можно из меню, списка частых действий или истории документов (создать его на основе предыдущего);
— Проработайте ошибки, прерывания и ограничения. Например, поведение системы, если пропал интернет;
— Сообщения об ошибках пишите под конкретные ситуации: можно не ввести номер расчётного счёта, ввести его не полностью, ошибиться цифрой, ввести правильно, когда сломался алгоритм его проверки или пропал интернет;
— Ограничения — это технические, бизнесовые и регуляторные условия, влияющие на элементы интерфейса. Иногда они становятся минимальными или максимальными состояниями. Например, в назначении платежа можно ввести только 210 символов;
— Учтите, что с одной и той же частью продукта могут работать разные типы пользователей. Например, у счёта может быть создатель (бухгалтер), отправитель (директор) и получатель, который увидит его на бумаге, сайте или в личном кабинете, если обслуживается в том же банке.

Николай Романов написал, как выстроить лендинг, чтобы его прокручивали до конца.

— Не обманывайте ожиданий: не лейте воду и не меняйте тему;
— Анимацию перехода от одной информации к другой синхронизируйте с прокруткой страницы. Так пользователь будет чувствовать контроль;
— Меняйте ритм повествования. Например, блоком с крупным текстом можно разбавить блоки с заголовками, текстом и картинками;
— Кроме прокрутки предлагайте другие способы взаимодействия: нажать или навести курсор, чтобы узнать детали. Но важно не переборщить: не больше 2–3 механик для лендинга до 20 экранов;
— Иногда лучше немного анимировать статичные картинки, чтобы они привлекали внимание.

Кейт Доулер поразмышляла, когда усложнение взаимодействия улучшает пользовательский опыт.

— Препятствие помогает замедлить пользователя, чтобы он успел включить голову. Пример: необходимость подтвердить действие;
— Также оно помогает изменить поведение. Пример: долгое ожидание лифта побуждает людей пользоваться лестницей. Но от таких манипуляций один шаг до тёмных паттернов;
— Вкладывая больше сил, люди больше ценят результат (эффект Ikea). Пример: разнашивание новых Dr. Martens (приносящее боль) включено в руководство пользователя;
— В определённых ситуациях человек может получать удовольствие от совмещения позитивных и негативных ощущений. Примеры: просмотр фильма ужасов; поедание острой пищи и знание, что жжение рано или поздно закончится;
— Попробуйте в рамках обратного мозгового штурма спроектировать плохое решение и посмотреть, какие идеи появятся.

Люси Скотт написала, как упростить интерфейс для людей в стрессе.

— Основные причины стресса: а) трудности в личной жизни, б) сложная задача, для решения которой мало времени или информации, в) с решением возникли проблемы: что-то идёт не так или пользователь не понимает, что делать;
— У человека в стрессе эмоции и инстинкты преобладают над рациональным. Он хуже ориентируется в пространстве и справляется с навигацией, может не заметить или неправильно понять те или иные символы, может повторять действия, даже если они не дают нужного результата (нажимать на одну и ту же кнопку). Страдает внимание и рабочая память, человек вообще может бросить свою задачу;
— Снижайте когнитивную нагрузку: сокращайте количество вариантов для выбора, делите информацию на легко усваиваемые части, показывайте рядом связанную с задачей информацию;
— Делите процесс на небольшие шаги, которые можно легко выполнить;
— Устраняйте неопределённость: используйте знакомые иконки, сопровождайте их подписями, пишите лаконичные и однозначные формулировки;
— Запрашивайте только необходимые данные, старайтесь автоматизировать всё, что возможно;
— Попробуйте сделать формулировки человечнее, чтобы они поддерживали пользователя и в нужных местах выражали сочувствие. Подумайте, как воспримет их человек в стрессе.

Анастасия Брыкова написала о культурных особенностях в дизайне интерфейсов.

— Недостаточно перевести текст на разные языки. Пользователи хотят, чтобы продукт учитывал их культурные особенности и методы ведения бизнеса;
— В разных культурах могут меняться значения цветов;
— Одно сообщение на разных языках может быть разной длины и отличаться направлением письма (справа налево и даже сверху вниз);
— Иероглифических шрифтов намного меньше, что сокращает возможности по оформлению текста с иероглифами;
— Отличаются единицы измерения, валюты, форматы отображения дат, чисел и цен;
— Может отличаться восприятие отдельных символов: знак «Окей» во Франции и Турции, «Палец вниз» в Японии;
— В японских интерфейсах обычно избыточно яркая цветовая гамма и много иллюстраций. Китай схож с Японией, но медленно перенимает европейский минимализм. В Южной Америке используют декоративные шрифты и сочетания ярких цветов.

Ещё о локализации недавно писали в GTE Localize.

В «Собаке Павловой» написали о решении дизайнерами бизнес-задач.

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

Смотрите также примеры бизнес-задач и диалога для их выявления из лекции Ильи Бирмана «Понимание задачи».

Чем отличаются униширинные и моноширинные шрифты?

Униширинный (Uniwidth) — пропорциональный шрифт, в котором ширина символов не меняется при изменении их насыщенности. Текст в начертании Bold занимает столько же места, сколько такой же текст в начертании Regular. Полезное свойство для элементов интерфейса: если болдом выделять текущий пункт горизонтального меню, соседние пункты не будут смещаться. Пример такого шрифта: Golos UI.

Моноширинный (Monospaced) — непропорциональный шрифт, в котором ширина всех символов одинакова. Пример: Courier.

Об униширинных шрифтах in English.

Эмилия Городовых и Анна Серова написали, как уменьшить когнитивные искажения при проведении пользовательских исследований.

— Когнитивные искажения — ошибки в восприятии информации. Они появляются непроизвольно, чтобы «помочь» нам справиться с неопределённостью или быстро понять, что делать дальше;
— Если знать, когда и как они проявляются, намного проще их отследить и скорректировать своё поведение;
— При формировании гипотез и планировании исследования часто встречаются: 1. Иллюзия асимметричной проницательности (отвергаем картины мира других людей, не слышим критику); 2. Искажение изобретателя (слишком любим свою идею, идём подтверждать гипотезу, а не проверять её);
— Это защитная реакция на неопределённость и наличие противоречий. И это нормально в начале исследования, которое призвано найти ответы и снять неопределённость. Чтобы избежать искажений, фокусируйтесь на процессе, а не результате в виде подтверждённой гипотезы;
— При проверке гипотез: 3. Эффект ожидания наблюдателя (ожидая определённого результата, бессознательно влияем на ход эксперимента, например, задаём наводящие и узкие вопросы); 4. Эффект обратного действия (сомневаемся в качестве выборки и корректности исследования, если гипотеза не подтверждена);
— Чтобы этого избежать, вовлекайте команду в процесс исследования, вместе изучайте скрипты интервью и так далее;
— При анализе результатов исследования: 5. Ошибка базового процента (слишком много внимания уделяем специфичным редким ситуациям); 6. Информационное искажение (ищем новую информацию, когда она уже ни на что не влияет);
— Чтобы этого избежать, подводите итоги исследования или интервью спустя время, уложив мысли в голове и отойдя от эмоций.