SuiteFit
Una piattaforma dove personal trainer e nutrizionista lavorano sullo stesso cliente, e il cliente li vede tutti e due da un accesso solo.
01 Problema
Da dove nasce
Chi segue un percorso serio in palestra spesso ha due professionisti: il personal trainer per l'allenamento, il nutrizionista per la dieta. I due non parlano quasi mai fra loro, e il cliente diventa il postino: riceve un PDF dall'uno, un foglio dall'altro, e se cambia qualcosa deve dirlo due volte.
Dall'altra parte, il professionista tiene i clienti su un misto di WhatsApp, Excel e memoria. Le scadenze dei rinnovi sono la prima cosa che si perde, perché non esistono da nessuna parte se non nella testa di chi le ha promesse.
Il modello dei dati è la parte difficile. Un cliente può avere un trainer, un nutrizionista, entrambi o nessuno. I due professionisti devono vedere il cliente ma non il lavoro dell'altro, mentre il cliente deve vedere tutto in un posto solo. Un unico rapporto "professionista-cliente" non regge: appena ne aggiungi un secondo tipo, i permessi diventano una serie di eccezioni.
Poi c'è il problema noioso e obbligatorio: qui dentro finiscono dati sulla salute delle persone. Peso, misure, piani alimentari. Non è materiale su cui si può improvvisare la cancellazione dell'account.
02 Ricerca
La strada che ho scartato
La tentazione era fare un rapporto solo, chiamarlo "professionista-cliente" e metterci dentro un campo tipo. Ci ho provato, e il codice si è riempito di `if` sul tipo sparsi ovunque: nei permessi, nelle notifiche, nelle query. Ogni funzione nuova doveva ricordarsi di controllare.
03 UX / UI
La direzione scelta, e perché quella
Il cliente ha una sola schermata che unisce le due parti: la scheda di allenamento e il piano alimentare stanno vicini perché è così che vive la sua settimana, non divisi per chi glieli ha dati.
Sulla cancellazione dei dati non ho improvvisato: cancellazione morbida con finestra di ripensamento, un processo pianificato che rimuove davvero quello che è scaduto, registro dei consensi separato. È la parte che non si vede in nessuna schermata ed è quella che ho riscritto più volte.
04 Codice
Come è fatto dentro
Ho tenuto due rapporti separati invece di uno generico — trainer-cliente e nutrizionista-cliente sono tabelle distinte, ognuna con il suo stato. I permessi diventano una domanda semplice a cui si può rispondere sempre, e aggiungere un terzo tipo di professionista domani non richiede di riscrivere quelli esistenti.
- PHP
- MySQL
- JavaScript
- HTML5
- CSS3
05 Risultati
Cosa è cambiato
-
Quattro ruoli, un accesso a testa
Cliente, personal trainer, nutrizionista e amministratore. Ognuno entra dallo stesso punto e vede solo la sua parte.
-
Il cliente vede entrambi i professionisti
Scheda di allenamento e piano alimentare nella stessa pagina, anche se arrivano da due persone che non si sono mai parlate.
-
Scadenze e rinnovi
Da incassare, incassato, scaduto. È la funzione che risolve il problema più concreto del professionista, cioè accorgersi che un abbonamento è finito prima che finisca.
-
Costruttore di schede e libreria esercizi
Composizione della scheda per trascinamento, con una libreria di esercizi ricercabile e modelli riutilizzabili.
-
Dati sanitari trattati come tali
Cancellazione morbida con recupero, pulizia pianificata dei dati scaduti, registro dei consensi, limite ai tentativi di accesso.
-
Cosa manca
È in beta e i dati che si vedono sono di prova — nessun professionista vero la sta ancora usando con clienti veri. Interfaccia e alcune funzioni sono da rifinire. Non ci sono numeri di utilizzo perché non c'è ancora utilizzo.
In prima persona
Due tabelle separate sembrano più lavoro e ne fanno di meno. La domanda “questo nutrizionista può vedere questo cliente?” ha una risposta sola, in un posto solo, e non cambia quando aggiungo qualcosa altrove.