В кожній галузі квітнуть свої стереотипи щодо певних фахів. Дуже часто вони заважають плідній співпраці. Може час позбутися них? Почнемо з дизайнерів та розробників.
У період з 2017 по 2018 рік Google підготував серію з 24 коротких відеороликів, в яких цифровий дизайнер Мустафа Куртулду (Mustafa Kurtuldu) інтерв’ював безліч дизайнерів та розробників, запитуючи спеціалістів стосовно різних хитрощів їхньої професії: від «Станьте креативним кодером» до «UX дослідження та тестування на простоту використання». Всупереч жартівливій назві, «Дизайнер проти розробника»/ Designer vs. Developer, мета серій полягала у тому, щоб зрозуміти особливості та нюанси кожної спеціальності, тим самим, заохочуючи подальшу і більш ефективну співпрацю у межах 2 дисциплін.
Як це майже завжди трапляється в інтернеті, коментатори під відео розповідали дещо іншу історію, яка демонструвала певний рівень невдоволення серед дизайнерів та розробників. Вони не мали такого ж безшовного досвіду співпраці, як люди, які віщали з екрана – для яких міждисциплінарні команди та дизайнерські спринти здавалися нормою.
Багато в чому проблема міждисциплінарної співпраці пов’язана з неправильним уявленням про те, ким насправді є дизайнерами та розробниками та те, чим вони займаються.
« – Я думаю, що дизайнерів сприймають як дуже креативних людей, які працюють незвичним, абстрактним способом – класичний стереотип стосовно студента-митця, – говорить незалежний цифровий дизайнер Майлз Палмер (Myles Palmer). – З розробниками все навпаки. Їх бачать як вундеркіндів: вони ботаніки, вони суперсерйозні люди, які влаштовані певним чином. З цього помилкового розрізнення і починаються проблеми, люди вважають, що коли дизайнери та розробники співпрацюють, це є колаборацією полярних протилежностей. Дурниці. Один із людей, який навчив мене багатьох тонкощів дизайну, є розробником, тому будь-які протиставлення не корисні для командної роботи».
Дизайнерів та розробників слід розглядати як дві сторони однієї й тієї ж монети; дизайнерам потрібна базова грамотність у деяких мовах програмування у той час, як розробники повинні розуміти типографію та макет. І так, дискусія щодо того, чи варто дизайнерам кодувати, продовжує йти своїм звичаєм (звичайно, вони повинні знати, як кодувати хоч трохи. Ніхто ніколи серйозно не замислювався над тим, чи важливо дизайнеру журналу вміти читати).
Обмін навичками та розумінням дисципліни один з одним є ключовим фактором для забезпечення безперебійної роботи серед команд компанії Figma, інструменту проєктування, розробки та створення прототипів, що сприяє співпраці в режимі реального часу між командами.
« – Я думаю, що розуміння залежить від знаходження в середовищі, – каже креативний директор Торі Хінн (Tori Hinn). – Ми намагаємось зробити програмування більш доступним для всіх. Кожного четверга ми запрошуємо всіх співробітників принести свій обід та послухати блискавичну промову одного зі своїх колег. Спочатку це були технологічні зустрічі, в рамках яких інженери компанії Figma просвіщали колег у своїй галузі, але відтоді вони еволюціонували й розширилися до інших тем. Це дуже простий спосіб дізнатися про інші дисципліни та краще зрозуміти проблеми, з якими вони стикаються».
Окрім заохочення емпатії між дизайнерами та розробниками, також важливо обміркувати, як можна використовувати їхні різноманітні кваліфікаційні знання. Правильна глибина розуміння може мати величезний вплив на те, яким буде проєкт чи продукт, не кажучи вже про те, чи почуватимуться члени команди позитивно щодо процесу співтворчості.
На одному рівні це просто зводиться до розумного персоналу. « – Вся робота у Figma є спільною, – каже Хінн, – тому ми намагаємось уважно продумувати процес найму та укомплектування персоналу. Наприклад, дизайнерська команда включає людей, кожен з яких є експертом в певній частині дизайнерського світу. Команда дизайнерів продукту працює безпосередньо з інженерами, але здебільшого незалежно один від одного. Кожна інженерна команда також виконує завдання, пов’язані з різними складовими продукту та досвіду і глибоко інтегрована з дизайнерами та дослідниками. З боку бренду наші дизайнери працюють між собою, але вони також тісно інтегруються з розробниками. Тож ми намагалися створити команди, які мають багатий досвід, який дозволить досягти найкреативніших результатів».
У Wolff Olins, одного з найбільших лондонських агентств з брендингу, обсяг роботи є різноманітнішим, і команди створюються на проєктних засадах, відповідно до потреб клієнта.
« – Наразі у нас немає штатних розробників, – каже старший дизайнер Стеффан Каммінс (Steffan Cummins). – Раніше у нас працювали розробники на постійній основі, і ми можемо повторити цю практику, але завжди йдеться про те, щоб знайти потрібну людину, яка б адаптувалася до того типу роботи, який ми виконуємо. Завдання полягає в тому, що ми працюємо з розробниками в дуже багатьох можливостях – будь то розробка веб-сайтів, креативна технологія, створення прототипів чи дизайн взаємодії – і потрібно знайти потрібну людину для кожної роботи».
Хоча це означає, що Каммінс та його команда можуть працювати з найкращими розробниками на різних етапах проєкту, в деяких випадках вони не приймаються на роботу до останньої хвилини. « – Що стосується найдрібніших деталей та остаточного виконання, зазвичай ми залучаємо спеціалістів-розробників, – говорить він. – До цього моменту ми точно знаємо, що потрібно зробити. Ми матимемо чітку інформацію та зможемо забезпечити залучення правильних людей».
Палмер вважає, що наявність розробників у складі команди від початку до кінця приносить користь усім.
« – Люди часто ставляться до цифрового дизайну, як до процесу друку, – каже він. – Ви щось проєктуєте, даєте розробнику для виготовлення, а потім вони відправляють це вам назад. Але подібна послідовність дій не є вірною. Цифровий дизайн – це жива, дихаюча річ, яка розвивається з часом. Пристрої змінюються, змінюються технології, змінюються звички людей, отже змінюється і цифровий дизайн. Це – живий організм.
В ідеалі ви хочете, щоб усі працювали разом з початку проєкту. Це більш ітеративний і приємний спосіб роботи. Ви робите великі пласти роботи, розміщуєте плоди своєї праці, заохочуєте людей користуватися ними, приймаєте відгуки, а потім проводите ще один тиждень на їхнє вдосконалення. Альтернативою є система, де матеріал розробляється без технічного розгляду, він передається розробнику для побудови, а кінцевий результат – це не те, що усі очікували, тому що мали місце великі розбіжності».
Ітераційна робота як з дизайнерами так із розробниками може стати великим бонусом для клієнтів. Замість того, щоб чекати виходу кінцевого розробленого продукту, вони можуть грати з інтерактивними прототипами на різних етапах проєкту, отримуючи реальне враження від того, як продукт функціонує.
« – Навіть низькоякісний прототип допомагає залучити клієнта, – каже Каммінс. – Важливо, щоб вони реально розуміли взаємодію».
« – Ми не можемо просто уявляти речі у своїх головах, – погоджується Палмер. – Ви можете інтерпретувати щось настільки просте, як прокрутка сторінки у стільки різних способів».
Отже, якщо це добре підходить для дизайнерського процесу та допомагає залучати клієнтів, чому інтегровані команди дизайнерів та розробників ще не є галузевим стандартом? На жаль, бюджети часто стримують команди.
« – Постійні сподівання, що ви можете робити речі швидше та краще, та відсутність розуміння, що потрібно для створення гарного дизайну та розробки, – каже Куммінс. – Це означає, що на дизайнерів та розробників часто тиснуть, щоб в найкоротші терміни придумати мінімально життєздатний продукт».
« – Клієнти повинні розуміти, що для створення чудових цифрових продуктів потрібен час і безперебійна спільна робота. Це не лінійний процес, – каже Палмер. – Це постійний цикл. Чим раніше люди сприймуть це, тим краще».
ВАРТО ЧИТАТИ:
- GlobalLogic інвестує в навчання українських embedded-інженерів
- Самотність — люди яких професій під загрозою?
- Чи може прокрастинація на роботі мати позитивні наслідки?
Джерело: TNW