Як дизайнеру і програмісту працювати злагоджено?
Ви коли-небудь серйозно замислювалися про дивацтва відносин між розробником і дизайнером? Чому фахівці, які працюють разом над створенням одного продукту, в дійсності працюють порізно. Безумовно, у кожного свої таргани і бачення проектів: якщо дизайнер представляє все з творчої та естетичної сторони, то програмісти мислять технічно.
Відео: ЯК ЗНАЙТИ ПЕРШУ РОБОТУ В КАНАДІ | Як влаштуватися програмісту або дизайнерові | Мій досвід
Про те, чому розробники і дизайнери повинні працювати разом, ми писали кілька місяців тому. Однак одне питання так і залишилося невирішеним - як повинен вести себе веб-дизайнер, щоб спільна робота вийшла дійсно конструктивної і злагодженої?
Теорій на цей рахунок існує безліч, але лише людина, яка має багаторічний досвід такого співробітництва може в повній мірі описати, що потрібно, а чого не варто робити при роботі з кодером.
Відео: Як знайти віддаленого програміста, дизайнера або копірайтера за 5 хвилин! Авито, Work-zilla і Etxt
Покопавшись на дизайнерських форумах, в зарубіжних журналах і блогах, ми знайшли найбільш розширений відповідь на наше питання. І, хоча, оригінальний пост був написаний ще в 2012 році, він актуальний донині.
Автором статті є Дженна Байлотт - дизайнер, яка пропрацювала не один рік у великих компаніях, яка вирішила поділитися своїм безцінним досвідом вибудовування відносин з програмістами. Більш того, вона дохідливо пояснила, як, в свою чергу, повинні себе вести і самі розробники, щоб робота була злагодженою і не викликала дискомфорт.
1. Користуйтеся тими ж інструментами, що і програмісти
Починаючи працювати з програмістом, перший крок, який необхідно зробити, це поцікавитися, як йому подобається працювати. багато дизайнери роблять непрощенну помилку, використовуючи в роботі методи або інструменти, до яких самі звикли або вже були успішно використані з колишніми кодерами. Однак не варто забувати, кожен фахівець унікальний: То, що підходить одному, може в корені не подобатися іншому.
Розбіжностей можна уникнути вже на самому початку проекту, лише поцікавившись перевагами розробника. Деякі фахівці люблять створити спільний документ для відстеження помилок або використовувати спеціальне програмне забезпечення. Іншим досить спілкування через емайл або використання швидкого способу начебто Pivotal Tracker.
дійсно хороший дизайнер в змозі адаптуватися до будь-якого запропонованого інструменту, який необхідний для ефективної взаємодії двох сторін. І навіть якщо його вивчення може відняти деякий час, це з лишком окупиться, скоротивши тертя і недомовки в процесі розробки продукту.
2. Беріть участь в розробці проекту з початку до кінця
Відео: Дизайнер VS Програміст
Дизайнер може легко зіпсувати свої відносини з розробником в тому випадку, коли він просто не бере участі в процесі розробки продукту. Нерідко програміст виявляється в неприємному становищі, коли ближче до запуску проекту на нього немов шуліка налітає дизайнер і вимагає детальні зміни, які можна було усунути набагато раніше.
Як не дивно, але кодеру необхідна присутність дизайнера протягом усього циклу проекту, а не тільки для того, щоб останній розробив зовнішній вигляд продукту. Дизайнер повинен бути залучений в роботу і бути в курсі важких завдань розробника. Більш того, він повинен допомагати на будь-якому етапі проекту і святкувати завершення кожного з них, як одна згуртована команда, навіть якщо це був кривої і зроблений наполовину прототип майбутнього продута.
Дуже часто можна спостерігати, як дизайнери втручаються в технічну естетику або взаємодія дизайну початкового варіанту. Настільки рання критика і зауваження щодо деталей, про які кодер ще навіть не встиг подумати, призводить до того, що програміст просто нічого очікувати йому давати наступні звіти. У підсумку все закінчується тим, що дизайнер починає вимагати будь-які значні зміни буквально перед самим запуском, але в більшості випадків, не отримує їх.
Відео: США 3: Робота в США в IT без вищої освіти. Вимоги для роботи в США IT
3. Будьте конкретні у своїх вимогах
Деякі дизайнери впевнені, що їх робота закінчена після того, як готовий макет переданий розробнику, а коли проект майже готовий до запуску, починають нервувати і чіплятися, якщо зовнішній вигляд продукту не відповідає їхнім задумом. Однак замість того щоб бризкати слиною і волати «Це не відповідає моїй задумом, подивіться ще раз макет!» - поясніть конкретно, що зроблено не так.
Сподіваємося, що досвід Дженни Байлотт допоможе побудувати ефективні робочі відносини між дизайнером і розробником, в результаті яких ми зможемо отримувати якісні продукти, що приносять ні з чим не порівнянний призначений для користувача досвід.
