Проектування інформаційної архітектури мобільного додатка
Коли користувач не може знайти потрібну функцію за три тапи — він виходить. Не тому що інтерфейс некрасивий, а тому що інформаційна архітектура (IA) проектувалася за принципом «додамо в меню» замість аналізу реальних користувацьких сценаріїв. Це дороже всього обходиться вже після релізу, коли переділювати навігаційне дерево доводиться разом з рефакторингом роутинга.
Де IA ломається частіше за все
Глибокі ієрархії — найпоширеніша помилка. Додаток рівня 4–5 вложеності екранів без швидкого повернення наверх — це майже гарантований провал onboarding-у. На iOS стандартний UINavigationController терпить це, але користувач — ні.
Ще одна типова ситуація: дублювання контенту в кількох розділах. Продуктова команда додає «Вибране», «Історія», «Мої покупки» як окремі розділи, хоча з точки зору mental model користувача це один об'єкт — «моє». В результаті в додатку три різних способи потрапити до одного й того ж, і жоден не очевидний.
Помилки в таксономії — коли категорії перетинаються або не покривають весь контент — обнаруживаються найпізніше. 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-додатки або ребрендинг існуючого продукту з накопленим контентом — окремої історія, там строки обговорюються після аудиту.
Вартість розраховується індивідуально після аналізу вимог та існуючих матеріалів.