2016-05-12

Maggio 2016

Volume 31 Numero 5

Il presente articolo è stato tradotto automaticamente.

Visual Studio - Creazione di un'esperienza utente semplificata

Da Karl Melder | Maggio 2016

In Visual Studio 2015, Microsoft recapitati diverse funzionalità nuove di debug e diagnostica in dettaglio da Andrew Hall nel 2016 marzo articolo di MSDN Magazine, "Miglioramenti di debug in Visual Studio 2015" (msdn.com/magazine/mt683794). Per le funzionalità che implicano modifiche sostanziali per l'esperienza utente, Microsoft adottato un approccio di "Lean UX" con esperimenti iterativi feedback diretto dell'utente per informare la progettazione.

Si desidera condividere con il processo che è stato utilizzato per progettare una di queste caratteristiche, PerfTips, con le procedure consigliate, suggerimenti e trucchi prelevati lungo il percorso. L'obiettivo è e consentono ai team di riduzione in modo efficace i suggerimenti dei clienti direttamente nei processi di sviluppo.

Lean UX

Lean UX è un complemento alle pratiche di sviluppo snella tendenze del settore. Eric Ries intende la pratica di "Build, misure e informazioni" lean nel suo libro 2011, "Il Lean avvio" (Crown Business), in cui descrive un approccio "sperimentazione basato su ipotesi business". Analogamente, UX Lean è un set di principi e i processi che si concentra sulla convalida dei clienti molto anticipata e in corso, in cui eseguire esperimenti per convalidare l'utente e le ipotesi di progettazione del prodotto in cicli molto brevi. Le alternative di progettazione vengono eseguite rapidamente con particolare attenzione sulla risoluzione dei problemi di utente reale. Una Guida di riferimento è libro 2013 di Jeff Gothelf, "Lean UX" (o ' Reilly Media), in cui fornisce indicazioni e fogli di lavoro per aiutare i team di rendere chiare a ciò che si ritiene o raggiungere.

Per il team di fornire l'esperienza di debug in Visual Studio, UX Lean è un approccio estremamente collaborativo in cui l'intero team, inclusi i responsabili del programma, ricercatori UX, sviluppatori e progettisti UX, coinvolti nella generazione di idee, generare ipotesi, e interpretazione dei quali è stato sentito e visto dai nostri clienti.

Questo articolo è completamente l'adozione di feedback dei clienti nel processo di sviluppo del prodotto. Sta gestiti più rapidamente in avanti. È sulla ottenere commenti e suggerimenti su idee senza dei bit di lavoro. Su non è sufficiente un team nella divisione sviluppatori di strumenti di questa operazione, ma molti team cambiando radicalmente come funzionalità sono progettate in un processo di sviluppo pulito.

La sfida di progettazione

Tecnologia Microsoft è ricco di dati che possono fornire agli sviluppatori un modo più agevole per diagnosticare i problemi. Tuttavia, nei laboratori UX, gli utenti ripetutamente rientrerebbero nuovamente per completare manualmente l'esecuzione del codice nonostante il vantaggio che forniti strumenti quali il Profiler. Strumentazione dati foro out un basso utilizzo di Visual Studio Profiler nonostante la convinzione che rende le prestazioni di ricerca invia un processo molto più efficiente. Per uno strumento come Visual Studio, in cui un utente impiega più di otto ore lavorando un giorno, in cui viene chiesto all'utente di modificare la modalità di lavoro può essere un'attività complessa. Pertanto, il team desidera sfruttare naturale stile di lavoro dell'utente durante il debug di problemi di prestazioni e offrire un ambiente.

Era stato applicato un approccio più tradizionale a cascata, focus group potrebbero essere state svolte per ottenere alcuni presto un feedback, una specifica dettagliata scritte e quando la codifica è quasi completata, l'usabilità studi sarebbero stati pianificati. Un utente verrebbe assegnato attività esercitata le nuove funzionalità e valutare i problemi segnalati come avviene con i bug. Per Visual Studio 2015, è stato eseguito un approccio molto diverso.

Il processo di ricerca

Invece di programmazione studi sull'utilizzabilità quando lavoro bit erano disponibili, due utenti sono stati prescheduled ogni venerdì per la maggior parte del ciclo del prodotto. Questi giorni sono stati definiti in modo informale "Venerdì Pulse rapido". Gli utenti è stato ricevuto per circa due ore, in cui il tempo in genere è stato suddiviso in esperimenti da due a quattro. Per ogni esperimento, è stato effettuato un tentativo per quanto tempo deve essere dedicata. Ogni esperimento riguardavano per consentire a Microsoft ulteriori informazioni su utenti e il loro funzionamento o sulle provare un'idea. Dovevano sopravvivere almeno tre settimane di ottenere risultati positivi per proseguire con le idee di progettazione. Un risultato positivo destinati agli utenti che sia ritenuto fortemente ha valore per l'individuazione di essi, un aumento, più semplice da utilizzare o potuto dimostrare miglioramenti per gli scenari principali.

Ricerca UX è spesso suddivisa in quantitativi e qualitativi, in cui una combinazione di commenti e suggerimenti di clienti e strumentazione/analisi Guide business e sviluppo di prodotti. Nelle ricerche qualitativi anticipata, commenti e suggerimenti devono ottenere reazione degli utenti alle idee. Il team ha preso in considerazione non solo si dice, ma la reazione fisico, facciale e tono di voce. Gli utenti hanno avuti un'attività reale, ad esempio corregge un bug delle prestazioni in un'applicazione senza assistenza da parte del team di ricerca come essi sono stati rilevati, come illustrato in foto nella Figura 1. Ciò significa che consente l'apparenza di utenti. Il team richiederebbe video di essi per un'analisi futura e prendere appunti su entrambi cosa è stato sentito e visibili. Osservando gli utenti hanno consentito al team di comprendere le modalità di lavoro e identificare i requisiti non articolate non sanno per chiedere a un utente, ma può fornire un notevole miglioramento del prodotto.

Figura 1 Research sessione con un utente

Qual è stato fondamentale per il successo del team è stato non spese da effettuare in qualsiasi momento per convincere i clienti per avere un'idea. Gli utenti sono stati semplicemente è stati illustrati il concetto in termini di cosa sarebbe come utilizzarlo. Quindi, il team con rientri nuovamente semplicemente in ascolto, controllati e domande che hanno consentito di comprensione punti di vista degli utenti. La chiave per il successo del team era la capacità di dissociare stesso dall'idea o che potrebbero avere ritenuto fortemente sulla progettazione.

Ogni settimana sono stati assunti partecipanti diversi per un flusso costante di nuove prospettive. Si è verificato un team interno sia un fornitore che ha assunto, vagliate e pianificati gli utenti. Il team non cercare gli utenti che hanno esperienza specifica con diagnostica; piuttosto, il profilo di selezione è stato semplicemente active agli utenti di Visual Studio. Questo significa che ogni settimana erano presenti utenti con competenze diversi, esperienze e contesti di lavoro. Il team ha fornito l'opportunità di imparare qualcosa di nuovo ogni settimana e lasciare che identificano i consistenze. Il team potrebbe anche sviluppare le idee abbia esito positivo con un pubblico più ampio.

Altrettanto importante è stato bilanciamento del carico come il team di interazione con gli utenti. Come è stata posta una domanda potrebbe notevolmente influire sul risultato e definire la conversazione. Il team ha sviluppato l'abitudine di porre sempre domande aperte, in cui le domande del sondaggio derivavano da ciò che l'utente ha o stato. Ad esempio, se un utente del team che non desiderano qualcosa, sono stati semplicemente richiesto, "Ulteriori informazioni che." Il team ha tentato di non presuppone nulla e carente le ipotesi e le ipotesi ad ogni opportunità. Queste competenze sono base al campo dell'esperienza utente e sono state adottate da tutti i membri del team. Se si desidera ulteriori informazioni su queste tecniche di colloqui di lavoro, è consigliabile Cindy Alvarez 2014 libro, "Lean cliente Development" (o ' Reilly Media).

Le prime sessioni rapida Pulse e la modalità di lavoro Unshakeable

Nelle prime fasi del ciclo del prodotto, il team avviato con un'idea che consentono agli utenti di monitorare le prestazioni del codice. Il team creato un modello e corretta davanti utenti rapido Pulse venerdì. Cosa è stato in modo coerente, anche dopo tre settimane prima della modifica di progettazione, è stato che essi non eravamo certi era da e che essi "sarebbe probabilmente disattivarlo!" Non era necessariamente ciò che voleva ascoltare il team, ma è necessaria un'opinione.

Durante la riproduzione anche gli utenti diagnosticare i problemi dell'applicazione, tuttavia, era chiaro che il team è necessaria un'esperienza utente che più direttamente faceva parte dell'esperienza di navigazione di codice. Anche se vi sono diverse finestre del debugger che forniscono informazioni aggiuntive, era difficile per gli utenti di prestare attenzione alle diverse finestre contemporaneamente. Il team osservati molti utenti mantenendo i stato attivo nel codice, spesso mentalmente "codice di analisi" l'esecuzione. Ciò potrebbe sembrare ovvio per qualsiasi sviluppatore lettura di questo articolo, ma ciò che era molto interessante era tale stile di lavoro come unshakable è nonostante la disponibilità di altri strumenti progettati per rendere più efficienti attività.

Il team è nata concezione idee tramite Photoshop, in cui il richiederebbe una finestra di progettazione molto esperto upward of un giorno per generare un modello che può essere usato per commenti e suggerimenti. Photoshop tende a presta alla creazione di un'interfaccia utente con alta fedeltà. Al contrario, il team all'uso di Microsoft PowerPoint e un componente aggiuntivo storyboard (aka.ms/jz35cp) che consente di tutti i membri del team di creare rapidamente rappresentazioni media fedeltà delle proprie idee. Questi storyboard assegnato agli utenti un'idea di cosa potrebbe essere simile, ma erano sufficientemente approssimative agli utenti di individuare era una progettazione in corso e che il loro contributo ha impatto diretto. Il risultato finale è che è stato molto più semplice eliminare un investimento di 30 minuti quando non è riuscita di un esperimento. Inoltre, potrebbero essere testate idee che il team era funzionerebbe in pratica, ma i commenti e suggerimenti degli utenti consente di generare nuove idee.

Per ottenere un feedback sul modello di interazione dell'utente, tutte le diapositive ponti PowerPoint rappresentato un'azione dell'utente o una risposta del sistema per tale azione. Quando disegnate l'interazione, un'immagine icona del cursore da visualizzare in cui l'utente fare clic su verranno inclusa. Questo è utile quando la condivisione di idee e l'utilizzo dei dettagli. Tuttavia, l'icona del cursore verrebbe rimosso prima di visualizzarlo agli utenti. Si tratta di consentito al team di chiedere loro di ciò che è necessario eseguire successivamente, fornendo un modo di sconto per identificare questi possibili problemi. Per ciascuna diapositiva di risposta del sistema che il team potrebbe richiedere anche se gli utenti ritenevano che erano stato di avanzamento, che consentono il team di sapere se è quello di fornire commenti e suggerimenti adeguati. Questa tecnica di commenti e suggerimenti è denominata "processo cognitivo procedura dettagliata" Research UX e consente di identificare problemi molto meno recenti nelle fasi di progettazione l'interazione, offrendo un senso anticipata di aree di interesse che richiederà ulteriore sperimentazione predisporre e iterazione.

Per misurare l'impatto potenziale di un'idea, il team si basava sulla capacità dell'utente di esprimere in modo specifico come è possibile utilizzare il concetto in un ambiente di lavoro quotidiano e ha percepito potrebbe essere diretti vantaggi e svantaggi. L'utente doveva fornire esempi dettagliati e plausibili per il team di diventare certezza che l'idea era consigliabile utilizzare. Il team inoltre esaminato per verificare se l'utente ha iniziato a prestare particolare attenzione, ottenere ulteriori entusiasmo animato e rapido. Il team stava cercando di idee che attirano l'attenzione degli utenti e potenzialmente avere un impatto molto positivo sulla propria esperienza di diagnostica.

"Wow, questa è incredibile!"

Il team serviva un modo per visualizzare informazioni sulle prestazioni nel codice che riguarda la leggibilità del codice e concederebbe agli utenti un'esperienza di debug di codice in ambiente. Codice di filtro, una funzionalità di Visual Studio che consente di visualizzare informazioni relative alla cronologia di modifica, bug, unit test e i riferimenti, forniti l'ispirazione su un modello di interazione potenziali e progettazione visiva. Il team provato a bozze di alcune idee con i clienti, gli sviluppatori passaggi tramite codice, viene valori relativi alle prestazioni in millisecondi (vedere Figura 2).

Figura 2 un Mockup anticipata che mostra i dati sulle prestazioni in una sessione di debug

L'indicazione prima che il team si è a un elemento è stato quando un partecipante, che è un responsabile di sviluppo, cominciato molto è stato esaminato l'esperienza. Devo sottolineare è stato appena illustrato l'esperienza proposta senza le informazioni di background. Come si è reso conto è stato visualizzato, ha iniziato a porre domande dettagliate e ottenuto animato piuttosto come ha parlato. Ha detto che sarebbe una soluzione a un problema che si presenta con il suo sviluppatori inesperti prendere decisioni scrittura di codice che ha comportato scarse prestazioni dell'applicazione. Nel suo processo corrente, problemi di prestazioni sono state risolti attraverso il processo di revisione del codice un'operazione complessa che era una pesante imposte su quest'ultimo e il suo team. Quale ha raccontato che questa proposta potrebbe contribuire suoi sviluppatori inesperti imparare a scrivere il codice ad alte prestazioni sono stati prima crea il proprio codice. Mark ha commenti, ad esempio "questo [perftip relativo al], è possibile, criteri [Visual Studio]?" Un altro utente, dopo il riconoscimento di valore, sottolineato, "che cosa rende un notevole miglioramento Visual Studio dipende dalle capacità quando si dispone di una riga di codice!"

Questi commenti e suggerimenti anticipato anche cominciato il team su questa funzionalità potenziali da un punto di ingresso per gli strumenti di diagnostica, risoluzione dei problemi di individuazione. Il team con ipotesi che questi PerfTips potrebbe essere un trigger per gli utenti per il set di strumenti più ricche per avventurarsi.

I dettagli di progettazione

Tutto fatto fino a questo punto coinvolti solo bozze, ovvero con alcun investimento nel codice. Se idee trazione, maggiori livelli di dettagli sono stati creati in PowerPoint "click-through," e un numero elevato di alternative di progettazione per sperimentare settimanale. Tuttavia, è stato raggiunto il limite di cosa si può realizzare con bozze quando diversi problemi di ricerca è rimasta:

Convalida che la progettazione per PerfTips durante il debug di problemi comuni di logica non era una distrazione, ma è rimasta individuabile quando si lavora con prestazioni problemi.
Il team addetto agli utenti di interpretare correttamente i valori delle prestazioni, che siano stati replicati dopo l'ultima interruzione in esecuzione.
Gli utenti ha suggerito contenente solo i valori quando le prestazioni sono preoccupante, ma nessuno potrebbe suggerire agevolmente una soglia predefinita.
Per evitare l'overhead del debugger, che è possibile aggiungere molti millisecondi, potrà diminuire il valore ai clienti sono stati.

Il team ha implementato una versione minima della funzionalità che ha lavorato in condizioni specifiche. Quindi è stata creata un'applicazione con problemi di prestazioni e la logica per gli utenti di diagnosticare. Gli utenti è sono chiesto di identificare la causa del problema specifica. Se non fossero ha esito positivo, il team potrebbe determinare gli utenti non sono state corretta da cosa è stata sentita e visto. La progettazione può essere modificata e ha tentata di nuovo la settimana successiva. Inoltre, durante questo periodo versione CTP esterna è stata recapitata che è stato instrumentato, in cui è stato collegato il perftip relativo nella finestra proprietà in modo gli utenti possono facilmente modificare la soglia, se si desidera. Il team ha rilevato:

PerfTips non erano una distrazione quando gli utenti sono stati di risoluzione dei problemi di logica. In effetti, PerfTips doveva essere modificati con animazione impercettibili per renderli più evidenti quando gli utenti sono stati affrontare problemi di prestazioni.
Alcune semplici formulazione delle modifiche, ad esempio aggiungendo la parola "scaduto", cancellata backup di tutti gli utenti confusione avevo sull'interpretazione dei dati di intervallo.
Le soglie confuso solo gli utenti quando questi non visualizzati in modo coerente e non è stato identificato un semplice valore utilizzabili nella maggior parte dei casi. Alcuni utenti detto perché erano consapevoli del proprio codice migliore, che sarebbero il giudice migliore di quello che sarebbe tempi di prestazioni accettabile.
Gli utenti riconosciuto che i valori non sarebbe esatto a causa di sovraccarico del debugger, ma si dice che ripetutamente fossero correttamente con esso si sarebbe esaminando lorde differenze.

In generale, nelle diverse settimane di iterazioni, il team risultati positivi in modo coerente quando visualizzato tasking utenti per identificare l'origine dei problemi di prestazioni. Senza richiedere alcun intervento, entusiasti commenti e suggerimenti con i commenti, ad esempio, "Fantastico" assegnato a utenti e, ", è sorprendente!"

Le annotazioni

Quando prendere appunti, il team è stato illustrato come evitare disegno conclusioni finché la sessione quando si è verificato tempo sedersi insieme per discutere cosa è successo. Qual era più utili per prendere appunti molto non elaborati in tempo reale, tentando di scrivere verbatim tutto ciò che gli utenti pronunciato e delle loro azioni. Grammatica e ortografia aveva alcun problema. Queste note è diventato il riferimento del team durante l'aggiornamento stesso su cosa è successo e lasciare che disegnare approfondimenti dagli schemi che sono stati osservati in diverse settimane.

Microsoft OneNote è diventato uno strumento molto utile per tenere traccia di ciò che il team è stato pianificazione di test, le note non elaborate e redigere un riepilogo rapido. Era sempre un incaricato che ha acquisito ciò che è stato sentito e visibili. Questo ha conferito di altri team membri lascia spazio sufficiente per completamente lo stato attivo per l'utente. Per coloro che non può partecipare, le sessioni live sono stati condivisi con il team tramite Skype; ogni membro del team è stato invitato a imparare. Inoltre, le sessioni sono state registrate per i membri del team che si sono verificati conflitti riunione e si desideravano controllare in un secondo momento. Le registrazioni video anche consentono il team di esaminare le aree che è necessaria maggiore attenzione. La discussione del team sui risultati ogni settimana informato ciò che può essere effettuato la settimana successiva in cui la scrittura di un report formale era e si sono appena rallentati tutti gli elementi.

Avvolgendo

La progettazione e lo sviluppo di PerfTips è solo una sezione delle operazioni eseguite negli esperimenti settimanali. Sono state illustrate molte idee, con un massimo di quattro esperimenti per utente ogni settimana. La riprogettazione impostazioni punto di interruzione è un altro esempio di esperimenti che sono stati eseguiti settimana all'iterazione offre un'esperienza più utile e utilizzabile. Applicando Lean UX il team è stato in grado di ridurre i rischi, durante la ricerca di ispirazione da ciò che è stato sentito e si verifica durante la sperimentazione. Questi esperimenti ha richiesto le incognite equazione durante la progettazione di funzionalità. Idee provengono da molte origini e sono ispirate osservando il modo di lavorare normalmente gli sviluppatori.

Se gli utenti non è stato visualizzato il valore in un'idea, basso costo per creare un modello semplificato ricominciare. Inoltre, gli errori ti nuove idee. Mi auguro che gli esempi e suggerimenti per Lean UX offrirà l'ispirazione per fare una prova. La serie "Lean" della documentazione di riferimento in questo articolo verrà utilizzato anche come una Guida e un framework per questo approccio.

Partecipare al programma

Il team di ricerca Microsoft UX esegue la ricerca di tutti i tipi di sviluppatori per fornire feedback diretto, oltre a far parte di questo esperimento in corso. Per iscriversi, includere alcune informazioni sulle proprie competenze tecniche e su come contattare l'utente al meglio aka.ms/VSUxResearch.

Si desidera assegnare un ringraziamento speciale a tutte le persone coinvolte in un modo o un altro progetto. È possibile descrivere solo il venerdì Pulse rapido come "contiene troppi elementi," con il team di guardare, formazione e pensare molto difficile sulla distribuzione di un'aggiunta ben strutturato e risoluta a Visual Studio. Un ringraziamento speciale necessarie per passare a Dan Taylor che era necessario anticipare il team di sviluppo e che ci si sposta sfide tecnologiche con pensa?. Andrew Hall mantenuto il team di procedere con la sua conoscenza tecnica approfondita e pratico. Frank Wu mantenuto le idee di progettazione in entrata e ha la capacità uncanny riducono un'idea e trovare un modo per essere semplice.

Karl Melderlavora come ricercatore senior UX che è stato costantemente l'applicazione di sua formazione ed esperienza nella ricerca UX, informatica, dell'interfaccia utente e risorse umani fattori alla progettazione UXes. Negli ultimi 15-plus anni ha lavorato per migliorare lo sviluppo esperienza in Visual Studio per un'ampia gamma di clienti.

Grazie ai seguenti esperti tecnici Microsoft per la revisione di questo articolo: Andrew Hall, Dan Taylor e Frank Wu
Andrew Hall è un senior program manager del team del Debugger di Visual Studio. Dopo l'esportazione di scuola ha scritto applicazioni line of business prima della restituzione dell'istituto di istruzione per la laurea specialistica in informatica. Dopo aver completato una laurea specialistica, si è unito il team di strumenti di diagnostica in Visual Studio. Nel tempo in Microsoft ha lavorato nel debugger, profiler e strumenti di analisi codice in Visual Studio.

Dan Taylor è un program manager del team di diagnostica di Visual Studio e lavora sugli strumenti di profilatura e di diagnostici per gli ultimi due anni. Prima di unire il team di diagnostica di Visual Studio, Taylor è un program manager del team di .NET Framework e hanno contribuito a numerosi miglioramenti delle prestazioni per .NET Framework e CLR.

Frank Wu è attualmente si interessa principalmente sulla progettazione e offrire la migliore modifica dalla finestra di progettazione senior utente esperienza e diagnostica esperienza per tutti gli sviluppatori. Ha lavorato su software di protezione, i prodotti Windows Server e gli strumenti di sviluppo negli ultimi 10 anni dopo avere ottenuto una laurea specialistica in uomo.

Condividi tramite