Дмитрий Якушин написал о дизайн-токенах.

— Набор дизайн-токенов позволяет сделать визуально согласованный и при этом гибкий дизайн (легко поменять один оттенок на другой);
— Дизайн-токен — псевдоним определённого значения той или иной переменной: цвета, шрифта, размера элемента, тени, отступа, скругления;
— Цвет #677178 можно назвать color-grey-600 и использовать в макетах так, а можно создать токены color-text-secondary и color-component-badge-bg-neutral, которые будут ссылаться на color-grey-600;
— В тёмной теме color-text-secondary может ссылаться на другой цвет, что упрощает создание макетов для других тем;
— Говорящие названия упрощают их использование, особенно новыми участниками команды;
— Есть черновая версия стандарта дизайн-токенов от W3C;
— В составном токене (миксине) может быть больше одной переменной. Например, в токене типографики: название шрифта, кегль, высота строки, межбуквенный интервал;
— color-green-600 — глобальная переменная (примитив, палитра, референсный токен) с абстрактным названием без контекста. Число обычно отражает количество света в цвете;
— color-text-success — дизайн-токен, который ссылается на переменную color-green-600 и имеет контекст использования: для текстовых сообщений об успехе;
— Есть компонентные токены, которые относятся к конкретным компонентам, например, color-component-badge-bg-info для фона информационного бейджика;
— Распространены стили названия: color_text_primary для веба, сolorToken.textPrimary для мобильных платформ;
— Полная структура названия: префикс, группа (color), тип (text, component), элемент (badge), модификатор (background), вариант (info), состояние (hover);
— Некоторых частей может не быть: если токен не относится к компоненту, если к проекту не подключено нескольких библиотек с токенами (прификс их идентифицирует);
— В именах токенов размеров лучше не использовать цифры, чтобы не было путаницы с фактическими значениями: xx-small, x-small, small, medium, large, x-large, xx-large;
— Категории: colors, font family, font size, line height, border color, grid, border radius, spacing, box shadow, duration/transition, shadows, z-index, size.

#figma #design_system

Илья Кретов написал об интерфейсном тексте и типографике. Некоторые советы:

— Сокращайте использование кавычек. Например, названия разделов можно писать с заглавной буквы или выделять полужирным начертанием: «Ищите треки в разделе Коллекция»;
— Разделяйте узким пробелом разряды числа, сумму и знак рубля, числа и среднее тире в диапазоне;
— Чтобы написать −25%, используйте знак минуса (а не дефис) и не отделяйте его от числа пробелом;
— Написанный только заглавными буквами текст слишком эмоционален, кричит. Лучше использовать его максимум в кнопках или бейджах;
— Связывайте текст кнопки с заголовком: «Подключить услугу? [Подключить]». Если любите Conversational Design, когда вместо «Подключить» пишут «Да, хочу!», убедитесь, чтобы кнопка была рядом с заголовком, иначе смысл может потеряться;
— Пишите эмоционально нейтрально: «Вы не можете продолжить без регистрации» → «Для продолжения необходимо авторизоваться»;
— Учитывайте адаптивность. Самая важная информация должна вмещаться на самые маленькие экраны;
— Текст на экране должен быть понятен без контекста. Лучше строить его на именительном падеже: «Какого настроения соберём плейлист? [Весёлого] [Грустного]» → «Под какое настроение соберём плейлист? [Весёлое] [Грустное]».

Копия статьи. #writing #typography

Евгения Береснева написала о разделе с часто задаваемыми вопросами (FAQ).

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

#writing #support

Кэлвин Френч-Оуэн написал о категориях пользователей и учёте их потребностей при планировании продукта.

— Продукт должен быть удобным покупателю, быть удобным пользователю не обязательно. Можно ориентироваться на практиков (покупатели и пользователи в одном лице) и руководителей (покупатели и отчасти пользователи);
— Продавать практикам помогает эстетика и хороший UX. Возможность совместного использования ускоряет распространение знания о продукте между специалистами;
— Руководителям важнее всего отчётность: насколько эффективно работают подчинённые, есть ли проблемы;
— Также им важна стандартизация. Когда все работают одинаково, повышается безопасность, можно экономить на масштабах. Нужна настройка ролей и доступов с учётом корпоративной иерархии, сложная модель данных, позволяющая настроить продукт под требования конкретного покупателя;
— Узнайте, что нужно тому, кто принимает решение о покупке. Продаёте начальникам отделов? Насколько им важен отполированный интерфейс для обычных специалистов?
— Если продукт покупают руководители, вкладывайтесь в отчётность, интеграции с почтой и Слаком, ежемесячные сводки;
— Если практики — в инвайты, вход через волшебные ссылки и G Suite, самообслуживание, автоматический биллинг, объединение пользователей. Устраните все барьеры при регистрации.

In English. #product

Станислав Хрусталёв написал о входе в приложение по номеру телефона.

— Объедините вход и регистрацию. При вводе номера проверяйте, есть ли такой пользователь, и ведите на нужный сценарий;
— Вынесите ввод номера на отдельный экран. Не смешивайте с другими элементами неавторизованной зоны, чтобы не размывать фокус;
— Заголовок формы должен быть достаточно большим и содержать призыв к действию;
— Добавьте пояснение, что произойдёт дальше («Отправим сообщение с кодом»), чтобы управлять ожиданиями пользователя. Можно подчеркнуть ответственное отношение к приватности («Обещаем хранить его в тайне») или скорость входа («Займёт всего минуту»);
— Не дублируйте заголовок в плейсхолдере поля. Покажите в нём формат номера телефона, чтобы смысл поля был понятен с первого взгляда. Цифры лучше показать нулями или девятками;
— Активируйте поле автоматически при открытии экрана, отображайте цифровую раскладку клавиатуры (без возможности её поменять);
— Если принимаете только российские номера, +7 можно отобазить по умолчанию;
— Если пользователь вышел, но не удалил приложение, его номер можно сохранить и предложить при повторном входе. Если удалил приложение, номер можно запомнить по Device ID;
— Поле ввода можно промаркировать как phone number, чтобы пользователь мог подставить сохранённый на устройстве номер;
— Чтобы снизить количество ошибок, форматируйте введённый номер и ограничивайте количество символов (в зависимости от кода страны);
— При удалении номера по символам, автоматически удаляйте символы форматирования;
— Переходить к подтверждению лучше по нажатию на кнопку. Разместите её в нижней части экрана, не перекрывайте клавиатурой. Иногда кнопку «Получить код» размещают в кастомизированном меню над клавиатурой;
— Код по смс удобнее звонка, так как с автоподстановкой его можно ввести одним нажатием. Пуш ещё удобнее — приложение само может его обработать;
— На экране подтверждения стоит написать, что смс отправлено (и на какой номер). Но это сообщение должно быть визуально вторичным;
— Отправитель смс — название бренда. Код — в начале сообщения, чтобы не надо было его открывать. В текст добавьте пояснение, что это за код и что его не надо никому сообщать;
— Проверять код можно автоматически при вводе нужного количества символов.

#log_in #sign_up

Кейт Моран и Тейлор Дайкс написали о сравнительных таблицах.

— Когда альтернатив множество, выбирая товар, люди ориентируются на одну основную характеристику. С этим помогают фильтры. Когда товаров 5–7, люди учитывают достоинства каждого конкретного варианта. Здесь хорошо работают сравнительные таблицы;
— Если вы предлагаете не более 5 альтернатив (модели Apple Watch, варианты подписки), подойдёт статическая таблица. В ней можно контролировать отображение информации, редактировать формулировки;
— В динамической таблице пользователь сам выбирает, какие товары сравнить;
— Если в ней может оказаться больше 5 вариантов, предусмотрите способы сократить количество, например, добавив фильтры;
— Главная проблема динамической таблицы — неполнота данных о параметрах товаров;
— Стандартная компоновка: столбцы для товаров, строки для параметров;
— Фиксируйте заголовки столбцов при прокрутке;
— Связывайте абстрактные значения параметров с чем-то понятным: аккумулятор на 3350 мАч — хватит 1,2 раза зарядить iPhone 6;
— Объясняйте термины и непонятные параметры. Можно добавить всплывающие подсказки и ссылки на статьи;
— Если параметров много, дайте пользователю возможность управлять отображением: прятать отдельные группы параметров в аккордеон, отображать только отличающиеся параметры. В статические таблицы можно добавить краткий и полный вариант отображения;
— Сравнительные таблицы неэффективны, если варианты не взаимоисключающие (вместо сравнения двух платьев лучше оба добавить в корзину), простые (мало параметров), дешёвые или заменяемые (нет смысла тратить время на изучение таблицы), уникальные и трудно сравниваемые (разные параметры).

In English. #ecommerce #table

Роб МакКоган написал о влиянии типографики на восприятие и поведение.

— Более контрастный цвет повышает разборчивость текста и делает его более убедительным;
— Более сложный для восприятия шрифт (Brush Script против Arial) усложняет чтение и стимулирует критичное отношение к написанному, что помогает заметить подвох. Если таким набрано задание, оценка времени его выполнения будет больше (в эксперименте — почти в 2 раза);
— Есть ассоциативная связь между словами и формой. Слово «Кики» — угловатая форма, «Буба» — обтекаемая. Используя подходящую или неподходящую форму, можно создать гармонию или конфликт;
— Когда шрифт соответствует смыслу, такой текст читают быстрее. Например, Truck и шрифт Impact, Flower и шрифт Snell Roundhand;
— Если типографика оптимизирована, человек меньше устаёт и лучше потом решает задачи на сообразительность;
— При рецензировании научных материалов положительные оценки чаще получали статьи с иллюстрациями, подготовленными графическими дизайнерами (а не учёными).

In English. #typography

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

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

#management

Иван Вербов написал о стилистике в дизайне интерфейсов.

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

#style

Бенджамин Брэндалл написал об отмене подписки в разных сервисах и выделил хорошие практики.

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

In English. #offboarding

Позабавило сегодня. В компании «Ю-эксперт», которая занимается проектированием интерфейсов, написали об ошибках в форме запроса консультации.

Среди прочих выделили:

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

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

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

4. Непонятное сообщение об отправке заявки. Например, английский текст, когда остальной интерфейс на русском, или что-то на технарском вроде «Ответ записан».

Плюс ещё 3 ошибки.

Заканчивается статья ссылкой на форму запроса бесплатного аудита юзабилити в компании «Ю-эксперт». И сколько же ошибок в этой форме? Ноль? А вот и нет: все перечисленные выше, то есть 4 из 7 обозначенных в статье.

#form

Блейр Фикс объяснил, почему эффекта Даннинга — Крюгера не существует.

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

In English. #psychology

Паша Злобин написал о сервисах для а/б-тестирования.

— Google Optimize закрыт с сентября 2023 года;
— Сервисы из России: Varioqub (проект Яндекса, интегрируется с Метрикой), UX Rocket, Sigma;
— У первых двух есть бесплатные тарифы;
— Паша показал процесс настройки а/б-теста в первых двух (попробовать Сигму без подписания договора нельзя);
— В комментариях подсказали, что пользователи из России могут на собственном сервере поднять опенсорсный GrowthBook (есть бесплатный тариф).

#tool #ab_testing

Дарья Хуторянская написала о UX-аудите.

— Это оценка, насколько продукт или отдельные фичи, удовлетворяют потребности пользователей и решают задачи бизнеса;
— Аудит не нужен, если продукт активно растёт, привлекает пользователей и инвестиции (лучше заняться новыми фичами и сбором обратной связи, чтобы укрепиться на рынке) или если налажено отслеживание метрик, которые показывают, что продукт в порядке;
— Если продукт для дизайнера новый, он смотрит на него незамыленным взглядом (это плюс), но должен быстро в нём разобраться (это минус), чтобы не скатиться в поверхностную оценку UI;
— 1-й шаг. Определите задачи бизнеса и потребности пользователей. С этим поможет серия экспертных интервью с владельцем продукта. Если есть время, поговорите с пользователями, контактирующими с ними специалистами компании (персональные менеджеры, продажи, поддержка), изучите отзывы и обращения в поддержку;
— Задачи бизнеса должны попадать в категории: 1) рост выручки и прибыли компании, 2) удержание и возвращение клиентов, 3) снижение издержек;
— 2-й шаг. Изучите данные о поведении пользователей: конверсию в завершение сценария (пути тех, кто не доходит, могут указать на проблемы), время решения задачи (можно сравнить, когда сценарии будут доработаны), поисковые запросы (что люди ищут и не могут найти), используемые устройства, DAU, MAU (востребованность фичи от месяца к месяцу);
— Если таких данных не собирают, заведите задачу на подключение аналитики. Что-то можно выгрузить из баз данных и логов активности;
— 3-й шаг. Если фич много, выберите те, что приносят больше всего пользы бизнесу, из них выберите 3−5 самых востребованных у пользователей;
— Каждую оцените по эвристикам (есть разные фреймворки). Так вы не упустите и UX, и UI-составляющие фичи. Если эвристика соблюдается, ставьте 1, если нет, ставьте 0 и добавляйте комментарий, почему так;
— 4-й шаг. Презентуйте результаты команде (в сложном продукте может понадобиться серия часовых встреч), обсудите, зафиксируйте конкретные задачи, которые пойдут в работу, заведите эпики для будущих доработок.

#audit

Илья Бирман написал о вертикальном масштабе графика.

— Тафти рекомендует подбирать его так, чтобы в среднем угол наклона графика был примерно 45°;
— График нужен для сравнения данных, выявления тенденций и закономерностей;
— Даже сжимая график по вертикали, мы не снижаем его разрешение, а повышаем. Если средний угол наклона — 45°, лучше видны пологие участки и резкие перепады.

#data_visualization

Михаил Озорнин написал о масштабе временных рядов.

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

#data_visualization #time

Никита Цейковец написал, какими техническими решениями пользуются люди с нарушениями зрения.

— Опрос провели в интернете в 2023 году среди русскоязычных пользователей, поучаствовал 491 респондент. Это уже 5-й опрос, можно оценить динамику;
— 99% используют мобильные устройства, 91% десктопные. Важно обеспечить доступность мобильных приложений, но и про десктоп не стоит забывать;
— Треть респондентов не пользуется голосовым интерфейсом. Он не должен становиться единственным способом взаимодействия;
— Из платформ чаще используют Windows и Android, но доля пользователей iOS и iPadOS достаточно значима и в последние годы растёт. Растёт также интерес к GNU/Linux;
— Недоступность мобильного приложения нельзя компенсировать доступной мобильной версией сайта, пользователи предпочитают приложения;
— Проверять доступность сайтов на деcктопе следует в Chrome и Firefox, а на мобильных устройствах в Chrome и Safari;
— Конфигурации для проверки в порядке снижения приоритета. Сайты на десктопе: Chrome и Firefox с NVDA на Windows, с JAWS на Windows, Safari с VoiceOver на macOS, Chrome с Orca на GNU/Linux. Сайты на мобильных устройствах: Chrome с TalkBack на Android, Safari с VoiceOver на iOS/iPadOS;
— При тестировании доступности для слабовидящих в первую очередь стоит применять встроенные инструменты увеличения экрана и коррекции изображения. Они как правило наиболее популярны.

#accessibility #tool

Саадия Минхас написала о нижней панели вкладок (tab bar).

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

In English. #tab_bar

Анастасия Вихарева написала о повышении доступности интерфейса.

— Правильная последовательность заголовков (h1 → h2 → h3) помогает пользователям скринридеров ориентироваться на странице;
— Оптимальная длина строки — 60 символов. На клавиатуре Брайля можно разместить максимум 66 символов;
— Ссылки делайте частью текста, а не вставляйте просто как https://www…, так как скринридер такие ссылки читает посимвольно;
— Порядок расположения текста, связанного с текстовым полем: лейбл, хинт, текст ошибки, плейсхолдер;
— Не забывайте о сфокусированных состояниях для элементов интерфейса;
— В опросе после списка вариантов ответа желательно ставить кнопку «Продолжить», чтобы слепой пользователь понял, где заканчивается список;
— При открытии всплывающего окна автофокус — на заголовок.

#accessibility