Как проверять адаптивный дизайн

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

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

Подготовьте страницу, способную выявить проблемы

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

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

Запишите, какие возможности должны сохраниться. На вымышленной странице записи на практикум посетитель должен прочитать дату, понять, где проходит мероприятие, сравнить варианты занятий и начать запись. Если узкий макет скрывает место проведения ради экономии пространства, дизайн теряет необходимые для задачи сведения, даже если композиция выглядит чище.

Выберите контрольные ширины и проверьте промежутки между ними

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

Выберите узкую, среднюю и широкую контрольные точки. Конкретные числа менее важны, чем охват условий, значимых для вашей аудитории. Для первоначальной проверки можно взять примерно 360, 768 и 1440 CSS-пикселей, а затем постепенно изменять ширину между ними.

Особенно внимательно смотрите участки изменения структуры. Шапка может свободно помещаться на большой контрольной ширине и правильно сворачиваться на маленькой, но становиться тесной непосредственно перед переключением. Блоку из трёх колонок на промежуточной ширине может требоваться больше места, чем даёт родительский контейнер. Проблема часто возникает перед точкой перелома, а не в самой точке.

Рекомендации web.dev по адаптивному дизайну предлагают привязывать изменения макета к потребностям контента, а не к названиям устройств. Примените этот принцип: зафиксируйте первую ширину, на которой компонент перестаёт работать удобно. Это даст основание для изменения и конкретное место для повторной проверки.

Полезный пример: GOV.UK сохраняет последовательность чтения

Рекомендации GOV.UK по макетам начинают с одной колонки на небольших экранах и для многих широких страниц советуют отводить две трети ширины под основной текст. В официальном примере с пропорцией две трети к одной трети тот же контент при сужении становится вертикальной последовательностью.

Заимствовать полезно связь между блоками, а не дробь. Основное объяснение остаётся первым, вспомогательный материал идёт за ним. На вашей странице юридическое условие, необходимое до оплаты, не становится второстепенным только потому, что удачно помещается в боковую колонку. Определите его роль прежде, чем копировать макет, в котором ему достанется более низкий приоритет.

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

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

Стройте проверку адаптивного дизайна вокруг задач

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

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

Пройдите страницу в процессе использования

Навигация: открыть, выбрать, закрыть, открыть снова

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

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

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

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

Порядок чтения: пройдите мобильную последовательность

Когда колонки выстраиваются в одну, порядок чтения следует проверить заново. Настольная версия может опираться на пространственные связи, которые больше не существуют. Цена рядом с объяснением может оказаться на несколько экранов от него. Подпись может начать восприниматься как описание следующего изображения вместо предыдущего.

Читайте узкую страницу сверху вниз, не сверяясь с настольным макетом. Спрашивайте себя, к пониманию чего дальше готовит каждый раздел. На странице записи сведения о занятии должны появляться до того, как посетителю предлагают его выбрать. Большое декоративное изображение между выбором и его объяснением может разорвать смысловую связь с действием.

Следите за чередующимися настольными секциями. Блок «изображение слева, текст справа», за которым следует «изображение справа, текст слева», может дать непоследовательный мобильный порядок, если реализация просто складывает исходные элементы вертикально. Определите, вводит ли каждое изображение текст или иллюстрирует его после прочтения, и сохраняйте эту связь там, где контент выполняет одинаковую роль.

Переполнение: сначала найдите причину

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

Отличайте случайное переполнение от намеренной области прокрутки. Широкая сравнительная таблица вполне может прокручиваться горизонтально внутри собственного блока. Вся страница, сдвигающаяся вбок из-за одной слишком большой иллюстрации, — другая проблема. Если горизонтальная прокрутка предусмотрена намеренно, посетитель должен замечать продолжение и сохранять понимание того, что читает.

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

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

На каждом кадрировании проверяйте смысл изображения

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

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

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

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

Держите сведения для решения рядом с элементами управления

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

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

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

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

Проверяйте формы после смены состояния

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

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

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

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

Разделяйте проблемы размещения и проблемы содержания

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

Другие сбои однозначно относятся к макету. Важные условия нельзя удалять только потому, что нынешний компонент слишком негибок. Условие отмены на странице записи может быть необходимо, даже если усложняет композицию. В зависимости от того, когда оно нужно посетителю, решением могут стать более подходящее место, раскрываемое объяснение или дополнительная высота.

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

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

Превращайте наблюдения в небольшие проверяемые правки

В одном замечании описывайте один сбой. Укажите компонент, условие и ожидаемое поведение. Например: «На средней ширине предпросмотра пункт „Место проведения“ перекрывает „Записаться“. Сворачивайте эту шапку до соприкосновения элементов; сохраните подписи и переход к записи». Такой запрос полезнее, чем «Сделайте планшетный макет лучше».

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

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

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

Завершите проверку записью, пригодной для передачи

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

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

Расставляйте нерешённые проблемы по тому, чему они мешают. Скрытое действие или нечитаемое требование может заблокировать задачу. Неловкий, но читаемый заголовок обычно менее приоритетен. Это задаёт разумный порядок следующей итерации, не объявляя визуальное качество неважным. Просто мелкая полировка не заслоняет проблемы, из-за которых люди не могут пользоваться страницей.