Словник для систем проектування: 20 термінів, які кожен розробник Frontend повинен знати

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

Фундаментальні поняття

1. Маркер дизайну

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

** Використання: ** “Ми замінили твердо закодоване шістнадцяткове значення символом color.brand.primary, тому воно автоматично оновлюється всюди, якщо коли-небудь зміниться колір марки.”

2. Бібліотека компонентів

Збірка попередньо створених компонентів інтерфейсу користувача (кнопок, вхідних даних, модальних елементів), які можна використовувати повторно, які реалізують візуальну мову і поведінку системи проектування, призначені для спільного використання між продуктами або командами.

** Використання: ** * “Замість створення нового спадного списку з нуля, перевірте, чи вже є у бібліотеці компонентів список, який відповідає цьому випадку використання.” *

3-й. Єдине джерело правди

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

** Використання: ** * “Зараз шкала інтервалів дублюється у трьох різних файлах CSS — нам потрібен єдиний джерело правди, щоб вони не виходили з синхронізації.” *

4. Тема

Механізм, за допомогою якого система дизайну підтримує візуально відмінні варіанти — наприклад, світлий режим, темний режим або різні оболонки брендів — зазвичай, за допомогою обміну наборами знаків дизайну, а не переписування компонентів.

** Використання: ** “Теми обробляються повністю за допомогою обміну символами, тому компонентам не потрібен жодний код, специфічний для темного режиму.”

Комплексна архітектура

Вариант 5

Відмінна візуальна або функціональна версія одного і того ж компонента, наприклад, « первинний », « вторинний » і « деструктивний » варіанти кнопки, як правило, керуються за допомогою репу.

** Використання: ** * “Ми додали новий варіант « деструктивного » компонента кнопки для дій, таких як постійне вилучення, стилізований за допомогою кольору попередження.” *

6. Складність

Ступінь, до якого компоненти можна об’ єднувати і вкладати, щоб створити складніший інтерфейс користувача, без зміни самих компонентів.

** Використання: ** * “Цей компонент карти має хороші можливості компонування — ви можете вставити будь- яку комбінацію вмісту заголовка, тіла і нижнього колонтитула без торкання внутрішніх частин карти.” *

7-й. Слоти / API композиції

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

** Використання: ** * “Ми додали слот для нетипового вмісту нижнього колонтитулу, щоб користувачі не застрягали з нашим типовим набором кнопок дій.” *

8. буріння пропелера

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

** Використання: ** “Це значення теми буде пробурено через п’ ять шарів компонентів — нам слід скористатися контекстом, щоб проміжним компонентам не потрібно було знати про це.”

9. безголовий компонент

Компонент, який забезпечує керування поведінкою і станом, але не має вбудованого візуального стилю, що дозволяє користувачам застосовувати власний дизайн, одночасно використовуючи логіку, що лежить в основі.

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

Послідовність і управління

10. проектний борг

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

** Використання: ** “Ми маємо значний проектний борг у потоці оплати — половина кнопок використовує стару шкалу інтервалів, яка була введена до поточної системи знаків.”

11-й. Дрейф (вигляд/компонентний дрейф)

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

** Використання: ** * “Дрейф компонентів з’ явився тому, що команди додавали одноразові перевищення CSS замість того, щоб запитувати зміни до спільного компонента.” *

Модель управління

Процес, за допомогою якого зміни до системи проектування пропонуються, переглядаються і схвалюються, балансуючи послідовність зі швидкістю, з якою окремі команди повинні рухатися.

** Використання: ** “Наша модель управління вимагає перегляду нових компонентів командою розробників системи, але окремі команди можуть пропонувати додати токен за допомогою легшого асинхронного процесу.”

Модель вкладу

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

** Використання: ** * “Ми перейшли до моделі федеративного вкладу, тому команди продукту можуть безпосередньо вносити нові компоненти, замість того, щоб подавати запит і чекати.” *

14. Коефіцієнт прийняття

Частка інтерфейсу користувача продукту, яка фактично використовує компоненти і символи проектної системи, на відміну від нетипових, одноразових реалізацій.

Використання: “Рівень прийняття нової системи токенів становить близько 60% у всьому продукті — решта 40% це застарілий код, який ми ще не мігрували.”

Документація та інструменти

Жива документація

Документація для системи проектування, яка автоматично синхронізується з поточним кодом (наприклад, за допомогою відтвореного майданчика для ігор з компонентами), а не статичний документ, який може бути застарілим.

** Використання: ** * “Наш сайт з документацією відтворює справжній код компонента, тому приклади ніколи не будуть відрізнятися від того, що використовується у виробництві.” *

16-й. Книга історій (або компонентний майданчик)

Середовище розробки, призначене для збирання, тестування і документування компонентів інтерфейсу користувача у окремій, відокремленій від повної програми, формі.

** Використання: ** * “Ми спочатку тестуємо кожен новий варіант компонента у Storybook, щоб дизайнери могли переглянути його візуально перед тим, як його буде вставлено у справжню сторінку.” *

17-го. Передача дизайну в код

Процес перетворення візуального дизайну (часто з інструменту дизайну) у реалізований код, ідеально з мінімальною неоднозначністю або вручну переінтерпретацією.

** Використання: ** “Використання спільних знаків дизайну з обох сторін зробило передачу дизайну до коду набагато плавнішою — значення у файлі дизайну відображаються безпосередньо на значення в коді.”

18-й. Доступність (a11y) базовий рівень

Мінімальний набір гарантій доступності — наприклад, співвідношення контрасту кольорів, навігація за допомогою клавіатури і підтримка програм для читання з екрану — які, за типовими параметрами, має виконувати кожен компонент системи проектування.

** Використання: ** * “Оскільки базова лінія доступності вбудована у спільний компонент, команди отримують навігацію за допомогою клавіатури і належне позначення ARIA безкоштовно, без необхідності реалізувати це самі.” *

19-й. Зміна виміру (в контексті системи проектування)

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

** Використання: ** “Переназва цього токену є технічно неможливою зміною для будь- кого, хто звертається до нього безпосередньо — нам потрібен період застаріння і керівництво з міграції перед вилученням старої назви.”

20-х років. Зрілий рівень системи

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

** Використання: ** “Ми на ранній стадії зрілості — у нас є токени і декілька основних компонентів, але ще немає офіційного процесу управління для запропонованих змін.”

Ключеві моменти

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