Більшість команд будують дизайн-систему від атомів: визначають кнопки, поля вводу, бейджі й таблиці, збирають із них більші блоки, а потім розкладають усе це по екранах. Ця звичка настільки поширена, що багато хто плутає її з самою методологією Atomic Design. Але Бред Фрост із самого початку наголошував: це не лінійний процес, а ментальна модель, яка дозволяє тримати в полі зору ціле й частини одночасно. П'ять рівнів — атоми, молекули, організми, шаблони й сторінки — не є кроками з першого по п'ятий.
Продуктова робота зазвичай стартує з іншого боку — з користувацького досвіду. Коли дизайнер дивиться на екран, перше питання не «які компоненти тут використані», а «що користувачу потрібно тут зробити». Як він шукатиме, фільтруватиме, порівнюватиме, обиратиме, редагуватиме? Це інша точка входу в модель Atomic Design — підхід, який можна назвати «scope-first», тобто від області впливу дії.
Компонентний підхід зазвичай починається з інвентаризації: ось кнопка, ось поле вводу, ось бейдж, ось таблиця. Для цього добре працюють дві відомі методики — Interface Inventory Бреда Фроста та Component Cut-Up Workshop Нейтана Кертіса. Обидві чудово виконують своє завдання: описати наявний інтерфейс і запустити роботу над бібліотекою компонентів. Але вони відповідають на конкретне питання «що є на екрані», а решту — чому це там і з чим пов'язано — доводиться думати самостійно.
Візьмімо типовий адмін-екран із таблицею даних. Інвентаризація виглядає пристойно: заголовок сторінки, основні дії, таб-навігація, поле пошуку, поля фільтрів, кнопки сортування, пагінація, тултіпи. За кадром залишається те, як усе це пов'язано між собою. Бейдж статусу прив'язаний до одного рядка. Сортування переставляє всі рядки в наборі даних, хоча сам контрол розташований у заголовку однієї колонки. Пошук і фільтри змінюють те, які записи взагалі відображаються на екрані. Основна дія на кшталт «Додати людей» впливає на всю сторінку. Таби можуть повністю замінити вміст контентної області.
Близькість елементів один до одного тут поганий орієнтир. Кнопка сортування — найочевидніший приклад: вона живе в заголовку колонки, але впливає на всю таблицю. Елементи пов'язані не розташуванням, а областю впливу своєї поведінки. Тому, розбираючи екран, варто починати з області впливу кожної дії — набору даних або частини інтерфейсу, які змінюються, коли користувач її запускає.
У такому розборі кожен рядок лівої колонки відповідає на одне й те саме питання: що саме змінюється? Спокуса додати категорії на кшталт «навігація» чи «заголовок таблиці» описує, чим контрол є або де він розташований. Це інша вісь, і змішування двох осей тихо повертає вправу до звичайної інвентаризації. Другий важливий момент: тултіпи й бейджі не мають області впливу взагалі — вони нічого не змінюють, а лише доповнюють картину.
Такий розбір не універсальний: на іншому екрані чи в іншому продукті області впливу будуть іншими. Переноситься не список, а процес. Спершу — що користувач може зробити і з чим взаємодіяти. Далі — на що впливає кожна конкретна дія. Потім — який рівень має володіти логікою. Так команда отримує структурну модель екрана ще до створення компонентів.
Окрема напруга виникає між бібліотекою та продуктом. Проєктуючи компоненти, ми думаємо про універсальність, незалежність і застосовність у контекстах, які не можемо передбачити. Проєктуючи продукт, думаємо про бізнес-логіку: частини мають скластися в цілісний досвід. Пошук, фільтри й пагінація ілюструють це дуже наочно. Як компоненти бібліотеки вони можуть з'являтися в різних комбінаціях на різних екранах, тож логічно тримати їх незалежними. Але на цьому адмін-екрані вони керують спільним набором даних: зміна фільтра може скинути пагінацію на першу сторінку, а пошуковий запит без збігів спорожнює таблицю, і пагінація стає непотрібною.
Перелічити всі такі сценарії під час документування окремих компонентів неможливо, та й самі компоненти не повинні про них знати. У момент, коли компонент фільтра дізнається про компонент пагінації, він втрачає перевикористовуваність і починає нести бізнес-логіку одного конкретного кейсу. Але щось ці зв'язки має керувати.
Найзручніше робити це на рівні шаблону. В Atomic Design шаблони — це об'єкти рівня сторінки, які позиціонують компоненти в макеті та визначають структуру контенту: вони про структуру, а не про стан. Простіше кажучи, шаблон діє як «дурний» презентаційний компонент, що знає лише, як виглядає і які дані отримує ззовні. «Розумні» компоненти-контейнери здатні керувати даними, станом і поведінкою, і їх часто будують як обгортки навколо презентаційних. Саме шаблону варто віддати керування зв'язками між пошуком, фільтрами й пагінацією, залишивши окремі компоненти презентаційними.
Для українських продуктових і агенційних команд це практична настанова: перш ніж малювати бібліотеку, розберіть екран за областями впливу дій. Це дешевше, ніж потім переписувати компоненти, які обросли логікою конкретного екрана.