«Открыть. Кнопка». Как мы делаем приложение «Мой МТС» доступным каждому

Дизайнеры «Мой МТС» рассказывают, как выстраивают работу над инклюзивным интерфейсом в своих дизайн-процессах.

Привет, VC! На связи команда дизайна приложения «Мой МТС». Сегодня хотим рассказать, как вместе с командой продукта мы начали работать над инклюзивным дизайном нашего приложения.

Пока это только первые шаги (и нам есть куда расти), но мы верим, что наш опыт будет полезен многим. А ещё надеемся на обратную связь в комментариях, чтобы узнать, как у вас устроена работа в этом направлении.

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

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

Внутри команды «Мой МТС» мы поставили цель — сделать интерфейс нашего мобильного приложения доступнее и удобнее для всех в течение 2024 года.

Мы применяем продуктовый подход, поэтому эту задачу традиционно мы начали с этапа исследования, которое вылилось в 5 составляющих.

1. Аудит приложения

Для начала мы решили понять, насколько хорошо или плохо сейчас реализована поддержка доступности в «Мой МТС». Поэтому мы предложили коллегам из департамента экспертизы качества продуктов МТС протестировать инклюзивность нашего приложения. Ребята сделали это и составили для нас отчёт, в котором содержались рекомендации по доработкам и оценка уровня доступности.

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

Всего же существует 3 уровня доступности. Целевым для нас мы наметили уровень АА. При нём интерфейс удобен для большинства пользователей.

2. Анализ рынка

Далее мы изучили статистику по пользователям, которые нуждаются в дополнительных настройках интерфейса.

Благодаря свежей статье от Яндекса выяснили:

• 51% пользователей смартфонов использует хотя бы одну настройку доступности

• 35% пользователей используют настройку увеличенного текста

• 27% пользователей используют настройку «тёмная тема оформления»
• 6% пользователей включают настройки чтения вслух
• 0,02% пользователей используют скринридер — специальный режим навигации и чтения текста на экране

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

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

3. Изучение опыта других компаний и продуктов экосистемы МТС

Мы перечитали опыт Сбера, Додо, Яндекса и других компаний, которые делают много в области цифровой инклюзии. Все они круто описали свои подходы — это дало нам базу.

К тому же не так давно внутри МТС появился общий гайд по цифровой доступности, на который мы также опирались (всем, кто только ступает на путь цифровой доступности, рекомендуем ознакомиться).

4. CustDev со слабовидящими и незрячими пользователями

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

Коллеги из нашей UX-лаборатории помогли организовать интервью с несколькими слабовидящими и незрячими людьми. Эти встречи помогли понять, на что необходимо обратить внимание в первую очередь при адаптации интерфейса.

Поделиться записями интервью мы не можем в силу NDA, однако для общего понимания рекомендуем посмотреть этот старый ролик Wylsacom.

5. Защита идеи перед бизнесом и формирование процесса

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

В особенности нас интересовало:

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

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

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

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

Поэтому нам потребовалось:

1. Составить и приоритезировать бэклог изменений по внедрению доступности согласно результатам аудита (исправить то, что сейчас плохо работает).
2. Заключить внутри команды договорённость о том, что теперь любая новая фича в мобильном приложении должна быть адаптирована для людей с ограниченными возможностями (доступность = неотъемлемая часть фичи).
3. Придумать набор артефактов и формат их передачи между участниками команды, которые бы отвечали на вопросы:
   
   a) как дизайнеру передать требования инклюзивности аналитику?
   b) как аналитик эти требования должен описать в ТЗ разработчику?
   c) как разработчик должен это запрограммировать?
   d) как тестировщик должен протестировать такой функционал?
   e) как менеджер должен понять, что функционал повлиял на метрики?

Аспекты, связанные с аналитикой, разработкой, тестированием и сбором метрик, мы разберём в будущих статьях (если вам будет интересно). А в этой статье далее поделимся тем, какие артефакты и правила мы создали на стороне дизайна.

При подготовке макетов к разработке мы уже придерживаемся определённого набора правил оформления.

У нас есть зафиксированный шаблон файла, чёткие инструкции по тому, что должно быть в макете, библиотека элементов оформления (заголовки, комментарии, блок-схемы, стрелки и пр.), а также строгая система именования макетов и отображения статуса их готовности. Подробнее об этом рассказали в подкасте «Дизайн Прост».

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

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

Если зайдёте в режим настроек размера шрифта в Android и iOS, то увидите ползунок с огромным числом делений. Он позволяет не только увеличивать, но и уменьшать шрифт во всей системе и в приложениях, которые поддерживают эту функцию.

В Android старых версий ползунок, как правило, содержит 4 деления, тогда как прошивки от производителя (Samsung, Xiaomi, Huawei) и Android версий 13 и выше уже предоставляют выбор из 8 и более градаций.

iOS по умолчанию отображает 7 делений, но при переключении специального свитчера количество настроек увеличивается до 12.

Чтобы правильно подготовить макет с увеличенными шрифтами, нам потребовалось разобраться, как именно ОС на обеих платформах это делает, а также договориться о каком-то базовом наборе. Ведь рисовать 20 макетов одного и того же экрана со всеми размерами шрифтов под каждую отдельную операционку — бессмысленная трата времени.

Согласно документации Google и профильным статьям, Android для обозначения размера шрифта использует масштабируемую единицу SP, которая зависит от плотности экрана, выбранного кегля и коэффициента масштабирования. То есть изменяя положение ползунка, пользователь просто меняет этот коэффициент от ~0,75 до ~1,5 — и шрифт вместе с высотой линии изменяет размеры.

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

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

Для упрощения задачи подготовки макетов мы договорились за основу взять более прозрачный подход Android и зафиксировали базовый набор из 5 коэффициентов масштабирования:

• Small (0,85)
• Normal (1,0)
  
• Large (1,14)
  
• Huge (1,28)
  
• Extreme (1,42)
  

При масштабировании мы договорились следовать этим правилам:

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

Эти правила помогают описать поведение блоков и тип их вёрстки — резиновая вёрстка с динамической высотой и шириной или фиксированная с заданными неизменными размерами.

Чтобы делать это можно было в пару кликов, мы используем плагин Text Resizer & Accessibility Checker для Figma.

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

• 12/14 (Small или 0,85)
• 14/14 (Normal или 1,0)
  
• 16/14 (Large или 1,14)
  
• 18/14 (Huge или 1,28)
  
• 20/14 (Extreme или 1,42)
  

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

Если использовать Auto Layout и Constraints в макете правильно, подготовка макета в 5 разных размерах шрифта занимает примерно 5 минут.

Операционная система предоставляет пользователю несколько режимов навигации на выбор.

По умолчанию включена навигация по элементам. В этом режиме система будет зачитывать все элементы на экране подряд сверху вниз слева направо по мере жеста скролла или при тапе.

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

Для этого все элементы интерфейса обозначаются в вёрстке так называемыми «трейтами», по которым система ориентируется на экране.

Они помогают VoiceOver и TalkBack идентифицировать элемент, понять, как с ним взаимодействовать, и определить, какую информацию в итоге зачитывать пользователю.

На Android и iOS перечень доступных трейтов зафиксирован и почти полностью идентичен на обеих платформах.

Также система может оповещать пользователя об изменениях, возникших на экране: например, пропало интернет-соединение, неверный ввод данных в поле ввода, новое всплывающее уведомление и прочее. Чтобы скринридер корректно оповестил юзера о них, используются специальные трейты-уведомления.

Если правильно разметить вёрстку, прописать корректный трейт для всех UI-элементов и уведомления об изменениях, то людям, использующим скринридер, будет удобно ориентироваться в приложении.

Для упрощения мы соотнесли перечень системных трейтов с элементами нашей дизайн-системы «Гранат».

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

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

Компонент разделён на два варианта. Первый — стандартная озвучка текста интерфейса, второй — озвучка при различных уведомлениях: ошибках, тостах, загрузках и т. д.

В макетах это выглядит примерно так: дизайнер с помощью компонента размечает по порядку каждый UI-элемент (слева направо, сверху вниз) и прописывает текст и трейт, который разработчик должен разметить для экранного ридера в коде.

Обычно разметка одного экрана занимает не более 5 минут. Скачать наш компонент можно по ссылке.

Итоги пока подводить рано, мы только в начале пути. Это первый подход к цифровой доступности для приложения «Мой МТС» — как со стороны команды дизайна, так и со стороны продукта в целом.

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

Если эта статья вызовет отклик, будем ещё делиться внутренней кухней!

Хорошего дня!