Idea principal

Un vencimiento de facturación futuro aparece en el calendario de pagos de un cliente. Sin embargo, no existe como documento: solo tendrá existencia propia en el momento en que se emita la factura. Consecuencia inmediata: está ausente de los resultados de búsqueda. El usuario, en cambio, lo ha visto en pantalla; lo busca, no lo encuentra y abre un ticket.

No es un defecto puntual, es toda una familia de reclamaciones, tratada caso por caso desde hace años por un soporte que no dispone de ninguna formulación de la causa. Cada ticket se cierra con una explicación improvisada, y el siguiente vuelve a empezar.

El origen es una distancia entre dos modelos: lo que la interfaz da a ver y lo que el producto maneja como objetos. Una cosa vista por el usuario es un objeto para él, sea cual sea su existencia técnica.

Por qué es importante

Eso proporciona un ángulo de búsqueda por derecho propio: recorrer lo que el usuario maneja a diario y verificar que cada elemento existe en algún sitio como objeto del producto. Las pantallas traen así lo que ni el código ni la base señalan.

Cambia también el tratamiento de los tickets repetitivos: una familia de reclamaciones sin causa escrita es una señal de modelo ausente, no un volumen que absorber.

Matices y límites

No todo lo que se muestra tiene que convertirse en un objeto: un total, una agrupación de visualización, una línea de síntesis pueden seguir siendo vistas sin que nadie lo sufra. El criterio no es la presencia en pantalla, es que el usuario necesite recuperar la cosa, hablar de ella o actuar sobre ella.

Y la corrección no consiste necesariamente en crear el objeto: nombrar la ambigüedad y explicarla en la interfaz puede bastar.

Preguntas abiertas

• ¿Cómo detectar estos casos de otro modo que leyendo las pantallas una a una, en un producto que tiene varios centenares?