3. СОБИРАЕМ КОМАНДУ

Авторы: Г. Г. Жур, О. В. Линник, Т. Н. Миронова, А. А. Орлова
Время чтения: 12 мин.

КРАТКОЕ СОДЕРЖАНИЕ

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

3.1 СДЕЛАТЬ ИНКЛЮЗИЮ ПРИОРИТЕТОМ ДЛЯ ЧЛЕНОВ КОМАНДЫ

Хотя требования по доступности цифрового контента содержатся в ГОСТе, для большинства ИТ-специалистов в России доступность не ассоциируется с конкретными требованиями, которые обязательны к исполнению. Инициативы по тестированию сервисов на доступность в России единичны. Вполне возможно, что в команде не окажется готовых специалистов по доступности, но это не должно быть препятствием для ее внедрения.
Подобные исследования проводит, например, инклюзивный проект Everland. См.: Павликова С. Продолжаем проверять онлайн на доступность для незрячих: исследование Everland // VC. ru.
Доступности нужно учиться, вовлекая в это обучение всю команду, всех, кто принимает участие в разработке и тестировании продукта.
Подробнее об обучении см. раздел 4.5.
Во Франции подразделение Межведомственной дирекции по цифровому развитию, которое занимается дизайном цифровых услуг, разработало игру-фреймворк для команд, внедряющих принципы доступности в работу цифрового сервиса. Игра состоит из девяти блоков с интерактивными карточками, над которыми команде предстоит работать в течение нескольких дней. Так, первый блок — «Разбираемся в теме» — помогает команде определить целевую аудиторию своего сервиса и увидеть, насколько она разнообразна, а также ответить на вопрос, почему сервис должен быть доступным. Карточки содержат полезные ресурсы, которые помогут лучше понять проблемы, с которыми сталкиваются люди с ОВЗ, позволят обучить команду, провести аудит разного уровня и организовать непрерывную работу над доступностью.

Во Франции подразделение Межведомственной дирекции по цифровому развитию, которое занимается дизайном цифровых услуг, разработало игру-фреймворк для команд, внедряющих принципы доступности в работу цифрового сервиса. Игра состоит из девяти блоков с интерактивными карточками, над которыми команде предстоит работать в течение нескольких дней. Так, первый блок — «Разбираемся в теме» — помогает команде определить целевую аудиторию своего сервиса и увидеть, насколько она разнообразна, а также ответить на вопрос, почему сервис должен быть доступным. Карточки содержат полезные ресурсы, которые помогут лучше понять проблемы, с которыми сталкиваются люди с ОВЗ, позволят обучить команду, провести аудит разного уровня и организовать непрерывную работу над доступностью.
Le jeu de l’OAA // DesignGouv.
Распространенная проблема с доступностью заключается в том, что, хотя формально все поддерживают обеспечение доступности, инклюзия не попадает в список приоритетов команды. Кроме того, дизайнеры и разработчики часто не являются экспертами в области доступности. В результате при проектировании вопросы доступности даже не возникают: специалисты не задумываются о том, как это важно, или не знают, как решить эту задачу.
Создавая цифровые сервисы, специалист использует свой предыдущий опыт, знания, навыки и представления об удобстве сервиса. Именно поэтому так важно, чтобы все члены команды имели хотя бы базовое представление о доступности, как минимум знали основные типы ОВЗ и связанные с ними особенности взаимодействия пользователей с электронными сервисами.
«Прежде чем помогать пользователям, нужно понять, что именно вы собираетесь делать. Разработчикам нужно научиться пользоваться скринридером, разобраться с его навигацией, посмотреть видео, где незрячие люди рассказывают о том, как пользуются этим инструментом».

Михаил Рубанов,
автор книги «Про доступность iOS»
Чтобы создавать инклюзивные, доступные, клиентоориентированные решения, нужны эмпатия, внимание к деталям и любопытство.
Жительница Индии Милеха Сонеджи (Mileha Soneji) придумала оригинальное решение для своего дяди, который из-за болезни Паркинсона может ходить по ровной поверхности только с ходунками. Наблюдая за ним, девушка с удивлением увидела, что по лестнице дядя идет свободно благодаря эффекту непрерывного движения. Тогда она она создала иллюзию, нарисовала лестницу на плоской поверхности. Этот спецэффект сильно облегчил ее родственнику жизнь. Подобные примеры Валерия Курмак собирает в своем Telegram-канале «Не исключение».

Жительница Индии Милеха Сонеджи (Mileha Soneji) придумала оригинальное решение для своего дяди, который из-за болезни Паркинсона может ходить по ровной поверхности только с ходунками. Наблюдая за ним, девушка с удивлением увидела, что по лестнице дядя идет свободно благодаря эффекту непрерывного движения. Тогда она она создала иллюзию, нарисовала лестницу на плоской поверхности. Этот спецэффект сильно облегчил ее родственнику жизнь. Подобные примеры Валерия Курмак собирает в своем Telegram-канале «Не исключение».
Наблюдение за повседневной жизнью людей с инвалидностью, эксперименты с завязыванием глаз или перемещением на колясках, которые проводят маркетологи, полезны для развития эмпатии у членов команды, но не дают инструментов, которые помогли бы сделать продукт понастоящему доступным.
Знание того, в чем заключается доступность и как ее обеспечить, должно быть частью профессиональных компетенций каждого из членов команды. Работу по обеспечению доступности можно вести как силами имеющейся команды, так и с привлечением внешних специалистов на разовые задачи. В небольших командах задачи дизайнеров, разработчиков и тестировщиков могут быть отданы на аутсорс. В этом случае отвечать за доступность будет менеджер, который заказывает продукт. У него должен быть достаточный уровень экспертности, чтобы включить в ТЗ пункт о соответствии ГОСТу (см. раздел 2.4), а затем организовать тестирование и доработку продукта.
При создании продукта может быть полезен такой инструмент, как дизайн-мышление: он позволяет изучать опыт человека или группы людей, анализировать его, синтезировать, проектировать, создавать первые прототипы, тестировать их и выпускать MVP продукта или сам продукт.
Чтобы повысить шансы на создание универсального и доступного продукта, важно позаботиться о разнообразии профессионального, культурного и личного опыта команды.
«Мы стараемся набирать максимально разнообразные по составу команды. Например, мы объединяем специалистов по цифровым технологиям, педагогов и специалистов по социальным медиа для того, чтобы создать руководство по медийно-информационной грамотности для учителей. Конечно, непросто организовать слаженную работу людей, значительно разнящихся по опыту, профессии, сфере деятельности или возрасту. При этом мы сталкиваемся с тем, что люди не просто пользуются разной терминологией, они по-разному видят мир. Интегрировать порой диаметральные позиции сложно, но это очень полезная работа».

Татьяна Мурована,
программный специалист ИИТО ЮНЕСКО
Владельцу продукта полезно изучить целевую аудиторию сервиса и оценить, какую долю в нем могут составить люди с особыми потребностями, которым, к примеру, потребуется скринридер или функции увеличения текста.
«У нас есть заказы от незрячих людей, сейчас их около 20 в неделю. После адаптации приложения количество заказов от незрячих людей выросло вдвое. Мы довольно поздно начали собирать эти цифры. Скорее всего, незрячие клиенты были и раньше, но они не могли сделать заказ, потому что на каком-то этапе сталкивались с неразрешимыми проблемами. Мы собираем эту статистику с помощью настройки в телефоне, которая говорит о том, что скринридер запущен. Примерно 10% наших клиентов имеют проблемы со зрением и пользуются функциями увеличения текста и повышения контрастности. Мы заметили, что средний чек у них выше».

Михаил Рубанов,
автор книги «Про доступность iOS»
Если адаптировать основной сервис под какую-то узкую категорию пользователей не удается, то необходимо предоставить таким пользователям альтернативный способ решения их проблемы. Например, вместо поиска адресов на карте предложить поиск в списке.

3.2 КТО ОБЕСПЕЧИВАЕТ ДОСТУПНОСТЬ: РОЛИ И ФУНКЦИИ

Говоря о ролях и функциях при обеспечении доступности, мы не используем названия должностей или стандартных ролей, а лишь обозначаем роль, которую играет специалист в процессе обеспечения доступности. Состав команды, должности и функции могут существенно различаться в разных организациях. Александра Вельянинова, главред «Райффайзенбанка» и экс-главред команды клиентского сервиса «Яндекс Go», считает, что в работе над цифровыми продуктами актуальна схема из трех ключевых компетенций: дизайна, редактуры и исследований. В небольших командах эти компетенции может совмещать один специалист. А специалист по UX на мобильных устройствах компании Google Анна Потанина отметила, что в Google над UX работают разные специалисты: дизайнеры, исследователи, инженеры, менеджеры.
Приведем примерный список ролей.
1
Амбассадор доступности, идейный вдохновитель, выступает драйвером темы и продвигает ее среди коллег. Эту роль может исполнять любой член команды, например владелец продукта, проектировщик или дизайнер. Он должен получить представление о том, что такое доступность сайта, о том, как пользуются электронными сервисами незрячие люди, люди с нарушениями моторики. Важно, чтобы он обладал авторитетом в команде. Свой амбассадор доступности может быть в каждом подразделении.
2
Руководитель (руководитель организации или подразделения) дает согласие на обеспечение доступности сервиса, выделяет на это ресурсы.
3
Менеджер (менеджер проекта, владелец продукта, руководитель подразделения разработки) отвечает за весь процесс, в том числе и за доступность, учитывает доступность при создании функциональных возможностей сервиса. Следит, чтобы дизайнер потратил время на контрастность, разработчик учел доступность в коде и т. п. Также отвечает за организацию службы поддержки (шаблоны, скрипты и т. п.).
4
Дизайнер вместе с менеджером продумывает функциональность, проектирует пользовательский опыт в интерфейсе, закладывает логику навигации и взаимодействия. Должен быть в курсе требований к инклюзивному дизайну, при создании интерфейса должен учитывать особенности восприятия разных групп людей.
5
Разработчик дизайн-системы (команда, создающая дизайн-систему, может включать как дизайнеров, так и разработчиков) придумывает, как учесть требования доступности в дизайн-системе.
«Любая продуктовая работа, если мы говорим про большие компании, — это тесная связка дизайнера и разработчика. Предположим, макет сделан по всем нормам, контрастный, все понятно, легкая простая структура, но его можно сверстать абсолютно недоступно, а можно сверстать доступно. Тут очень многое зависит от разработчика».

Евгений Кузнецов,
дизайн-лид компании Сбер
6
Редактор интерфейсов (UX-райтер) на этапе макета продумывает функции и названия кнопок, то, как они будут озвучены для незрячих людей. Его задача — объяснить пользователю с помощью текста, как работает продукт.
Команда редакторов может состоять из трех групп специалистов: продуктовых редакторов (отвечают за весь продукт, знают о нем все, пишут все тексты для интерфейса и коммуникаций по этой теме), UX-райтеров (отвечают за интерфейсы и связанные с ними действия, в частности push-оповещения) и коммуникационных редакторов (отвечают за разнообразные коммуникационные тексты от писем и СМС до билбордов и скриптов поддержки).

Команда редакторов может состоять из трех групп специалистов: продуктовых редакторов (отвечают за весь продукт, знают о нем все, пишут все тексты для интерфейса и коммуникаций по этой теме), UX-райтеров (отвечают за интерфейсы и связанные с ними действия, в частности push-оповещения) и коммуникационных редакторов (отвечают за разнообразные коммуникационные тексты от писем и СМС до билбордов и скриптов поддержки).
7
Разработчик, получив макет, пишет код так, чтобы люди с ОВЗ могли полноценно пользоваться сервисом. В некоторых компаниях в ответственность разработчика входят автотесты.
8
Тестировщик проверяет результат работы команды и сообщает менеджеру, насколько доступным получился сервис.
9
Специалисты службы поддержки помогают пользователям с различными особенностями быстро получить электронную услугу. Современные электронные сервисы часто являются единственным каналом получения жизненно важных услуг, поэтому у клиентов должна быть возможность в сложных случаях обратиться не к роботу, а к сотруднику, который имеет достаточно полномочий, чтобы решить проблему.
Лучшие решения, касающиеся поддержки пользователей сервиса, предполагают три уровня взаимодействия.
  • Робот пока умеет не все, будет рад помочь, а если нет, даст быстрый доступ к оператору.
  • Оператор решает более сложные задачи, у него не скрипт, а какие-то рамки, например темы и вопросы, за которые он отвечает.
  • Служба «ангелов» состоит из специалистов, имеющих более широкие полномочия, решающих сложные вопросы.
Как выглядит качественная работа трехуровневой системы? В 2019 году клиенту банка потребовалось снять крупную сумму денег в Подмосковье, чтобы оплатить покупку земельного участка. Клиент позвонил в банк, ему ответил робот, переключил на оператора. Оператор сообщил, что возможности заказать к завтрашнему дню нужную сумму нет. Когда клиент возразил, что в этом случае у него сорвется сделка, его переключили на «ангела». Тот смог решить проблему, заказав нужную сумму в отделение банка в соседнем городе. Решая проблему, специалист звонил клиенту четыре раза, а на следующий день проверил, что тот смог получить деньги.

Как выглядит качественная работа трехуровневой системы? В 2019 году клиенту банка потребовалось снять крупную сумму денег в Подмосковье, чтобы оплатить покупку земельного участка. Клиент позвонил в банк, ему ответил робот, переключил на оператора. Оператор сообщил, что возможности заказать к завтрашнему дню нужную сумму нет. Когда клиент возразил, что в этом случае у него сорвется сделка, его переключили на «ангела». Тот смог решить проблему, заказав нужную сумму в отделение банка в соседнем городе. Решая проблему, специалист звонил клиенту четыре раза, а на следующий день проверил, что тот смог получить деньги.