¿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 envíos por correo (PDF A4, HTML enviado por correo), pero me complace escuchar alguna información de otros dominios (diseño web, publicidad, ...)
Mi objetivo es presentar un documento que el cliente pueda firmar y que represente el diseño real. Una vez que se firma el documento, podemos comenzar la implementación; y tienen muy poco riesgo de que el cliente no esté satisfecho con el producto real; o solicitar 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 ¿La 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 se ajusten mejor a 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 algunas razones. 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 prensa, está en prensa.
Sin embargo, el proceso de diseño hasta ese punto puede ser tan iterativo como desee. Asegúrese de estar facturando 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 en color). En un momento dado, desea que se firmen las maquetas 'finales'.
Luego pasa a la preimpresión, donde debe crearse una 'prueba' que es esencialmente la maqueta, pero con el tamaño y el color reales. Esto debe ser verificado tanto por el diseñador como por el cliente. Si está bien, entonces ese es su documento final. ¡Empiecen las prensas!
Si hablamos de diseño digital (email, web)...
Entonces mi respuesta es bastante diferente. Para el trabajo web, no existe tal cosa como una "prueba", ya que no es un medio físico grabado en piedra. Como tal, recomiendo encarecidamente alejarse de los documentos de aprobación y, en su lugar, adoptar 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 firmas ocurrían en lugares muy específicos a lo largo del camino.
Investigue 'Lean UX' para inspirarse 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.
Porque hacemos software, trabajamos con Scrum Sprints. Nos tomó 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 complicado imaginar cuánto tiempo se supone que toma algo creativo!).
Lo que hago ahora es lo siguiente: por lo general, tengo un gran elemento pendiente para la interfaz de usuario . Las tareas dentro de él van desde la investigación y las maquetas hasta la revisión, ejecución y prueba. En la práctica, la maqueta 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í y la 'forma' que toma no es tan importante (correos electrónicos, reuniones), lo 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 Inesperado, o lo dejamos para el próximo Sprint. Todos en el equipo se acostumbraron a esto, no mueves una tarjeta a Listo hasta que estés seguro de que realmente está lista (mantenemos una lista de cosas para revisar antes de mover una tarjeta, solo para asegurarnos). Si se agregan nuevas funciones o es necesario repensar las cosas, se agregan instrucciones al trabajo pendiente y elegimos el mejor momento para hacerlo.
Ahora, esto probablemente no sea algo que 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 puedan tener acceso al tablero de tareas!). Para clientes individuales, creo que una comunicación clara y un buen contrato que lo proteja de modificaciones interminables es el mejor enfoque que puede tomar.
dom
Gerardo Yin
dom