Plantillas de prompts para diseñadores: una estructura reutilizable

¿Qué es una plantilla y en qué se diferencia de un prompt suelto?

Un prompt suelto es lo que escribes en el momento: “revísame esta pantalla”. Una plantilla es la versión que guardas y reutilizas: la misma estructura, con huecos para lo que cambia en cada caso. La diferencia no es de tamaño. Es que la plantilla ya contiene las preguntas que tú te harías si tuvieras tiempo.

Es una forma concreta de aplicar la disciplina de prompt engineering sin convertirla en un oficio aparte. Cada hueco que llenas es una decisión que antes se quedaba implícita.

¿Qué partes debe tener?

Una plantilla útil para diseño suele tener seis bloques:

1. Rol. Quién es el modelo en esta tarea: “Actúa como revisor de accesibilidad con foco en formularios”.
2. Contexto. Qué producto es, para quién y en qué momento del flujo estamos.
3. Tarea. Qué debe producir, en una frase con verbo claro.
4. Insumos. Qué material se adjunta: la pantalla, el sistema de componentes, la guía de tono.
5. Restricciones. Qué no debe hacer: inventar datos, usar colores fuera de los tokens, cambiar textos legales.
6. Formato de salida. Cómo lo entrega: tabla, lista de hallazgos con severidad, JSON, o un borrador en Markdown.

El orden importa poco. Lo que importa es que ninguno falte, sobre todo las restricciones y el formato, que son lo que más se olvida.

Las restricciones suelen acabar en el system prompt de una aplicación, así que escríbelas con cuidado.

¿Cómo se escribe cada bloque?

Algunas reglas que funcionan en la práctica:

• Sé explícito. “Lista cada problema de contraste con su nivel WCAG” funciona mejor que “revisa accesibilidad”.
• Explica el motivo de las reglas. “No uses rojo para éxito, porque el sistema lo reserva para errores” da al modelo un criterio para casos que no previste.
• Separa secciones con etiquetas. Envolver los insumos en etiquetas como <pantalla> o <reglas> evita que el modelo mezcle instrucciones y material. La guía de mejores prácticas de Anthropic cubre esta estructuración con etiquetas XML.
• Pide el formato que vas a usar. Si el resultado entra a un documento de research, pide tabla con columnas fijas.
• Pon ejemplos cuando el formato sea raro. Un ejemplo de hallazgo bien escrito vale más que tres párrafos de descripción. Esto se conoce como few-shot prompting.

¿Cómo pruebas una plantilla antes de compartirla?

Una plantilla no se valida porque suene bien. La documentación de Anthropic recomienda tener antes criterios de éxito claros y una forma de probarlos. Nielsen Norman Group, al comparar herramientas de diseño con IA, volvió a correr el mismo prompt en chats nuevos para obtener variantes y comparó los resultados con diseños hechos por sus diseñadores sin IA. Aplicado a una plantilla, el método es este:

1. Elige tres o cuatro casos que ya resolviste a mano.
2. Corre la plantilla en cada uno y guarda el resultado.
3. Compara con tu propia respuesta: qué encontró que tú no, qué inventó, qué omitió.
4. Ajusta la plantilla, no el caso. Si la IA se equivoca de la misma forma dos veces, falta una restricción.
5. Cuando sea estable en los casos de prueba, compártela con el equipo y anota la versión.

Este paso se parece a un eval simple, y es la forma más barata de tener uno.

¿Cuándo NO conviene una plantilla?

• Cuando la tarea cambia cada vez y el valor está en explorar, no en repetir. Forzar una plantilla rígida puede esconder ideas nuevas.
• Cuando el contexto es tan específico que la plantilla tiene más huecos que texto fijo. En ese caso es mejor un documento de contexto que una plantilla.
• Cuando el resultado es sensible (datos de pacientes, decisiones legales) y la plantilla no incluye una revisión humana explícita.

Ejemplo

Ejemplo ilustrativo: un equipo de research quiere que la IA resuma notas de entrevistas. La primera versión, “resume estas notas”, devuelve párrafos largos con citas inventadas. La plantilla nueva tiene rol (investigadora de UX), contexto (producto y objetivo de la entrevista), tarea (extraer hallazgos con su evidencia), insumos (las transcripciones entre etiquetas), restricciones (“cada hallazgo debe citar una frase textual de la transcripción; si no hay evidencia, escribe sin evidencia”) y formato (tabla con hallazgo, cita, participante). Tras probarla con cuatro entrevistas, las citas inventadas desaparecen y el equipo la guarda como versión 1.1.

¿Cómo se versiona una plantilla?

Una plantilla es código de trabajo, aunque no lo parezca. Cuando cambia, cambia el resultado, y ese cambio debe poder rastrearse. Guárdala en un lugar con historial, como el repositorio del equipo o un documento versionado, con un número de versión en la primera línea y una nota sobre qué cambió y por qué. Así, si una revisión de hace un mes salió distinta, puedes comparar con la versión que la produjo. Evita tener tres copias en distintos chats y con distintas personas: con el tiempo, nadie sabe cuál es la vigente. Un solo lugar y un dueño claro resuelven esa confusión.

Errores comunes

• Guardar una plantilla sin probarla en casos reales.
• Olvidar las restricciones, que son el bloque que más evita errores.
• Copiar plantillas de internet sin adaptar el contexto al producto.
• Cambiar la plantilla cada semana sin anotar versiones. Nadie sabe qué resultado salió de cuál.
• Pedir un formato que la herramienta no puede entregar.

Fuentes

• Prompt engineering overview, documentación de Claude (criterios de éxito y pruebas antes de optimizar un prompt)
• Prompting best practices, documentación de Claude (claridad, contexto, ejemplos, etiquetas XML y roles)
• Testing AI design tools: methodology, Nielsen Norman Group (repetir prompts en chats nuevos y comparar con diseño humano)