Ensayo · 4 min · Arturo Ordóñez
Qué debe explicar una interfaz
Un botón, un formulario o un mensaje de error tienen algo que explicar. Revisar esas pequeñas promesas ayuda a encontrar problemas que una captura de pantalla no muestra.
Al entrar en una web, una persona intenta averiguar si está en el lugar adecuado. Busca qué se ofrece, para quién sirve y cómo avanzar. La composición puede responder a esas preguntas o retrasarlas: un titular ocupa espacio aunque apenas diga algo, y una fotografía atrae atención aunque no ayude a entender el servicio.
La confianza depende después de que las acciones cumplan lo que anuncian. Aquí conviene revisar la web como un recorrido: leer, elegir, actuar y comprobar qué ocurrió. Mirar sólo la portada deja fuera buena parte de esa experiencia.
El nombre de una acción fija una expectativa
«Consultar disponibilidad» y «Reservar» no prometen lo mismo. El primer texto permite esperar una respuesta informativa; el segundo sugiere que se va a ocupar una fecha. Antes de ajustar el tamaño de un botón, hay que saber qué hace realmente. El texto debe anticipar ese resultado y cualquier paso intermedio que cambie la decisión.
En un formulario, cada dato solicitado necesita un motivo comprensible. Nombre, correo y descripción de la necesidad pueden bastar para iniciar una conversación. Un campo adicional merece preguntas concretas: ¿se necesita ahora?, ¿qué formato admite?, ¿qué ocurre si la persona no dispone de esa información?
La guía del W3C sobre etiquetas e instrucciones explica que las entradas deben indicar qué información se espera. Es una comprobación específica; su cumplimiento por sí solo no acredita la accesibilidad completa del formulario.
El estado debe corresponder a lo que ocurrió
Una pantalla puede mostrar que una petición se está enviando, que el proveedor la aceptó o que no se conoce el resultado. Conviene distinguir esos estados antes de escribir una confirmación. «Solicitud aceptada» no permite asegurar que el destinatario haya leído el correo.
El mensaje también debe llegar a quien no ve una actualización en pantalla. La documentación del W3C sobre mensajes de estado describe cómo anunciar los cambios pertinentes a las tecnologías de asistencia sin mover el foco. La interfaz necesita elegir qué cambios requieren ese anuncio y evitar una sucesión de interrupciones innecesarias.
Esta revisión alcanza al comportamiento del control. Durante un envío pendiente, una segunda pulsación no debería crear otra solicitud. Al terminar, la respuesta tiene que permitir entender si hay algo más que hacer.
Un error necesita una salida
Un mensaje como «Algo salió mal» deja pendiente todo el trabajo de averiguación. Una explicación aprovechable identifica qué se sabe: hay un campo incompleto, se perdió la conexión o el proveedor no pudo aceptar la petición. Si no se conoce la causa, es mejor describir esa incertidumbre que atribuirla a la persona.
La recuperación se puede revisar con tres preguntas:
- ¿Sigue disponible lo que ya se había escrito?
- ¿Se señala el dato que hay que corregir?
- ¿Es seguro volver a intentarlo o debemos comprobar antes el estado de la operación?
Conservar un borrador requiere decidir dónde se guarda y cuándo se elimina. Añadir un botón de reintento exige saber si la primera operación pudo haber producido un efecto. Son decisiones del funcionamiento que terminan afectando al texto y al diseño.
Revisar la página fuera de la captura
Una captura permite comparar tamaño, contraste y distribución. Para revisar el recorrido hay que abrir el menú, recorrerlo con teclado, ampliar el texto, cambiar de idioma y llegar a la acción principal desde una pantalla estrecha. También interesa comprobar qué permanece disponible cuando una imagen o un vídeo no carga.
Las imágenes pueden establecer un tono; los diagramas, explicar relaciones. Su presencia debería dejar intacta la información necesaria para actuar. En un vídeo voluntario, el póster y su contexto escrito tienen que permitir decidir si merece la pena reproducirlo.
El resultado de esta revisión debería ser una lista de cambios comprobables: renombrar una acción, conservar una entrada, corregir un estado o acercar una explicación al control que la necesita. Así se puede volver a recorrer la página y verificar qué ha mejorado.
El tamaño y el espacio dan un peso distinto a cada pregunta.
Leer la historia visual
Una interfaz debe orientar la lectura, hacer visible una acción pendiente y conservar una salida cuando algo falla.
Una entrada de lectura. El propósito permite reconocer qué se puede hacer aquí. El recorrido empieza en Propósito, continúa por Información y termina en Acción. Una marca señala la posición de lectura.
Una acción pendiente tiene estado. Mientras se espera, la misma petición no debe enviarse otra vez. Acción conduce a Pendiente. La línea de repetición queda detenida mientras no existe una respuesta.
La confirmación dice lo que se sabe. Aceptar una solicitud no confirma que alguien ya la haya leído. La respuesta se identifica como Solicitud aceptada. La lectura por una persona aparece como un hecho todavía no confirmado.
Un fallo necesita una explicación. El mensaje debe indicar qué ocurrió y qué parte se puede corregir. El recorrido se bifurca hacia Error. Un vínculo señala la información que necesita atención en lugar de borrar todo lo escrito.
Recuperar el trabajo permite continuar. Conservar la entrada y permitir otro intento reduce la repetición. La entrada conservada conecta con Corregir y Volver a intentar. Una flecha regresa al punto de la acción.
No se pudo cargar este vídeo. Puedes leer la historia visual completa arriba.