Як побудувати продуктивну взаємодію між дизайнерами й розробниками
Каріна Охріменко — Product Designer у R&D-центрі британської фінтех-компанії Wirex. Вона відповідає за дизайн вебсайту нашого продукту, блогу та Help Center компанії. Тож її роботу бачать усі, починаючи від членів наших команд, закінчуючи нашими користувачами.
Каріна вже більше як три роки у компанії Wirex. За цей час вона встигла побувати не тільки у ролі дизайнера, а й Front-End-Developer’а. І цей досвід взаємодії із візуальними елементами інтерфейсів та написанням коду й понині допомагає Карині створювати кращі дизайн-рішення.
У нашій статті Каріна вирішила поділитись методами ефективної взаємодії між розробниками та дизайнерами, та пояснила чому взагалі така комунікація є вкрай важливою для кінцевого результату роботи обох команд.
Каріна Охріменко, Product Designer: Мета дизайнера — не самовираження, а винахід якісного, продуманого рішення
Дизайн — це не відокремлений процес, а цілісна система взаємодій, направлена на вирішення певних задач. Як бачимо, більшість ресурсів зосереджені на проблемі комунікації дизайнера з клієнтом та користувачем, а також на тому, як задовольнити їхні потреби та допомогти клієнтам досягнути бізнес-цілей. Але є ще один аспект, який часто не беруть до уваги — це взаємодія дизайнерів із розробниками.
Відсутність комунікації між командами дизайнерів та девелоперів може призвести до витрачання зайвого часу на вирішення задач та зменшення продуктивності роботи спеціалістів. Команда може підготувати дизайн, віддати його в розробку, а потім виявляється, що реалізація певного рішення займатиме забагато часу, або ж буде зовсім технічно неможливою.
У результаті команда дизайнерів має винайти нове рішення, або ж зовсім відмовитись від певного функціонала. Збільшення часу на розробку, або ж погіршення юзабіліті — непростий вибір. І у такому випадку технічна обізнаність дизайнера може стати у пригоді. Уникаючи нескінченних суперечок про те, чи має дизайнер вміти писати код чи ні, можна стверджувати, що дизайнер принаймні має розуміти, як все працює. Якщо є певні сумніви щодо технічних можливостей реалізації певного функціонала — дизайнеру варто ставити запитання до розробників. Це дозволить прояснити складнощі на ранній стадії проєктування дизайну та зекономить усім командам час.
А все тому, що коли дизайнери беруть до уваги технічні можливості та залучають розробників до презентації дизайн-концепту, команди відкривають нові можливості, що йдуть усім на користь. Розробники отримують можливість поділитися своєю думкою, а дизайнери, своєю чергою, отримують необхідну інформацію для вдосконалення дизайн-рішення та оптимізації робочого процесу в цілому.
Основні методи комунікації між дизайнерами та розробниками
Одним з найуживаніших способів комунікації дизайнерів з розробниками є стайлгайд. Сітки, типографіка, кольорові схеми, компоненти, варіації станів і загалом компонентний підхід — є дуже важливою складовою для продуктивної роботи обох команд.
Дизайнери, уточнюючи технічні можливості у розробників, приймають рішення щодо того, чи то буде адаптивний дизайн, чи окрема версія для мобільних та десктопних браузерів. Так, попри те, що світ стрімко увірвався в епоху соціальних мереж та мобільних застосунків, багато бізнесів не можуть повноцінно існувати, не маючи вебсайту. Тож з огляду на розмаїття розмірів екранів та версій мобільних браузерів, дизайнери повинні створювати адаптивні та легко масштабовані компоненти.
Також дизайнерам важливо продумати усі стани роботи системи. Не тільки “happy flow”, а й імовірні системні помилки, службові повідомлення, помилки сервера тощо. На якій би стадії проєктування продукту команда не знаходилась, чи то розробка нового проєкту, чи редизайн вже наявного, — зробити це ніколи не запізно. Звичайно, іноді достатньо скористатися Material або iOS Design Kit, проте лише розробники компанії знають тонкощі поведінки певної системи та можуть підказати, на що в першу чергу звертати увагу.
Тож які саме кроки ми робимо в Wirex, щоб поліпшити процес спілкування з розробниками?
- Стайлгайд та бібліотека компонентів. Ми додаємо всі сітки, типографіку, елементи, компоненти з усіма імовірними станами та передаємо їх команді розробників через Zeplin.
- Ітераційна взаємодія. Це участь дизайнера у щоденних зустрічах з девелоперами, під час яких з’ясовуються будь-які сумніви щодо реалізації певного функціонала.
- Презентація прототипу. Тут команда дизайнерів обговорює з девелоперами усі ключові моменти розробки функціоналу, нюанси рішень та можливі відповіді системи на певні запити користувачів.
- Презентація готового дизайн рішення команді розробників. На цьому етапі команди детально розглядають всі юзер-флоу, екрани та можливі стани системи.
- Присутність дизайнера на дев-грумінгах. У процесі детального планування задач у розробників можуть виникнути сумніви або запитання, які продуктивніше вирішувати у кооперації з дизайнерами. Крім того, під час таких зустрічей дизайнер має можливість отримати ширші знання про те, як все працює.
Таким чином, чим більше запитань команда поставить на початку роботи над проєктом, тим менше проблем з’явиться на етапі презентації дизайну та у процесі його розробки. У результаті команди отримують економію часу та якісніший кінцевий дизайн.
Річ у тім, що підручники найчастіше описують ідеальні умови роботи команд. Однак, у реальності часто бракує часу на повноцінні дизайн-дослідження, може не бути остаточних вимог, та іноді певний функціонал неможливо реалізувати через технічні обмеження або з юридичних причин. Дизайнери повинні намагатися зібрати якомога більше інформації на ранніх стадіях розробки прототипу, тим самим даючи собі шанс створити ідеальне рішення у недосконалих умовах.
Важливо, що метою роботи дизайнера є не самовираження, а винахід якісного, продуманого рішення. Тож споглядаємо, прислухаймося до порад і будемо вдячними за будь-яку інформацію, бо іноді навіть найпростіша ідея може стати каталізатором для досягнення правильного рішення.
