Cuando el código funciona, pero la interfaz miente: 3 errores de UX de datos que ninguna prueba detecta
Por el equipo de Wonk · · 5 min de lectura
Tres errores reales de visualización de datos que pasaron todas las pruebas sin una sola advertencia, y las preguntas para detectarlos.
Un mapa muestra «0 habitantes».
El sistema funciona. La consulta respondió correctamente, la consola está limpia y nadie reportó un bug.
Pero ese cero puede significar dos cosas distintas: que ahí no vive nadie, o que no tenemos datos de esa zona.
La primera es un hallazgo: una zona despoblada, un predio industrial, una reserva. La segunda es una ausencia de información. Si alguien está decidiendo dónde abrir un centro de salud, confundirlas es la diferencia entre descartar una zona porque está vacía y descartarla porque no la medimos.
La pregunta que nadie le hace al software
Validamos software preguntando si el código funciona: si compila, si las pruebas pasan. En una interfaz de datos hay una segunda pregunta, igual de importante y mucho menos frecuente: ¿la información que comunicamos es verdadera en el contexto en que la mostramos?
Las herramientas de desarrollo no responden eso, y no es un defecto suyo: verifican la estructura del dato, no la afirmación que hace. Un 0 es un número válido en un campo numérico. Nada en el sistema sabe que está diciendo algo falso sobre un municipio de Cundinamarca.
Mientras construía el Modo Mapa de Wonk —la vista donde los datos del censo del DANE se consultan directamente sobre el territorio— encontré tres errores de este tipo. Los tres pasaban la compilación sin una sola advertencia.
Error 1: la forma que contradice la petición
El usuario elige «radio de 2 km» alrededor de un punto. Eso es un círculo, no una interpretación. En pantalla se dibujaba como una nube irregular.
Hay dos maneras de definir un área alrededor de un punto. Un radio es todo lo que está a menos de X metros: un círculo. Una isócrona es todo lo que alcanzas en X minutos caminando, y sigue la red vial.
Para el código, ambas son «un polígono alrededor de un punto». Estaba generando las dos con la misma función, y ninguna herramienta tenía forma de objetar: el resultado era un polígono válido en los dos casos.
No falló la geometría. Falló el contrato entre la intención del usuario y su representación visual. Alguien que pide 2 km y ve una forma irregular puede pensar que el sistema está roto o, peor, creer que esa forma significa algo.
La lección: cuando el usuario especifica una operación geométrica, la forma en pantalla es la confirmación de que se ejecutó.
Error 2: dos poblaciones para el mismo territorio
El segundo es el más grave. Arriba, el indicador de contexto del área decía 651.550 habitantes. Abajo, la ficha de población total decía 412.580.
Mismo territorio, misma vista, dos números a treinta centímetros de distancia.
El indicador de arriba derivaba la población del área activa: superficie por densidad. El panel de abajo devolvía un total que no dependía del área: mostraba la misma cifra sin importar qué zona estuviera seleccionada.
Ambas rutas eran correctas en su propia lógica, pero respondían preguntas distintas y nadie las había comparado.
Una contradicción así destruye algo que no se recupera fácil. Quien ve dos cifras incompatibles en la misma pantalla no piensa «hay un bug arriba». Piensa «no puedo confiar en estos números». Y tiene razón.
La lección: si una cifra aparece en más de un lugar, tiene que venir de la misma fuente. Ninguna prueba automática nota que dos números correctos se contradicen.
Error 3: datos de un lugar mostrados sobre otro
El tercero fue el más silencioso. Tres capas encendidas sobre el mapa, todas con el mismo aspecto legítimo. Dos se habían calculado sobre un área anterior, a kilómetros de donde el usuario estaba mirando.
Mantener las capas al cambiar de zona es razonable: a veces quieres comparar. Pero no avisarlo convierte una comparación en un engaño. La solución no fue borrarlas, sino marcar cada capa desalineada con una advertencia visible.
La lección: cuando un dato deja de corresponder al contexto activo, callarlo es peor que mostrarlo.
Volviendo al cero
Los tres errores anteriores los introduje y los arreglé. El caso del dato vacío es distinto: no es un error, es una decisión.
En Wonk, cuando no hay censo para un territorio, la ficha dice «sin dato censal»: dice con palabras que no sabemos. Lo mismo con los indicadores de baja confiabilidad estadística, que llevan una advertencia visible. Es coherente con la apuesta de fondo del producto: cada dato tiene que poder rastrearse hasta su fuente, y eso incluye admitir cuando la fuente no existe.
Cuesta más código y produce una interfaz menos limpia. Pero en una plataforma de decisiones territoriales, una interfaz limpia que miente vale menos que una honesta que admite lo que no sabe.
Tres preguntas antes de dar algo por terminado
¿Qué muestro cuando no hay dato? Si la respuesta es un cero, estás convirtiendo una ausencia en una afirmación.
¿Alguna cifra aparece en más de un lugar? Si sí, ¿viene de la misma fuente? Dos rutas de cálculo se desincronizan tarde o temprano.
¿Lo que dibujo corresponde a lo que el usuario pidió? No solo si el dato es correcto: si la forma y el contexto confirman lo que ejecutó.
Un compilador puede decirnos que nuestro código es válido. Una prueba puede decirnos que nuestra función hace lo que esperábamos.
Ninguna de las dos puede decirnos si estamos mintiendo con los datos.
Esa pregunta todavía tiene que hacerla alguien mirando la pantalla.
Temas: Visualización de Datos, Calidad de Datos, UX de Datos, Mapas, Inteligencia Territorial, Diseño de Producto, Wonk