Як побудувати успішну співпрацю дизайнера і веброзробника. Висновки з досвіду

Усім привіт! Я займаюся комерційною розробкою сайтів понад три роки. Зараз Webmaster у DataArt. Оскільки працюю в дизайн-студії і сам мав досвід у дизайні, тема роботи дизайнера та розробника пліч-о-пліч мене цікавила завжди. Адже вважаю, що гарний результат — це насамперед налагоджена робота всіх учасників, які працюють для його досягнення.

У статті розгляну:

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

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

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

Ілюстрація Уляни Патоки

Основи ефективної співпраці

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

Повага

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

Робочі стосунки

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

Раннє залучення в проєкт

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

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

Гнучкість розробки

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

Розуміння з пів слова

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

Відкритість до комунікації

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

Введення в контекст

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

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

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

Успішна передача дизайну в розробку

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

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

Інструкції зі стилю інтерфейсу (UI Style Guide)

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

Дизайн-система

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

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

Звичай найменування

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

Економія часу на роботу із запитаннями та пропозиціями

Щоб до дизайнера було менше питань і його не відволікали надто часто при роботі, варто виділити окремий час на запитання, огляди та інші внутрішні уточнення та узгодити його з розробником. Інтерактивні прототипи не у всіх проєктах потрібні та не завжди є на них час. Однак це заощадить багато часу на розробку, адже спеціаліст буде швидше працювати, ніж якби він користувався статичним прототипом. Також нерідко сайти (особливо landing pages) містять анімаційні ефекти, для зручності та більш чіткого розуміння давайте розробнику посилання на платформи, де це зроблено в схожому вигляді.

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

Готовий набір елементів інтерфейсу (UI Kit)

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

Запланована зустріч для передачі дизайну

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

Запитання до дизайнерів можуть бути такі:

• Які браузери має підтримувати продукт?
• Яку дизайн-систему використовували або запозичували?
• Який фреймворк бажано використовувати?
• Чи буде можливість клієнту змінювати контент власноруч?
• До кого звертатись, якщо виникнуть питання щодо розробленого дизайну?
• Яка точність виконання дизайну має бути, які сторінки не вимагають точної деталізації?
• Де можуть бути зміни в дизайні надалі? Чого очікувати?
• Як інформуватимуть розробника, якщо виникне потреба вносити зміни?
• Які сторінки бажано робити першими, а які можуть зачекати?

Буду вдячний, якщо дасте ще можливі питання в коментарях.

Ключові принципи передачі дизайну в розробку

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

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

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

Незручні кейси із життя веброзробника у роботі з готовим дизайном

Адаптивний та гумовий дизайни

Якщо ви розробляєте кілька розширень екранів, можете виявити, що на кінцевому етапі у вас все одно будуть «стрибки» під час зміни розмірів екрана. На це є багато причин, але розробник має уточнити, який йому обрати підхід до створення верстки продукту, щоб той мав гарний адаптив: від найменшого до найбільшого екрана (mobile first) або навпаки, від найбільшого до найменшого (desktop first). Також є елементний підхід (element first), коли ми фокусуємось не на розмірах екрана, а на елементах дизайну і тому, який вони матимуть вигляд на різних розмірах.

Детальніше про плюси та мінуси таких підходів читайте тут.

Стан наведення

Hover стан показують на кнопках, проте нерідко забувають показати на окремих елементах дизайну. Це можуть бути цитати та інші поля тексту або картинок. Корисно демонструвати всі стани динамічних інтерактивних елементів. І не забудьте надати швидкість переходу (transition) з одного стану в інший і його вид.

Індикатор фокусу

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

Організація шарів

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

Ширина контенту

Інколи ширину текстових полів, заголовків тощо роблять різною для різних розмірів екрана. Такі розміри варто вказувати окремо, зазначати, яка максимальна ширина для цього контенту, а яка мінімальна, бо розробник не завжди зауважить цю різницю. А якщо він зразу буде знати про таку поведінку деяких елементів контенту, то використовуватиме правильні інструменти. До прикладу, є такі варіанти grid-template-columns.

Буває так, що select box закороткий для деяких елементів зі списку вибору, що теж потрібно враховувати, аби розробнику потім не доводилося вигадувати, як обійти ці видимі проблеми.

Темна тема

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

Фіксація

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

Нетипові випадки

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

Багатомовність

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

Стани полів форм

Доволі очевидно, що потрібно показувати усі стани полів форм у дизайні. Однак, як свідчить практика, багато хто про це забуває. Головне — пам’ятати, які є види станів. Найпопулярніші: normal, errors, mandatory, focused, typing, disabled.

Анімації

Не варто недооцінювати анімації та мікровзаємодії, адже зараз це важливий елемент дизайну. Вони не тільки фінальними штрихами персоналізують продукт, а й, якщо це зроблено якісно, поліпшують користувацький досвід (UX). Зручний інструмент для дизайнерів — Lottie від Airbnb. Він дає змогу працювати з анімацією в AfterEffects, а потім експортувати в .json. І головне — можна переглянути готовий результат перед передачею дизайну розробникові.

Висновок

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

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