Проектирование информационной архитектуры мобильного приложения
Когда пользователь не может найти нужную функцию за три тапа — он уходит. Не потому что интерфейс некрасивый, а потому что информационная архитектура (IA) проектировалась по принципу «добавим в меню» вместо анализа реальных пользовательских сценариев. Это дороже всего обходится уже после релиза, когда переделывать навигационное дерево приходится вместе с рефакторингом роутинга.
Где IA ломается чаще всего
Глубокие иерархии — самая распространённая ошибка. Приложение уровня 4–5 вложенности экранов без быстрого возврата наверх — это почти гарантированный провал onboarding-а. На iOS стандартный UINavigationController терпит это, но пользователь — нет.
Ещё одна типичная ситуация: дублирование контента в нескольких разделах. Продуктовая команда добавляет «Избранное», «История», «Мои покупки» как отдельные разделы, хотя с точки зрения mental model пользователя это один объект — «моё». В итоге в приложении три разных способа попасть к одному и тому же, и ни один не очевиден.
Ошибки в taxonomy — когда категории пересекаются или не покрывают весь контент — обнаруживаются позже всего. Card sorting с 15–20 реальными пользователями на этапе IA снимает большинство из них до того, как они войдут в wireframes.
Как строим архитектуру
Начинаем с инвентаризации контента и функций. Каждый экран, каждое действие, каждый тип данных — в таблицу. Обычно на выходе получается 40–120 сущностей для среднего по сложности приложения. После этого — affinity mapping: группировка без оглядки на существующий дизайн.
Дальше — tree testing. Инструмент Optimal Workshop Treejack или аналог позволяет проверить иерархию без единого пикселя дизайна. Тест из 10–15 задач, 20+ участников — и уже видно, где пользователи теряются. Это несравнимо дешевле, чем переделывать готовый прототип.
Для мобильных приложений отдельно прорабатываем:
- Основную навигацию — Tab Bar (iOS) / Bottom Navigation (Android) vs. Drawer. Правило: если разделов больше 5 и они несопоставимы по частоте использования — думаем иначе.
- Вторичную навигацию — как пользователь движется внутри раздела, где push, где modal, где contextual actions.
- Глобальные точки входа — поиск, уведомления, профиль. Их размещение влияет на всю остальную иерархию.
- Edge cases — пустые состояния, ошибки, onboarding. Они часто выпадают из IA и потом добавляются хаотично.
На выходе — структурированная схема в Figma (FigJam) или Miro: визуальное дерево с указанием типов переходов и приоритетности разделов. Не просто скетч, а документ, из которого дизайнер берёт wireframes, а разработчик — структуру роутинга.
Артефакты и применимость
| Артефакт | Инструмент | Для кого |
|---|---|---|
| Контентный инвентарь | Notion / Google Sheets | PM, дизайнер |
| Иерархическая схема (sitemap) | FigJam / Miro | Дизайнер, разработчик |
| Card sorting результаты | Optimal Workshop | UX-исследователь, PM |
| Tree test отчёт | Treejack | PM, дизайнер |
| IA-документ с обоснованием | Confluence / Notion | Вся команда |
IA-документ живёт дольше, чем кажется. Хороший документ используется при добавлении новых фич через 6–12 месяцев, когда исходная команда уже поменялась.
Сроки и этапы
Для простого приложения (10–20 экранов) полный цикл — 1 день: инвентаризация + схема + базовая валидация. Для среднего (30–60 экранов) с проведением card sorting и tree testing — 2–3 дня. Сложные enterprise-приложения или ребрендинг существующего продукта с накопленным контентом — отдельная история, там сроки обсуждаются после аудита.
Стоимость рассчитывается индивидуально после анализа требований и существующих материалов.