Caso studio di prodotto / Piattaforma di gestione scuole
ClassWolf
Far crescere la scuola, custodire la sua storia.
Uno spazio di lavoro connesso per scuole e attività a lezioni ricorrenti. Corsi, presenze, abbonamenti e pagamenti si incontrano in un'interfaccia che aiuta lo staff a leggere la giornata e conservare una storia operativa affidabile.
- Il nostro contributo
- Strategia di prodotto, UX/UI, brand e sviluppo
- Focus del progetto
- Sito pubblico e gestionale scolastico con ruoli distinti
01 / La sfida
Dietro ogni lezione, un ecosistema operativo
Una scuola è più di un calendario. È la relazione fra un corso, una sala, un docente, le persone presenti e i pagamenti che lo sostengono. ClassWolf rende esplicite queste relazioni. Pensato per attività ricorrenti come danza, yoga e musica, collega il lavoro quotidiano della segreteria alla storia della scuola.
La sfida era rendere gestibili operazioni interdipendenti: ricorrenze, capienza delle sale, docenti, presenze, ingressi prepagati e pagamenti. Il sistema deve anche conservare i dati storici quando cambiano persone o corsi, senza appesantire le attività quotidiane o mostrare a ogni ruolo complessità superflua.
Le scelte dietro l’esperienza
Partire dalla giornata, poi entrare nel dettaglio
La dashboard riunisce lezioni in arrivo, pagamenti da seguire e scorciatoie operative. Gli elenchi mantengono una struttura coerente per passare da un segnale alla scheda pertinente. L'interfaccia mette in primo piano ciò che richiede attenzione prima di chiedere di interpretare un report.
Progettare le ricorrenze intorno ai vincoli reali
Un corso collega docenti, sala, orari e iscrizioni. Nella danza di coppia conta la disponibilità per leader e follower; in altre attività questa distinzione può rimanere fuori dal flusso. Le configurazioni per settore rendono disponibili le regole specifiche dove servono.
Rendere leggibili gli abbonamenti a ingressi
Gli abbonamenti collegano acquisto, ingressi residui, scadenza e attribuzione ai docenti. Stati leggibili distinguono un pacchetto attivo da uno esaurito o scaduto. Riunire questi dati aiuta la segreteria a spiegare un saldo senza ricostruirlo fra fogli separati.
Conservare continuità quando cambiano le persone
I docenti possono essere disattivati mantenendo il collegamento con lezioni e dati storici. I permessi distinguono le responsabilità dello staff e i report restano collegati alle operazioni. La memoria della scuola è parte del prodotto e accompagna i cambiamenti dell'organizzazione.
02 / Persone e ricerca
Progettare intorno ai bisogni
Proto-personas illustrative, ricavate dai ruoli e dai flussi del prodotto. Descrivono ipotesi progettuali, non persone intervistate.
Chi gestisce la scuola
Proto-persona illustrativa · operatività e continuità
- Bisogno
- Capire le priorità della giornata e collegare corsi, pagamenti e storico.
- Ostacolo
- Una domanda su presenze o pagamenti richiede di consultare archivi separati.
- Risposta progettuale
- Panoramica condivisa e schede collegate di corsi, studenti e pagamenti.
Il docente fra una lezione e l'altra
Proto-persona illustrativa · lezioni e presenze
- Bisogno
- Trovare la prossima lezione, segnare le presenze e leggere le informazioni utili.
- Ostacolo
- Poco tempo fra le lezioni e schermate che richiedono troppo contesto gestionale.
- Risposta progettuale
- Contesto della lezione chiaro, presenze mirate e accesso adeguato al ruolo.
Domande di ricerca e validazione
Questo framework di ricerca ricostruito parte dalle relazioni operative descritte nei requisiti. Chi gestisce deve leggere insieme corsi e pagamenti; i docenti devono concentrarsi sulla lezione; gli studenti devono capire l'iscrizione. Un pacchetto di ingressi aggiunge dipendenze fra acquisto, presenze, scadenza e attribuzione al docente. Conservare lo storico quando un insegnante lascia la scuola è un bisogno esplicito della discovery. Le domande proposte esplorano come vengono riconciliati oggi questi dati e quali informazioni servono per agire con chiarezza in segreteria o fra le lezioni.
Una ricostruzione editoriale del ragionamento progettuale. Le domande d’intervista e gli scenari di usability testing sono una traccia di validazione: non vengono presentati come ricerca sul campo già svolta o risultati misurati.
Traccia per le interviste
- Ipotesi: una panoramica unica riduce le ricostruzioni. Domanda: come rispondi oggi a una domanda su una lezione non pagata?
- A chi gestisce: quali informazioni devono restare disponibili quando un docente va via o un corso termina?
- Ai docenti: cosa devi vedere sul telefono subito prima e dopo una lezione?
- Ipotesi: saldi espliciti aiutano a spiegare i pacchetti. Domanda: quali situazioni sugli abbonamenti generano più domande?
Scenari di usability testing
- Creare un corso ricorrente e verificare docente, sala e contesto iscrizioni prima della conferma.
- Trovare un pacchetto e spiegarne ingressi residui, scadenza e stato usando dati dimostrativi.
- Trovare la prossima lezione e segnare le presenze su schermo piccolo con il ruolo docente.
- Verificare tastiera, etichette di stato e permessi, compreso lo storico di un docente disattivato.
03 / Customer journey
Customer journey
Un percorso rappresentativo ricostruito dai flussi del prodotto, che collega ogni bisogno a una scelta d’interfaccia.
| Fase | Azione della persona | Ostacolo | Risposta progettuale |
|---|---|---|---|
| Pianificare | Impostare un corso ricorrente | Docenti, sale e capienza devono combaciare | Un modello connesso con orari e capienza visibili |
| Iscrivere | Collegare lo studente al corso | Dati e iscrizioni si trovano in posti separati | Schede studente e corso collegate |
| Partecipare | Verificare la lezione e registrare le presenze | Poco tempo all'inizio della lezione | Un'azione presenze centrata sulla lezione |
| Incassare | Verificare pagamento e ingressi residui | Scadenza, ingressi e stato del pagamento si confondono | Saldi, date e stati dei pacchetti espliciti |
| Rileggere | Leggere l'attività e conservare il contesto storico | I cambi di staff interrompono la memoria della scuola | Report e collegamenti storici conservati |
01Pianificare
- Azione della persona
- Impostare un corso ricorrente
- Ostacolo
- Docenti, sale e capienza devono combaciare
- Risposta progettuale
- Un modello connesso con orari e capienza visibili
02Iscrivere
- Azione della persona
- Collegare lo studente al corso
- Ostacolo
- Dati e iscrizioni si trovano in posti separati
- Risposta progettuale
- Schede studente e corso collegate
03Partecipare
- Azione della persona
- Verificare la lezione e registrare le presenze
- Ostacolo
- Poco tempo all'inizio della lezione
- Risposta progettuale
- Un'azione presenze centrata sulla lezione
04Incassare
- Azione della persona
- Verificare pagamento e ingressi residui
- Ostacolo
- Scadenza, ingressi e stato del pagamento si confondono
- Risposta progettuale
- Saldi, date e stati dei pacchetti espliciti
05Rileggere
- Azione della persona
- Leggere l'attività e conservare il contesto storico
- Ostacolo
- I cambi di staff interrompono la memoria della scuola
- Risposta progettuale
- Report e collegamenti storici conservati
04 / Wireframing
Dalla struttura all’interfaccia
Wireframe a bassa fedeltà ricostruiti per questo caso studio. Spiegano gerarchia delle informazioni e flusso, senza riprodurre file originali di progetto.
05 / UI e design visivo
Siti pubblici e bozze di design
Le didascalie distinguono catture di siti pubblici e bozze di piattaforma generate con AI. Apri un’immagine per osservarla nel dettaglio.
Cosa rende possibile il design
ClassWolf collega persone, lezioni e dati della scuola. Le scelte di progetto mantengono visibili priorità quotidiane, saldo degli ingressi e contesto storico. Le immagini a colori sono bozze concettuali generate con AI per illustrare queste idee.
