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

Ігор Артюхов, Lead Designer в NIX, який вже 9 років працює в ІТ і має досвід взаємодії з різними бізнес-доменами та різними замовниками, розповів, що має включати макет, як його перевірити та чого очікує від дизайнера розробник.

До дизайну

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

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

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

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

Консистентність

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

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

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

Під час роботи варто показувати іншій стороні проміжні результати та запитувати, що додати й у якому вигляді, щоб із цим було зручно працювати. Часом розробник може сказати: «Не треба нічого, вистачить посилання на макет». Але хороший дизайнер вирішить: «Я не просто скидатиму посилання, а все одно підготую все, стандартизую та приведу до прийнятного вигляду». У такому разі, я вважаю, що варто спочатку показати розробнику цей прийнятний вигляд. Можливо, це продемонструє турботу дизайнера про зручність команди, і тоді розробник зможе все ж таки уточнити необхідний формат. Таке спілкування є обов’язковим пунктом програми під час створення дизайну.

Перевірка

Перед передачею макету необхідно перевірити безліч деталей. Я пропоную зробити це за наступним чек-листом.

Структура макету

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

Підписи для фреймів, якщо їх багато

Вони можуть просто, але чітко описувати стан фрейму. При цьому оформлювати їх можна навіть гігантськими літерами: «ГОТОВО ДО РОБОТИ», «НЕ ЧІПАТИ, ЗНАХОДИТЬСЯ В РОЗРОБЦІ» тощо. Також можна брати великий текст і створювати рамки та смужки для відокремлення частини фреймів від інших. Якщо ж це ітераційний проєкт і робота йде з постійним створенням та поетапною відправкою в розробку чогось нового, то можна підписувати фрейми так: In progress, Ready for development тощо. Так розробники не заплутаються у файлах і швидше зорієнтуються в макеті.

Назви фреймів, груп та елементів

Крім підписів до фреймів, варто намагатися створювати логічні блоки для найменувань або назв. Зазвичай вони відповідають змісту. Наприклад, фрейм для сторінки «Про нас» можна підписати просто About Us, а підвал сторінки як footer.
Тільки необхідні розміри текстових блоків

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

Текстовий блок одним шаром

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

Відступи

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

Відсутність дробових значень

Це, як на мене, справжній must have для дизайнера. Адже цілі значення красномовно говорять про акуратність фахівця та дотримання порядку в макеті. Дробові цифри показують: дизайнер недбало ставиться до них, і це напевно проявляється в усьому іншому. Недарма перед тим, як найняти фахівця, багато лідів звертають увагу саме на цю, здавалося б, дрібницю, оцінюючи проєкти у Figma. Варто одразу привчатися робити все добре та правильно. Звісно, якщо не використовувати інструмент Scale та не відключати в налаштуваннях прив’язку до піксельної сітки, дробових значень бути не має. Але про всяк випадок варто переглянути проєкт та перевірити такі деталі.

Все виконується через стилі та компоненти

Такий підхід убезпечить дизайнера від неуважності. Допустимо, він/вона може поставити заокруглення блоків і змінити його по всьому макету, але в одному місці пропустити. У результаті втратиться єдність оформлення, та сама консистентність. Тому завжди слід намагатися використовувати компоненти.

Сітка або система відступів

Практика показує: розробникам не дуже важливе використання саме сітки. Але для них є важливою  наявність певної системи, закономірності! Про це обов’язково треба  пам’ятати. Неприйнятна ситуація, коли відступи гуляють від блоку до блоку: 25, 27, 33, 28 тощо.

Що чекає від дизайнера розробник?

Ось писок з кількох найважливіших, на мою думку, пунктів.

Макет додатку

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

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

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

Специфікації

Специфікації — це джерела даних, які цікавлять розробника насамперед. І насправді майже все, про що йде мова, багатьом розробникам взагалі не знадобиться. Тому специфікаціям треба приділити особливу увагу. Вивантажити їх для розробника можна у різні способи. Найпростіший — посилання з Figma. Коли проєкт відкривається, розробник зможе перейти до вкладки прототипування та пункту Inspect. Крім текстових та колірних стилів, там можна вибирати окремі елементи дизайну (наприклад, кнопки) із назвами, розмірами та іншими параметрами. При цьому можна змінювати одиниці виміру під CSS, iOS та Android. Зазвичай специфікацій із Figma для роботи розробника більш ніж достатньо.

Але є, звісно, ​​й інші рішення. Наприклад, Zeplin. Він призначений винятково для специфікацій, малювати в ньому неможливо. За своєю суттю Zeplin є плагіном під Figma, Sketch, Adobe XD та Photoshop. Для його використання треба реєструватися, а ключова логіка — синхронізація всіх фреймів у макеті. Після їх вивантаження на сервіс залишається лише розшарити проєкт для розробника. Він зможе побачити і макети загалом, і окремі елементи, їхні властивості, стилі, код тощо. При цьому у Zeplin у рази більше доступного та важливого саме для розробника функціоналу, ніж у Figma. Плюс у ньому можна знайти збірку всіх стилів, фактично Style Guide. Хоча я не скажу, що це критично, і часто у Figma можна обійтися базовими специфікаціями. Ще зі схожим функціоналом можна згадати Avocode. Але найбільш правильне рішення: дізнатися у самого розробника, як йому буде зручніше.

Документація

Вона є обов’язковим елементом роботи дизайнера. Зазвичай вона створюється на окремій сторінці макету та містить всі елементи: кнопки, інпути, навіть іконки, які зроблять роботу іншого дизайнера над проєктом простішою і зрозумілішою. Також супровідну документацію можна створювати у вигляді посилання — іноді навіть на ту саму Figma.

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

• Style Guide. Мінімальний варіант супровідної документації, який включає в себе опис стилів проєкту. Сюди входять кольори, шрифти, сітка, відступи, тіні, іконки, зображення, опис використання цих зображень. Якщо є зображення нестандартних форматів, потрібно враховувати, що буде при їх заміні розробником або замовником, чи кадруватиметься щось важливе тощо.
• UI Kit. Розширений формат документації. Він включає те саме, що й Style Guide, але доповнює його окремими даними. Насамперед мова про компоненти. До них відносяться кнопки та інші інтерактивні дизайн-патерни, у яких до того ж показані всі стани: наведення, натискання, заповнення тощо. Якщо проєкт досить великий і у дизайнера є час, то UI Kit буде зручнішим, аніж простий Style Guide.
• Design System. Це найкомплексніший підхід до створення супровідної документації. У класичному розумінні дизайн-система включає готові та вже зверстані компоненти. Але у дизайнерів дизайн-системою називається й дуже докладна супровідна документація. У ній не просто описані, припустимо, кнопки та їх стани, а чітко прописано: такі-то кнопки потрібні для найважливіших дій на сайті, не треба використовувати їх у таких-то випадках. По суті, це список у вигляді do та don’t/«робіть» і «не робіть», з правилами про те, як, коли, що і у якому випадку використовувати. І це стосується буквально всього: карток, тіней тощо. Більше того, у дизайн-системі можуть бути навіть посилання на дослідження, які проводив сам дизайнер, UX-ресьорчери (якщо вони підключені до проєкту) чи сторонні компанії.

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

Іменування стилів та компонентів

Правило іменування просте: спілкуватися з розробником треба однією мовою. Ідеально — називати стилі та компоненти, як у мові розмітки HTML та CSS, плюс англійською. Я виписав 12 найбільш стандартних найменувань, які використовую особисто. В інших же випадках я просто звертаюся до англійської мови. При цьому логіка імені теж проста. Якщо це, наприклад, іконки, беру для назви те, що на них зображено або де вони використовуються. А ще є терміни з верстки — navigation, header, footer, input.

Також можна працювати зі скороченнями — як btn для button (кнопка). Щоправда, саме розробники їх не використовують, хоча це загальновідомий термін. У будь-якому випадку його напевно зрозуміють усі, як і варіації типу btn secondary та btn primary (другорядна та первинна кнопки).

Карта екранів

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

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

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

Клікабельний прототип потрібен розробнику з тих самих міркувань, що й карта екранів — і тільки у випадку, коли мова йде про великий проєкт, а не умовні лендінг-пейджі. Він дає змогу зрозуміти, як працюють різні елементи. Створювати клікабельні прототипи можна у Figma, Adobe XD, Invision, Axure. Останній раніше був взагалі стандартом для інструментів прототипування через дуже крутий функціонал. Наприклад, багатьом подобалася можливість робити поля введення саме полями введення. Тобто, людина може натиснути на них і щось написати. А в клікабельному прототипі у тій же Figma поле введення — це просто прямокутник із рамкою. Максимум, що можна: показати його стан, але без справжнього інтерактиву. Щоправда, сам Axure дуже складний. Сьогодні його частіше використовують бізнес-аналітики для створення вайрфреймів.

Іконки та графіка

В ідеалі іконки та графіку потрібно викачати та віддати розробнику одним великим архівом. Так, у Figma та Adobe XD можна експортувати кожну іконку, але якщо їх буде дуже багато, розробнику доведеться обходити по черзі всі екрани, клікати на кожну іконку, щоб знайти потрібну. Краще продемонструвати турботу про колегу в команді.

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

Окремо варто сказати про назви графічних елементів. Для них слід використовувати тільки латиницю, жодної кирилиці! При цьому не варто писати англійськими літерами українські чи російські слова, нічого хорошого з цього не вийде. Також не варто використовувати прогалини. Вважається, що краще замінити їх дефісами або нижнім підкресленням. А ще стануть у нагоді префікси для типу об’єкта: ic для іконок, ill для ілюстрацій, pic для фото тощо. Наприклад, назву іконки можна формувати за чітким принципом: ic_ місце знаходження_ і що це за іконка. Тоді може вийти щось на кшталт ic_main_catalog. Такі довгі назви допоможуть будь-якій людині, яка використовує цю іконку, зрозуміти, з чим вона має справу.

Шрифти

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

Анімації

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

Про CodePen варто згадати окремо. Цей сервіс пропонує величезний архів найрізноманітніших анімацій, якими діляться розробники та дизайнери. Такі інструменти називаються пінами та, що найважливіше, можуть містити код: HTML, CSS і JS (іноді все відразу, іноді лише частина з них). Користуватись сервісом дуже просто. Достатньо ввести в пошуку, наприклад, «button», щоб отримати сотні варіантів анімації переходу від одного стану кнопки до іншого — і все з такою бажаною розробниками «кодовою» реалізацією! Залишається лише вибрати потрібний пін, скопіювати посилання на нього та передати його розробнику. Дизайнеру залишається фактично намалювати саму кнопку, а анімація буде зроблена на основі знайденого в CodePen коду.

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

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