Чекліст порад: як зробити взаємодію дизайнера та розробника ефективною

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Усім привіт! Мене звати Маша Образцова, я Front-end Developer у продуктовій IT-компанії Universe. Ми працюємо у двох напрямах — створення бізнес-утиліт для iOS та розвиток власного R&D-центру. За час своєї роботи я брала участь у розробці двох вебзастосунків, які тоді перебували на етапі стартапу. Критично важливо було пришвидшити передачу дизайну в розробку, щоб оперативно відстежувати зміни в продуктах.

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

Цей чекліст корисний для дизайнерів, розробників, а також для тестувальників, якщо в компанії є процес QA-review (тобто задачу перед розробкою приймає тестувальник, а не розробник). Як ним користуватись? Я б порадила обговорити його пункти з вашим розробником / дизайнером та обрати з них ті, що релевантні для робочого процесу. Або, можливо, він надихне вас на власні пункти.

Використовуйте auto-layouts

Auto-layouts у Figma наближає структуру та поведінку компонентів у дизайні до структури та поведінки цих самих компонентів у коді. Наприклад, під час розтягування «батьківського» компонента відповідно змінюється розмір або розміщення його «дітей».

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

Приклад помилки, що виникла через не використання auto-layout (вкладений блок ширший за батьківський)

У прикладі — ситуація, коли «дитячий» компонент ширший за «батьківський» (як показано на скриншоті: виділений фрейм ширший за «батьківський» Marketing Landing).

Так, подібних помилок припускаються в основному через неуважність. Але максимальна автоматизація (зокрема за допомогою auto-layout) повністю вилучить таку вірогідність.

Використовуйте padding та gap

Ще один з плюсів auto-layout — можливість виставляти padding та gap (тобто відступи між та всередині компонентів). Це максимально схоже на імплементацію такої структури компонента в коді.

Таким способом ви уникаєте помилок з несиметричними відстанями між компонентами або всередині фрейму (як це показано на скриншоті).

Приклад несиметричних відстаней усередині компоненту

З власного досвіду скажу, що якщо верхній відступ 152px, а нижній — 148px, то з великою ймовірністю обидва відступи перетворяться на 150px під час перенесення в код (якщо це, звичайно, не спеціальний дизайнерський задум).

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

Зверніть увагу, чи кольори та тексти прив’язані до дизайн-системи

Підніму завісу створення коду вебсайту: у більшості проєктів є щось дуже схоже на дизайн-систему.

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

Tip: у Figma для типографії, кольорів, відстаней та іншого можна використовувати figma variables.

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

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

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

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

Позначайте зміни коментарями

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

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

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

І всіх цих проблем можна уникнути, якщо дизайнер просто залишатиме коментарі про те, що він змінив. Наприклад, на елементі зі зміненим верхнім відступом поставити коментар «змінився верхній відступ».

Приклад коментаря про те, що саме змінилось у старому дизайні

Обирайте мінімальну ширину екрана мобільного девайса

У нас на проєкті це 375px, наприклад. Цей момент суто організаційний, як і попередній, але дозволяє економити час та зусилля всіх залучених сторін.

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

Чому це важливо? Знову ж таки, економія часу. З точки зору продукту абсолютно логічно створювати дизайни з урахуванням девайсів реальних користувачів. А з точки зору розробки зручно мати дизайн на найменшу можливу ширину — тоді розробникам / розробницям не треба буде придумувати, що робити з розташуванням елементів під час звуження екрана (як це було у нас на проєкті, коли дизайн розроблявся на 414px).

Tip: добре отримати аналітику розмірів екранів у реальних користувачів (якщо дозволяє продуктова частина). Ми провели такий зріз нещодавно на нашому вебпроєкті — і це дозволило значно пришвидшити та в цілому покращити процес проєктування дизайну.

Перевіряйте тексти на десктопі та мобільному

Або узгодьте, у який з варіантів гарантовано вносять правильний текст. У мене був кейс, який призвів до появи цього пункту в чеклісті. Задача полягала в оновленні декількох текстів та зміні кольорів блоків — загалом це мало зайняти 20 хвилин. А насправді зайняло на годину більше, саме через неузгодження текстів на десктопі та мобайлі. Річ у тому, що на проєкті траплялися блоки, де тексти справді за задумом відрізнялися, тому я не могла автоматично взяти оновлений текст (який був на десктопі) і підставити його в мобільну верстку.

Аби уникнути таких проблем, достатньо просто домовитися, який варіант вважати правильним у випадку розбіжностей (або ретельно перевіряти тексти під час того, як берете задачі в розробку).

Обгорніть усі компоненти у фрейми

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

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

Назвіть усі картинки / фрейми коректно

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

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

Прив’яжіть картинки до фрейму потрібного розміру

Усі необхідні шари над картинкою також потрібно прив’язати до цього фрейму.

На скрині зображені варіанти з картинкою, не привʼязаною до фрейма.

У такому разі розробник експортне саме зображення та за допомогою стилів CSS задасть йому положення на екрані (відцентрує), накладе градієнтне затемнення (можливо, цього не видно на скрині, але там є невелике затемнення).

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

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

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

Замість висновків

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