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

— Это накопленные проблемы с дизайном, решение которых отложили на потом;
— Варианты разумного дизайн-долга: а) Преднамеренный: команда понимает, что дизайн не очень, но решает его реализовать и планирует доработки на следующие итерации; б) Непреднамеренный: команда реализует хороший дизайн, но со временем он перестаёт быть таковым, так как меняются обстоятельства;
— Безрассудный преднамеренный дизайн-долг отличается от разумного тем, что команда делает «быстро и грязно», не оценивая трудозатраты на доработки и не планируя их (хакатоны, инновационные спринты);
— Безрассудный непреднамеренный дизайн-долг появляется из-за некомпетентности и отсутствия опыта;
— Кто создаёт продукт, тот и должен его обслуживать, в том числе устранять дизайн-долг;
— Время на обслуживание надо закладывать в план. В 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. Информационное искажение (ищем новую информацию, когда она уже ни на что не влияет);
— Чтобы этого избежать, подводите итоги исследования или интервью спустя время, уложив мысли в голове и отойдя от эмоций.

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

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

Илона Саркисова завершила серию статей о Customer Journey Map рассказом о том, что делать, если пользователь не является покупателем.

— Пользователями могут быть сотрудники организации. Им не нужно узнавать о продукте и покупать его, так как его навязывает работодатель;
— Классическая CJM им не подходит, но чтобы создать удобный продукт, полезно хоть как-то картировать их опыт;
— Полезен сам процесс создания карты — помогает активировать эмпатию;
— Сначала сформулируйте, для чего нужна карта и что она будет иллюстрировать;
— Для b2b-продуктов может быть непросто определить, чей опыт картировать, так как в работу могут быть вовлечены разные роли, действия которых взаимозависимы;
— Рамки, когда начинается и заканчивается картируемый опыт, зависят от цели проекта. Найдите очевидные моменты начала и окончания и немного отступите от них, чтобы проверить, нет ли ещё важных шагов;
— Состав информации на карте (слои) тоже зависит от целей проекта и должен помогать фокусироваться на главном;
— Процесс картирования: Инициирование → Исследование → Визуализация → Синхронизация (ключевой этап);
— Процесс несколько сместился от создания документа отчётности к созданию практического инструмента. Главным стал не итог, а путь к нему. Авторы карты превращаются в своего рода координаторов, а карта — в трамплин для коллективного осмысления пользовательского опыта (Джим Калбах);
— Поэтому важно правильно инициировать: определить участников, продать им эту активность, спланировать работу до, во время и после воркшопа;
— При визуализации не сковывайте себя типовыми шаблонами, при необходимости меняйте их под себя, а также упрощайте (избегайте больших текстов, визуального шума), выделяйте важное, устраняйте двусмысленность, группируйте всё, что связано;
— Ещё Илона рассмотрела разные виды карт: Service Blueprint, User Experience Map, User Stories Map, Empathy Map.

Смотрите также: первая статья серии, вторая, статья Андрея Шапиро о CJM и SB.

Салли Коллинз написала о популярных ошибках на главных страницах интернет-магазинов.

— Показана лишь малая часть из категорий товаров, предлагаемых магазином (менее 40%). Пользователи неверно понимают его специализацию и недооценивают широту ассортимента;
— Агрессивная и отвлекающая реклама. Вызывает негативную реакцию, затрудняет переход к оценке ассортимента (особенно на мобильных), пользователи могут решить, что попали не туда;
— Карусель работает неправильно. Например, меняет слайд за мгновение до того, как пользователь на него нажимает. Есть статья Baymard Institute о том, как правильно. Хорошая альтернатива — распределить по странице секции со статичным содержимым и избранными категориями;
— Не представлены популярные категории и подкатегории. Пользователи не могут быстро перейти к релевантной подборке товаров или переходят в нерелевантные и не находят нужных товаров. Хороший инструмент для магазина игрушек или подарков — визард;
— Скучные фото товаров без контекста, например, без демонстрирующих одежду моделей или играющих с игрушками детей;
— Поле поиска не отображается или малозаметно;
— Всплывающее окно выбора языка малозаметно или похоже на рекламу, предложение пройти опрос или подписаться на рассылку. Хороший вариант — автоматически определять страны пользователей по IP-адресам.

Перевод местами странный, лучше читать in English.

Ребекка Картер поделилась рекомендациями по созданию страницы «О компании».

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

In English.

Леонид Межевых, Полина Адрианова и Анастасия Батпаева поделились советами начинающим UX-исследователям.

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

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

— Если пользователь ввёл адрес электронной почты, но не смог авторизоваться (ввёл неверный пароль), подставляйте введённый ранее адрес в форму восстановления пароля. Например, так делает Booking;
— Если в мобильной версии сайта в поле надо вводить только цифры (например, код подтверждения), укажите для этого поля свойство inputmode=numeric, чтобы пользователю отображалась цифровая клавиатура;
— В тултипе к иконке пишите, что пользователь может сделать, нажав на неё. Например, на Booking у колокольчика тултип «View your notifications», у помощи — «Contact Customer Service», у флага — «Choose your language». А вот на Etsy у колокольчика тултип просто «Updates».