Під час ребрендингу для Shyp в минулому році, над дизайном продукту працювало три людини з нашої команди. В процесі ми виробили керівництво по стилю, яке могло б допомогти нам дотримуватися постійної естетики між дизайнерами. Тепер у нас є гайд по стилю для кожного нашого продукту, і цей документ став незамінним ресурсом для дизайну нових функцій і доповнень, крос-командної роботи.
Як і більшість команд, ми використовуємо Dropbox для обміну файлами і спільної роботи над проектами. Якщо дизайнер хоче змінити розмір шрифту у файлі, вони просто роблять це зміна, і натискають save, а інша частина команди використовує оновлений файл. Це відмінний режим роботи для тривалих проектів, але все ж є небезпека для дотримання сталості та проходження керівництву по стилям. На жаль, але існує великий ризик перезаписати чиюсь роботу своїми змінами, і не завжди вносяться зміни узгоджені з документацією по стилям.
Чому Github підходить нам
Коли ми обговорювали, яким повинен бути наш ідеальний робочий процес, ми зрозуміли, що команда наших розробників вже реалізувала систему для безконфліктно обміну кодом. Використовуючи Github, інженери пропонують зміни в базі коду, приходять до єдиного рішення, і переносять їх в продакшн. Це був якраз такий процес, в якому мали потребу і ми, дизайнери для файлів на зразок керівництва за стилями. Нам необхідно отримати згоду всієї команди перед перезаливка попередньої версії керівництва за стилями.
Дизайнери повинні мати можливість розпізнавати, хто і як змінював керівництво по стилям, і пропонувати свої зміни. Github відмінно підходить для таких цілей, тому що коли хтось пропонує внести зміни, інші члени команди можуть порівняти різницю з поточною версією, надати свій фітбек, при необхідності внести свої правки і схвалити нову версію.
Commit → Review → Update
І хоча ми з побоюванням представляли це нововведення в нашій роботі, його необхідність для деяких файлів із загальним доступом була очевидною. Ми хотіли, щоб зміни в керівництві по стилям проводилися за одностайним рішенням команди. Так що ми вирішили протестувати підхід, схожий з моделлю роботи наших інженерів.
Крок 1: Branch і Commit - дизайнер робить пропоноване їм зміна і коммітов його в гілку на Github
Крок 2: Pull Request - Коли все готово, вони роблять «pull request» в головній гілці
Крок 3: Review - Команда переглядає pull request і надає фідбек
Крок 4: Modify - Якщо потрібно, дизайнер вносить правки в свою пропозицію, і знову просить команду оцінити їх.
Крок 5: Merge - Як тільки зміни затверджені, дизайнер зливає pull request в головну гілку.
Крок 6: Everyone Update - критично важливий останній крок: кожен оновлює свої файли. Зміни тепер офіційні, і кожен може рухатися вперед, в згоді з новим керівництвом за стилем.
Ще одна перевага використання Github - інтеграція Slack. Як тільки хтось робить pull request, він відправляє повідомлення на наш канал #Design slack, інформуючи команду, що є пропозиція щодо змін, і потрібен їх відгук.
Все ще в пошуку
Це послужило поліпшенням нашого робочого процесу, але Github все одно не ідеально підходить нашим потребам. Дизайнерам потрібен час на вивчення Github, а це ще один додатковий етап в нашій роботі. Також неясно, як можна відстежити візуальну різницю між змінами в Github, так що отримати фідбек досить клопітно - треба спочатку завантажити файл зі змінами і вручну порівняти його з попередньою версією. Ми оцінювали і інші сервіси, такі як Pixelapse. але вони не мають за потрібне там функціоналом по типу «pull request».
Очевидно, що є й інші способи поліпшення робочого процесу, але в цілому це був корисний досвід з отримання потрібного контролю над важливими файлами. Ми можемо спільно працювати над файлами, і переваги будуть ще відчутніше у міру зростання команди. Коли нові дизайнери приєднуються до нашої команди, у них є можливість використовувати наші керівництва по стилю і пропонувати свої зміни в атмосфері здорового обговорення всією командою.
Як ваша команда працює з керівництвом по стилям?
Завжди цікаво дізнатися про досвід інших команд, як вони управляють своїми посібниками по стилям. Чи використовує такі документи ваша команда? Як ви вносите оновлення та зміни в такі файли?