UI / UX Design
Vivo Duoc UC: rediseñar una app y construir el sistema que la sostiene
Cómo lideré el rediseño completo de la app de Duoc UC, construí la identidad visual del producto desde cero y desarrollé en paralelo el design system que escalaría a todos los productos digitales del instituto.
Year :
2025
Industry :
Educación superior
Client :
DUOC UC
Rol :
Lead Product Designer
Contexto
Duoc UC es uno de los institutos de educación superior más grandes de Chile, con más de 130.000 estudiantes activos en sedes a lo largo del país. Su app móvil era la herramienta principal con la que los alumnos gestionaban su vida académica, horarios, calificaciones, asistencias, certificados, credencial virtual y mucho más.
El problema era evidente al abrir la app. Había sido construida por desarrolladores sin dirección de diseño, con una interfaz funcional pero sin sistema, sin identidad y sin criterio de experiencia de usuario. Cada pantalla parecía haber sido diseñada de forma independiente. Era una app que hacía lo que tenía que hacer, pero no se sentía como un producto.
En 2024 Duoc UC tomó la decisión de hacer el rediseño completo. La condición era clara, no era solo rediseñar pantallas. Era construir una nueva identidad para el producto digital del instituto y desarrollar en paralelo el design system que serviría de base para la app, para la web y para cualquier producto digital nuevo que Duoc UC lanzara en el futuro.
No era un rediseño. Era construir desde cero el lenguaje visual digital de una institución con 130.000 estudiantes.
La app que teníamos
App anterior | Nueva App VIVO |
|---|---|
Navegación por grid de íconos sin jerarquía. 15 opciones visibles al mismo tiempo sin priorización. | Bottom navigation con 5 secciones principales. Acceso directo a lo más usado. |
Sin sistema de diseño. Cada pantalla usaba colores, tipografía y espaciado diferente. | Design system completo con tokens, componentes y documentación. |
Identidad visual mezclada: azul institucional con amarillo sin cohesión | Nueva identidad púrpura con tipografía y paleta definidas por el equipo de diseño. |
Onboarding inexistente. El usuario entraba sin saber qué podía hacer. | Walkthrough de 3 pasos que contextualiza las funciones principales antes del login. |
Estados de error genéricos. Mensajes técnicos sin contexto ni solución sugerida. | 4 tipos de modales de error con mensajes específicos y acciones concretas. |
Sin bottom navigation. La navegación principal era la misma lista de íconos del home. | Navegación contextual con acceso directo a la asignatura desde el horario. |
Dos proyectos en paralelo
Este proyecto tenía una complejidad particular y es que no se podía diseñar la app sin el sistema, pero el sistema no podía existir sin la app que lo validara. Trabajé los dos en paralelo de forma intencional.
🟣 App Vivo Duoc UC (Producto) | 🟠 Design System (Infraestructura) |
|---|---|
Rediseño completo de la app móvil. Nuevos flujos, nueva identidad, nuevas features y nueva arquitectura de información. El producto que los 130.000 estudiantes usarían todos los días. | Librería de componentes, tokens y documentación construida en paralelo. Diseñada para escalar a la web, productos internos y cualquier nueva herramienta digital que el instituto desarrollara. |
Los desafíos
01 Escala real desde el día uno. La app tenía que funcionar para estudiantes de carreras completamente distintas: una alumna de Comunicación y un estudiante de Ingeniería necesitaban la misma app, pero usaban funciones totalmente diferentes. El diseño tenía que ser flexible sin ser genérico. |
|---|
02 Un solo diseñador de producto liderando todo. Trabajé con un diseñador UI de una empresa externa para la parte visual del sistema, pero las decisiones de arquitectura, flujos, identidad y componentes las lideré yo. Eso exigía un proceso muy ordenado para no perder coherencia. |
03 El design system tenía que ser usable por equipos que no habían participado en su construcción. No servía de nada un sistema que solo yo entendía. La documentación y los criterios de uso tenían que ser autónomos desde el inicio. |
04 Decisiones de identidad sin precedente. Duoc UC no tenía una identidad digital establecida para sus productos. El púrpura, la tipografía, el tono visual y la personalidad de VIVO fueron decisiones del equipo de diseño, no mandatos de marca previos. |
05 Casos de uso complejos. Algunos estudiantes tenían más de una carrera activa simultáneamente. Los flujos de asistencias, cursos, certificados y solicitudes tenían que manejar esa complejidad sin abrumar al usuario promedio que solo tenía una. |
Resultados
+50%Mejora en satisfacción de usuarios post-lanzamiento | −35%Reducción en tiempo de diseño por sprint con el DS |
|---|---|
4xProductos que consumen la librería de componentes | 130kEstudiantes impactados por el rediseño |
Mi proceso
Auditoría y research con usuarios realesEmpecé por mapear todos los flujos de la app existente e identificar los puntos de fricción. Hice entrevistas con estudiantes de distintas carreras y sedes para entender qué usaban más, qué evitaban y qué les faltaba. El hallazgo más importante: los usuarios más frecuentes eran los que tenían clases en el día y necesitaban verificar horario, asistencia y credencial en menos de 30 segundos. Eso definió las prioridades de la navegación principal. |
|---|
Definición de identidad y dirección creativaCon el equipo definí la identidad visual de VIVO. La decisión del púrpura fue intencional: queríamos romper con el azul institucional pesado que asociaba la app con trámites y burocracia. El púrpura daba energía juvenil sin perder seriedad académica. Definí la paleta completa, la tipografía, el tono visual y los principios de diseño que guiarían todas las decisiones posteriores. |
Arquitectura de información y nueva navegaciónRediseñé la arquitectura completa. El grid de 15 íconos se reemplazó por una bottom navigation de 5 tabs: Inicio, Horario, Solicitudes, Notificaciones y Perfil. Las funciones menos frecuentes se organizaron dentro de cada sección de forma contextual. Ese cambio fue la decisión estructural más importante del proyecto: poner lo crítico al alcance del pulgar sin eliminar las funciones secundarias. |
Construcción del Design System en paraleloMientras diseñaba los flujos de la app, construí el sistema de diseño. Empecé por los tokens: color, tipografía, espaciado, radio de bordes y sombras. Después los componentes atómicos: botones, inputs, cards, badges, modales. Luego los patrones: cómo se combinan esos componentes para resolver problemas concretos como un formulario de solicitud o una card de actividad con múltiples estados. El diseñador UI externo ejecutó el sistema visual bajo mis criterios.  |
Diseño de flujos complejosDiseñé los flujos más complejos de la app: el progreso académico con visualización de créditos por categoría, la inscripción de asignaturas con estados diferenciados (inscrita, aprobada, reprobada, complementaria), el sistema de solicitudes con seguimiento de tickets y el calendario integrado con sincronización a Google Calendar y calendario nativo. Cada flujo tenía que manejar casos de alumnos con múltiples carreras activas sin romper la experiencia del caso estándar.  |
Estados de error y casos edgeDediqué tiempo específico a los estados de error. La app anterior tenía un solo modal de error genérico para todo. Diseñé cuatro tipos distintos, error genérico, perfil de colaborador no soportado, carrera online no disponible y alumno eliminado del sistema. Cada uno tenía un mensaje específico, una acción concreta y un tono diferente según la gravedad. Eso redujo la fricción en los casos de acceso problemático que antes llegaban al soporte sin contexto.  |
Walkthrough y onboardingDiseñé un walkthrough de 3 pantallas que aparece la primera vez que el usuario abre la app. No era un tutorial genérico: cada pantalla comunicaba una propuesta de valor concreta: sigue tu progreso académico, gestiona tu tiempo, todo en un solo lugar. También diseñé el estado de mantenimiento con acceso directo a la credencial digital, para que incluso cuando la app estuviera en mantención, los estudiantes pudieran acceder a su carnet virtual.  |
El design system
El design system no era un proyecto separado: era la infraestructura que haría que la app fuera mantenible y escalable. Lo construí con una lógica de tres capas.
01 Tokens | 02 Componentes | 03 Patrones |
|---|---|---|
Color, tipografía, espaciado, radio y sombras. Los valores primitivos del sistema con nombres semánticos. | Botones, inputs, cards, badges, modales, navegación. Cada uno con variantes de estado documentadas. | Combinaciones de componentes para resolver flujos completos: solicitudes, calendarios, formularios, listas académicas. |
La Card de Actividad fue uno de los componentes más complejos del sistema. Tenía que funcionar para 5 tipos de actividad (clase teórica, práctica, taller, actividad institucional, feriado), 4 estados (default, en curso, suspendida, recuperativa), 3 formatos (presencial, online, híbrido) y combinaciones de cambio de sala. Diseñar ese componente de forma que todos los casos fueran legibles sin crear una explosión de variantes fue el desafío técnico más importante del sistema.
Flujos y pantallas diseñadas
Login + estados de error 4 modales de error específicos, estado de loading, modal de ayuda con número de soporte y opción de activar cuenta. | Calendario y horario Vista semanal y mensual, filtros por categoría, detalle de actividad con acceso directo a la asignatura, sincronización con calendarios externos. |
|---|---|
Progreso académico Visualización de créditos por categoría, tooltips explicativos, estados por asignatura y acceso al plan de estudios. | Inscripción de asignaturas Flujo completo con estados diferenciados: inscrita, aprobada, reprobada, complementaria. Manejo de múltiples carreras simultáneas. |
Sistema de solicitudes Mis solicitudes con estados abiertas, cerradas e históricas. Detalle de ticket con timeline de respuesta y opción de replicar solicitud rechazada. | Credencial digital + mantención Credencial con código de barras accesible siempre, incluso durante mantenimiento. Pantalla de mantención con acceso directo sin login. |
Decisiones de diseño clave
La decisión más importante fue cambiar el paradigma de navegación. Pasar del grid de íconos a la bottom navigation no era solo un cambio visual: era una declaración sobre qué importaba. El grid trataba todas las funciones como iguales. La bottom navigation decía: estas cinco cosas son las que un estudiante necesita todos los días. Todo lo demás está, pero no compite por atención con lo crítico.
La segunda decisión fue la credencial accesible durante mantenimiento. Eso no estaba en el brief original. Pero durante el research descubrí que muchos estudiantes usaban la credencial para entrar a la sede. Si la app estaba en mantención y no podían entrar, el problema no era técnico. Era físico. Esa pantalla de mantención con acceso a la credencial fue una de las decisiones más pequeñas del proyecto con mayor impacto real.
El mejor diseño del proyecto fue una pantalla de error. La credencial accesible durante mantenimiento resolvió un problema que nadie había nombrado pero todos habían vivido.
En el design system, la decisión más importante fue diseñar para el equipo que no estaba en la sala. El sistema tenía que ser autónomo: documentado de forma que un diseñador nuevo pudiera entenderlo, un desarrollador pudiera implementarlo y un product manager pudiera tomarlo como referencia sin necesitar que yo se los explicara.
Aprendizajes
Producto y sistema son inseparables No se puede construir un buen sistema sin un producto que lo valide, ni un producto escalable sin un sistema que lo sostenga. Trabajarlos en paralelo fue la decisión correcta aunque fuera la más difícil. | Los casos edge son el diseño real Los alumnos con dos carreras, los colaboradores que intentan entrar, la app en mantención. Esos casos no son la excepción. Son donde el diseño se demuestra o se rompe. |
|---|---|
Liderar sin equipo grande Ser la única product designer exigió mucho criterio sobre qué hacer primero, qué delegar y qué simplificar sin perder calidad. Aprendí a priorizar con más disciplina que nunca. | El sistema diseña para el futuro El design system no era para la app actual. Era para que Duoc UC pudiera lanzar cualquier producto digital nuevo sin empezar desde cero. Eso cambió cómo tomé cada decisión del sistema. |
Más proyectos
UI / UX Design
Vivo Duoc UC: rediseñar una app y construir el sistema que la sostiene
Cómo lideré el rediseño completo de la app de Duoc UC, construí la identidad visual del producto desde cero y desarrollé en paralelo el design system que escalaría a todos los productos digitales del instituto.
Year :
2025
Industry :
Educación superior
Client :
DUOC UC
Rol :
Lead Product Designer
Contexto
Duoc UC es uno de los institutos de educación superior más grandes de Chile, con más de 130.000 estudiantes activos en sedes a lo largo del país. Su app móvil era la herramienta principal con la que los alumnos gestionaban su vida académica, horarios, calificaciones, asistencias, certificados, credencial virtual y mucho más.
El problema era evidente al abrir la app. Había sido construida por desarrolladores sin dirección de diseño, con una interfaz funcional pero sin sistema, sin identidad y sin criterio de experiencia de usuario. Cada pantalla parecía haber sido diseñada de forma independiente. Era una app que hacía lo que tenía que hacer, pero no se sentía como un producto.
En 2024 Duoc UC tomó la decisión de hacer el rediseño completo. La condición era clara, no era solo rediseñar pantallas. Era construir una nueva identidad para el producto digital del instituto y desarrollar en paralelo el design system que serviría de base para la app, para la web y para cualquier producto digital nuevo que Duoc UC lanzara en el futuro.
No era un rediseño. Era construir desde cero el lenguaje visual digital de una institución con 130.000 estudiantes.
La app que teníamos
App anterior | Nueva App VIVO |
|---|---|
Navegación por grid de íconos sin jerarquía. 15 opciones visibles al mismo tiempo sin priorización. | Bottom navigation con 5 secciones principales. Acceso directo a lo más usado. |
Sin sistema de diseño. Cada pantalla usaba colores, tipografía y espaciado diferente. | Design system completo con tokens, componentes y documentación. |
Identidad visual mezclada: azul institucional con amarillo sin cohesión | Nueva identidad púrpura con tipografía y paleta definidas por el equipo de diseño. |
Onboarding inexistente. El usuario entraba sin saber qué podía hacer. | Walkthrough de 3 pasos que contextualiza las funciones principales antes del login. |
Estados de error genéricos. Mensajes técnicos sin contexto ni solución sugerida. | 4 tipos de modales de error con mensajes específicos y acciones concretas. |
Sin bottom navigation. La navegación principal era la misma lista de íconos del home. | Navegación contextual con acceso directo a la asignatura desde el horario. |
Dos proyectos en paralelo
Este proyecto tenía una complejidad particular y es que no se podía diseñar la app sin el sistema, pero el sistema no podía existir sin la app que lo validara. Trabajé los dos en paralelo de forma intencional.
🟣 App Vivo Duoc UC (Producto) | 🟠 Design System (Infraestructura) |
|---|---|
Rediseño completo de la app móvil. Nuevos flujos, nueva identidad, nuevas features y nueva arquitectura de información. El producto que los 130.000 estudiantes usarían todos los días. | Librería de componentes, tokens y documentación construida en paralelo. Diseñada para escalar a la web, productos internos y cualquier nueva herramienta digital que el instituto desarrollara. |
Los desafíos
01 Escala real desde el día uno. La app tenía que funcionar para estudiantes de carreras completamente distintas: una alumna de Comunicación y un estudiante de Ingeniería necesitaban la misma app, pero usaban funciones totalmente diferentes. El diseño tenía que ser flexible sin ser genérico. |
|---|
02 Un solo diseñador de producto liderando todo. Trabajé con un diseñador UI de una empresa externa para la parte visual del sistema, pero las decisiones de arquitectura, flujos, identidad y componentes las lideré yo. Eso exigía un proceso muy ordenado para no perder coherencia. |
03 El design system tenía que ser usable por equipos que no habían participado en su construcción. No servía de nada un sistema que solo yo entendía. La documentación y los criterios de uso tenían que ser autónomos desde el inicio. |
04 Decisiones de identidad sin precedente. Duoc UC no tenía una identidad digital establecida para sus productos. El púrpura, la tipografía, el tono visual y la personalidad de VIVO fueron decisiones del equipo de diseño, no mandatos de marca previos. |
05 Casos de uso complejos. Algunos estudiantes tenían más de una carrera activa simultáneamente. Los flujos de asistencias, cursos, certificados y solicitudes tenían que manejar esa complejidad sin abrumar al usuario promedio que solo tenía una. |
Resultados
+50%Mejora en satisfacción de usuarios post-lanzamiento | −35%Reducción en tiempo de diseño por sprint con el DS |
|---|---|
4xProductos que consumen la librería de componentes | 130kEstudiantes impactados por el rediseño |
Mi proceso
Auditoría y research con usuarios realesEmpecé por mapear todos los flujos de la app existente e identificar los puntos de fricción. Hice entrevistas con estudiantes de distintas carreras y sedes para entender qué usaban más, qué evitaban y qué les faltaba. El hallazgo más importante: los usuarios más frecuentes eran los que tenían clases en el día y necesitaban verificar horario, asistencia y credencial en menos de 30 segundos. Eso definió las prioridades de la navegación principal. |
|---|
Definición de identidad y dirección creativaCon el equipo definí la identidad visual de VIVO. La decisión del púrpura fue intencional: queríamos romper con el azul institucional pesado que asociaba la app con trámites y burocracia. El púrpura daba energía juvenil sin perder seriedad académica. Definí la paleta completa, la tipografía, el tono visual y los principios de diseño que guiarían todas las decisiones posteriores. |
Arquitectura de información y nueva navegaciónRediseñé la arquitectura completa. El grid de 15 íconos se reemplazó por una bottom navigation de 5 tabs: Inicio, Horario, Solicitudes, Notificaciones y Perfil. Las funciones menos frecuentes se organizaron dentro de cada sección de forma contextual. Ese cambio fue la decisión estructural más importante del proyecto: poner lo crítico al alcance del pulgar sin eliminar las funciones secundarias. |
Construcción del Design System en paraleloMientras diseñaba los flujos de la app, construí el sistema de diseño. Empecé por los tokens: color, tipografía, espaciado, radio de bordes y sombras. Después los componentes atómicos: botones, inputs, cards, badges, modales. Luego los patrones: cómo se combinan esos componentes para resolver problemas concretos como un formulario de solicitud o una card de actividad con múltiples estados. El diseñador UI externo ejecutó el sistema visual bajo mis criterios. |
Diseño de flujos complejosDiseñé los flujos más complejos de la app: el progreso académico con visualización de créditos por categoría, la inscripción de asignaturas con estados diferenciados (inscrita, aprobada, reprobada, complementaria), el sistema de solicitudes con seguimiento de tickets y el calendario integrado con sincronización a Google Calendar y calendario nativo. Cada flujo tenía que manejar casos de alumnos con múltiples carreras activas sin romper la experiencia del caso estándar. |
Estados de error y casos edgeDediqué tiempo específico a los estados de error. La app anterior tenía un solo modal de error genérico para todo. Diseñé cuatro tipos distintos, error genérico, perfil de colaborador no soportado, carrera online no disponible y alumno eliminado del sistema. Cada uno tenía un mensaje específico, una acción concreta y un tono diferente según la gravedad. Eso redujo la fricción en los casos de acceso problemático que antes llegaban al soporte sin contexto. |
Walkthrough y onboardingDiseñé un walkthrough de 3 pantallas que aparece la primera vez que el usuario abre la app. No era un tutorial genérico: cada pantalla comunicaba una propuesta de valor concreta: sigue tu progreso académico, gestiona tu tiempo, todo en un solo lugar. También diseñé el estado de mantenimiento con acceso directo a la credencial digital, para que incluso cuando la app estuviera en mantención, los estudiantes pudieran acceder a su carnet virtual. |
El design system
El design system no era un proyecto separado: era la infraestructura que haría que la app fuera mantenible y escalable. Lo construí con una lógica de tres capas.
01 Tokens | 02 Componentes | 03 Patrones |
|---|---|---|
Color, tipografía, espaciado, radio y sombras. Los valores primitivos del sistema con nombres semánticos. | Botones, inputs, cards, badges, modales, navegación. Cada uno con variantes de estado documentadas. | Combinaciones de componentes para resolver flujos completos: solicitudes, calendarios, formularios, listas académicas. |
La Card de Actividad fue uno de los componentes más complejos del sistema. Tenía que funcionar para 5 tipos de actividad (clase teórica, práctica, taller, actividad institucional, feriado), 4 estados (default, en curso, suspendida, recuperativa), 3 formatos (presencial, online, híbrido) y combinaciones de cambio de sala. Diseñar ese componente de forma que todos los casos fueran legibles sin crear una explosión de variantes fue el desafío técnico más importante del sistema.
Flujos y pantallas diseñadas
Login + estados de error 4 modales de error específicos, estado de loading, modal de ayuda con número de soporte y opción de activar cuenta. | Calendario y horario Vista semanal y mensual, filtros por categoría, detalle de actividad con acceso directo a la asignatura, sincronización con calendarios externos. |
|---|---|
Progreso académico Visualización de créditos por categoría, tooltips explicativos, estados por asignatura y acceso al plan de estudios. | Inscripción de asignaturas Flujo completo con estados diferenciados: inscrita, aprobada, reprobada, complementaria. Manejo de múltiples carreras simultáneas. |
Sistema de solicitudes Mis solicitudes con estados abiertas, cerradas e históricas. Detalle de ticket con timeline de respuesta y opción de replicar solicitud rechazada. | Credencial digital + mantención Credencial con código de barras accesible siempre, incluso durante mantenimiento. Pantalla de mantención con acceso directo sin login. |
Decisiones de diseño clave
La decisión más importante fue cambiar el paradigma de navegación. Pasar del grid de íconos a la bottom navigation no era solo un cambio visual: era una declaración sobre qué importaba. El grid trataba todas las funciones como iguales. La bottom navigation decía: estas cinco cosas son las que un estudiante necesita todos los días. Todo lo demás está, pero no compite por atención con lo crítico.
La segunda decisión fue la credencial accesible durante mantenimiento. Eso no estaba en el brief original. Pero durante el research descubrí que muchos estudiantes usaban la credencial para entrar a la sede. Si la app estaba en mantención y no podían entrar, el problema no era técnico. Era físico. Esa pantalla de mantención con acceso a la credencial fue una de las decisiones más pequeñas del proyecto con mayor impacto real.
El mejor diseño del proyecto fue una pantalla de error. La credencial accesible durante mantenimiento resolvió un problema que nadie había nombrado pero todos habían vivido.
En el design system, la decisión más importante fue diseñar para el equipo que no estaba en la sala. El sistema tenía que ser autónomo: documentado de forma que un diseñador nuevo pudiera entenderlo, un desarrollador pudiera implementarlo y un product manager pudiera tomarlo como referencia sin necesitar que yo se los explicara.
Aprendizajes
Producto y sistema son inseparables No se puede construir un buen sistema sin un producto que lo valide, ni un producto escalable sin un sistema que lo sostenga. Trabajarlos en paralelo fue la decisión correcta aunque fuera la más difícil. | Los casos edge son el diseño real Los alumnos con dos carreras, los colaboradores que intentan entrar, la app en mantención. Esos casos no son la excepción. Son donde el diseño se demuestra o se rompe. |
|---|---|
Liderar sin equipo grande Ser la única product designer exigió mucho criterio sobre qué hacer primero, qué delegar y qué simplificar sin perder calidad. Aprendí a priorizar con más disciplina que nunca. | El sistema diseña para el futuro El design system no era para la app actual. Era para que Duoc UC pudiera lanzar cualquier producto digital nuevo sin empezar desde cero. Eso cambió cómo tomé cada decisión del sistema. |
Más proyectos
UI / UX Design
Vivo Duoc UC: rediseñar una app y construir el sistema que la sostiene
Cómo lideré el rediseño completo de la app de Duoc UC, construí la identidad visual del producto desde cero y desarrollé en paralelo el design system que escalaría a todos los productos digitales del instituto.
Year :
2025
Industry :
Educación superior
Client :
DUOC UC
Rol :
Lead Product Designer
Contexto
Duoc UC es uno de los institutos de educación superior más grandes de Chile, con más de 130.000 estudiantes activos en sedes a lo largo del país. Su app móvil era la herramienta principal con la que los alumnos gestionaban su vida académica, horarios, calificaciones, asistencias, certificados, credencial virtual y mucho más.
El problema era evidente al abrir la app. Había sido construida por desarrolladores sin dirección de diseño, con una interfaz funcional pero sin sistema, sin identidad y sin criterio de experiencia de usuario. Cada pantalla parecía haber sido diseñada de forma independiente. Era una app que hacía lo que tenía que hacer, pero no se sentía como un producto.
En 2024 Duoc UC tomó la decisión de hacer el rediseño completo. La condición era clara, no era solo rediseñar pantallas. Era construir una nueva identidad para el producto digital del instituto y desarrollar en paralelo el design system que serviría de base para la app, para la web y para cualquier producto digital nuevo que Duoc UC lanzara en el futuro.
No era un rediseño. Era construir desde cero el lenguaje visual digital de una institución con 130.000 estudiantes.
La app que teníamos
App anterior | Nueva App VIVO |
|---|---|
Navegación por grid de íconos sin jerarquía. 15 opciones visibles al mismo tiempo sin priorización. | Bottom navigation con 5 secciones principales. Acceso directo a lo más usado. |
Sin sistema de diseño. Cada pantalla usaba colores, tipografía y espaciado diferente. | Design system completo con tokens, componentes y documentación. |
Identidad visual mezclada: azul institucional con amarillo sin cohesión | Nueva identidad púrpura con tipografía y paleta definidas por el equipo de diseño. |
Onboarding inexistente. El usuario entraba sin saber qué podía hacer. | Walkthrough de 3 pasos que contextualiza las funciones principales antes del login. |
Estados de error genéricos. Mensajes técnicos sin contexto ni solución sugerida. | 4 tipos de modales de error con mensajes específicos y acciones concretas. |
Sin bottom navigation. La navegación principal era la misma lista de íconos del home. | Navegación contextual con acceso directo a la asignatura desde el horario. |
Dos proyectos en paralelo
Este proyecto tenía una complejidad particular y es que no se podía diseñar la app sin el sistema, pero el sistema no podía existir sin la app que lo validara. Trabajé los dos en paralelo de forma intencional.
🟣 App Vivo Duoc UC (Producto) | 🟠 Design System (Infraestructura) |
|---|---|
Rediseño completo de la app móvil. Nuevos flujos, nueva identidad, nuevas features y nueva arquitectura de información. El producto que los 130.000 estudiantes usarían todos los días. | Librería de componentes, tokens y documentación construida en paralelo. Diseñada para escalar a la web, productos internos y cualquier nueva herramienta digital que el instituto desarrollara. |
Los desafíos
01 Escala real desde el día uno. La app tenía que funcionar para estudiantes de carreras completamente distintas: una alumna de Comunicación y un estudiante de Ingeniería necesitaban la misma app, pero usaban funciones totalmente diferentes. El diseño tenía que ser flexible sin ser genérico. |
|---|
02 Un solo diseñador de producto liderando todo. Trabajé con un diseñador UI de una empresa externa para la parte visual del sistema, pero las decisiones de arquitectura, flujos, identidad y componentes las lideré yo. Eso exigía un proceso muy ordenado para no perder coherencia. |
03 El design system tenía que ser usable por equipos que no habían participado en su construcción. No servía de nada un sistema que solo yo entendía. La documentación y los criterios de uso tenían que ser autónomos desde el inicio. |
04 Decisiones de identidad sin precedente. Duoc UC no tenía una identidad digital establecida para sus productos. El púrpura, la tipografía, el tono visual y la personalidad de VIVO fueron decisiones del equipo de diseño, no mandatos de marca previos. |
05 Casos de uso complejos. Algunos estudiantes tenían más de una carrera activa simultáneamente. Los flujos de asistencias, cursos, certificados y solicitudes tenían que manejar esa complejidad sin abrumar al usuario promedio que solo tenía una. |
Resultados
+50%Mejora en satisfacción de usuarios post-lanzamiento | −35%Reducción en tiempo de diseño por sprint con el DS |
|---|---|
4xProductos que consumen la librería de componentes | 130kEstudiantes impactados por el rediseño |
Mi proceso
Auditoría y research con usuarios realesEmpecé por mapear todos los flujos de la app existente e identificar los puntos de fricción. Hice entrevistas con estudiantes de distintas carreras y sedes para entender qué usaban más, qué evitaban y qué les faltaba. El hallazgo más importante: los usuarios más frecuentes eran los que tenían clases en el día y necesitaban verificar horario, asistencia y credencial en menos de 30 segundos. Eso definió las prioridades de la navegación principal. |
|---|
Definición de identidad y dirección creativaCon el equipo definí la identidad visual de VIVO. La decisión del púrpura fue intencional: queríamos romper con el azul institucional pesado que asociaba la app con trámites y burocracia. El púrpura daba energía juvenil sin perder seriedad académica. Definí la paleta completa, la tipografía, el tono visual y los principios de diseño que guiarían todas las decisiones posteriores. |
Arquitectura de información y nueva navegaciónRediseñé la arquitectura completa. El grid de 15 íconos se reemplazó por una bottom navigation de 5 tabs: Inicio, Horario, Solicitudes, Notificaciones y Perfil. Las funciones menos frecuentes se organizaron dentro de cada sección de forma contextual. Ese cambio fue la decisión estructural más importante del proyecto: poner lo crítico al alcance del pulgar sin eliminar las funciones secundarias. |
Construcción del Design System en paraleloMientras diseñaba los flujos de la app, construí el sistema de diseño. Empecé por los tokens: color, tipografía, espaciado, radio de bordes y sombras. Después los componentes atómicos: botones, inputs, cards, badges, modales. Luego los patrones: cómo se combinan esos componentes para resolver problemas concretos como un formulario de solicitud o una card de actividad con múltiples estados. El diseñador UI externo ejecutó el sistema visual bajo mis criterios. |
Diseño de flujos complejosDiseñé los flujos más complejos de la app: el progreso académico con visualización de créditos por categoría, la inscripción de asignaturas con estados diferenciados (inscrita, aprobada, reprobada, complementaria), el sistema de solicitudes con seguimiento de tickets y el calendario integrado con sincronización a Google Calendar y calendario nativo. Cada flujo tenía que manejar casos de alumnos con múltiples carreras activas sin romper la experiencia del caso estándar. |
Estados de error y casos edgeDediqué tiempo específico a los estados de error. La app anterior tenía un solo modal de error genérico para todo. Diseñé cuatro tipos distintos, error genérico, perfil de colaborador no soportado, carrera online no disponible y alumno eliminado del sistema. Cada uno tenía un mensaje específico, una acción concreta y un tono diferente según la gravedad. Eso redujo la fricción en los casos de acceso problemático que antes llegaban al soporte sin contexto. |
Walkthrough y onboardingDiseñé un walkthrough de 3 pantallas que aparece la primera vez que el usuario abre la app. No era un tutorial genérico: cada pantalla comunicaba una propuesta de valor concreta: sigue tu progreso académico, gestiona tu tiempo, todo en un solo lugar. También diseñé el estado de mantenimiento con acceso directo a la credencial digital, para que incluso cuando la app estuviera en mantención, los estudiantes pudieran acceder a su carnet virtual. |
El design system
El design system no era un proyecto separado: era la infraestructura que haría que la app fuera mantenible y escalable. Lo construí con una lógica de tres capas.
01 Tokens | 02 Componentes | 03 Patrones |
|---|---|---|
Color, tipografía, espaciado, radio y sombras. Los valores primitivos del sistema con nombres semánticos. | Botones, inputs, cards, badges, modales, navegación. Cada uno con variantes de estado documentadas. | Combinaciones de componentes para resolver flujos completos: solicitudes, calendarios, formularios, listas académicas. |
La Card de Actividad fue uno de los componentes más complejos del sistema. Tenía que funcionar para 5 tipos de actividad (clase teórica, práctica, taller, actividad institucional, feriado), 4 estados (default, en curso, suspendida, recuperativa), 3 formatos (presencial, online, híbrido) y combinaciones de cambio de sala. Diseñar ese componente de forma que todos los casos fueran legibles sin crear una explosión de variantes fue el desafío técnico más importante del sistema.
Flujos y pantallas diseñadas
Login + estados de error 4 modales de error específicos, estado de loading, modal de ayuda con número de soporte y opción de activar cuenta. | Calendario y horario Vista semanal y mensual, filtros por categoría, detalle de actividad con acceso directo a la asignatura, sincronización con calendarios externos. |
|---|---|
Progreso académico Visualización de créditos por categoría, tooltips explicativos, estados por asignatura y acceso al plan de estudios. | Inscripción de asignaturas Flujo completo con estados diferenciados: inscrita, aprobada, reprobada, complementaria. Manejo de múltiples carreras simultáneas. |
Sistema de solicitudes Mis solicitudes con estados abiertas, cerradas e históricas. Detalle de ticket con timeline de respuesta y opción de replicar solicitud rechazada. | Credencial digital + mantención Credencial con código de barras accesible siempre, incluso durante mantenimiento. Pantalla de mantención con acceso directo sin login. |
Decisiones de diseño clave
La decisión más importante fue cambiar el paradigma de navegación. Pasar del grid de íconos a la bottom navigation no era solo un cambio visual: era una declaración sobre qué importaba. El grid trataba todas las funciones como iguales. La bottom navigation decía: estas cinco cosas son las que un estudiante necesita todos los días. Todo lo demás está, pero no compite por atención con lo crítico.
La segunda decisión fue la credencial accesible durante mantenimiento. Eso no estaba en el brief original. Pero durante el research descubrí que muchos estudiantes usaban la credencial para entrar a la sede. Si la app estaba en mantención y no podían entrar, el problema no era técnico. Era físico. Esa pantalla de mantención con acceso a la credencial fue una de las decisiones más pequeñas del proyecto con mayor impacto real.
El mejor diseño del proyecto fue una pantalla de error. La credencial accesible durante mantenimiento resolvió un problema que nadie había nombrado pero todos habían vivido.
En el design system, la decisión más importante fue diseñar para el equipo que no estaba en la sala. El sistema tenía que ser autónomo: documentado de forma que un diseñador nuevo pudiera entenderlo, un desarrollador pudiera implementarlo y un product manager pudiera tomarlo como referencia sin necesitar que yo se los explicara.
Aprendizajes
Producto y sistema son inseparables No se puede construir un buen sistema sin un producto que lo valide, ni un producto escalable sin un sistema que lo sostenga. Trabajarlos en paralelo fue la decisión correcta aunque fuera la más difícil. | Los casos edge son el diseño real Los alumnos con dos carreras, los colaboradores que intentan entrar, la app en mantención. Esos casos no son la excepción. Son donde el diseño se demuestra o se rompe. |
|---|---|
Liderar sin equipo grande Ser la única product designer exigió mucho criterio sobre qué hacer primero, qué delegar y qué simplificar sin perder calidad. Aprendí a priorizar con más disciplina que nunca. | El sistema diseña para el futuro El design system no era para la app actual. Era para que Duoc UC pudiera lanzar cualquier producto digital nuevo sin empezar desde cero. Eso cambió cómo tomé cada decisión del sistema. |