Wellcam.fit

Soluzione

WWG ha strutturato il progetto in quattro fasi: configurazione dell'ambiente e revisione delle API, sviluppo del modulo principale, controllo qualità e implementazione, con sprint Scrum di due settimane per garantire tempi di consegna prevedibili e un'elevata visibilità per il cliente durante tutto il processo.

L'applicazione è stata realizzata attorno a due esperienze distinte e autenticate, che condividono un codice sorgente comune. Gli account dei formatori accedono alla creazione e alla gestione delle lezioni, alla visualizzazione dell'agenda settimanale, alla gestione delle richieste dei clienti e al monitoraggio dei guadagni tramite un'interfaccia di portafoglio. Gli account dei clienti accedono alla ricerca dei formatori, a un catalogo dei corsi con funzionalità di filtro e lista dei desideri, a un flusso di prenotazione e alla cronologia delle sessioni personali. Il routing e le autorizzazioni basati sui ruoli garantiscono la separazione sia a livello di interfaccia che di API.

Il sistema di prenotazione è stato uno dei moduli tecnicamente più complessi del progetto. I clienti possono prenotare lezioni individuali o sessioni di gruppo ricorrenti, selezionando frequenza e durata. Il backend genera automaticamente istanze di lezioni ricorrenti fino a 12 mesi in anticipo, verificando la disponibilità del docente per ogni fascia oraria prima della creazione. Il pagamento viene gestito tramite un meccanismo di blocco del portafoglio: i fondi vengono riservati al momento della prenotazione e rilasciati al docente al termine della sessione, con Stripe che gestisce le ricariche e Zustand che gestisce lo stato del carrello e del portafoglio sul frontend. Miglioramenti UX post-demo

A seguito di una demo interna del prodotto, WWG ha identificato e proposto una serie di miglioramenti UX che sono stati integrati prima della consegna finale. Tra le migliorie apportate figurano la visualizzazione delle date esatte di prenotazione nel calendario anziché la selezione astratta del giorno della settimana, la visualizzazione delle fasce orarie disponibili dei formatori direttamente nell'interfaccia di prenotazione, la visualizzazione del saldo attuale del portafoglio all'interno del carrello, l'aggiunta di una sezione con la cronologia delle lezioni alla visualizzazione del portafoglio e l'estensione dell'agenda con la navigazione settimana per settimana. Ciascun miglioramento ha risolto una reale lacuna di usabilità identificata durante la fase di test.

Le conferme di prenotazione e i promemoria delle sessioni vengono inviati tramite AWS Pinpoint (SMS) ed e-mail, utilizzando modelli gestiti nel backend. La logica di notifica verifica le restrizioni della sandbox e i limiti di utilizzo, con un sistema di registrazione degli errori per individuare eventuali problemi di consegna durante il controllo qualità.

Il backend di Bagisto è stato creato come framework di e-commerce generico. Concetti come finestre di disponibilità degli istruttori, generazione di lezioni ricorrenti, rilevamento dei conflitti a livello di slot e cicli di blocco e sblocco del portafoglio non sono presenti nativamente in un modello di carrello acquisti. Colmare questa lacuna ha richiesto una stretta collaborazione tra il team frontend e backend, un ampio lavoro di mappatura delle API e una logica personalizzata su entrambi i lati, inclusa la creazione di un generatore di lezioni ricorrenti che crea istanze fino a 12 mesi in anticipo, rispettando le prenotazioni esistenti.

Anziché addebitare al momento della prenotazione, Wellcam.fit utilizza un modello di blocco dei fondi: quando un cliente prenota una sessione, il costo viene bloccato dal saldo del suo portafoglio e trattenuto fino allo svolgimento della lezione. Solo allora i fondi vengono rilasciati all'allenatore. Ciò ha richiesto l'implementazione di un ciclo di vita della transazione a più stati — blocco, trattenuta, rilascio e trasferimento — con Stripe che gestisce le ricariche e il backend che applica i controlli di sufficienza del saldo prima che qualsiasi prenotazione venga confermata.

Le specifiche di progettazione per tutte e tre le superfici della piattaforma non erano state definite completamente all'inizio dello sviluppo. Il team ha lavorato con le informazioni disponibili, ha segnalato sistematicamente le lacune attraverso un processo strutturato di domande e risposte con il cliente e ha preso decisioni pragmatiche — optando per la più semplice tra due interpretazioni di progettazione ambigue e segnalando le decisioni per la revisione del cliente — per rispettare le scadenze ed evitare di accumulare rilavorazioni.