Mejor documentación y comunicación del equipo con documentos de diseño de productos

El proceso típico para trabajar como diseñador de producto en una empresa o startup puede resultarte familiar: se está desarrollando un nuevo producto para el que dar una solución de diseño. Luego, trabaja en algunas propuestas de diseño y las presenta frente a 1 a 3 personas para recopilar comentarios.

A veces este proceso funciona bien, pero otras veces no. Por ejemplo, algunas personas están ocupadas prestando atención para terminar sus propias tareas y no dedican suficiente tiempo a proporcionar comentarios claros y concisos para su propuesta de diseño.

También puede suceder que, aunque su proceso sea bueno, aún desee formalizar el proceso anotando decisiones, realizando un seguimiento de las iteraciones y el proceso de diseño en general, especialmente en los tiempos actuales en los que nos encontramos trabajando de forma remota debido a COVID19.

Documentar el proceso tiene muchos beneficios. Por ejemplo, hace que su trabajo sea más visible, crea oportunidades para obtener comentarios de muchas más personas, mejora la comunicación general y proporciona una imagen clara de cómo se diseñó una característica con todo el contexto y las consideraciones que la rodean.

La caída del diseñador héroe

Alrededor de 2018, estaba trabajando como Product Designer remoto desde Madrid en una empresa que opera en América Latina, involucrando en este proceso a otros equipos de México y Sao Paulo, Brasil.

Antes de comenzar a trabajar en esta empresa, tuve muchas experiencias diferentes en mi carrera trabajando en entornos pequeños y grandes de muchos sectores diferentes, como medios de comunicación, estudios de diseño, una red social, un sistema operativo móvil, fundé una startup de comercio electrónico. , e incluso hizo algunos trabajos independientes con otras pequeñas empresas emergentes.

Durante esos años había estado siguiendo el mismo enfoque, haces que algunas personas se sienten en la misma sala, presentas tu solución, proporcionas algunas pantallas, flujos, recibes comentarios y la vuelves a presentar. Después de algunas iteraciones, su trabajo estará listo para llegar a la fase de desarrollo.

Sin embargo, este mismo enfoque dejó de funcionar. Poco después de unirme al equipo, me di cuenta de que presentar mis diseños en una videollamada no era suficiente. Estaba creando muchas propuestas, pero no pude llegar a la aprobación final de mis partes interesadas y compañeros de equipo. Estaba confundido y me preguntaba: ¿Qué estaba pasando? ¿No estaba diseñando la mejor solución posible? ¿No estaba entregando un trabajo de buena calidad? Cada una de esas preguntas me estaba haciendo perder la confianza en mí mismo. El problema era que necesitaba adaptar mi proceso a este entorno.

Tan pronto como me di cuenta de que mi proceso no estaba funcionando, comencé a leer muchos artículos sobre cómo trabajar como diseñador de forma remota, el efecto gaviota (cuando alguien entra en tu trabajo, lo critica duramente y luego se va volando), cómo otras empresas se estaban acercando a la colaboración remota y cómo formalizaron su proceso escribiéndolo. Después de leer todo este material, me preguntaba cómo se enfrentaban los desarrolladores a este mismo problema. ¿Cómo colaboran en entornos remotos de forma casi asincrónica? ¿Cómo llegan a acuerdos finales? Descubrí que, de hecho, la comunidad de desarrolladores ya tiene un proceso que les funciona bastante bien: se llama solicitudes de incorporación de cambios.

Las solicitudes de extracción le permiten introducir cambios en una base de código más grande al documentarlos y validar sus decisiones con los comentarios de otras personas. De esta forma, los cambios que introduzcas se mezclan a la perfección con todos los estándares y conexiones que ya tiene el código. Esto es exactamente lo que necesitaba lograr, pero por supuesto con un enfoque de diseño y moda. Permítanme presentarles el documento de diseño de productos.

El documento de diseño de producto

Un documento de diseño de producto (PDD) es un documento que convierte los problemas que desea resolver, el contexto y la solución final en un enfoque iterativo o basado en etapas.

Esto significa que puede documentar todo su proceso de diseño en un solo documento que se puede compartir con cualquier persona en su empresa y se mantendrá como una base de conocimiento para las decisiones de productos que tome. Suena genial, ¿eh? Profundicemos en los detalles.

Conceptos Generales

Un PDD se puede describir en 4 conceptos principales: metadatos, contexto, etapas y retroalimentación .

• Los metadatos son solo información útil sobre el documento, como el título, la fecha, el estado, etc.

  

• El contexto es lo que otras personas necesitan leer para entender las propuestas de diseño que haces, piénsalo como la descripción, el problema, el resumen o los objetivos de lo que necesitas lograr.

• Las etapas son las diferentes iteraciones de su diseño, generalmente comenzando a enfocarse en la solución más amplia y en cada etapa enfocándose en detalles más específicos. Cada etapa se basa en la anterior y responde a la retroalimentación recibida. Esta es una forma estructurada de llegar a un punto final donde los problemas resueltos no pueden volver a aparecer.

• La retroalimentación se refiere a todas las opiniones, comentarios, solicitudes y recomendaciones que recopilas de otras personas. Puede recopilar comentarios de sus partes interesadas o miembros del equipo.

Con estos cuatro conceptos, puede crear diferentes variaciones de PDD para satisfacer sus necesidades, cada empresa/proyecto es diferente y lo que funcionó para mí, no tiene que funcionar de la misma manera para usted. Pero si cubre estos 4 conceptos principales en su PDD, es probable que funcione en casi cualquier situación.

Estructura de ejemplo

Después de entender los conceptos principales, compartiré con ustedes la estructura que he estado usando durante mi tiempo en esa empresa. Tiene las siguientes secciones:

• El Título debe ser conciso, claro y fácilmente distinguible de otros títulos PDD que ya tenga.
• El Estado indica en qué etapa se encuentra su documento en este momento:
• Sequía
  Todavía estoy trabajando en la definición del Contexto. No estoy listo para recibir comentarios.
• S30, S60, S90
  Las diferentes etapas (30%, 60%, 90%) de su solución (más detalles sobre las etapas más adelante).
• Completo
  Todos los comentarios se han abordado y no faltan puntos. El PDD está terminado.
• El resumen es la descripción del problema para el que necesita diseñar, y generalmente se vincula a otras lecturas relacionadas útiles que pueda tener.
• Los objetivos son los puntos clave en los que debe enfocarse su solución, esta es una lista de verificación que revisará constantemente para asegurarse de que está en el camino correcto.
• S30 (o Stage 30% ) es la primera propuesta que haces en base al resumen y los objetivos, centrándote en la solución más amplia en lugar de los detalles, tal vez proporcionando una estructura alámbrica de baja fidelidad o una técnica similar. Esta es la etapa en la que la solución propuesta podría tener un enfoque totalmente diferente y se espera que ocurra una retroalimentación importante.
• S60 (o Stage 60 % ) es su solución al 60 % de integridad y aplica los comentarios de S30. Tiene menos detalles que el S90, pero indica claramente la intención de su solución. Proporciona una estructura alámbrica de alta fidelidad con más casos involucrados y algunas definiciones de flujo. Es posible que reciba algún tipo de retroalimentación que se centre principalmente en casos perdidos y pequeños escenarios inesperados.
• S90 (o Etapa 90% ) es la etapa que tiene la solución al 90% de completitud y aplica la retroalimentación de S60. Esta etapa se enfoca en los detalles más finos de su diseño, incluidos todos los diferentes escenarios, casos de esquina, diseño visual e incluso prototipos. Se espera que tenga algún tipo de retroalimentación menor.

Quizás se esté preguntando, ¿debo seguir el mismo orden y la misma convención de nomenclatura de etapas? Bueno, no, no lo haces. Puede cambiar el nombre de la etapa de S30, S60 y S90 a solo: Exploración, Propuesta, Solución.

También puede cambiar el orden para que el trabajo más refinado (S90, Solución) quede en la parte superior del documento y el flujo de lectura pase de la etapa final a la inicial (S30, Exploración).

Plantillas

Comience rápidamente con una de las plantillas provistas para las plataformas de escritura más comunes. Recuerda: Las convenciones de nomenclatura de las secciones son totalmente personalizables. Si no le gusta Abstract , simplemente use Brief , About o cualquier cosa que se adapte a sus necesidades. El concepto principal que deberá mantener es sobre la creación de diferentes iteraciones para centrarse en cada etapa, simplemente puede cambiar el nombre de S30 por Exploración, S60 por Propuesta y S90 por Solución.

• Papel
• Noción
• Documentos de Google
• ejemplo de la vida real

Beneficios clave de usar PDD

1. Cada decisión está documentada.
   Lo que significa que incluso cuando deje su empresa/proyecto (y eso sucederá tarde o temprano), todo el conocimiento generado se quedará en la empresa para siempre, para que otras personas puedan verlo e iterar desde donde lo dejó.

2. Mejora la comunicación.
   Hacer que diferentes personas de su equipo en el PDD brinden retroalimentación ayuda a que todos permanezcan en la misma página y estén al tanto de las decisiones tomadas.

3. Limita los cambios interminables de las partes interesadas.
   Cada etapa se enfoca en un ángulo diferente del problema, pasando de soluciones más amplias a soluciones más específicas. Esto permite que las personas se concentren en un solo problema a la vez, ayudándolos en las etapas finales.

4. El producto se construye en colaboración.
   En lugar de que las partes interesadas definan soluciones específicas, dejamos que los equipos de ingeniería, diseño y otros se comprometan con la solución y los hagamos parte de ella.

Notas finales

Cerrando la historia sobre esta empresa remota, pude trabajar allí durante algunos meses más y pude implementar los documentos de diseño de productos al menos en 5 proyectos diferentes. Mi frustración se redujo mucho y pude llegar a un consenso sobre mis propuestas de diseño para que el producto siguiera evolucionando. Desde entonces, la empresa ha crecido mucho y parte del trabajo que hice durante mi tiempo todavía se está utilizando.

PD: Empecé a escribir este artículo en 2019, luego en 2021 vi que Abstract estaba creando un producto para documentar el proceso de diseño, así que decidí retomar el rumbo y terminarlo. Parece que sigue siendo un tema bastante relevante.

Bibliografía

• Cómo ejecutar ejercicios de diseño en un equipo remoto por Hannah Hearth
• Evite el efecto gaviota: el marco 30/60/90 para la retroalimentación por Lauren Moon
• ¿Cómo se diseña un documento de diseño? por John Saito
• El poder del documento de diseño de Brendan Fagan
• Presentamos los cuadernos de Matt Colyer