Як ми побудували систему дизайну Atomic з бібліотеками Sketch @Capital Float

Уроки, отримані під час створення модульної системи дизайну у компанії FinTech.

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

Незабаром ми зрозуміли необхідність уніфікації нашої продукції. Єдиний спосіб зробити це - визначити візуальне керівництво. Але як і з чого почати?

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

Наш перший стиль-путівник

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

Час на виконання та створення реальної системи проектування

Будучи комп’ютерним інженером, став дизайнером UX, я знав силу модульності. Але як це зробити для дизайну, я не мав поняття, з чого почати! Будучи величезним шанувальником дизайну Google, я розпочав реверсивну інженерію та ставить під сумнів їхню систему дизайну матеріалів. Я також досліджував Bootstrap і Angular Framework, щоб зрозуміти, як вони визначають компоненти.

Цілі нашої бібліотеки

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

  1. Стандартизовані елементи та Уніфікована система дизайну для всієї нашої продукції, незалежно від платформи.
  2. Створення 1: 1, наскільки це можливо, з нашими кодованими компонентами та ескізними символами, як візуально, так і структурно.
  3. Легкий в обслуговуванні. Оновлення або доповнення компонентів повинно бути простим, щоб дизайнери та розробники отримували останню інформацію без особливих очікувань.

Перше, що спочатку

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

Ми окреслили певні закономірності / правила для підтримки гігієни на робочому місці

  1. Структура файлів і папок
  2. Управління сторінками та дошками мистецтва (Дошка мистецтва як варіант екрана, Сторінки як функції)
  3. Не повторюйте себе (використовуйте символи)
Структура файлів і папокУправління сторінками та аркушами

Рівень 0: Кварки та електрони

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

Завантажте зразок файлу: https://goo.gl/9WdLYR
Ми визначили символ формули для створення варіації кольору і повторно використовуємо його для створення палітри. Так що ми просто повинні турбуватися про базові кольори. Формули - це не що інше, як накладка на базовий колір і працює так само, як Shades & Tint.

Рівень 1: Атоми

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

Все, що можна визначити та використовувати індивідуально, - це атоми. Наприклад, картка, підказка, тінь, роздільник, кнопка, логотипи, курсори тощо.

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

Рівень 2: Молекули

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

Вся ідея молекул - це думати загальне.
Варіації родового компонента

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

Рівень 3: Організми та сторінки

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

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

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

Останні слова

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

  1. Порядок шарів у вашому символі має значення. Оскільки вони з’являться в тому ж порядку на панелі «Переосмислити». Ви також можете заблокувати деякі шари, щоб уникнути захаращення.
  2. Використовуйте програму Run Sketch, щоб шукати та вставляти символи, оскільки вона має кращий попередній перегляд, ніж у Sketch.
  3. Використовуйте Генератор стилів ескізів для створення загальних стилів тексту та шарів.
  4. Якщо ви непрограмовані та хочете знати, як розробники бачать елементи дизайну, скористайтеся плагіном Sketch Measure для експорту ваших проектів. Це також допомагає полегшити передачу дизайну.
Безсумнівно, ескіз вдосконалює наш процес проектування, але є ще мало важливих відсутніх функцій, таких як ..
  1. Спільні тексти та стилі шарів насправді не можуть бути доступними поза вашим файлом!
  2. Експорт активів із символів із переосмисленням - це біль! Перегляньте цю тему для отримання додаткової інформації.
  3. Контроль версій для бібліотек. (На відміну від контролю версій розробника, Sketch дозволяє переходити лише до вищої / останньої версії компонента)
  4. Символи як маска

Журнал змін

Будь ласка, розгляньте нижче коментар як мій відкритий лист!

Я хотів би тут зазначити / зазначити, що вищенаведена стаття має на меті продемонструвати наші знання та процес досягнення атомного дизайну. Це не означає, що я є власним творінням! Це скромна спроба втілити концепцію "Атомного дизайну" Бреда Фроста.

Величезне спасибі Олександру Тримуле, Бреду Морозу та Оліверу Джану за те, що надихнули мене розпочати роботу з дизайнерською системою.

Вищенаведена стаття висвітлена у розділі CC0 - Ніяких прав не захищено. Я відмовляюся від усіх авторських та суміжних прав у повному обсязі, дозволеному законом.

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