Al giorno d'oggi uno degli aspetti più sottovalutati nel campo della UX è quello della gestione di account o ruoli multipli da parte di uno stesso utente.
E' prassi ormai consolidata quella di creare un account per utilizzare un servizio o un'applicazione ed è qusi impossibile che trascorra un singolo giorno lavorativo senza che abbiamo a che fare con procedure di login, registrazione o recupero di password.
Le esigenze che portano un utente alla creazione di più account per una stessa app sono molteplici. E' il caso degli account aziendali; sul nostro smartphone Android ad esempio potremmo voler utilizzare contemporaneamente il nostri account Google business e quello personale e passare rapidamente dall'uno all'altro.
Pensiamo invece a Netflix: qui il paradigma è differente, ad un unico account vengono associati più profili in maniera tale che ognuno di essi possa mantenere separata la propria cronologia, conservare le proprie preferenze (lingua, sottotitoli, notifiche) e impostare determinate limitazioni, come i profili per i bambini.
Un altro caso comune è quello di configurare più account per motivi legati ad esigenze di uso del dispositivo o di licenze: pensiamo all'attuale panorama del gaming e delle console dove gli acquisti sono sempre vincolati all'account. Analizziamo il caso della Nintendo Switch: ogni utente deve necessariamente configurare un account principale e legarlo alla console fisica, dove può giocare a tutti i titoli acquistati anche offline. Nulla ci vieta di aggiungere ulteriori account a cui legare preferenze differenti, quali social network collegati o salvataggi; ogniqualvolta andremo a lanciare un videogame il sistema ci chiederà di scegliere tra uno di essi.
Nel caso precedentemente illustrato ad account diversi sono associati diversi titoli che vengono aggregati in maniera trasparente nel launcher delle applicazioni. L'unica limitazione è data dal fatto che, per ovvie ragioni, ci sarà impedito di lanciare un gioco di un account diverso da quello principale se non siamo online. Qualcosa di simile accade su PC con Steam, dove è presente un sistema di condivisione dei titoli che ci permette di accedere a quelli di un altro account dopo aver eseguito una procedura di configurazione iniziale (quindi senza dover dare esplicitamente le nostre credenziali ad un'altra persona), ma stavolta ci viene chiaramente indicato chi è il proprietario.
Un ultimo esempio di gestione di account multipli è quello dei Workspace di Slack. Un utente che ha la necessità di operare con uno o più team può creare diversi Workspace; ad ognuno di essi è associato un account distinto che può o meno condividere uno stesso indirizzo email.
Uno degli errori più comuni che portano ad un indebolimento dell'esperienza di utilizzo è quello di confondere il concetto di ruolo dell'utente reale nell'applicazione e a mischiarlo con la gestione delle autorizzazioni da parte del sistema, dando luogo ad ambiguità difficilmente risolvibili. Nel primo caso l'esempio più semplice è quello del cosiddetto ruolo di Admin: determinati privilegi e funzionalità dell'applicazione sono disponibili solo per questa tipologia di utente. Da un punto di vista tecnico quindi si vanno a garantire particolari permessi e si concede l'accesso a rotte e funzionalità esclusive. Dare ad un utente un "ruolo" in quest'ottica vuol dire quindi concedergli un sottoinsieme di permessi che andiamo ad identificare con un nome, Admin in questo caso.
Quello che in realtà va identificato in prima battuta è il "ruolo" reale dell'utente di un'applicazione: ad esempio, un'app in ambito medico potrebbe essere utilizzata sia da medici che da pazienti e solo alcuni tra i medici potrebbero essere identificati come "admin", magari senza nemmeno avere la necessità di creare esplicitamente un ruolo apposito.
In che misura tutti i concetti espressi nei precedenti paragrafi impattano nello studio dell'esperienze utente di un prodotto digitale?
Gli Archetipi o le User Persona sono dei deliverables importanti che ci aiutano ad estrapolare i ruoli e ci permettono di costruire flussi (Stories, User Flows, Journeys) ad hoc per ognuno di essi, grazie ai quali l'identificazione dei permessi e delle limitazioni sull'accesso alle rotte diventa un'operazione quasi immediata.
Anche il layout e lo stile di una pagina, i suoi contenuti, i componenti e le azioni in dati contesti sono differenti per ruoli distinti e devono essere analizzati separatamente da uno UX Designer. Da un punto di vista meramente pratico ciò vuol dire produrre più documentazione sui flussi e più schermate per i wireframe; riguardo a queste ultime, spesso per ragioni di budget o tempo diventa difficile riuscire a disegnare tutti i possibili stati di un sistema, diventa quindi più importante fornire linee guida chiare agli sviluppatori riguardo i pattern e il comportamento dell'applicazione.