Caso de producto / Plataforma de gestión de escuelas
ClassWolf
Que la escuela avance sin perder su historia.
Un espacio conectado para escuelas con clases recurrentes. Cursos, asistencias, bonos y cobros se reúnen en una interfaz que ayuda al equipo a entender el día y conservar una historia operativa fiable.
- Nuestra contribución
- Estrategia de producto, UX/UI, marca y desarrollo
- Enfoque del proyecto
- Sitio público y producto de gestión escolar con distintos roles
01 / El reto
Detrás de cada clase, un ecosistema operativo
Una escuela es más que un calendario: es la relación entre un curso, una sala, un profesor, las personas que asisten y los pagos que lo sostienen. ClassWolf hace explícitas esas relaciones. Pensado para actividades como danza, yoga y música, conecta el trabajo diario de recepción con la historia de la escuela.
El reto era hacer manejables las operaciones relacionadas: horarios recurrentes, aforo, profesores, asistencias, bonos y cobros. Además, el sistema debe conservar el historial cuando cambian personas o cursos, sin ralentizar las tareas diarias ni mostrar complejidad innecesaria a cada rol.
Las decisiones detrás de la experiencia
Empezar por el día y abrir el detalle
El panel reúne próximas sesiones, pagos pendientes y accesos prácticos. Las listas mantienen una estructura coherente para pasar de una señal al registro correspondiente. La interfaz prioriza lo que necesita atención antes de pedir interpretar un informe.
Diseñar la recurrencia con sus restricciones reales
Un curso conecta profesores, sala, horarios e inscripciones. En baile de pareja importa el aforo por líder y seguidor; en otras actividades esa distinción puede quedar fuera del flujo. La configuración por actividad muestra las reglas específicas donde aportan valor.
Hacer comprensibles los bonos
Los bonos conectan compra, clases restantes, caducidad y asignación al profesor. Estados claros distinguen un bono activo de uno agotado o caducado. Reunir estos datos permite explicar el saldo sin reconstruirlo entre hojas de cálculo.
Mantener la continuidad cuando cambian las personas
Los profesores pueden desactivarse conservando su relación con clases y registros históricos. Los permisos distinguen responsabilidades y los informes mantienen el vínculo con las operaciones. La memoria de la escuela forma parte del producto y acompaña los cambios de la organización.
02 / Personas e investigación
Diseñar en torno a las necesidades
Proto-personas ilustrativas, basadas en los roles y flujos del producto. Describen hipótesis de diseño, no participantes entrevistados.
Quien dirige la escuela
Proto-persona ilustrativa · operaciones y continuidad
- Necesidad
- Entender las prioridades del día y conectar cursos, cobros e historial.
- Fricción
- Una duda sobre asistencia o pagos obliga a consultar registros separados.
- Respuesta de diseño
- Resumen compartido y registros conectados de cursos, alumnos y cobros.
El profesor entre clases
Proto-persona ilustrativa · clases y asistencias
- Necesidad
- Encontrar la siguiente sesión, marcar asistencia y consultar la información necesaria.
- Fricción
- Poco tiempo entre clases y pantallas que exigen demasiado contexto de gestión.
- Respuesta de diseño
- Contexto claro de sesión, asistencia centrada en la tarea y acceso según el rol.
Preguntas de investigación y validación
Este marco de investigación reconstruido parte de las relaciones operativas de los requisitos. La dirección necesita conectar cursos y cobros; los profesores, centrarse en la sesión; los alumnos, entender su inscripción. Un bono añade dependencias entre compra, asistencia, caducidad y asignación al profesor. Conservar el historial cuando se marcha un docente es una necesidad explícita de la discovery. Las preguntas propuestas exploran cómo se concilian hoy estos registros y qué información permite actuar con claridad en recepción o entre clases.
Una reconstrucción editorial del razonamiento de diseño. Las preguntas de entrevista y los escenarios de usabilidad son una guía de validación; no se presentan como trabajo de campo realizado ni resultados medidos.
Guía de entrevistas
- Hipótesis: una visión común evita reconstruir información. Pregunta: ¿cómo respondes hoy a una duda sobre una clase sin pagar?
- A responsables: ¿qué información debe conservarse cuando se marcha un profesor o termina un curso?
- A profesores: ¿qué necesitas ver en el móvil justo antes y después de una clase?
- Hipótesis: los saldos explícitos facilitan explicar bonos. Pregunta: ¿qué situaciones con bonos generan más dudas?
Escenarios de pruebas de usabilidad
- Crear un curso recurrente y revisar profesor, sala e inscripciones antes de confirmar.
- Encontrar un bono y explicar clases restantes, caducidad y estado con datos de demostración.
- Encontrar la siguiente sesión y marcar asistencia en pantalla pequeña con rol de profesor.
- Comprobar teclado, estados y permisos, incluido el historial de un profesor desactivado.
03 / Customer journey
Customer journey
Un recorrido representativo reconstruido a partir del producto, que conecta cada necesidad con una decisión de interfaz.
| Etapa | Acción de la persona | Fricción | Respuesta de diseño |
|---|---|---|---|
| Planificar | Configurar un curso recurrente | Profesores, salas y aforo deben encajar | Un modelo conectado con horarios y aforo visibles |
| Inscribir | Vincular al alumno con un curso | Los datos y la inscripción están separados | Registros conectados de alumno y curso |
| Asistir | Consultar la sesión y marcar asistencia | Poco tiempo al empezar la clase | Una tarea de asistencia centrada en la sesión |
| Cobrar | Revisar el cobro y las clases restantes | Se confunden caducidad, clases y estado de pago | Saldos, fechas y estados de bono explícitos |
| Revisar | Entender la actividad y conservar el contexto histórico | Los cambios de equipo rompen la memoria de la escuela | Informes y relaciones históricas conservadas |
01Planificar
- Acción de la persona
- Configurar un curso recurrente
- Fricción
- Profesores, salas y aforo deben encajar
- Respuesta de diseño
- Un modelo conectado con horarios y aforo visibles
02Inscribir
- Acción de la persona
- Vincular al alumno con un curso
- Fricción
- Los datos y la inscripción están separados
- Respuesta de diseño
- Registros conectados de alumno y curso
03Asistir
- Acción de la persona
- Consultar la sesión y marcar asistencia
- Fricción
- Poco tiempo al empezar la clase
- Respuesta de diseño
- Una tarea de asistencia centrada en la sesión
04Cobrar
- Acción de la persona
- Revisar el cobro y las clases restantes
- Fricción
- Se confunden caducidad, clases y estado de pago
- Respuesta de diseño
- Saldos, fechas y estados de bono explícitos
05Revisar
- Acción de la persona
- Entender la actividad y conservar el contexto histórico
- Fricción
- Los cambios de equipo rompen la memoria de la escuela
- Respuesta de diseño
- Informes y relaciones históricas conservadas
04 / Wireframing
De la estructura a la interfaz
Wireframes de baja fidelidad reconstruidos para este caso. Explican la jerarquía y el flujo, sin reproducir archivos originales del proyecto.
05 / UI y diseño visual
Sitios públicos y bocetos de diseño
Los pies de imagen distinguen capturas de sitios públicos y bocetos de plataformas generados con IA. Abre una imagen para ver sus detalles.
Lo que permite el diseño
ClassWolf conecta personas, clases y registros de la escuela. Las decisiones de diseño mantienen visibles las prioridades, los saldos de los bonos y el contexto histórico. Las imágenes en color son bocetos conceptuales generados con IA para explicar estas ideas.
