Основні уроки, які я засвоїв, створивши популярну систему дизайну

Ілюстрація супер талановитої Майї Елі

У 2012 році я розпочав невеликий побічний проект зі стандартизації дизайнерських моделей та досвіду користувачів 12 програмних продуктів в Atlassian. Протягом наступних 3 років цей невеликий побічний проект перетворився на дуже великий проект, який став моєю повною роботою, яка передбачала створення та доставку декількох версій Atlassian Design System і створила команду дизайнерської платформи (яка існує і сьогодні, але з багатьма іншими люди) для обслуговування та використання систем, що працюють в усьому наборі продуктів Atlassian.

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

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

1. Почніть з того, що не має масштабів

Перша версія Atlassian Design System мала близько 20 статичних HTML-файлів, які я розмістив на Mac Pro під своїм робочим столом. У цих файлах не було шаблонів, не було контролю над версіями, я імпортував CSS з наших продуктів, і я сам написав розмітку для кожного компонента. Ця версія була неприємна для оновлення і не була масштабованою, але достатньо людей знайшли в ній цінність, що саме я надихнувся інвестувати більше часу та зусиль, що поставило нас на шлях створення системи дизайну Atlassian.

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

2. Не озброюйте свої правила

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

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

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

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

3. "Давайте просто переробимо все"

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

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

4. Отримайте перехресну функціональну підтримку вашої системи дизайну

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

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

Ще в 2013 році співвідношення дизайнера та інженера було чимось у діапазоні від 1 дизайнера до кожні 15–20 інженерів. Хоча сьогодні я здригаюся від думки про це число, тоді я намагався використати цей дисбаланс на свою користь. Щось, що допомогло мені отримати інженерну організацію на моєму боці в Atlassian, це створити розмову для нових початківців під час їх першого тижня на борту в компанії. Близько 15 людей близько цього тижня, і я можу змусити їх зрозуміти, що ми намагаємося робити з першого дня. Наприклад, я перегляну історію того, як у нас було 44 різні спадні місця меню (не перебільшення), але у нас це є зараз, і ось, як ви повинні ним користуватися.

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

5. Вийдіть за посібник зі стилів

Система дизайну (або настанова) відрізняється від посібника зі стилів. Отримати всі компоненти у файлі Sketch досить просто - всі основні кнопки одного кольору, або ви використовуєте сітку 8 пікселів. Але коли я використовую первинну кнопку замість другої? Які мітки повинні мати кнопки? Коли первинна та вторинна кнопки разом, яка зліва?

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

Як я вже згадував вище, проектна команда Atlassian на початок 2013 року була порівняно невеликою (~ 13 осіб) порівняно з інженерною командою (~ 300 осіб). Однією з переваг включення письмових рекомендацій було те, що інженери могли досягти величезного прогресу без дизайнера там. Це означало, що ми можемо зупинити розробку екранів у Sketch і замість цього стрибнути на дошку та мозковий штурм потоку або почати працювати над значно більшими проблемами з продуктами, які існували вище за течією.

6. Попросіть когось наглядати за системою, але переконайтесь, що кожен робить внесок

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

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

Цікавить дізнатися більше про Асану? У нас на сайті https://asana.design є акуратний веб-сайт, де ми можемо трохи ознайомитись з тим, хто ми і що робимо. Ми також наймаємо менеджерів дизайну та дизайнерів продуктів у нашому офісі в Сан-Франциско, одному з найкращих місць для роботи в 2018 році! (Ми можемо переїхати, якщо ви зараз не перебуваєте в районі затоки.)

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