Los desarrolladores son "dueños" del código, ¿no deberían los diseñadores "poseer" la experiencia?

Publicado: 2022-03-10
Resumen rápido ↬ Todos hemos estado allí. Pasó meses recopilando requisitos comerciales, resolviendo viajes de usuario complejos, elaborando elementos de interfaz de precisión y probándolos en una muestra representativa de usuarios, solo para ver un producto final que se parece poco a la experiencia deseada.

Todos hemos estado allí. Pasó meses reuniendo los requisitos comerciales, resolviendo viajes de usuario complejos, elaborando elementos de interfaz de precisión y probándolos en una muestra representativa de usuarios, solo para ver un producto final que se parece poco a la experiencia deseada .

¿Tal vez debería haber sido más contundente e insistido en un enfoque ágil, a pesar de su creencia de que la organización no estaba lista? Tal vez debería haber hecho un mejor trabajo con sus carteras de patrones, asegurándose de que los desarrolladores usaran su biblioteca de código modular en lugar de crear cinco variaciones diferentes de un carrusel. O tal vez incluso debería haberse sentado al lado del equipo de desarrollo todos los días, asegurándose de que lo que diseñó realmente se hizo realidad.

Lectura adicional en SmashingMag:

  • Por qué debería incluir a su desarrollador en el proceso de diseño
  • Colaboración en equipo y cierre de brechas de eficiencia en el diseño receptivo
  • Diseñadores y desarrolladores Jugando bien
  • Cómo comunicarse efectivamente con los desarrolladores

En cambio, te quedas con un revoltijo de elementos de la interfaz de usuario, con toda la sutileza eliminada. ¿No pudieron ver que trabajó durante días para hacer las transiciones correctamente, solo para que ellos colocaran una biblioteca de animación predeterminada? ¿Y de dónde diablos vino ese paso adicional de check-out? Apuesto a que el marketing arrojó eso en el último minuto. Sabías que la integración iba a ser difícil y que sería necesario hacer concesiones, pero se supone que debemos hacer que la vida de los usuarios sea más fácil aquí, no el equipo técnico.

¡Más después del salto! Continúe leyendo a continuación ↓
Cuando muchas personas están involucradas en un proyecto, es muy importante asegurarse de que tengan una comprensión común del problema y su solución.
Cuando muchas personas están involucradas en un proyecto, es muy importante asegurarse de que tengan una comprensión común del problema y su solución. (Crédito de la imagen: La próxima web)

Por supuesto, hay muchas buenas razones por las que el sitio es así. Diferentes equipos con diferentes niveles de habilidad trabajando en diferentes partes del proyecto, un montón de cambios de última hora que acortan el ciclo de desarrollo y una gran cantidad de desafíos técnicos. Aún así, ¿por qué el equipo de desarrollo no pudo venir y pedir su consejo sobre los cambios en la interfaz de usuario? No te metes con su código, así que ¿por qué tienen que cambiar tus diseños? ¡Especialmente cuando el impacto comercial podría ser enorme! Estás a la vuelta de la esquina y te hubiera encantado ayudar si te lo hubieran pedido.

Si bien la historia anterior puede ser ficticia, es un sentimiento que escucho de todos los rincones del mundo del diseño, ya sea internamente o del lado de la agencia. Una experiencia cuidadosamente diseñada arruinada por un equipo de desarrollo de mano dura.

Esta experiencia me recuerda una noticia que vi en un canal de noticias local de EE. UU. hace varios años. Una feria del condado estaba organizando una competencia de resistencia en la que la última persona que quedaba con la mano en una camioneta ganaba el premio. A menudo pienso que el diseño es como un juego masivo de "tocar el camión" , en el que el equipo de desarrollo siempre se lleva las llaves al final del concurso. Al igual que la última palabra en una discusión, la última persona que entra en contacto con el sitio tiene todo el poder y puede dictar cómo funciona o cómo se ve. Especialmente si afirman que la experiencia de destino en particular no es "técnicamente posible", que a menudo es una abreviatura de "realmente difícil", "No puedo molestarme en hacerlo de esa manera" o "Creo que hay una mejor manera de hacerlo". así que voy a sacar la tarjeta de desarrollo”.

Ahora sé que estoy siendo injustamente duro con los desarrolladores aquí y no pretendo serlo. Hay algunos tecnólogos increíblemente talentosos que realmente se preocupan por la usabilidad y quieren hacer lo mejor para el usuario. Sin embargo, a menudo se siente como si hubiera un nivel asimétrico de respeto entre disciplinas debido a la creencia de que el diseño es fácil y, por lo tanto, algo sobre lo que todos pueden tener una opinión, mientras que el desarrollo es difícil y solo para los especialmente iniciados. Por lo tanto, aunque se alienta a los diseñadores (a veces se espera) a que involucren a todos en el proceso de diseño, a menudo no se les permite el mismo lujo.

Para ser honesto, no los culpo. Después de todo, conozco el desarrollo suficiente para ser peligroso, por lo que sería un idiota si quisiera mi opinión sobre la estructura de la base de datos y el rendimiento del código (aparte de que creo que el rendimiento es algo bueno). Por otra parte, sé lo suficiente como para saber cuándo los desarrolladores están manipulando las cosas y siempre es divertido volver a ellos con un prototipo funcional de algo que dijeron que era imposible o que llevaría meses implementar, pero estoy divagando.

El problema es que creo que muchos desarrolladores están en la misma posición sobre el diseño, simplemente no se dan cuenta. Entonces, cuando hacen un cambio en un elemento de la interfaz basado en algo que escucharon en una conferencia hace unos años, es posible que les falte un contexto importante. Tal vez esto fue algo que ya probó y descartó porque tuvo un desempeño deficiente. ¿Quizás eligió este elemento sobre otro por una razón específica, como la accesibilidad? O tal vez las opiniones de los desarrolladores estaban equivocadas, basadas en cómo experimentan la web como superusuarios en lugar de un Jo promedio.

Ahora vamos a aclarar algo aquí. No digo que los desarrolladores no deban mostrar interés en el diseño o participar en el proceso de diseño. Creo firmemente en el emparejamiento multifuncional y creo que algunas de las mejores soluciones de usabilidad emanan del equipo de tecnología . También hay mucha gente talentosa que abarca una multitud de disciplinas. Sin embargo, en algún momento la experiencia debe ser propiedad, y no creo que deba ser propiedad de la última persona que abra el archivo HTML y "toque el camión".

Entonces, si los buenos diseñadores respetan la habilidad y la experiencia que los grandes desarrolladores aportan, ¿qué tal un poco de paridad? Si los diseñadores están contentos de que los desarrolladores "posean el código", ¿por qué no mostrar una cantidad similar de respeto y dejar que los diseñadores "posean la experiencia" ?

La comunicación es clave, así que esté disponible.
Todo el mundo tiene una opinión. Sin embargo, no es una razón suficiente para sumergirse y comenzar a hacer cambios. Crédito de la imagen: Open Source Way

Hacer esto es bastante simple. Si alguna vez se encuentra en una situación en la que no está seguro de por qué algo se diseñó de una manera particular y cree que podría hacerse mejor, no se sumerja y comience a hacer cambios . Del mismo modo, si se encuentra con un obstáculo técnico y cree que le facilitaría la vida diseñar algo de una manera diferente, hable con su diseñador. Es posible que estén absolutamente de acuerdo con los cambios sugeridos, o que quieran irse y pensar en otras formas de resolver el mismo problema.

Después de todo, la colaboración va en ambos sentidos. Entonces, si no desea que los diseñadores comiencen a "optimizar" su código en el servidor en vivo, fuera de sus procesos de control de versiones, deje de hacer lo mismo con su diseño.