36
7 мин
На экране ноутбука всё было готово. Мы включили мобильный режим браузера, уменьшили ширину, отправили форму — ошибок не нашли. Затем открыли ту же страницу на iPhone: экранная клавиатура перекрыла кнопку, а после возврата из приложения с кодом подтверждения поле очистилось.
Эмуляция не была бесполезной. Она помогла быстро проверить десятки ширин. Просто у неё другая работа. Она не воспроизводит в точности клавиатуру, жесты, системные панели, звонок посреди заполнения, экономию трафика и поведение конкретного браузера. Поэтому финальную приёмку мы не заканчиваем за компьютером.
Дневник пятнадцатиминутной проверки
00:00–03:00 — первый вход
Открываем ссылку из письма или рекламной метки через мобильную сеть. Смотрим, что появляется до первого действия: баннер cookies, уведомление, чат, запрос геолокации. По отдельности каждый элемент может быть нормальным, вместе они иногда закрывают предложение.
03:00–08:00 — главное действие
Ищем услугу или вариант, открываем форму, вводим настоящую по длине фамилию, телефон и комментарий. Ошибаемся в одном поле. Переключаемся в другое приложение и возвращаемся. Нажимаем кнопку дважды, как это делает нетерпеливый пользователь.
08:00–12:00 — поворот и возврат
Поворачиваем экран, открываем меню, переходим назад, меняем масштаб текста. Нас интересует не идеальная картинка в каждом положении, а сохранение контекста: выбранный вариант не исчез, кнопки доступны, страница не перескочила в случайное место.
12:00–15:00 — результат вне сайта
Проверяем письмо, CRM или уведомление менеджера. В заявке должны быть страница, выбранная услуга и контакт. Затем звоним по номеру и открываем маршрут — сайт заканчивается не на пикселе, а на реальном действии.
Не нужно покупать двадцать устройств
Набор выбираем по фактической аудитории. Смотрим операционные системы, браузеры и разрешения в аналитике, а также устройства сотрудников и клиентов. Обычно для короткой приёмки достаточно старого небольшого Android, актуального Android среднего класса и iPhone. Облачные сервисы расширяют охват, но не заменяют хотя бы один проход руками.
| Инструмент | Для чего хорош | Чего не доказывает |
|---|---|---|
| Макет | Содержание, композиция, состояния | Работу формы и браузера |
| Эмулятор | Много ширин и быстрый поиск переполнений | Жесты, клавиатуру, реальные задержки |
| Облачный браузер | Редкие версии систем и повторяемость | Ощущение устройства в руке |
| Реальный телефон | Полный пользовательский эпизод | Покрытие всех возможных моделей |
Если проект ориентирован на недвижимость, люди часто смотрят планировки по дороге или после разговора с менеджером. В кейсе сайта застройщика мобильный трафик составлял 65%, поэтому доступ к планировкам, фотографиям стройки и форме был частью основной задачи, а не финальной адаптацией.
Как записать дефект, который действительно исправят
Плохо: «форма прыгает на айфоне». Хорошо: «iPhone, Safari, страница услуги: открыть форму, ввести телефон, перейти в сообщения, вернуться — поле пустое, кнопка скрыта клавиатурой».
К записи добавляем короткое видео, адрес страницы, модель, браузер и ожидаемый результат. Не объединяем пять ошибок в один комментарий. После исправления повторяем тот же сценарий, а не просто смотрим на обновлённый скриншот.
При разработке лендинга это занимает меньше времени, чем обсуждение дефекта по памяти. Для строительных проектов полезно добавить выбор планировки и звонок; примеры таких задач есть в разделе сайтов для застройщиков.
Когда можно выпускать
Мы не ждём отсутствия любой визуальной мелочи. Блокирующим считаем то, что не даёт понять предложение, выбрать вариант, связаться, прочитать обязательное условие или получить подтверждение. Замечания без влияния на сценарий можно вынести в план после запуска, назначив дату и ответственного.
Перед финальным решением удобно пройти чек-лист мобильной версии. Но ставить галочки должен человек с телефоном в руке. Иначе команда проверит изображение сайта, а клиент столкнётся с самим сайтом.
