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

Muy a menudo trabajo en este tipo de proyectos, y la respuesta es un rotundo SÍ, y tan pronto como sea posible.

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

• Dé a los expertos una impresión de cómo podría presentarse 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 realmente 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 UI incluso cuando tienes diseñadores de UI en el proyecto).

Recomiendo encarecidamente que no hagas maquetas que parezcan pantallas reales. Si los comparte con usuarios finales, 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.)

Sí, absolutamente.

No dejes que otra persona 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.

Haz maquetas de baja fidelidad, no hagas que se vean como pantallas reales. Perderá demasiado tiempo ajustando las fuentes, los píxeles y los bordes, y los usuarios se obsesionarán con esos detalles en lugar de centrarse en la funcionalidad. Algo como el balsamiq es genial para esto, no hay duda de que existen otras herramientas similares. Con la maqueta en la 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 general 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 deshacerse de sus primeros dos o tres scetches, o al menos reorganizar los elementos de la interfaz de usuario en gran medida.

Entonces, si tiene una herramienta gráfica de diseño de interfaz de usuario que le permite hacerlo 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 utilizando una herramienta de dibujo gráfico o simplemente usando lápiz y papel.

No necesariamente. Hay al menos dos razones por las que 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ás por hacer, puedes seguir adelante y hacer exactamente eso. No impulsará el arte del diseño de la interfaz de usuario, pero eso es igual de bueno.

En segundo lugar, los usuarios finales a menudo no saben qué es bueno para ellos y por qué. Simplemente no pueden decirlo 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 UI, como las pantallas N anteriores", puede comenzar con un prototipo en funcionamiento y reorganizar a medida que avanza. Realice una maqueta y discútala con sus colegas cuando esté a punto de hacer algo sofisticado.

SIEMPRE!

Trabajo para una pequeña empresa y soy la única persona de TI "blanda". Realizo 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 DEL DISEÑO: sus usuarios finales se lo agradecerán. También te agradecerás, porque HARÁS volverás a trabajar para hacer felices a los usuarios finales. Incluso si tu maqueta no es nada más que un pedazo de papel garabateado a mano, les da una idea de qué esperar. Tomar 10 minutos para garabatear algo puede ahorrar una semana de trabajo (ya lo he hecho, he hecho eso)

También te ayuda en tu codificación. Le brinda la oportunidad de pensar qué debe hacer, la manera más eficiente de lograrlo y cualquier obstáculo que pueda estar 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 le muestra a su equipo, a sus superiores, o incluso puede ser utilizado para posibles oportunidades futuras de carrera que hace más que lo mínimo y puede salir de esa caja de "no es mi trabajo" (< --- seriamente , NO seas ese chico, todos lo odiamos) o te da la oportunidad de aprender más.

Veamos esto de una manera más general:

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

¿Es una buena idea crear borradores?

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

La desventaja de crear un borrador es que usa tiempo. No tiene sentido pasar 2 horas creando un borrador elaborado para algo que demora 4 horas crearlo.

En su caso, el nivel de la maqueta debe tener en cuenta la cantidad estimada de trabajo que se realiza en el proyecto y el beneficio del borrador. Dependiendo de estos, su maqueta puede estar en cualquier lugar entre un garabato de 10 segundos en un post-it y un sitio web totalmente 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 hacen eso.

¿Quién debería crear los borradores?

No hay necesidad de una respuesta elaborada aquí: si se beneficia de la creación de un borrador, crea un borrador. Si se beneficia de que otra persona haga un borrador por usted, pídale a otra persona que haga un borrador por 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 que sea razonablemente fácil de usar. A menos que planee cambiar radicalmente la interfaz de usuario (que recomendaría enérgicamente contra ... para aplicaciones internas), simplemente siga la apariencia existente. Las maquetas son geniales, pero en tu caso, solo aumentará tu dolor.