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

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

#client

Виктория Друзенко написала о прокачке UI.

— Навыки UI-дизайна могут просесть, если долго работать с дизайн-системой на одном продукте;
— UI Daily может не подойти, так как макеты там оторваны от контекста, и надо тратить время на его додумывание;
— Переделывайте макеты из своих старых проектов. Подойдут даже макеты с предыдущего спринта;
— Так вы увидите свой прогресс, можете пересмотреть решения и улучшить UX, не будет ограничений со стороны заказчиков и разработки, а результат можно положить в портфолио;
— Анализируйте чужой дизайн, выделяя удачные и неудачные решения, предлагайте альтернативы;
— Публикуйте свои наблюдения там, где другие дизайнеры могут их увидеть и обсудить, это даст обратную связь;
— Так вы научитесь давать обратную связь, прокачаете насмотренность;
— Вовлекайте коллег, знакомых дизайнеров, менторов;
— Помимо того, что так веселее, будет больше обратной связи, можно перенять чужой опыт, сложнее слиться с прокачки;
— Перерисовывайте понравившиеся макеты;
— Так ваша база UI-решений будет расти. Вы будете не только знать разные визуальные ходы, но и уметь их воспроизвести;
— Можно попробовать новые инструменты для оптимизации работы. Если надо перерисовать экран, стоит подумать, как сделать это быстрее и качественнее.

#visual #upskilling

Женя Белодед поделился процессом и находками из исследования касс самообслуживания.

— Для сокращения воровства в «Пятёрочке» касса выводит изображение со своей камеры прямо в интерфейс и так показывает, что за покупателем наблюдают;
— Удобно, когда кнопки «Каталог», «Пакеты» и «Позвать на помощь» доступны всегда. В любой момент можно взять пакет, если не рассчитал вместимость рюкзака, и позвать консультанта, если возникли вопросы;
— С верхней частью экрана взаимодействовать неудобно. Все важные элементы лучше размещать в нижней, а список товаров формировать снизу вверх;
— Длинный список товаров должен прокручиваться автоматически, чтобы последние отсканированные позиции были видны сразу;
— Большой экран устройства скорее усложняет использование, надо искать способы оптимизации «пробега» пальца и глаза;
— Обозначение товаров 18+ и 16+ в списке помогает консультантам быстрее в нём ориентироваться, когда надо подтвердить возраст покупателя;
— Компактнее и удобнее объединять одинаковые товары в одну строку, указывая количество штук;
— Если показывать старую и новую цену для товаров со скидкой и акционных, экономия станет наглядной, снизится стресс от покупки;
— В сложных ситуациях помогают интерфейсные подсказки о действиях пользователя в кассе и вне её;
— Как справляться с косыми взглядами охранников: «Придумал историю, что возрастная мама хотела бы начать пользоваться кассой самообслуживания, но боится, что не разберётся и будет выглядеть глупо. Поэтому попросила сына записать видеоинструкцию, чтобы разобраться дома. С такой легендой охранники были спокойны, а консультанты без проблем всё показывали и комментировали прямо на камеру».

Копия на Хабре. #retail #self_checkout

Юрий Герыш написал о работе с Chrome DevTools.

— Открыть их можно через меню (пункт «Инструменты разработчика») или нажав правой кнопкой мыши в любом месте страницы (пункт «Просмотр кода страницы»);
— Экспорт изображений в формате SVG: скопируйте содержимое тега <noscript> из кода страницы и вставьте в Фигму;
— Если картинка в формате PNG, можно поискать её SVG-версию на сайте: добавьте к адресу картинки «?noscript», например: «https://habr.com/img/habr-logo-ru.png?noscript»;
— Меняя код CSS (вкладка Styles), можно быстро прикидывать стилевые правки;
— В Styles можно видеть и менять правила, определяющие внешний вид страницы;
— На вкладке Computed отображаются текущие свойства выбранного элемента, которые получились после применения всех правил. Например, сколько в пикселях составила ширина, которую задали в процентах;
— Меняя HTML, можно править текст, дублировать и удалять элементы;
— Так можно проверить поведение элементов в корнер-кейсах. Например, что будет, если название слишком длинное;
— Просмотр адаптивных состояний: можно задать размер окна браузера. Есть пресеты размеров популярных устройств;
— Чтобы выбирать Инспектором элементы, свёрстанные с помощью Shadow DOM (изолирование стилей элемента), включите в настройках «Show user agent shadow DOM»;
— Просмотр состояний элементов (hover, active): список состояний отображается на вкладке Styles с нажатым «:hov», либо можно выделить элемент через Инспектор и в контекстном меню нажать «Force state».

#review #chrome_devtools

Антон из X5 Tech написал о скелетонах.

— Это такая загрузка экрана, когда сначала отображаются серые прямоугольники, а потом вместо них появляется контент;
— Их важно анимировать, чтобы всё это не было похоже на баг;
— Прижилась пульсация (мерцание) и волна (единое для всех блоков смещение градиента, background: fixed);
— Плюс скелетона в предварительном представлении структуры экрана и возможности отображать контент по мере его загрузки;
— Каждый прямоугольник скелетона — обёртка для контента и заглушка на время загрузки;
— Но что должно быть внутри обёртки: атом, молекула или организм в терминах атомарного дизайна?
— Отдельными блоками скелетона может быть то, что запрашивается с сервера отдельными запросами;
— Скелетировать можно всю страницу (высоконагруженные проекты, у значимой доли пользователей плохой интернет), её части (тяжёлые блоки с таблицами, статистикой) или отдельные элементы (результат множества запросов, сложного вычисления и так далее);
— Будьте последовательны. Если где-то есть скелетоны, спиннеры в раскрывающихся списках смотрятся странно;
— Заглушки должны соответствовать размеру контента (в первую очередь высоте), чтобы при загрузке ничего не скакало, а также его внешнему виду, чтобы не сильно контрастировать с контентом;
— Если в карточках может быть разный состав контента, ради простоты можно сделать для всех карточек одну усреднённую заглушку;
— Высокая детализация требует затрат, которые не всегда оправданы. Например, вкладки могут быть одним прямоугольником. Обычно это один компонент на странице, его заглушка воспринимается как заголовок, да и показывать заглушки отдельных табов непросто;
— Но иногда повышение детализации имеет смысл и помогает сразу привлечь внимание к определённой части страницы;
— Повторяющиеся элементы вроде ячеек с текстом в таблице можно скелетировать красиво, сделав заглушки разной ширины (90, 75, 85, 80, 65% от ширины ячейки) и сохранив выравнивание.

#loader

Энтони Ценг написал о сегментированных переключателях в формах.

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

In English. #chips #toggle #segmented_control

Карен Ананян написал о подходе Stretch, Scale, Switch при проектировании адаптивных состояний.

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

#adaptive

С прошлого анонса в @uxwork кроме вакансий вышли ещё материалы:

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

Светлана Юдина написала о Product score — комплексной оценке UX и UI в продуктах.

— Продакты мыслят цифрами, поэтому UX-проблемы часто ускользают из их поля зрения;
— Product score даёт числовую оценку качества пользовательского опыта;
— В Сравни этим проактивно, без запросов от продуктовых команд, занимается внутренняя UX-лаборатория;
— Периодическая оценка позволяет отслеживать изменения в продукте, сравнить продукты между собой и находить конкретные места для улучшения;
— UX оценивают с респондентами (по 6 на сегмент), которые на проде со своими реальными данными проходят полный флоу оформления покупки или использования услуги;
— Исследователь вмешивается только если респондент зашёл в тупик, чтобы посмотреть весь флоу;
— Он фиксирует количество пройденных этапов и места, где респондент споткнулся, а также оценивает критичность этих проблем: низкая, средняя, высокая;
— В конце респондент по 5-бальной шкале оценивает удобство сервиса и скорость прохождения сценария;
— Всё это складывается в оценку UX от 0 до 100% (хитрые формулы смотрите в статье);
— Дизайнер из другой команды с чеклистом по 5-бальной шкале оценивает UI по параметрам: понятность и логичность, типографика и текст, анимация, графика, консистентность;
— Он может также предложить рекомендации по улучшению UI;
— Оценка UX оставляет 75% от итоговой, оценка UI — 25%;
— Product score и рекомендации передают команде, бизнес-оунерам и партнёрам, так как часть флоу иногда проходит в интерфейсах партнёров.

#metrics

Егор Камелев написал об автофокусе на первом поле формы.

— Автоматически помещать фокус на первом поле формы рекомендуют, чтобы открывший её пользователь сразу, без лишних действий, смог ввести данные;
— Это хорошее базовое правило, которое можно применять по умолчанию. При этом не стоит забывать о нюансах, из-за которых от него стоит отступить;
— Если форма — не единственное содержимое страницы и находится где-то внизу, автофокус прокрутит страницу к форме и помешает изучить страницу;
— В мобайле автофокус приведёт к появлению экранной клавиатуры, что затруднит ознакомление с формой в целом;
— Бывают формы, которые часть пользователей может заполнять не с первого поля;
— Либо этому первому полю может предшествовать информация о регионе с контролом его изменения. И это изменение значительно меняет форму.

#form

Дмитрий Сергушкин написал, как сделать таблицы удобнее.

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

In English. #table

Станислав Хрусталёв прошёлся по ошибкам в отображении рейтинга товаров. Я переформулировал их в рекомендации.

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

#rating #ecommerce

Бо Кибза и Лёха Макаренко (дизайнеры дизайн-систем Альфа-Банка, Озона, Самоката и Почтатеха) рассказали о развитии системы цветов в ДС Туту.

— Легаси-ДС не дорабатывали, чтобы нигде ничего не отвалилось. Команды с большой автономностью локально допиливали компоненты под свои нужды;
— Хотели консистентности, единых стандартов и при этом пространства для свободы;
— Одним из требований к системе цветов была отзывчивость к изменениям, так как компания ребрендилась;
— В этом случае, если минимизировать возможность кастома, бардак накопится не в продукте, а в ДС, где его проще прибрать;
— Обычно делают слои токенов: палитра → семантика (подложки, обводки, текст) → компоненты (текст на кнопке);
— Ради скорости дизайна и разработки компонентов отказались от семантического слоя. Условие: не использовать цвета палитры напрямую, не оверрайдить цвета в покрашенных компонентах;
— Подход даёт очень много компонентных переменных, а также много мелких разночтений (вроде немного отличающихся подложек в чипе и лейбле);
— Зато дизайнеры успели попробовать компоненты в макетах и понять, что нужно единое решение для контрастных элементов и компоновки On white / On gray;
— On white больше подходит для коммуникационных экранов, On gray — для более интерфейсных, с формами и карточками;
— On gray экраны нельзя просто перевести в тёмную тему — бекграунд светится ярче, чем форграунд, и в интерфейсе появляются дыры;
— Можно завести в светлой теме 2 background и 2 panel цвета, которые в тёмной теме станут 1 background и 1 panel. Но как объяснить дизайнерам, какой из 2 цветов использовать?
— В итоге завели мод для переключения On white / On gray, и в светлой теме оставили 1 background и 1 panel;
— Мод On gray кроме цвета подложки может устанавливать, например, более тёмный цвет текста, чтобы сохранять контраст на более тёмном фоне;
— Также через мод Contrast (low, high) реализовали возможность делать отдельные элементы более контрастными;
— Таким образом, семантика построена на основе конкретных продуктовых запросов;
— Палитру всегда можно доделать потом;
— Удобно, когда семантические цвета в палитре находятся на одном уровне: можно сразу увидеть ошибку и в целом запомнить, что цвет текста — это 500;
— Также удобно иметь отдельную палитру для тёмной темы с интерпретированными цветами (можно оставить только те, что точно используются).

#color #design_system

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

— Когда человек заводит электронную почту, его имя пользователя и домен почтового сервиса становятся уникальным адресом;
— Но его не обязательно указывать в точности, чтобы получать письма;
— Все почтовые сервисы игнорируют регистр букв. Gmail — точки в имени пользователя. Почти все игнорируют то, что в имени пользователя указано после «+»;
— Фишка с «+» описана в одном из стандартов работы электронной почты и может использоваться для борьбы со спамом и сортировки почты;
— Плюс тестировщики могут так зарегистрировать несколько аккаунтов в тестируемых продуктах, не заводя множества почтовых ящиков;
— Некоторые почтовики работают на нескольких доменах. Например, gmail.com и googlemail.com, yandex.ru и ya.ru;
— По хорошему, сделав исключение для тестировщиков, всё это стоит учитывать при регистрации, входе и восстановлении пароля (в статье в общих чертах описан механизм), чтобы пользователи не создавали несколько аккаунтов, фактически связанных с одним ящиком;
— Пользователь может забыть, с каким адресом регистрировался ранее, и по ошибке завести ещё один аккаунт;
— Если посмотреть на крупные и популярные сервисы вроде ChatGPT, Notion, Amazon, они отрабатывают только кейс с регистром букв.

#login #signup

Новые материалы в @uxwork (кроме вакансий):

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

Геннадий Мохов написал о регламентах в работе дизайн-команды.

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

#management

Анна Малинина написала об обработке ошибок при заполнении форм.

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

#form #error

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

— 33% дизайнеров утверждают, что встречи и переписки мешают сосредоточиться. Это не зависит от размера компании. Проблема не в коммуникации как таковой, а в её хаотичности;
— Задавайте правила общения. Даже простое «Если комментарий неясен — обсуждаем голосом» сделает процесс понятнее и снизит напряжение;
— Дизайнерам сложнее общаться не с разработчиками (как многие считают), а со стейкхолдерами и маркетингом. Для взаимодействия с разработчиками есть отлаженные ритуалы, помогающие налаживать контакт;
— Дизайнеры реже чувствуют перегрузку в больших командах, возможно, потому что у них чаще встречаются понятные процессы, чёткое разделение ролей и поддерживающая инфраструктура;
— 58% опрошенных не видят возможностей для карьерного роста. 81% называют нехватку обратной связи от руководства одним из главных препятствий для роста;
— Проводите сессии обратной связи, разрабатывайте понятные карьерные треки (включая горизонтальный, экспертный рост) и вовлекайте дизайнеров в работу над задачами, связанными с бизнес-целями;
— Главные причины выгорания: нереалистичные дедлайны, размытые ожидания и зоны ответственности, конфликты. Йога и психолог помогают справляться со стрессом, а не бороться с его причинами;
— Руководителям следует инвестировать в прозрачное планирование и адекватную оценку сроков;
— Вместо общих курсов по дизайну есть запрос на специализированные и глубокие форматы: разборы реальных задач, рабочих процессов, фидбек;
— 77% не видят в ИИ прямой угрозы для своей карьеры. При этом 49% ощутили его влияние и активно внедряют в процессы;
— Поиск работы стал дольше, но в России он занимает не так много времени, возможно, из-за более коротких процессов найма;
— Только 9% дизайнеров считают, что при поиске работы получили обратную связь в достаточном объёме. Недостаточная обратная связь или её отсутствие ухудшают мнение соискателей о работодателе.

#management

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

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

#industrial #research

Александр Горчаков поделил команды на 4 типа по уровню стабильности и вызовов и написал, что делать лидерам таких команд.

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

#management

Борис Юзефпольский поделился лайфхаками, как провести интервью и восстановиться после.

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

#research #interview