Некоторые практические стратегии решения дилеммы пиксельной обезьяны

Я видел этот вопрос на UXSE, но подумал, что было бы интересно посмотреть, каков ответ на графическом дизайне SE по сравнению с stackoverflow или программированием SE:

Хотя немного предыстории... Первоначально я видел вопрос, опубликованный пользователем на UXSE, но похоже, что на вопрос должны ответить обе стороны забора, поэтому я разместил его на StackOverflow (с катастрофическими последствиями), потому что он должен был иметь вместо этого был размещен на Programmer SE. Но я думаю, что проблема касается многих профессионалов, участвующих в командах, которые сотрудничают в работе над дизайном и реализацией, поэтому я попытался разместить здесь сообщение о графическом дизайне SE (также с катастрофическими последствиями).

Было бы неплохо получить некоторые ответы, потому что комментарии довольно длинные, или, если это неуместно как вопрос, тогда некоторые идеи о том, где это должно быть (пожалуйста)...

Итак, теперь к вопросу:

Цитата из интервью с практиком с техническим образованием и ролью:

Все разработчики умные люди; им не нравится их работа, если кто-то говорит им, что это то, что вам нужно делать, и вот как вы собираетесь это делать. Никто не хочет чувствовать себя обезьяной-программистом.

Это так называемая «дилемма кодирующей обезьяны». Я уверен, что многие из вас, кто работал в разных типах команд разработчиков или работал с UX, сталкивались с подобными ситуациями, в которых роль визуального, графического дизайнера и т. д. в некоторой степени считалась «угрозой» для удовлетворенности работой разработчиков. Кажется, что в некотором смысле они могут восприниматься как «трудные» для работы из-за непонимания ролей друг друга в проекте.

Какие подходы (процессы, инструменты, методы и т. д.) вы используете в своей работе для преодоления «дилеммы пиксельной обезьяны»?

Я также хотел бы прочитать больше об этом, если вы знаете какие-либо ссылки.

Хотя хороший вопрос, он очень похож на дубликат того, что уже закончилось в UX. Учитывая количество пересечений между UX.se и GD.se, я не думаю, что нам нужны дубликаты на разных сайтах (мои 2 цента...)
@ DA01 Я думаю, что важно видеть вещи с разных точек зрения, и меня особенно интересует, как визуальный / графический дизайнер рассмотрит эту дилемму по сравнению с дизайнером UX. Если ничего другого, это укажет на общее (или другое) решение.
В дизайне то, что вы описываете, является редким подтипом очень распространенного типа ситуации «Клиенты из ада»; люди без соответствующего опыта микроуправления творческим процессом. На самом деле это довольно редко исходит от программистов, помимо «хм, вам действительно нужно X, Y было бы намного проще / эффективнее» - гораздо чаще от клиентов и «посредников» руководителей или менеджеров. Я уверен, что у нас есть прошлые вопросы по этому поводу, но я не могу их найти... это довольно близко graphicdesign.stackexchange.com/questions/1007/…
Я также думаю, что об этом есть глава или две в книге « Как стать графическим дизайнером, не теряя души », но у меня сейчас нет копии под рукой.
@MichaelLai, хотя я согласен, моя точка зрения заключалась в том, что многие из нас находятся как на UX.se, так и на GD.se, поэтому нет большой разницы в перспективе. Несмотря на это, я думаю, что ответы в значительной степени такие же, как и на UX. Решение состоит в том, чтобы действительно продвигать совместные процессы вместо традиционных процессов водопада / перебрасывания через забор.
От дизайнера: Для дизайнеров важно: Упомянуть об ожиданиях Дать некоторые рекомендации Кратко объяснить суть вашей работы Чего вы не хотите/не нужно (предвидеть типичные ошибки) Иногда опошлять свои объяснения (некоторые дизайнеры не t задавать достаточно вопросов), приведите примеры для начинающих в качестве справки. Если можете, работайте с дизайнерами, которые любят учиться и больше относятся к междисциплинарному типу. Худший тип разработчика для дизайнеров и клиентов — это тот, кто пытается что-то доказать, у него слишком много эгоизма, он не может просто объяснить, не уверен в том, что ему нужно!
@ DA01 Я бы не стал тратить ваше время, он также разместил его в StackOverflow и Programmers, как указано в первом предложении, которое он не удосужился отредактировать перед публикацией здесь (и подтвердил, проверив свой профиль). Голосование за закрытие, потому что: A) неуважение, B) слишком широко, C) мы в целом не программисты/веб-разработчики, D) запрос ссылок еще больше заставляет меня поверить, что это какой-то опрос/домашнее задание/тезис.
Поскольку я инженер-механик, моя проблема с обезьяной называется жирной обезьяной?
@go-me Добавьте несколько примеров из своего опыта, и это будет хорошим ответом!
@ user568458 Мой опыт работы с разработчиком? Ни в коем случае, я получу минус, ха-ха! Но в целом я нахожу их слишком «приемлемыми» и придерживаюсь позиции «Ничего, я с этим разберусь». Я имею в виду, что они должны ТРЕБОВАТЬ то, что им нужно в виде файлов! Часто мне просто говорят "Мне нужно сделать интерфейс для приложения"... И я должен задавать вопросы по формату, слоям или нет, нарезанному или нет, приложение для чего именно и т.д. Некоторые совсем разочаровались в жизни уже! Ну, а для эго... Я заметил, что они очень злятся, когда вы говорите им: "Я не понимаю ваши переменные, какого размера и формата вам нужны файлы?" ;)
Я считаю, что чем больше у дизайнера будет опыта, тем меньше уступок он будет готов сделать для других членов команды, таких как разработчики. И это работает наоборот: чем больше вы вовлечены в код/скрипты/разработку инструментов и языков (и т. д.), тем меньше времени и внимания у вас может быть на «хороший дизайн». Я обнаружил, что чрезвычайно сложно найти даже хорошего разработчика, который понимает, что означает «дизайн», что такое «дизайн» и почему важно проектировать «хорошо» (или очень хорошо).

Ответы (1)

Это субъективный вопрос, поэтому мой ответ также должен быть субъективным.

На мой взгляд, чем больше у дизайнера будет опыта, тем меньше уступок он будет готов сделать для других членов такой команды, как разработчики. Это работает наоборот: чем больше вы вовлечены в инструменты и языки кода/скриптов/разработки, тем меньше времени и усилий у вас может быть на «хороший дизайн». Я обнаружил, что очень сложно найти даже хорошего разработчика, который понимает, что такое «дизайн» и почему важно делать «хороший» дизайн. И это работает и наоборот.

Все сводится к следующему: вы можете быть визуально ориентированным человеком/художественно настроенным или научно мыслящим человеком, но вряд ли и тем, и другим. Вы можете мечтать стать дизайнером или программистом, но редко и тем, и другим.

Как дизайнер, я очень уважаю разработчиков и людей, которые кодируют, но я не могу думать, что один человек может следить за миром дизайна, а также за миром разработчиков и не уменьшать свои таланты в той или иной области.

Я думаю, что баланс имеет ключевое значение, но, в конце концов, клиент всегда прав («le client est roi» по-французски: клиент — король). Таким образом, если веб-сайт выглядит визуально и на уровне UX, и если он работает так, как ожидают пользователи, веб-сайт успешен, независимо от того, как был (или не был!) достигнут баланс между дизайном и разработкой.

В какой-то степени я бы сказал, что дизайн всегда немного важнее кода, потому что вы обращаетесь к своей аудитории благодаря тому, как он спроектирован и предназначен для функционирования. Для меня это объясняет важность дизайна в таких компаниях, как Apple: люди любят устройства, которые хорошо выглядят, и графические интерфейсы, которые хорошо выглядят и интуитивно понятны. Код/разработка должны служить пользовательскому опыту.

Некоторые технологические компании также поощряют творческий подход своих команд . И вы всегда можете посетить веб-сайты с потрясающим дизайном во время работы, независимо от того, являетесь ли вы дизайнером или разработчиком...

А еще есть люди , которые утверждают, что вы должны быть очень хороши и в том, и в другом, и в конечном итоге говорят вещи, которые, как мне кажется, звучат невежественно или крайне субъективно.

Я не могу полностью согласиться с этим. Да, некоторые люди являются чисто визуальными. Некоторые люди просто код. Некоторые люди и то, и другое. Это не редкие люди, хотя иногда они занимают редкие позиции в организационных схемах. Что прискорбно. Реальность такова, что есть много дизайнеров, которые не только заинтересованы, но и способны писать отличный жизнеспособный код, и есть много программистов, которые не только заинтересованы, но и способны создавать хороший веб-дизайн и дизайн взаимодействия. Просто многие организационные схемы подавляют междисциплинарные таланты многих людей.
Но +1 за «Я думаю, что баланс — это ключ».
Визуальная ориентация и научный подход не исключают друг друга, не в большей степени, чем музицирование. Но даже отличный графический дизайнер, который является превосходным программистом, должен делать то, что у него получается лучше всего.
@ DA01 Я также проголосовал за ваши комментарии ... и, как я уже сказал, субъективность приводит к субъективным ответам :) Я уверен, что мог бы уточнить больше, учитывая подробные тематические исследования сложных веб-сайтов, над которыми я работал, и способ управления этим «балансом» ... Но мой ответ на самом деле начинался как комментарий, а когда он вышел за рамки комментария, стал полноценным ответом. В таких дискуссиях давайте помнить, что мы проектируем/создаем для других, а не для себя. «Хороший код» не обязательно ощущается большинством пользователей. Создавайте продукты, которые могут использовать все, или не создавайте вообще ничего. Это базовое правило.
@joojaa Абсолютно, и я не обязательно имел в виду, что они были эксклюзивными, поскольку они не особенно интуитивно понятны или за ними легко следить одновременно. Писателей не просят переплетать книги, которые они пишут, или разрабатывать собственные шрифты, режиссеры не обрабатывают свои фильмы (то есть большинство из них) и т. д. Каждый должен придерживаться своей области знаний, оставаться любопытным и доверяйте другим членам команды, чтобы они знали, что они делают. В конце концов, когда вы работаете с кем-то, кто не является лучшим в своей игре, вы обычно можете довольно быстро сказать, независимо от того, занимается ли он дизайном или программированием.
Я не знаю, для меня код — это какая-то инфографика в моей голове. Так или иначе, в человеческом обществе люди занимаются не тем, в чем они лучше всего, а тем, в чем у них больше ресурсов. Так что вполне может случиться так, что графический дизайнер-медик создаст руководства по графическому дизайну для блестящего графического дизайнера, который окажется более ценным для компании как программист.
Я понимаю, что вы говорите. Но это жесткая аналогия. Дело в том, что дизайн и код во многом совпадают. Вы не можете быть дизайнером взаимодействия, если не умеете писать на jQuery. И вы не можете быть разработчиком пользовательского интерфейса, если не можете создать несколько иконок, когда они вам нужны. Я полагаю, что аналогия, которую я бы использовал, состоит в том, что код похож на кисть. Хороший художник должен хорошо разбираться в своих инструментах: кистях, холстах, красках. Хороший UI/интерактивный дизайнер использует код, как художник использует кисть. Художник, вероятно, поручает талантливому печатнику заниматься созданием отпечатков...
... и талантливый дизайнер взаимодействия, вероятно, доверяет талантливой команде разработчиков окончательную реализацию, но это не исключает того, что художник немного запутается в прессе, а интерактивный дизайнер немного запутается с массивами Javascript. Искусство беспорядочно. :)
Все сказанное, возвращаясь к первоначальному вопросу, я думаю, что проблема действительно в организационных диаграммах. Особенно в крупных организациях существует тенденция помещать людей в ведра и никогда не позволять им исследовать что-либо за пределами этого небольшого, определенного пространства. Вот как вы получаете организации с разрозненными командами, которые могут просто перебросить что-то через забор и надеяться, что другая сторона это получит. Это противоположность сотрудничеству, которое, я бы сказал, является единственным реальным решением: всегда сотрудничайте.
У меня не было «шанса» (или неудачи) работать в таких компаниях, @DA01, но я работал с одним из лучших современных UX-дизайнеров. Она приходила к нам в офис на три дня и просто использовала продукт, комментируя его. Это все, что она сделала. Никто бы не осмелился попросить ее написать код, не говоря уже о том, чтобы изменить что-либо самой. Нет, она воспользовалась сайтом. Она видела вещи, которые не были идеальными. Она говорила. То, что она сказала, было золотом. Все, что она сказала, имело смысл. Человек, который работал главным дизайнером над этим проектом, проводит время в мастерской, рисуя. Для меня это по-прежнему идеальная команда.
@fabriced, что, как мне кажется, на самом деле интересно, но с другой динамикой. Я называю это «дизайнер против арт-директора». Некоторые из лучших арт-директоров — опытные, очень талантливые дизайнеры. Некоторые из лучших арт-директоров не могли создать салфетку. Дело в том, что люди могут быть высококвалифицированными в чем-то одном или высококвалифицированными во многих вещах. Или просто опытный во многих вещах. (или неопытный во многих вещах ... увы, я работал с этими людьми.) :)
@ DA01 идеальное завершение этой дискуссии! :D Отлично, добавить нечего!
Некоторые практические стратегии решения дилеммы пиксельной обезьяны
СпросиСетьПолитика конфиденциальности1y, 0v