Proceso
Sin research formal previo, el proceso partió de un inventario exhaustivo de componentes existentes. Se redujo la biblioteca a la mitad, se definieron los foundations desde cero y se rediseñó el sistema teniendo siempre al usuario como centro de las decisiones.
- Inventario de componentes
- Reducción a la mitad
- Foundations desde cero
- Diseño y migración simultáneos
- Usuario como centro
Dos perfiles con necesidades distintas en la misma plataforma. El nuevo usuario llega a la web pública buscando entender qué es BKOOL y si vale la pena suscribirse, necesita claridad, confianza y una ruta de conversión sin fricción. El usuario existente entra al área de gestión con una tarea concreta: cambiar de plan, pausar la suscripción, añadir un familiar. Necesita eficiencia, control y la sensación de que la plataforma está de su lado. Ambos perfiles comparten el mismo sistema visual pero con énfasis distintos: conversión para el primero, utilidad para el segundo.
Tres flujos definieron las prioridades del sistema. El primero: el flujo de conversión, que un nuevo usuario entendiera el producto y se suscribiera sin fricción. El segundo: la gestión de suscripción, que un usuario existente pudiera pausar, cambiar de plan o darse de baja sin sentirse atrapado. El tercero: añadir familiares o amigos al plan, un flujo con restricciones complejas (máximo dos usuarios añadidos, máximo dos cambios permitidos) que requería componentes nuevos y edge cases muy bien resueltos.
El punto de partida fue un inventario exhaustivo de todos los componentes existentes en la plataforma. El diagnóstico fue claro: no existía un sistema pensado, había componentes duplicados, variantes innecesarias y soluciones ad hoc para problemas que ya tenían solución estándar. La decisión fue no adaptar lo existente sino partir desde los foundations: definir primero tipografía, paleta de color, espaciados y breakpoints, y construir los componentes desde ahí. Ese orden, foundations primero, componentes después, descartó la alternativa más rápida de reutilizar componentes existentes y limpiarlos, que habría perpetuado la inconsistencia subyacente.
El sistema se construyó en capas ordenadas. Primero los foundations: tipografía, paleta cromática, espaciados, breakpoints e iconografía. Después el inventario y auditoría de componentes existentes. Luego el rediseño, unificación y descarte, la biblioteca se redujo aproximadamente a la mitad. Finalmente los componentes nuevos para flujos que no existían anteriormente, como el módulo de añadir familiares con sus restricciones y edge cases.
