Interfaces de IA para quienes no redactan prompts

En este contexto de diseño, un prompt es la instrucción y el contexto que se proporcionan a un modelo de IA. Tratar ese material como la interfaz principal concentra varias decisiones de diseño en un único cuadro de texto: qué información importa, cómo debe formularse la solicitud, qué restricciones se aplican y qué forma debe adoptar el resultado. Esa flexibilidad puede ser adecuada para algunas tareas, pero sigue siendo una decisión de producto y no una opción predeterminada neutral.

Una alternativa consiste en diseñar la interacción en torno al trabajo en sí. El producto puede recopilar el material relevante, mostrar opciones significativas y devolver un resultado preparado para un siguiente paso concreto. Esto no elimina la creación del prompt. Traslada esa creación a un sistema que los diseñadores pueden inspeccionar, probar y revisar.

Empieza por la tarea, no por el prompt

Empieza describiendo el trabajo con términos que no dependan de un modelo. Identifica el material de origen, la decisión que debe respaldarse, la persona responsable de la revisión y la acción posterior. Una solicitud general de ayuda con un documento deja sin resolver muchas decisiones de la interfaz. Una tarea centrada en extraer preguntas pendientes para su revisión proporciona al producto unos límites más claros.

La interfaz debe representar las opciones que cambian de forma sustancial el resultado. Evita pedir información solo porque podría resultar útil. Cada campo, selección y valor predeterminado debe estar relacionado con una regla de salida o una condición de implementación que el equipo haya verificado.

• Define el material de origen y sus límites.
• Indica la decisión prevista o la siguiente acción.
• Identifica las restricciones que podrían cambiar qué resultado es aceptable.
• Especifica quién revisa el resultado antes de utilizarlo.

Convierte el contexto en entradas estructuradas

Una entrada estructurada es información recopilada mediante campos con nombre, opciones seleccionadas o material adjunto, en lugar de reunirse por completo en un texto de formato libre. La estructura puede aclarar la tarea cuando sus categorías se corresponden con el trabajo previsto. Un formulario rígido que omita una excepción importante puede ser menos útil que un formulario pequeño con un campo opcional para notas.

Separa los hechos proporcionados de las instrucciones y las preferencias. Esta distinción puede ayudar a conservar la procedencia, es decir, el lugar del que vino la información, al tiempo que mantiene las decisiones de formato separadas del contenido de origen. El prompt interno puede combinar estas partes, pero la interfaz visible debe permitir que una persona responsable de la revisión comprenda qué entró en el proceso.

1. Recopila el material de origen mínimo necesario para la tarea.
2. Solicita las restricciones mediante opciones con consecuencias claras.
3. Proporciona ejemplos solo cuando aclaren la entrada esperada.
4. Conserva el contexto opcional sin otorgarle autoridad de forma inadvertida.
5. Muestra qué se procesará antes de que comience el procesamiento.

Haz visibles las decisiones del sistema

Si el producto crea una instrucción detrás de la interfaz, también toma decisiones editoriales. Puede seleccionar contexto, asignar etiquetas, solicitar un formato o excluir material. El equipo debe documentar esas decisiones como parte de la función, incluso cuando la instrucción interna completa no aparezca en la interfaz principal.

Una visibilidad útil no exige mostrar todos los detalles técnicos. Implica mostrar las condiciones que afectan a la tarea, incluidas las fuentes seleccionadas, las restricciones activas, el tipo de resultado y las exclusiones. Si cambia un modelo o método de procesamiento, el equipo debe verificar si ese cambio afecta a estas condiciones antes de considerarlo un mero detalle interno de implementación.

En la interfaz, muestra las fuentes seleccionadas y el material omitido, resume las restricciones activas con un lenguaje corriente, diferencia los valores predeterminados del producto de las selecciones explícitas y permite revisar las decisiones automáticas que tienen consecuencias. Cada elemento debe estar relacionado con una condición que pueda cambiar el resultado o la revisión necesaria.

Da forma a los resultados para revisarlos y reutilizarlos

La respuesta de un modelo no debe convertirse automáticamente en el artefacto final del producto. Diseña el resultado en función de cómo se comprobará, editará, copiará, comparará o aprobará. Una respuesta conversacional puede ser apropiada para una tarea exploratoria, mientras que una tarea de revisión puede requerir hallazgos etiquetados y vinculados al material proporcionado. La forma adecuada es una decisión de producto.

Separa el contenido generado de la información de estado. La información de estado describe las condiciones de procesamiento, las entradas que faltan o las comprobaciones que requieren atención. No debe mezclarse con el texto propuesto. Si la incertidumbre es relevante, muestra el motivo de la revisión, como pasajes contradictorios del material de origen o una restricción incumplida, en lugar de dar por sentado que existe un valor numérico de confianza o que este resulta significativo.

1. Presenta el artefacto solicitado con la estructura prevista.
2. Coloca las advertencias y los avisos sobre entradas ausentes fuera del contenido generado.
3. Mantén adjuntas las referencias a las fuentes cuando la implementación lo permita.
4. Ofrece controles de edición que se correspondan con la siguiente acción práctica.

Evalúa el ciclo completo de interacción

La evaluación debe abarcar el recorrido desde la selección de las fuentes hasta la creación de las entradas, el procesamiento, la revisión y la acción final. Un conjunto de evaluación es una colección mantenida de ejemplos representativos y difíciles que se utiliza para comprobar una función frente a condiciones definidas. Su propósito es hacer que el comportamiento previsto pueda inspeccionarse, no reducir la interacción a una muestra pulida.

Elige ejemplos que pongan a prueba variaciones significativas de la tarea, como material incompleto, instrucciones contradictorias y contenido que deba permanecer sin cambios. Registra qué debe inspeccionar la persona responsable de la revisión, en lugar de reducir cada resultado a una única puntuación. Cuando cambien las condiciones de implementación, repite las comprobaciones pertinentes y examina si la interfaz sigue comunicando sus límites.

• Confirma que cada control visible cambia la condición prevista.
• Comprueba que la información omitida siga apareciendo claramente como omitida.
• Revisa los resultados según criterios de aceptación específicos de la tarea.
• Prueba las vías de recuperación para entradas incompletas o inadecuadas.
• Mantén la aprobación humana en las decisiones que requieran criterio.

Crea un contrato de entrada y salida

Un diseño práctico puede resumirse como un contrato: el producto declara qué acepta, cómo se restringe ese material, qué devuelve y dónde corresponde realizar la revisión. Este contrato debe poder entenderse sin saber redactar un prompt. Internamente, proporciona al equipo puntos estables para probar prompts, modelos y pasos de procesamiento sin confundir esos componentes con la propia interfaz.

Para la siguiente decisión de diseño, anota cuatro cosas: la entrada requerida, las opciones con consecuencias, el resultado revisable y la acción posterior. Después, examina cada control y mensaje según esa secuencia. Si un elemento no puede relacionarse con el contrato, elimínalo, acláralo o trátalo como un detalle de implementación que todavía debe verificarse.