Русалина Ушакова написала о том, когда удобный интерфейс мешает обучению.

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

#learning #principles

Снежана Чепа написала об ошибках в работе с персональными данными на российских сайтах, которые могут привести к штрафам. Суммы можно посмотреть в статье.

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

#laws

Илья Бирман написал о сценариях.

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

#scenario

Кейт Каплан написала о контекстном меню.

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

In English. #menu

Стас Мельников написал, как с помощью CSS-свойств улучшить дизайн веб-страниц.

— Чтобы, например, на последней строке заголовка не оставалось одного слова, можно использовать свойство text-wrap: balance;
— Свойство padding задаёт внутренние отступы. У интерактивных элементов оно позволяет увеличить область нажатия и облегчить пользователям попадание по таким элементам;
— Если на новость ведёт ссылка и в заголовке, и в картинке, пользователи скринридеров услышат о ссылке дважды. С помощью псевдоэлемента ::before можно убрать вторую ссылку и при этом сохранить интерактивность картинки;
— В разметке попапа код кнопки закрытия часто идёт первым. В этом случае пользователи скринридера, открыв попап, сразу же слышат о кнопке закрытия попапа;
— Можно расположить код кнопки в конце разметки попапа, но с помощью свойства position: absolute сохранить её визуальное расположение в верхней части попапа;
— Для выделенного текста голубой цвет фона можно заменить на любой другой. При этом цвет текста можно автоматически делать контрастным по отношению к цвету фона с помощью функции contrast-color().

#accessibility #css

Татьяна Бублик поделилась своей системой организации файлов в Фигме.

— Все макеты продукта могут находиться в одном файле;
— Из-за этого он может тормозить и даже перестать открываться, обновления дизайн-системы будут применяться ко всем макетам, даже архивным, команде сложно находить нужные макеты;
— В Фигме есть бранчи, но недоработки этого инструмента и ошибки дизайнеров могут принести больше проблем;
— Заведите папки: для файлов дизайн-системы (сюда можно отнести редполитику и любые вспомогательные материалы), для текущих задач (и шаблонов для новой задачи и мастер-файла), для каждой фичи или микросервиса;
— Макеты по отдельной задаче создаются в отдельном файле, в названии которого есть номер тикета, чтобы легко его находить;
— Появляется такой файл в папке для текущих задач. Дизайнер подключает к нему нужные файлы дизайн-системы;
— При передаче макетов в разработку размещает их на странице For dev;
— После успешного дизайн-ревью и завершения разработки перемещает файл в папку фичи;
— А макеты из файла задачи копирует в мастер-файл фичи, в котором отображаются макеты всех флоу фичи;
— Статусы задачных файлов отличаются от статусов задач в таск-трекере: In progress, Ready for dev, Design review, Freeze, Closed (закрыта, но ещё не перенесена в папку фичи), Archive (перенесена в папку);
— В архивных файлах дизайнер не принимает обновлений ДС, макеты выглядят так, как должны были быть разработаны, что важно разработчикам и тестировщикам;
— Мастер-файлы фич содержат макеты всех флоу, что позволяет команде быстро понимать актуальное состояние фичи;
— Система требует времени для поддержания порядка (час каждого дизайнера в спринт). Плюс команде требуется время, чтобы привыкнуть.

#figma #management

Анастасия Ефанова написала, как сокращение количества пушей в 2,5 раза повысило конверсию из пушей в 3 раза и снизило отписки на 38,5%.

— Ключевая метрика — конверсия в завершённую смену, то есть работник согласился на подработку и отработал смену;
— Пуши использовались для онбординга, вывода на смену, информирования об акциях;
— Новые пользователи получали 8–10 пушей в день. Важно конвертировать их в первую смену в течение месяца, иначе такой пользователь отваливается;
— Начали с изучения сценариев отправки пушей. Выяснили, что информируют о закончившихся акциях или работают в соответствии с устаревшей бизнес-логикой (напоминают о чекине в течение часа после выхода на смену, хотя такого требования уже нет);
— По конверсии и адекватности количества пушей все сценарии разделили на худшие (надо отключать), средние (улучшать), лучшие (масштабировать);
— Например, пуш о подработках в радиусе 20 км был бесполезен в Москве и Петербурге, так как местные работники не готовы ездить так далеко;
— Сократили интервалы между онбординговыми пушами, чтобы отправить их за 2 недели вместо месяца и во вторые 2 недели сфокусироваться на конверсии в смену;
— Большинство всё равно загружает документы и выполняет прочие действия сразу, и пушей с напоминаниями не получает;
— Ввели ограничения на пуши о подработке в радиусе 10 км, если работник уже на смене или выйдет в ближайшие дни. Плюс отправляют их не чаще одного раза в день;
— Понизили приоритет пушей об акциях: если уже отправлен пуш о подработке, пуш об акции не отправится;
— Добавили ограничения на уровне сценариев. Триггерный сценарий срабатывает не чаще одного раза в 2 часа. У отдельных сценариев (вроде возвращения доступных подработок) — раз в 2 дня.

#push

Елена Плинер написала о юзерфлоу.

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

#user_flow