Caso de estudio
Un proyecto de rediseño de panel de soporte que ordena la información sin perder la cercanía con quien la usa.
El panel anterior acumulaba tres años de funciones agregadas sin una revisión general. Los tickets se mezclaban con métricas internas y el acceso a respuestas frecuentes quedaba escondido detrás de dos clics. El equipo de soporte pedía lo mismo desde hacía tiempo: menos ruido visual y más contexto sobre cada conversación.
El encargo llegó con una condición clara: no se trataba de sumar módulos nuevos, sino de reorganizar lo existente para que el flujo diario tuviera sentido. Había que conservar las funciones que ya funcionaban y descartar lo que nadie usaba.
Se trabajó con el equipo de soporte durante dos semanas para mapear las tareas más frecuentes. El resultado fue una jerarquía nueva: el historial del cliente pasó a primer plano, las respuestas rápidas quedaron a un clic y los informes internos se movieron a una vista separada.
El rediseño también incluyó un sistema de estados más claro para los tickets, con colores que se distinguen incluso en pantallas pequeñas. Se eliminaron dos paneles que nadie abría y se unificaron los filtros de búsqueda en una sola barra.
El panel pasó de 14 vistas a 6, y el tiempo promedio para resolver un ticket bajó porque la información relevante aparece antes. El equipo de soporte dejó de mantener una hoja de cálculo paralela con datos que el sistema ya tenía.
La implementación se hizo en dos entregas: primero la estructura de navegación y luego los ajustes de detalle. Cada cambio se probó con el equipo antes de pasar a producción, lo que evitó sorpresas en el día a día.
Se documentaron los wireframes originales y la versión final del flujo de resolución de tickets. El código de muestra incluye los componentes de filtros y la lógica de estados.
El caso completo quedó registrado para futuras iteraciones del producto.
Proyecto 02
Un proyecto enfocado en decisiones prácticas y restricciones reales de calendario.
Un pequeño operador turístico de la costa necesitaba ordenar su temporada alta. Hasta ese momento, las reservas se manejaban por correo y una planilla compartida que cada semana terminaba con datos cruzados. El encargo fue claro: un flujo de reservas que funcionara sin depender de una persona específica.
Trabajamos con un calendario real de disponibilidad, bloques de temporada y reglas de pago por adelantado. La parte más delicada no fue el diseño, sino definir qué pasaba cuando un cliente quería mover una fecha ya confirmada.
En lugar de permitir cualquier fecha, el sistema muestra solo los rangos disponibles según la temporada. Esto redujo las consultas de clientes que intentaban reservar fuera de temporada.
El cliente elige fecha, ve el precio estimado y recién después ingresa sus datos. Separar la selección del formulario evitó abandonos por fricción innecesaria.
Definimos que los cambios de fecha se podían hacer hasta 7 días antes sin cargo. Después de eso, se trataba como nueva reserva. Esta regla se comunicó desde el inicio y evitó discusiones posteriores.
El flujo más simple no siempre es el mejor. En este caso, una regla de modificación explícita fue más valiosa que cualquier animación o efecto visual. El cliente sigue usando el sistema dos temporadas después.