Станислав Хрусталёв написал об ошибках при сборе обратной связи. Некоторые из них:

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

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

Переход к опросу:
— Срок действия приглашения ограничен;
— Терминал для оценки находится рядом со специалистом, которого надо оценить.

Прохождение опроса:
— Опрос собирает контактные данные. Это значит, что он не персонализирован;
— На уточняющий вопрос можно ответить только в свободной форме. Узнавая о причине негатива, выделите ключевые факторы и добавьте поле для свободного ввода;
— Все вопросы обязательные. Если клиент не захочет отвечать на конкретный вопрос, он закроет опрос;
— Не используется ветвление. Если клиент в первом ответе низко оценил сервис, на втором вопросе можно написать «Очень сожалеем, что огорчили вас. Что мы могли бы исправить?».

https://hardclient.com/feedback-acquisition-pitfalls

Марк Херст написал о тёмных паттернах и «возрождении» UX-дизайна.

Если до 2018 года UX-дизайн терял влияние, то потом он полностью изменился. Сейчас пользовательскому опыту можно дать новое определение — эксплуатация пользователей.

Например: отписка от Amazon Prime. То, что должно быть одной страницей с кнопкой «Отменить подписку», стало шестью страницами с тёмными паттернами, которые вводят пользователей в заблуждение и отвлекают.

В Amazon есть хороший UX-отдел, который обманывает, эксплуатирует и вредит клиентам. UX-дизайн полностью изменился: ранее он защищал интересы пользователя, а теперь работает против него.

Такое «возрождение» дорого обошлось: превратило дизайн во вредную сферу и привело к оттоку хороших специалистов. Как следствие, например, во время крупнейшего кризиса здравоохранения Нью-Йорк не может создать понятный сайт о вакцинах.

https://vc.ru/design/202669

Clo S написал о вреде бесполезных уведомлений и как их сделать полезнее.

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

https://ux.pub/kak-sozdat-produmannyy-dizayn-push-uvedomleniya/

Джозеф Мюллер написал о проблемах вложенных модальных окон.

Модальное окно закрывает основное содержимое экрана, пока пользователь не выполнит в этом окне действия. Вложенное модальное окно появляется, когда два модальных окна накладываются друг на друга.

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

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

— Перевод (не работают анимации с вайрфреймами решений): https://ux.pub/problema-vlozhennyh-modalnyh-okon-v-tsifrovyh-produktah/
— Оригинал [English]: https://uxplanet.org/6762351cf6de

Сергей Алексеев написал о пользовательском тестировании ещё не работающего голосового интерфейса.

Подход «Волшебник страны Оз»: кто-то из исследователей становится «волшебником», который выступает в роли голосового помощника или запускает аудиофайлы в ответ на запросы пользователя.

Волшебником может быть и сам респондент. Это позволит узнать наиболее релевантные для него ответы продукта.

Избегайте слов-подсказок в заданиях вроде «Попросите голосового помощника включить фильм „Любовь и голуби“». Скорее всего, респондент так и скажет «Включи фильм „Любовь и голуби“», и вы ничего нового не узнаете.

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

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

https://vc.ru/design/198986

Кейт Моран из Nielsen Norman Group написала о тестировании контента.

«Сценарий, который вы даёте людям, должен соответствовать проблеме, которую они должны решить в реальной жизни. В отличие от исследований, ориентированных на пользовательский интерфейс, исследования, ориентированные на контент, не должны просить участников тестирования «притворяться» или «представлять», что они находятся в той или иной ситуации.

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

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

https://teletype.in/@marfitsin/content-research

Кирилл Егерев написал книгу «Этой кнопке нужен текст» о том, как UX-писатели работают в продуктовых командах и как писать понятный и не раздражающий интерфейсный текст.

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

Особенности работы:
— UX-писатель может общаться с командой целый день и написать всего две строчки или оставить текст без изменений. Видна лишь малая часть его работы, как айсберг;
— Иногда итоговый макет со всеми подсказками становится громоздким. Проблема в том, что исходный вариант был слишком выхолощенным и не учитывал проработанных UX-писателем ситуаций;
— Это нормально — написать для новой фичи не только интерфейсный текст, но и минимальный набор промо вроде пуш-уведомления, письма с анонсом, описания обновления для магазина приложений. Никто лучше UX-писателя о фиче не расскажет.

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

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

— Книга: https://www.alpinabook.ru/catalog/book-684019/
— Больше тезисов и цитаты: https://vandergrav.ru/this-button-needs-text/

Опубликовал конспект курса «Типографика и вёрстка» Игоря Штанга, который прошёл в 2016 году в Санкт-Петербурге:

1. Бегство от «серого прямоугольника» — текста произвольного размера, который прислал заказчик. Он не похож на дизайн. Игорь предложил 6 приёмов, как превратить серый прямоугольник во что-то, похожее на дизайн.
https://vandergrav.ru/typeschool-1/

2. Конструкция — пространственное отношение элементов, текстовый скелет макета. Не путаем её с сеткой (это лишь один из инструментов) и композицией (это ещё и цвет с фактурой). Статья о создании конструкции.
https://vandergrav.ru/typeschool-2/

3. Выключка, абзац, заголовок, отступ — о разных вариантах выравнивания текста, вёрстке абзацев и заголовков.
https://vandergrav.ru/typeschool-3/

4. Список, таблица, иллюстрация, линейка — о вёрстке списков, таблиц и иллюстраций, а также использовании в макете линеек, рамок и плашек.
https://vandergrav.ru/typeschool-4/

5. Дополнительные материалы — рекомендации книг, ссылки на статьи, коллекции и инструменты.
https://vandergrav.ru/typeschool-5/

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

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

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

Опубликовал конспект доклада Ильи Бирмана «Фак юикс» с Дизайн-просмотра 2020 года.

«Главная беда: исследованиями подменяют экспертизу.

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

Это очевидное решение. Уже 30 лет известно, что никто не нажимает на эти знаки вопроса. Люди проводят такие исследования, потому что некомпетентны. Предполагается, что специалисты чему-то учатся, у них есть опыт, и им не нужно тестировать все свои решения».

https://vandergrav.ru/ilya-birman-about-ux-design/

Дейв Акин сформулировал законы проектирования космических кораблей. Некоторые из них:

3. Проектирование — итеративный процесс. Необходимое количество итераций всегда на единицу больше, чем то, которое вы сделали в данный момент. Это верно в любой момент времени.

4. Ваши лучшие конструкторские разработки неизбежно окажутся невостребованными в итоговом проекте. Научитесь жить с разочарованием.

12. Не существует единственно правильного решения. Но всегда есть несколько неправильных.

13. Проектирование основано на технических требованиях. Нет никаких оснований делать что-то хоть немного «лучше», чем предписывают эти требования.

15. (Закон Ши) Талант к конструктивным улучшениям проявляется в первую очередь в интерфейсах. И это также лучшее место для того, чтобы всё испортить.

16. У людей, которые проводили аналогичные исследования до вас, не было прямого доступа к извечной мудрости. Следовательно, нет никаких оснований доверять их расчётам больше, чем своим. И в особенности нет никаких оснований представлять их как свои.

20. Плохой проект при хорошей подаче в конце концов обречён. Хороший проект при плохой подаче — обречён сразу.

31. (Закон эволюционного развития Мо) Вы не сможете добраться до Луны, взбираясь на всё более высокие деревья.

36. Любой рядовой инженер может спроектировать что-то изящное. Хороший инженер проектирует работоспособные системы. Опытный инженер — эффективные.

38. Возможности определяют технические требования, независимо от того, что говорится в учебниках по системной инженерии.

41. (Закон Макбрайана) Вы не сможете сделать лучше, пока не сделаете, чтобы работало.

https://zamesin.me/akins-laws-of-spacecraft-design/

Шейла Шейх и Кирилл Улитин написали о новой панели инструментов в редакторе документов МойОфис.

В прошлой версии инструменты были сгруппированы по вкладкам, которые отображались в зависимости от контекста. Если пользователь редактировал текст в таблице, появлялись вкладки «Текст» и «Таблица». Изменение цвета заливки ячейки и цвета текста было на разных вкладках, что плохо, так как пользователи часто меняют эти цвета вместе.

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

Тестирование «риббона» показало, что чем больше вкладок, тем больше времени человек тратит на их перебор, если не может найти нужную кнопку.

Интересно, что некоторые участники теста говорили о том, что им нравятся вкладки. Тестирование было модерируемым, и мы смогли выяснить основную причину такого заключения: пользователям нравится группировка кнопок, при этом необходимость переключения они всё же рассматривали как недостаток».

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

Ещё интересно, что все свойства панели собраны в Airtable и могут быть экспортированы в XML. Дизайнеры правят конфигурацию панели инструментов независимо от разработки, и корректировки автоматически применяются при сборке продукта. Это позволило удешевить процесс внесения изменений и исключить человеческий фактор.

https://habr.com/ru/company/ncloudtech/blog/541970/

В лаборатории дизайна Pragmatica запустили новую рубрику видеоблога — «Артефакты». Минус: срачи, хейт и оружие второго удара. Плюс: темы, которые формируют насмотренность, кругозор и креативность дизайнеров.

Уже есть 3 выпуска:

1. Дизайн в Российской империи, музей дизайна в Хельсинки (Финляндия), премии в целом и премия D&AD, виниловые пластинки
youtube.com/watch?v=DXuMMWXAwxc

2. Итоги 2020 года (важность шрифта и «Доброшрифт», скорость создания сайтов, национальный флаг РБ), тренды на будущий год, артефакты из бананового бункера, пост-интернет искусство Кати Новиковой, концепция и дизайн iMac G4, история Snapchat
youtube.com/watch?v=W61iC5OuIUk

3. Приложение «Помощь» Никиты Кукушкина, ажиотаж вокруг Clubhouse, выставки самоизоляции, Malofiej Awards, цифровые образы Данилы Криворучко, соковыжималка Филипа Старка
youtube.com/watch?v=2B7lqEXSjGM

Сделал конспект книги Майкла Джанда «Сожги своё портфолио» о самоорганизации и работе с клиентами.

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

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

https://vandergrav.ru/burn-your-portfolio-book-summary/

Пранава Тандра написала об автоматических подсказках в полях поиска.

8 тезисов с примерами из реальных продуктов.

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

[English] https://blog.prototypr.io/9c3394774519

Заметка подготовлена совместно с @vanillatime.

Ира Моторина написала, как планировать и писать пуш-уведомления.

Это агрессивный формат коммуникации. Чтобы пуши не раздражали, они должны приходить не слишком часто и быть полезными. Если приложение при установке обещает «приятные новости по заказам и скидкам», нельзя потом заваливать пользователя нерелевантными скидками.

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

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

Если пользователь не выполняет целевое действие и не реагирует на уведомления, можно написать, что больше не будете их отправлять (Duolingo).

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

Если приложение работает на старых телефонах, текст уведомления лучше уместить в 40 символов. Если работает только на новых, можно использовать 120.

#writing #push

Вадим Митякин опубликовал 6-ю главу книги «Метод параноика». Глава посвящена принципу динамических команд.

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

https://paranoidmethod.org/paranoid-method-book-06

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

https://www.youtube.com/watch?v=82AoEza1EvU

В KISLOROD написали о навигации в мобильной версии интернет-магазина:

— В шапке обычно размещают логотип и ссылки на избранное, сравнение, корзину и личный кабинет;
— Меню можно закрепить у нижней грани экрана (Ozon);
— Показывайте товарные категории на главной странице (Audiomania). Если их много, покажите 30−40% основных категорий;
— Дайте возможность искать по темам, например, «зимняя куртка», «подарок к 8 марта»;
— Не скрывайте хлебные крошки, но не занимайте ими больше одной строки. В них может быть ссылка на родительскую категорию (Ozon) или ссылки на всю цепочку вышележащих категорий (Mvideo). Во втором случае будет горизонтальная прокрутка;
— Для просмотра категорий каталога можно использовать аккордеон (Lamoda), последовательное меню (Letoflowers) и их комбинацию (Mvideo);
— В последовательном меню отображайте текущее положение пользователя, давайте не только перейти в подраздел, но и посмотреть общий список товаров раздела;
— Показывайте дополнительные, совместимые и альтернативные товары (Eldorado). На мобильном устройстве поиск товаров, совместимых с тем, что у пользователя уже есть, ещё сложнее;
— Дублируйте навигацию в подвале;
— Показывайте в правом нижнем углу кнопку возвращения в начало страницы.

https://vc.ru/design/219560