Статті
Проєктування дизайн-системи
Конспект дизайнера
13 вересня, 2019
Віталій Дворецький
Продакт-дизайнер DeviantArt/Wix

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

Продакт-дизайнер DeviantArt/Wix Віталій Дворецький розповів на лекції про особливості дизайн-систем, а Telegraf.Design занотував почуте.

Читайте також: Чому ви невчасно робите дизайн-систему? Колонка Дениса Суділковського

Автор усіх зображень: Віталій Дворецький

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

Зазвичай це набір стилів чи компонентів, які можуть бути описані, зібрані на кількох артбордах і виконувати базові задачі. Іноді системи доповнюються, наприклад, UX-патернами, брендингом, Voice & Tone. Якщо ви маєте справу з великим продуктом, важливо дбати про Voice & Tone. Ще можна потурбуватись про те, щоб контент був доступний і зручний для людей з фізичними і ментальними порушеннями.

Дизайн-система — це:

Зазвичай: візуальний стиль та UI-компоненти;

Іноді: UX-патерни, брендинг, Voice & Tone;

Рідко: доступність (accessibility), локалізація та візуалізація даних.

Вона розробляється за допомогою:

Зазвичай: HTML, CSS, документів і гайдлайнів;

Іноді: дизайн-асетів (Sketch-файлів, бібліотек тощо);

Рідко: JS-фреймворків (React, Angular тощо).

Документується все зазвичай у живих вебсторінках (Confluence, Phabricator, Google Docs/Dropbox), дуже рідко в офлайні, у PDF-файлах.

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

З чого почати:

  1. З опитування користувачів: у вас мають бути потенційні або реальні контриб’ютори дизайн-системи. Потрібно спілкуватись з ними, дізнатись про проблеми й перспективи вашого продукту.
  2. Визначення вимог: у кожної команди є усталений підхід до формулювання документації, циклу релізів тощо. Радикальні зміни (а це якраз стосується дизайн-систем) завжди складно втілювати, краще помалу оптимізувати звичні процеси. Є купа рекомендацій щодо того, як збирати вимоги, спілкуватись з девелоперами тощо. Наприклад, Бред Фрост зробив добірку матеріалів про те, як писати гайдлайни для фронтендерів.
  3. Огляд продуктів. На вас чекають радикальні зміни; щоб підготуватися, потрібно зібрати максимум інформації. Чим більше продуктів ви побачите, проаналізуєте, обговорите з командою, тим легше буде щось вирішувати.

Концептуальне спрямування

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

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

Команда і комітменти

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

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

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

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

Поступовий delivering

Почніть з базових компонентів, робіть їхні маленькі релізи. Так ви отримаєте реальні дані та побачите, як впливають зміни на продукт.

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

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

Види командної роботи

Гібридна дизайн-команда

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

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

Окрема команда для дизайн-системи

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

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

Змішані команди

Усі працюють над продуктом і допомагають розвивати дизайн-систему.

У дизайн-системи багато контриб’юторів: маркетологи, дизайнери, копірайтери, фронтендери, усі потенційні користувачі можуть зробити свій вклад.

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

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

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

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

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

Щоб зробити документацію потрібно:

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

Product map і структура

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

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

Труднощів додає і контроль версій. У нових версіях компоненти можуть бути виправлені, змінені відповідно до нових вимог, мати варіації для A/B-тестування. Усьому цьому потрібен менеджмент і не факт що над новою версією компоненту буде працювати та сама людина, що й над попередньою. Це нормально, але до цього треба бути готовими: поговорити з людиною, яка раніше відповідала за компонент та фічі, де цей компонент використовується.

Деталізація та шаблони для документів

Поділяється на три частини: приклади, дизайн і код.

1. Приклади

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

Можна обрати і простіший шлях, як команда WeWork Plasma, котра має досить обмежені ресурси. Вони просто використовують GoogleDocs, де описують компоненти, структурують їх, додають кейси, приклади коду.

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

Наприклад, IBM Carbon додають гіфки, а Apple — скріншоти з описами контексту.

2. Дизайн-гайдлайни

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

  1. Use-кейси. Коли в систему додається компонент, потрібно розповісти, як він взаємодіє з іншими елементами, як його варто використовувати, а як ні (наприклад, такі іконки застосовуються лише для головного меню, а такі для контекстного).
  2. Візуальний стиль — які є візуальні рішення, які у них кейси, індексація шрифтів, кольорів, іконок, бордів, як вони поєднуються.
  3. Взаємодія — те, як усе працюватиме в динаміці. Опишіть, як користувач приходить до певного кейса і що отримує внаслідок взаємодії з елементом. Це стосується всіх переходів, анімацій, таргетованих івентів тощо.
  4. Контент. Важливо, щоб продукт супроводжував консистентний текст, був тон спілкування з користувачами і відповідний візуальний контент. Те, як контент масштабується, обрізається, як стискаються зображення — усе це частини дизайн-системи.

Кілька порад, як покращити дизайн-гайдлайни:

  • Дотримуйтесь однакової структури в усій документації.
  • Використовуйте слова: Include… , Avoid… , Prevent… , Limit… .
  • Додавайте посилання.
  • Використовуйте списки.
  • Робіть читання документу швидшим і простішим.

Приклад того, як пише гайдлайни Apple:

3. Код

У документації подбайте про:

  • живі приклади;
  • опис версій та змін у нових релізах;
  • статус задачі — на якому етапі розробки зараз компонент;
  • зазначення відповідальних осіб та команд — product owners.

Контроль версій

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

З контролем версій допомагає софт Abstract та git. Як варіант можна використовувати Zeplin + сховище файлів + список з описом того, що й де зберігається (наприклад, у SpreadSheet).

Ще один корисний інструмент — Confluence, це розробка Atlassian для документації. Вона базується на технологіях git і після кожного зберігання документації показує вам ченджлог. Так ви знаєте, що змінилось, додалось чи видалилось у кожній новій версії.

Контроль якості

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

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

Як оцінювати дизайн-систему

Перший критерій — те, наскільки активно люди користуються вашою дизайн-системою. Скільки компонентів девелопери розробили з нею? Як усе задокументовано? Скільки людей використовують ваші інструменти для пошуку?

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

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

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

Розробляти першу версію дуже складно. Підтримувати і розвивати її ще складніше. 


Раніше ми розповідали про створення дизайн-систем за допомогою Atomic Design.

avatar
Віталій Дворецький
Продакт-дизайнер DeviantArt/Wix
Колонка

У нас є ще дещо для вас