Вадим Митякин и Андрей Шапиро обсудили CJM и Карту процесса-опыта.

— В CJM представляют линейный путь пользователя, который решает какую-то задачу, разложенный на ключевые точки, где с потребителем происходит что-то важное;
— Даже если в этих точках мы, как создатели продукта, во взаимодействии не участвуем;
— Цель — понять, как создать для пользователя ценность, помочь ему с решением задачи на том или ином шаге с помощью функций нашей системы;
— Функции CJM: фиксация, формирование единого понимания участниками процесса, включение новых участников, управление процессом изменения;
— Нет какой-то единой или классической нотации CJM;
— Нотация BPMN фиксирует процессы. Люди там тоже есть, но они на периферии;
— CJM нужен, чтобы попасть в шкуру пользователя, что-то понять и перейти к созданию какого-то конкретного решения для определённой ключевой точки. Поэтому CJM часто остаются пылиться после создания;
— Карта процесса-опыта — результат эволюции гибридной нотации CJM и Service blueprint;
— Она позволяет соединить опыт потребителя (или других участников взаимодействия) с обеспечивающими этот опыт процессами;
— В отличие от CJM у неё есть конкретная нотация. В отличие от BPMN, нотация простая, с минимумом элементов, не требующая специальных знаний, чтобы её читать;
— Также в отличие от BPMN она учитывает, что это не программы, а живые люди, которые не всегда обязаны двигаться по процессу. Потребитель может просто уйти;
— Но если вы пришли на проект, где все говорят на языке BPMN, возможно, не стоит этого менять и лучше подстроиться;
— Карта процесса-опыта соединяет машины и людей, показывает связь бизнес-модели и инструментов, задействованных в ней.

Копия видео в ВК. #cjm #sb

Игорь Штанг написал, можно ли ставить заголовок на одинаковом расстоянии от верхнего и нижнего текста.

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

Копия в ЖЖ. #layout

Энтони Ценг написал, как в мобильных интерфейсах можно иногда отказаться от кнопки «Назад».

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

In English. #navigation #mobile

Поле обратной связи
#совет из старого фонда

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

Что у нас есть для этого в арсенале? Подпись, пространство, плейсхолдер.

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

Пространство. Размер поля даёт понять пользователю, сколько от него примерно ждут текста. Если вы хотите отзыв длиннее двух-трех слов — дайте для этого пространство. В однострочное поле напишут ровно одну строку, даже если это это ограничение чисто визуальное. А слишком большое поле может отпугнуть, как пустой А4 на экзамене.

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

И кое-что ещё. Не рекомендую делать универсальные поля «для всего». Например, одно поле для отзывов и для пожеланий. Лучше сделать отдельными полями, чтобы не путать людей. Если разделить не вариант, то хотя бы перечислить возможные типы сообщения в подписи или плейсхолдере.

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

— В студии проекты длятся 4−8 месяцев, дизайнер может вести 2 проекта параллельно. Продукты живут и развиваются годами и десятилетиями;
— Проекты могут быть из самых разных сфер. В продукте дизайнер глубоко погружается в предметную область и начинает разбираться в тонкостях этого бизнеса;
— В студии типовые задачи дизайнера связаны с созданием проектов с нуля, от брифа и концепции до защиты перед клиентом. В продукте — с улучшением и развитием существующего, от изучения стратегии и ключевых метрик до увязывания решения с интересами нескольких стейкхолдеров и соседних отделов;
— В продукте любые решения проходят через ведущего дизайнера, продакта и вышестоящих менеджеров, творческая свобода ограничена дизайн-системой, брендом, финансовыми целями, легаси, интересами разных департаментов и видением продакта, так как цена ошибки высока;
— Ключевые навыки дизайнера в студии должны позволять ему придумывать что-то новое и воплощать минимальными средствами. В продукте — мыслить системно, быть в курсе работы других команд, учитывать технические и бизнес-ограничения, работать с метриками;
— Зарплаты в продукте чаще всего будут больше, так как студия зарабатывает на дизайнерах, а продукт, например, на кредитках и ипотеках, и зарплаты дизайнеров в его бизнес-модели — незначительная часть издержек;
— Прежде чем менять работу, подумайте, какие задачи вас вдохновляют, чему вы хотите научиться, значима ли ваша работа, часто достаточно сменить проект или команду внутри компании;
— Нет студийных или продуктовых дизайнеров. Сильный дизайнер понимает в бизнесе, умеет исследовать и измерять результаты своей работы, и такой дизайнер всегда будет востребован.

#career

Дмитрий Якушин написал о тактильной обратной связи в мобильных приложениях.

— Тактильная обратная связь (haptic feedback) — использование вибрационных паттернов для передачи информации пользователю;
— Виброотклик — одна из её форм, а не синоним;
— Она позволяет снизить объём визуальной обратной связи (меньше отвлекает), добавить ещё один канал взаимодействия кроме визуального и аудиального (повышает доступность) и в целом сделать приложение более отзывчивым и живым;
— Можно использовать для подтверждения действий. Приложение Сбербанка коротко вибрирует при успешной отправке денег и длинно, если произошла ошибка;
— Чтобы выделить достижение конца списка. Яндекс Музыка реагирует, когда громкость на максимуме и увеличить её нельзя. Авито — когда пользователь прокрутил весь список фильтров;
— Чтобы сообщить об ошибке, например, если отправляемая форма заполнена некорректно;
— Чтобы выделить нажатия на значимые кнопки или переключатели. Самокат вибрирует, когда пользователь меняет адрес доставки или добавляет товар в корзину;
— Или выделить значимое изменение со стороны приложения. Яндекс Такси вибрирует, когда такси найдено. Авито — если пропал интернет;
— Давайте тактильную обратную связь не на все действия пользователя, а только на важные или вызываемые сложными жестами (тактильно можно подтвердить, что приложение восприняло жест);
— Не используйте только тактильную обратную связь;
— Следуйте тактильным паттернам операционной системы (как она показывает позитивное, негативное или нейтральное событие), к которым привыкли пользователи;
— Помните, что вибрация уменьшает заряд аккумулятора. Разрешите пользователям отключать её или уменьшать частоту.

Энтони Ценг написал о странице с сообщением о покупке.

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

In English.

Слава Соколов написал об основах BDUI для продуктовых дизайнеров (в зарубежных источниках можно встретить синоним SDUI).

— BDUI (backend driven user interface) — подход к разработке приложений, при котором бекенд управляет данными, внешним видом и поведением приложения;
— Он позволяет обновлять мобильное приложение без релиза его новых версий в сторах. Причём, обновлять целиком, включая состав и последовательность экранов в многошаговых сценариях;
— Продукты, чьи приложения удалены из сторов, могут сохранять актуальными их старые версии;
— Также он упрощает реализацию единой логики на разных платформах (веб, iOS, Android), проведение а/б-тестов и сокращает затраты на разработку фронтенда;
— Продуктовому же дизайнеру эта технология даёт набор ограничений и навык чтения контрактов в формате JSON;
— Компонент в дизайн-системе и его контракт ограничивают то, что можно настроить при его использовании (свойства и их значения). Нельзя быстро подкрутить стили на фронте, если настроек не хватает (нет свойства для настройки отступов или среди возможных размеров нет нужного), — придётся дорабатывать компонент и контракт;
— Чтобы не сломать существующие фичи и сохранить консистентность, для доработки потребуются обсуждения и согласования, а это время;
— Поэтому в компоненты закладывают максимум гибкости с самого начала;
— Сложную кастомную вёрстку позволяют сделать компоненты, состоящие из набора слотов, куда можно вставить любые другие компоненты (даже такие наборы слотов);
— Контракт в BDUI — главный источник истины;
— В JSON свойства называют ключами, это строковые переменные (например, «size»). Значения могут быть строковыми, числовыми и логическими переменными (true, false, required);
— Объект — список параметров сложного элемента, для описания которого нужно несколько ключей (порядок их перечисления не важен);
— Массив — тоже список, но порядок элементов в нём важен. Он может содержать список полей для отображения на экране;
— Часто описания значений выносят в отдельные файлы ($ref), чтобы было удобно ссылаться на них сразу из многих контрактов. Например, токены цвета в дизайн-системе;
— Ещё Слава рассказал о ключах required, enum и oneOf. Написанного в статье достаточно для чтения контрактов.

Видео в Ютубе и ВК.

Никита Колюгин написал, что надо знать о клиент-серверной архитектуре, чтобы учитывать все нужные состояния интерфейса.

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

#loader #error

Морган Пэн написала о балансе сложности интерфейса.

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

#complicated

Игорь Штанг написал о пользе повторов.

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

#layout #writing

Таня Юдина написала о найме дизайнеров с точки зрения нанимающего лида. Получились советы и соискателям и нанимающим:

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

Копия статьи. #career #management

Катя написала об артефактах модерируемого юзабилити-теста.

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

#unmoderated

Тарас Бакусевич написал о повышении вовлечённости и удержании пользователей. В статье 21 рекомендация, здесь только часть:

— Можно достать пользователя пушами, а можно как Дуолинго ненавязчиво напоминать о себе виджетом на домашнем экране;
— Персонализированные триггеры эффективнее общих. Старбакс опирается на историю покупок и предпочтения клиента;
— Чтобы человек что-то сделал, сложность действия должна быть меньше оценки вознаграждения. Описывайте получаемую ценность (получить акции стоимостью $75 за прохождение теста) и само действие (тест займёт всего 3 минуты);
— Побуждайте пользователя брать на себя обязательства, не требующие больших усилий. Например: 7 дней подряд проходить уроки;
— Одной внешней мотивации (вознаграждения, баллов) мало. Продукт должен давать пользователю что-то для развития внутренней мотивации: чувство удовлетворённости, улучшение физической формы и так далее;
— Давайте обратную связь (сообщения об успехе, анимации, заполнение шкалы прогресса), особенно, если вознаграждение откладывается. В Тиндере пользователь свайпает сейчас, а матч происходит потом;
— Большие задачи делите на этапы и визуализируйте прогресс;
— Непредсказуемое вознаграждение вызывает интерес и предвкушение. Например: лутбоксы со случайными наградами;
— Позволяйте настраивать продукт под себя: плейлисты, предпочтения, настройка интерфейса;
— Создавайте условия для долгосрочного взаимодействия: новые достижения, прокачка персонажа, многоуровневая система лояльности;
— Можно также усложнять механики по мере того, как пользователь осваивается. Например: более сложные медитации и длинные сеансы в Headspace.

In English.

Якоб Нильсен ещё в 2004 году написал об использовании чекбоксов и радиокнопок.

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

In English. #checkbox #radio_button

Александр Клименков написал о личном руководстве по стилю.

— В изданиях есть руководства по стилю, которые помогают сохранять единообразие в тексте и его оформлении всех материалов издания;
— Например, они могут предписывать всегда писать букву «ё», вычищать её автозаменой на «е» или использовать только там, где без неё возникает путаница;
— Есть общие стандарты вроде The Chicago Manual of Style или ГОСТов для НИОКР;
— Свои руководства есть в некоторых организациях. Например: Microsoft Writing Style Guide;
— Если вы пишете текст для себя или организации, где такого руководства нет, полезно иметь свой набор правил, чтобы не принимать решения по оформлению каждый раз и не вспоминать, как делали раньше;
— Александр поделился своим набором. Не со всеми правилами можно согласиться, но статья полезна списком вопросов, на которые надо ответить, чтобы создать основу собственного руководства;
— Использование кавычек (включая кавычки внутри кавычек), когда какие чёрточки нужны (дефис, минус, среднее и длинное тире), когда нужен неразрывный пробел (в том числе ставить ли его перед «%»), когда использовать нумерованные списки и какие знаки препинания ставить в конце пунктов списка;
— Буква «ё», использование пассивного (страдательного) залога, когда выделять текст полужирным начертанием, курсивом, подчёркиванием, когда уместно зачёркивать текст, оформление таблиц (включая выравнивание в шапке и столбцах).

#writing

Эдвард Скотт написал о сложных паролях.

— 82% сайтов, исследованных Baymard Institute, заставляют придумывать сложные пароли;
— Людей это расстраивает. Негативный эффект проявляется не при регистрации, а при повторном входе. 18% пользователей с учётной записью отказываются от оформления заказа из-за проблем со сбросом пароля;
— Неподходящий пароль может сподвигнуть пользователей пробовать разные имейлы, если они точно не помнят, с каким имейлом регистрировались;
— Иногда люди придумывают один сложный пароль, который используют везде. Это небезопасно из-за утечек паролей;
— Волшебные ссылки (одноразовые ссылки для входа, присылаемые на имейл) — не панацея. Проблемы у них такие же как при восстановлении пароля: письма задерживаются, попадают в спам, у людей возникают проблемы с входом в почту;
— Для сайтов электронной коммерции эксперты NIST рекомендуют ограничить минимальную длину пароля (6−8 символов), не ограничивать максимальную, но не требовать конкретных символов;
— Пользователи смогут использовать сложные пароли без принуждения;
— Полезно также сделать максимум функциональности доступным без ввода пароля;
— Снижая требования к паролям, стоит внедрить дополнительные меры безопасности: ограничить количество попыток входа, показывать капчу при подозрениях на бота, добавить опциональную двухфакторную аутентификацию, отправлять имейл для подтверждения при входе с нового устройства;
— Приложение Target просит повторно ввести номер карты при выборе нового адреса доставки.

In English. #login #signup

Кейт Каплан написала о тестировании иконок.

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

In English. #icon