# Interacción humano-computador y lenguaje

Una interfaz organiza posibilidades de acción y pone a la vista signos para reconocerlas. Un botón titulado «Guardar», un mensaje que anuncia «Cambios publicados» y una conversación donde alguien pide «déjalo listo» participan en esa organización de maneras distintas. Con el lenguaje se expresan objetivos, se interpretan estados, se coordinan pasos y se corrigen problemas, aunque el mismo lenguaje puede ocultar diferencias. Guardar un documento no siempre significa publicarlo, preparar una acción no es ejecutarla y un sistema puede haber comprendido una petición sin haber realizado todavía la acción correspondiente.

La interacción humano-computador estudia cómo las personas utilizan sistemas informáticos dentro de actividades concretas y cómo se diseñan esas relaciones. Su objeto abarca interfaces, tareas, aprendizaje, accesibilidad, trabajo y contextos de uso. Los modelos de lenguaje amplían las formas de interacción, aunque dejan en pie problemas anteriores, como saber qué puede hacer el sistema, cómo se descubren sus posibilidades, qué ocurrió después de una acción y cómo se recupera el control cuando aparece un error. Este texto examina el lenguaje como recurso de diseño y como parte de la actividad, en relación con la conversación, la manipulación de objetos, la iniciativa y la evaluación. Su propósito es explicar por qué una interfaz lingüísticamente fluida puede resultar difícil de utilizar y cómo diseñar interacciones en las que las palabras contribuyan a una acción comprensible y verificable, ajustada a las necesidades de sus participantes.

## La actividad como punto de partida

Una tarea formulada por el equipo de diseño rara vez describe por completo la actividad de una persona. «Buscar un documento» puede formar parte de la preparación de una clase, de la resolución de una discrepancia o de un trámite, finalidades que imponen criterios de éxito distintos. Encontrar cualquier archivo con un título parecido puede bastar en una exploración y quedarse corto cuando se necesita la versión vigente. El análisis debe situar las operaciones de interfaz dentro de esos propósitos. El lenguaje del usuario da pistas sobre ellos, aunque no siempre lo especifica todo. Una petición breve puede apoyarse en documentos visibles, decisiones previas o convenciones compartidas con otras personas; si el sistema no tiene acceso a esos recursos, una formulación aparentemente clara puede quedar indeterminada. Diseñar la interacción implica decidir qué contexto se muestra, qué se conserva y qué debe aclararse. La carga no debería recaer por entero en que el usuario redacte una instrucción exhaustiva en cada ocasión.

La investigación de Suchman (2007) sobre la acción situada cuestiona que lo que hacen las personas pueda explicarse únicamente como ejecución de planes especificados de antemano y dirige la atención hacia los recursos y las contingencias de cada actividad. Para el diseño, esto sugiere observar cómo las personas ajustan lo que hacen ante materiales, resultados y problemas. Durante la actividad, un plan puede orientarla sin anticipar cada decisión necesaria. En un ejemplo hipotético, quien organiza un archivo académico puede descubrir duplicados, cambiar una categoría o decidir conservar versiones que pensaba eliminar. Una interfaz que solo admite ejecutar un plan cerrado entorpece ese trabajo. Lo acompaña mejor otra en la que pueden inspeccionarse resultados parciales y modificarse los criterios. El diseño debe contemplar esa revisión como parte normal del uso, sin reducirla a una excepción o a un error del usuario.

## Expresar una intención e interpretar un resultado

La interacción enfrenta dos dificultades relacionadas. Primero, la persona necesita traducir su objetivo a acciones que el sistema admita; después, tiene que interpretar el estado resultante para saber si lo alcanzó. Hay interfaces que facilitan una de estas operaciones y dificultan la otra. Aceptar peticiones en lenguaje corriente reduce el esfuerzo inicial, pero una respuesta vaga puede dejar a la persona sin saber qué archivos se modificaron o qué condiciones se aplicaron. Un menú, con sus opciones visibles, ayuda a descubrir las acciones posibles y acota la elección. Una caja de conversación admite mayor flexibilidad expresiva, aunque puede ocultar el repertorio real del sistema; el usuario quizá tenga entonces que adivinar qué pedir y cómo formularlo. Por eso las interfaces conversacionales suelen beneficiarse de ejemplos, objetos seleccionables y controles complementarios, sin los cuales la libertad de entrada no asegura un aprendizaje fácil.

La interpretación del resultado requiere una retroalimentación vinculada a la acción. «Listo» puede bastar después de un cambio trivial y visible. Cuando se han procesado muchos documentos, en cambio, la palabra resulta ambigua y el sistema debería indicar el resultado relevante para la tarea, como cuántos elementos se modificaron, qué quedó pendiente o dónde consultar el producto. La información técnica solo ayuda cuando orienta una decisión. Si se reduce a un registro extenso de operaciones internas, puede entorpecer la comprensión sin dar al usuario más control. La distancia entre intención y resultado se acorta con correspondencias consistentes. Cuando una selección visual determina el alcance de una orden, esa selección tiene que seguir clara durante la ejecución, del mismo modo que una fecha límite fijada en la conversación debería poder verificarse en el resultado. Lograr que lenguaje, objetos y estado transmitan una misma interpretación es un problema de diseño del sistema completo y no únicamente de redacción de mensajes.

## La interfaz como organización de signos

Los signos de una interfaz incluyen palabras, iconos, posiciones, colores, sonidos y comportamientos, cuyo significado surge de convenciones y de relaciones de uso. Un icono familiar facilita a veces el reconocimiento, aunque fuera de cierto contexto puede volverse ambiguo. Algo semejante ocurre con una etiqueta precisa, que puede perder eficacia si aparece junto a controles que sugieren otra acción. La interpretación depende del conjunto y de la experiencia de quienes lo utilizan y no de una propiedad aislada del elemento gráfico.

De Souza (2005) propuso la ingeniería semiótica como una perspectiva centrada en la comunicación, mediada por la interfaz, entre quienes diseñan un sistema y quienes lo usan. La propuesta ayuda a examinar qué concepción del usuario, de sus objetivos y de las acciones posibles queda inscrita en el producto. Vista así, una interfaz comunica cómo se espera que la persona interprete y utilice sus signos, aun en ausencia de sus diseñadores. Una categoría como «Mis documentos» presupone una relación de pertenencia que debe definirse. Puede abarcar archivos creados, compartidos, editados o simplemente abiertos. Si la interfaz mezcla esos criterios, la etiqueta genera expectativas que el comportamiento no satisface. Con el análisis semiótico puede preguntarse qué relación se está comunicando y si corresponde al modelo operativo de la aplicación, cuestiones que la corrección gramatical de la etiqueta deja sin resolver.

Los signos también distribuyen relevancia. Una acción resaltada visualmente puede parecer recomendada; una advertencia escondida puede recibir poca atención. El orden de los resultados y la forma de nombrar las alternativas influyen en las decisiones, de modo que el diseño lingüístico abarca también la jerarquía y el contexto de presentación. Una evaluación limitada a frases aisladas deja fuera el modo en que la interfaz las convierte en invitaciones, condiciones, confirmaciones o señales de autoridad.

## Nombrar acciones y objetos

Una etiqueta de acción debería permitir anticipar su consecuencia. Guardar, enviar, archivar y publicar designan operaciones diferentes; cuando se usan de manera intercambiable, los usuarios tienen que aprender excepciones que aumentan los errores. El criterio es mantener dentro del servicio una relación consistente entre cada expresión y su efecto, sin imponer una palabra universal. Si una operación tiene consecuencias poco evidentes, una explicación breve puede completar la etiqueta.

Los nombres de los objetos deben responder al vocabulario de la actividad. Lo que los usuarios conocen como «formulario» o «trámite» quizá sea, para la institución, una «solicitud». El diseño necesita investigar esas diferencias y decidir cómo representarlas, a veces con términos alternativos en la búsqueda o la ayuda. Si se adopta exclusivamente el vocabulario interno del equipo, una función técnicamente disponible puede resultar difícil de encontrar para quienes la necesitan. La consistencia tampoco significa repetir la misma palabra para realidades distintas. «Versión» puede designar un archivo, una publicación o una configuración del sistema; si esas entidades participan en acciones diferentes, la interfaz debe distinguirlas donde importe. Un término general puede resultar cómodo al comienzo y volverse confuso cuando aparecen decisiones complejas. La precisión se ajusta al punto de la actividad en que una diferencia se vuelve necesaria para actuar.

Para probar una etiqueta puede preguntarse a la persona qué opción elegiría para recuperar un archivo, qué cree que ocurrirá al pulsar un botón y cómo interpreta el estado posterior. Las respuestas revelan expectativas además de preferencias estéticas. Hay etiquetas agradables que inducen una acción equivocada. La evaluación debería comprobar comprensión y resultado, aparte de recoger opiniones sobre claridad o tono.

## Manipulación directa y lenguaje

Shneiderman (1983) caracterizó la manipulación directa, entre otros rasgos, por la representación visible de los objetos y por operaciones rápidas, incrementales y reversibles. Esa tradición de diseño ayuda a entender el valor de actuar sobre elementos reconocibles y observar de inmediato sus efectos. La conversación abre otra vía, la de expresar una intención sin especificar todos los movimientos. Ambas pueden complementarse cuando la interfaz mantiene visibles los objetos y resultados que anclan las referencias lingüísticas. Supongamos que una persona selecciona tres párrafos y pide «haz más breve esta parte». La selección reduce la ambigüedad de «esta parte», mientras el lenguaje expresa una transformación difícil de representar con un único control. El resultado debería mantener visible el alcance de la edición y permitir comparar versiones. La combinación facilita una acción que sería laboriosa con comandos rígidos y ambigua en una conversación sin referencia al documento.

En otras tareas un control explícito puede ser más eficiente que conversar, como al ordenar una tabla por una columna, ajustar un valor conocido o alternar entre dos vistas. El diseño debe sopesar esfuerzo, frecuencia y precisión; disponer de un modelo de lenguaje no obliga a convertir cada operación en diálogo.

La complementariedad requiere consistencia de estado. Un filtro cambiado mediante un control debe reflejarse en la conversación si viene al caso, así como una instrucción que modifica la selección debe actualizar la vista. Si esa correspondencia falla, aparecen dos versiones de la actividad, la que narra el asistente y la que muestra la interfaz. Mantenerlas coordinadas hace del lenguaje un recurso para controlar los objetos manipulados.

## Iniciativa y automatización

Entre la persona y el sistema, la iniciativa puede distribuirse de distintas maneras. El usuario solicita una acción; el sistema, a su vez, puede proponer un paso, señalar información faltante o completar una operación rutinaria. Horvitz (1999) examinó principios para interfaces de iniciativa mixta, que combinan servicios automatizados con control directo. Su perspectiva lleva a evaluar cuándo una intervención automática aporta un beneficio y cuándo interrumpe o se adelanta a una decisión que corresponde al usuario.

La incertidumbre sobre la intención es un factor central de esa evaluación. Si la persona selecciona varios archivos, quizá quiera moverlos, compararlos o revisarlos. Actuar automáticamente a partir de una sola señal puede ahorrar pasos en algunos casos y producir errores en otros. Ante esa duda el sistema puede presentar una propuesta visible, esperar otra indicación o ejecutar una acción reversible cuando el contexto deja suficientemente clara la intención. La elección debe atender a la actividad y a lo que cuesta equivocarse.

Las sugerencias también tienen costos. Un aviso puede desviar la atención, obligar a leer o agregar una decisión. Cuando las propuestas irrelevantes se repiten, el usuario aprende a ignorar las sugerencias, incluso cuando una posterior sea útil. La evaluación debe considerar la frecuencia, la oportunidad y la posibilidad de desactivarlas. Examinada por separado, cada intervención puede parecer razonable aunque el aumento acumulado de interrupciones reduzca la calidad del trabajo. El control significativo requiere que la persona pueda aceptar, modificar o rechazar las propuestas y sepa qué ocurrirá si no responde. Una interfaz que presenta una sugerencia como opción y luego la ejecuta por defecto, bajo condiciones poco claras, limita ese control. La automatización debe hacer comprensible su alcance y conservar rutas de recuperación. El objetivo es coordinar capacidades sin que la comodidad de delegar convierta decisiones inciertas en acciones difíciles de revisar.

## Conversación y descubrimiento de capacidades

Una interfaz conversacional acepta expresiones variadas y puede combinar operaciones. Esa flexibilidad reduce la necesidad de aprender una sintaxis formal, aunque el sistema mismo sigue teniendo que aprenderse. Los usuarios necesitan saber qué recursos están disponibles, qué límites existen y cómo se representan los resultados. Cuando el asistente responde con igual fluidez a peticiones que puede ejecutar y a otras que solo puede describir, la diferencia de capacidad queda oculta tras una apariencia uniforme. Los ejemplos de uso ayudan si representan tareas reales y no prometen competencias inexistentes. También ayuda mostrar el estado de las conexiones, los documentos seleccionados o las herramientas disponibles cuando afectan a la petición, siempre cerca de la decisión que orientan. Un catálogo exhaustivo de funciones puede resultar tan poco útil como la ausencia total de orientación. El descubrimiento suele ser gradual y ligado a objetivos que la persona reconoce como propios.

La conversación no debe castigar formulaciones razonables. Si falta un dato, el sistema puede pedirlo de manera específica y conservar lo ya entendido. Obligar a reiniciar la petición tras cada dificultad aumenta el trabajo y vuelve opacas las condiciones de éxito. Una reparación eficaz identifica el punto pendiente, sea el archivo, el periodo o el destinatario. Con reparaciones de ese tipo, la persona puede aprender a colaborar con la herramienta sin dominar fórmulas especiales.

También cuenta la consistencia entre sesiones. Si una petición produce una acción en una sesión y una explicación en otra, el usuario necesita comprender qué cambió en el contexto. Cambios de permisos, de disponibilidad o de selección pueden justificar conductas distintas, siempre que se hagan visibles. De lo contrario, la variación se percibe como arbitraria. El diseño conversacional tiene que apoyar la flexibilidad lingüística en una estructura estable de capacidades y estados, de modo que la experiencia pueda aprenderse y anticiparse.

## Tiempo, espera y continuidad

Las operaciones informáticas tienen duraciones distintas y la interfaz debe ayudar a interpretarlas. A veces una respuesta inmediata confirma la recepción de una orden aún no ejecutada, o un indicador de progreso muestra actividad en un proceso que todavía puede fallar. El lenguaje de estado tiene que distinguir estas situaciones. «Estoy procesando los documentos» comunica un proceso en curso, mientras que «los documentos están actualizados» afirma un resultado. Si la persona confunde ambos mensajes, puede dar por cerrada una tarea que aún no se ha completado.

Durante la espera la persona puede cambiar de objetivo o descubrir un error. Cancelar, corregir el alcance o seguir con otra actividad forman parte de la interacción. Un sistema que bloquea toda acción mientras trabaja encarece cada operación; uno que acepta nuevas instrucciones debe definir cómo se relacionan con lo que está en curso. Según el caso, una corrección modifica el trabajo pendiente u obliga a detenerlo antes de aplicar el nuevo criterio. Para la continuidad cuenta también el contexto que se conserva entre un paso y otro. Quien vuelve a una tarea necesita reconocer qué se hizo, qué quedó pendiente y qué decisiones siguen abiertas. Esa información puede estar en el historial completo, aunque obligar a releerlo entero no siempre es adecuado. Un resumen del estado puede facilitar el regreso, siempre que conserve las referencias y mantenga como provisionales las decisiones que todavía lo son.

La evaluación del diseño debe atender a los tiempos percibidos y sus consecuencias, además de a la latencia técnica. Una operación algo más lenta puede ser preferible si da ocasión de inspeccionar el resultado y reduce correcciones posteriores. A la inversa, una respuesta muy rápida puede generar más trabajo si obliga a verificar afirmaciones vagas. La medida pertinente es el recorrido completo de la actividad, que abarca comprensión, ejecución, revisión y recuperación. Optimizar un único intervalo puede empeorar la experiencia si desplaza el esfuerzo a etapas menos visibles.

## Errores y posibilidades de recuperación

Los errores de uso pueden surgir de expectativas razonables ante una interfaz ambigua. Culpar al usuario por elegir una opción equivocada deja sin explicar por qué esa opción le parecía la adecuada. El análisis debe examinar etiquetas, contexto, estado y consecuencias. Una confirmación adicional quizá ayude en ciertos casos, aunque también puede volverse un trámite mecánico si aparece constantemente. La prevención necesita entender el origen del error, sin añadir fricción de manera indiscriminada.

La recuperación requiere que el sistema describa qué ocurrió y qué puede hacerse. Un mensaje como «Operación fallida» no aclara si nada cambió o si hubo cambios parciales. Cuando algunos documentos se actualizaron y otros no, el usuario necesita saber cuáles. Un mensaje que sugiera repetir todo podría crear duplicados. La explicación del fallo tiene que conectarse con el estado real y con acciones que permitan avanzar sin agravar el problema. La reversibilidad reduce el costo de explorar. Comparar versiones, deshacer cambios y restaurar selecciones permite aprender actuando. Sin embargo, la interfaz debe indicar qué operaciones son reversibles y hasta cuándo. Presentar un botón de deshacer que no cubre los efectos externos puede crear una expectativa falsa. La correspondencia entre el control visible y su alcance real tiene que ser especialmente precisa cuando una actividad combina edición local y acciones sobre servicios compartidos.

Amershi y colaboradores (2019) propusieron y evaluaron un conjunto de orientaciones para la interacción humano-IA que atienden a las capacidades del sistema, los errores, la corrección y la evolución del uso. Con ellas pueden organizarse las preguntas de diseño a lo largo de toda la experiencia, más allá de la primera respuesta.

Esas orientaciones han de aplicarse de manera situada. Saber que una corrección debe ser fácil todavía deja por decidir cómo representarla en una tarea concreta y qué información tiene que conservar el sistema.

## Accesibilidad y diversidad de formas de participación

Las personas difieren en capacidades perceptivas, motoras y lingüísticas, así como en sus condiciones de uso. Una interfaz que depende exclusivamente del color, de la voz o de la precisión motora puede dejar fuera situaciones de uso relevantes. Con el lenguaje pueden abrirse alternativas y, al mismo tiempo, surgir barreras de lectura, memoria o producción escrita. Diseñar para la accesibilidad requiere examinar actividades completas con los usuarios implicados, sin dar por supuesto que una modalidad nueva resuelve todas las dificultades de acceso. Cuando escribir resulta difícil, la voz puede facilitar la interacción, aunque tal vez sea inadecuada en un espacio compartido o ruidoso. El texto puede revisarse y es discreto, pero exige acceso visual o tecnologías de apoyo. En lo posible, las distintas modalidades deberían conservar funciones equivalentes. Si una acción solo puede confirmarse mediante un gesto visual o una respuesta oral rápida, ciertos usuarios quedan en desventaja aunque el resto del servicio parezca accesible.

La claridad lingüística también depende del dominio. Simplificar una explicación puede ayudar a comprenderla, pero si se elimina una distinción técnica la persona puede quedar sin los elementos de una decisión informada. Una solución es organizar el detalle en capas, con una formulación inicial comprensible y acceso a condiciones o definiciones cuando hagan falta. La adaptación tiene que preservar el significado y dejar que el usuario controle el nivel de explicación. Hablar en tono infantilizante o imponer la misma simplificación a todos los usuarios no facilita el acceso.

La evaluación de accesibilidad recurre a herramientas de inspección e incluye a personas con experiencias y estrategias distintas. Observar cómo navegan, corrigen y recuperan información permite descubrir obstáculos que una lista de componentes no revela. También hay que considerar las interrupciones, la fatiga y el uso con dispositivos diferentes. La accesibilidad es una propiedad del recorrido entre objetivo y resultado y no únicamente de la presencia de etiquetas o de una opción de lectura en voz alta.

## Personalización y modelos del usuario

Según preferencias explícitas y patrones de uso, un sistema puede adaptar el vocabulario, el orden de las opciones o la cantidad de ayuda. Esa adaptación puede reducir el esfuerzo y, a la vez, volver impredecible la interfaz. Si una función cambia de lugar o una respuesta se acorta sin explicación, la persona puede perder una estrategia aprendida. Las preferencias estables y las necesidades momentáneas merecen un tratamiento distinto. El usuario debería poder revisar o restablecer las decisiones que afectan su experiencia.

Los modelos del usuario son aproximaciones operativas e incompletas de una persona. Que alguien haya solicitado una explicación introductoria no demuestra una falta general de conocimiento. Tampoco los errores de escritura dan base segura para juzgar la capacidad intelectual de quien escribe. La adaptación debería usar información pertinente para la tarea y abstenerse de extrapolaciones personales innecesarias. Cuando una preferencia puede preguntarse directamente con poco costo, preguntar puede ser más útil que una inferencia opaca y difícil de corregir.

La memoria de preferencias necesita límites comprensibles. El usuario debería saber qué decisiones se conservaron y poder modificarlas. Trasladada de un proyecto a otro sin distinguir el contexto, una preferencia puede dar resultados inadecuados. Una memoria selectiva y revisable, que conserve bajo condiciones claras lo que ayuda a la actividad, puede ser más útil que una acumulación extensa de efecto difícil de anticipar.

La personalización debe evaluarse a lo largo del tiempo. Una adaptación útil en el aprendizaje inicial puede estorbar cuando crece la experiencia o cambian los objetivos y las condiciones de trabajo. La interfaz tiene que permitir el paso entre niveles de apoyo sin obligar a abandonar el servicio. Estudiar esas trayectorias da información que una prueba breve de primera impresión no recoge, aunque las dos evaluaciones son útiles.

## Métodos para estudiar la interacción

Los estudios de uso parten de preguntas definidas, por ejemplo si las personas descubren una función, comprenden un estado, detectan un error o completan una actividad. Para responderlas pueden combinarse observación, entrevistas, registros y tareas controladas. Cada método aporta una evidencia distinta. Una entrevista recoge cómo la persona describe su experiencia. Los registros muestran secuencias de acciones y la observación contextual las relaciona con materiales y circunstancias. Tomada aisladamente, ninguna de esas fuentes describe la interacción completa.

Los prototipos permiten investigar antes de construir toda la infraestructura. Una representación de baja fidelidad puede bastar para estudiar etiquetas y organización de opciones. Una simulación conversacional sirve para explorar qué información solicita el usuario y cuándo necesita aclaraciones. En ese caso el protocolo debe comunicar con claridad la naturaleza del estudio y separar el comportamiento simulado del rendimiento real del sistema. Si esa separación falta, los resultados pueden atribuir a una tecnología capacidades que pertenecían al procedimiento experimental.

Las métricas deben corresponder a los objetivos. El tiempo de finalización, los errores, la recuperación y la comprensión pueden ser relevantes junto con la satisfacción. Alguien puede preferir una interfaz más agradable aunque con ella detecte menos errores. Otra persona, en cambio, quizá trabaje más despacio y obtenga resultados mejor revisados. La comparación tiene que interpretar esos intercambios. Un promedio alto de satisfacción no demuestra eficacia, ni una reducción del tiempo prueba que la calidad del producto se haya mantenido.

Las tareas de prueba deben representar actividades plausibles. Pedir operaciones artificiales puede facilitar el control experimental a costa de la validez de uso. Una estrategia posible combina contrastes controlados, que ayudan a aislar efectos, con estudios contextualizados, que revelan cómo esos efectos se integran con interrupciones, colaboración y conocimiento previo. Más que acumular métodos, la triangulación pone en relación evidencias como estas, que responden a aspectos complementarios de una misma pregunta de diseño.

## Caso de diseño sobre la revisión de un archivo académico compartido

Consideremos una interfaz para revisar y organizar los artículos de un proyecto, en la que es posible seleccionar documentos, pedir resúmenes y proponer cambios de clasificación. El diseño inicial dispone únicamente de una conversación. Admite instrucciones flexibles, pero surgen dudas sobre qué archivos están incluidos y qué cambios ya se aplicaron. Las sesiones de prueba muestran que el problema central es la falta de una representación compartida del estado, antes que una incapacidad del sistema para comprender las palabras de la petición.

Una segunda propuesta combina la conversación con una lista de documentos, filtros visibles y un panel de cambios propuestos. La instrucción «agrupa estos por tema» toma como alcance la selección actual y el sistema responde con una propuesta que puede editarse antes de aplicarla. Cada categoría lleva ejemplos y una definición breve. La interfaz distingue entre la clasificación propuesta y la guardada. Estas decisiones conectan lenguaje, objetos y consecuencias, de manera que es posible revisar cómo se interpretó la petición sin reconstruir toda la conversación.

La evaluación compara tareas de búsqueda, reclasificación y recuperación de errores, con interrupciones intercaladas para estudiar cómo se retoma una actividad pendiente. Se observa si las personas identifican el alcance, detectan documentos mal ubicados y comprenden qué cambió. Además de la rapidez, cuenta que el archivo final represente las decisiones de la persona y que pueda explicarse cómo se llegó a ese estado cuando alguien más lo consulte.

El archivo, como muchos sistemas, se utiliza dentro de una organización donde una acción afecta a otras personas. Un cambio de nombre, una clasificación o un resumen pueden circular más allá de la interfaz que los produjo, por lo que el diseño debe atender a la procedencia, las versiones y las responsabilidades. Un resultado claro dentro de la conversación puede ser equívoco para un lector posterior que desconoce su estatuto; un borrador generado y una decisión aprobada tienen que distinguirse cuando participan en un flujo de trabajo común.

El lenguaje organiza esas transiciones. Términos como propuesta, revisado y publicado indican estados diferentes siempre que correspondan a procesos reales. Hacer visible quién realizó cada acción y qué revisión falta puede facilitar la coordinación. La interfaz no necesita convertir cada paso en burocracia, aunque sí debe preservar las distinciones en que los participantes se apoyan para confiar en el trabajo. La calidad de la interacción incluye el modo en que sus resultados se incorporan a actividades posteriores.

En la revisión del archivo, la persona debería poder reconocer qué versión tiene abierta y dónde quedaron sus cambios. Cuando el encargo es ambiguo, la conversación puede aclararlo. Una duda sobre lo modificado, en cambio, quizá se resuelva mejor con una comparación visible entre versiones. La elección depende de la tarea. Cuando el usuario tiene que reconstruir el estado preguntando una y otra vez, la fluidez del diálogo está compensando una carencia de la interfaz. Observar ese trabajo adicional ayuda a decidir qué información debe permanecer visible y qué aclaraciones conviene dejar a cargo del lenguaje.

## Referencias

Amershi, S., et al. (2019). Guidelines for Human-AI Interaction. *Proceedings of CHI*. https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/

De Souza, C. S. (2005). *The Semiotic Engineering of Human-Computer Interaction*. MIT Press. https://mitpress.mit.edu/9780262527095/the-semiotic-engineering-of-human-computer-interaction/

Horvitz, E. (1999). Principles of Mixed-Initiative User Interfaces. *Proceedings of CHI*. https://www.microsoft.com/en-us/research/publication/principles-mixed-initiative-user-interfaces/

Shneiderman, B. (1983). Direct Manipulation: A Step Beyond Programming Languages. *Computer, 16*(8), 57–69. https://www.cs.umd.edu/~ben/papers/Shneiderman1983Direct.pdf

Suchman, L. (2007). *Human-Machine Reconfigurations: Plans and Situated Actions*. Cambridge University Press. https://www.cambridge.org/core/books/human-machine-reconfigurations/9D53E602BA9BB5209271460F92D00EFE