Розглянемо наступну (ідеалізовану) діаграму.

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

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

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

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

Зверніть увагу, я зосереджуюсь на дизайнерській стороні, а не на стороні, що розвивається.

Будь-який кваліфікований дизайнер завжди буде зацікавлений у впровадженні до певної міри. Можливо, не в аспекті "я можу це побудувати", але принаймні в аспекті "це неможливо".

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

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

І я не думаю, що це так само, як ваш другий графік.

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

Чи є ще розробники, які потрапили в крайній лівий край, абсолютно. Так само, як і досі є дизайнери, які потрапляють в крайній правий край. Однак важливішим аспектом може бути досвід . Чи є розробники / дизайнери, які потрапляють в крайній лівий / правий, якщо вони мають 5, 8 або 10 років досвіду? Я сумніваюся в цьому. Чим більше досвіду, тим ближче до середини, яку вони отримують.

Тож, можливо, це доречніше:

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

Де повинна лежати відповідальність за розробку чуйного веб-сайту?

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

Спритний розвиток - це хороший спосіб наблизитись до цього.

Багато організацій , звичайно, цього не роблять, і прагнуть силосувати кожну з перерахованих вище команд і використовувати стару процедуру «кидати її через паркан і не турбуватися про це» водоспад.

Зверніть увагу, я зосереджуюсь на дизайнерській стороні, а не на стороні, що розвивається.

У цьому проблема. Ви не можете зосередитись на одному, а не на іншому. Дизайн чуйного сайту є розробка чуйним сайту.

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

Моя ідеальна структура команди UX містила б такі ролі *:

• Візуальний дизайнер та / або дизайнер інтерфейсу
• UI Developer
• Зміст
• Дослідження / Тестування користувачів

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

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

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

Хоча я погоджуюся з менталітетом у відповіді DA01, я думаю, що в цьому питання є більше, ніж просто те, на що він звертається.

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

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

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

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

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

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

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

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

І, нарешті, безпосередньо вирішити проблему під рукою в одну обставину , що ОП , здається, посилання, я скажу , що якщо повне розділення праці вирішується на (повне розділення знань / зворотній зв'язок повинна НЕ бути зроблено), то я рекомендую що команда дизайнерів повинна створити невелику і велику версію, принаймні в більшості випадків, а решта залишається розробнику. Це змушує проектну команду пам’ятати про всі етапи між тим, що не турбуватися про точні деталі.

Тут є кілька чудових відповідей, але це насправді не так складно.

Нижня лінія:

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

Не вимагайте від розробника заповнювати пробіли або спиратися на рамку.

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

Не змушуйте Інжиніринг займатися своєю роботою, і вони не просять вас зробити їх ;-)

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

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

Я збираюся пропустити веб-крафтери, оскільки я не дуже працюю з цим терміном.

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

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

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