¿Existe un sistema de especificación de diseño gráfico?

¿Existe un sistema de especificación de diseño de uso común para presentar un diseño gráfico a un cliente antes de comenzar la implementación? Mi desafío es específicamente en los correos (PDF A4, HTML enviado por correo), pero estoy feliz de escuchar cualquier idea de otros dominios (diseño web, publicidad, ...)

Mi objetivo es presentar un documento para que el cliente pueda firmar y representar el diseño real. Una vez que el documento se cierra, podemos comenzar la implementación; y tienen muy poco riesgo de que el cliente no esté satisfecho con el producto real; o solicite muchos cambios después.

Especialmente, estoy tratando de evitar múltiples viajes de ida y vuelta después de la implementación donde el cliente pregunta: "¿Puedes mover este cuadro un poco hacia la izquierda?", "Hum, ¿puedes moverlo un poco hacia abajo?", "¿Puede esto imagen ser un poco más azul? "," Hum, ¿puede este campo ser un poco más grande? "," Esto funciona bien en GMail, ¡pero no estoy contento con Lotus Notes! "

Entiendo que los enfoques iterativos, ya sea facturados como Tiempo y material, o con un esfuerzo limitado, probablemente sean más adecuados para eso. (y si los usa, como diseñador profesional, hágamelo saber también). Sin embargo, en algunos proyectos, el cliente necesita un enfoque en cascada por algunos motivos. Me gustaría saber cómo manejar mejor esos casos.

No se puede hacer ágil con la impresión. No hay iteración. Una vez que está en la prensa, está en la prensa.

Sin embargo, el proceso de diseño hasta ese momento puede ser tan iterativo como desee. Asegúrese de facturar en consecuencia, por supuesto.

Por lo general, se crean maquetas (para el diseño de impresión, puede ser tan simple como las impresiones láser a color). En cierto punto, desea que se firmen las maquetas 'finales'.

Luego pasa a preimpresión, donde debería haber una 'prueba' creada que es esencialmente la maqueta, pero el tamaño real y el color real. Esto debe ser verificado tanto por el diseñador como por el cliente. Si está bien, entonces ese es su documento final. ¡Comienza las prensas!

Si hablamos de diseño digital (correo electrónico, web) ...

Entonces mi respuesta es bastante diferente. Para el trabajo web, no existe una 'prueba', ya que no es un medio físico incrustado. Como tal, le recomiendo que se aleje de los documentos de cierre de sesión y, en su lugar, adopte una metodología ágil. Esto puede ser un desafío dado que muchos clientes y organizaciones todavía están familiarizados con los viejos modelos de cascada donde las aprobaciones ocurrieron en lugares muy específicos en el camino.

Investigue 'Lean UX' para obtener inspiración sobre cómo trabajar el diseño en el modelo ágil.

Después de leer la excelente respuesta de DA , y debido a que he estado usando Scrum (Agile) para el desarrollo web y el diseño de interfaces, quería compartir mi experiencia en estos dos casos.

Como hacemos software, trabajamos con Scrum Sprints. Nos llevó un tiempo ajustar la metodología al lado del diseño del proceso (la parte más difícil para mí fue calibrar los tiempos, ¡es bastante difícil imaginar cuánto tiempo se supone que toma algo creativo!).

Lo que hago ahora es lo siguiente: por lo general, tengo un gran elemento de reserva para la interfaz de usuario . Las tareas en su interior van desde investigación y maquetas hasta revisión, ejecución y pruebas. En la práctica, la burla generalmente significa crear imágenes planas y compartirlas con el equipo. Tenemos reuniones matutinas todos los días, por lo que a veces las usamos para discutir las propuestas.

La discusión en sí misma y la 'forma' que toma no es tan importante (correos electrónicos, reuniones), lo que es importante es esto: una vez que una tarjeta de tarea se mueve a la columna 'Listo', no puede volver atrás. Si necesitamos hacer nuevos cambios, creamos una nueva tarjeta en Inesperada, o la dejamos para el próximo Sprint. Todos en el equipo se acostumbraron a esto, no mueves una carta a Listo hasta que estés seguro de que realmente está hecho (mantenemos una lista de cosas para verificar antes de mover una carta, solo para asegurarnos). Si se agregan nuevas funciones, o hay que repensar las cosas, se agregan instrucciones al trabajo atrasado y elegimos el mejor momento para hacerlo.

Ahora, esto probablemente no sea algo que realmente pueda hacer con clientes individuales, por lo que mi respuesta se limita a un escenario diferente (a menos que pueda capacitar a sus clientes en Scrum, ¡y ellos pueden tener acceso al tablero de Tareas!). Para los clientes individuales, creo que una buena comunicación y un buen contrato que lo protegerán de modificaciones sin fin es el mejor enfoque que puede tomar.