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

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

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

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

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

Кирилл Егерев, автор канала @txtin, написал книгу «Этой кнопке нужен текст» о том, как 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/

Юрий и Александра Клименко сделали симулятор переговоров и урегулирования конфликтных ситуаций. Полезная штука, если вы взаимодействуете с другими людьми и защищаете свои решения на работе.

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

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

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

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

Комментируя, можно заработать баллы, в обмен на которые ваши ответы прокомментируют Юрий или Александра.

В описании сказано, что симулятор рассчитан на 100 часов прохождения. Это похоже на правду. Я заканчиваю 2-й модуль из 10, прошло уже часа 3, и я ещё плохо различаю псевдоэмоциональный и псевдорациональный тип конфликта (видимо, придётся перечитать теорию). Не уверен, плюс это или минус, но это стоит учесть.

Промокод uxnotes до 31 марта даёт скидку 2000 рублей. Первый модуль доступен бесплатно: https://simulator.skillslab.center/landing

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

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.

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

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

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

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

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

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

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

https://skillsetter.io/blog/how-to-push-notification

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

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

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

Банк ВТБ ищет героев для создания сервисов, которыми будут пользоваться миллионы людей!

Программа ВТБ «600 дней» продолжается. Цифровизация клиентского опыта и ускоренное развитие продуктов идут полным ходом, над этим трудится уже более 200 кросс-функциональных команд. Но ВТБ нужны ещё герои, которые будут создавать продукты и сервисы нового поколения для миллионов людей! Никаких длительных согласований — ответственность за продукт перед клиентом и руководством полностью несут команда и её лидер. Дебюрократизация процессов позволяет реализовывать смелые проекты в кратчайшие сроки! Классный коллектив и отличные условия гарантированы.

Сейчас ВТБ ищет:

UI/UX-дизайнер

— Вы будете разрабатывать интерфейсы;
— создавать: скетчи, макеты, интерактивные прототипы с учетом целей бизнеса и пользователей (Sketch/Figma/Invision/Marvel/Zeplin);
— сотрудничать с графическими дизайнерами при подготовке визуального интерфейса и с разработчиками для повышения качества UX;
— проводить качественные и количественные исследования;
— анализировать разработанные продукты/сервисы и мониторить результаты с точки зрения удобства использования.

Оставляйте отклик по ссылке!

Публикация оплачена

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

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

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

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

https://vc.ru/design/219560

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

— Если человеку не важно знать, что есть какое-то недоступное ему действие, заблокированную кнопку лучше скрыть. Например, кнопку добавления комментария, если комментирование пользователю недоступно;
— Добавьте объяснение, почему действие недоступно (рядом или во всплывающей подсказке);
— Если условия, при которых кнопка окажется заблокированной, маловероятны, можно её не блокировать и показывать сообщение об ошибке при необходимости.

https://ux.pub/reshenie-problem-neaktivnyh-knopok/

Мариана Варгас привела примеры тёмных паттернов из популярных сервисов.

1. Замаскированная реклама — имитирует контент или навигацию. Например: реклама в ленте Ютуба, похожая на видео;
2. Тараканья ловушка — упрощение попадания в определённую ситуацию и затруднение выхода из неё. Например: создание и удаление профиля в Спотифае и Инстаграме;
3. Заманить и подменить — пользователь хочет сделать одно, но вместо этого делает что-то другое. Например: в ленте Реддита нажатие на картинку в рекламном посте открывает рекламируемый сайт, а не увеличивает картинку, как обычно;
4. Принудительное продолжение — списание денег с карты без предупреждений после окончания пробного периода. Например: Skillshare;
5. Подтверждение с укором — пользователя стыдят за выбор, который он собирается сделать. Например: подтверждение отключения уведомлений в Wish;
6. Предотвращение сравнения цен. Например: в АлиЭкспрессе конкретные цены видны в результатах поиска, а в карточке товара отображается ценовой диапазон. Чтобы узнать цену, надо выбрать количество, цвет и способ доставки;
7. Скрытые затраты — неожиданное увеличение цены на последнем этапе оформления заказа из-за налогов, доставки и прочего. Например: broadway.com.

https://habr.com/ru/company/alconost/blog/548600/

Пора начинать в этом разбираться, так как рано или поздно такие приёмы запретят на законодательном уровне: https://vc.ru/design/221548

Кирилл Шерстобитов написал о тестировании User Flow продукта.

Если продукт уже работает:

— Можно дать респондентам задание и по итогам прохождения задать вопросы из анкеты оценки юзабилити (System Usability Scale). Полезно таким же способом проверить конкурентов и сравнить результаты. Опрос даёт количественные оценки и прямую речь респондентов;
— Провести удалённое немодерируемое тестирование. Респонденты выполняют задание под запись экрана, а потом дают обратную связь. Тестирование помогает увидеть, с какими проблемами сталкиваются люди, но не позволяет уточнить у них непонятные моменты;
— Провести модерируемое тестирование. Интервьюер очно или удалённо наблюдает за респондентом и может задать уточняющие вопросы. Более трудоёмкий способ, требующий определённой квалификации.

Если продукт ещё в разработке, для каждого шага сценария можно провести First Click Test: показать дизайн или эскизы респондентам, дать задание и посмотреть, куда они нажмут. Тест даёт количественные данные, можно понять, какой шаг вызывает затруднения.

https://vc.ru/design/200804