Оптимізація роботи портальної дизайн-команди з допомогою Sketch і хмари

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



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

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

Всі дизайнери нашої портальної команди працюють в загальному хмарі, розбитому на папки проектів:



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

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

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



В корені папки продукту йде розбивка на використовувані в проекті платформи. Основні портальні проекти Mail.Ru пережили кілька помітних редизайнів, тому наступний рівень ми розбили на «покоління» продуктів. Цей базовий етап дозволив нам розкласти по поличках основу і відокремити актуальні матеріали від явно застарілих.

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

На наступному рівні, як я вже згадував, можливі варіації, але в загальному вигляді це виглядає так:



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

Всередині папки з завданням є кілька обов'язкових розділів:

  • _Export — для всіх експортованих ассетов: іконки, скріни, фонові зображення і т. д.;
  • _Obsolete — для драфтовых і застарілих макетів.
Домовившись до цієї схеми, ми провели кілька планових «суботників», досить швидко розібравши накопичені за роки завали.

Тепер приступаючи до роботи над проектом, дизайнеру не доводиться з болем в серці дивитися на папки "_final", "_final-ok", "_new" і т. д. Тепер ми завжди знаємо, де брати матеріали по проекту, а так само будь макет найбільш актуальне. У цьому нам здорово допомагає Sketch.

Організація макетів
Sketch кардинально змінив те, як ми можемо структурувати свої макети. У минулому залишилися авгієві стайні з 50 psd-шників «ver.1, ver.2,… ver.90» і змушували диміти мій мак файли з усіма станами в прихованих папках або layer comps. Все стало набагато простіше.

Поєднання artboards та pages у Sketch дозволяє без особливих проблем і збитку продуктивності зберігати весь інтерфейс в одному майстер-файлі. Схема при цьому досить проста:

  • pages служать для розбиття інтерфейсу на екрани;
  • artboards — для відображення станів одного екрану.


Візьмемо, приміром, інтерфейс Пошти Mail.Ru:


Картинка кликабельна

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

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

В кожному проекті існує «майстер» — весь актуальний набір файлів проекту, які зараз в продакшені. Було б занадто ризиковано вносити зміни відразу в майстер, т. к. це може непередбачувано відбитися на проекті. У зв'язку з цим з'явився Git як система контролю змін і версій. Розробники коммитят зміни в окремі гілки і після проходження перевірок ці зміни приймаються і додаються до майстра. У результаті безліч людей, працюючи одночасно, безпечно і контрольовано оновлюють продукт.



Чим це може допомогти нам? Ні, ми не стали використовувати Git (хоча могли б, і деякі йдуть саме цим шляхом), але трохи переглянули вже наявні інструменти. Якщо оперувати поняттями розробників, то і у нас є свій «майстер» — основний скетч-файл з усіма екранами і станами інтерфейсу. Він повинен зберігатися в корені папки проекту і бути максимально актуальним. Він недоторканний, вносити в нього зміни напряму може лише кілька людей в команді. Також є «гілки» — окремі файли-копії, які ви вносите будь-які зміни в рамках виконання тієї чи іншої задачі. Кожна задача — своя гілка. Як тільки завдання, а зміни погоджені — можна взяти виправлену частина з гілки і внести у майстер-файл.



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



Для того щоб створити зв'язок, потрібно прописати одну просту команду в терміналі (terminal.app):

ln -s "/Users/username/Work folder/Master-file.sketch" "/Users/username/Library/Application Support/com.bohemiancoding.sketch3/Templates/Master-file.sketch"

  • Перший блок в лапках — це шлях до папки, де лежить майстер-файл (в нашому випадку — це Dropbox).
  • Другий блок — це шлях до папки Templates у скетчі.






Картинки клікабельні

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



Цей прийом, само-собою, працює для будь-яких sketch-файлів, тому ми не зупинилися на UI Kit'e і додали в шаблони інші часто використовувані файли, наприклад, пак з іконками і ілюстраціями. Тепер при необхідності додати в макет інтерфейсну іконку або невелику ілюстрацію ми звертаємося до цього шаблону, де вони лежать в svg, готові до експорту.



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



Картинка кликабельна

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.