El problema
El CRM ya operaba: asignaciones, sitios y personal a diario. El freno no era el dominio, era la UI — navegación confusa, jerarquía débil y un viewport comido por barras y márgenes que no aportaban a la tarea.
La pregunta diaria del operador era siempre la misma: ¿qué persona está en qué sitio y en qué proyecto? Responderla es cruzar listados —personal, sitios, asignaciones— durante horas. Cada barra fija se cobra en filas que no caben, y cada fila que no cabe es un scroll más para encontrar a alguien.
El encargo: rediseñar la superficie, no reescribir el producto. Más datos útiles de un vistazo, y que la herramienta se sintiera actual y no un legacy con capa de pintura.
El encargo
- Área útilMás superficie para tablas, formularios y detalle; menos marcos fijos.
- JerarquíaQué mirar primero en cada vista — título, metadata, acción.
- DensidadMás filas y controles sin perder legibilidad en jornadas largas.
- SistemaShell y componentes listos para implementar sin reinterpretar cada módulo.
Rediseño
Qué cambié
Framework de capas, prueba de área útil, patrón de listados y un kit para que desarrollo no adivinara en cada pantalla.
01Framework
Tres capas. Un solo criterio
Había dos caminos: rediseñar pantalla por pantalla o un framework de capas. Aposté por lo segundo (shell, datos y sistema visual) con un objetivo: más espacio para el trabajo, menos para los marcos.
Eso evitó un maquillaje suelto y alineó a negocio y devs en cómo se medía el éxito: área útil, legibilidad y consistencia, no “más bonito”.
Aquí se ven las dos primeras. El shell decide cuánto marco fijo hay; los datos, cuánto cabe dentro de lo que queda. La tercera capa —el sistema visual— es la que hace que esas dos se repitan igual módulo a módulo, y por eso cierra el case en su propia sección.
Rail colapsado a iconos: 168 px de ancho que vuelven a la mesa.
Más filas visibles; filtros densos sin perder lectura.
02Prueba
Antes y después: recuperar pantalla
La prueba más clara era de superficie útil. Compacté navegación, unifiqué barras de acción y bajé ruido para que el usuario trabajara con datos, no con la interfaz.
La comparación no era estética: era cuánto de la pantalla sirve al trabajo. Medí el área de tabla —donde viven los datos— en ambas versiones, sobre una pantalla de 1440×950: pasó de 1066×432 a 1296×695. En superficie, casi el doble (+95%), y la proporción entre datos e interfaz se dio la vuelta.
Traducido a lo que ve quien trabaja ahí: el listado pasó de 10 a 17 filas visibles sin scroll. Siete personas más de un vistazo, cada vez que el operador abre la vista para saber quién está en qué sitio. Sin tocar la lógica de negocio, y con la densidad revisada con negocio y desarrollo antes de entregar.
Estimación, no medición: con 17 filas en vez de 10, recorrer un listado de 100 sitios pasa de 10 pantallas a 6 — un 40% menos de paginación para revisar lo mismo. Sale de la cuenta de arriba; no hubo instrumentación que lo confirmara en uso real.
| Criterio | Antes | Después |
|---|---|---|
| Ancho del área de tablaSobre 1440 px de pantalla | 1066 px · 74% | 1296 px · 90% |
| Alto del área de tablaSobre 950 px de pantalla | 432 px · 45% | 695 px · 73% |
| Superficie para datosProporción de la pantalla completa | 34% · el resto, interfaz | 66% · +95% de área |
| Filas visiblesSin hacer scroll | 10 | 17 · +70% |
03Patrón core
La tabla es el producto
Para el operador el listado no es una vista más: es donde se responde quién está dónde. Ajusté tipografía, filas, estados (activo, pendiente, suspendido, finalizado, cancelado) y filtros para escanear personal y sitios de un vistazo y actuar en un clic, sin cajas ni bordes de adorno.
Y no es una vista: el producto son listados. Sitios de trabajo, tipos de sitio, clientes, usuarios, proyectos, permisos y reportes de check-in — siete módulos, seis de ellos tablas. Por eso el patrón no era un componente más del kit: al resolverlo una vez quedaba resuelta casi toda la herramienta, y ese doble de superficie no se gana en una pantalla, se gana en las siete.
El menú listaba acciones
El lateral anterior vivía siempre expandido: Crear cliente y Crear sitio ocupaban fila propia, Listado se repetía tres veces sin decir de qué, y Actividades se desplegaba para mostrar Actividades. Dos reglas lo ordenaron: un módulo con un solo destino navega, no despliega, y los verbos viven en su pantalla —donde ya está el botón Nuevo sitio—.
Lo que costó: decidir qué quitar
Duplicar el área de tabla no fue añadir, fue restar: se fueron la nav superior entera, el lateral ancho y la segunda fila de filtros. El riesgo era pasarse — un shell demasiado delgado deja al operador sin saber dónde está. El criterio, elemento por elemento: se va lo que se repite o se puede deducir; se queda lo que dice dónde estoy. Por eso el rail colapsado conserva el módulo activo resaltado y la identidad de quien entra, aunque pierda las etiquetas.
Restricción: producto vivo
Rediseño sobre una herramienta en uso diario: los siete módulos se entregaron para handoff incremental, módulo a módulo, no en un big-bang que parara la operación.
Design system
Shell + kit
El rediseño no cerraba en pantallas sueltas: cerraba en un shell de navegación y un kit de componentes con reglas, para que desarrollo no reinterpretara los siete módulos uno por uno.
- Shell — menos chrome fijo, iconografía alineada, orientación clara entre módulos.
- Componentes — botones, campos, chips y estados en Figma con uso explícito.
- Handoff — una fuente de verdad visual sobre el mismo dominio de negocio.
Cierre
Resultado
Una UI más densa y clara sobre el mismo producto: más área útil, listados que son el trabajo y un sistema para seguir construyendo.
-
Más espacio para el trabajo
Listados, formularios y detalle como foco, no los marcos alrededor.
-
Sin reescribir el negocio
Misma lógica de producto; el valor está en densidad, claridad y consistencia visual.
-
Base para seguir construyendo
Shell + kit de componentes: el equipo puede extender módulos sin reinventar la UI en cada pantalla.
Qué supe después
El handoff fue incremental y la comunicación con desarrollo, escasa: los devs fueron implementando módulo a módulo y no tuve acceso a analítica ni a un seguimiento formal.
Lo que sí llegó de vuelta fue el comentario de quienes lo usan a diario: la navegación mejoró y dejaron de saltar entre pantallas para juntar información que ahora ven en un solo lugar. Es exactamente lo que perseguía el framework de capas —más datos por vista, menos tránsito—, pero conviene nombrarlo como lo que es: evidencia cualitativa, no medida.
Qué haría distinto: dejar acordadas dos métricas simples antes del handoff —tiempo hasta localizar a una persona y número de vistas por tarea— para no depender de que el feedback llegue por casualidad.
Aprendizaje
«Cada píxel de marco es un píxel menos de trabajo. Este rediseño avanzó cuando la discusión dejó de ser de estilo y pasó a ser de medidas.»