Erika Romera
EL PROBLEMA
La burocracia no debería dar clase.
El profesorado dedica tiempo a registrar, recopilar y reportar información que ya existe en su trabajo diario. Mientras tanto, la coordinación se entera tarde y a través de revisiones manuales. Los productos existentes suelen ser cuadernos ágiles sin jerarquía o ERPs escolares pesados. El hueco está entre ambos: una herramienta que el profesorado quiera usar y que permita coordinar con permisos reales.
CÓMO FUNCIONA
Un producto para el centro, no otra tarea para el profesor.
Flavio es un SaaS B2B: el centro lo contrata y lo habilita para sus equipos. El valor no está en acumular funciones, sino en reducir el trabajo manual del profesorado y coordinación además de proteger el acceso a información sensible.
GESTIONA
Profesorado
Trabaja con varias asignaturas y grupos desde su actividad cotidiana: notas, asistencia, tareas, incidencias.
CONSULTA
Coordinación
Ve el progreso de su departamento sin solicitar informes individuales.
SUPERVISA
Dirección
Accede a la información que corresponde a su alcance operativo y de seguridad.
EL PROCESO
Del problema documentado a un sistema comprobable.
El trabajo no empezó diseñando pantallas. Empezó entendiendo qué debía resolver Flavio, qué información podía circular y cómo demostrar que el sistema respetaba sus propios límites.
01
Investigar el problema
La investigación combinó fuentes sindicales, comparativa de producto y foros del sector. El objetivo no era hacer una lista de funciones, sino entender por qué el profesorado acaba haciendo trabajo administrativo adicional y por qué la coordinación depende de reuniones e informes manuales.
Salida: una oportunidad estructural.
02
Modelar roles y permisos
Se definieron tres perfiles y se estableció qué puede consultar cada uno. La unidad de trabajo se modeló como asignatura + grupo, porque un profesor puede impartir varias asignaturas a varios grupos.
Salida: un modelo granular de acceso, con mínimo privilegio.
03
Diseñar el sistema
El sistema se organizó alrededor del cuaderno del aula. Esa actividad genera la información que consulta coordinación, sin crear un flujo paralelo de informes. Botones, campos, tablas, diálogos y tarjetas están documentados en un design system y se repiten de forma idéntica en los tres roles de la app —aula, coordinación y dirección—, para que cambiar de perfil no sea aprender una interfaz nueva.
Salida: una propuesta de valor clara — coordinar sin pedir.
04
Prototipar el producto
A partir del modelo de datos, los roles y las reglas de autorización, se construyó una demo funcional de Flavio con Claude Code.
Salida: demo funcional basada en 3 roles.
05
Comprobar lo invisible
Se probaron tanto los permisos que deben funcionar como los accesos que deben fallar. También contraste, foco visible, responsive y consistencia del sistema.
Salida: 613 pruebas de autorización (pgTAP) y 815 pruebas de cliente.
DECISIONES CLAVE
El cliente no puede concederse acceso.
Flavio no se organizó a partir de una lista de funcionalidades, sino de unas pocas decisiones estructurales. Todas parten de una pregunta: ¿cómo puede coordinar un centro sin conceder más acceso del necesario?
01
La unidad de trabajo es asignatura + grupo
Un profesor puede impartir varias asignaturas y trabajar con distintos grupos. Modelar la relación como "un profesor, un grupo" habría sido demasiado simple y habría impedido definir los permisos con precisión.
02
Coordinación tiene alcance de departamento
Una persona responsable de un departamento no puede consultar automáticamente toda la información del centro. Su alcance queda limitado a lo que necesita para hacer seguimiento.
03
La información sensible tiene una política propia
La información médica, alergias, medicación y observaciones psicológicas no heredan automáticamente los permisos del resto de la ficha del alumno.
LÍMITE Y ALCANCE
Un prototipo honesto, con límites explícitos.
Delimitar qué no se construye protege la calidad de lo que sí se construye. Esto se dejó fuera, deliberadamente:
Login de familias
IA (simulada, no real)
Matricualaciones
Boletines oficiales
Facturación
Mi alcance como diseñadora de producto termina donde la seguridad básica (roles, permisos, autenticación) está bien resuelta y demostrada. Cifrado avanzado, cumplimiento normativo e infraestructura de producción son territorio de un equipo técnico especializado — y ese es precisamente el punto: saber señalar la frontera es parte del oficio.
LA INTERFAZ
RESULTADOS
Un sistema que se comprueba solo.
No es una maqueta navegable: es una aplicación con modelo de datos, autorización y suite de pruebas, desplegada como demo pública con datos ficticios.
La interfaz se revisó también fuera de la pantalla de escritorio: en el móvil y la tablet, en tamaño pequeño y grande, siempre contra la versión real publicada. Se hizo además una auditoría de accesibilidad que comprobó el contraste de color, que el foco se vea con claridad al navegar con teclado, que los botones sean lo bastante grandes para tocarlos con el dedo, que la aplicación respete cuando alguien pide menos movimiento en pantalla, y que las casillas se vean y funcionen como se espera. Y todo eso queda vigilado por pruebas automáticas que comprueban, en cada nueva versión, que el foco, el contraste y cada botón siguen funcionando bien.
LO QUE APRENDÍ
Diseñar productos, no solo pantallas.
La intuición orienta, pero la evidencia decide
El contraste, el foco, los desbordamientos y los permisos no siempre se perciben a simple vista. Las decisiones de diseño necesitan apoyarse en mediciones y casos concretos, no solo en criterio visual.
La arquitectura del producto también es experiencia de usuario
Si el modelo de datos y la lógica de permisos se definen tarde, la interfaz acaba ocultando contradicciones que deberían haberse resuelto antes.
El alcance es una herramienta de diseño
Delimitar funciones, usuarios y escenarios permite concentrar el esfuerzo en el problema principal y evita que las partes incompletas se interpreten como promesas del producto.