Навіщо створювати блог Design System Thiga

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

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

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

Чого очікувати від системи дизайну ?

Хоча це не срібна куля, система дизайну може бути особливо корисною, якщо у вас є:

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

Ви можете очікувати:

Спільне використання та співпраця: члени групи продуктів, дизайну чи розробки створюють спільну мову, яка значно впорядковує обмін.
Ефективність: більше не витрачаються витрачені ресурси! Зараз компоненти розробляються і розробляються лише один раз. Швидкість виробництва збільшується, витрати на проектування та розробку зменшуються. Час до ринку та час до впливу прискорюються.
Фокус: це дозволяє дизайнерам бути там, де вони можуть мати найбільше доданої вартості (дослідження користувачів, дизайн нових функцій тощо), уникаючи витрачати більшу частину свого часу на створення інтерфейсів.
Послідовність та якість: у користувача є Продукт, досвід роботи якого є цілісним завдяки чітко визначеному поведінці інтерфейсу, отже, легше обробляти та когнітивно засвоювати.

Що таке система проектування ?

Трохи історії

Ідея стандартизації візуальної ідентичності бренду не нова. Вже у 1975 році Стандартний графічний посібник NASA став першим прикладом кодифікації цього типу. Існували логотипи, шрифти та кольори, якими могли користуватися команди НАСА. Ви також можете знайти, як використовувати їх на будівлях, канцелярських товарах, формі, формах, наукових публікаціях, космічних човниках тощо.

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

Система дизайну, поєднання матеріального та нематеріального

Визначення: Що є - чи ні - система проектування ?

Починаючи з 1975 року, інші компанії наслідували цей приклад, і потроху з'явилася концепція дизайнерської системи. Ми говоримо про систему, оскільки вона є структурованим цілим, яке можна розбити на елементи та піделементи, такі як логічна або математична система. Ці елементи взаємопов’язані, багаторазові та сприймаються спільнотою людей, які самі пов’язані між собою. Таким чином, три експерти з дизайну визначають концепцію системи дизайну:

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

Тереза Міра - Старший дизайнер в Designit NYC

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

Натан Кертіс - Співзасновник EightShapes

"Система дизайну - це офіційна історія того, як ваша організація розробляє та будує цифрові продукти".

Бред мороз - веб-дизайнер, консультант, письменник

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

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

Система проектування - це система, заснована на матеріальних елементах, таких як вміст. Але також він спирається на нематеріальні елементи, такі як процеси (Тереза Міра, 7 вимог цілісної системи дизайну, Medium). Ось усе, що він може зрозуміти:

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

Матеріальні елементи:

Активи бренду (місія, цінності, тембр голосу тощо)
Принципи дизайну (або принципи досвіду)
Графічні компоненти, якими користуються спільні дизайнери
Бібліотека розроблених компонентів (спільна між розробниками)
Документація на компоненти (правила використання компонентів)
Документація щодо доступності (наприклад: рівень контрасту між текстом та фоном, субтитри до відео тощо)

Нематеріальні елементи:

Процес та управління (подання нового компонента, оновлення існуючого компонента тощо)

Основні компоненти та варіанти

Насправді, система проектування рідко буває такою всеосяжною. Залежно від вашої культури, вашої продукції та вашої зрілості в дизайні, лише деякі елементи мають значення. Ми виділяємо 3 рівні зрілості (найнижчий рівень зрілості є найпоширенішим сьогодні):

Рівні зрілості в системі дизайну (натхненний Натан Кертіс)

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

Хоча структура цих різних прикладів, як правило, однакова, деякі включають специфічні особливості, специфічні для їх конкретних потреб:

Детальні вказівки щодо взаємодії та дизайну руху.
Розділ "Як внести свій внесок", щоб кожен міг мати можливість подавати зміни (доповнення, виправлення помилок тощо).
Зовні відкриті елементи, такі як набір інтерфейсу користувача та принципи дизайну.
Детальні вказівки щодо тембру голосу.

Як це налаштувати ?

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

Ключі до гарного початку: створення вашої системи дизайну

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

- Чого ми хочемо, створюючи цю систему, які наші цілі ?
- Який периметр? Скільки продуктів або команд це повинно дозволити вирівняти ?
- Що ми будемо вкладати в систему проектування ?
- Для кого ми створюємо систему дизайну ?
- Скільки продуктів вплине на систему дизайну ?
- Які технології нам слід використовувати ?
- Який тип системи або який рівень узгодженості ми хочемо між різними Продуктами ?

Визначте цілі

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

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

Обов’язковою умовою для визначення сфери дії Системи проектування (і переконання у необхідності такої) може бути проведення інвентаризації того, що вже існує. Це включає перелік різних моделей (повторювані функціональні компоненти) та активів (елементів бренду, піктограм, кольорів тощо), що використовуються у Продукті. Кожен член команди (Дизайнери, але також Front-end Developers, наприклад) може зробити свій внесок, надаючи скріншоти для вичерпного каталогу існуючих. Інвентаризація дозволить командам:

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

Закладання основ: принципи проектування та технологічний вибір

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

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

Створіть організацію навколо Системи проектування

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

Чи варто створити команду, присвячену системі дизайну ?

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

Децентралізована або розподілена модель: кільком членам команд Продукту виділяється невелика частина часу для роботи над впровадженням та постачанням Системи проектування.
Централізована модель: за систему проектування відповідає спеціальна команда.

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

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

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

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

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

Як заохотити залучення команди ?

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

Для того, щоб організація слідувала вказівкам, встановленим командою, необхідно:

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