¿Debería un desarrollador hacer maquetas de UI si no hay diseñadores en el proyecto?

Estoy trabajando con un pequeño equipo que crea una aplicación web propietaria y UX no es una gran prioridad ya que nuestra propia gente será la que lo opere, pero intentamos facilitar su trabajo.

¿Debería, como desarrollador, crear una maqueta de UI antes de comenzar a crear una nueva pantalla? Nada demasiado elegante, principalmente el diseño general para hablarlo con los colegas y tener un modelo de referencia. Lo estaba comparando con la creación de algunos diagramas UML antes de profundizar en escribir código a ciegas.

Uno de mis compañeros de trabajo dice que esto es absurdo y que no es mi trabajo hacer eso.

Muy a menudo trabajo en tales proyectos, y la respuesta es un rotundo SÍ, y lo antes posible.

A las personas les resulta mucho más fácil criticar mejorar algún borrador que encontrar una solución desde cero. Así que empiezo a redactar temprano por dos razones:

• Dé a los expertos en la materia una impresión sobre cómo se podría presentar la información.
• Mostrar mi comprensión actual del problema y las estructuras informativas.

En casos raros, también fue bueno tener alguna prueba de que he entregado lo que acordamos ...

Las maquetas son fantásticas y no hay razón para que un desarrollador no las haga. (Incluso puede ser útil para un desarrollador hacer un borrador de un diseño de interfaz de usuario incluso cuando tiene diseñadores de interfaz de usuario en el proyecto).

Le recomiendo que no haga maquetas que parezcan pantallas reales. Si comparte esto con usuarios finales que a menudo se centran en cosas que no importan, como los colores y los temas. Lo que te recomiendo que hagas es crear bocetos dibujados a mano en papel o en pizarra. O si los quiere en la computadora, use algo como Pencil Project o Visio ( aquí hay algunas plantillas de Visio de Jonathan Abbett que parecen dibujadas a mano).

Si, absolutamente.

No dejes que alguien más te diga cómo hacer tu trabajo. Y tiene razón, es muy parecido a hacer UML para su modelo de datos. Asumiendo que usted es un desarrollador, su trabajo es entregar software de calidad. Si las maquetas te ayudan a hacer eso, entonces eso es parte de tu trabajo.

Realice maquetas de baja fidelidad, no las haga parecer pantallas reales. Perderá demasiado tiempo ajustando las fuentes, los píxeles y los bordes, y sus usuarios se obsesionarán con dichos detalles en lugar de centrarse en la funcionalidad. Algo así como balsamiq es genial para esto, no hay duda de otras herramientas similares. Con la maqueta en mano, es mucho más fácil discutir las características del proyecto con sus usuarios y con los otros miembros del equipo de desarrollo.

Al diseñar "una nueva pantalla", primero debe analizar la idea aproximada de la interfaz de usuario con un usuario y / o sus colegas. No puede discutir esto con un usuario "en código" o "en UML", que simplemente no funciona (ni siquiera funcionará entre programadores). Y debe esperar que necesite tirar sus primeros dos o tres scetches, o al menos reorganizar en gran medida los elementos de la interfaz de usuario.

Entonces, si tiene una herramienta gráfica de diseño de interfaz de usuario que le permite hacer esto rápidamente, tiene sentido usarla. Sin embargo, si necesita codificar los elementos de la interfaz de usuario manualmente, y desechar o reorganizar los elementos de la interfaz de usuario requiere mucho esfuerzo, entonces obviamente tiene más sentido no "codificar" la interfaz de usuario primero. Será mucho más eficiente crear maquetas separadas, ya sea usando una herramienta gráfica de dibujo, o simplemente usando lápiz y papel.

No necesariamente. Hay al menos dos razones por las cuales las maquetas pueden ser de poca utilidad.

Primero, si hay prácticas bien establecidas de la industria con respecto a hacer las cosas que está a punto de hacer, puede seguir adelante y hacer exactamente eso. No impulsarás el arte del diseño de la interfaz de usuario, pero eso es igual de bueno.

En segundo lugar, sus usuarios finales a menudo no saben qué es bueno para ellos y por qué. Simplemente no pueden saberlo hasta que comienzan a usar el programa (con datos reales o simulados). Ninguna cantidad de maquetas estáticas ayudará con eso.

Con un marco web modestamente flexible, para "solo otra pantalla de interfaz de usuario, como las pantallas N anteriores", puede comenzar con un prototipo funcional y reorganizarlo a medida que avanza. Haz una maqueta y discute con tus colegas cada vez que estés a punto de hacer algo elegante.

¡SIEMPRE!

Trabajo para una pequeña empresa y soy la única persona de TI "blanda". Hago todos los requisitos, diseño, codificación, pruebas (aunque alguien siempre valida mis pruebas), diseño de bases de datos, etc.

NUNCA CORTE ESQUINAS EN LOS PASOS DE DISEÑO: sus usuarios finales se lo agradecerán. Usted se agradecerá también, porque SE terminan re-trabajo que hacer feliz a los usuarios finales. Incluso si su maqueta no es más que una hoja de papel garabateada a mano, les da una idea de qué esperar. Tomar 10 minutos para garabatear algo puede ahorrar una semana de trabajo (estado allí, hecho eso)

También te ayuda en tu codificación. Te da la oportunidad de pensar en lo que necesitas hacer, la forma más eficiente de lograrlo y cualquier obstáculo que pueda haber en el camino.

Por ejemplo, puede encontrar que el informe "simple" que necesita crear es más difícil de lo que pensó al principio porque no está capturando alguna fecha en la tabla xyz. También amplía sus horizontes y muestra que su equipo, sus superiores, o incluso pueden ser utilizados para posibles oportunidades profesionales futuras que usted hace más que el mínimo y puede salir de esa caja de "no es mi trabajo" (<--- en serio, NO seas ese tipo, todos lo odiamos) o te da la oportunidad de aprender más.

Veamos esto de una manera más general:

• ¿Crear borradores es una buena idea?
• ¿Quién debería crear los borradores?

¿Crear borradores es una buena idea?

Crear borradores proporciona principalmente 2 beneficios. Primero, proporciona enfoque, lo que conduce a una aceleración en el trabajo real que se realiza. En segundo lugar, hace que discutir la dirección del trabajo antes de que el trabajo esté completo sea mucho más simple.

La desventaja de crear un borrador es que usa el tiempo. Tiene poco sentido pasar 2 horas creando un borrador elaborado para algo que lleva 4 horas crearlo.

En su caso, el nivel de la maqueta debe tener en cuenta la cantidad estimada de trabajo que se dedica al proyecto y el beneficio del borrador. Dependiendo de esto, su maqueta puede estar entre 10 segundos en un post-it y un sitio web completamente interactivo. Para proyectos muy grandes y costosos, no es raro que equipos enteros trabajen en un borrador durante semanas y creen borradores de su borrador mientras lo hacen.

¿Quién debería crear los borradores?

No necesita una respuesta elaborada aquí: si se beneficia de crear un borrador, crea un borrador. Si se beneficia de que otra persona haga un borrador para usted, pídale a otra persona que haga un borrador para usted.

Tu colega es absolutamente correcto. Las aplicaciones internas generalmente tienen un aspecto predefinido. También para tales aplicaciones, los usuarios no buscan una interfaz de usuario de vanguardia. Todo lo que quieren es algo que funcione y sea razonablemente fácil de usar. A menos que planee cambiar radicalmente la interfaz de usuario (que desaconsejaré enérgicamente ... para aplicaciones internas), simplemente siga el aspecto existente. Las maquetas son geniales, pero en su caso, solo aumentarán su dolor.