Типографика онбординга в приложении: заголовок, прогресс и действие

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

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

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

Запишите черновик онбординга как последовательность ответов на вопросы: «Что это за продукт?», «Чем он полезен мне?», «Как настроить старт?», «Что произойдёт после нажатия?». Затем сгруппируйте ответы так, чтобы один экран сообщал одну главную мысль. Такой сценарий легче отредактировать, чем набор красивых, но независимых слоганов.

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

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

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

Визуальная иерархия не сводится к правилу «заголовок крупный, остальное мелкое». Различайте роли сочетанием кегля, насыщенности, длины строки, интервалов и расположения. Если заголовок, подпись и кнопка выглядят одинаково весомыми, пользователь вынужден угадывать порядок чтения. Если заголовок кричит, а пояснение едва заметно, важное условие легко пропустить. Сначала определите порядок внимания, затем подберите параметры текста в дизайн-системе.

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

Если преимуществ несколько, покажите их на отдельных карточках только тогда, когда каждая помогает принять решение. Для знакомства с функциями используйте ясные заголовки («Слова сохраняются в личном списке»), а не пустые метки («Удобно», «Быстро»). Не превращайте слайды в презентацию: человек должен иметь понятный способ продолжить, пропустить ознакомление и позднее найти настройки, если это соответствует логике продукта.

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

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

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

Расположение элементов тоже задаёт последовательность. Сначала заголовок и объяснение, затем выбор, если он нужен, после — главное действие; вторичные ссылки не должны конкурировать за первый взгляд. При этом кнопка должна оставаться в привычной и удобной зоне, а не попадать под системную клавиатуру или жестовую область. На компактном экране проверяйте весь экран целиком: перенос подписи может вытолкнуть действие за нижний край.

Онбординг часто выглядит свободным на дизайнерском макете, но теряет смысл при увеличении текста. В iOS Dynamic Type позволяет людям выбирать размер текста; рекомендации Apple советуют адаптировать компоновку к крупным размерам, сокращать обрезку и проверять смысловые значки при изменении размера. В Android для размеров текста используют масштабируемые единицы, чтобы настройки пользователя влияли на отображение. Если приложение использует собственную гарнитуру, убедитесь, что её размеры и начертания тоже корректно реагируют на системные настройки.

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

Для веб-экранов WCAG описывает критерий изменения размера текста до 200% без потери содержания или функциональности. Нативное приложение следует оценивать по правилам своей платформы и используемым технологиям доступности, поэтому не объявляйте эту веб-норму универсальным сертификатом для мобильного продукта. Но сам тест полезен как простой способ обнаружить жёсткие высоты, обрезку и зависимость от одного размера шрифта.

Допустим, приложение помогает планировать поездки, а экран предлагает собрать места из заметок. Черновик «Откройте для себя возможности умного планирования путешествий» звучит широко и не объясняет действие. Заголовок «Соберите места из заметок в один маршрут» сразу называет результат; подпись «Импортируйте сохранённые адреса — вы сможете проверить каждый перед добавлением» объясняет контроль пользователя; основная кнопка — «Выбрать заметки». Вторичная ссылка «Сделать это позже» оставляет путь выхода.

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

Перед публикацией пройдите каждый экран первого запуска и отметьте пункты:

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

**Заголовок обещает атмосферу, но не сообщает пользу.** Поэтичная фраза может подойти бренду, если подпись сразу объясняет продукт. Без этой опоры человеку приходится разгадывать, зачем приложение просит продолжить.

**Все функции показывают подряд.** Длинная серия экранов превращает первое знакомство в обязательную лекцию. Оставьте только то, что помогает начать; дополнительные советы можно показать в контексте функции.

**Кнопки называют только порядок, а не действие.** «Далее» на экране выбора может быть терпимым, но «Включить уведомления» после явного объяснения точнее говорит о результате. Системный запрос разрешения лучше объяснять до показа системного диалога, а не маскировать его общим CTA.

**Текст сокращают до телеграфного.** Отдельные слова вроде «Готовы?» и «Вперёд» экономят место, но не отвечают на вопросы. Сокращайте повторы, вводные обороты и декоративные лозунги, сохраняя субъект, действие и последствие.

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

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

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

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

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

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

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

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

Источники по поддержке крупного текста: Apple Human Interface Guidelines: Typography, Android Developers: Grids and units, W3C: Understanding Resize Text.