12 luglio 2014

Convergenza di interfaccia ed esigenze degli utenti

Un esempio di come si possano interpretare le esigenze operative e come riuscire a soddisfarle. Quasi tutte.


La convergenza tecnologica, la realizzazione di una unica interfaccia per media e device diversi, non è una feature di prodotto, ma una disciplina prettamente umanistica.

Convergenza non è un punto fisso nel dominio delle possibilità tecnologiche e delle esigenze funzionali, bensì un equilibrio dinamico perturbato da mutevoli istanze organizzative, tecniche e normative.

L'obiettivo di chi si prefigge di realizzare un sistema "convergente" non deve essere dunque la soddisfazione delle esigenze attuali e istantanee degli utenti, ma l'individuazione dei nodi-chiave che modulano nel tempo le caratteristiche della forma organizzativa, tecnica e normativa entro cui tale sistema dovrà operare.

O almeno in teoria.

In realtà si deve fare sempre i conti con le risorse, i tempi e i costi, e questo aggiunge una ulteriore difficoltà alla ricerca della soluzione ideale. Le soluzioni del sistema di equazioni che si viene a determinare sono pressoché infinite e dipendono dalla visione, dall'awareness di contesto operativo e alla knowledge tecnologica di chi si trova a dover stendere le specifiche o prendersi carico delle scelte progettuali.

Per chiarire il senso di quanto detto finora, diamo uno sguardo ad un generico modello qualitativo applicabile a diverse realtà operative. Abbiamo una "entità" operativa (una azienda, un reparto, una pubblica amministrazione), che necessita di un generico sistema di controllo (per una macchina, un impianto, una centrale). Tale sistema verrà operato da diversi ruoli presenti all'interno dell'entità, per svolgere ciascuno le funzioni a lui preposte: un operatore, un manutentore, un ingegnere e un dirigente. Individuiamo dunque delle esigenze operative/fuzionali genericamente indicate con delle "qualità" del sistema di controllo.

Procedura

È il grado di "procedurizzazione" del sistema, ovvero se le azioni possibili sono formalmente identificate come elementi di procedura e se prevedono un workflow specifico e definito per essere completate.

Specializzazione

È il grado di complessità delle funzioni implementate nel sistema. Tale valore è basso se le funzioni sono "atomiche", mentre è altro se sono implementate funzioni articolate e altamente specializzate.

Dettaglio

È il grado di dettaglio delle informazioni rappresentate. Tale valore è basso quando si hanno informazioni di sintesi, aggregazioni e dashboard riepilogative, mentre è alto se è possibile effettuare il drill-down delle informazioni fino al dettaglio tecnico di più basso livello.

Decisione

Tale parametro indica se il sistema accetta input da utenti che sono in grado di determinare una reazione più o meno "radicale" del sistema.

Semplificazione

Indica il grado di sintesi nella rappresentazione del processo; sistemi con bassa semplificazione richiedono più "manualità", mentre sistemi più semplificati sacrificano una rappresentazione più realistica del processo per favorire l'usabilità del sistema di controllo.

Inseriamo quindi tali qualità come assi di un grafico radar. Per ciascuno dei ruoli abbiamo (sempre qualitativamente) assegnato un valore a ciascuna dimensione: questo valore rappresenta l'esigenza percepita da quell'utente in relazione alla qualità del sistema di controllo.

In altre parole abbiamo immaginato il sistema come se fosse descritto da ciascun ruolo in relazione alle qualità indicate (*).

Constatato che tali stime sono qualitativamente verosimili, ci troviamo di fronte a quattro diverse esigenze espresse dai quattro diversi ruoli che dovranno operare sul sistema.

Come è possibile dunque trovare una convergenza, una comunanza di esigenze, una unità di interfaccia quando le esigenze differiscono così tanto per ciascun utente?
Le soluzioni più intuitive sono principalmente due: l'Envelope Surface e la Weighted Surface.

La prima massimizza le qualità, la seconda appiattisce le esigenze.



 La terza soluzione possibile, che è la più performante sotto il punto di vista delle esigenze e della longevità e adattabilità, ha però il limite dei lunghi tempi (e conseguenti costi) di progettazione e implementazione (ed è per questo che è anche la meno perseguita).

È ovvio, per chi ha visto più di un progetto, che è possibile trovare soluzioni intermedie e compromessi più che accettabili nella "composizione" di soluzioni ibride, che magari concedano più peso a determinate qualità tralasciandone altre, o che introducano una parametrizzazione solo in alcune delle qualità individuate, o che ridimensionino le esigenze espresse o inespresse di ruoli utente secondari.


(*) L'esempio non vuole rappresentare un caso reale o una reale metodologia, ma spiegare le ragioni delle considerazioni fatte nell'articolo e rappresentare un processo mentale. Ovviamente può essere realmente applicato in questi termini qualora la valutazione sulla fattibilità del sistema di controllo accetti come parametri di valutazione le qualità espresse.