Я не хочу разжигать так называемые конфликты между ролями, но сегодня мне попалась такая статья. Да, это статья о код-обезьянах и дизайн-львах. Она началась с того, что один пользователь сети задал вопрос в некоем сообществе:
Разработчик отказывается воспроизводить дизайн в соответствии со спецификациями UI. Как мне заставить его понять важность точного воспроизведения и тем самым изменить код?
Когда инженер-разработчик раз за разом спрашивает: «Какой смысл сдвигать этот 1px? Почему я должен тратить на это время?» — и отказывается вносить изменения, как помочь этому разработчику понять и признать важность изменения?
Почему многим визуальным дизайнерам в Китае приходится гоняться за инженерами, чтобы те исправляли детали, которые кажутся незначительными, даже ничтожными, но при этом очень важны для дизайнеров, перечислять проблемы одну за другой и всё равно не получать положительного отклика от инженеров? Например, я слышал от коллеги, что инженеры в Frog разработали собственное ПО для проверки соответствия дизайну, чтобы не влиять на работу визуальных дизайнеров.
Какова глубинная причина, из-за которой реализация дизайна так трудна? Дело в том, что дизайнеры не понимают код? В эстетическом восприятии некоторых технических специалистов? Или в менталитете большой компании или других причинах? Как можно разрешить эту ситуацию? В какую эпоху или на каком переломном моменте её можно решить?
Что ж, неудивительно, что ответ с наибольшим количеством голосов был таким.
Из-за ограничений по объёму скопируйте ссылку в браузер, чтобы просмотреть полный текст. Ссылка: http://zhi.hu/8lyF
На протяжении всей статьи автор не жалеет усилий, чтобы очернить и высмеять дизайнеров, даже подменяя тему. В статье говорится:
Для разработки программного обеспечения работа кодера необходима. Работа дизайнера необязательна.
Без дизайна программное обеспечение всё ещё можно использовать. На самом деле, в сегодняшнюю эпоху плоского дизайна многие платформы разработки, такие как iOS, имеют системные шаблоны по умолчанию, которые некрасивы, но они и не голый бетонный каркас. Но без кода не было бы вообще ничего.
Важность работы определяет, кто кого слушает. Всё просто.
Что ж, после прочтения единственное чувство, которое испытал Цзиндянь, было: это бандитская группировка или просто крайнее самомнение? Если аудитория пользователей определяет качество ответов, я в этом нисколько не сомневаюсь. Помимо лёгкой неприязни к этому сообществу, Цзиндянь также хочет поделиться некоторыми мыслями и опытом о взаимоотношениях дизайнеров и разработчиков в реальности.
Сначала заявлю свою позицию: Цзиндянь — дизайнер, который немного разбирается в коде и продукте.
Всё начинается с 1 пикселя: менять или не менять?
Для ответственного дизайнера важен ли 1 пиксель? Если вы скажете, что это неважно, то Цзиндянь считает, что этот человек — не квалифицированный дизайнер, потому что это основная обязанность дизайнера.
Если вы скажете, что это важно, некоторые скажут, что в этом мире нет ничего идеального. Расслабьтесь, ничего страшного, если не менять это. Не суетитесь из-за этого!
Когда они обращаются к разработчикам, чтобы исправить эту проблему, разработчик может сказать, что изменение этого требует много работы и времени. К тому же это всего лишь проблема с пикселем, не оказывающая большого влияния, так что не меняйте это.
Продакт-менеджер говорит: Наша конечная цель — обеспечить быструю итерацию продукта и чтобы ключевые функции работали хорошо. Не нужно поправлять тот 1 пиксель; это пустая трата времени~
Хватит суетиться, хватит суетиться, хватит суетиться!
На этом этапе дизайнер, способный отпустить ситуацию, вероятно, отказался бы от такой настойчивости. Пусть и неохотно, но выбора нет, и он думает: ладно, если это не будут менять, то и не будут. Всё в мире несовершенно.
Со временем проблемы в 1 пиксель накапливаются. В конце концов, когда накопятся сотни или тысячи таких 1-пиксельных проблем, однажды пользователь скажет: "Почему это программное обеспечение (веб-страница) такое уродливое? Как вы делали дизайн? Вы некомпетентны?"
Все вокруг дизайнера говорят: "Это проблема с твоим дизайном. Неужели нельзя нормально сделать дизайн? Твоего мастерства не хватает! Твоё отношение к делу проблематично!"
Дизайнер: "..."
Думаю, это происходит вокруг всех нас. В итоге в свет выходит неаккуратное программное обеспечение (веб-страница). А реакция рынка, сами знаете...
Думаю, в этот момент в душе дизайнера наверняка проносятся десять тысяч альпак.
Плохой продукт рождается из бесчисленных компромиссов и 1-пиксельных несоответствий. В сегодняшнем крайне однородном ландшафте продуктов пользователи, естественно, выберут продукты с красивыми и удобными интерфейсами.
Никто не занимается дизайном, но программное обеспечение всё ещё можно использовать?
Да, им можно пользоваться. Без дизайна программное обеспечение абсолютно пригодно к использованию, просто пользоваться им мучительно. Например, когда люди жили в древности, все ели сырое мясо, и никто не видел в этом ничего плохого. Позже какой-то придирчивый идиот (простите за это слово, извините) сказал всем: "Эй, вообще-то мясо, зажаренное на огне, вкуснее." Представляю, как многие говорили ему: "Какого чёрта ты делаешь? Сырое мясо вкусное. Есть сырое мясо достаточно. Как хлопотно есть жареное мясо!" Но в конце концов приготовленное мясо победило сырое, и в результате после этого никто не ел сырое мясо. Что хочет сказать Jingdian: мириться с недостатками не невозможно, но мириться уже не может удовлетворять всё более высокие эстетические потребности людей. Людям нужно не только поесть, но и наесться, а потом поесть вкусно.
То же самое относится и к ценности дизайна. Что касается чьего-то заявления на ZhiX о том, что код обязателен, а дизайн необязателен, то, помимо «хех», Jingdian хотел бы также отпустить колкость: «На самом деле код тоже необязателен, потому что есть — необязательно, жить — необязательно. Всё остальное может идти к чёрту! Друг мой, разве ты не согласен?»
Когда дизайнеры начинают писать код, а программисты начинают пробовать дизайн, что делаете вы?
На самом деле проблема в 1 пиксель — вовсе не проблема. Когда дизайнер завершает макет дизайна с тщательным продумыванием и чёткими аннотациями, а разработчик следует макету, точность очень высока, в основном достигает 80–90%. Что касается мелких деталей на этом этапе, Jingdian советует дизайнерам активно общаться и координировать действия с разработчиками для решения проблем. Я считаю, что большинство разработчиков очень готовы помочь нам решить проблемы. С другой стороны, во время общения дизайнерам также нужно понимать из процесса сотрудничества, как разработчики воспроизводят макет дизайна: как пишется код, как вёрстка разумна, где можно избежать проблем и что можно продумать и решить вместе с разработчиками.
В процессе разработки приложения Jingdian компьютер имеет ту же среду выполнения, что и у разработчиков (Xcode), а git используется для синхронизации кода с кодом разработчиков. Это помогает нам понять, как создаётся программное обеспечение. При необходимости мы также можем освоить несколько небольших приёмов стилевой настройки. Для дизайнеров это означает изучение большего числа вещей, помогающих реализовать макет дизайна. Что касается разработчиков, они, безусловно, приветствуют это, потому что рядом есть кто-то, кто тоже может написать немного кода и помочь им решить проблемы, а не просто поднимать вопросы и оставлять их разбираться. Так рождаются хорошие друзья.
В ходе этого процесса происходит очень хорошее явление. Благодаря прогрессу в ваших отношениях, как дизайнер, когда программист сталкивается с выбором цвета или какими-то простыми проблемами с изображениями, вы можете удобно помочь ему. Вы даже можете установить ему Photoshop и постепенно научить его некоторой простой обработке изображений.
Таким образом возникают взаимное сотрудничество и гармоничное общение. В тот момент что вы делаете? Пишете едкий манифест на ZhiX или бесконечно жалуетесь на другую сторону?
Отличные дизайнеры и разработчики — общение и взаимопонимание
На самом деле мы постоянно подчёркиваем важность общения. Что такое общение? Двусторонний обмен — это общение. Одностороннее объяснение, когда другая сторона равнодушна, — это не общение. Ранее мы предполагали, что дизайнеры и разработчики оба разумны и не настолько несовместимы по характеру. Но что, если вы встретите несовместимого человека? Или что, если другая сторона просто отказывается изменить этот 1px? Возможные причины могут быть такими:
- 1. Дизайн-макет недостаточно проработан, изменения происходят часто. Дизайнеры, представьте ситуацию, когда вы работаете на клиента, а изменения доводят вас до белого каления.
- 2. Если дизайн-макет проработан и полностью аннотирован, но точность реализации постоянно низкая, настолько низкая, что вы не можете с этим мириться, то помимо общения перед вами встаёт вопрос способностей и отношения. Если это начальное сотрудничество, мы можем попробовать пообщаться. Если у обеих сторон хороший настрой, другая сторона, как правило, будет готова помочь. Есть ещё ситуация, на которую все обращают больше всего внимания: другая сторона крайне неуступчива. На этом этапе нам нужно попросить PM или вашего руководителя выступить посредником, чтобы скоординировать действия и успешно разрешить конфликт. Помните: в такой ситуации дизайнерам не следует быть слишком упрямыми, иначе это игла против шила, и обе стороны в итоге пострадают.
- 3. Когда дизайнер проявил внимание и понимание, как описано во втором пункте, но другая сторона остаётся крайне неготовой к сотрудничеству, что в итоге приводит к проблемам с продуктом, это уже не то, что дизайнер может решить. Верьте, что ваш начальник или руководитель глубже понимает и оценивает общую ситуацию. Всё, что вам нужно, — безупречно выполнять свою работу. Потому что качество конечного продукта уже не в вашей власти. Отпустите это и находите чувство удовлетворения другими способами.
- 4. Нет надлежащего механизма обратной связи по багам и контроля качества, а проблемы объясняются различиями в личном восприятии, а не стандартизацией процессов.
- 5. Плохая коммуникация. Я знаю, дизайнер, ты говоришь: «менять, менять, менять», а разработчик, возможно: «... (даже не утруждает себя ответом тебе)».
Нашим дорогим разработчикам
- 1. Мы знаем, что вы очень заняты, каждый день сталкиваетесь с бесчисленными строками кода, пока глаза не зарябятся, и с бесчисленными багами, которые нужно исправить. Но я очень хочу научиться немного программировать, чтобы разделить вашу ношу.
- 2. Мы знаем, что вы не низкосортный, безвкусный маньяк кода. В вашем сердце непременно есть стремление к совершенству.
- 3. Пожалуйста, поймите, что коммуникация двусторонняя. Часто нам нужно, чтобы вы сказали нам, дизайнерам, которые ничего не понимают в коде, как делать вещи лучше.
- 4. Мы знаем, что лаконичный, элегантный, высокоэффективный код — ваше дело всей жизни, но разве работа с дизайнером над исправлением проблемы в 1 пиксель не может быть тоже интересной?
- 5. Наша конечная цель одна: создать продукт, который удовлетворяет. Пожалуйста, доверяйте профессионализму дизайнера, даже если вы можете быть талантливее его.
- 6. Дизайнеры с радостью помогут вам установить на компьютер небольшие инструменты, которые делают разработку интерфейса удобнее.
- 7. Пожалуйста, не говорите обидных вещей вроде: «Если бы программисты умели пользоваться Photoshop, зачем нужны были бы художники?»
Себе — дизайнеру, стремящемуся к тому самому 1 пикселю
- 1. Быть строгим к себе — это определённо правильно. Относитесь серьёзно к каждому макету и каждому 1px.
- 2. Если вас измучили неразумные заказчики, подумайте, как вы, будучи заказчиком, теперь относитесь к «исполнителю».
- 3. Если пиксель можно поправить один раз, не правьте его дважды. Если вы правите его туда-сюда много раз, лучше извинитесь перед разработчиком, а затем научитесь править его сами.
- 4. Изучите простой код. Это не так уж сложно, и даже довольно весело. Попробуйте попросить инженеров установить на ваш компьютер среду разработки; поверьте, они будут рады помочь.
- 5. Наша конечная цель одна: создать продукт, который всех устроит. Пожалуйста, доверяйте профессионализму разработчика, даже если вы можете быть талантливее его.
- 6. Верьте, что границы между профессиями в будущем будут становиться всё более размытыми. Вы как раз такой крутой дизайнер, который умеет писать код, или, возможно, продакт-менеджер, понимающий дизайн. Пусть они вам завидуют.
- 7. Постарайтесь поверить, что каждый разработчик милый и добрый. Если не можете поверить в предыдущее предложение, не прекращайте поиски.
И напоследок: я люблю каждого дизайнера и инженера-разработчика, который работает серьёзно и самоотверженно, умеет совершенствоваться и имеет устремления.