Inclusive design: когда проектируешь для меньшинства — выигрывают все

Бордюр на тротуаре — мелочь, пока ты не на коляске, не с коляской и не с тяжёлым чемоданом. Стоит срезать угол под пандус — и им начинают пользоваться все: курьеры, родители, доставка, человек после операции. Это и есть весь inclusive design в одной картинке.

Дизайнеры часто слышат «доступность» и думают про слепых пользователей и скринридеры. Это правда, но это меньше половины истории. Inclusive design — про то, что любой человек в любой момент может оказаться в ситуации, для которой интерфейс не рассчитан. Сломанная рука. Громкое метро. Старый телефон в роуминге. Уставший мозг в час ночи. Если продукт работает только для бодрого, зрячего, праворукого пользователя на свежем MacBook — он работает для меньшинства, а не для большинства.

---

## Доступность, адаптивность, инклюзивность: не одно и то же

Эти слова часто валят в кучу, и от этого разговор разваливается.

Доступность (accessibility) — соответствие конкретным критериям: контраст, фокус, альт-тексты, навигация с клавиатуры. Это про чеклист и WCAG.

Адаптивность — про устройства и контексты: экран, ввод, скорость сети.

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

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

---

## Почему «крайний случай» — это не крайний случай

В продуктовых обсуждениях быстро всплывает фраза «это edge case, у нас таких 2%». Проблема в том, что эти 2% складываются.

• 2% с нарушением зрения
• 4% с плохим интернетом
• 7% с устаревшим устройством
• 10% не на родном языке интерфейса
• 15% с ситуативным ограничением прямо сейчас (ребёнок на руках, шум, спешка)

Это не один и тот же человек. В сумме «крайний случай» — это больше половины аудитории в произвольный момент времени. Когда команда отказывается чинить «редкий» сценарий, она обычно режет не 2%, а кусок воронки, который потом не сходится в метриках и никто не понимает почему.

### Анти-паттерны на ревью

• «Это для слепых, у нас их нет» — у вас их нет потому, что им неудобно
• «Сделаем потом отдельной задачей» — отдельная задача никогда не приезжает
• «Поправим, если будут жалобы» — недовольные пользователи не жалуются, они уходят
• «Это снизит конверсию у основной аудитории» — почти всегда оказывается наоборот

---

## Принцип curb-cut: проектируй для края, выигрывают все

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

Закономерность простая: ограничение заставляет искать решение, которое уменьшает трение в принципе. Если интерфейс понятен человеку с когнитивной усталостью — он понятен и уставшему сеньору-разработчику в пятницу вечером.

### Как применить в работе

• Берёшь сценарий и спрашиваешь: «Кто здесь не справится?»
• Для каждого «не справится» ищешь причину: восприятие, моторика, контекст, язык, опыт
• Чинишь причину так, чтобы не создать отдельную «версию для инвалидов»
• Проверяешь, что фикс улучшает основной сценарий, а не утяжеляет его

Если фикс ухудшает основной сценарий — обычно он сделан неправильно. Хороший inclusive-фикс почти всегда упрощает интерфейс, а не нагружает его.

---

## Кого вы исключаете прямо сейчас: быстрый аудит

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

### Сценарии для прогона

• Только клавиатура. Можно ли пройти флоу не трогая мышь и тачпад?
• Скринридер на 10 минут. Включить VoiceOver/TalkBack и попробовать дойти до результата
• Одна рука. Большим пальцем на телефоне, второй рукой держишь кофе
• Плохой свет. Уменьшить яркость экрана наполовину, выйти на улицу
• Медленный интернет. Throttling до 3G в девтулзах
• Не родной язык. Переключить интерфейс на язык, которым владеешь плохо
• Когнитивная нагрузка. Пройти флоу параллельно слушая подкаст

### Вопросы для ревью после прогона

• На каком шаге впервые захотелось бросить?
• Где интерфейс предположил то, чего у пользователя нет?
• Какая ошибка не объяснила, что делать дальше?
• Что выглядело необязательным, но оказалось блокером?
• Какой текст пришлось перечитывать дважды?

Короткий итог: inclusive design — это не отдельный трек «для особых пользователей», это способ найти места, где продукт хрупкий. Чинишь край — укрепляется середина.

## Рабочий процесс: как вшить инклюзивность в обычный дизайн-флоу

Главная ошибка — относиться к инклюзивности как к отдельному этапу «после макета». Это как пытаться добавить фундамент к уже построенному дому. Инклюзивность работает только если она встроена в те же шаги, что и обычное проектирование: исследование, скетч, макет, ревью, передача в разработку.

### Этап 1: формулировка задачи

В брифе на любой флоу должны появиться три строчки рядом с основной целью:

• Кто пользователь в худшем сценарии (плохой свет, шум, спешка, чужой язык)
• Какое ограничение мы НЕ закладываем (например: «не требуем смартфон последних трёх лет»)
• На каком устройстве и в каком контексте флоу должен работать минимально приемлемо

Без этого все последующие решения молча оптимизируются под «себя за макбуком в тихом офисе».

### Этап 2: скетч и каркас

На уровне wireframe инклюзивность — это в основном про структуру и приоритет.

• Один основной CTA на экран, остальное — вторично
• Логика читается сверху вниз без иконок и цвета
• Любая ошибка имеет место, где её можно показать рядом с причиной
• Любое поле формы переживает удвоение длины текста (немецкий, перевод, длинное имя)
• Есть путь назад с каждого шага, и он не уносит введённые данные

Если каркас разваливается без иконок и без цвета — это не каркас, это раскраска.

### Этап 3: визуальный макет

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

• Контраст текста к фону проходит AA, для крупного — минимум 3:1
• Тач-таргеты не меньше 44×44, между ними есть воздух
• Состояние focus видно без щурения, не только hover
• Цвет никогда не единственный носитель смысла (ошибка не только красная — у неё есть текст и иконка)
• Шрифт читается на 13–14px на средненьком телефоне, а не только на ретине
• Иерархия работает в чёрно-белом скриншоте

### Этап 4: тексты и микрокопия

Это часть макета, которую дизайнеры почему-то отдают «потом напишем». А именно здесь чаще всего происходит исключение.

• Плейсхолдер не заменяет лейбл — он исчезает, когда нужнее всего
• «Введите корректный email» — это не ошибка, это упрёк. Скажи, что именно не так
• Не пиши «просто», «легко», «всего один клик» — для кого-то это не так
• Поля «имя» и «фамилия» — почти всегда должны быть одним полем «как к вам обращаться»
• Обращение на «вы» / «ты» — осознанное решение, а не наследие шаблона

---

## Диагностика готового макета: 15-минутная проверка

Когда макет уже есть, прогоняй его по короткому протоколу перед тем, как отдавать в разработку.

### Шесть быстрых тестов

1. Скриншот в градации серого. Всё ещё понятно, где что?
2. Размытие 5px. Видна ли иерархия и где основное действие?
3. Только Tab по прототипу. Доходишь до конца без застреваний?
4. Удвоение длины всех строк. Ничего не ломается, не обрезается, не наезжает?
5. Прокрутка одним пальцем на телефоне в одной руке. Большой палец дотягивается до главного?
6. Чтение вслух всех текстов подряд. Звучит как человек или как форма из госуслуг?

Если какой-то тест валится — это не «к лучшему позже», это правка сейчас. Большинство фиксов занимает меньше времени, чем спор о них.

### Вопросы для дизайн-ревью

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

---

## Типичные ошибки, которые проще всего не совершать

• Accessibility-режим отдельной кнопкой. Если у тебя есть «версия для слабовидящих» — основная версия плохая. Чини основную
• Капча, которую нельзя пройти со скринридером. Альтернатива должна быть в той же точке, а не «напишите в поддержку»
• Модалки без фокус-трапа и без Esc. Клавиатурный пользователь застревает навсегда
• Иконка без подписи. Если значение не очевидно за полсекунды — нужен текст
• Анимации без prefers-reduced-motion. Для части людей это буквально вызывает тошноту
• Сообщения об ошибке только цветом рамки. Скринридер не видит цвет, дальтоник не отличит красный от серого

### Короткий итог сегмента

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

## Продвинутые сценарии: где обычный чеклист уже не справляется

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

### Множественные ограничения одновременно

Реальный пользователь редко «просто слабовидящий» или «просто на клавиатуре». Чаще — человек на солнце, с одной рукой занятой ребёнком, на 4G в метро, с увеличенным шрифтом в системе на 130%.

Полезные сценарии для прогона макета:

• Скринридер + увеличение шрифта 200% — не разъезжается ли layout
• Клавиатура + сужение окна до 320px — остаются ли все действия достижимыми
• Голосовой ввод вместо клика — есть ли у элементов внятные доступные имена
• Высокий контраст системы (Windows / macOS) — не исчезают ли границы и иконки, нарисованные одним только бэкграундом

Если хотя бы один сценарий разваливает интерфейс — это не «крайний случай», это точка, где вы теряете тихих пользователей без жалоб.

### Контекст важнее диагноза

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

• Одна рука занята — большой палец и нижняя зона экрана
• Шумно — субтитры по умолчанию, а не «включите если надо»
• Тихо — звук не единственный сигнал уведомления
• Английский не родной — короткие предложения, без идиом, термины расшифрованы при первом появлении
• Стресс или усталость — критичные действия имеют подтверждение и откат

## AI в инклюзивном дизайне: что реально помогает, а что вредит

LLM и встроенные в Figma ассистенты ускоряют рутину, но создают новый класс ошибок: правдоподобный мусор, который выглядит как нормальный интерфейс.

### Где AI работает хорошо

• Переписать упрекающую ошибку в человеческую («Введите корректный email» → «Похоже, в адресе пропущена @»)
• Сгенерировать длинные локализации для стресс-теста полей (немецкий, финский, арабский)
• Предложить альтернативный текст для иконок и иллюстраций — как черновик, не как финал
• Прогнать копию на читаемость и упростить до уровня 6–7 класса
• Описать макет словами для проверки «понятно ли это без зрения» — если AI не может объяснить экран, скринридер тоже не сможет

### Где AI стабильно подводит

• Выдумывает доступные имена, которых нет в коде
• Генерирует «accessible» цвета, которые на самом деле не проходят AA на реальных фонах
• Уверенно объясняет несуществующие правила WCAG
• Предлагает alt-текст вида «изображение, на котором изображено» — формально есть, по сути бесполезно

Правило простое: AI-результат по доступности всегда проверяется инструментом или человеком, который умеет тестировать руками. Сгенерированный alt без ревью — хуже отсутствующего, потому что создаёт ложное чувство, что задача закрыта.

### MCP, плагины и автоматические проверки

Если у команды настроен пайплайн с MCP-сервером или плагинами в Figma — туда логично завести: контраст-чекер, проверку размеров тач-таргетов, линтер на текст «нажмите сюда» и «узнать больше». Это снимает споры на ревью: либо проходит, либо нет.

Что туда не стоит завозить: автоматическую генерацию alt без человека в цикле и «AI accessibility audit» как единственный отчёт перед релизом. Инструмент ловит механику, не смысл.

## Как объяснить решение команде, не превращаясь в полицию доступности

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

### Переводи на язык собеседника

• Продакту: «этот фикс закрывает сегмент, который сейчас отваливается на шаге 2, по поддержке это N тикетов в месяц»
• Разработчику: «это semantic HTML, не отдельный режим, кода будет меньше»
• Дизайнеру: «контраст не ограничивает палитру, он отсекает сочетания, которые и так выглядели мутно»
• Маркетингу: «субтитры — это ещё и просмотры без звука в ленте»

### Аргументы, которые работают на ревью

• Показать тот же экран глазами скринридера или в градации серого — короткое видео убеждает быстрее презентации
• Привязать правку к конкретному сценарию пользователя, не к параграфу WCAG
• Предложить вариант, а не только запрет: «вот так — и проходит, и выглядит так же»
• Считать стоимость переделки сейчас vs. после релиза — она всегда не в пользу «потом»

### Антипаттерны коммуникации

• Ссылаться на закон, когда команда не в юрисдикции, где он применяется
• Спорить про «правильно по WCAG» вместо «работает для пользователя»
• Приносить список из 40 замечаний без приоритета — это игнорируется целиком
• Делать вид, что у тебя нет компромиссов: они есть, и честнее проговорить, что мы сейчас не закрываем и почему

### Короткий итог сегмента

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

## Чеклист: инклюзивный дизайн на ревью макета

Это не WCAG-аудит, а быстрый прогон, который реально успеть за 10–15 минут перед отправкой в разработку.

### Контраст и цвет

• Текст и иконки проходят AA на реальных фонах, не на белом из палитры
• Ни одно состояние (ошибка, успех, выбрано) не передаётся только цветом
• Фокус виден на любом фоне, включая тёмные изображения
• Дизейблед-состояние отличается не только прозрачностью

### Текст и язык

• Заголовки кнопок описывают действие, а не «Подтвердить», «ОК», «Узнать больше»
• Ошибки объясняют, что сделать, а не констатируют провал
• Сокращения и термины расшифрованы при первом появлении
• Тон не упрекает пользователя

### Структура и навигация

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

### Моторика и ввод

• Тач-таргеты не меньше 44×44 на мобильном
• Критичные действия имеют подтверждение и откат
• Нет жестов без альтернативы кнопкой
• Таймеры либо отключаются, либо продлеваются

### Медиа

• У видео есть субтитры, у аудио — транскрипт
• У осмысленных изображений — alt по сути, у декоративных — пустой alt
• Автоплей без звука, движение можно остановить

## Анти-паттерны, которые маскируются под доступность

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

### Отдельный «доступный режим»

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

### Контраст ради галочки

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

### Alt-текст ради присутствия

«Изображение», «фото», «иконка кнопки» — формально атрибут есть, по факту скринридер озвучивает мусор. Лучше пустой alt у декоративного изображения, чем заглушка.

### Тултипы как основное объяснение

Если ключевая информация живёт только в тултипе по ховеру — её нет для тача, клавиатуры и скринридера. Тултип — это подсказка, не контент.

### Капча без альтернативы

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

### «Мы починим в следующем спринте»

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

## Вопросы для дизайн-ревью

Эти вопросы стоит держать перед глазами, когда смотришь чужой макет или свой через день.

• Что произойдёт, если у пользователя одна рука занята?
• Что увидит человек, который читает экран сверху вниз без цвета?
• Как этот экран звучит для скринридера — в каком порядке и какими словами?
• Если убрать иконки, всё ещё понятно, что делает каждая кнопка?
• Что случится, если текст вырастет в полтора раза при переводе?
• Какой шаг здесь самый дорогой по откату — и есть ли защита от случайного клика?
• Где пользователь застрянет, если интернет тормозит и половина не загрузилась?
• Кому этот экран будет неудобен — и осознанное ли это решение?

Если на любой из вопросов отвечаешь «не знаю» — это место для прототипа в коде или прохода с реальным ассистивным инструментом, а не для догадок.

## Практический итог

Инклюзивный дизайн — это не отдельная дисциплина рядом с продуктом, а способ принимать обычные решения с учётом большего числа людей. Контраст, размер тач-таргета, формулировка ошибки и порядок фокуса — это не «доступность», это просто хорошо сделанный интерфейс.

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