Arquitectura de la Información: Etapas de diseño de la AI – Etapa 5/6 Búsqueda

En corto: Un sistema de búsqueda no se reduce a un campo y un botón. Es un ciclo de consulta, recuperación, resultados, refinamiento y corrección.

Primero se decidirá si aporta valor. Cuando sea necesaria, se documentará qué puede buscarse, mediante qué términos y metadatos, cómo se determina la relevancia y qué ocurre en cada estado. Si se omite, también se registrará la razón.

La cantidad de páginas no decide por sí sola

La búsqueda es uno de los cuatro componentes descritos por Gonzales Cam, junto con organización, navegación y rotulado. Su utilidad aumenta cuando explorar categorías deja de ser suficiente para recuperar información, pero no existe un número universal de páginas o registros que determine automáticamente su necesidad.

Un producto pequeño puede requerir búsqueda si la tarea consiste en localizar rápidamente un identificador exacto. Uno muy extenso podría funcionar principalmente mediante navegación si su contenido se explora por etapas y no existe una colección recuperable.

La decisión dependerá de:

• Volumen, diversidad y crecimiento del contenido.
• Frecuencia, urgencia y precisión de las tareas de localización.
• Conocimiento y términos disponibles.
• Capacidad de la navegación para resolver la necesidad.
• Calidad del índice, permisos y factibilidad técnica.

El comercio electrónico suele beneficiarse de una búsqueda robusta, pero también requiere investigar sus consultas. Baymard Institute muestra que autocompletado, lógica de resultados y filtros contienen problemas diferentes; disponer de un campo no significa resolverlos.

Qué recibe esta etapa

Las etapas anteriores ya definieron:

• Tareas y criterios de éxito.
• Actores, escenarios y restricciones.
• Organización, rutas y destinos.
• Vocabulario de objetos, acciones y estados.

Estos insumos permiten preguntar qué necesidades no resuelve bien la navegación y qué lenguaje podría utilizarse al consultar.

Método para diseñar un sistema de búsqueda

1. Decidir si la búsqueda es necesaria

Antes de diseñarla se responderá:

1. ¿Qué intenta localizar la persona?
2. ¿Conoce su nombre, identificador o alguna característica?
3. ¿Con qué frecuencia y urgencia realiza la tarea?
4. ¿Cuántos elementos podrían coincidir?
5. ¿La navegación, el filtrado de una lista o un acceso reciente resolverían mejor la necesidad?
6. ¿Existe información estructurada suficiente para ofrecer resultados útiles?

Si las personas necesitan examinar siempre una lista pequeña y estable, agregar búsqueda puede introducir una vía innecesaria. Si localizan registros entre miles de elementos mediante identificadores, nombres o estados, puede convertirse en el acceso principal.

2. Definir qué puede recuperarse

La búsqueda necesita un corpus: la colección de objetos y contenidos que el sistema podrá consultar. Para cada tipo se documentará:

• Campos indexables.
• Metadatos disponibles.
• Sinónimos, abreviaturas y variantes.
• Formatos de identificadores, fechas o números.
• Contenido excluido.
• Reglas de actualización.
• Permisos para mostrar el resultado y sus datos.

Una interfaz no puede compensar un índice incompleto o información mal clasificada. Si el estado de una solicitud no se actualiza o un contrato carece de identificador, la dificultad pertenece también al modelo de datos.

3. Comprender cómo se formula la consulta

Las consultas pueden buscar:

• Un elemento conocido, como un número de solicitud.
• Un conjunto, como solicitudes bloqueadas durante un periodo.
• Una característica o una respuesta todavía imprecisa.

Entrevistas, observación, consultas y soporte ayudan a conocer términos, errores y reformulaciones. El vocabulario del sistema puede diferir del que las personas escriben.

4. Diseñar la entrada de búsqueda

El mecanismo visible puede contener campo, nombre, ejemplo, activador y opción para limpiar. Deberá permitir:

• Reconocer la colección consultada.
• Escribir, pegar y activar la consulta.
• Revisarla y modificarla después de obtener resultados.
• Comprender restricciones de formato.

El ancho visual no se decidirá mediante un mínimo universal de 27 o 30 caracteres. Dependerá de la longitud habitual de las consultas, el dispositivo y el espacio disponible; el sistema tampoco debe truncar el valor real por el tamaño visible del campo.

El icono de lupa puede apoyar el reconocimiento, pero el control necesita un nombre comprensible y accesible. El autocompletado se incluirá cuando existan datos y reglas suficientes para ofrecer sugerencias pertinentes, no como requisito automático.

5. Definir coincidencia y relevancia

Antes de diseñar la lista se necesita acordar cómo responde el sistema:

• Coincidencia exacta o parcial.
• Tolerancia a errores y variantes.
• Peso de cada campo.
• Actualidad, popularidad u otros criterios de orden.
• Tratamiento de sinónimos.
• Resultado principal cuando existe una coincidencia inequívoca.

“Mostrar lo más relevante” no constituye una especificación mientras no se defina qué significa relevancia para la tarea.

6. Diseñar resultados y refinamiento

Cada resultado debe aportar suficiente información para decidir si conviene abrirlo. Puede mostrar título, fragmento, estado, fecha, categoría u otros metadatos según el dominio. La consulta debería permanecer disponible para facilitar su corrección.

También se distinguirán mecanismos que suelen confundirse:

Solo se ofrecerán opciones que ayuden a decidir. Una lista extensa de filtros puede trasladar al usuario la complejidad que el sistema no resolvió.

7. Representar estados y recuperación

El modelo deberá incluir:

• Estado inicial.
• Escritura y sugerencias.
• Carga.
• Resultados.
• Pocos resultados.
• Cero resultados.
• Consulta corregida.
• Error técnico.
• Resultado restringido por permisos.

Una pantalla sin coincidencias debe reconocer lo ocurrido y ofrecer acciones pertinentes: revisar escritura, eliminar filtros, ampliar alcance, utilizar otra ruta o solicitar ayuda. No deberá presentar contenido no relacionado como si fuera una coincidencia.

8. Elegir cómo continuar la lista

Paginación, carga incremental y desplazamiento infinito resuelven necesidades distintas. El desplazamiento infinito favorece exploración continua, pero Nielsen Norman Group desaconseja utilizarlo de forma general en tareas dirigidas a localizar o comparar elementos.

La elección deberá considerar regreso a una posición, comparación, volumen, rendimiento, accesibilidad y necesidad de compartir o conservar resultados.

9. Evaluar el sistema

La prueba utilizará consultas y tareas representativas. Se observarán:

• Éxito al localizar el elemento correcto.
• Consultas sin resultados.
• Reformulaciones y correcciones.
• Uso de filtros y ordenamiento.
• Selección de resultados pertinentes.
• Tiempo y esfuerzo.
• Recuperación después de un intento fallido.

Estas medidas deberán interpretarse junto con la intención. Reformular puede indicar un problema, pero también una exploración deliberada.

Ejemplo: localizar solicitudes y contratos

En el sistema interno ficticio se determina que la búsqueda sí aporta valor porque existen numerosos registros y las personas suelen conocer algún identificador, nombre, fecha o estado.

El modelo establece:

• Búsqueda principal por identificador y nombre relacionado.
• Coincidencia exacta prioritaria para identificadores.
• Filtros por estado, fecha y responsable.
• Resultados con identificador, estado, fecha y siguiente dato útil para distinguirlos.
• Persistencia de la consulta al abrir un resultado y regresar.
• Estado sin resultados con revisión de formato y eliminación de filtros.
• Restricción de datos según permisos.

Todavía no se decide si el campo estará en el encabezado, dentro de la lista o en una vista independiente. Esa ubicación dependerá de la jerarquía y frecuencia de uso que se resolverán al estructurar la interfaz.

Entregable: modelo de búsqueda

Qué deja resuelto para la interacción

Esta etapa define el comportamiento de recuperación: qué se consulta, cómo responde el sistema, cómo se interpreta el resultado y cómo se continúa después del error. No decide todavía la ubicación, prominencia ni relación espacial del buscador con el resto de la tarea.

Ejercicio

Elegir una colección real y elaborar:

1. Dos tareas que justifiquen o descarten la búsqueda.
2. Cinco consultas representativas.
3. Los metadatos necesarios para distinguir resultados.
4. Tres formas de refinar el conjunto.
5. Los estados de cero resultados y error técnico.

Conclusión

La búsqueda es un sistema de recuperación, no un accesorio visual. Su calidad depende tanto de la organización, los rótulos y los metadatos como del campo que aparece en pantalla.

Con objetivos, contexto, rutas, lenguaje y recuperación documentados, la última etapa podrá integrar las decisiones. La estructura dejará de ser un acomodo intuitivo de cajas y se convertirá en la traducción espacial y conductual de la Arquitectura de la Información.