Design e user experience

Progettare l'esperienza d'uso, le interfacce e i prodotti digitali: OTOKO® traduce i vostri requisiti in un utilizzo chiaro e coerente.

I clienti vogliono portare a termine le proprie pratiche, i team sul campo hanno bisogno di informazioni sul luogo di intervento e i reparti necessitano di una panoramica affidabile.

Prototipo cliccabile e test con gli utenti insieme all'area di business o ai clienti prima dello sviluppo Frontend web con React, Next.js o Vue, accessibilità secondo le WCAG 2.2 App mobili con React Native oppure native in Kotlin e Swift, inclusa la pubblicazione negli store Accesso tramite OpenID Connect, protezione delle sessioni e certificate pinning secondo OWASP MASVS Funzionalità offline, notifiche push e telemetria con consenso secondo il GDPR

App pubblicata e applicazione web con codice sorgente Design system e report di accessibilità Report di verifica della sicurezza secondo OWASP MASVS

Gruppi di utenti e attività principali Sistema di accesso esistente e modello dei ruoli Dispositivi necessari e situazioni offline

Un portale partner sostituisce le richieste via e-mail. I partner vedono solo le proprie pratiche, caricano i documenti e ricevono le richieste di chiarimento nel processo. La gestione interna utilizza gli stessi dati, ma ruoli e autorizzazioni diversi.

React Next.js Vue React Native Kotlin Swift

Un portale è utile quando gli utenti raggiungono il proprio obiettivo senza giri inutili. Progettiamo flussi completi per accesso, inserimento dati, upload, richieste di chiarimento e monitoraggio dello stato. I casi di errore fanno parte del piano: sessioni scadute, documentazione incompleta o una connessione interrotta non devono causare la perdita del lavoro già inserito. I prototipi cliccabili rendono questi flussi verificabili prima dell'implementazione. I feedback dell'area di business e del gruppo di utenti confluiscono in navigazione, moduli e messaggi comprensibili. Un sistema di componenti condiviso garantisce che le nuove funzionalità utilizzino la stessa logica di interazione.

La scelta segue l'utilizzo previsto. Un portale basato su browser facilita l'accesso senza installazione. Una progressive web app può essere sufficiente per determinati flussi mobili; app native o multipiattaforma entrano in gioco quando interfacce del dispositivo, elaborazione in background o requisiti offline lo richiedono. Verifichiamo le capacità necessarie su dispositivi reali. I dati offline richiedono regole per l'archiviazione locale, la sincronizzazione e la gestione dei conflitti. In un'app per il personale sul campo, ad esempio, deve essere chiaro quale modifica ha la priorità quando due persone lavorano sulla stessa pratica. Queste questioni influenzano il backend e le autorizzazioni tanto quanto l'interfaccia.

La navigazione da tastiera, gli stati di focus riconoscibili, i messaggi di errore comprensibili e la possibilità di ingrandire il testo fanno parte del lavoro sull'interfaccia. Concordiamo con voi il quadro di verifica necessario per l'accessibilità. Una bozza visiva o una scansione automatica da sole non costituiscono una prova completa dell'accessibilità. Verifichiamo gli accessi lato server per ogni ruolo e ogni operazione. Per il caricamento dei file, le sessioni e le condivisioni dei dati prevediamo misure di protezione specifiche. Per il rollout pianifichiamo dispositivi di test, eventuali approvazioni negli store, i canali di supporto e l'introduzione presso i vostri utenti.

Un account cliente è composto da più di un semplice login. Inviti, cambi di organizzazione, accessi perduti, deleghe e l'uscita di collaboratori devono rientrare nel modello delle autorizzazioni. Chiariamo chi può autorizzare nuovi utenti e quali passaggi richiedono una nuova conferma. Le identità gestite centralmente possono essere collegate: la decisione nel merito su un incarico concreto resta comunque compito del portale. Per i percorsi di richiesta e i caricamenti consideriamo l'intero flusso fino alla lavorazione interna. Le dimensioni dei file, i contenuti ammessi, la quarantena e l'approvazione vengono pianificati insieme a messaggi di stato comprensibili. Un caricamento riuscito non significa ancora che un documento sia stato verificato o accettato. Le bozze, il salvataggio automatico e la ripresa su un altro dispositivo richiedono regole chiare sulla visibilità. Le informazioni sensibili non devono comparire per errore in notifiche, URL o messaggi di diagnostica.

Un'applicazione mobile in magazzino o sul campo non può presupporre una connessione stabile in modo continuo. Distinguiamo i dati offline in sola lettura dalle modifiche registrate localmente e stabiliamo per quanto tempo restano validi. Grandi quantità di dati non vengono copiate indiscriminatamente su ogni dispositivo. Diritti degli utenti, memoria del dispositivo e la gestione di un dispositivo smarrito rientrano nel piano. Al momento della riconnessione, lo stesso record potrebbe essere già stato modificato sul server. Una regola generica del tipo «vince l'ultima modifica» è inadatta per molti processi specialistici. Definiamo quali campi possono essere uniti automaticamente e quali conflitti richiedono una decisione. Le trasmissioni in sospeso restano visibili agli utenti. I test comprendono interruzioni della connessione durante l'invio, invii ripetuti, sessioni scadute e modifiche alle autorizzazioni tra la registrazione e la sincronizzazione.

Un portale non viene utilizzato solo su un grande monitor di sviluppo. Nomi lunghi, traduzioni, testo ingrandito, tastiere a schermo e dispositivi lenti modificano il layout. Per questo verifichiamo attività complete sui dispositivi rilevanti e con diversi metodi di inserimento. I messaggi di errore spiegano cosa correggere e rimandano al punto corretto. Un modulo non deve perdere i dati inseriti solo perché l'accesso deve essere rinnovato. Per l'introduzione pianifichiamo una cerchia limitata di utenti, un supporto raggiungibile e riscontri da flussi di lavoro reali. Nelle app mobili le versioni precedenti possono restare installate: il backend deve tenere conto del periodo di transizione concordato. Le misurazioni d'uso dovrebbero rispondere a domande concrete di miglioramento, ad esempio in quale punto una pratica si interrompe. Prima dell'implementazione si chiarisce quali misurazioni possono essere utilizzate e quali informazioni richiedono.

Panorama applicativo, requisiti, rischi Area di business, IT, sicurezza delle informazioni, architetto software OTOKO® Iniziative valutate, analisi dello stato attuale, requisiti di sicurezza e di esercizio

Architettura, tecnologia, modello operativo Area di business, architettura, protezione dei dati, sicurezza delle informazioni Architettura target, modello delle minacce, strategia di test, modello operativo, milestone