Algunas estrategias prácticas para el dilema del mono pixel

Vi esta pregunta en UXSE, pero pensé que sería interesante ver cuál es la respuesta en diseño gráfico SE en comparación con stackoverflow o programación SE:

Sin embargo, solo un poco de información ... Originalmente vi la pregunta publicada en UXSE por el usuario, pero parece que la pregunta debería ser respondida por ambos lados de la cerca, así que publiqué en StackOverflow (con consecuencias desastrosas) porque debería haber sido publicado en Programmer SE en su lugar. Pero creo que el problema se aplica a muchos profesionales involucrados en equipos que colaboran en el trabajo de diseño e implementación, por lo que traté de publicar aquí en Graphic Design SE (también con consecuencias desastrosas).

Sería bueno obtener algunas respuestas porque los comentarios son bastante largos, o si es inapropiado como pregunta, algunas ideas sobre dónde debería ir esto (por favor)...

Así que ahora a la pregunta:

Una cita de una entrevista con un profesional con formación y función técnica:

Los desarrolladores son todos personas inteligentes; no disfrutan de su trabajo si alguien les dice que esto es lo que tienes que hacer y así es como lo vas a hacer. Nadie quiere sentirse como un mono programador.

Este es el llamado 'dilema del mono codificador'. Estoy seguro de que muchos de ustedes que han trabajado en diferentes tipos de equipos de desarrollo o trabajan con UX han experimentado situaciones similares en las que el papel de un diseñador visual, gráfico o similar se considera de alguna manera una "amenaza" para la satisfacción laboral de los desarrolladores. Parece que, de alguna manera, pueden ser percibidos como "difíciles" de trabajar con ellos debido a la falta de comprensión sobre los roles de los demás en el proyecto.

¿Qué enfoques (procesos, herramientas, métodos, etc.) utiliza en su trabajo para superar el 'dilema del mono píxel'?

También me gustaría leer más sobre esto si conoce alguna referencia.

Si bien es una buena pregunta, se parece mucho a un duplicado de lo que ya terminó en UX. Dada la cantidad de cruces entre UX.se y GD.se, no creo que queramos duplicados entre sitios (mis 2 centavos...)
@DA01 Creo que es importante ver las cosas desde diferentes perspectivas, y estoy particularmente interesado en cómo un diseñador visual/gráfico consideraría este dilema en comparación con un diseñador de UX. Por lo menos, apuntará a una solución común (o diferente).
En diseño, lo que describe es un subtipo raro de un tipo muy común de situación de "Clientes del infierno"; personas sin experiencia relevante en la microgestión del proceso creativo. En realidad, es bastante raro que provenga de programadores, más allá de "ugh, ¿realmente necesita X? Y sería mucho más fácil / más eficiente", mucho más común de clientes y ejecutivos o gerentes "intermediarios". Estoy seguro de que tenemos preguntas anteriores al respecto, pero no puedo encontrarlas... esto está un poco cerca graphicdesign.stackexchange.com/questions/1007/…
También creo que hay un capítulo o dos sobre esto en el libro Cómo ser un diseñador gráfico sin perder el alma , pero no tengo una copia a mano en este momento.
@MichaelLai aunque estoy de acuerdo, mi punto es que MUCHOS de nosotros estamos tanto en UX.se como en GD.se, por lo que no hay una gran diferencia de perspectiva. De todos modos, creo que las respuestas son más o menos las mismas que en UX allí. La solución es impulsar realmente los procesos de colaboración en lugar de los procesos tradicionales de cascada/tirar la valla.
De un diseñador: Para los diseñadores, es importante: Mencionar las expectativas Dar algunas pautas Explicar brevemente la naturaleza de su trabajo Lo que no quiere/necesita (anticipe errores comunes) A ​​veces vulgarice sus explicaciones (algunos diseñadores no t haga suficientes preguntas), proporcione ejemplos a los principiantes como referencia. Si puede, trabaje con diseñadores a los que les encante aprender y que sean más del tipo multidisciplinario. El peor tipo de desarrollador para diseñadores y clientes es el que está tratando de probar algo, tiene demasiado ego, no puede explicar las cosas de manera simple, ¡no es asertivo sobre lo que necesita!
@ DA01 No le haría perder el tiempo, también lo publicó en StackOverflow y Programmers como lo indica la primera oración que no se molestó en editar antes de publicar aquí (y lo confirmó al revisar su perfil). Votar para cerrar porque: A) falta de respeto, B) demasiado amplio, C) en general no somos programadores/desarrolladores web, D) la solicitud de referencias me lleva a creer que esto es algún tipo de encuesta/tarea/tesis.
Como soy ingeniero mecánico, ¿mi problema de mono se llama mono de grasa?
@ go-me ¡Agregue algunos ejemplos de su experiencia y esa sería una buena respuesta!
@ user568458 ¿Mi experiencia trabajando con desarrolladores? De ninguna manera, me votarán negativo jaja! Pero, en general, los encuentro demasiado "aceptadores" y tienen la actitud de "No importa, me ocuparé de eso". Quiero decir, ¡deberían EXIGIR lo que necesitan como archivos! A menudo simplemente me dicen "Necesito hacer una interfaz para una aplicación"... Y tengo que hacer preguntas sobre el formato, capas o no, rebanadas o no, aplicación para qué exactamente, etc. Algunos realmente se dieron por vencidos con la vida. ¡ya! Y para el ego, bueno... Noté que se enojan mucho cuando les dices "No entiendo tus variables, ¿de qué tamaño y formato quieres los archivos?" ;)
Creo que cuanta más experiencia tenga un diseñador, menos concesiones estará dispuesto a hacer a otros miembros de un equipo como los desarrolladores. Y esto funciona al revés: cuanto más involucrado esté en el código/scripting/desarrollo de herramientas y lenguajes (etc.), menos tiempo y cuidado tendrá para el "buen diseño". Descubrí que es extremadamente difícil incluso encontrar un buen desarrollador que entienda qué significa "diseño", qué es "diseño" y por qué es importante diseñar "bien" (o extremadamente bien).

Respuestas (1)

Esta es una pregunta subjetiva, por lo que mi respuesta también tiene que ser subjetiva.

Para mí, cuanta más experiencia tenga un diseñador, menos concesiones estará dispuesto a hacer a otros miembros de un equipo como el de desarrolladores. Funciona al revés: cuanto más involucrado esté en el código/script/herramientas y lenguajes de desarrollo, menos tiempo y cuidado tendrá para el "buen diseño". Descubrí que es muy difícil incluso encontrar un buen desarrollador que entienda qué significa/es "diseño" y por qué es importante diseñar "bien". Y esto también funciona al revés.

Todo se reduce a esto: puedes ser una persona con orientación visual/una mentalidad artística o una persona con mentalidad científica, pero difícilmente ambas cosas. Puedes soñar con convertirte en diseñador o programador, pero rara vez ambos.

Como diseñador, tengo mucho respeto por los desarrolladores y las personas que codifican, pero no puedo pensar que una persona pueda mantenerse al día con el mundo del diseño y con el mundo de los desarrolladores y no disminuir sus talentos en un campo u otro.

Creo que el equilibrio es clave, pero al final del día, el cliente siempre tiene la razón ("le client est roi" en francés: el cliente es el rey). Entonces, si un sitio web se entrega visualmente y en el nivel de UX, y si funciona de la manera en que los usuarios esperan que funcione, el sitio web es exitoso, sin importar cómo se logró (¡o no!) el equilibrio entre diseño y desarrollo.

Hasta cierto punto, diría que el diseño siempre es un poco más importante que el código, porque estás llegando a tu audiencia a través de la forma en que está diseñado y diseñado para funcionar. Para mí, explica la importancia del diseño en empresas como Apple: a la gente le encantan los dispositivos que se ven bien y las GUI que se ven bien y son intuitivas. El código/desarrollo tiene que servir a la experiencia del usuario.

Algunas empresas de tecnología también alentarán a sus equipos a ser más creativos . Y siempre puedes ir a visitar sitios web increíblemente diseñados cuando estés trabajando, ya seas diseñador o desarrollador...

Y luego hay algunas personas que afirman que tienes que ser muy bueno en ambos, y que terminan diciendo cosas que, creo, suenan ignorantes o extremadamente subjetivas.

No puedo estar completamente de acuerdo con esto. Sí, algunas personas son puramente visuales. Algunas personas son puramente código. Algunas personas son ambas cosas. Estas no son personas raras, aunque a veces son posiciones raras en los organigramas. Lo cual es desafortunado. La realidad es que hay muchos diseñadores que no solo están interesados, sino que son capaces de escribir un gran código viable, y hay muchos codificadores que no solo están interesados, sino que son capaces de un buen diseño web e interactivo. Es solo que muchos organigramas suprimen los talentos interdisciplinarios de muchas personas.
Pero +1 para "Creo que el equilibrio es clave".
La orientación visual y el enfoque científico no son mutuamente excluyentes, no más que tocar música. Pero incluso un gran diseñador gráfico que es un codificador superior, necesita hacer lo que mejor sabe hacer.
@ DA01 También voté sus comentarios ... y como dije, la subjetividad trae respuestas subjetivas :) Estoy seguro de que podría haber elaborado más, dados estudios de casos detallados de sitios web complejos en los que he trabajado, y la forma en que se manejó este "equilibrio" ... Pero mi respuesta en realidad comenzó como un comentario, y cuando rompió los límites del comentario, se convirtió en una respuesta completa. En tales discusiones, tengamos en cuenta que diseñamos/creamos para otros, no para nosotros mismos. El "buen código" no es necesariamente palpable para la mayoría de los usuarios. Cree productos que todos puedan usar, o no cree nada en absoluto. Es una regla básica.
@joojaa Absolutamente, y no necesariamente quise decir que fueran exclusivos, sino que no son particularmente intuitivos o fáciles de seguir simultáneamente. A los escritores no se les pide que encuadernen los libros que escriben, o que diseñen sus propias fuentes, los cineastas no procesan sus propias películas (es decir, la mayoría de ellas), etc. Cada uno debe ceñirse a su campo de especialización, permanecer curioso y confiar en otros miembros del equipo para saber lo que están haciendo. Al final del día, cuando estás trabajando con alguien que no está en la cima de su juego, por lo general puedes darte cuenta con bastante rapidez, sin importar si diseñan o codifican.
No sé, para mí el código es una especie de infografía en mi cabeza. De todos modos, en la sociedad humana, las personas no hacen lo que mejor saben hacer, sino aquello en lo que son mejores recursos. Entonces, bien podría ser que un diseñador gráfico mediocore haga guías de diseño gráfico para un diseñador gráfico brillante que resulte ser más valioso para la empresa como codificador.
Entiendo lo que dices. Pero es una analogía difícil. Lo que pasa con el diseño y el código es que hay MUCHA superposición. No puedes ser exactamente un diseñador de interacción si no puedes escribir algo de jQuery. Y no puede ser exactamente un desarrollador de interfaz de usuario si no puede crear algunos íconos cuando los necesita. Supongo que la analogía que usaría es que el código es como un pincel. Un buen pintor debe conocer íntimamente sus herramientas... los pinceles, los lienzos, las pinturas. Un buen diseñador de interfaz de usuario/interactivo usa código como un pintor usa un pincel. Es probable que el pintor le confíe a un impresor talentoso que se encargue de crear impresiones...
... y un diseñador de interacción talentoso probablemente confíe a un equipo de desarrollo talentoso la implementación final, pero eso no impide que el pintor se ensucie un poco con la prensa ni que el diseñador interactivo se ensucie un poco con las matrices de Javascript. El arte es desordenado. :)
Dicho todo esto, para volver a la pregunta original, creo que el problema realmente son los organigramas. Especialmente en las organizaciones más grandes, existe la tendencia de colocar a las personas en cubos y nunca dejar que exploren fuera de ese espacio pequeño y definido. Así es como terminas con organizaciones con equipos altamente aislados que simplemente pueden arrojar algo por encima de la cerca y esperar que el otro lado lo obtenga. Es la antítesis de la colaboración, que yo diría que es la única solución real: estar siempre colaborando.
No he tenido la "oportunidad" (o la mala suerte) de trabajar en esas empresas, @DA01, pero he trabajado con uno de los mejores diseñadores de UX que existen en la actualidad. Vino a nuestras oficinas durante tres días y simplemente agotó el producto mientras lo comentaba. Eso es todo lo que hizo. Nadie se habría atrevido a pedirle que codificara, y mucho menos modificar algo ella misma. No, ella usó el sitio web. Vio cosas que no eran ideales. Ella habló. Lo que ella dijo era oro. Todo lo que dijo tenía sentido. La persona que trabajó como diseñadora principal en este proyecto pasa su tiempo en un taller de pintura. Para mí, eso sigue siendo lo que es un equipo ideal.
@fabriced que creo que en realidad es una dinámica interesante, pero diferente. Yo lo llamo el 'diseñador versus director de arte'. Algunos de los mejores directores de arte son diseñadores experimentados y de gran talento. Algunos de los mejores directores de arte no pudieron diseñar un mantel individual. El punto es que las personas pueden ser muy hábiles en una cosa o muy hábiles en muchas cosas. O simplemente habilidoso en muchas cosas. (o sin experiencia en muchas cosas... por desgracia, he trabajado con esas personas para hacerlo.) :)
@ DA01 ¡Conclusión perfecta para esta discusión! :D Excelente, nada que agregar!
Algunas estrategias prácticas para el dilema del mono pixel
RespuestasAquíPolítica de privacidad1y, 0v