UX Notes

Как добавлять в Фигму реальную рыбу

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

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

Для этого в Фигме я пользуюсь двумя плагинами: FigGPT и Content Reel.

ФигЖПТ может делать супер дофига всего прямо в Фигме, начиная от рерайта текста, заканчивая генерацией и подстановкой контента. Он платный, 5 баксов в месяц.

📹 Детальнее, что умеет ФигЖПТ и как пользоваться можно посмотреть в видосе

Для тех, у кого уже есть ЧатЖПТ и кто не хочет платить доп. деньги, есть вариант с бесплатным плагином Content Reel.

Флоу работы выглядит так:
1. Пишу запрос в чатЖПТ на генерацию нужного контента столбиком без списков.
2. Добавляю «свой» контент в плагин (нужна регистрация), делаю его приватным.
3. Выделяю нужные поля и подставляю контент в макеты

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

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

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

#layout #writing

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

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

#complicated

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

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

#loader #error

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

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

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

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

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

In English.

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

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

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

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

#career

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

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

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

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

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

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

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

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

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

In English. #navigation #mobile

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

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

Копия в ЖЖ. #layout

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

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

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

Егор Камелев написал о проблеме неактивной кнопки при отправке формы.

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

#button #form

Настя Фальковская написала о пирамиде кайфовости интерфейсного текста.

— Аарон Уолтер в книге «Эмоциональный веб-дизайн» представил характеристики продукта в виде пирамиды: чем ближе к основанию, тем они важнее;
— Характеристики текста тоже можно представить в виде пирамиды. Нет смысла улучшать его более высокоуровневые характеристики, не проработав основные;
— В основании будет «Польза»: текст должен решать какую-то задачу. Какая у экрана цель, кто аудитория, что человек должен сделать после прочтения текста? Может оказаться, что текст вообще не нужен или его можно заменить графикой;
— Уровнем выше — «Грамотность»: ошибки показывают неаккуратность и невнимательность, что негативно характеризует продукт и то, как мы оказываем услуги;
— Затем «Удобство и понятность»: формулировки понятны и помогают пользователю не спотыкаться на пути к цели. Например, вместо «Выйти» на кнопке — текст, который подсказывает, что изменения будут сохранены. Антипример: «Не сохранять изменения? Да / Нет»;
— Далее «Красота и доступность»: деепричастия, страдательный залог и прочий канцелярит заменены на простые и лаконичные формулировки;
— На вершине пирамиды «Эмоциональность»: текст доставляет удовольствие, радует пользователя. Шутками, проявлениями заботы, отсылками и так далее. Не каждая надпись должна вызывать эмоции, но общее впечатление должно быть приятным и тёплым.

#writing

Никита Самутин написал, как начинающему дизайнеру выделиться, откликаясь на вакансии.

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

#career

Опубликованы видео с Дизайн-просмотра:

1. Егор Мызник, Plenum — Профессиональные заболевания дизайнеров

2. Данила Шорох, Всесмарт — Лопни свой социальный пузырь

3. Олег Баринбойм, TutkovBudkov — Как продавать креатив

4. Александр Лыгин — Что не так с вашими проектами

5. Сергей Гуров — Невидимый дизайн. Идиоматический подход

6. Александра Королькова, Paratype — Вся правда о шрифтовых парах

7. Михаил Кучин, М18 — Открытый дизайнер

8. Покрас Лампас — Новая Визуальная Культура

9. Леонид Ивахов, МТС — Развитие дизайн лидера и команды

10. Митя Осадчук, Иви — О смыслах дизайна и эффективности айдентики

11. Вова Лифанов, Супрематика — Что было после

Матеуш Литарович написал о когнитивной нагрузке.

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

In English. #cognitive_load

Дмитрий Подгайский написал, почему геймификацию не стоит начинать с баллов, лидербордов и ачивок.

— Баллы — это награда за совершённые действия, которая может принимать форму очков опыта, игровой валюты и прочего. Они хорошо работают для положительного подкрепления;
— Сложно определить, сколько баллов давать за те или иные действия;
— Чтобы пользователи ценили баллы, нужна возможность обменять их на что-то ценное, а это дополнительный бюджет, которого может на старте не быть;
— Баллы надо считать: сколько выдали и потратили. Без экономической модели и контроля механика быстро ломается;
— Это внешняя мотивация, которая работает хуже внутренней;
— Лидерборды разжигают соревновательность и азарт, показывают, кто самый крутой. Некоторые люди любят возглавлять разные рейтинги;
— Также они позволяют проводить разные турниры, делать посты в соцсетях и создают инфоповоды;
— Хороший лидерборд, который не будет демотивировать недостижимыми позициями лидеров, сделать непросто. Надо делить его на лиги, классы и разделы, отделять активных участников и остальных;
— И надо понять, по каким критериям его строить. С фитнес-приложениями понятно, а что делать интернет-магазинам?
— Плюс для построения лидерборда у пользователей должны быть профили, имена и аватары;
— Ачивки в геймификации бизнеса не работают и на метрики не влияют. От них можно получить пользу, но точно не на старте геймификации.

#gamification

Ксения Толокнова написала о мобильных клавиатурах.

— При проектировании мобильных форм стоит подумать о подходящих экранных клавиатурах;
— Клавиатура зависит от типа поля ввода, которых около 50 на iOS и 30 на Android;
— Например, для ввода имейла на iOS на клавиатуре с буквами появляются «.» и «@». Для ввода телефона используется цифровая клавиатура с символами «+», «*» и «#»;
— Есть более специфичные варианты, заточенные под ввод определённых наборов символов. Например, dectimalPad для ввода нецелых чисел;
— Можно скрыть строку с рекомендациями (при вводе имейла в ней может быть имейл пользователя), настроить действия при вводе, например: автозамену при орфографических ошибках, написание новых предложений с заглавной буквы;
— Во многих клавиатурах есть кнопка действия (может быть заблокированной). По умолчанию это Return, которая в зависимости от типа поля переключает на следующее поле, создаваёт новую строку, сворачивает клавиатуру;
— В iOS их 12 вариантов: Next переключает на следующий элемент ввода или шаг, Continue переводит на следующий шаг, Search запускает поиск;
— Если в вашей форме на кнопке написано Continue, здорово, если на экранной клавиатуре тоже будет Continue;
— Можно настроить, как скрывать клавиатуру (или не скрывать совсем, как в Ноушене). В iOS-приложении Телеграма она скрывается свайпом вниз, у Ютуба — минимальной прокруткой контента;
— Чтобы в тулбаре появлялись коды из смс, типом поля должно быть OTP;
— Над клавиатурой можно добавить кастомный тулбар (Ноушен, Твиттер). Их можно стилизовать под нативный с помощью серого фона (Google App, Revolut);
— Например, в приложении MyFitnessPal в тулбаре можно менять единицы изменения, одновременно с этим вводя числа в соответствующее поле.

Копия статьи. #mobile #form