Атомний дизайн

Атомний дизайн — це методологія побудови інтерфейсних систем шляхом об'єднання невеликих, багаторазових частин у поступово більші структури. Запропонований Бредом Фростом у 2013 році, він запозичує хімічну метафору та визначає п'ять рівнів: атоми — найменші неподільні елементи, такі як мітки, поля введення та кнопки; молекули — прості групи, такі як поле пошуку з його міткою та кнопкою; організми — складніші збірки, такі як заголовок сайту або картка продукту; шаблони — структури сторінок із заповнювачами контенту; та сторінки — шаблони, заповнені реальним контентом.

Внесок методології полягає у спільному словнику для рішення, яке кожна команда інтерфейсу приймає неявно: що таке компонент, що таке композиція та де починається повторне використання. Без фреймворку команди створюють екрани індивідуально, дублюють подібні елементи з невеликими варіаціями та в результаті отримують десятки ледь помітно різних кнопок та карток, кожну з яких необхідно підтримувати. Атомний дизайн забезпечує структуру для ідентифікації блоків повторного використання та для визначення рівня, на якому знаходиться певний фрагмент інтерфейсу.

Його практичні переваги проявляються в обслуговуванні, а не в початковій збірці. Зміна базового елемента оновлює все, що з нього складається, тому зміна стилю фокусування або інтервалів поширюється послідовно, замість того, щоб вимагати пошуку в кодовій базі. Нові екрани можна збирати з існуючих фрагментів, що скорочує терміни виконання та зменшує кількість рішень, необхідних для кожної нової сторінки. Робота із забезпечення якості та доступності зосереджується на рівні компонентів, де одна правильна реалізація обслуговує кожне використання, а не повторюється на кожній сторінці.

Методологія викликає обґрунтовану критику, здебільшого щодо буквалізму. Команди витрачають непропорційно багато зусиль на обговорення того, чи є даний елемент молекулою чи організмом, що є таксономічним аргументом без практичних наслідків. Метафора хімії також розпадається на межах і погано доноситься до недизайнерів. Більшість досвідчених команд трактують рівні як нечіткий орієнтир, часто зводячи їх до простіших відмінностей, таких як примітиви, компоненти та шаблони, і зосереджуються на основному принципі композиції, а не на правильній класифікації.

Надмірна абстракція — це серйозніший ризик. Створення бібліотеки компонентів до того, як зрозуміло, що насправді потрібно продукту, створює компоненти, розроблені для уявних випадків, з надмірною кількістю варіантів конфігурації та незрозумілим призначенням. Більш надійна послідовність полягає в тому, щоб створювати екрани, помічати справжнє повторення та витягувати компоненти після того, як шаблон кілька разів з'являвся в реальному використанні. Передчасну абстракцію важче розібрати, ніж дублювання, оскільки кожен споживач компонента обмежує те, як він може змінюватися.

Цінність методології значною мірою залежить від управління, яке вона сама не забезпечує. Бібліотека компонентів без чіткого володіння, правил внеску та процесу припинення підтримки накопичує варіанти: три картки, які дещо відрізняються, два компоненти-кнопки з перекриваючими призначеннями та зростаючий набір одноразових перевизначень, що застосовуються, оскільки існуючий компонент майже підійшов. Вирішення питання про те, хто затверджує нові компоненти, як команда запитує зміни до спільного компонента та як застарілий шаблон видаляється з існуючого використання, має більше значення для довгострокової узгодженості, ніж таксономія. Організації, які впроваджують таке управління, виявляють, що бібліотека з часом зменшує обсяг роботи; ті, хто цього не робить, виявляють, що вона стає ще однією несумісною поверхнею, що потребує обслуговування поряд з кодом, який вона мала спростити.

З точки зору поставки, цей підхід працює найкраще, коли бібліотека проектування та бібліотека коду відповідають один одному, таким чином, що компонент у засобі проектування має єдину реалізацію з однаковою назвою та однаковими варіантами. Встановлення цієї відповідності є спільною відповідальністю всіх... дизайн продукту та розробка продукту, і саме це визначає, чи зменшує система дизайну обсяг роботи, чи просто додає другий артефакт для підтримки разом із кодом.