Инклюзивный дизайн продуктов должен быть в центре внимания каждого разработчика. Портал ITPro Today приводит несколько рекомендаций советников по облачной разработке Microsoft Рори Предди и Хенка Боелмана о том, как внедрить принципы инклюзивного дизайна в процесс создания ПО.
Сегодня существуют новые захватывающие способы сделать так, чтобы технологии стали более инклюзивными и более доступными. Ниже представлены рекомендации по разработке инклюзивных продуктов.
1. Для кого я это создаю? С кем я это создаю?
Это вопросы, которые необходимо задавать в процессе разработки ПО. Для действительно инклюзивного дизайна продукта ответ на первый вопрос должен быть «для всех». Что касается второго вопроса, то, хотя очевидно, что все не могут быть вовлечены в процесс разработки, для создания наиболее инклюзивных приложений привлекают широкий круг людей с разными способностями для тестирования UX.
Так, разработчикам стоит привлекать людей с нарушениями зрения на этапе проектирования приложений. Участие людей с различными видами инвалидности на ранних стадиях разработки позволит вам быть уверенным в том, что вы на правильном пути и вам не придется возвращаться к исходной точке позже.
2. Кто cможет этим пользоваться?
Представьте себе мобильную игру, которая является полностью визуальной: в ней нет ни звука, ни звукового описания происходящего на экране. Человек с полной потерей зрения не сможет воспринимать такую игру ни в каком виде. Аналогичным образом, игра, которая полагается на слуховые подсказки и не содержит титров, будет недоступна для глухого человека.
Разработчики должны помнить о том, что некоторые люди могут быть не в состоянии полностью или частично пользоваться их продуктом. В идеале они должны внести соответствующие изменения, чтобы каждый мог пользоваться продуктом. Примерами способов обеспечения доступности являются alt-текст, титры, возможность преобразования текста в речь и транскрипты.
3. Кого я непреднамеренно исключаю?
Если инклюзивный дизайн продукта не учитывается, разработчики могут непреднамеренно ограничить доступность своего ПО. Хотя эти ограничения являются непреднамеренными, разработчики все равно должны быть готовы взять на себя ответственность и пересмотреть свои продукты.
Пользовательское тестирование с участием людей с широким диапазоном возможностей должно дать результаты, которые подскажут вам, кого вы непреднамеренно исключаете. Следует убедиться, что у каждого есть возможность участвовать в том, что вы создаете.
4. Доступны ли функции доступности и опции для всех?
Все мы сталкивались с бесконечным поиском на сайте или в приложении, чтобы найти определенную опцию или функцию. Когда дело доходит до доступных функций, совет простой: «Не прячьте их».
Например, вряд ли вы хотите, чтобы люди, обращающиеся за помощью, использовали субтитры. Дизайн продукта должен быть очевидным.
5. Учитесь на обратной связи. Итерируйте
Прислушивание к отзывам пользователей и учет их в своем продукте требует смирения и готовности адаптироваться. Это очень важно для разработки инклюзивных и доступных продуктов.
Используйте отзывы пользователей в новых итерациях. Если вы начнете сделаете это на ранних этапах процесса, вы сможете уловить проблемы до того, как они превратятся в огромные и трудноразрешимые.
Заключение
Включение данного подхода в процесс проектирования и разработки ПО может создать дополнительную работу, но это того стоит — чтобы создавать продукты, которые действительно могут быть использованы всеми.
