Які переваги та недоліки у дизайн-систем, як зрозуміти, що вже час запровадити дизайн-систему, і як порозумітися з розробниками, коли вводиш нові правила, — ці та інші важливі питання обговорили дизайнери Максим Кір’янов, Іван Даньков і Дмитро Дворніченко.

Повна версія панельної дискусії «Дизайн-система цифрових продуктів: коли і навіщо це потрібно?»

Навіщо потрібні дизайн-системи: переваги та недоліки

Максим Кір’янов — Product Owner у стартапі Boxmode

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

Переваги дизайн-системи:

• оптимізація витрат;
• консистентність дизайну;
• пришвидшення розробки («час — це гроші»).

 Недоліки дизайн-системи:

• складно впровадити;
• потрібно багато часу, щоб створити;
• необхідно знайти ресурси для створення.

Іван Даньков — Product Designer у Crello, працював над дизайн-системами для Crello, Weblium і Booked

Цінність дизайн-системи для дизайнера:

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

А от можливість вносити невеликі зміни у продукт без дизайнера — це і перевага, і недолік. Коли наш CPO, який мав дизайн-бекграунд, дізнався про дизайн-системи, його було не зупинити. Загалом у нас 20% дизайн-завдань вирішуються без дизайнера. Менеджер просто каже: «Ось цей компонент — сюди». Завдання додати нову кнопку закривають без нашої допомоги, а це круто.

Дмитро Дворніченко — Design Technology Lead у GlobalLogic Ukraine

Дизайн-система потрібна:

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

Коли час створювати дизайн-систему

Максим Кір'янов

Product Owner у стартапі Boxmode

Дизайн-система потрібна, коли вже існує 70% усіх компонентів та елементів, які ти будеш використовувати у майбутньому. Коли у додатка вже є усталені інтерфейсні компоненти, тоді вже можна робити дизайн-систему, впроваджувати її та розвивати далі. У нашій компанії ми так і робимо.

Зверніть увагу, йдеться про етап пост-MVP (minimum viable product, мінімально життєздатний продукт – ред.), бо на етапі MVP немає сенсу робити дизайн-систему через додаткові витрати та навантаження на дизайнерів і розробників. На MVP та ранній пост-MVP стадії ніхто не буде цим займатися, бо потрібно швидше випускати оновлення з новими функціями.

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

Іван Даньков

Іван Даньков

Product Designer в Crello

У Crello, коли я туди прийшов, починався ребрендинг — Spiilka зробила нову айдентику. Нам потрібно було поступово оновлювати продукт, і тоді ініціатива створення дизайн-системи йшла від дизайнерів та розробників. Для нас не було питання, робити це раніше чи пізніше. Ми розуміли: якщо зараз цим не займемося, через три місяці нам буде дуже погано. І нас було 5-6 людей, тому ми б робили дизайн-систему, навіть якби нас ніхто не підтримував. Але розробники були на нашому боці.

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

• Дизайн-система — це інструмент економії, а не заробітку.
• Треба робити дизайн-систему, коли ви почали заробляти.
• Дизайн-систему потрібно створювати, коли є ресурс і бажання.

Дмитро Дворніченко

Design Technology Lead у GlobalLogic Ukraine

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

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

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

Хто має ініціювати створення дизайн-системи

Максим Кір’янов

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

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

Інструменти для роботи з компонентами дизайн-системи

Максим Кір’янов

У нас в команді саме дизайнери шукали технічні рішення для дизайн-системи та узгоджували їх з розробниками. Спочатку була зв’язка Sketch + Zeplin через плагін, а потім відбувалось перенесення у сторібук. Але це складна система, що нам не сподобалась. З другої спроби нам підійшла система Figma + zeroheight + сторібук.

Ось як це працює: після того, як дизайнер зробив компонент і затвердив його з лідом, він вносить цей компонент у zeroheight (з Figma обираєш потрібний компонент чи артборд, натискаєш «імпортувати», і усе готово). Звідти розробники витягують його у форматі JSON і додають до сторібуку, де зберігається документація для компонентів.

Це напівавтоматичний процес, бо на кожному етапі потрібна присутність людини. Але дизайнери вміють швидко додавати нові компоненти. Розробникам це зручно, бо вони використовують npm-пакети (з англ. Node Package Manager — ред.): нові компоненти оновлюються усюди, і в продукті також. У цьому і сенс дизайн-системи.

Іван Даньков

Щодо інструментів: у нас це Figma, у якій зберігаються компоненти. До кожного з них є пачка фреймів з атрибутами та поведінкою. Коли з’являється новий компонент, готовий до передачі у розробку, це означає, що він скоро вже має бути розміщений у сторібуці. До кожного компонента прив’язаний тікет у Jira. Дуже зручно, що коли ми робимо нові фічі, це викликає зміни у компонентах, і ми просто зв’язуємо тікети. У такій системі розробники не мають іншого виходу, крім використання дизайн-системи.

Як допомогти замовнику розібратися з правилами застосування дизайн-системи

Дмитро Дворніченко

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

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

Щоб порозумітися з розробниками, шукайте союзників

Дмитро Дворніченко

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

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

Іван Даньков

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

У нас в Crello майже не було проблем з тим, щоб «продати» розробникам ідею дизайн-системи. Якщо вже є звалище стилів і дизайн-компонентів, які ми використовуємо, йому потрібна синхронізація. Ми провели зустріч, де я показував, які стилі та компоненти у нас є, а розробники намагалися зрозуміти, як вони можуть це реалізувати. Там були суперечки, але врешті ми домовилися. У Weblium і Booked усе відбувалося схоже.

Труднощі виникли, коли стилі вже були організовані та почались перші компоненти. За перші пів року ми ввели компоненти у code convention (стандарт оформлення коду – ред.) розробників. Якщо можна було використати компонент, розробники були зобов’язані застосувати саме його. Порушення цих правил розробники обговорювали на code review (огляд коду – ред.).

Важливий момент: у кожній компанії, де ми впроваджували дизайн-систему, я намагався знайти агента серед девелоперів, який допоможе мені просувати цю тему серед розробників. І цей союзник буде тією людиною, яка почне на code review усіх «підштовхувати».

Як відбувається тестування компонентів для дизайн-систем

Іван Даньков

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

На рівні компонентів ми вже не перевіряємо доступність, якщо там усе створено за правилами. Далі йде етап, коли ми передаємо компонент розробнику. А після розробки QA-команда бере участь у тестуванні компонентів.

Дмитро Дворніченко

У нас багато проєктів з високою насиченістю даних. Наприклад, фінансовий проєкт, де є аналітика компанії, та потрібно відстежувати багато чисел і динаміку, розглядати на екрані цифри й графіки. Тоді йдеться про високі вимоги до контрастності. Щодо читабельності, то вибір шрифту — це окремий процес зі своїми тонкощами. Принципи, закладені в accessibility (доступності — ред.), та інші вимоги ми використовуємо за замовчуванням: контраст, safe кольори, кольори для графіків, щоб вони відрізнялись одне від одного, і щоб була широка палітра.

Читайте також: Як обирати шрифти: веб-дизайн

А от у проєктах з охорони здоров‘я ми діємо за вимогами гайдлайнів з accessibility, тестуємо всі кольори, розміщення кнопок на фонах карток (щоб впевнитись у контрастності). Щоб пройти регулятора, це все потрібно задокументувати та подати, і в результаті отримати затвердження. І це тільки для того, щоб додаток міг побачити світ, і його можна було використовувати у сфері охороні здоров’я. Наприклад, якщо йдеться про додаток-асистент для інсулінової помпи. Це великий челендж і водночас допомога хворим людям.

Чи можна використовувати дизайн-системи повторно?

Дмитро Дворніченко

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

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

Чи не гальмує дизайн-система розвиток продукту?

Іван Даньков

Через дизайн-систему в мене спочатку було відчуття, що я тут зайвий, і заважаю продукту розвиватися. Спершу доводилося «відволікати» дизайнерів: пояснювати, що вони беруть елементи не з дизайн-системи. Ми разом вирішували, які елементи можна використати повторно.

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

Максим Кір’янов

Я не бачив кейсів, коли дизайн-система гальмує розвиток продукту, якщо враховувати те, що з часом вона змінюється (нові компоненти, редизайн). У Boxmode ми до такого ще не дійшли, але ж працюємо з дизайн-орієнтованим продуктом: якщо з’явиться новий мегапопулярний тренд, нам доведеться заредизайнити компоненти. Водночас усе залежить від продукту — величезний enterprise-проєкт, у якому по світу працюють сотні команд, може сповільнюватися через дизайн-систему.