Саша Окунев рассказал об опыте слияния дизайн-систем в Озоне.

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

Также Саша рекомендовал посмотреть сначала 20-минутную лекцию Александра Дьякова о дизайн-системе: что это, какие задачи решает, из чего состоит и как выглядит.

Антон Жиянов написал, что должно быть в сообщении о заказе от интернет-магазина.

— Напишите: «Приняли заказ №12345, стоимость 5623 ₽, доставим в пятницу 16 июля с 10 до 14»;
— Если ваши айти-системы умеют идентифицировать заказ по номеру телефона, номер заказа можно не писать. Но может возникнуть путаница, если у клиента несколько заказов одним днём;
— Добавьте телефон, чтобы человек не искал, как с вами связаться;
— Если есть ограничения по оплате, напишите: «Оплата только наличными, у курьера нет сдачи» или «Заказ оплачен, вот чек»;
— Такой формат подходит для письма и смс. В письмо можно добавить подробностей: список товаров, как изменить время или отменить заказ, особенности (курьер звонит за час, доставка до двери);
— Адрес доставки имеет смысл указывать, если у клиента их несколько. ФИО, телефон, электронную почту — если заказ для другого человека.

#email #ecommerce

Владимир Меркушев написал вводную статью об а/б-тестировании.

— Суть в том, чтобы разделить аудиторию на части, показать им разные версии чего-либо и понять (на основе количественных данных), какая версия лучше;
— Протестировать можно, например, как разные призывы к действию влияют на конверсию, а также более долгосрочные метрики вроде среднего чека или прибыли;
— Тест лучше проводить с контрольной выборкой: для проверки 2 вариантов аудиторию делят на 3 группы, и двум из них показывают один и тот же вариант. Если метрики у этих двух групп не будут отличаться, значит, внешние факторы на результат не повлияли, и данным можно доверять;
— Если вариантов больше двух, можно провести мультивариантное тестирование. Так удобно тестировать комбинации вариантов, например, 4 призыва к действию и 2 цвета кнопки (будет тест с 8 вариантами);
— Стоит тестировать не только первое целевое действие (например, количество нажатий на кнопку), но и дальнейшее поведение пользователя (например, показатель отказов на открывшейся странице или конверсию в покупку);
— Не смешивайте выборки параллельно идущих тестов, так как варианты из одного теста могут влиять на восприятие вариантов из других тестов. Например, не стоит на главной странице одновременно тестировать кнопки меню и текст призыва к действию;
— А/б-тестирование скорее всего не подойдёт для B2B, B2G, премиального сегмента и продукта на старте, когда у него мало трафика;
— Калькуляторы для расчёта показателя статистической значимости обычно интегрированы в системы настройки тестов.

#ab_testing

Опубликованы видео с Fintech Design Conf 2021:

1. Бренд- и дизайн-команда Райффайзенбанка — Что сделали за год

2. МТС Банк — Особенности дизайна виртуальной карты

3. Хайс — Подход к дизайну и выпуску продуктов

4. Ак Барс Банк — Внедрение автоматизированных рабочих мест собственной разработки

5. ВТБ — Консистентность пользовательского опыта при большом количестве распределённых команд

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

7. ONY и Бланк — Идея, брендинг и стиль

8. Тинькофф — Разработка нового интерфейса банкоматов

9. Дизайн-команда Росбанка — Эволюция команды и превращение в отдельную часть компании

Все видео одном плейлисте: YouTube · ВК.

Максим Козлов написал об организации UX-исследований. О пользе вовлечения команды:

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

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

#research

Настя Овсянникова написала серию статей об отображении ошибок в интерфейсе.

— С точки зрения взаимодействия между пользователем, клиентом и сервером можно выделить виды ошибок: а) Сбой клиента; б) Результат валидации данных на клиенте и сервере; б) Результат обработки данных и команд; в) Потеря связи с сервером;
— Потеря связи с сервером происходит, если пропал интернет, проблемы с VPN, сервер упал или от него вообще нет ответа;
— Обстоятельства, при которых обнаруживаются ошибки: а) Приём данных от пользователя; б) Скачивание или подгрузка данных по его инициативе; в) Перенаправление на другую страницу; г) Перенаправление в модальное окно;
— Единые решения по отображению 4 видов ошибок при 4 видах обстоятельств позволяют: а) Команде говорить на одном языке; б) Не создавать макеты ошибок для каждой ситуации и сохранять консистентность; в) Упростить подключение новых членов команды;
— При сбое клиента решили перенаправлять пользователя на особенную страницу в виде Configuration Item, которая существует вне информационной архитектуры и всегда может быть отображена клиентом, но на ней нельзя показать разные варианты текста ошибки в зависимости от контекста;
— Ошибка валидации данных может быть связана с отдельным полем или группой полей. Во втором случае сообщение должно быть визуально связано со всей группой (например, отображаться над ней);
— Если нет связи с сервером, на странице решили показывать баннер-растяжку сверху, а в модальном окне — алерт под его заголовком;
— Если есть фоновая проверка связи с сервером, и пользователь просматривает модальное окно, сообщение о потере связи лучше показывать после того, как он на что-нибудь нажмёт или закроет окно;
— Если ошибка произошла после перенаправления пользователя на страницу, решили отображать полноэкранную ошибку с соответствующим текстом. После перенаправления в модальное окно — алерт под его заголовком;
— На странице Configuration Item не стоит размещать кнопки и ссылки и советовать перезагрузить страницу (это ни к чему не приведёт). Стоит подсказать, куда обратиться и что сообщить сотрудникам техподдержки;
— Если суть сообщения об ошибке одна, а сущности разные, можно использовать общие грамматические конструкции. Например, когда сущность уже есть там, куда её добавляем, можно использовать конструкцию «Такой(-ая) [сущность] уже входит в [сущность]»;
— То же самое, если меняются не сущности, а значения параметров. Например: «Загрузите 1 файл до 100МВ в формате .docx, .pdf или .xlsx». Меняется количество файлов, лимит мегабайтов и форматы;
— Для специфических полей (номер телефона, дата или сумма) можно зафиксировать отдельные ситуации. Например: «Дата окончания периода не может быть раньше даты начала»;
— Ошибка может отображаться по-разному (полноэкранная, алерт, нотификация) с разным контентом. Стоит предусмотреть текстовые токены, из которых можно собрать любое отображение ошибки. Например: заголовок, полный текст, краткий текст, основное действие, второстепенное действие.

Настины статьи:
— Как возникают ошибки;
— Выбор способа отображения ошибки в интерфейсе;
— Выбор контента для описания ошибки пользователю.

#error

В Canvs написали об офбординге.

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

Об отписке от Яндекс Плюса.

Илона Саркисова написала первую статью из серии о Customer journey map.

— В 1998 году в IDEO по заказу Amtrak пытались понять, как повысить привлекательность поездок по железным дорогам. Возможно, это первое использование термина;
— CJM рассматривает человека как клиента компании и показывает, как тот узнаёт о сервисе, решает им воспользоваться, пользуется, а затем остаётся лояльным (жизненный цикл взаимодействия). Изучение пользовательского интерфейса здесь отходит на второй план;
— Подходит для анализа существующего сервиса и планирования нового;
— Нет смысла строить CJM, если а) человек ничего не покупает и нет взаимодействия по оказанию услуги, б) вы хотите проиллюстрировать только работу пользователя с интерфейсом;
— При построении CJM сначала надо понять, какие у сервиса есть (или должны быть) клиенты и описать персоны. Если их несколько, будет несколько CJM;
— Далее надо выписать точки взаимодействия и проблемы в каждой точке. В CJM можно включать любые элементы, которые помогут в проектировании сервиса;
— Например, можно выделить моменты истины — взаимодействия, в ходе которых клиенты решают, воспользуются они сервисом или нет;
— Также можно зафиксировать поставщиков услуг (кто оказывает сервис и несёт ответственность), эмоции (что клиенты чувствуют в каждой из точек взаимодействия), возможности (как можно улучшить взаимодействие) и так далее;
— CJM помогает увидеть сервис с высоты птичьего полёта, найти способы улучшить обслуживание и придумать новые услуги. Это инструмент на грани продуктового Customer Experience и маркетинга.

#cjm

Денис Тамбовцев рассказал, как меняется роль дизайнера интерфейсов, если это интерфейс для VR/AR.

— В VR нет плоскости, на которую надо нажать, чтобы рука взяла яблоко. Надо подойти к виртуальному столу и поднять объект своей рукой или контроллером в руке;
— Управление строится вокруг пользователя: его крупной и мелкой моторики, перемещения в пространстве, направления взгляда и голосовых команд;
— В играх интерфейсы можно разделить на а) находящиеся вне игровой сцены и б) находящиеся в пространстве сцены, вплетённые в повествование. В первом случае используется классический игровой HUD: подсказки появляются в центре экрана, шкала здоровья, количество патронов и миникарта находятся в его углах. Во втором случае, чтобы посмотреть направление, персонаж берёт в руки бумажную карту;
— Преимущества второго подхода: а) игрок сильнее фокусируется на игровом мире, б) из-за специфики VR-очков нельзя использовать классический HUD;
— Дизайнер должен не просто спроектировать и отрисовать окно системного меню, а также решить, как вообще отображать меню в виртуальной среде, чтобы не разрушить эффект погружения;
— Например, меню может находиться на запястье виртуальной руки в виде умных часов, проецироваться на голографический стол в конкретной точке сцены, выводиться виртуальным компаньоном пользователя, быть отдельной сценой при выходе из текущей;
— Частично дизайнер берёт на себя то, чем раньше занимались 3D-художники, гейм-дизайнеры и дизайнеры уровней. А значит, он должен понимать, как управлять фокусом пользователя через архитектуру локации, уметь прототипировать 3D-окружение и взаимодействие с ним.

В «Собаке Павловой» написали, как собрать UX-портфолио, работая в команде над большими коммерческими проектами.

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

#career

Илона Саркисова написала, как применять Customer journey map для проектирования нового сервиса.

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

Заметка о трёх типах персон. #cjm

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

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

#layout

Игорь Штанг написал об алгоритме вёрстки.

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

Ещё пара примеров. #layout

Роман Горбачёв написал об иерархии погружения (с очень понятными примерами).

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

#layout

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

— Выбирайте из пользователей тех, кому сообщение реально может быть полезно. Например, пуш о функции «Черновик» в Авито стоит направить тем, кто размещает много объявлений;
— Если пуш может приходить часто, напишите несколько вариантов текста, чтобы он не наскучил;
— Проверяйте сообщения на логичность в разных обстоятельствах. О вакансиях рядом с домом лучше сделать 2 варианта пуша: а) в радиусе 5 км для Москвы и Санкт-Петербурга, б) в радиусе 1 км для всех остальных;
— Не лезьте в жизнь людей. Сообщение от сервиса недвижимости с советом переехать или купить свою квартиру будет звучать грубо, так как сделать это непросто;
— Для каждого сообщения настраивайте кулдаун — время, в течение которого пользователь не получит его повторно. Выбирайте такое время, чтобы не надоесть. Также можно ограничить общее количество сообщений, приходящих от сервиса;
— Используйте в сообщениях переменные, так они станут персональными и более убедительными. Например: «Пользуется спросом. Объявление «1-к. квартира, 47,4 м…» из вашего избранного посмотрели 456 раз за неделю»;
— Проверяйте, что любые значения переменных работают на цель сообщения. Если вместо числа 456 будет 2, пользователь не решит поторопиться с решением по поводу этой квартиры;
— Если несколько одинаковых событий произошли одновременно, присылайте общий пуш;
— Новые эмодзи могут отображаться только в последних версиях систем. Чтобы все пользователи увидели эмодзи, используйте только те, которые появились до 2019 года;
— Используйте знак рубля и неразрывные пробелы.

#push

Тесс Гадд написала об аккордеонах.

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

#accordion

Андрей Шапиро написал о схематизации опыта с помощью CJM, Service Blueprint и собственной гибридной нотации.

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

#cjm #sb

В SimbirSoft написали о проектировании форм. Об этом было уже много публикаций, поэтому я выбрал не самые распространённые советы:

6. Если поле заполнено неправильно, выделите его и напишите, что не так и как это исправить. Можно скрывать текст подсказки к полю (который не помог заполнить его правильно) и показывать только текст сообщения об ошибке.

7. Не располагайте в форме ссылки на другие страницы. Пользователь может перейти по ссылке и не вернуться к форме.

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

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

12. Подстраивайте размер полей под предполагаемое содержимое.

13. Оставляйте кнопки формы активными. Если пользователь заполнит не все поля, их можно выделить при нажатии на кнопку отправки формы. О неактивных кнопках есть хорошая статья.

#form

20 самых популярных постов в 2021 году:

1. Как тестировать User Flow: четыре метода и лайфхак для бесплатного UI-тестирования — статья Кирилла Шерстобитова. Анонс в ВК получил 89 лайков и 71 репост.

2. Пользователям плевать на дизайн: как устроен «хороший UX» на самом деле — статья «Атвинты». 67/65.

3. Прототипирование стартапов — запись моего доклада. 59/71.

4. Фак юикс — конспект доклада Ильи Бирмана. 63/58.

5. Fintech Design Conf 2020 — записи докладов мероприятия. 61/58.

6. Аудит интерфейса: как его проводить и почему это проектирование наоборот — статья «Собаки Павловой». 60/59.

7. Avito Design Talk 2020 — записи докладов мероприятия. 56/59.

8. 15 советов для улучшения UX форм регистрации и входа в систему — перевод статьи Эрика Кеннеди. 56/55.

9. Fintech Design Conf 2021 — записи докладов мероприятия. 50/57.

10. Как выглядит хороший макет — статья Михаила Озорнина. 47/48.

11. Отображение ошибок в интерфейсе (часть 2, часть 3) — статьи Насти Овсянниковой. 49/42.

12. Фиксируем результаты UX-тестирования интерфейса на бегу: экономим время и обходимся без объёмных документов — статья «Собаки Павловой». 49/42.

13. «Я потерял веру в UX»: основатель агентства о том, как корпорации усложняют интерфейсы ради увеличения прибыли — перевод статьи Марка Херста. 48/39.

14. Схематизация опыта с CJM и Service Blueprint: практика гибридной нотации — статья Андрея Шапиро. 52/34.

15. Четыре фазы разработки интерфейса: что обсуждать с заказчиком, когда нет даже картинок — статья Ахнафа Кунакулова и Антона Илларионова. 50/35.

16. Интерфейсные тексты: как дизайнеру начать писать грамотнее — перевод статьи Дэвида Холла. 41/43.

17. Тёмный паттерн: как Яндекс манипулирует пользователями — статья Левана Джамелашвили. 53/31.

18. Информационная архитектура: краткий экскурс — статья Павла Шерера. 43/41.

19. Как создавать полезные для бизнеса дашборды: алгоритм, принципы вёрстки, инструменты, архитектура — статья Романа Бунина. 44/37.

20. M-commerce: 11 нюансов навигации в мобильной версии интернет-магазина — статья KISLORODа. 44/37.

Брайан Миллар написал об экстремальных пользователях.

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

Кстати, включил реакции, чтобы следующий топ UX Notes можно было определить на основе лайков и дизлайков в Телеграме, а не лайков в ВК. Но работают они только в последних версиях Телеграма.