El Gerente de Producto es a menudo descrito como el «puente entre el negocio, diseño y tecnología». El puente» entre el diseño y la tecnología » es especialmente crítico cuando se trata de enviar un producto de calidad: libre de errores, perfecto para píxeles y que tenga en cuenta todos los escenarios y estuches de borde posibles. Para asegurarse de que bridge funciona bien, el equipo de diseño lo maneja de varias maneras:

• El diseñador envía un prototipo completo, que muestra todos los flujos del producto. Desafortunadamente, esto a menudo tomará mucho tiempo y aún perderá algunos casos extremos.
• El diseñador solo enviará un prototipo que muestre los flujos principales de la función y que permanezca disponible para preguntas del equipo de desarrollo. Desafortunadamente, estos cambios de ida y vuelta son altamente ineficientes (especialmente en una configuración remota) y pierden mucho tiempo tanto del equipo de diseño como del de desarrollo.
• El diseñador, además del prototipo completo, escribe un documento de especificaciones adecuado que enumera todos los posibles escenarios y estuches de borde. El problema es que a menudo es una pérdida de tiempo, porque (1) el valioso tiempo de los diseñadores se gastará mejor diseñando otras características, no escribiendo un documento de especificaciones, y (2) no siempre tienen la misma vista de 360° del producto que los gerentes de producto, lo que hará que pasen por alto algunos escenarios y casos de borde.

Es por eso que los equipos de productos maduros generalmente confían la escritura de sus especificaciones de producto a los gerentes de producto.

Pero, ¿cómo debe escribir las especificaciones del producto? He escrito especificaciones de productos durante los últimos 5 años y encontré un formato que es muy apreciado por los equipos de software con los que trabajo. En esta publicación, comparto más sobre mi metodología y las herramientas que estoy usando para escribir especificaciones de productos. También estoy describiendo algunas limitaciones que estoy enfrentando con las herramientas que estoy usando y algunas ideas de mejora que tengo en mente.

Aquí están los 5 temas principales que abordo en una especificación de producto:

1. Contexto y objetivos
2. Mapa de arquitectura
3. Epopeyas e historias de usuario
4. Criterios de aceptación
5. Diseño, contenido y traducciones

Contexto y objetivos

Incluso si la especificación del producto está dirigida principalmente a equipos de software, todavía les gusta saber por qué están trabajando en lo que están trabajando. He llegado a entender que uno de los principales impulsores de motivación para los ingenieros de software es el impacto. La mayoría de ellos sueñan con trabajar en funciones que son utilizadas por millones de usuarios. Se emocionan cuando se enteran de que la nueva experiencia de usuario que han implementado ha aumentado la retención en un 15%, por ejemplo. Por lo tanto, es importante dar contexto sobre la función que implementarán:

• ¿De qué estamos hablando? ¿Qué parte del producto? Siéntase libre de agregar cualquier historial de la función que sea útil para comprender la situación actual.
• ¿Cuál es el problema actual? Nota: Puede haber varios problemas que resolver.
• ¿Hay comentarios / verbatimas cualitativos de los usuarios para citar?
• ¿Hay algún dato (por ejemplo, gráficos) que mostrar? En esta sección, siéntase libre de incluir cualquier tabla o gráfico que haga que los datos sean más comprensibles.
• ¿Cuál es la solución elegida? (descríbalo simplemente, en unas pocas frases)
• ¿Se ha considerado alguna otra solución? En caso afirmativo, ¿por qué se ha dejado de lado?
• ¿Ya se ha implementado alguna otra solución? ¿Cómo ha estado funcionando?
• ¿cuáles son los objetivos ? ¿Hay algún KPI que estemos tratando de impactar? Esto ayudará especialmente al equipo de software a comprender si necesitan implementar nuevos rastreadores / etiquetas / eventos para recopilar los datos correctamente. He visto a los equipos sentirse tan impulsados por el proyecto que tomaron la iniciativa de configurar paneles para seguir las métricas en tiempo real, sin que yo ni nadie lo pidiera.

Mapa de arquitectura

Antes de entrar demasiado en los detalles de la función, es importante dar una visión general de alto nivel de lo que cambia y lo que permanece igual en su producto. E incluso si está trabajando en un producto completamente nuevo, un mapa de arquitectura seguirá siendo extremadamente relevante para comprender cómo está estructurado el producto.

«Mapa de arquitectura» es la forma en que llamo a un diagrama de alto nivel representación de las características del producto (flujos, pantallas y contenido) y cómo se relacionan entre sí. Algunas personas lo llaman «Arquitectura de la información», «Mapa de flujo», «Mapeo de experiencia de usuario», etc.

no Hay ninguna metodología oficial de cómo dibujar una arquitectura de mapa. En una aplicación móvil, por lo general trato de diferenciar flujos, pantallas y «partes de una pantalla» (o «contenido en la página»), utilizando una forma diferente para cada uno de ellos, como se detalla en la leyenda anterior.

También puede ser útil reproducir el código de color. En el ejemplo anterior, utilicé 3 colores y también líneas sólidas vs. punteadas para explicar cómo se actualizaría la arquitectura de información actual con la renovación de UX de la aplicación en la que estábamos trabajando. (verde: permanecerá como está, naranja: se actualizará, rojo: se eliminará; sólido: permanecerá en el mismo lugar, punteado:se moverá a otro lugar). De esa manera, los ingenieros tenían una visión clara a vista de pájaro sobre qué parte de la aplicación estaría sujeta a cambios.

Otro consejo para construir un mapa de arquitectura comprensible es distinguir claramente las diversas partes de la navegación, como se hace a continuación con áreas separadas para cada una de ellas.

Tener una arquitectura mapa será muy útil para tu especificaciones de producto; te permitirá resaltar de qué parte del producto estás hablando en cada una de tus historias de usuario.

¿Qué herramienta debe usar para dibujar un mapa de arquitectura? Hay un montón de ellos disponibles por ahí, mi favorito es Caprichoso (porque es visualmente agradable y muy sencillo, no lleno de tantas características), pero también utilicé Draw.io en el pasado, lo cual es interesante porque está integrado con Google Drive, por lo que si trabajas con Google Slides y Google Docs, es agradable de usar. También está integrado con JIRA y Confluence.

Si quieres aprender más sobre mapas de arquitectura (qué hacer y qué no hacer, qué herramientas usar, algunos ejemplos, etc.), a Toptal se le ha ocurrido una gran lectura: La Guía Completa de Arquitectura de la Información.

Epopeyas e historias de usuario

Desglosar y explicar todas las partes de su producto puede volverse muy caótico rápidamente. Durante los últimos 5 años, la mejor manera que he encontrado para mantener las especificaciones organizadas y comprensibles es desglosarlas de acuerdo con las «historias de usuario».

¿Qué es una historia de usuario? De acuerdo con el Modelado ágil, una historia de usuario es «una definición de muy alto nivel de un requisito, que contiene la información suficiente para que los desarrolladores puedan producir una estimación razonable del esfuerzo para implementarla.»

La idea de las historias de usuario es poner a los usuarios en primer lugar y evitar el uso exclusivo de vocabulario técnico oscuro & cuando se discuten características. Como dice Atlassian: «Después de leer una historia de usuario, el equipo sabe por qué está construyendo lo que está construyendo y qué valor crea.»

Están dirigidos a construir un mejor producto donde el usuario está en el centro de los debates, contrariamente al buen desarrollo de productos de cascada.

he Aquí cómo una historia de usuario debe ser formulada:

Como < tipo de usuario >, Quiero < algún objetivo > para que < alguna razón >.

Por ejemplo, he aquí cómo podríamos formular historias de usuario para los siguientes subparte de la arquitectura de mapa que dibujó para uno de mis clientes:

• la Historia de Usuario #1: Como empleado en la sección de perfil, quiero editar mi perfil, así que puedo actualizar mi foto, nombre y apellido.
• Historia de usuario # 2: Como empleado en la sección perfil, quiero acceder a la configuración para poder actualizar mi contraseña y las preferencias de notificación.
• Historia de usuario #3: Como empleado en la sección de perfil, quiero acceder al chat para poder dar comentarios a los desarrolladores de la aplicación

Depende del gerente de producto decidir qué nivel de detalles desea cubrir en la historia de usuario. Si quisiéramos, también podríamos profundizar un nivel en la Historia de usuario # 2, por ejemplo:

• Historia de usuario # 2.a: Como empleado en la configuración, quiero acceder a la sección» editar contraseña » para poder actualizar mi contraseña
• Historia de usuario #2.b: Como empleado en la configuración, quiero acceder a las preferencias de notificaciones para poder actualizar la frecuencia con la que recibo cada tipo de notificaciones

, pero como puede ver, esto es algo obvio y redundante. Personalmente elegí cubrir estos escenarios en los «criterios de aceptación» (ver sección siguiente) de las historias en cuestión.

Para organizar historias de usuarios, a menudo usamos «epopeyas». En términos ágiles, las» epopeyas » son grandes cantidades de trabajo que se pueden dividir en historias de usuarios más pequeñas. Yo personalmente uso epopeyas para agrupar historias que son parte del mismo tema o área en el producto. Por ejemplo, he elegido agrupar las historias anteriores como parte de la épica» Perfil». Algunas personas optan por formular épicas de la misma manera que las historias de usuario, con una estructura más simple (p. ej. «Como usuario, quiero acceder a mi perfil»)

Criterios de aceptación

Para asegurarnos de que se agrega suficiente detalle a una historia de usuario, utilizamos «criterios de aceptación» (a veces también llamados «condiciones de satisfacción»).

Según LeadingAgile.com, «criterios de aceptación» son » las condiciones que un producto de software debe satisfacer para ser aceptado por un usuario, cliente o, en el caso de la funcionalidad a nivel de sistema, el sistema consumidor.»

En los criterios de aceptación, debe enumerar todas las especificidades funcionales que no se detallan claramente en la historia del usuario. Ejemplo:

la Historia de Usuario

Como empleado en la sección de perfil, quiero editar mi perfil, así que puedo actualizar mi foto, nombre y apellido.

Criterios de aceptación

• Dado que estoy en la pantalla de editar perfil Cuando hago clic en el icono de editar nombre, debería cambiar al modo de edición, centrarse en la entrada y abrir el teclado (lo mismo para el apellido)
• Dado que estoy en la pantalla de editar perfil Cuando hago clic en el icono de editar foto, debería pedirme que elija entre cámara y biblioteca
• Dado que estoy editando mi nombre Cuando hago clic en «guardar», debería redirigirme al modo de lectura y Debería ver una notificación de éxito

etc

Piense en los criterios de aceptación como un lista de verificación que deberá completarse para que se envíe el producto. El formato dado/Cuándo/Entonces utilizado anteriormente es una buena manera de ayudarlo a formular sus criterios de aceptación, pero en algunos casos puede ser difícil de usar.

Diseño, contenido y traducciones

Tener diseños actualizados en las especificaciones de sus productos

Hasta ahora, no he mencionado qué herramienta estoy utilizando para escribir especificaciones. En el pasado, he cambiado entre Google Docs, Google Slides y Notion. Realmente disfruté usando Notion para todas las integraciones geniales que ofrece (especialmente las que tienen InVision y Figma). Pero ahora he cambiado completamente a Google Docs: prefiero tener más libertad en la forma en que formateo las especificaciones de mis productos. También es más conveniente usar productos de Google cuando trabajas con socios o clientes externos.

Para asegurarse de que la identidad visual de su producto sea realzada con precisión por el equipo de desarrollo, es importante darles acceso a las pantallas más actualizadas enviadas por su diseñador(s). Pero como no hay una integración real entre Google Docs y herramientas de diseño como Figma, InVision o Zeplin, solía exportar pantallas y copiarlas/pegarlas en las especificaciones de mis productos.

Esto se convertiría rápidamente en un problema: los diseñadores repiten en sus pantallas a diario, e incluso cuando todo se ha acordado en una pantalla, puede cambiar unas semanas más tarde debido a que se actualiza un componente específico en la biblioteca de diseño. Esto causaría que mis especificaciones estuvieran desactualizadas la mayor parte del tiempo.

Es por eso que hoy solo estoy usando el nombre de las pantallas. Por ejemplo, si una historia de usuario sobre profile edition es de aproximadamente 2 pantallas que se han diseñado en Figma, solo escribiré «Nombre de pantalla Figma: editar-perfil – 1 y editar-perfil-2».

Por supuesto, esto no es ideal y obliga a los desarrolladores o a cualquier otra persona que lea mis especificaciones a cambiar entre varias herramientas.

Pero esto muestra que hoy en día hay algo ineficiente en la forma en que escribimos las especificaciones de los productos. El uso de varios productos plantea cuestiones de integración y sincronización. ¿Cómo garantizar que toda la información necesaria para construir un producto sea visible en un solo lugar, sin estar desactualizada? (En realidad, esto no solo se aplica a los diseños, sino también a los mapas de arquitectura y el contenido).

→ Si usted está experimentando este problema y ha encontrado una solución, me interesaría conocer tu opinión!

Dar fácil acceso al contenido y las traducciones para evitar errores tipográficos

Cuando diseñas pantallas con una gran cantidad de contenido, es bueno dar a los desarrolladores la oportunidad de copiarlo / pegarlo fácilmente en lugar de tener que volver a escribirlo ellos mismos. De lo contrario, podría terminar con (1) muchos errores tipográficos y (2) desarrolladores enojados. Hay varias formas de darles acceso al contenido:

• Dándoles acceso a los archivos fuente del trabajo de diseño en Sketch, Figma o Zeplin, por ejemplo.
• Copiando / pegando el contenido directamente en la especificación (puede hacerlo un poco desordenado).

Si su producto existe en varios idiomas, también dé acceso a cada traducción. Por ejemplo, puede usar una matriz para mostrar la traducción de su contenido original en cada idioma. El siguiente nivel de gestión de traducciones es usar una herramienta de localización (como Frase) y agregar solo las «claves de traducción» en las especificaciones de su producto. Pero de nuevo, esto implica un ir y venir más entre las especificaciones de su producto y otra herramienta.