Jira para diseñadores sin sufrir: tipos de issue, backlog y Figma

¿Qué es Jira y por qué le importa a diseño?

Jira organiza el trabajo en elementos de trabajo, tableros y backlogs. Atlassian anunció en noviembre de 2024 que dejaría de llamarlos issues: en menús y ayuda son work items, y el tipo (historia, bug, etc.) es el work type. En este artículo uso issue porque sigue siendo la palabra de muchos equipos, y es lo mismo. En muchos equipos de producto, es el sitio donde desarrollo sigue lo que tiene que construir. Si el diseño no está en ese sistema, las pantallas llegan a desarrollo por otros canales: un enlace en un chat, una captura en un correo, un archivo que nadie sabe si es el último.

Por eso el objetivo del diseñador no es dominar Jira, sino conseguir que lo que se diseña tenga un issue, un estado y un enlace al archivo correcto.

¿Por qué le importa a un diseñador junior?

Porque el tablero de Jira suele ser la primera forma en que un junior ve cómo trabaja el equipo de producto. Entender los tipos de trabajo, los estados y el backlog te permite proponer un flujo de diseño que no genere ruido. Y saber qué no mandar a Jira también es parte del trabajo.

Además, muchos conflictos entre diseño y desarrollo vienen de estados mal definidos. Si “listo” significa cosas distintas para cada persona, el ticket se devuelve una y otra vez.

¿Qué tipos de issue usar?

Atlassian explica que un work item puede representar una historia, un bug, una tarea u otro tipo de trabajo, y que quien administra el espacio puede crear tipos nuevos. Hack Design, una guía de diseño de un tercero, describe la jerarquía habitual: los Epics contienen Stories, Tasks y Bugs. Una Story es una funcionalidad vista desde el usuario y un Epic, una funcionalidad grande hecha de varias historias. Para diseño sugiere tipos propios como «Design Task» o «Design Spike», este último una exploración con tiempo limitado que entrega decisiones, no trabajo terminado. Es una recomendación de un tercero, no una norma de Atlassian.

Una regla práctica: un tipo de issue debe servir para tomar una decisión. Si el equipo no sabe qué hace distinto un “Design Task” de una “Story”, el tipo sobra.

¿Cómo funcionan el backlog y los estados?

Según la ayuda de Atlassian, hay dos tipos de backlog. El backlog Scrum muestra el trabajo del espacio agrupado en backlog y sprints; se prioriza arrastrando cada elemento y se mueve a un sprint arrastrándolo allí. El backlog Kanban tiene dos secciones, Backlog y Selected for Development, y mantiene la planificación fuera del camino del equipo para que el tablero muestre solo el trabajo en curso. Un administrador debe activarlo en cada tablero.

Los estados describen el lugar de un elemento en el flujo de trabajo, y las columnas del tablero se asignan a ellos. Por defecto, las columnas de un tablero Scrum son To Do, In Progress y Done, y las de uno Kanban, Backlog, Selected for Development, In Progress y Done. Jira solo considera completado lo que está en la columna de más a la derecha, así que un estado como «Cancelado» debe asignarse ahí o impedirá cerrar el sprint. Hack Design propone para diseño To Do, In Progress, Review y Done. Es un ejemplo, no un valor por defecto. Lo importante es que cada estado tenga un significado compartido. Un estado «Review» que no dice quién revisa ni qué se revisa no sirve para nada.

El paso a desarrollo es el punto más delicado. Un estado como “Ready for development” debería significar que el diseño está aprobado, que las pantallas están enlazadas y que los casos de error están documentados.

¿Cómo se conecta con Figma?

Según la ayuda de Figma, la integración se instala con la app Figma for Jira y requiere una cuenta de Jira Software, además de permiso para ver el archivo vinculado. Permite vincular archivos o prototipos a un work item y previsualizar el diseño sin salir de Jira. En el work item aparece «Design updated» cuando el archivo vinculado cambió desde la última vez que lo viste, y «Ready for dev» refleja el estado de Dev Mode del archivo en Figma. El plugin de Jira en Figma permite vincular work items existentes a páginas o capas y crear work items nuevos desde Figma.

La ayuda de Figma indica también que no se pueden añadir embeds en Jira Align ni en Jira Service Desk con esta integración (así llama a ese producto). Si tu equipo usa esas herramientas, compruébalo antes de planificar el flujo. La ayuda no menciona requisitos de plan. Jira tiene planes Free, Standard, Premium y Enterprise; sus precios y límites se consultan en la página de precios de Atlassian.

¿Cuándo NO conviene Jira para diseño?

• Cuando desarrollo no usa Jira. No tiene sentido llevar el diseño a un tablero que nadie mira. Conviene usar la herramienta que use el equipo de dev.
• Cuando el trabajo de diseño es exploratorio. Un espacio libre, como FigJam o Miro, suele ser mejor para pensar antes de convertir algo en un ticket.
• Cuando solo hay que registrar una petición puntual. Abrir un issue para cada cambio pequeño satura el tablero y no aporta nada.

Hack Design recomienda hacer el pensamiento de diseño en Figma, Notion o un cuaderno, no vivir en Jira, agrupar las actualizaciones y pasar el trabajo a Jira cuando está listo para desarrollo. Es una opinión de un tercero, pero coincide con la idea de tener una sola fuente de verdad para cada decisión.

Ejemplo

Ejemplo ilustrativo: un equipo de producto usa Jira con un backlog Scrum. Un diseñador junior quiere llevar el rediseño de la pantalla de facturas.

• Work items: una Epic «Rediseño de facturación» con cinco Stories, una por flujo.
• Estados: To Do, In Progress, Review, Ready for development, Done. “Ready for development” exige un enlace a Figma y una lista de casos de error.
• Vínculo: cada Story enlaza al frame correspondiente de Figma. Cuando el archivo cambia, Jira muestra el aviso «Design updated».
• Problema detectado: una Story pasó a desarrollo sin los casos de error. Se añade a la definición de “Ready for development” una comprobación explícita.

El cambio fue pequeño: una frase en la definición del estado. Pero evitó que desarrollo construyera sin la mitad de la información.

Para la parte de entrega de diseño, el artículo sobre design handoff describe qué debe llegar al desarrollo, y el de gestionar proyectos cómo se organiza el trabajo en el tiempo.

Si tu equipo ya usa agentes de IA sobre el tablero, el artículo sobre handoff en la era de la IA trata qué cambia en esa entrega.

Errores comunes

• Crear tipos de issue que nadie sabe distinguir.
• Definir estados sin acordar qué significa cada uno.
• Mandar a Jira decisiones de diseño que deberían vivir en Figma.
• Abrir un issue por cada cambio pequeño.
• Mover un issue a desarrollo sin enlace al diseño ni casos de error.
• Planificar la integración con Figma sin comprobar qué productos de Jira usa la empresa (Software, Align o Service Desk).

Fuentes

• Atlassian, ‘Work,’ your way: Jira’s language is evolving to better represent all teams (13 de noviembre de 2024)
• Atlassian, Use your scrum backlog
• Atlassian, Use your kanban backlog
• Atlassian, Configure columns
• Atlassian, Work items en Jira Software
• Atlassian, Jira pricing
• Figma, Jira integration (ayuda de Figma)
• Hack Design, Jira (guía de un tercero)