Требования к UX и UI дизайну в ТЗ

Коротко: Чтобы избежать юридических рисков и переделок, требования к UX и UI дизайну в ТЗ должны включать обязательную поддержку доступности по ГОСТ Р 70176-2022. С марта 2026 года для госсектора это не рекомендация, а норма: интерфейс обязан поддерживать масштабирование текста до 200%, корректную работу экранных дикторов и наличие альтернативного описания для всего нетекстового контента.

Кстати, в AmSales мы делаем внедрение и настройку Битрикс24 и разработку сайтов под ключ под ключ. Если нужна помощь - напишите нам.

Зачем прописывать требования к UX и UI

Многие заказчики совершают одну и ту же ошибку: они заказывают "красивую картинку", забывая, что дизайн - это прежде всего функциональный инструмент. Если в техническом задании указано только "сделать современный интерфейс в стиле минимализма", вы получаете продукт, который может быть эстетичным, но абсолютно непригодным для бизнеса. Дизайнер не знает ваших бизнес-процессов, логики работы CRM или специфики пользовательских сценариев, если вы не зафиксировали их в ТЗ. Без четких требований к UX (пользовательскому опыту) вы рискуете получить интерфейс, где кнопка "Оформить заказ" находится в неудобном месте, а путь пользователя от регистрации до покупки занимает десять лишних кликов.

Проблема не только в удобстве. UI (пользовательский интерфейс) - это визуальная оболочка, которая должна работать предсказуемо. Если не прописать требования к сеткам, типографике и компонентам, разработчики будут собирать интерфейс "на коленке", что приведет к визуальному хаосу и невозможности масштабировать продукт. Когда каждый новый экран выглядит иначе, чем предыдущий, пользователь теряет доверие к сервису. Это напрямую влияет на конверсию и стоимость привлечения клиента. Чем сложнее интерфейс, тем дороже обходится его поддержка и исправление ошибок, которые вылезут на этапе тестирования.

Для B2B-сектора, где интерфейсы часто перегружены данными, отсутствие требований к UX превращается в катастрофу. Представьте оператора колл-центра или менеджера склада, который работает в вашей системе по 8 часов в день. Если интерфейс не учитывает эргономику, скорость работы падает, а количество ошибок растет. В этом случае дизайн становится не активом, а пассивом, замедляющим бизнес. Поэтому требования к UX и UI в ТЗ - это страховка ваших инвестиций в разработку.

Кроме того, стоит учитывать регуляторную среду. В 2026 году требования к цифровым продуктам стали жестче. Если вы разрабатываете решение для госсектора или крупного энтерпрайза, требования к доступности интерфейсов становятся юридически значимыми. Ошибка в ТЗ на этапе проектирования может привести к тому, что готовый продукт не пройдет проверку на соответствие стандартам, и вам придется полностью переделывать фронтенд, что в разы дороже, чем заложить правильные требования сразу.

Как составить техническое задание на дизайн: три уровня проработки

Грамотное ТЗ должно охватывать три уровня: логику, визуальную систему и технические ограничения. На уровне логики вы описываете User Flows - пути, по которым идет пользователь. Например, "Пользователь заходит в личный кабинет, выбирает тариф, переходит к оплате и получает подтверждение". На уровне визуальной системы вы задаете дизайн-систему: цвета, шрифты, отступы, состояния кнопок (hover, active, disabled). На техническом уровне - требования к адаптивности и доступности.

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

Новые стандарты доступности интерфейсов 2026

В 2026 году понятие "доступность" (accessibility) окончательно перестало быть факультативным. Если раньше на это закрывали глаза, то теперь это жесткий стандарт. Главный драйвер изменений - постановление Правительства РФ от 07.02.2026 № 102. Оно радикально изменило правила игры для всех официальных сайтов госорганов, органов местного самоуправления и их подведомственных организаций. Теперь требования к доступности информации для людей с нарушениями зрения являются обязательными и подлежат строгому контролю.

Важно понимать, что старый порядок, регулируемый приказом Минцифры № 953 от 2023 года, фактически устарел. Новые нормы гораздо масштабнее и детальнее. Теперь требования распространяются не только на "версию для слабовидящих" с увеличенным шрифтом, но и на саму архитектуру интерфейса. Это означает, что доступность должна быть заложена в ядро продукта, а не прикручена сверху в виде отдельной страницы с настройками. Если вы разрабатываете проект, который может быть классифицирован как государственный или окологосударственный, игнорирование этих норм - это прямой путь к предписаниям и штрафам.

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

В ТЗ на дизайн в 2026 году необходимо четко разделять функциональные требования и требования по доступности. Недостаточно просто написать "соответствовать ГОСТ". Нужно прописать конкретные параметры: как ведут себя элементы при навигации с клавиатуры, как работают фокусы, как реализована семантическая разметка. Без этого дизайнеры нарисуют красивые, но "немые" для программ экранного доступа интерфейсы.

Как внедрить ГОСТ Р 70176-2022 в проект

ГОСТ Р 70176-2022 - это фундамент, на котором строится современная цифровая доступность в России. Это не просто набор рекомендаций, а технический стандарт, определяющий, как именно должен быть сконструирован интерфейс, чтобы быть понятным для людей с нарушениями зрения, моторики или когнитивных функций. Внедрение этого стандарта в проект требует системного подхода, начинающегося еще на этапе сбора требований.

Первым шагом в ТЗ должно стать указание на соответствие именно этому стандарту. Это дает дизайнерам и разработчикам конкретную базу для работы. Процесс внедрения выглядит следующим образом:

1. Анализ целевой аудитории и определение необходимых уровней доступности.
2. Проектирование архитектуры контента с учетом семантической разметки (заголовки, списки, области).
3. Создание дизайн-системы, где все цветовые сочетания проходят проверку на контрастность по стандартам ГОСТ.
4. Разработка сценариев взаимодействия без использования мыши (только клавиатура).
5. Тестирование готовых компонентов с помощью программ экранного доступа (скринридеров).

На практике внедрение ГОСТа часто натыкается на сопротивление разработчиков, которые считают это "лишней нагрузкой". Однако, если требования к UX/UI дизайн требования для госсайтов прописаны корректно, разработчик получает четкий алгоритм. Например, вместо абстрактного "сделайте доступно", в ТЗ должно быть указано: "Все интерактивные элементы должны иметь видимый фокус при навигации клавишей Tab, а контрастность текста к фону должна составлять не менее 4.5:1". Это уже техническая задача, которую можно измерить и проверить.

Не стоит забывать, что ГОСТ Р 70176-2022 тесно связан с тем, как интерфейс будет интерпретироваться вспомогательными технологиями. Если вы пропустите этап проектирования семантики в ТЗ, то на этапе верстки окажется, что кнопка на самом деле является просто текстовым блоком с цветом, и ни один скринридер не поймет, что на нее можно нажать. Это фундаментальная ошибка, которую крайне сложно исправлять в готовом коде.

Масштабирование контента и поддержка экранных дикторов

Одним из ключевых требований, вступивших в силу 1 марта 2026 года, является обязательное масштабирование контента. Согласно постановлению № 102, текст на официальных ресурсах должен масштабироваться не менее чем на 200% от исходного размера без потери функциональности и без необходимости использования специальных вспомогательных технологий. Это значит, что при увеличении шрифта верстка не должна "разваливаться", элементы не должны накладываться друг на друга, а горизонтальная прокрутка не должна появляться там, где она не предусмотрена.

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

Второй важнейший аспект - поддержка экранных дикторов (скринридеров). Эти программы озвучивают содержимое экрана для людей с нарушениями зрения. Чтобы интерфейс был "читаемым" для диктора, он должен иметь правильную иерархию. В ТЗ необходимо зафиксировать требования к использованию ARIA-атрибутов (Accessible Rich Internet Applications) и правильной семантике HTML-тегов. Например, заголовок должен быть именно тегом <h1>, а не просто крупным текстом, оформленным через CSS. Если разработчик проигнорирует это, пользователь скринридера просто "заблудится" в интерфейсе, не понимая, где заканчивается меню и начинается основной контент.

Для эффективной работы экранных дикторов крайне важна логика фокуса. Когда пользователь нажимает Tab, фокус должен перемещаться в предсказуемом порядке: сверху вниз, слева направо. В ТЗ нужно отдельно прописать правила управления фокусом для сложных компонентов, таких как модальные окна, выпадающие списки или карусели. Если при открытии модального окна фокус остается на фоновой странице, пользователь скринридера не поймет, что перед ним появилось новое окно, и не сможет с ним взаимодействовать. Это классический пример провала в UX, который делает продукт недоступным.

Таблица: Сравнение требований к масштабированию и доступности

Альтернативный текст для нетекстового контента

Визуальный контент - это не только картинки, это графики, иконки, схемы и инфографика. С 1 марта 2026 года требования к нетекстовому контенту стали предельно жесткими: он должен сопровождаться альтернативным текстовым описанием. Это описание должно быть таким, чтобы его можно было легко преобразовать в увеличенный шрифт, шрифт Брайля, речь или даже в упрощенный язык для людей с когнитивными особенностями.

В ТЗ на дизайн нельзя просто написать "добавить alt-тексты". Это слишком размыто. Нужно прописать требования к качеству этих описаний. Например, для декоративной иконки (которая не несет смысловой нагрузки) alt-текст должен быть пустым, чтобы скринридер ее игнорировал. Но для иконки "Корзина", которая служит кнопкой, описание должно быть функциональным: "Перейти в корзину". Если иконка заменяет текст, она обязана его дублировать в доступной форме.

Особое внимание стоит уделить сложным элементам, таким как инфографика или графики. В 2026 году недостаточно просто написать "График роста продаж". Хорошее ТЗ требует, чтобы к сложному визуальному элементу прилагалась текстовая интерпретация данных. Это может быть скрытая таблица, которую считывает скринридер, или развернутое текстовое описание ключевых точек графика. Это обеспечивает реальную доступность, а не формальное выполнение требований.

Еще один нюанс - использование изображений как носителей информации. Если на картинке написан важный текст (например, на баннере акции), этот текст должен быть продублирован в alt-атрибуте или в текстовом блоке рядом. Если информация содержится только в картинке и не имеет текстового эквивалента, интерфейс считается недоступным. В ТЗ стоит зафиксировать правило: "Любая информация, передаваемая визуально, должна иметь текстовый эквивалент в коде".

Типичные ошибки при описании UI в ТЗ

Ошибки в ТЗ стоят дорого. Самая распространенная - это использование субъективных эпитетов. "Красивый", "легкий", "современный", "чистый" - это слова, которые не имеют технического измерения. Дизайнер может интерпретировать "чистый дизайн" как обилие пустого пространства, а заказчик - как отсутствие лишних деталей в интерфейсе. В итоге результат не совпадает с ожиданиями, и начинается бесконечный цикл правок.

Вторая критическая ошибка - отсутствие описания состояний элементов. Часто в ТЗ прикладывают только "идеальные" макеты. Но интерфейс - это живая среда. Что происходит с кнопкой, когда на нее навели курсор? Как выглядит поле ввода, если пользователь ввел некорректные данные (ошибка валидации)? Как отображается загрузка данных (скелетоны или спиннеры)? Если эти состояния не описаны, разработчики будут реализовывать их на свое усмотрение, что приведет к разрыву пользовательского опыта.

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

Наконец, отдельная категория ошибок - игнорирование технических ограничений. Например, требование использовать сверхтяжелые анимации или высокодетализированные изображения без учета скорости загрузки на мобильных устройствах или ограничений пропускной способности сети. В ТЗ должны быть четко прописаны требования к весу ресурсов и форматам (например, использование WebP для изображений), чтобы дизайн не убил производительность системы.

Чек-лист проверки требований к доступности

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

• Указано ли в ТЗ соответствие ГОСТ Р 70176-2022?
• Прописано ли требование о масштабировании контента до 200% без потери функциональности?
• Определены ли требования к контрастности текста и графических элементов (не менее 4.5:1)?
• Зафиксирована ли необходимость использования семантической разметки (H1-H6, nav, main, article)?
• Описаны ли правила навигации с помощью клавиатуры (порядок фокуса, видимый фокус)?
• Установлено ли требование к наличию альтернативного текста (alt) для всех значимых изображений?
• Предусмотрены ли текстовые эквиваленты для сложных графиков и инфографики?
• Прописаны ли требования к поддержке программ экранного доступа (ARIA-атрибуты)?
• Есть ли в ТЗ описание состояний элементов (hover, focus, active, error, loading)?

Если хотя бы на один пункт вы не можете ответить "да" - ТЗ требует доработки. Помните, что в современных реалиях доступность - это не "фича", а базовое требование к качеству любого цифрового продукта, особенно если вы планируете работать с государственным сектором или крупным бизнесом.

Что запомнить

• С 1 марта 2026 года требования к доступности для госсектора стали обязательными по постановлению № 102.
• ГОСТ Р 70176-2022 - это основной стандарт, на который нужно опираться при проектировании интерфейсов.
• Масштабирование текста должно работать до 200% без поломки верстки.
• Доступность должна закладываться на этапе проектирования UX, а не добавляться в конце разработки.
• ТЗ на дизайн должно содержать конкретные технические параметры, а не субъективные описания.