Caso studio di prodotto / Nautica · Ecosistema SaaS
SupaSailing & SupaMaritime
Un mondo marittimo. Uno spazio di lavoro per ogni ruolo.
Dalla sala macchine di uno yacht all'ufficio di un marina e a un'agenzia portuale: una famiglia di prodotti digitali che rende più leggibili operazioni complesse, con due brand distinti e un approccio coerente al lavoro quotidiano.
- Il nostro contributo
- Strategia UX, product design e sviluppo web
- Focus del progetto
- Architettura di brand · Navigazione per ruolo · Interfacce operative · Siti responsive
01 / La sfida
Progettare le connessioni dietro ogni navigazione
Il lavoro marittimo raramente avviene a una sola scrivania. Comandanti, tecnici, team dei marina, operatori charter e agenti portuali lavorano sulla stessa imbarcazione da prospettive molto diverse. Il progetto traduce questa complessità in una famiglia leggibile: SupaSailing serve la nautica da diporto con Fleet, Charter, Marina, Broker, Shipyard e Guild; SupaMaritime si rivolge alle operazioni commerciali con Agent, Ferry, Merchant e Guild, affiancati da un'offerta separata per la biglietteria traghetti. Il sito chiarisce questa struttura prima di chiedere al visitatore di scegliere un prodotto. Nell'ecosistema, il focus passa dal raccontare le funzionalità all'aiutare ogni ruolo a capire cosa richiede attenzione e quale azione compiere.
La sfida principale non è il numero di funzioni, ma quello dei contesti. Un responsabile marina ragiona per posti barca e arrivi; un tecnico per impianti e manutenzioni; un agente per scali e documenti. Una dashboard generica nasconderebbe queste differenze. Allo stesso tempo, prodotti distinti richiedono schemi familiari per stati, schede, permessi e conferme, mentre la navigazione pubblica deve rendere comprensibile la distinzione fra diporto e commerciale.
Le scelte dietro l’esperienza
Partire dal ruolo, poi mostrare il modulo
Le pagine per ruolo traducono il catalogo in situazioni di lavoro: chief engineer, responsabile marina, operatore charter e titolare di cantiere. Ogni pagina collega una responsabilità riconoscibile al modulo pertinente. I nomi dei prodotti restano visibili, ma la prima domanda diventa «Cosa devi gestire?» invece di richiedere conoscenza del catalogo.
Due brand riconoscibili, una famiglia coerente
SupaSailing e SupaMaritime parlano a mercati diversi: i siti mantengono quindi una distinzione chiara fra yachting e trasporto marittimo commerciale. Convenzioni di navigazione, colori dei moduli e strutture di pagina comparabili creano continuità. I collegamenti fra brand dichiarano la destinazione, aiutando a capire il passaggio a un'altra parte dell'ecosistema.
Mostrare lo stato operativo prima dell'amministrazione
Fleet mette in evidenza manutenzioni, difetti, magazzino e documenti in scadenza; Marina organizza il lavoro intorno a mappa ormeggi, arrivi, richieste e contratti; Agent ruota attorno agli scali e alle relative attività. Tabelle, etichette di stato e azioni contestuali rendono riconoscibile l'oggetto del lavoro. I dettagli trovano posto nella scheda, preservando la gerarchia della panoramica.
Progettare anche il lavoro lontano dalla scrivania
Il flusso comprende anche il pontile e la sala macchine. Il canale Telegram di Fleet supporta le segnalazioni operative; il percorso letture di Marina usa foto, OCR, scelta del posto barca e conferma. Il principio è completare il compito nel canale di lavoro: acquisire il dato, controllare l'interpretazione e confermare la registrazione prima del salvataggio.
Collegare i dati senza promettere un'unica app indistinta
L'architettura condivisa definisce un registro canonico delle imbarcazioni e collegamenti espliciti verso Fleet, Charter, Broker, Marina e Shipyard. Ogni applicazione conserva le proprie responsabilità operative. Per la UX, coerenza significa entità riconoscibili e passaggi prevedibili, con confini di integrazione chiari invece di suggerire che ogni funzione sia disponibile ovunque.
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.
La coordinatrice del marina
Operazioni · Marina
- Bisogno
- Assegnare un posto adatto, preparare gli arrivi e collegare cliente, contratto e fatturazione.
- Ostacolo
- Le richieste arrivano da canali diversi e lo stesso posto cambia stato nel tempo.
- Risposta progettuale
- Mappa ormeggi per data, inbox richieste e scheda cliente con azioni contestuali.
Il responsabile tecnico di bordo
Operazioni tecniche · Fleet
- Bisogno
- Capire cosa è in scadenza, trovare la scheda dell'impianto e chiudere la manutenzione con i dati corretti.
- Ostacolo
- Le informazioni sono distribuite tra impianti, difetti, manuali e ricambi, spesso consultati lontano dalla scrivania.
- Risposta progettuale
- Scheda centrata sull'impianto, stato manutentivo visibile e segnalazioni Telegram con conferma.
L'agente portuale
Operazioni commerciali · Agent
- Bisogno
- Coordinare lo scalo e riconoscere quale attività, servizio o documento richiede attenzione.
- Ostacolo
- Più scali avanzano insieme, con passaggi fra operazioni, documentazione e amministrazione.
- Risposta progettuale
- Uno spazio per scalo con stati espliciti, documenti collegati e prossima azione chiara.
Domande di ricerca e validazione
Questo quadro di ricerca è una ricostruzione editoriale basata sui repository e sulle pagine per ruolo del prodotto. Le proto-personas e il journey rappresentativo esprimono ipotesi progettuali. Le tracce d'intervista e gli scenari di usabilità qui sotto costituiscono un piano di validazione proposto, non risultati di interviste documentate o test utenti già svolti.
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: l'ingresso per ruolo aiuta a scegliere il modulo. Traccia d'intervista: «Cosa dovevi organizzare l'ultima volta che hai cercato un software nautico?».
- Ipotesi: lo stato è utile solo con il contesto. Traccia d'intervista: «Quali informazioni ti servono prima di assegnare un ormeggio o una manutenzione?».
- Ipotesi: i passaggi di consegne generano reinserimenti. Traccia d'intervista: «Mostraci dove i dati passano da un messaggio a un foglio e al collega successivo».
- Ipotesi: l'acquisizione mobile richiede una verifica esplicita. Traccia d'intervista: «Quando registri sul pontile o a bordo, cosa puoi controllare subito e cosa deve aspettare?».
Scenari di usability testing
- Task di usabilità proposto: scegliere brand e modulo dalla descrizione di un ruolo; annotare percorso, esitazioni e motivazione.
- Task di usabilità proposto: trovare un posto per barca e periodo di esempio; verificare comprensione di data, dimensioni, disponibilità e conflitti.
- Task di usabilità proposto: verificare una lettura OCR in Telegram, correggere un posto ambiguo e confermare; osservare recupero dall'errore e sicurezza prima di salvare.
- Task di usabilità proposto: individuare una manutenzione scaduta e la scheda impianto; valutare chiarezza di urgenza, responsabilità e prossima azione senza aiuto.
- Piano di verifica: ripetere i percorsi essenziali su schermo piccolo e da tastiera, includendo stati vuoti, limiti di permesso, caricamenti interrotti e salvataggi falliti. Rilevare completamento ed errori senza attribuire baseline o risultati non disponibili.
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 |
|---|---|---|---|
| 01 · Trovare il punto di ingresso | Il professionista arriva sul sito partendo dal proprio ruolo o bisogno operativo. | Un catalogo ampio può rendere difficile distinguere moduli simili. | Le pagine per ruolo spiegano lo scenario e portano al brand e al modulo pertinenti. |
| 02 · Comprendere la situazione | La coordinatrice controlla data, arrivi previsti e disponibilità degli ormeggi. | Una panoramica senza contesto temporale può suggerire una disponibilità diversa dal soggiorno richiesto. | Tenere insieme data, stato dei posti e richieste in ingresso. |
| 03 · Agire sulla scheda corretta | La richiesta viene verificata, collegata a cliente e barca e assegnata a un posto adatto. | Reinserimenti e selezioni ambigue possono produrre informazioni duplicate o in conflitto. | Usare schede riconoscibili, selezioni esplicite e feedback sui conflitti. |
| 04 · Registrare il lavoro sul pontile | L'operatore fotografa il contatore e controlla la lettura interpretata in Telegram. | La sola foto non garantisce lettura, unità e posto barca corretti. | Mostrare il valore interpretato, consentire la scelta del posto e confermare prima di salvare. |
| 05 · Passare il lavoro con il contesto | L'ufficio rivede soggiorno, consumi collegati e attività amministrative aperte. | Il passaggio perde valore se il collega non vede cosa è stato registrato e cosa resta aperto. | Collegare soggiorno, letture e fatturazione, con stato e prossima azione visibili. |
0101 · Trovare il punto di ingresso
- Azione della persona
- Il professionista arriva sul sito partendo dal proprio ruolo o bisogno operativo.
- Ostacolo
- Un catalogo ampio può rendere difficile distinguere moduli simili.
- Risposta progettuale
- Le pagine per ruolo spiegano lo scenario e portano al brand e al modulo pertinenti.
0202 · Comprendere la situazione
- Azione della persona
- La coordinatrice controlla data, arrivi previsti e disponibilità degli ormeggi.
- Ostacolo
- Una panoramica senza contesto temporale può suggerire una disponibilità diversa dal soggiorno richiesto.
- Risposta progettuale
- Tenere insieme data, stato dei posti e richieste in ingresso.
0303 · Agire sulla scheda corretta
- Azione della persona
- La richiesta viene verificata, collegata a cliente e barca e assegnata a un posto adatto.
- Ostacolo
- Reinserimenti e selezioni ambigue possono produrre informazioni duplicate o in conflitto.
- Risposta progettuale
- Usare schede riconoscibili, selezioni esplicite e feedback sui conflitti.
0404 · Registrare il lavoro sul pontile
- Azione della persona
- L'operatore fotografa il contatore e controlla la lettura interpretata in Telegram.
- Ostacolo
- La sola foto non garantisce lettura, unità e posto barca corretti.
- Risposta progettuale
- Mostrare il valore interpretato, consentire la scelta del posto e confermare prima di salvare.
0505 · Passare il lavoro con il contesto
- Azione della persona
- L'ufficio rivede soggiorno, consumi collegati e attività amministrative aperte.
- Ostacolo
- Il passaggio perde valore se il collega non vede cosa è stato registrato e cosa resta aperto.
- Risposta progettuale
- Collegare soggiorno, letture e fatturazione, con stato e prossima azione visibili.
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
Il risultato è una famiglia di prodotti dalla struttura leggibile: mercati distinti, ingressi per ruolo e interfacce organizzate intorno agli oggetti del lavoro quotidiano. Il caso unisce architettura di brand, siti pubblici e progettazione operativa, dalla scheda imbarcazione alla mappa degli ormeggi e alla lettura confermata sul campo. Il contributo principale è un modo coerente di rendere la complessità visibile e affrontabile; non vengono attribuiti impatti economici o metriche d'uso senza una misurazione documentata.
