Продуктовый дизайн мобильных приложений по HIG и Material Design

Роль продуктового дизайна и сравнение HIG и Material

Зачем мобильному продукту нужен продуктовый дизайн

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

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

Ключевые результаты, за которые обычно отвечает продуктовый дизайн:

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

Конверсия в ключевые действия (регистрация, покупка, публикация, подписка)

Удержание и привычка (возврат в продукт)

Снижение когнитивной нагрузки и ошибок

Доступность для разных пользователей и контекстов

Чем продуктовый дизайн отличается от UI и UX

Термины часто смешивают, но в курсе мы будем опираться на практичное разделение:

UX-дизайн — проектирует логику взаимодействия: сценарии, информационную архитектуру, пользовательские потоки, тексты и состояния.

UI-дизайн — отвечает за визуальную систему и интерфейсные паттерны: композицию, типографику, сетки, иконки, компоненты, стили.

Продуктовый дизайн — объединяет UX и UI и добавляет продуктовую рамку: целевые метрики, ограничения бизнеса, приоритизацию, эксперименты, работу с командой и релизный цикл.

Удобная формула для запоминания:

UX: правильный сценарий

UI: правильная форма

Product: правильная ценность и результат

Где в работе дизайнера начинаются HIG и Material

HIG и Material Design — это не просто наборы компонентов. Это гайдлайны и дизайн-системы, которые помогают создавать интерфейсы, соответствующие ожиданиям пользователей конкретной платформы.

Для iOS и iPadOS источником является Apple Human Interface Guidelines (HIG): Apple Human Interface Guidelines

Для Android источником является Material Design: Material Design

Их роль в продуктовом дизайне:

Снижают риск сделать интерфейс, который кажется чужим для платформы

Ускоряют проектирование за счет готовых паттернов

Упрощают коммуникацию с разработкой и QA

Улучшают доступность за счет платформенных стандартов

Важно: следование гайдлайнам не отменяет продуктовых решений. Гайдлайны помогают в том, как реализовать, но не отвечают за то, что именно строить и почему.

Философия: что считается хорошим интерфейсом

HIG (Apple)

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

Ясным — смысл и действие читаются быстро

Деференцированным — интерактивные элементы легко отличимы

Глубоким — визуальные слои и анимации помогают пониманию, а не отвлекают

Material Design (Google)

Material Design — это система, где много внимания уделяется масштабируемости, консистентности и адаптивности под разные устройства и бренды. В современном Material 3 сильный акцент на:

Токены и дизайн-системный подход

Адаптивную верстку и разные форм-факторы

Динамическое оформление и темы

Официальный источник: Material Design 3

Ключевые различия HIG и Material на практике

Ниже — сравнение на уровне повседневных решений продуктового дизайнера.

| Область | HIG (iOS) | Material (Android) | |---|---|---| | Общая цель | Нативность и ощущение системного приложения | Масштабируемая система, легко адаптируемая под бренд | | Навигация | Часто опора на нижнюю панель вкладок и иерархию через навбар | Часто опора на навигационные паттерны Material, включая bottom navigation и навигационные контейнеры | | Компоненты | Компоненты выглядят сдержанно, много системных стилей | Компоненты более выраженные, гибкая стилизация через токены | | Типографика и плотность | Часто больше воздуха, крупные зоны касания | Плотность может быть выше, но стандарты касаний сохраняются | | Анимации | Сдержанные, подчеркивают причинно-следственную связь | Более системно описанные движения и переходы, часто заметнее | | Настройка под бренд | Обычно аккуратнее, чтобы не разрушить iOS-ощущение | Обычно шире возможности брендирования через систему токенов |

Навигация: одинаковая задача, разные ожидания

Одна и та же продуктовая задача, например дать доступ к 4–5 ключевым разделам, на iOS и Android может восприниматься по-разному из-за привычек пользователей.

Типичные продуктовые выводы:

На iOS пользователи часто ожидают четкую иерархию экранов с верхней навигацией и предсказуемым возвращением назад.

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

Поэтому кроссплатформенное решение уровня один дизайн на всех часто ухудшает метрики: интерфейс становится менее предсказуемым хотя бы на одной из платформ.

Компоненты и дизайн-система: почему продукту выгодно быть последовательным

В продуктовой работе важно не рисовать экраны заново каждый раз, а строить систему.

Компоненты — повторяемые элементы (кнопки, поля ввода, карточки). Паттерны — повторяемые решения на уровне сценариев (поиск, фильтры, онбординг). Токены — именованные значения стилей (цвета, размеры, радиусы, отступы), чтобы управлять темой системно.

Material 3 очень явно продвигает токены и системность: Material Design — Design tokens

HIG тоже опирается на системные стили, но часто в логике используй нативное, где возможно и не перегружай кастомизацией: Apple HIG

Продуктовая ценность дизайн-системного подхода:

Скорость итераций: быстрее собирать новые фичи из готовых блоков

Качество: меньше случайных различий и ошибок

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

Доступность: не опция, а часть качества

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

Что стоит считать базовым минимумом:

Достаточный контраст текста и элементов

Понятные состояния: ошибка, фокус, отключено, загрузка

Достаточные зоны касания

Поддержка системных настроек размера текста, где это возможно

Официальные источники:

Apple — Accessibility

Material Design — Accessibility

Когда следовать гайдлайнам строго, а когда адаптировать

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

Ситуации, когда обычно стоит следовать строго:

Базовые паттерны навигации

Системные элементы ввода

Жесты, поведение кнопки назад на Android, стандартные модальные сценарии

Доступность и состояния

Ситуации, когда допустима адаптация:

Визуальный стиль бренда при сохранении читаемости и доступности

Компоненты, где платформенных аналогов нет, но есть понятный паттерн

Эксперименты, если есть гипотеза и план оценки результата

Типичные ошибки начинающих в HIG и Material

Копировать iOS-интерфейс на Android и наоборот без учета ожиданий платформы

Игнорировать состояния: загрузка, пусто, ошибка, нет прав

Дробить интерфейс на уникальные элементы вместо системы компонентов

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

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

!Схема показывает, что у HIG и Material разные акценты, но общие цели качества пересекаются

Итоги

Продуктовый дизайн отвечает за достижение пользовательских и бизнес-результатов через опыт.

HIG и Material — практические опоры для нативности, консистентности и качества.

Различия систем важны: они отражают ожидания пользователей платформ.

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

Исследование пользователей: задачи, JTBD, сценарии и метрики

Зачем продуктовому дизайнеру исследование, если есть HIG и Material

В предыдущей статье мы разобрали, что HIG и Material Design помогают делать интерфейсы нативными, предсказуемыми и доступными для пользователей конкретной платформы. Но гайдлайны отвечают в основном на вопрос как оформить и реализовать решение. Они почти не отвечают на вопрос какую проблему решать и какой результат считать успехом.

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

Найти реальные задачи пользователей, а не «идеи из головы»

Понять контекст использования (на ходу, одной рукой, при плохой связи)

Сформулировать, что именно продукт должен улучшить в жизни человека

Превратить наблюдения в сценарии и измеримые метрики

Принять платформенно-уместные решения в рамках HIG и Material, не теряя продуктовую цель

Базовые понятия: задача, цель, сценарий

Чтобы команда говорила на одном языке, зафиксируем простые определения.

Цель пользователя — желаемый итог (например, «купить билет на завтра»)

Задача пользователя — конкретное действие или шаг, который приближает к цели (например, «найти рейсы на нужную дату», «выбрать место», «оплатить»)

Сценарий — описание ситуации и последовательности действий в контексте (например, «покупаю билет в метро, интернет нестабилен, нужно быстро»)

В продуктовой работе важно отделять:

Что пользователь хочет получить (цель)

Что он делает (задача)

Почему и в каких условиях он это делает (сценарий)

JTBD: как описывать потребность без привязки к UI

JTBD (Jobs To Be Done) — подход, который помогает описывать потребности как «работу», которую пользователь нанимает продукт выполнить.

Полезное свойство JTBD: он меньше привязан к конкретным экранам и фичам, поэтому помогает проектировать не «кнопки», а ценность.

Одна из популярных формулировок:

Когда [ситуация], я хочу [мотивация/намерение], чтобы [ожидаемый результат]

Пример для приложения доставки:

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

Что JTBD дает продуктовому дизайнеру:

Понимание триггера (когда возникает потребность)

Понимание критериев успеха глазами пользователя (что значит «получилось»)

Основание для приоритизации (какие «работы» наиболее частые и ценные)

Полезный обзор подхода: Nielsen Norman Group — Jobs-to-be-Done (JTBD)

Как собирать данные в мобильном продукте

Выбор метода зависит от стадии продукта и вопроса, на который вы отвечаете.

Качественные методы: понять почему

Интервью о реальном опыте (недавний кейс, конкретные детали)

Контекстное наблюдение (где и как человек пользуется телефоном)

Юзабилити-тестирование прототипа (находим провалы в сценарии и понимании)

Особенность мобильного контекста: важно фиксировать условия.

Одна рука или две

На ходу или сидя

Плохая сеть

Прерывистое внимание (уведомления, шум, параллельные задачи)

Количественные методы: понять сколько и где

Аналитика воронок (где отваливаются)

Логи ошибок и крашей

Поисковые запросы внутри продукта

A/B-тесты (если есть трафик и стабильная постановка гипотез)

Важно: аналитика хорошо показывает симптомы (например, «падает конверсия на шаге оплаты»), но обычно не объясняет причину без качественного слоя.

Превращаем инсайты в артефакты: от наблюдений к решению

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

| Артефакт | Для чего нужен | Пример результата | |---|---|---| | Список задач | Описать, что пользователь реально делает | «Найти товар», «Сравнить варианты», «Оплатить» | | JTBD | Зафиксировать мотивацию и критерий успеха | «Хочу быстро повторить прошлый заказ, чтобы не тратить время» | | Сценарии | Понять контекст и ограничения | «В очереди, 30 секунд, слабый интернет» | | Пользовательский поток (flow) | Согласовать шаги и состояния | Экран выбора → подтверждение → оплата → статус | | Метрики | Определить, как поймем, что стало лучше | Конверсия, время, ошибки, удержание |

!Цепочка показывает, как исследование превращается в требования к интерфейсу и измеримый результат

Сценарии и состояния: что обязательно продумать в мобильном UX

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

Загрузка (медленная сеть, долгий расчет)

Пусто (нет данных, нет результатов поиска)

Ошибка (оплата не прошла, сервер недоступен)

Нет прав (геолокация запрещена, нет доступа к фото)

Прерывание (звонок, уведомление, сворачивание)

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

Метрики: как измерять качество сценария, а не только «красоту UI»

Метрика нужна, чтобы ответить на вопрос: дизайн улучшил опыт или нет. В мобильном продукте удобно держать набор метрик на разных уровнях.

Продуктовые метрики (результат для бизнеса)

Конверсия в ключевое действие (покупка, заявка, подписка)

Доход или средний чек (если применимо)

Удержание (возвраты, повторные действия)

UX-метрики сценария (результат для пользователя)

Успешность выполнения задачи (доля пользователей, которые дошли до конца)

Время до результата (например, «время до оформления заказа»)

Частота ошибок и возвратов (ошибки формы, отмены, повторные попытки)

Обращения в поддержку по теме сценария

Диагностические метрики (помогают найти причину)

Падение на конкретном шаге воронки

Количество повторных нажатий (часто сигнал, что интерфейс «не отвечает»)

Доля пользователей, которые включают/выключают фильтры и сортировки, но не находят результат

Важно не перегружать команду десятками показателей. Хорошая практика: выбрать 1–2 главные метрики успеха для фичи и 2–4 диагностические, которые объясняют, что пошло не так.

Как исследование связывается с платформенными решениями

Одна и та же JTBD может привести к разным UI-решениям на iOS и Android, потому что ожидания пользователей и паттерны платформ отличаются.

Пример: JTBD в финансовом приложении

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

Дизайнерские выводы из исследования:

Нужен быстрый повтор перевода

Нужна ясная проверка реквизитов перед отправкой

Нужны понятные ошибки и восстановление после сбоя сети

Платформенная реализация:

На iOS вы с высокой вероятностью будете опираться на привычную иерархию экранов, системные элементы ввода и предсказуемые паттерны подтверждения

На Android вы будете учитывать системную кнопку назад, типичное поведение навигации и ожидания по взаимодействию с формами и состояниями

Смысл не в том, чтобы «сделать по-разному ради разности», а в том, чтобы одинаково хорошо решить задачу пользователя, сохранив нативность.

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

Сформулируйте продуктовый вопрос

Выберите метод (интервью, тест, аналитика) под этот вопрос

Соберите 5–10 конкретных историй реального опыта (лучше меньше, но глубже)

Выпишите задачи и JTBD, отделяя факты от интерпретаций

Опишите 2–4 ключевых сценария с контекстом и ограничениями

Спроектируйте поток с обязательными состояниями

Выберите метрики успеха и диагностики

Проверьте прототип (качественно), затем измеряйте на продукте (количественно)

Типичные ошибки

Подменять исследование опросом «нравится/не нравится» вместо разбора реального опыта

Формулировать JTBD как список фич («хочу кнопку») вместо результата («хочу быстро повторить перевод»)

Проектировать только «идеальный путь», игнорируя ошибки, пустые состояния и прерывания

Выбирать метрики, которые не связаны с задачей (например, считать клики вместо успешности выполнения)

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

Итоги

Исследование пользователей отвечает на вопросы что строить и как понять, что стало лучше.

Задачи, JTBD и сценарии переводят наблюдения в структуру, пригодную для проектирования.

Метрики фиксируют успех и позволяют отличать улучшение опыта от субъективного ощущения.

HIG и Material помогают реализовать найденные решения нативно и предсказуемо, но не заменяют понимание пользователя.

Информационная архитектура и навигационные паттерны iOS и Android

Зачем продуктового дизайнера вообще волнует навигация

В прошлых материалах мы зафиксировали две опоры:

HIG и Material помогают делать интерфейс нативным и предсказуемым для платформы.

Исследование пользователей (задачи, JTBD, сценарии, метрики) отвечает на вопрос, что именно должен уметь продукт и как понять, что стало лучше.

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

Быстро понимал, где он находится

Легко находил нужную функцию

Не терял контекст при переходах

Предсказуемо возвращался назад

Если IA слабая, даже идеально собранные компоненты по HIG/Material не спасают: пользователь не может построить ментальную карту приложения и начинает ошибаться, уходить или обращаться в поддержку.

Определения: что такое IA и чем она отличается от навигации

Информационная архитектура (IA) — способ организовать контент и функции: разделы, категории, иерархия, названия, отношения между сущностями.

Навигация — способ перемещаться по этой структуре: контейнеры (вкладки, верхняя панель, боковое меню), правила переходов, паттерны “назад/вверх”, модальные сценарии.

Практическая разница:

IA отвечает на вопрос: что где лежит и как это названо.

Навигация отвечает на вопрос: как я туда попаду и как вернусь.

Ментальная модель пользователя: главный критерий хорошей структуры

Пользователь не видит вашу схему разделов. Он строит ментальную карту по сигналам интерфейса:

Названия разделов и экранов

То, что находится на первом уровне

Повторяемость паттернов

Поведение “назад” и сохранение контекста

Цель IA и навигации — сделать эту карту простой и устойчивой.

Как строить IA из задач и сценариев

Ниже — рабочий алгоритм, который опирается на материал про задачи/JTBD/сценарии, а не на “как принято”.

Инвентаризация: что вообще есть в продукте

Составьте список:

Сущностей (например: товар, заказ, адрес, карта, чат)

Пользовательских задач (например: найти, сравнить, оплатить, повторить)

Критических состояний (загрузка, ошибка, нет сети, пусто)

Инвентаризация нужна, чтобы не проектировать навигацию “на ощущениях” и не забыть важные сущности.

Группировка: какие вещи должны жить рядом

Группировать лучше по пользовательским целям и частоте сценариев:

То, что нужно каждый день и быстро — ближе к первому уровню

То, что нужно редко или в настройках — глубже

Полезный вопрос из JTBD-логики: что пользователь пытается сделать прямо сейчас, и что будет его следующим шагом?

Выбор структуры: иерархия, вкладки или гибрид

Три базовые модели:

Иерархия — пользователь идет “вглубь” по шагам (каталог → категория → товар).

Плоская структура — несколько равнозначных разделов на первом уровне (4–5 ключевых зон продукта).

Гибрид — на первом уровне вкладки/разделы, внутри каждого — своя иерархия.

Для мобильных продуктов чаще всего выигрывает гибрид: он соответствует ожиданиям и iOS, и Android.

Именование: “что это значит для пользователя”

Правила для названий разделов и пунктов:

Называйте результат, а не внутреннюю терминологию

Избегайте синонимов для одного и того же (например, “Заказы” и “Покупки” в разных местах)

Проверяйте, что названия выдерживают озвучивание голосом (для доступности и ясности)

Валидация: проверка структуры до пикселей

До детального UI полезно проверить IA быстрыми методами:

Карточная сортировка (закрытая или открытая)

Tree testing (поиск разделов в “дереве” без дизайна)

Прототип потока и 5–8 коротких юзабилити-сессий

Два слоя навигации: глобальная и локальная

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

Глобальная навигация — переключает крупные зоны продукта.

Локальная навигация — помогает двигаться внутри зоны: списки → детали, фильтры → результаты, создание → подтверждение.

!Двухслойная модель: глобальные разделы и локальные переходы внутри каждого раздела

Основные навигационные контейнеры и когда их выбирать

Вкладки / нижняя навигация

Подходит, когда:

Есть 3–5 ключевых разделов, между которыми часто переключаются

Разделы равнозначны, а не “шаги” одного процесса

Платформенные ожидания:

iOS: типичный контейнер — tab bar. Источник: Apple HIG — Tab bars

Android: типичный контейнер — bottom navigation. Источник: Material Design 3 — Navigation bar

Важное продуктовое правило: если разделов больше пяти, обычно качество падает — пользователи перестают различать зоны. Лучше пересобрать IA или вынести второстепенное глубже.

Верхняя панель (navigation bar / top app bar)

Подходит для локальной навигации и контекста:

Заголовок экрана

Действия уровня экрана (поиск, избранное, поделиться)

Переход “назад/вверх”

Платформенные источники:

iOS: Apple HIG — Navigation bars

Android: Material Design 3 — Top app bar

Боковое меню (navigation drawer)

Чаще уместно, когда:

Есть много разделов, но они не все одинаково важны

Продукт “инструментальный” (например, корпоративные системы, сложные каталоги)

Material рассматривает drawer как вариант для больших IA, но не как способ спрятать ключевые функции. Источник: Material Design 3 — Navigation drawer

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

Поиск как навигация

В больших IA поиск становится альтернативной навигацией: пользователь не идет по категориям, а “телепортируется” к сущности.

Практика:

Дайте понятные подсказки и историю

Покажите пустые результаты как управляемое состояние (что можно сделать дальше)

Разделяйте “поиск по контенту” и “поиск по функциям”, если это разные задачи

Ключевые различия iOS и Android в навигационном поведении

Главное отличие не в том, как выглядит панель, а в том, какие ожидания у пользователя про возврат и иерархию.

“Назад”, “вверх” и предсказуемый возврат

iOS: возврат обычно ассоциирован с иерархией внутри навигационного стека и кнопкой back в верхней панели, плюс жест “свайп назад”.

Android: возврат сильно завязан на системный back (жест/кнопка). Пользователь ожидает, что back работает везде и корректно.

Это влияет на проектирование:

Не делайте неожиданные “петли”, где back ведет не туда, куда пользователь только что пришел.

Сохраняйте состояние списков, фильтров, позиции скролла при возврате, если сценарий предполагает сравнение.

Официальные рекомендации по навигации Android: Android Developers — Navigation

Модальные сценарии

Обе платформы поддерживают модальные паттерны, но ожидания про “закрыть и вернуться” особенно важны.

Правило для продукта:

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

Типичные модальные задачи:

Фильтры/сортировка

Быстрое создание

Выбор варианта (дата, адрес, способ доставки)

iOS-паттерны для модальных представлений описаны в HIG: Apple HIG — Sheets

Адаптивность под разные экраны

Даже если курс про мобильные приложения, реальность такова: Android-устройства сильно разнообразны, а iOS включает iPad.

Практический вывод:

IA должна масштабироваться: то, что на телефоне во “втором уровне”, на большом экране может стать параллельной панелью.

Material 3 уделяет этому большое внимание через адаптивные паттерны (например, navigation rail). Источник: Material Design 3 — Navigation rail

Типовые паттерны потоков: список → детали → действие

Один из самых частых сценариев в продуктах: найти сущность, открыть детали, выполнить действие.

Чтобы он работал хорошо, проверьте:

Список дает достаточную информацию для выбора (иначе пользователь открывает десятки карточек)

Детали отвечают на ключевой вопрос “почему мне это подходит”

Действие на деталях не прячет критические условия (цена, сроки, ограничения)

Возврат назад сохраняет контекст (позиция, фильтры)

Этот паттерн одинаково релевантен iOS и Android, но его “упаковка” будет платформенной через HIG/Material компоненты.

Мини-гайд: как выбрать навигационный паттерн под продуктовую задачу

Ниже — практическая шпаргалка, которая связывает IA с навигационным контейнером.

| Ситуация в продукте | Рекомендация по структуре | Типичный контейнер | |---|---|---| | 3–5 равнозначных разделов, частые переключения | Плоский 1-й уровень + локальные стеки | iOS tab bar / Android navigation bar | | Один основной процесс (например, оформление) | Иерархия шагов с ясным прогрессом | Верхняя панель + внутриэкранный прогресс | | Много разделов, часть второстепенная | Гибрид, второстепенное глубже | Drawer (осторожно) | | Большой каталог или контент | Иерархия + мощный поиск | Поиск как навигация | | Планшеты/большие экраны критичны | Адаптивная структура | Android navigation rail / iPad split view (по задаче) |

Ошибки, которые ломают IA и навигацию

Делать разделы “как у конкурента”, не проверив задачи и частоту сценариев.

Прятать ключевые функции в drawer или “прочее”, чтобы “не загромождать”.

Смешивать разделы разной природы на одном уровне (например, “Каталог”, “Корзина”, “Помощь”, “О приложении” рядом).

Нарушать ожидания “назад”: сбрасывать фильтры, терять позицию, возвращать не туда.

Дублировать одно и то же разными путями без причины, создавая путаницу.

Как связать IA и метрики

Чтобы оценивать качество структуры, удобны метрики сценариев из предыдущей статьи:

Успешность выполнения задачи (доля пользователей, дошедших до результата)

Время до результата (сколько занимает “найти и сделать”)

Возвраты и повторные попытки (сигнал, что пользователь потерялся)

Переходы “туда-сюда” между экранами (часто сигнал плохой категоризации)

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

Итоги

IA отвечает за структуру и названия, навигация — за перемещение и возврат.

Хорошая IA строится от задач/JTBD и контекста использования, а не от визуальных предпочтений.

В мобильных продуктах полезно разделять глобальную и локальную навигацию.

iOS и Android отличаются ожиданиями по возврату, иерархии и адаптивности, поэтому паттерны нужно выбирать платформенно.

Оценивать качество IA и навигации стоит через метрики сценария: успешность, время, ошибки и потери контекста.

UI-компоненты, визуальный стиль и дизайн-система

Как эта тема продолжает курс

В предыдущих статьях мы зафиксировали три опоры продуктового дизайна мобильных приложений:

HIG и Material задают платформенные ожидания и снижают риск «чужого» интерфейса.

Исследование (задачи, JTBD, сценарии, метрики) отвечает на вопрос, что строить и как измерять успех.

Информационная архитектура и навигация превращают задачи в структуру экранов и предсказуемые переходы.

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

Термины: компонент, паттерн, стиль, токен

Чтобы команда говорила на одном языке:

UI-компонент — переиспользуемый интерфейсный элемент с четкой анатомией и состояниями: кнопка, поле ввода, табы, карточка.

Паттерн — повторяемое решение на уровне сценария или флоу: поиск с подсказками, фильтры, онбординг, пустые состояния.

Визуальный стиль — правила «как выглядит продукт»: типографика, цвет, иконки, сетка, радиусы, тени, иллюстрации.

Дизайн-токены — именованные значения стилей, которые связывают дизайн и код: color.primary, radius.m, space.12, type.titleLarge.

Дизайн-система — согласованный набор токенов, компонентов, паттернов и правил использования, плюс процесс поддержки и изменений.

Важно для продуктового дизайнера: IA и навигация отвечают за куда и как перемещаемся, а дизайн-система отвечает за как это собрано так, чтобы было предсказуемо, доступно и быстро в разработке.

!Ментальная модель, как дизайн-система масштабирует UI от базовых значений до экранов

Платформенный базис: почему компоненты нельзя «просто унифицировать»

HIG и Material предлагают не только внешний вид, но и ожидаемое поведение: размеры касания, анимации, иерархию акцентов, расположение действий.

Полезное правило:

Сначала выбираем платформенный паттерн и поведение, потом брендируем в допустимых границах.

Официальные источники:

Apple Human Interface Guidelines

Material Design 3

На практике это означает:

На iOS чаще выигрывают решения, которые выглядят и ведут себя как системные (особенно в формах, навигации, модальных сценариях).

На Android Material 3 дает больше «законного» пространства для брендирования через тему и токены, сохраняя узнаваемое поведение компонентов.

Анатомия UI-компонента: что нужно описать, чтобы им можно было пользоваться

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

Назначение: для чего компонент, какие задачи закрывает.

Анатомия: из каких частей состоит (контейнер, текст, иконка, supporting text).

Варианты: размеры, типы, визуальные вариации.

Состояния: normal, pressed, disabled, loading, error, focus.

Правила контента: длина текста, переносы, числа, локализация.

Доступность: контраст, зоны касания, озвучивание, фокус.

Ограничения: где нельзя использовать.

Состояния — обязательная часть качества, а не «дополним потом»

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

Типовой набор, который стоит продумывать почти всегда:

Default: обычное состояние.

Pressed: реакция на нажатие.

Disabled: действие недоступно, причина должна быть понятна в UX.

Loading: пользователь понимает, что процесс идет.

Error: понятная причина и путь восстановления.

Success: подтверждение результата там, где это критично.

Материальные ссылки по компонентному мышлению:

Material Design 3 — Components

Ключевые компоненты мобильных продуктов и платформенные различия

Ниже — компоненты, на которых чаще всего «сыпется» качество, если не опираться на гайдлайны.

Кнопки и иерархия действий

Продуктовая цель кнопок — управлять приоритетом действий и снижать вероятность ошибок.

Практические правила:

На экране должно быть понятно, какое действие главное.

Деструктивные действия визуально отделяются и требуют более осторожного UX.

Текст кнопки должен описывать результат: «Оплатить 1 290 ₽» часто лучше, чем «Далее».

Источники:

Apple HIG — Buttons

Material Design 3 — Buttons

Поля ввода и формы

Формы — место, где метрики чаще всего страдают из-за мелочей: клавиатура, формат, ошибки, автозаполнение.

Что важно зафиксировать на уровне системы:

Типы полей и маски (телефон, карта, дата).

Поведение ошибки: когда показываем, где размещаем текст, как исправлять.

Поддержка автозаполнения и системных подсказок.

Источники:

Apple HIG — Text fields

Material Design 3 — Text fields

Списки, карточки и «плотность» интерфейса

Списки и карточки — базовая поверхность для сценариев “список → детали → действие”.

Решения, которые стоит стандартизировать:

Высота строки и отступы.

Правила для превью-контента (заголовок, подзаголовок, метаданные).

Поведение при длинных текстах и локализации.

Источники:

Apple HIG — Lists and tables

Material Design 3 — Cards

Диалоги, листы и подтверждения

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

Продуктовые рекомендации:

Подтверждать только необратимые или дорогие действия.

Текст должен объяснять последствия.

Кнопки должны быть однозначными: «Удалить» лучше, чем «Ок».

Источники:

Apple HIG — Alerts

Material Design 3 — Dialogs

Визуальный стиль как инструмент продуктовых метрик

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

Цвет: акцент, статус, тема

Как продуктово использовать цвет:

Выделять главное действие и текущий статус.

Отделять интерактивное от неинтерактивного.

Передавать состояние (ошибка, успех, предупреждение) без двусмысленности.

Material 3 дает развитую модель цвета и темы, которую удобно переводить в токены.

Источник:

Material Design 3 — Color

Типографика: читаемость и иерархия

Типографика определяет скорость сканирования экрана.

Что важно стандартизировать:

Набор стилей текста (заголовки, body, подписи).

Правила переносов и сокращений.

Поддержка Dynamic Type на iOS и масштабирования шрифта на Android.

Источники:

Apple HIG — Typography

Material Design 3 — Typography

Иконки: узнаваемость и соответствие платформе

Ошибки с иконками часто «ломают нативность» сильнее, чем цвета.

Практические правила:

На iOS для системных смыслов уместно использовать SF Symbols.

На Android уместно опираться на Material Symbols и общую логику Material.

Для кастомных иконок важны единый стиль, толщина линии и оптические компенсации.

Источники:

SF Symbols

Material Symbols

Дизайн-токены: мост между дизайном и разработкой

Токены полезны, когда продукт растет, появляются темы, платформы и много экранов.

Что такое токен на практике

Токен — это имя для значения.

Вместо «цвет #6750A4» вы используете color.primary.

Вместо «радиус 12» вы используете radius.m.

Плюсы:

Консистентность: одинаковые решения везде.

Масштабирование: легко поменять тему или бренд.

Скорость: меньше ручной работы и «почти одинаковых» значений.

Material 3 прямо строится вокруг темы и токенов.

Источник:

Material Design 3 — Design tokens

Минимальный набор токенов, который нужен почти любому продукту

Цвета: primary, secondary, surface, error, onPrimary и аналоги.

Типографика: набор текстовых стилей.

Отступы: шкала space.

Радиусы: шкала radius.

Тени и уровни: если используете elevation.

Размеры касания и высоты контролов.

Как собирать дизайн-систему продуктово, а не «ради системы»

Дизайн-система окупается, когда она ускоряет выпуск фич и снижает дефекты.

Пошаговый подход

Выберите 2–3 критических пользовательских сценария из исследования и метрик.

Выпишите UI-элементы, которые встречаются в этих сценариях чаще всего.

Зафиксируйте токены (цвет, типографика, отступы) на минимальном наборе.

Соберите библиотеку ключевых компонентов с анатомией и состояниями.

Опишите паттерны для повторяющихся флоу (ошибки, пустые, загрузки).

Введите правила внесения изменений: кто владелец, как версионируем, как коммуницируем.

Критерии «готовности» компонента

Компонент можно считать готовым к масштабированию, если:

Есть все ключевые состояния и примеры контента.

Понятно, где использовать, а где нельзя.

Есть требования доступности.

Есть соответствие платформенным ожиданиям.

Разработка может реализовать без додумывания.

!Иллюстрация, почему компонент без состояний неполный

Доступность как часть дизайн-системы

Доступность нельзя «прикрутить» в конце, потому что она вшита в компоненты: контраст, зоны касания, фокус, озвучивание.

Базовый минимум, который стоит включать в спецификацию компонентов:

Достаточный контраст текста и важных элементов.

Достаточный размер зоны касания.

Понятные тексты ошибок и связка ошибки с полем.

Поддержка увеличенного текста.

Источники:

Apple — Accessibility

Material Design 3 — Accessible design

Частые ошибки при работе с компонентами и дизайн-системой

Собирать библиотеку «сразу на весь продукт», вместо того чтобы начать с самых частых сценариев.

Делать компоненты без состояний, особенно без error/loading.

Пытаться полностью унифицировать iOS и Android визуально, ломая платформенные ожидания.

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

Держать токены только в дизайне и не синхронизировать с разработкой.

Итоги

UI-компоненты и визуальный стиль — это слой, который превращает IA и сценарии в реализуемые интерфейсы.

Дизайн-система состоит из токенов, компонентов и паттернов, плюс правил поддержки.

HIG и Material важны не только внешним видом, но и поведением компонентов.

Состояния и доступность — обязательная часть спецификации.

Самый практичный путь — строить систему от ключевых сценариев и метрик, а не «покрывать всё» сразу.

Прототипирование, доступность и проверка качества интерфейса

Как эта тема продолжает курс

В предыдущих статьях мы собрали основу продуктового дизайна мобильных приложений:

Мы сравнили философию HIG и Material Design и договорились, что по умолчанию следуем платформенным ожиданиям.

Мы разобрали, как исследования (задачи, JTBD, сценарии) превращаются в решения и метрики.

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

Мы зафиксировали роль компонентов, состояний, токенов и дизайн-системы.

Теперь нужен мост между «мы придумали решение» и «мы уверены, что оно работает и реализуется без потерь»:

Прототипирование помогает быстро проверить сценарий и снизить риск до разработки.

Доступность гарантирует, что решение работает в разных условиях и для разных пользователей.

Проверка качества интерфейса превращает гайдлайны, сценарии и компоненты в конкретные критерии приемки.

!Диаграмма показывает, как прототипирование и проверки качества встроены в общий цикл продуктового дизайна

Прототипирование как продуктовый инструмент

Прототип — это модель интерфейса, которая позволяет проверить поведение и понимание сценария до (или параллельно) разработке. Ценность прототипа не в «красоте», а в том, что он быстро отвечает на вопросы:

Пользователь понимает, что делать дальше?

Сценарий выполняется без ошибок и лишних шагов?

Навигация предсказуема для платформы?

Все критические состояния предусмотрены?

Команда одинаково понимает поведение (дизайн, продакт, разработка, QA)?

Уровни детализации прототипа

В мобильном продукте удобно мыслить прототипами по точности.

Низкая детализация: быстрые схемы экранов и переходов, без визуальной полировки.

Средняя детализация: уже есть структура, тексты, базовые компоненты и состояния.

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

Практическое правило: выбирайте детализацию под риск.

Если вы проверяете структуру и маршрут (IA и навигацию), чаще достаточно низкой или средней.

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

Какие вопросы прототип отвечает лучше всего

Проверка понятности сценария через короткое юзабилити-тестирование.

Проверка «провалов» воронки до разработки (где пользователь может потеряться).

Уточнение логики состояний: loading, empty, error, no permission.

Согласование поведения с разработкой: что является «экраном», что «модалкой», как работает «назад».

Про прототипирование как способ ранней валидации хорошо пишет Nielsen Norman Group: Prototyping: A Brief Guide

Что именно прототипировать в мобильном интерфейсе

Чтобы прототип действительно снижал риск, он должен включать не только «идеальный путь», но и то, что чаще всего ломает метрики.

Основной пользовательский поток

Критические развилки

Состояния и ошибки

Возвраты и сохранение контекста

#### Критические состояния, которые стоит включать почти всегда

Загрузка

Пустое состояние

Ошибка (с возможностью восстановления)

Нет сети или нестабильная сеть

Нет прав (камера, геолокация, фото)

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

Платформенная реалистичность прототипа

Даже если вы делаете один продукт, прототип должен учитывать ключевые различия ожиданий iOS и Android.

На iOS пользователь часто воспринимает навигацию как иерархический стек с предсказуемой кнопкой back и жестом возврата.

На Android пользователь ожидает корректной работы системного back и логики «назад» как возврата по фактической истории.

В прототипе это означает:

Проверять, куда возвращает «назад» на каждом шаге.

Проверять, сохраняются ли фильтры, позиция списка, введенные данные.

Не смешивать без причины модальные сценарии и «полноэкранную» навигацию.

Если вы сомневаетесь, опирайтесь на платформенные источники:

Apple Human Interface Guidelines

Material Design 3

Доступность как часть качества, а не отдельная «фича»

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

Почему это продуктовая тема:

Доступность снижает количество ошибок и повышает успешность выполнения задач.

Доступность уменьшает когнитивную нагрузку, а значит влияет на конверсию.

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

Ключевые источники:

Apple — Accessibility

Material Design — Accessible design

Android Developers — Accessibility

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

Ниже — чек-лист, который можно применять уже на уровне прототипа.

#### Текст и масштабирование

Интерфейс должен выдерживать увеличение текста без обрезаний и наложений.

Иерархия должна оставаться читаемой: заголовок, основной текст, подписи.

Связь с гайдлайнами:

iOS: поддержка Dynamic Type и системных настроек размера текста описана в экосистеме Apple, стартовая точка — Apple Human Interface Guidelines.

Android: важно учитывать настройки размера шрифта и масштабирования, стартовая точка — Android Developers — Accessibility.

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

Цвет не должен быть единственным способом передать смысл (например, «ошибка только красным»).

Статусы должны иметь дополнительный сигнал: текст, иконку, подпись.

Материал по принципам доступного дизайна: Material Design — Accessible design

#### Зоны касания и моторика

Интерактивные элементы должны быть достаточно крупными для нажатия.

Между элементами должно быть расстояние, чтобы избежать случайных нажатий.

Платформенные ориентиры часто формулируются как «минимальная удобная зона касания»:

iOS традиционно опирается на 44x44 pt как практический минимум в рекомендациях Apple. Стартовый раздел для контекста компонентов: Apple HIG — Buttons

Android и Material обычно ориентируются на 48 dp как базовую цель для touch target. Контекст по компонентам: Material Design 3 — Buttons

#### Скринридеры и семантика элементов

Каждый интерактивный элемент должен иметь понятную озвучку: что это и что произойдет.

Иконка без текста почти всегда требует подписи для доступности.

Порядок фокуса должен соответствовать логике чтения и сценарию.

Точки входа:

iOS: Apple — Accessibility

Android: Android Developers — Accessibility

#### Движение и анимации

Анимация должна объяснять переход, а не отвлекать.

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

Проверка качества интерфейса: что именно проверяем и как

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

Решает пользовательскую задачу из исследования

Соответствует платформенным ожиданиям HIG или Material

Реализуется консистентно с дизайн-системой

Имеет все состояния и не ломается на краях

Доступен

Три уровня критериев качества

#### Сценарий и метрика

Проверяем, что интерфейс поддерживает ключевой сценарий из исследования.

Пользователь понимает первый шаг.

Действие доводится до результата.

Ошибки объяснимы и исправимы.

Если у вас есть метрики, то критерии можно формулировать как «что должно улучшиться». Например:

Снижение ошибок на шаге ввода

Сокращение времени до результата

Рост успешности выполнения задачи

#### Платформа

Проверяем, что паттерны и поведение нативны.

Навигация и «назад» предсказуемы для платформы.

Компоненты ведут себя ожидаемо (состояния, фокус, отключенность).

Источники:

Apple Human Interface Guidelines

Material Design 3

#### Система

Проверяем, что продукт не распадается на «уникальные экраны».

Используются компоненты из библиотеки.

Токены применяются последовательно.

Набор состояний у компонентов одинаковый по всему продукту.

Как проводить дизайн-QA по готовой сборке

Дизайн-QA лучше планировать как регулярный процесс, а не как «разово перед релизом».

Проверьте сценарий по шагам

Проверьте состояния

Проверьте соответствие платформе

Проверьте доступность

Проверьте визуальную консистентность

Чтобы это было воспроизводимо, полезно иметь короткий шаблон репорта дефекта.

Где найдено: экран, шаг сценария

Ожидание: как должно быть (ссылка на макет/компонент)

Факт: как работает сейчас

Влияние: почему это ломает сценарий или доступность

Приоритет: блокирует релиз или можно исправить позже

Типовые «дыры качества», которые прототип помогает поймать заранее

| Риск | Как проявляется в продукте | Как ловить на прототипе | |---|---|---| | Потеря контекста при возврате | Сброс фильтров, скролла, введенных данных | Прогон сценария «выбор → детали → назад» | | Нет состояний | Нет error/empty/loading, непонятно что происходит | Добавить ветки состояний прямо в прототип | | Непонятная иерархия действий | Пользователь не видит главную кнопку или путает действия | Тест 5–8 пользователей на одну задачу | | Ненативные паттерны платформы | «Чужая» навигация, непривычные модалки | Сверка с HIG/Material и системными паттернами | | Недоступность | Мелкие зоны касания, нет подписей, низкий контраст | Чек-лист доступности + прогон скринридером |

Практический рабочий процесс: от прототипа к уверенной реализации

Ниже — процесс, который хорошо стыкуется с тем, что мы уже проходили (исследование → IA → компоненты).

Выберите один ключевой сценарий и одну метрику успеха

Соберите прототип среднего уровня

Добавьте обязательные состояния (loading/empty/error/no permission)

Проведите короткое тестирование на понятность сценария

Исправьте провалы и соберите прототип высокой точности для критических экранов

Согласуйте с разработкой компоненты, токены, поведения «назад» и модальные сценарии

Проведите дизайн-QA по сборке и проверьте доступность

После релиза проверьте метрики и вернитесь к итерациям

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

Итоги

Прототип — инструмент снижения риска: проверяет сценарий, навигацию, состояния и понимание до разработки.

Доступность — часть качества продукта и напрямую влияет на успешность выполнения задач.

Проверка качества интерфейса должна включать три слоя: сценарий и метрика, соответствие платформе, консистентность с дизайн-системой.

Лучший результат дает процесс: прототип → тест → уточнение состояний и доступности → дизайн-QA по сборке → измерение метрик.