Amaia Cuida Product Design
Rediseñar un ecosistema de cuidado sin frenar su crecimiento
Durante dos años trabajé como única Product Designer en la evolución de Amaia Cuida, un ecosistema SaaS formado por tres plataformas conectadas para profesionales de residencias y familias.
El reto no fue simplemente rediseñar una interfaz. El producto estaba creciendo mientras lo utilizaban centros reales, por lo que el trabajo consistió en construir progresivamente una base más consistente, comprensible y escalable sin detener su evolución.
- Mi rol
- Product Designer UX/UI
- Duración
- 2 años
- 2023–2025
- Equipo
- CEO, Frontend, Backend y Customer Success
- Productos
- 3 plataformas
- Amaia Profesionales (web)
- Amaia Conecta (tablet)
- Amaia App (familias)
01 El punto de partida
Un producto que ya funcionaba, pero necesitaba una base común
Cuando me incorporé, Amaia ya era un producto en funcionamiento y seguía incorporando nuevas funcionalidades. El problema más evidente era la falta de consistencia entre pantallas y flujos construidos en momentos diferentes.
Una misma acción podía representarse con botones de formas, colores o estilos distintos. Los patrones cambiaban entre secciones y la interfaz no siempre ayudaba a entender qué elementos cumplían funciones equivalentes.
Además, el producto iba a crecer rápidamente. Antes de seguir añadiendo nuevas funcionalidades necesitábamos construir una base que permitiera hacerlo sin multiplicar esas diferencias.
02 Primero, dar coherencia
La primera capa del rediseño fue visual
Empecé por Amaia Profesionales, la plataforma principal y la que concentraba más funcionalidades y demostraciones con clientes.
En esta primera etapa no intenté replantear toda la arquitectura del producto. La prioridad era resolver las inconsistencias más visibles y trasladar la identidad de Amaia a una interfaz más coherente.
Unificamos progresivamente colores, tipografía, botones, contenedores, jerarquías y patrones visuales. La estructura de muchos flujos seguía siendo la existente: primero necesitábamos estabilizar la base antes de intervenir con mayor profundidad.
Primero estabilizar la interfaz. Después, mejorar progresivamente cómo se utilizaba.
03 Cuando el producto empezó a crecer
La coherencia visual ya no era suficiente
A medida que el producto incorporaba nuevas funcionalidades y yo entendía mejor cómo se utilizaban, el trabajo empezó a ir más allá de la capa visual.
Los perfiles de las personas residentes concentraban cada vez más información: Preferencias, Historia de Vida, Valoraciones, Planificador, Reminiscencia, Galería… Mantener la navegación original hacía más difícil orientarse y moverse entre áreas.
La evolución del producto nos llevó a revisar progresivamente estructuras y patrones de navegación. Uno de los cambios más importantes fue introducir una navegación global persistente que permaneciera accesible incluso dentro del perfil de una persona.
Así, el profesional podía moverse entre las principales áreas del producto sin perder el contexto de dónde estaba.
04 Construir un lenguaje compartido
De pantallas consistentes a un sistema compartido
A medida que el producto crecía, mantener la consistencia pantalla a pantalla dejó de ser suficiente. Necesitábamos que las decisiones pudieran reutilizarse.
Trabajando directamente con frontend decidimos apoyarnos en Material Design y adaptarlo a la identidad de Amaia. Utilicé FlexColorScheme para definir el tema y facilitar su traducción a Flutter, mientras construía en Figma una librería de componentes alineada con ese mismo lenguaje.
El sistema fue creciendo junto al producto: tipografía, color, botones, diálogos, navegación y otros componentes se documentaban y reutilizaban a medida que aparecían nuevas necesidades.
- Material Design
- Sistema Amaia
- Figma y Flutter
Foundations
Componentes
No se trataba solo de que todo se viera igual
La estandarización también afectó a decisiones menos visibles, como la tipografía.
No quería definir los estilos únicamente por tamaño o apariencia, sino también por su función dentro de la interfaz. Un Label, un Body y un Title podían compartir determinadas propiedades visuales, pero cumplían funciones diferentes y debían utilizarse de forma consistente.
La misma lógica se trasladó progresivamente a componentes y patrones.
Con el sistema más maduro, Figma y Flutter compartían un lenguaje mucho más cercano. Reutilizábamos componentes con mayor facilidad, había menos dudas durante la implementación y disminuyeron muchas correcciones visuales.
Pero había un resultado todavía más importante: las decisiones empezaban a dejar de depender exclusivamente del conocimiento que frontend y yo habíamos construido trabajando juntos.
El sistema permitía documentarlas y reutilizarlas para que otras personas pudieran continuar haciendo crecer el producto.
05 Iterar también significó descartar
Más información no significaba más utilidad
El Home fue uno de los espacios donde mejor pudimos observar cómo evolucionaba nuestra comprensión de los profesionales.
V1 Dar identidad
La primera versión estuvo condicionada por la necesidad de mejorar rápidamente la interfaz. El foco estuvo en trasladar la identidad de Amaia al producto y organizar mejor la información disponible.
V2 Construir un dashboard más completo
A medida que conocíamos mejor el producto incorporamos indicadores, estadísticas, accesos rápidos y datos sobre el estado de las personas residentes.
La información era mucho más completa, pero apareció otro problema: tener más datos disponibles no hacía necesariamente el Home más útil.
Algunos profesionales nos explicaron que encontrarse de golpe con tantos indicadores y elementos pendientes podía resultar abrumador. Incluso hubo quienes preferían evitar esa sección porque ya sabían que tenían muchas cosas sin completar.
V3 De mostrar información a facilitar la siguiente acción
En la última iteración cambiamos el enfoque.
En lugar de utilizar el Home principalmente para mostrar el estado del producto, organizamos la información alrededor de lo que podía resultar útil en el trabajo diario:
- Tareas pendientes
- Las tareas pendientes convertían procesos incompletos en acciones concretas: aprobar una Historia de Vida, generar un pictograma o finalizar información pendiente de un perfil.
- Información nueva
- La información nueva funcionaba como un tablón para mantenerse al día sin mezclarla con aquello que requería una acción.
- Indicadores de cuidado
- Los indicadores de cuidado permitían entender el progreso general sin convertirlo en el protagonista de la experiencia.
- Próximos cumpleaños
- Y mantuvimos Próximos cumpleaños, una funcionalidad sencilla que los profesionales ya utilizaban y que trasladaba al producto una tarea que algunos centros seguían gestionando mediante calendarios físicos.
Aprendizaje
El reto no era mostrar más datos, sino distinguir entre lo que el profesional necesitaba saber y aquello sobre lo que necesitaba actuar.
06 Una base preparada para seguir creciendo
Más que una interfaz, una base para el futuro
El resultado de estos dos años no fue únicamente una interfaz diferente a la que encontré al incorporarme.
Amaia también había crecido como producto y como ecosistema. Ese crecimiento nos obligó a pasar progresivamente de resolver pantallas individuales a pensar en patrones, navegación, componentes y reglas compartidas.
- Consistencia
Una base común de componentes, estilos y patrones redujo las diferencias entre áreas creadas en distintos momentos del producto.
- Colaboración
Diseño y frontend construimos un lenguaje compartido que hacía más directa la transición entre Figma y Flutter y reducía dudas durante la implementación.
- Continuidad
Documentar las decisiones permitía que el conocimiento no dependiera únicamente de las personas que habíamos trabajado diariamente en el producto.
07 Lo que me llevo
Diseñar un sistema también es diseñar cómo trabaja un equipo
Entré en Amaia intentando poner orden en una interfaz que necesitaba mejorar con urgencia. Dos años después, dejaba un producto mucho más amplio que el que había encontrado, pero también una base de diseño preparada para seguir evolucionando.
El proceso no fue lineal. Hubo decisiones rápidas, versiones que tuvimos que replantear y partes del sistema que tardamos mucho más de lo que me habría gustado en estandarizar.
Precisamente por eso, uno de mis mayores aprendizajes fue entender que un sistema de diseño no consiste solo en crear componentes consistentes, sino en construir acuerdos entre diseño, tecnología y producto que puedan mantenerse en el tiempo.