Модель BNARL — це стратегічний фреймворк для формування здорової культури роботи над дизайн-системами. BNARL означає: Beliefs (Припущення), Norms (Норми), Artifacts (Артифакти), Rituals (Ритуали) та Language (Мова).
Автор: Буді Танрім (Budi Tanrim), Head of Design у education civic tech. Раніше співпрацював з Bukalapak, Shopify. Інші замовники: Yahoo, Palantir, Marvelapp.
Коли дизайн-система встановлена, є кілька поширених перешкод на шляху до її втілення:
- Дизайн-система обмежує творчий потенціал дизайнерів і стає надто негнучкою. Проте, вона може пришвидшити роботу та підтримати її послідовність.
- Дизайнери вважають, що дизайн-системи ігнорують контекст і надають надто універсальні компоненти.
Ці критичні зауваження справедливі. Але часто вищеописане відбувається через нездорову культуру дизайн-системи. Модель BNARL допомагає лідам зрозуміти стан цієї культури та за необхідності втрутитися.
Схема моделі BNARL
Який вигляд має BNARL?
Ось приклад моделі BNARL у моїй команді:
- Припущення: наші користувачі не знайомі з технологією та потребують гарантій і впевненості.
- Норми: кожен може зробити внесок і розвивати дизайн-системи.
- Артефакти: ми створюємо інструменти для власної підтримки, а не ті, які нам заважають.
- Ритуали: висока залученість, щоб люди могли проявити свої вміння.
- Мова: проста та зрозуміла, яку легко запам’ятати.
Я навмисне намагаюся зробити BNARL досить загальною, високорівневою та простою, бо ці прописані стратегії є ключовими. У моделі не йдеться про практичний підхід до того, як щось зробити. Вона радше закладає бажану культуру.
Використовуйте модель BNARL для оцінки поточної культури та формування бажаної.
Читайте також: Як створити дизайн-систему для додатків з аудиторією 35 млн
Припущення/ Beliefs
Припущення виражають фундаментальні знання про користувачів, для яких ми працюємо. Ми використовуємо цю інформацію як одну з основних лінз у процесі мислення.
Для роздумів: наскільки ви поінформовані про найглибші припущення команди щодо користувачів? Зберіть ці погляди як набір гіпотез та перевіряйте їх у процесі роботи. Не ухвалюйте сліпих рішень, виходячи з неправильних переконань.
Наша команда створює продукти для вчителів та викладачів у Індонезії. Завдяки фундаментальному дослідженню ми дізналися, що є вчителі, які не хочуть використовувати технології та відчувають тривожність, коли беруться за послідовні дії.
Усвідомлюючи свої припущення, ми можемо використати їх як лінзи в нашому процесі мислення та ухвалення рішень.
Норми /Norms
Норми задають тон тому, як люди мають поводитися з дизайн-системами. Гарний приклад норми — в Японії очікують на потяг вишикувавшися в чергу.
Для роздумів: поспостерігайте, як люди діють у різних ситуаціях. Наприклад, як часто люди створюють новий компонент? Якщо вони роблять це тихо, тоді поточна норма — мовчати, коли створюєш новий компонент. Запитайте себе: «Чи це бажана поведінка?»
Що роблять дизайнери, якщо вони не можуть знайти хороший компонент у бібліотеці для розв’язання своєї проблеми? Чи нормально у вашій команді запропонувати покращення?
Чи мають інженери створювати компонент з нуля, коли перевіряють прототип та знаходять у ньому компонент, якого немає в бібліотеці?
Нам потрібна норма, в межах якої кожен може зробити внесок та розвивати дизайн-системи. В реальності це можна втілити кількома тактичними прийомами, наприклад, завдяки майданчику для співпраці.
Артефакти /Artifacts
Стратегія навколо артефактів визначає якими ми хочемо бачити артефакти (UI-кіти, принципи тощо) у нашому щоденному житті. Це ключове, а не те, які артефакти ми будемо створювати.
Для роздумів: яка роль артефактів у нашій команді? Це службовий інструмент, який ви вважаєте допоміжним? Або ж ви ставитеся до нього як до священного гладіаторського меча?
Чи можна сперечатися щодо типографського набору? Чи можна пропонувати новий колір токена, якщо дизайнер відчуває в цьому необхідність? Чи маємо ми розглядати колір і токен як постійні змінні, що рідко оновлюються?
У нашій команді ми створюємо інструменти, що допоможуть нам догодити користувачам, а не навпаки. Це означає, що ми відкриті до змін компонентів, принципів чи основ дизайну, якщо це допомагає нам краще відповідати на потреби користувачів.
Читайте також: Джаред Спул: Як формуються проактивні UX-стратегії у великих організаціях
Ритуали /Rituals
Можна розглядати ритуали як допоміжний елемент, що закріплює норми, які ви хочете сформувати в культурі команди.
Для роздумів: які ритуали ви можете придумати, щоб закріпити норми? Ритуал — один із найпоширеніших важелів впливу, який ви можете використати для зміни поточних норм на бажані.
Коли я приєднався до команди та поговорив з кількома дизайнерами, я побачив одну цікаву динаміку. Більшість дизайнерів у нашій команді виявляють ініціативу та вміють розв’язувати проблеми. Але дизайн інтерфейсів — не їхній сильний бік, багато хто вважає, що це зона росту, яку вони хочуть досліджувати.
Озброївшися цим розумінням, я також хочу впровадити спосіб, що дозволяє дизайнерам у нашій команді розвивати свої навички роботи з інтерфейсом. Отже, стратегія нашого ритуалу дизайн-системи — зосередитися на активній залученості, коли люди можуть реалізувати свої вміння.
Мова — «з родзинкою» чи проста?
Для роздумів: який ресурс сприйняття ви хочете використати для назви компонента чи кольору? Чи хочемо ми забезпечити простоту, або ж нам потрібно, щоб словниковий запас чимось вирізнявся та привертав до себе увагу?
За наявності дизайн-систем ваша команда поповнить спільний словниковий запас. Наприклад, як саме ви називаєте колір: чи було б краще для вашої команди мати живу назву, що легко запам’ятати, наприклад, «захід сонця» чи «ліс»? Або ми віддаємо перевагу простим назвам, як от «зелений-80»?
Це залежить від вашої мети. У нашій команді ми за просту, зрозумілу мову, яку легко запам’ятати.
Оригінал публікації англійською: Design systems: The BNARL model
Telegraf.Design живе за підтримки спільноти. Підтримуйте Telegraf.Design на Patreon.