В прошлой статье я разбирала пять искажений, которые мешают пользователю пройти по интерфейсу. Эта — про четыре других, которые мешают тому, кто интерфейс делает.

Двенадцать правок

Правки к макету пришли в пятницу вечером. Двенадцать пунктов.

Я прочитала первый и закрыла ноутбук. За эту секунду в голове уже прозвучало: «я не тяну эту роль».

Посмотрите, что произошло. Двенадцать замечаний к файлу превратились в утверждение о человеке. Без фактов, без разбора, за долю секунды. Если бы диагностика работала так же, я бы ставила диагноз по первой жалобе и уходила пить чай.

Мы умеем не доверять уверенности, когда речь об интерфейсе. Проводим тесты, зовём человека со стороны, ищем причину вместо того, чтобы закрасить симптом. Когда речь о себе, та же уверенность проходит внутрь без единого вопроса.

Два разных семейства искажений

Когда дизайнеры говорят «когнитивные искажения», обычно имеется в виду поведенческая экономика: якорь, эффект владения, ошибка выжившего, склонность к подтверждению. Аппарат Канемана и Тверски. Он про то, как человек принимает решения, и мы изучаем его профессионально — чтобы понимать пользователя. Об этом была прошлая статья.

Есть второе семейство, выросшее из клинической психотерапии: Аарон Бек, Альберт Эллис, позже Дэвид Бернс. Эти искажения занимаются другим — выводами, которые человек делает о себе. Дизайнеры их обычно не изучают, просто живут внутри них.

Разница принципиальная. Искажение здесь сидит в форме мысли. Содержание бывает любым — про правки, про ребёнка, про результат анализа, — а кривая схема одна и та же. Поэтому её можно узнать в лицо, не разбираясь в содержании.

Бернс описал около десяти таких схем. Ниже — четыре, которые я вижу в работе дизайнера чаще всего. Формулировки мои, примеры из практики; полный список — в его книгах по когнитивной терапии.

Почему у дизайнеров это цепляет сильнее

У нашей профессии три особенности, которые превращают обычную рабочую критику в разговор о личности.

Первая: работу оценивают вслух и коллективно. Бэкенд ревьюят двое в пул‑реквесте, макет смотрят восемь человек на созвоне, и каждый считает себя вправе высказаться, потому что глаза есть у всех.

Вторая: вкусовое мнение внешне неотличимо от аргумента. «Мне не нравится этот синий» и «этот синий не проходит по контрасту» звучат в одной интонации и приходят в одном списке. Отделять первое от второго — отдельный навык, и пока он не выработан, весь список читается как одно сплошное «плохо».

Третья: артефакт выглядит как продолжение автора. Код спрятан, а макет — картинка, которую видно целиком, и в ней читается вкус, аккуратность, чувство ритма. Замечание к макету ощущается как замечание к тому, как вы устроены.

Ни одна из трёх особенностей не делает критику личной на самом деле. Но все три делают ярлык очень удобным способом её прочитать.

1. Ярлык

Один поступок повышается до целой личности.

«Мне прислали правки» превращается в «я плохой дизайнер». «Я не заметила этот кейс» — в «я невнимательная». Между «я сделала ошибку» и «я неудачница» лежит пропасть, но проходится она мгновенно и незаметно.

Как это выглядит в работе. Джун приносит макет, вы отмечаете четыре вещи, которые нужно поправить. Он слышит: «я не тяну». Дальше он либо переделывает всё подряд, включая то, что было хорошо, либо перестаёт показывать работу до идеального состояния — то есть перестаёт показывать вообще.

Что делать. Разделить действие и человека прямо в формулировке. Не «я невнимательная», а «я пропустила состояние ошибки в этой форме». Первое не подсказывает ни одного следующего шага. Второе подсказывает ровно один.

2. Негативный фильтр

Из всей картины выхватывается одна тёмная деталь, и она красит собой остальное.

Двадцать человек согласовали флоу. Один спросил: «а почему тут так?». Вечером вы помните только его вопрос. Причём не как вопрос, а как приговор всей работе.

Я долго думала, что это моя мнительность. Это устройство внимания: негативный сигнал обрабатывается быстрее и держится дольше, потому что эволюционно он дороже. Полезная настройка для леса. Плохая — для ревью дизайна.

Как это выглядит в работе. После защиты макета вы садитесь править не то, что важно, а то, что вспомнилось. Приоритеты в бэклоге расставляет не задача, а эмоциональный вес комментария.

Что делать. Собирать обратную связь письменно и целиком, а не по памяти. Список из четырнадцати пунктов, где двенадцать — «ок», выглядит совсем не так, как воспоминание о нём. Это тот же приём, что и в лаборатории: результат смотрят по протоколу, а не по впечатлению.

3. Чтение мыслей

Вывод о том, что происходит в голове у другого человека, при полном отсутствии данных.

Заказчик молчит два дня — значит, ему не понравилось, и он уже присматривает другого подрядчика. Продакт коротко ответил в переписке — значит, недоволен. Никто ничего не сказал на демо — значит, было плохо.

Фактов ноль. Вывод готов и ощущается как знание.

Как это выглядит в работе. Это самое дорогое из четырёх, потому что бьёт по исследованиям. Дизайнер, который «и так знает», что подумал заказчик, той же мышцей знает, что подумает пользователь. «Тут очевидно, куда нажимать» и «он молчит, потому что злится» — одна и та же операция: достроить чужую голову изнутри своей.

Что делать. То же, что с гипотезой о пользователе. Не проверять её домыслом, а спрашивать. «Ты молчишь второй день — это занятость или что‑то не так с макетом?» Один вопрос вместо двух дней сценариев.

4. Императивы

Речь, собранная из слов «должна», «обязана», «нужно было».

«Я должна была предусмотреть этот кейс». Не «хорошо бы было предусмотреть», а «должна». Планка ставится на высоте, которую невозможно взять, и вы живёте в постоянном отставании от неё.

Как это выглядит в работе. Императивы съедают приоритизацию. «Я должна была предусмотреть все кейсы» — это отказ от выбора: кейсов бесконечно много, а работа дизайнера состоит ровно в том, чтобы решить, какие важны сейчас, а какие подождут до следующего релиза. Пока формулировка звучит как долг, любой невыбранный кейс становится личным провалом.

Что делать. Заменить долженствование на выбор с ценой. Не «я должна была это предусмотреть», а «я выбрала не закрывать этот кейс в первой версии, потому что закрывала оплату. Сейчас пришло время закрыть».

Как это чинится

Три шага, и все три письменные. Мысль, которая крутится в голове, живёт по своим законам; выписанная на бумагу, она становится обычным текстом, к которому можно предъявить требования.

Первое. Записать мысль дословно. Не смягчая. Если в голове звучало «я не тяну эту роль», так и писать, а не «немного не уверена в себе».
Второе. Назвать форму. Какая из схем? Часто в одной фразе их две‑три сразу.
Третье. Переписать точнее. Не позитивнее — точнее.

Как это выглядит на моём примере.

Было: «Я не тяну эту роль».

Факты: двенадцать комментариев. Восемь про отступы и состояния кнопок, два про логику шага, два вкусовых.

Стало: «Восемь правок по делу, два вопроса требуют обсуждения, два — вкусовщина. С логикой шага я действительно промахнулась, и это стоит разобрать до понедельника».

Вторая формулировка не добрее первой. Она точнее — и, в отличие от первой, из неё видно, что делать в понедельник.

Тут работает ровно та же логика, что с багом. «Всё сломалось» — не диагноз и не помогает. «Падает на пустом ответе сервера» — диагноз, из которого следует фикс.

Почему это профессиональный вопрос, а не самокопание

Мне важно проговорить это отдельно, потому что тема выглядит как разговор про чувства. Она про качество работы.

Обратная связь — это данные. Искажение на входе портит данные, а на испорченных данных принимаются решения о продукте. Дизайнер, который прочитал двенадцать правок как приговор, дальше делает одно из двух: либо переделывает всё подряд, включая то, что работало, либо начинает защищать макет вместо того, чтобы услышать, где он действительно ломается. Оба варианта стоят команде времени, и ни один не связан с тем, хороший ли это дизайнер.

Второе следствие — молчание. Человек, который ждёт приговора, перестаёт показывать сырое. А сырое — это ровно то, что дёшево менять. Чем позже макет выходит на свет, тем дороже каждая правка. Мы знаем это про пользовательские тесты и почему‑то не переносим на себя.

Что с этим можно сделать в команде

Пока это выглядит как работа наедине с собой, но половина чинится процессом.

Разделять в обратной связи факт и вкус. Простое правило для ревью: каждое замечание помечается как «блокер», «важно» или «на мой вкус». Автору сразу видно, что из четырнадцати пунктов блокеров два. Это не смягчение критики, это её честная разметка — и она отбирает у негативного фильтра материал для работы.
Проговаривать, что осталось хорошо. Не ради поддержки, а ради точности: если человек не знает, что сохранить, он перепридумает всё. Одна фраза «сетка и состояния работают, вопрос только к логике шага» экономит день переделок.
Просить формулировку, а не оценку. «Мне здесь неудобно» полезнее, чем «плохо», и, что важнее, почти не читается как приговор. Это тот же навык, который мы тренируем на юзабилити‑тестах, когда учимся спрашивать «что вы сейчас пытались сделать» вместо «вам нравится».
Показывать сырое раньше. Чем чаще макет выходит на свет полусобранным, тем меньше веса у каждого отдельного комментария. Правки к черновику никто не читает как приговор — их для того и звали.

Ничего из этого не требует, чтобы команда занималась чьей‑то самооценкой. Это обычная гигиена обратной связи, просто у неё есть побочный эффект: искажениям становится не за что зацепиться.

Чего не видел мой собственный контроль качества

Восемь лет я работала врачом клинической лабораторной диагностики и заведовала контролем качества. Вся моя работа состояла в том, чтобы не доверять одному результату. Перепроверить. Сравнить с контрольным образцом. Понять, где ошибка в измерении, а где действительно в организме. Один показатель вне нормы — это повод посмотреть внимательнее, а не поставить диагноз.

Когда результатом стала я сама, ни одна из этих процедур не включилась. Двенадцать комментариев к файлу прошли без перепроверки, без контрольного образца, без вопроса «а как это измеряли».

Уверенность эксперта — плохой диагностический инструмент. В медицине это знают и потому существуют второе мнение, консилиум и обязательная перепроверка на сложных случаях. В дизайне это знают и потому существуют юзабилити‑тесты, аудиты доступности и ревью. Обе профессии построены на признании, что своей уверенности доверять нельзя.

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

Границы

Список искажений — инструмент наблюдения, а не оценка и не диагностика. Он нужен, чтобы поймать себя на кривой формулировке и переписать её, а не чтобы поставить себе балл или диагноз.

Если самокритика месяцами мешает работать, спать и жить, четыре схемы из статьи здесь не помогут — это разговор со специалистом. Написанное выше про рабочие ситуации, а не про состояние, которое лечат.

Что в итоге

Пять искажений из прошлой статьи ломают путь пользователя по интерфейсу. Эти четыре ломают человека, который интерфейс делает, — и через него всё равно доходят до продукта.

Инструмент один и тот же: не верить первой формулировке. Записать. Найти форму. Переписать точнее.

Мы тестируем интерфейс, потому что не доверяем своей уверенности в нём. Своей уверенности в себе доверяем без единой проверки, хотя ошибается она чаще.

Полный список схем — у Дэвида Бернса, в его книгах по когнитивной терапии. Я взяла четыре, которые вижу в работе чаще всего.

Про дизайн, доступность и здоровье пишу в телеграм‑канале @kikodocc.

А что первым делом звучит у вас в голове, когда приходят правки?

Первая часть диптиха: «5 когнитивных искажений, которые ломают UX» — https://habr.com/ru/articles/1014772/

Пять искажений ломают UX. Ещё четыре ломают самого дизайнера