La mayor parte se reduciría a problemas de comunicación .
El mayor problema que he visto de los desarrolladores con respecto a los diseñadores de UX es probablemente la persona de UX que no comprende adecuadamente el esfuerzo que se necesita para implementar su diseño, o simplemente intenta hacer cambios en el diseño sin saber o pensar en las ramificaciones de cambiar lo que ha Ya ha sido construido.
Cuando los desarrolladores retroceden, a menudo es porque piensan que una tarea no es posible dentro del cronograma actual.
- Mi nuevo jefe amenaza con despedir a cualquiera que no use el IDE que ella usa. ¿Cómo debería lograr que nos deje usar el IDE que queramos?
- ¿Qué bibliotecas de Javascript usan los ingenieros de software?
- ¿Qué valor tendrán mis habilidades de software en los próximos años?
- Aparte de los algoritmos, ¿hay algo que los ingenieros de software sepan que los evaluadores de penetración no?
- ¿Cuál es el rendimiento promedio que un software de comercio de algo puede dar?
Otras cosas que he visto:
- Las formas en que hablan:
- Los desarrolladores tienden a hablar en términos de idiomas y bibliotecas. La gente de UX tiende a hablar en términos de sus propios resultados.
- Qué hacer en su lugar: los diseñadores de UX necesitan comprender más sobre cómo los desarrolladores hacen su propio trabajo y lo que necesitan. Ambos necesitan comprender cómo su rol se ajusta a la misión más amplia de lo que está haciendo su organización.
- Niveles de detalle:
- Algunos entregables de UX, como mapas de viaje del cliente, bocetos o incluso personas, pueden parecer irrelevantes para el desarrollador. Tuve un cliente que no me dio comentarios hasta que me hizo codificar un sitio beta completo para él.
- Qué hacer en su lugar: los diseñadores de UX deben tratar de llevar la realidad del producto terminado a los desarrolladores. Los consultores o autónomos de UX deberían considerar un breve documento PDF para sus clientes sobre “cómo darme su opinión de una manera que nos ayude más”.
- Casos periféricos : centrarse en los casos periféricos es una gran parte del desarrollo, especialmente en las pruebas unitarias.
- Piense en este caso: 2 botones en una pantalla; 1 hace clic el 99% del tiempo; el otro se hace clic el 1% del tiempo.
- Los desarrolladores necesitan escribir código para manejar ambos casos. El código se ve igual. Entonces, si están tomando las decisiones de diseño de la interfaz de usuario, es más probable que otorguen el mismo peso a ambos botones.
- Los diseñadores de experiencia de usuario suelen centrarse más en el flujo más probable de los usuarios a través del sistema. Si pierden el diseño para el caso límite, el desarrollador puede intentar diseñarlo para ellos. Pero si el diseñador de UX no ha comunicado lo que los usuarios necesitan en esa etapa, prepárese para una pantalla que pueda tener un rastro de pila a la vista.
- Qué hacer en su lugar: Diseñe para lo probable y proporcione lo posible. Pero en diseño, cuenta adecuadamente para ambos.