Cutting Edge - Architettura migliore con la progettazione basata sull'esperienza utente

Da Dino Esposito | Novembre 2015

Dino Esposito La progettazione di qualsiasi sistema software inizia con un passaggio noto: raccolta di requisiti dagli utenti. Ciò richiede in genere molte riunioni e interviste con clienti ed esperti di dominio. Dopo l'ultima riunione, quasi tutte le persone coinvolte nel progetto dovrebbe ritiene che tutti i dettagli del sistema sono stati ironed out e sviluppo è possibile avviare in modo sicuro. Nessuno deve dubito che il prodotto finale sarà diverso da ciò che è stato spiegato e riconosciute. I clienti devono essere soddisfatti e architetti devono ritenere che sanno esattamente cosa fare.

Tuttavia, in pratica, l'esperienza dimostra che concordare requisiti astratti non garantisce corretta implementazione. Quando i clienti visualizzare effettivamente il prototipo, molto spesso sono semplicemente non piace. Indipendentemente da tutte le riunioni e le discussioni, sembra che i clienti e gli sviluppatori di formano distinte idee del prodotto finale. Gli sviluppatori ricevono i requisiti e creare software attorno a esse. Ma il prodotto finale mancati riscontri spesso il marchio degli utenti desiderano.

Ritengo che gli sviluppatori spesso tendono a ha lo scopo di completezza funzionale e non sufficienti sugli utenti finali i processi di business necessaria per il sistema deve eseguire lo stato attivo. Pertanto mentre vengono acquisiti aspetti funzionali dei processi di business, l'implementazione complessiva è raramente come ordinato e smooth come previsto. In questo articolo presenterò un approccio di progettazione che consentono di migliorare le possibilità per gli architetti compilare la prima volta la cosa giusta. Chiamo questo approccio basato su UX progettazione o UXDD breve.

Apple che ricade sullo testa

Probabilmente si ricorderà la storia apocryphal di apple che ricade sullo head del Sir Isaac Newton, contattarlo per formulare il diritto di Gravitation Universal iniziali. Di recente un apple ricade sullo testa e il messaggio ricevuto è stato tale scadenza pagante attenzione alle aspettative degli utenti e ai processi reali talvolta richiede la creazione di elementi diversi. Ovvero, richiede più di un'analisi funzionale.

Un cliente richiesto creare un rapido e semplice, in modo che ha affermato, per supportare la parentesi competitiva per un tournament tennis applicazione Web. Si è verificato solo una storia utente. L'operatore è indicato il nome del lettore e posizione correlata all'interno di disegno e l'operatore previsto che il sistema di esporre alcuni feed XML che riflette lo stato corrente del disegno. Approccio mentale dello sviluppatore mio creato immediatamente la visione di una tabella di database per contenere i dati. Successivamente, ho avuto la visione di un form HTML rapida con due caselle di testo: uno per indicare il nome del lettore e uno per la posizione nel disegno. È interessante notare che, quando è terminata la discussione, il cliente è stato determinato lui uno strumento per immettere i lettori e posizioni e aveva alcuni XML per il supporto. Ma quando lo sviluppatore, mi, recapitati solo questa e testato il cliente nella simulazione di un disegno attivo, non funziona. Il cliente desidera effettivamente qualcosa di molto più complesso. Consultare Figura 1 illustra diverse prospettive tra sviluppatori e ai clienti. La schermata di sfondo è ciò che richiede il cliente e la rappresentazione del processo reale. la schermata gialla con un contorno nero in sovrimpressione è la soluzione a basso costo, veloce, poiché non è appropriato.

Figura 1 la differenza tra desiderato e ciò che è compreso

Alla fine del giorno, l'esperienza utente è molto più di movimenti e grafica, è l'esperienza che gli utenti passano attraverso durante l'interazione con il software. Per progettare un efficace UX, in qualità di architetto e sviluppatore che più è necessario concentrarsi su attività e processi aziendali più modelli di data e l'archiviazione. Per comprendere le attività, è necessario acquisire familiarità con il dominio, gli utenti e il funzionamento di tali utenti in tale dominio. UXDD risolve questo problema, ma non è semplicemente un suggerimento generico per utilizzare wireframe e modelli. Che ho utilizzato in uno scenario semplice e non funziona perché il cliente, il suo tenendo, considerato il software è stato troppo semplice e non la pena di progettazione completamente il processo reale. Come architetto, non ricevo il messaggio corretto dal cliente sull'importanza dell'attività. Non scegliere una soluzione a basso costo. Scegliere una soluzione efficace. Devo ammettere che la soluzione originale si è suggerito, ovvero la soluzione a basso costo, era praticamente impossibile da utilizzare in una situazione realistica. L'errore è stato completamente e ciecamente trust analisi del cliente e non ulteriori informazioni sui processi di business effettivo.

UXDD è una serie di indicazioni architetturali che è possibile ridurre al minimo il rischio di perdere punti aziendali più importanti relativi alle attività e l'interfaccia utente. È interessante notare che, UXDD modificare alcune delle procedure consolidate di oggi lo sviluppo e progettazione software.

Progettazione top-Down

Dal punto di vista funzionale, è possibile compilare correttamente un sistema funzionante indipendentemente dal fatto se si avvia lo sforzo di progettazione dal basso (ad esempio, dal modello di persistenza) o superiore (ad esempio, dal modello di livello e visualizzazione di presentazione). Dal punto di vista dell'esperienza utente, è possibile solo esito positivo se si avvia la progettazione di modelli di presentazione e visualizzazione e compila tutto il resto, tra cui lo stack di back-end, da qui.

Molti di noi professionalmente imparato che una volta ottenuto un modello di persistenza di entità e relazioni, create in base a requisiti degli utenti pressoché effettuate. Tale modello sarebbe il modello dell'intero sistema utilizzato in tutta l'intero stack e solo occasionalmente collaborato da alcuni oggetti di trasferimento dei dati specifici dell'interfaccia utente. In questo contesto, progettazione e creazione del sistema vengono eseguite in modo dal basso in alto e il livello di presentazione inevitabilmente riflette la visione incentrato persistenza del modello di dati. Viene spesso chiamato creazione, lettura, aggiornamento, eliminazione (CRUD) e viene spesso ridurre qualsiasi sistema CRUD con solo un po' più sofisticata logica di business. In questo modo, si prestano grande attenzione al livello di presentazione. Talvolta un'interfaccia utente troppo vicino al modello di dati è utile per gli utenti. In alcuni casi non è. Il secondo scenario consente di scintilla a ulteriore negoziazione dopo il primo prototipo di lavoro è stato recapitato. Innanzitutto si concepisce da zero un sistema di backup per scoprire poi che il livello più esterno deve essere modificata per riflettere i processi utente diverso. Si tratta in alcun modo diverso dal tentativo di inserire tasselli quadrati in aree libere di arrotondamenti. Per questo motivo, viene visualizzata come la maggiore sfida molti progetti software.

Cosa si può fare per migliorare il processo? Ritengo che la risposta è riportare un approccio di progettazione top-down che inizia dal livello di presentazione e rende eventuali ulteriori decisioni e di dettaglio di implementazione derivano da requisiti di presentazione. Per rendere effettiva, una sorta di sprint zero o passaggio preliminare a cascata, è necessaria assicurarsi che prima di passare a compilare il back-end del sistema viene acquisita una conoscenza approfondita dell'esperienza utente.

La metodologia basata sull'esperienza utente

Ho appreso da esperti UX che i requisiti sono più attivamente generati tramite discussione basata su prove di passivamente dedotto tramite colloqui. Talvolta gli architetti e gli analisti tendono a rimanere troppo passivo durante estrapolazione e in questo modo agli utenti di diminuire la priorità di tutte le funzionalità per disporre del software pronto appena possibile. Poi si lamentano che il sistema è poco utilizzabile quando infine diventino. Allo stesso tempo, rimanere troppo passivo in estrapolazione con il motivo che "questo è il cliente desidera" non interpretarla della "cosa" dobbiamo creare. Oggi, scriviamo software mirror parti del mondo reale piuttosto che a ciò che è stato stato indicato che il cliente desidera del modello. Mancante nel componente strutturale di business è un peccato blocchi e i costoso.

È pratica comune utilizzare wireframe per raggiungere un accordo sull'interfaccia utente previsto. È in esecuzione in modo iterativo wireframe dagli utenti di richiedere commenti e suggerimenti funziona solo in una misura di piccole dimensioni. Wireframe sono eccezionali, ma un valore limitato senza storyboard.

Molto alcune attività vengono eseguite interamente mediante una singola schermata che è possibile riepilogare in modo efficace un wireframe. Esame wireframe di una schermata potrebbe non essere sufficiente per individuare possibili colli di bottiglia dell'implementazione del processo. Concatenazione di schermate in uno storyboard è un'idea migliore. A questo proposito, la maggiore sfida che vedo la ricerca di strumenti per la creazione di storyboard. Questi strumenti sono un mercato in rapida crescita. Figura 2 sono elencati alcuni strumenti che consentono rapidamente prototipo del livello di presentazione delle applicazioni in modo che offre agli utenti un'idea concreta del processo in fase di progettazione.

Figura 2 strumenti per la creazione di prototipi rapido ed efficace interfaccia utente

Strumento	URL
Windows	axure.com
Balsamiq	balsamiq.com
Studio Indigo	Infragistics.com/Products/Indigo-Studio
JustInMind	justinmind.com
UXPin	uxpin.com

Inoltre, le versioni recenti di Microsoft Visio e PowerPoint (soprattutto in combinazione con Visual Studio Ultimate) funzionalità anche alcune funzionalità di creazione di prototipi. Tutti gli strumenti elencati in Figura 2 offrono una piattaforma avanzata per creare wireframe e in alcuni casi offrono la possibilità di creare bozze selezionabili e trasformarle in prototipi funzionali.

Questi strumenti più avanzati fornire commenti e suggerimenti e, più importante, ora si comportano i clienti nel processo di progettazione e prima di scrivere una sola riga di codice. Se che non hai risposto punti importanti presentazione al termine della metà il back-end, è possibile eliminarlo oppure regolare cose.

Allo stesso tempo, stiamo parlando di esternalizzazione semplicemente il livello di presentazione di un team di esperti UX non è sufficiente. Il livello di presentazione oggi è la parte più importante di un sistema e lo sforzo combinato di architetti, progettisti UX e i clienti devono essere il risultato. Deve essere il primo passaggio e Idealmente si sposta su solo quando il cliente conclude la presentazione. In termini di metodologia, è possibile richiedere un'inclinazione a cascata e completare la progettazione intera presentazione prima della codifica ed essere più flessibili e aggiungere l'analisi di presentazione in un passaggio di sprint, come illustrato nella Figura 3.

Figura 3 le tre fasi di progettazione dell'architettura basata su UX

Il resto della soluzione di progettazione

Dopo aver completato il livello di presentazione per l'intera soluzione o semplicemente lo sprint corrente, si dispone di una raccolta di schermate, ad esempio, form, con un flusso di dati ben definita (è chiaro quali vantaggi si gode avanti e indietro di ciascun form). Dal punto di vista architettonico, ciò significa che si conosce il modello di input di ogni azione e il modello di visualizzazione necessario per compilare il modulo o generare la risposta prevista. Il livello di presentazione si connette al back-end tramite un livello di servizio intermedio che concettualmente corrisponde al modello di livello di servizio, come definito di Martin Fowler (bit.ly/1JnFk8i), nonché il livello nell'architettura a più livelli della progettazione dell'applicazione. È il segmento logico del sistema di cui si implementano i casi di utilizzo e qualsiasi orchestrazione delle attività che necessarie. Il livello dell'applicazione è la parte superiore del back-end e le finestre di dialogo direttamente con il livello di presentazione. Il livello dell'applicazione è costituito da endpoint diretto per ognuna delle azioni che possono essere attivate per la presentazione. Questi endpoint ricevano e restituiscono solo i modelli di input e visualizzazione risultante dal wireframe.

È questo l'approccio realmente efficace? Senz'altro. Se l'analisi di wireframe è completa e corretta, si implementa solo i processi con i clienti desiderano ed è giusto la prima volta. Ridurre notevolmente le possibilità di rinegoziazione modifiche dopo aver distribuito il primo rilascio o demo. Consente di risparmiare tempo e, successivamente, denaro. Come illustrato nella Figura 4, gli sviluppatori indicano come emblematic dell'aspetto software agli utenti. E UXDD porta alla progettazione software in questo modo.

Tracce del Software dal punto di vista dell'utente
Figura 4 essenza del Software dal punto di vista dell'utente

Avvolgendo

Rispetto a come si progetta software oggi, dal modello di data backup, ovvero UXDD assegna più importanza alle attività e presentazione rispetto ai modelli di dati. Non che la modellazione di dati e la persistenza non sono importanti, ma i relativi ruoli sono funzionali di attività anziché viceversa. Che piaccia o No, questo si avvicina a ciò che il mondo reale richiede oggi. UXDD riguarda la metodologia anziché tecnologia o modelli. UXDD non negare né Imponi qualunque tecnologia o un modello, anche se diventa molto bene con CQRS e generare eventi. Se non si è soddisfatti l'effettivo processo di creazione di applicazioni, utilizzare l'approccio UXDD come modulo di pensare laterale.

Dino Esposito è coautore di "Microsoft .NET: Architecting Applications for the Enterprise"(Microsoft Press, 2014) e" programmazione ASP.NET MVC 5"(Microsoft Press, 2014). Technical evangelist per Microsoft .NET Framework e piattaforme e Android in JetBrains e spesso come relatore a eventi del settore in tutto il mondo, Esposito condivide la sua visione di software software2cents.wordpress.com e su Twitter: @despos.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Jon Arne Saeteras