Маркери в системах дизайну

10 порад щодо рішення архітектора та впровадження дизайну для всіх

У нещодавньому огляді коду мої пристрасті збуджувались, коли я проходив стиль компонента «Таблетки» з товаришем по команді дизайнера.

Я насилу стримував своє хвилювання:

"Дивись. Так, це код, але придивіться уважно до цих жетонів. Ви знаєте, як це виглядає? Як специфікації! І що? Я можу це прочитати, як і ви. І ми можемо вносити ці теми скрізь: док, конструкції та конвої. Скрізь!

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

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

Ось як ми еволюціонували, архітектурували та впроваджували маркери під час дизайну, коду та співпраці.

Від змінних до токенів

Кожна система дизайну пропонує варіанти. Наприклад, кольори можуть масштабуватися від чорного через нейтралі до білого. Кожен нейтральний - ідентифікований за допомогою HEX-коду, як # 2B303B - може бути збережений та доступний у змінній $ color-neutral-20, для використання в препроцесорі типу Sass.

Змінні виводять таємницю із незрозумілих значень. Але вони не подолають розрив між називанням та використанням. Вони відповідають "Які варіанти у мене є?", Але залишають незрозумілим "Який вибір я роблю?"

Параметри недостатньо хороші.

Дизайнерські рішення, варіант, застосований до контексту

Сила системи полягає в тому, щоб знати, як застосовувати параметри (наприклад, $ color-neutral-20) до контекстів (наприклад, звичайний темний колір фону). Це обґрунтовує варіант як рішення.

Це рішення, які я можу використовувати впевнено!

Однак такі рішення, як правило, все ще ховаються в якомусь файлі в якомусь репо, використовуваному розробниками, які працюють над веб-продуктом, яким вони володіють. Що з дизайнерами? Інші веб-продукти? На інших платформах, таких як iOS та Android? Ми розшифрували рішення, призначені для всіх, але вони володіли в підземеллі репо, ніхто більше не може знайти.

Дизайнерські жетони, рішення, що поширюються через систему

Salesforce UX забезпечує огляд. Їх ідеї захоплюють мене, найбільше їх концепцію керівництва по живому стилю, яка застосовує дизайнерські жетони для продуктів, використовуючи їх інструмент Theo з відкритим кодом.

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

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

Чи бачите рішення великим специфікацією? Я можу. Дизайнери теж можуть. З такою наочністю та інструментальністю вони визнають вплив своїх рішень. Раніше ми визначилися з $ color-neutral-80 для межі або фону з трохи примхливими. Тепер ми застосовуємо $ border-hairline або $ background-color-light у продуманому, звичайному вигляді.

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

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

Архітектура жетонів

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

№1. Спочатку покажіть параметри, потім рішення

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

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

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

№2. Почніть з кольорів і шрифтів, і не зупиняйтеся на цьому!

Я часто говорю про велику трійку мов дизайну: колір, типографію та іконографію. Тож не дивно, що наш файл жетонів починається з кольорів та типів параметрів та рішень (піктограми автоматизовані в іншому місці). Однак візуальний стиль складається з набагато більше, і так би могло бути лексем.

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

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

№3. Варіанти різних значущих масштабів

Багато токенізованих концепцій включають масштаби на вибір, такі як розмір футболки (XS, S, M, L, XL, XXL), прогресії (наприклад, геометричні 2, 4, 8, 16, 32, 64) або спеціальна термінологія (як компактний, затишний і комфортний). Ваги також можуть починатися з декількох варіантів (лише S&M) і зростати, включаючи більше, як гарантовано.

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

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

Винос: прийняти та змістити масштаби та продемонструвати, як вони застосовуються в різних сценаріях.

№4. Запросіть внесок, але виправте колекцію

Коли вибір вимагає стати ознакою? Одноразове використання: ні, недостатньо. Друга може бракувати переконання. Але три? Якщо вона виявляється стільки, це зазвичай лексема. Винятки існують, але критерії "Використовуються 3 рази?" Викликають дискусію.

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

Тим не менш, я виконую функції куратора жетонів, скануючи роботу з оком на кандидатів у жетони. Я можу пропустити розмітку запиту та пропустити JavaScript. Однак я ретельно сканую стилі та файли токенів, щоб надати точні імена, перекласифікувати навпаки номінантів та заперечувати надмірне розширення. У кожного є голос лексеми. Але не кожен піклується достатньо або встигає зберегти жетони в чистоті.

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

№5. Рішення для випускників від компонентів до токенів

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

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

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

Ці змінні, що стосуються компонентів, пропонують корисний опис кандидатів, які перейшли до бібліотеки жетонів. Тут ми можемо знайти можливість замінити менш специфічний відключений колір на $ color-neutral-90 на більш навмисний $ background-color-disabled у файлі form_elements.styl. З іншого боку, розмір $ border-color-input-hover компонента є менш ймовірним для повторного використання поза формами і, отже, поганий кандидат-маркер.

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

№6. Передбачувано впоратися із системними змінами

Токени - прекрасний інструмент, коли ви формулюєте первозданну систему з нуля. Але що за 18 місяців відтепер, коли дизайнерські рішення еволюціонують? Як маркер змінює каскад? Які ризики є, і як їх пом’якшити?

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

Пошук загальної змінної

Раніше ви розчісуєте та оцінюєте сховище для шестигранного коду №2B303B або змінної $ color-neutral-20, застосованої до безлічі різних елементів. Бу!

Пошук конкретного рішення.

Тепер ви точно відстежуєте широту використання $ text-color-microcopy та зменшує ризик. Так!

Винос: скористайтеся перевагами технічного обслуговування жетону і використовуйте це як торговий пункт для своєї приймаючої команди.

Реалізація токенів

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

Це залишає обіцянки жетонів невиконаними. Перший крок у розповсюдженні токенів по всій системі - це звільнення їх у відкритому форматі, як JSON.

№7. Зробіть багаторазові дані Token через JSON

JSON - ідеальний відкритий стандарт для кодування ієрархічних пар імен / значень для повторного використання в усіх інструментах.

За допомогою жетонів у JSON ви можете трансформувати рішення для декількох препроцесорів - SASS, Stylus та LESS - як вимагає ваша громада. Це відкриває двері для продуктів, обмежених препроцесором, які вони не можуть або не залишать позаду, навіть якщо це не "рекомендована" система.

Аналогічно, JSON створює міст до інших платформ, будь то безпосередньо споживається в роботі iOS або перетворений у XML для команд Android.

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

№8. Легко керуйте та читайте дані Token через YAML

JSON є потужним, ієрархічним та гнучким. Однак це недосконале місце для управління даними. Синтаксис є багатослівним, схильним до помилок при ручному куруванні, не підтримує коментарів та не має змінних.

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

Наша команда використовує yamljs для перетворення даних YAML, якими ми керуємо як єдине джерело правди, в об’єкт JavaScript як етап нашого процесу збирання.

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

№9. Автоматизація документації за допомогою даних Token

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

У наших системах ми вбудовуємо маркери як структуру даних (думаю: JSON) у шаблони для відображення рішень у довіднику лексем та інших темах, як пробіл та тематичні кнопки.

Основні шаблони сайту документації, що працюють на базі даних маркера

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

Винос: Використовуйте жетони, щоб збагатити життєвим путівником.

№10. Вставити дані Token в Інструменти дизайну, занадто

Дані маркера можуть надихнути ідеї на інструменти не тільки для розробників, але і для дизайнерів. Ми говоримо про створення спеціальних інструментів для спільноти дизайнерів нашого портфоліо в таких інструментах, як Sketch, Photoshop або InDesign.

Таке програмне забезпечення пропонує різні надійні гачки, щоб використовувати дані JSON на вашу користь. Наприклад, InVision's Craft покладається на об'єкти JSON, що зберігаються як текст у підпапках, що пропонує можливу інтеграцію з результатами процесу складання нашої системи. У минулому такі зв'язки були достатньо зусильними та прокладеними, що їх ігнорували. Сьогодні вони відчувають себе більш реалістичними, як система дозріває.

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

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

Збираєтеся взятися за систему дизайну, чи потрібно зануритися глибше, щоб обговорити продукти та гравців? EightShapes проводить семінари з планування систем та тренує клієнтів із дизайнерських систем. Давай поговоримо!