Що потрібно пам’ятати при підготовці прототипу до розробки

Що потрібно пам’ятати при підготовці прототипу до розробки

November 4, 2022

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

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


Помилки, пов’язані з жорсткими навичками

Незрозумілі назви шарів

Дизайнери — початківці часто називають шари випадковим чином та виправдовують це тим, що колеги й так все зрозуміють. Так в прототипах з’являються назви на кшталт “Frame 95” або “Rectangle 10”. А в розробників, які їх бачать, виникає резонне питання: «Що це за шар, до чого він відноситься та за що відповідає?» Крім того, якщо дизайнер не вкаже точну назву, розробнику доведеться самостійно придумати текст для поля alt-text при завантаженні на сервер.

Щоб не витрачати свій час на пояснення того, до чого відноситься “Rectangle 10” та чому він ні в якому разі не повинен виходити за межі “Frame 95”, привласнюйте зрозумілі та інформативні назви шарам. Наприклад, якщо це фотографія людини, то назвіть шар з нею person-pic, якщо це кнопка — button.

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

В цьому випадку опис повинен виглядати так:

Назва: Primary-Button

Вид: Desktop

Розмір: 48

Стан: hover, active або default

Іконка: none, left, right, both

Текст: true або false

Не представлені різні стани елементів

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

Щоб так не відбувалося, продумайте та візуалізуйте всі основні стани елемента: по замовчуванню (default), при наведенні курсора (hover) та при натисканні (onclick). Коли ви додаєте посилання, то обов’язково додайте його стан після того, як користувач на нього перейде (visited). А якщо прототип має перемикач або радіокнопку, то потрібно придумати, як цей елемент буде виглядати в неактивному стані (disabled).

Відсутній порядок в ієрархії шарів

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

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

Дробові значення в розмірах шарів

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

Дробові значення ― це не завжди критично. Але якщо, наприклад, дроби будуть в розмірах картки товару, то на сторінці каталогу може з’явитися горизонтальна прокрутка, тож її стане незручно переглядати.

Якщо вам потрібно працювати без прив’язки до пікселів, то відключіть параметр “Snap to pixel grid” в налаштуваннях Figma. При цьому об’єкт, в параметрах якого є дробові значення, краще обернути в ще один фрейм, який своєю чергою буде вирівняний по сітці. Такий метод часто використовується при створенні іконок.

Для того, щоб у вашому проєкті не було дробових значень:

— Вирівнюйте об’єкти за піксельною сіткою. це можна швидко зробити за допомогою плагіну Pixel perfect.

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

— Намагайтеся вказувати тільки цілі значення в розмірах шарів та відступах між ними.

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

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

Неправильне оформлення текстових боксів

Деякі дизайнери розтягують текстові бокси вручну замість того, щоб налаштувати висоту рядка. Розробникам незручно працювати з такими текстовими блоками:тому, що в вебі не заведено фіксувати висоту контейнерів. Частіше всього їх розмір залежить від об’єму тексту, а висота всього текстового блоку — від висоти рядка в ньому (line-height). Тому не рекомендується розтягувати текстові бокси вручну, краще налаштувати висоту рядка набору (line-height) та відступи між абзацами (paragraph spacing) в спеціальному полі в Figma.

Для добре пропрацьованих (наприклад, Inter, Montserrat  Helvetica) та системних шрифтів (наприклад, Times New Roman та Georgia) краще взагалі не змінювати висоту рядка, та залишити значення по замовчуванню (auto). А якщо вам потрібно налаштувати  інтерліньяж вручну, то слідкуйте, щоб текстові блоки не виступали за межі колонки тексту.

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

Домінантна сітка

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

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

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

Помилки дизайнерів, пов’язані з гнучкими навичками

Страх перед використанням готових рішень

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

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

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

Однак є важливий нюанс: перш ніж брати чийсь шрифт, іконки або фотографії, переконайтеся, що вони доступні під відкритою ліцензією – Common Creatives (CC). Так ви убережете себе і клієнта від судових розглядів і великих штрафів за порушення авторських прав. Безкоштовні шрифти можна взяти на Google Fonts, іконки — на Flaticon, а фотографії  — на Unsplash.

Бажання підготувати фінальний дизайн з першої спроби

Завжди виконуйте роботу поетапно, щоб вона була «готова» в кожен момент часу. Тепер намалювати модний інтерфейс (UI) стало досить просто: можна підібрати будь-які кольори в спеціальному генераторі палітри Adobe Color, взяти вдалі пари шрифтів на Google Fonts або Type Wolf, а градієнти — на Webgradients. Набагато складніше продумати бізнес-логіку і шлях користувача на сайті – тобто UX. Це вимагає великих зусиль та розвинених аналітичних і комунікативних навичок.

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

Страх або небажання спілкуватися з розробниками

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

Для того, щоб вам не довелося викидати або переробляти готовий прототип, важливо:

— Заздалегідь приєднати розробника до проєкту. Найкраще залучати його до зустрічі з клієнтом після етапу аналітики та збору первинних вимог.

– Не бійтеся спілкуватися з розробником і ставити питання. Показуйте вайрфрейми або окремі блоки, уточнюйте та ставте відкриті питання: «Чи можна це зробити, чи ні? Якщо ні, то чому? Якщо так, то наскільки це складно і скільки часу це займе?". Запитуйте, поки не зрозумієте, яке рішення буде оптимальним у вашій ситуації.

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

Страх перед презентаціями

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

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

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

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

Розкажіть, які думки у вас виникли під час роботи над завданням, і чому ви пропонуєте саме таке рішення. Це потрібно для того, щоб уникнути питань на кшталт: «Чому ця кнопка синя, а та, що поруч з нею, сіра?» Буде добре, якщо після презентації або скрінкасту у розробника або клієнта до вас не залишиться ніяких питань. Але якщо вони з'являються, то переживати все одно не варто: це додатковий привід задуматися над своїм рішенням і зробити його ще кращим.

Методи досліджень для продуктових менеджерів

Методи досліджень для продуктових менеджерів

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

Design
Джунглі веброзробки: як не заплутатися серед фронтенду і бекенду

Джунглі веброзробки: як не заплутатися серед фронтенду і бекенду

Чим займаються веброзробники, які сфери існують в професії та чим вони відрізняються одна від одної

Front End
5 книг для продуктового дизайнера

5 книг для продуктового дизайнера

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

Design