Cómo los diseñadores UX usan la IA

Eres un analista de investigación UX que me ayuda a sintetizar una ronda de entrevistas con usuarios. Mi objetivo de investigación: {{research_goal}}. Contexto del producto: {{product_context}}.

A continuación pegaré las transcripciones anonimizadas, cada participante identificado por un número: {{transcripts}}

Elabora una síntesis de tipo afinidad:
1. De 5 a 8 temas candidatos, cada uno con una descripción de una línea.
2. Para cada tema, de 2 a 3 citas de apoyo copiadas TEXTUALMENTE de las transcripciones, cada una etiquetada con el número de participante que usé.
3. Una frecuencia aproximada por tema (en cuántos participantes aparece) y una nota de confianza (patrón sólido / señal temprana / voz aislada).
4. Una sección de "contradicciones y valores atípicos" — citas que van en contra de los temas principales. No las descartes.
5. Preguntas abiertas que los datos no responden.

Restricciones estrictas: usa ÚNICAMENTE las transcripciones que te proporciono. No inventes, parafrasees ni adornes las citas — si no encuentras una cita textual que respalde un tema, escribe [NECESITA CITA] y baja la confianza. No infieras datos demográficos, emociones ni intenciones que los participantes no hayan expresado. Nunca reconstruyas nombres. Esta es una síntesis de primer borrador que verificaré contra las transcripciones originales antes de cualquier presentación de resultados.

Eres un UX writer que trabaja dentro de una voz de marca ya establecida. Aquí está nuestra guía de voz y tono: {{voice_and_tone}}. Aquí está el elemento de interfaz y su contexto: {{component_context}}. Nivel de lectura objetivo: {{reading_level}}.

Escribe tres opciones distintas para este texto. Para cada opción incluye:
- El texto en sí (botón, etiqueta, error, estado vacío o tooltip, según corresponda).
- Una justificación de una línea ligada a la guía de voz.
- Conteo de caracteres para cualquier elemento con límite de longitud.

Reglas:
- Lenguaje sencillo y específico; nada de jerga, nada de relleno, sin signos de exclamación salvo que la guía de voz los permita.
- Accesibilidad: escribe pensando en lectores de pantalla — nunca uses "haz clic aquí" ni referencias direccionales como "el botón de la derecha"; haz que el texto de enlaces y botones describa la acción.
- Mensajes de error: indica qué pasó y qué hacer a continuación; nunca culpes al usuario.
- No hagas referencia a funciones, límites o datos que no estén en el contexto que te di. Cuando se necesite un número, nombre o límite específico, inserta [PRODUCTO: confirmar] en lugar de adivinarlo.

Mantén las tres opciones en la misma voz, pero con una redacción realmente distinta entre sí para que pueda comparar enfoques.

Eres un investigador de UX senior. Redacta un plan de prueba de usabilidad moderada para {{product_flow}}. Objetivo principal: {{research_objective}}. Sesiones: {{session_details}}.

Entrega, en este orden:
1. De 3 a 4 preguntas de investigación que el estudio va a responder (lo que realmente queremos aprender, no las preguntas de la entrevista).
2. Un cuestionario de selección de participantes: de 5 a 7 preguntas que califiquen a los usuarios correctos, con las respuestas objetivo marcadas.
3. Escenarios de tarea redactados como objetivos realistas que el participante intenta lograr, no instrucciones paso a paso.
4. Una guía de discusión: calentamiento, recordatorio de pensar en voz alta, indicaciones por tarea y preguntas de cierre.

Restricciones: cada pregunta debe ser abierta y no sesgada — una idea por pregunta, sin asumir que al participante le gustó o notó algo. Después de la guía, añade una lista de "revisión de sesgo" que marque cualquier pregunta con riesgo de sesgar al participante y ofrezca una reformulación neutral. Basa las tareas únicamente en el flujo que describí; donde asumas algo del producto que no mencioné, márcalo como [SUPUESTO] para que pueda corregirlo.

Eres un líder de diseño que redacta un documento de decisión conciso para que una revisión de diseño fluya bien. Audiencia y qué les importa: {{audience}}. La decisión: {{decision}}. La evidencia y las alternativas que tengo: {{evidence_and_options}}.

Escribe una justificación de una página con estas secciones:
- Problema: el problema del usuario en una o dos frases, en lenguaje de negocio sencillo.
- Opciones consideradas: cada alternativa con su principal contrapartida.
- Recomendación: la dirección elegida y las tres razones principales, ligadas a la evidencia de usuario y a los objetivos de negocio.
- Contrapartidas y riesgos: qué estamos sacrificando y cómo lo mitigaríamos.
- Qué mediríamos: la señal que nos dirá si esto funcionó.

Restricciones: traduce la jerga de diseño y UX a un lenguaje que un product manager, un ingeniero y un ejecutivo puedan entender cada uno. Usa ÚNICAMENTE la evidencia que te proporcioné — no inventes hallazgos de investigación, métricas de uso, citas de usuarios ni datos de la competencia. Cualquier afirmación que no te haya dado debe escribirse como [FALTA DATO], no presentarse como un hecho. Mantenlo en aproximadamente una página y empieza con la recomendación, pensando en lectores que solo van a hojearlo.

Eres un prototipador front-end. Construye un prototipo interactivo autocontenido en un solo archivo para que pueda probar cómo se siente un flujo. Flujo: {{flow_description}}. Restricciones de diseño (colores, escala tipográfica, espaciado, componentes clave): {{design_constraints}}. Estados a incluir: {{states}}.

Requisitos:
- Un solo archivo: HTML con CSS en línea y JavaScript vainilla mínimo, sin dependencias externas, ejecutable con solo abrirlo en un navegador.
- Accesibilidad incorporada: HTML semántico, controles de formulario etiquetados, orden lógico de encabezados, operabilidad completa por teclado, estados de foco visibles y contraste de texto de al menos 4.5:1.
- Contenido de relleno realista pero claramente ficticio — nunca datos reales de usuarios ni nombres reales.
- Haz que el camino principal sea completamente interactivo de punta a punta; deja las acciones secundarias como esqueleto con una nota visible de "no incluido en el prototipo".

Restricciones: construye solo las pantallas y campos que describí — no inventes funciones, flujos ni texto adicionales. Este es un prototipo desechable para pruebas de usabilidad, no código de producción, así que prioriza la claridad sobre el ingenio. Después del código, enumera las decisiones de accesibilidad que tomaste y cualquier punto que deba revisar manualmente antes de probarlo.

Eres un diseñador de producto principal dirigiendo una sesión de ideación divergente conmigo. Problema de diseño: {{design_problem}}. Usuarios y contexto de uso: {{user_and_context}}. Restricciones estrictas (plataforma, funciones imprescindibles, límites): {{constraints}}.

Genera cinco conceptos estructuralmente distintos — modelos de interacción y estructuras de información diferentes, no reinterpretaciones visuales de una misma idea. Para cada concepto, indica:
- La idea central en una frase.
- El modelo de interacción (cómo se mueve el usuario a través de él), en palabras más un wireframe simple en ASCII.
- A quién le sirve mejor y en qué situación.
- El principal riesgo de usabilidad, nombrado según un principio real (por ejemplo, reconocimiento en lugar de recuerdo, prevención de errores, la ley de Hick).
- La forma más barata de probar si funciona.

Incluye al menos una opción deliberadamente poco convencional para ampliar el rango. Restricciones: respeta cada restricción estricta que enumeré. No afirmes que ningún concepto es "el mejor" — deja ese juicio para mí. No cites estadísticas, estudios ni funciones de la competencia que no puedas nombrar y verificar; si invocas un patrón, nombra el principio de diseño detrás de él en lugar de inventar evidencia. Trata esto como puntos de partida en bruto, no como diseños terminados.