Calendario Z

Separar acento decorativo de acento funcional

El sistema actual usaba colores sin criterio semántico. Definí que cada color debía comunicar algo específico: tecnología (FO/RF), estado de tarea, prioridad por reprogramaciones. Esto reduce el error humano sin agregar complejidad visual.

Trazabilidad como feature central, no como log técnico

El historial de reprogramaciones existía en CRM pero era invisible en el calendario. Decidí surfacearlo como un contador visual de prioridad ,cuantas más reprogramaciones, más urgente visualmente. Eso elimina la necesidad de consultas manuales entre áreas.

Estandarizar duraciones por tipo de tarea

El selector manual de tiempo era la fuente principal de error humano. Instalación = 2h, Asistencia = 1h, Retiro = 30min. Fijo. El sistema calcula el cupo automáticamente. El operador deja de tomar esa decisión.

Bolsa de tareas pendientes en lugar de Excel paralelo

El sistema viejo ya tenía un panel de tareas, pero estaba desconectado de la carga semanal de cada cuadrilla: había que ir y volver entre secciones para decidir dónde asignar. Y las tareas sin fecha vivían aparte, en un Excel nocturno de CC. Diseñé un Task Pool integrado al calendario con dos caminos de asignación (selección manual o drag & drop) y feedback de compatibilidad en tiempo real por color: verde compatible, ámbar compatible con advertencia de localidad, gris incompatible. Si el usuario suelta igual sobre una cuadrilla incompatible, el sistema confirma antes de ejecutar la acción.

Design System con Shadcn como base

Para garantizar consistencia y velocidad de implementación, definímos junto al dev usar Shadcn como base del DS. Los componentes ya tienen accesibilidad resuelta, el equipo de dev puede adoptar el sistema sin fricción y yo puedo iterar los tokens sin tocar el código base. Por eso, después de validar flujos en Lovable, migré el prototipo a VS Code con Claude Code sobre el stack real (React + Tailwind + Shadcn): el handoff deja de ser un mockup para reinterpretar y pasa a ser código con algunos ajustes de escalabilidad.

Buscar por ID de Cliente, no por nombre

El research mostró que buscar por nombre generaba errores de homonimia en zonas de alta densidad de servicios. Prioricé ID de cliente, documento y ticket como claves de búsqueda, hoy ya implementado como búsqueda global por cliente, documento, ticket y localidad.

Capacidad visible antes que capacidad calculada

Cada tarjeta de cuadrilla muestra una barra de progreso con los minutos usados sobre el total del turno (360 min). El supervisor ve la capacidad real de un vistazo, sin sumar manualmente.

Un componente para los cinco estados de una tarea

En vez de una vista por estado, el modal de detalle es un único componente reutilizado en pendiente, asignada, completada, fallida y cerrada, que ajusta qué secciones muestra según corresponda. Si la cuadrilla asignada ya no existe, el detalle conserva igual el registro histórico de a quién estuvo asignada, en vez de romper o esconder el dato.

Accesibilidad visual como prioridad, no como extra

Las áreas coincidían en algo que no estaba en ningún documento del discovery: el blanco puro del sistema anterior generaba fatiga visual en jornadas largas. Prioricé el dark mode como experiencia principal y sumé el light mode para que cada usuario elija. En paralelo, los colores de zona, tecnología y estado cumplen contraste mínimo WCAG AA y nunca dependen solo del color para comunicar algo, y las áreas cliqueables de cuadrillas y tareas están dimensionadas para tocar sin errores.