Почнемо з початку

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

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

У 2018 році Usabilis запропонував такий опис: Система дизайну схожа на бібліотеку компонентів (бібліотеку), візуальних елементів і принципів із багаторазовим кодом. Цей масштабований набір пропонує сховище UX та UI для дизайнерів і розробників цифрових продуктів і послуг. Добре, але без технічного жаргону? 

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

Кухарями системи дизайну є дизайнери (UI та UX) та розробники. Саме їм система дизайну послужить найбільше. Дизайнери підберуть інгредієнти (створять компоненти), напишуть рецепти (виготовлять моделі) і нададуть їх розробникам, які готуватимуть страви (розроблятимуть веб-сайти, програми тощо).

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

І це навіть не головна перевага системи дизайну! Справді, його головна перевага — швидкість виконання, яку він дає змогу всій команді продукту (дизайнери + розробники). Оскільки компоненти вже готові, все, що вам потрібно зробити, це зібрати їх, щоб створити нові сторінки, інтерфейси,…! Ми часто порівнюємо систему дизайну з Lego, це не дарма.

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

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

# Зміст

Система проектування зазвичай складається з 2 джерел роботи. Джерело для дизайнерів, сумісне з використовуваним програмним забезпеченням (Sketch, Figma,…) і джерело для розробників, де представлені всі вже розроблені компоненти, а також їх код. У будь-якому випадку компоненти, присутні в цих джерелах, можна «викликати» безпосередньо (або в моделях для дизайнерів, або в коді для розробників), що заощаджує багато часу та послідовності при реалізації.  

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

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

Деякі важливі елементи вмісту:

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

З мого досвіду, основними проблемами при налаштуванні системи проектування є:

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

Тут ми зосередимося на тому, що безпосередньо впливає на команди.

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

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

Потім виникає питання спілкування. За розширенням номенклатури та розташування компонентів у системі проектування. Справді, щоб члени команди (нові чи ні) могли орієнтуватися, система проектування вже має бути інтуїтивно зрозумілою.   

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

Давайте візьмемо простий приклад : 

Деякі будуть говорити тут про спадний список, інші про спадний список. Ще інші зі спадного списку або навіть із DDL. 4 можливі назви для позначення окремого компонента.

Якщо для кількох компонентів системи дизайну кожен використовує власне ім’я, спілкування між людьми буде дедалі складнішим, тому що кожному доведеться докласти зусиль, щоб пам’ятати, що Ленні каже «dropdown», Карл «DDL», Ліза «droplist».

Тому кожен буде щоразу перекладати думку іншого. У цьому контексті уявіть собі Тоні, останнього прибулого. Він ще не знає, що ці колеги використовують різні імена, щоб говорити про одне й те саме. Під час розмови Ліза поговорить з ним про «дропліст». Це добре, Фреду це потрібно для його роботи. Таким чином, це буде посилатися на систему проектування і… немає компонента з назвою «droplist». Тому Фреду знадобляться додаткові зусилля, щоб знайти знаменитий компонент. Він також повинен буде дізнатися, що Ленні та Карл використовують інші терміни. 

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

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

# Підтримка та оновлення системи проектування

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

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

Систему проектування не слід розглядати як проект з обмеженою тривалістю. Компоненти та правила, які він містить, можуть змінюватися. Можуть знадобитися виняткові варіації деяких компонентів. Тому важливо продовжувати виділяти ресурси (розробники + дизайнери) для моніторингу та підтримки системи проектування. Якби його було пропущено на рік, його оновлення було б майже як повторне виконання всієї роботи з його налаштування. Це дуже довго. Ніхто не хоче робити це двічі. Не кажучи вже про витрати бізнесу. Тому важливо виділити ресурси для підтримки та розвитку системи проектування. Залежно від ступеня зрілості DS може бути достатньо однієї години на тиждень.

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

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

Якби вам довелося згадати лише кілька моментів :

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