Conferenza 14.

Progettazione dell'interfaccia utente I principi e le fasi di base della progettazione dell'interfaccia utente: selezione della struttura del dialogo, sviluppo di uno script di dialogo, definizione e posizionamento dei componenti visivi. Interfacce flessibili. Strumenti di supporto utente, Sistemi di aiuto

Interfaccia utente  - questa è una combinazione del modello informativo dell'area problematica, i mezzi e i metodi di interazione dell'utente con il modello informativo, nonché i componenti che assicurano la formazione del modello informativo durante il funzionamento del sistema software (diapositiva 14.1) .

Un modello informativo è inteso come una rappresentazione condizionale di un'area problematica, formata utilizzando oggetti informatici (visivi e sonori) che riflettono la composizione e l'interazione dei componenti reali dell'area problematica.

Mezzi e metodi di interazione con il modello informativo sono determinati dalla composizione dell'hardware e del software disponibili per l'utente e dalla natura del problema da risolvere. L'efficacia dell'utente è determinata non solo dalla funzionalità dell'hardware e del software a sua disposizione, ma anche dalla disponibilità di queste funzionalità per l'utente. A sua volta, il pieno utilizzo delle potenziali capacità delle risorse disponibili dipende dalla qualità dell'interfaccia utente.

La qualità dell'interfaccia utente è una caratteristica indipendente del prodotto software, paragonabile per importanza a indicatori quali l'affidabilità e l'efficienza dell'uso delle risorse informatiche.

Secondo una ricerca condotta da Xerox e dal suo dipendente David Liddle, l'interfaccia utente è costituita dai seguenti componenti principali, presentati sotto forma di un iceberg.

Secondo questo studio, l'interfaccia è composta da tre parti principali: il flusso di informazioni all'utente, l'interazione e le relazioni tra gli oggetti. Inoltre, la parte "visibile" dell'iceberg è molto più piccola della sua parte "invisibile" nascosta (diapositiva 14.2). La punta dell'iceberg è l'informazione per gli utenti (colore, animazione, suono, forma degli oggetti, posizione delle informazioni sullo schermo, grafica) è solo del 10% e non è affatto il componente più importante dell'interfaccia utente. La parte successiva dell'interfaccia utente (30% del modello del designer) è la tecnica di comunicazione con l'utente e feedback con lui. E infine, la parte inferiore dell'iceberg (60%) del modello del designer - la parte più importante di esso - sono le proprietà degli oggetti e il rapporto tra loro.

14.1. Fondamenti di progettazione dell'interfaccia utente

Il vantaggio principale di una buona interfaccia utente è quello l'utente sente sempre che controlla il software, non il software lo controlla.

Per creare una tale sensazione di "libertà interna" per l'utente, l'interfaccia deve avere un numero di proprietà (diapositiva 14.4) :

La naturalezza dell'interfaccia.

Coerenza dell'interfaccia

Cordialità dell'interfaccia (Principio del "perdono dell'utente")

Il principio del "feedback".

La semplicità dell'interfaccia.

Flessibilità dell'interfaccia.

Appello estetico.

La naturalezza dell'interfaccia.  Un'interfaccia naturale è quella che non obbliga l'utente a cambiare in modo significativo il modo in cui vengono utilizzati per risolvere il problema. Ciò, in particolare, significa che i messaggi e i risultati generati dall'applicazione non dovrebbero richiedere ulteriori spiegazioni.

Coerenza dell'interfaccia  La coerenza consente agli utenti di trasferire le conoscenze esistenti a nuove attività, apprendere più rapidamente nuovi aspetti e quindi concentrarsi sull'attività in corso e non perdere tempo a comprendere le differenze nell'uso di determinati controlli, comandi, ecc. Assicurando la continuità delle conoscenze e delle abilità acquisite in precedenza, la coerenza rende l'interfaccia riconoscibile e prevedibile.

La coerenza è importante per tutti gli aspetti dell'interfaccia, inclusi i nomi dei comandi, la rappresentazione visiva delle informazioni e il comportamento degli elementi interattivi. Per implementare la proprietà di coerenza nel software creato, è necessario tenere conto dei suoi vari aspetti.

Coerenza all'interno del prodotto.Lo stesso team deve svolgere le stesse funzioni ovunque si incontri e allo stesso modo.

Coerenza all'interno dell'ambiente di lavoro.Mantenendo la coerenza con l'interfaccia fornita dal sistema operativo (ad esempio Windows), un'applicazione utente può "fare affidamento" sulle conoscenze e le competenze dell'utente che aveva precedentemente ottenuto lavorando con altre applicazioni.

Coerenza nell'uso delle metafore.Se il comportamento di un oggetto programma va oltre ciò che di solito si intende con la sua metafora corrispondente, l'utente potrebbe avere difficoltà a lavorare con tale oggetto.

Interfaccia amichevole (Il principio di "perdono dell'utente").  Gli utenti di solito apprendono le funzionalità di lavorare con un nuovo prodotto software per tentativi ed errori. Un'interfaccia efficiente dovrebbe tenere conto di questo approccio. In ogni fase del lavoro, dovrebbe consentire solo una serie appropriata di azioni e avvisare gli utenti di situazioni in cui possono danneggiare il sistema o i dati; ancora meglio se l'utente ha la possibilità di annullare o correggere le azioni eseguite.

Anche con un'interfaccia ben progettata, gli utenti possono commettere alcuni errori. Questi errori possono essere di tipo "fisico" (selezione casuale del comando o dei dati errati) o "logico" (prendere la decisione sbagliata di scegliere il comando o i dati). Un'interfaccia efficace dovrebbe prevenire situazioni che potrebbero causare errori. Dovrebbe anche essere in grado di adattarsi ai potenziali errori dell'utente e facilitare il processo di eliminazione delle conseguenze di tali errori.

Il principio del "feedback".  Fornisci sempre feedback per le azioni dell'utente. Ogni azione dell'utente dovrebbe ricevere una conferma visiva, e talvolta valida, del fatto che il software abbia accettato il comando inserito; tuttavia, il tipo di reazione, se possibile, dovrebbe tener conto della natura dell'azione eseguita.

Il feedback è efficace se viene implementato in modo tempestivo, ad es. il più vicino al punto dell'ultima interazione dell'utente con il sistema. Quando un computer elabora un'attività in entrata, è utile fornire all'utente informazioni sullo stato del processo, nonché la possibilità di interrompere questo processo, se necessario. Nulla confonde un utente non molto esperto come uno schermo bloccato, che non reagisce alle sue azioni. Un tipico utente è in grado di sopportare solo pochi secondi di attesa di una risposta dal suo "interlocutore" elettronico.

La semplicità dell'interfaccia.  L'interfaccia dovrebbe essere semplice. Allo stesso tempo, ciò non significa semplificazione, ma facilità di studio e utilizzo. Inoltre, dovrebbe fornire l'accesso all'intero elenco di funzionalità fornite da questa applicazione. La realizzazione dell'accesso a un'ampia funzionalità e la garanzia di semplicità di lavoro si contraddicono a vicenda. Lo sviluppo di un'interfaccia efficace è progettato per bilanciare questi obiettivi.

Uno dei modi possibili per mantenere la semplicità è quello di visualizzare sullo schermo le informazioni che sono minimamente necessarie per l'utente per completare il passaggio successivo dell'attività. In particolare, dovrebbero essere evitati nomi o messaggi dettagliati dei comandi. Frasi mal concepite o ridondanti rendono difficile per l'utente estrarre informazioni essenziali.

Un altro modo per creare un'interfaccia semplice ma efficace è posizionare e presentare elementi sullo schermo, tenendo conto del loro significato semantico e della relazione logica. Ciò consente di utilizzare il pensiero associativo dell'utente nel processo.

Un altro modo per controllare la complessità delle informazioni visualizzate è utilizzare divulgazione sequenziale (finestre di dialogo, sezioni di menu, ecc.). La divulgazione sequenziale implica una tale organizzazione di informazioni in cui in ogni momento sullo schermo c'è solo quella parte di essa necessaria per eseguire il passaggio successivo. Riducendo la quantità di informazioni presentate all'utente, riducendo così la quantità di informazioni da elaborare. Un esempio di tale organizzazione è un menu gerarchico (a cascata), ogni livello del quale visualizza solo quegli elementi che corrispondono a un elemento selezionato dall'utente a un livello superiore.

Uno dei fondamenti metodologici dell'organizzazione della gestione del processo di elaborazione è l'uso di "metafore" - analoghi significativi dell'elaborazione mirata dei dati, ma in aree più comuni per l'uomo rispetto all'automazione.

Ad esempio, la metafora del "desktop" presuppone che l'interfaccia offra all'utente la possibilità di accedere a molte fonti di informazioni diverse e gli consenta di passare facilmente da una fonte all'altra (ovvero "spostare documenti sul tavolo"), cambiare un tipo di attività (foglio di calcolo ) a un altro (sistema di preparazione del testo). Allo stesso tempo, l'utente è disponibile anche in qualsiasi altro modo, compresi quelli ausiliari (calcolatrice, orologio, ecc.).

L'utente può trasferire informazioni da un documento a un altro includendo le parti necessarie di un documento nelle posizioni corrispondenti di un altro documento. Questo è associato ad un'altra metafora - "buffer dell'album". Prima dell'avvento dei sistemi di elaborazione testi automatizzati, esisteva un modo tradizionale per facilitare il layout: incollare un frammento ritagliato invece di riscrivere la pagina. Le interfacce WIMP offrono funzionalità di taglio e incolla simili, ma allo stesso tempo, il buffer in cui è posizionato il frammento di taglio consente di inserire tutte le copie degli elementi di dati necessarie.

Il principio metaforico è anche la base della tecnologia WISIWIG: visualizzazione immediata sullo schermo dei risultati delle azioni. Ciò significa che lo schermo dovrebbe simulare i mezzi di stampa e, se l'utente desidera stampare parte del testo in corsivo, dovrebbe essere digitato in corsivo sullo schermo. Se il file viene distrutto, l'utente vede che il file scompare dall'elenco dei file visualizzati sullo schermo. L'interfaccia in forma naturale fornisce all'utente informazioni sullo stato dell'oggetto, confermando che l'azione è stata eseguita. Possiamo dire che questa metafora si avvicina maggiormente alla formula " Vedi cosa hai ricevuto a seguito delle tue azioni ”.

Flessibilità dell'interfaccia.  La flessibilità dell'interfaccia è la sua capacità di tenere conto del livello di formazione e produttività dell'utente. La proprietà di flessibilità implica la possibilità di modificare la struttura del dialogo e / o dei dati di input. Concetto flessibile (Adaptive) l'interfaccia è attualmente una delle principali aree di studio dell'interazione tra uomo e computer. Il problema principale non è come organizzare i cambiamenti nel dialogo, ma quali segni dovrebbero essere usati per determinare la necessità di cambiamenti e la loro essenza.

Appello estetico.  Una corretta rappresentazione visiva degli oggetti utilizzati garantisce il trasferimento di informazioni aggiuntive molto importanti sul comportamento e l'interazione di vari oggetti. Allo stesso tempo, va ricordato che ogni elemento visivo che appare sullo schermo richiede potenzialmente l'attenzione dell'utente, che, come sapete, non è illimitata.

La qualità dell'interfaccia è difficile da quantificare, ma una valutazione più o meno obiettiva di essa può essere ottenuta sulla base dei seguenti indicatori particolari.

Il tempo necessario affinché un utente specifico raggiunga un determinato livello di conoscenza e abilità per lavorare con l'applicazione.

Conservazione delle competenze lavorative acquisite dopo un po 'di tempo (ad esempio, dopo una pausa di una settimana, l'utente deve eseguire una determinata sequenza di operazioni in un determinato momento).

La velocità di risoluzione del problema utilizzando questa applicazione; Allo stesso tempo, la velocità del sistema e la velocità di immissione dei dati dalla tastiera, il tempo necessario per raggiungere l'obiettivo dell'attività da risolvere, non dovrebbero essere valutati. Sulla base di ciò, il criterio di valutazione per questo indicatore può essere formulato, ad esempio, come segue: l'utente deve elaborare almeno 20 documenti in un'ora con un errore non superiore all'1%.

Soddisfazione dell'utente soggettiva quando si lavora con il sistema (che può essere quantificato come percentuale o come valutazione su una scala n-point).

In questa fase, i dati dell'utente vengono raccolti e analizzati, la funzionalità viene formalizzata e vengono determinati criteri obiettivi per il successo del progetto.

Formalizzazione del contesto di utilizzo

Formalizzazione di criteri oggettivi di successo

Analisi degli obiettivi

Formalizzazione dei ruoli aziendali degli utenti

Formalizzazione di funzionalità

Formalizzazione di scenari di azione dell'utente

Panoramica dell'interfaccia di sistema competitiva

Formalizzazione delle abitudini e delle aspettative degli utenti

Formalizzazione del contesto di utilizzo

A questo punto, vengono raccolte la maggior parte delle informazioni dell'utente. Sono descritte le seguenti proprietà del pubblico di sistema:

Caratteristiche dell'utente: esperienza informatica, conoscenza del dominio, motivi, dimensioni / importanza dei gruppi di utenti, schemi (situazioni tipiche) di utilizzo;

Obiettivi e obiettivi degli utenti;

Obiettivi del progetto: cosa ha causato la creazione del progetto, fasi della creazione del progetto, quali risultati dovrebbero essere ottenuti, quali informazioni sono necessarie e quando;

Tecnologia di sviluppo e piattaforma su cui gli utenti lavoreranno;

L'ambiente in cui il progetto verrà creato e utilizzato (fisico, di mercato, organizzativo e culturale).

All'ingresso: accesso agli utenti esistenti e potenziali del sistema, esperti e documentazione di progetto.

Output: una descrizione del contesto di utilizzo del sistema, possibilmente una descrizione più dettagliata delle proprietà dell'utente.

al piano di sopra ai contenuti

Formalizzazione di criteri oggettivi per il successo.

In questa fase, si distinguono criteri oggettivi per la valutazione dell'ergonomia dell'interfaccia, come indicatori di efficienza, produttività, soddisfazione dell'utente (nelle fasi precedenti è impossibile distinguere questi criteri).

Di conseguenza, in questa fase, viene creato un vero compito per la progettazione dell'interfaccia. Per esempio:

Un gruppo di utenti cambia costantemente la sua composizione e il modello di utilizzo previsto viene utilizzato di rado. È necessario concentrarsi sulla facilità di comprensione dell'interfaccia.

La stessa attività viene ripetuta più volte e il gruppo di utenti è piuttosto grande. È necessario concentrarsi sull'efficienza dell'uso.

il 20% riduce il numero di errori umani.

All'ingresso: accesso a utenti, esperti e documentazione di progetto.

In uscita: un elenco di criteri oggettivi per il successo.

al piano di sopra ai contenuti

Analisi degli obiettivi

Lo sviluppatore deve essere chiaramente consapevole che gli utenti non hanno bisogno di strumenti per conto proprio, hanno solo bisogno dei risultati del loro lavoro. Nessuno ha bisogno di un elaboratore di testi: hai bisogno della possibilità di scrivere comodamente testi. Nessuno ha bisogno di un programma di elaborazione delle immagini: sono necessarie immagini già elaborate. Ciò significa che le funzioni stesse non sono necessarie o importanti per nessuno. Le persone hanno bisogno di uno strumento in generale che consenta di svolgere qualche lavoro.

La differenza negli approcci alla scelta della funzionalità è convenientemente illustrata dall'esempio di un tostapane. L'approccio standard, in cui le funzioni sono selezionate virtualmente in modo arbitrario, nel migliore dei casi porta al seguente compito: "Abbiamo bisogno di una scatola con uno stretto foro rettangolare e un riscaldatore all'interno". L'analisi degli obiettivi dell'utente porterà a una diversa formulazione: “Abbiamo bisogno di pane tostato. Sembra che il modo più semplice per raggiungere questo obiettivo sia quello di creare una scatola con un foro a forma di un pezzo di pane e un riscaldatore all'interno. D'altra parte, sembra che questo metodo non sia l'unico ”. La seconda opzione, con il pieno sviluppo di questo metodo, può portare non solo alla creazione di un tostapane, ma anche a un tostapane (cioè un dispositivo in cui è possibile friggere non solo pane).

Il risultato di questo processo dovrebbe essere un elenco di obiettivi, ad esempio per un tostapane, l'elenco finale degli obiettivi dovrebbe apparire molto semplice: “Deve friggere piccoli pezzi di cibo, principalmente pane”.

All'uscita: raccomandazioni per l'ottimizzazione dell'interfaccia, un elenco di soluzioni di interfaccia di successo e non riuscite (l'attenzione principale è rivolta alle soluzioni che non hanno successo). Se in questa fase è stato effettuato il test di usabilità della versione corrente, il rapporto contiene brevi protocolli e un elenco dei risultati dello studio.

All'ingresso: accesso a utenti, esperti e documentazione di progetto

All'uscita: un elenco di obiettivi per l'introduzione di una nuova interfaccia con le caratteristiche di peso di ciascuno.

al piano di sopra ai contenuti

Formalizzazione dei ruoli aziendali degli utenti

La funzionalità di qualsiasi sistema è suddivisa in diversi ruoli utente: diversi utenti necessitano di diversi blocchi di funzionalità (nei sistemi di automazione, questi ruoli sono chiamati ruoli aziendali). La navigazione del sistema dipende direttamente da questi ruoli, poiché all'interno dello stesso ruolo non è consigliabile includere funzioni di qualcun altro nella navigazione. Di conseguenza, in questa fase, vengono evidenziati i ruoli principali degli utenti con funzioni correlate a questi ruoli. Inoltre, in questa fase, si svolgono interviste con ciascuno dei rappresentanti di un determinato ruolo al fine di identificare le caratteristiche di questo ruolo e scoprire quali ulteriori opportunità (in relazione alle formali) dovrebbero essere fornite.

In questa fase, puoi applicare il metodo di monitoraggio delle persone che svolgono il loro compito utilizzando gli strumenti esistenti, ed è il sistema di concorrenti (se presenti) e oggetti del mondo reale. Una buona fonte di materiale per l'analisi spesso non è nemmeno osservare le persone, ma analizzare i risultati del loro lavoro - se si scopre che il risultato del lavoro è praticamente indipendente dallo strumento utilizzato, significa che è necessaria solo la funzionalità che ha influenzato il risultato (ad es. non sono necessarie funzioni che nessuno ha usato).

Di solito ci sono diversi modi per implementare la stessa funzione. L'analisi delle azioni dell'utente consente solo di determinare quale metodo deve essere implementato. Poiché in questa fase apprendiamo quale tipo di funzionalità è necessaria per ciascun ruolo aziendale, possiamo scegliere la strada giusta in base alla regola "meno azioni un utente ha bisogno, meglio è".

Output: descrizione dei ruoli aziendali dell'utente.

al piano di sopra ai contenuti

Formalizzazione di funzionalità

In questa fase, sulla base delle informazioni generate nelle fasi precedenti, viene finalmente creato un elenco di funzionalità della nuova versione del sistema. Talvolta TK precedentemente generato non include parti della funzionalità necessaria o contiene funzionalità che non sono realmente richieste dagli utenti.

All'ingresso: accesso a utenti, esperti e documentazione di progetto, conoscenza dei principali aspetti dell'area tematica.

All'output: una descrizione della funzionalità del sistema (di solito non viene creato un rapporto sull'implementazione di questa fase di lavoro, invece, l'attività tecnica già creata viene modernizzata).

al piano di sopra ai contenuti

Formalizzazione di scenari di azione dell'utente

In questa fase, gli scenari tipici delle azioni dell'utente vengono parzialmente studiati e parzialmente sviluppati: i dati necessari agli utenti per completare il lavoro, la sequenza del lavoro stesso e i criteri per il completamento di questo lavoro vengono formalizzati.

Lo scopo di questa fase è quello di scrivere una descrizione verbale dell'interazione dell'utente con il sistema, non specificando come sta andando l'interazione, ma prestando la massima attenzione possibile a tutti gli obiettivi degli utenti. Il numero di scenari può essere arbitrario, la cosa principale è che dovrebbero includere tutti i tipi di attività che devono affrontare il sistema ed essere in qualche modo realistico. Gli scenari sono molto convenienti da distinguere per i nomi dei personaggi immaginari coinvolti in essi.

Supponiamo di dover sviluppare script per un futuro programma di posta elettronica. Apparentemente, per questo compito sono necessari tre scenari:

Elizaveta Petrovna lancia un programma di posta elettronica. Include il processo di download di nuova posta. Dopo aver ricevuto la posta, legge tutti i messaggi, quindi parte di essi viene eliminata e risponde a un messaggio. Quindi disattiva il programma di posta.

Andrey Fedorovich rende attiva la finestra di un programma di posta già aperto e include il processo di download di nuova posta. Dopo aver ricevuto la posta, la legge. Inoltra un messaggio a un altro destinatario, dopo di che lo elimina e ne stampa un altro. Quindi passa a un'altra attività.

È arrivato un nuovo messaggio e l'amministratore di sistema Andrey percepisce l'indicatore corrispondente. Rende attiva la finestra del programma di posta e apre il messaggio ricevuto. Lo legge e poi lo sposta in un'altra cartella. Quindi passa a un'altra attività.

Questi scenari hanno un doppio valore. In primo luogo, saranno utili per i test successivi, poiché non sono le attività astratte a essere testate, ma le operazioni specifiche incluse in questi scenari. In secondo luogo, il fatto della loro scrittura di solito, sebbene non sempre, porta a una migliore comprensione del design del sistema in fase di progettazione, spingendoci a ottimizzare immediatamente le interazioni future. In tali scenari, i passaggi non necessari sono molto chiaramente visibili. Ad esempio, nel terzo scenario, l'amministratore di sistema Andrei, dopo aver ricevuto l'indicatore, non è stato in grado di aprire immediatamente un nuovo messaggio, ma ha dovuto aprire la finestra di sistema, trovare il messaggio desiderato, aprirlo e solo successivamente leggerlo. È chiaro che è possibile eliminare in sicurezza queste fasi non necessarie già in questa fase iniziale di progettazione.

All'ingresso: accesso a utenti, esperti e documentazione di progetto, conoscenza dei principali aspetti dell'area tematica.

All'uscita: scenari di lavoro dell'utente (gli scenari sviluppati sono generalmente presentati sotto forma di diagrammi di flusso che descrivono l'intero processo di utilizzo del sistema per eseguire una determinata attività).

al piano di sopra ai contenuti

Panoramica dell'interfaccia di sistema competitiva

La maggior parte del pubblico di qualsiasi sistema ha le competenze per utilizzare diversi sistemi concorrenti; se l'interfaccia sviluppata è completamente diversa dalla concorrenza, gli utenti dovranno riapprendere. Inoltre, i sistemi concorrenti spesso contengono soluzioni efficaci che sono utili da adottare (o, più spesso, da considerare quando si progetta un'interfaccia).

Come nel caso della valutazione di esperti dell'attuale interfaccia di sistema, la relazione sull'attuazione di questa fase di lavoro contiene un elenco di soluzioni di interfaccia di successo e non riuscite; nel complesso, tuttavia, la relazione è più incentrata sulle buone decisioni.

All'ingresso: accesso a sistemi concorrenti.

Output: una panoramica dei vantaggi e degli svantaggi dell'interfaccia dei sistemi concorrenti.

al piano di sopra ai contenuti

Formalizzazione delle abitudini e delle aspettative degli utenti

In questa fase, vengono studiate le aspettative soggettive degli utenti dal sistema. Senza questo studio, è difficile o impossibile prevedere l'atteggiamento degli utenti verso il sistema futuro.

All'ingresso: accesso agli utenti.

All'output: una descrizione delle caratteristiche che l'interfaccia deve soddisfare per aumentare la soddisfazione soggettiva, un elenco di caratteristiche del sistema che sono significative per gli utenti. A seconda del metodo di ricerca scelto, contiene dati numerici o stimati.

Questo articolo sarà utile per coloro che stanno appena iniziando a creare interfacce: avrai un'idea in quale direzione muoverti. Non promettiamo nulla di nuovo agli esperti, il massimo: le tue conoscenze formeranno un quadro armonioso. Quindi da dove iniziare a progettare?

Correre per leggere libri e articoli di Google come fonte d'ispirazione non è una buona idea. Le interfacce della lettura non sono progettate e non migliorano. Certo, una teoria è buona, ma, come in ogni caso, non puoi andare lontano dalla teoria. È anche inutile fare riferimento a materiali di riferimento nella fase iniziale - questo deve essere fatto con domande specifiche. E una ricerca infinita di programmi di progettazione non genera produttività.

Quindi cosa fare per iniziare a progettare?

Innanzitutto, per iniziare, dovresti pensare al risultato: immagini (ovvero interfacce) e azioni. In secondo luogo, i passaggi specifici aiuteranno: comprendere il problema, formulare il problema, creare almeno qualcosa e quindi migliorarlo, scrivere storie (ne parleremo più avanti nel testo) o chiedere il parere di persone esperte.

Senza esperienza e la risposta alla domanda "Da dove cominciare?" la paura sorge. È spaventoso fare qualcosa di nuovo, ma non ha senso rimanere inattivi per sempre. Il primo pancake sarà ancora grumoso. Non aver paura di parlare della tua prima esperienza. Qualsiasi interfaccia che hai creato, anche se è terribile, può ancora essere utilizzata.

Crea storie

La prima cosa da capire è che le interfacce sono un linguaggio che già conosciamo. Qualsiasi utente può leggere e scrivere in questa lingua. Con errori, ovviamente, ma può. Come ogni lingua, esistono interfacce per trasmettere pensieri. È consuetudine esprimersi tra le persone, quindi il primo passo è formulare idee e creare una trama che catturi l'ascoltatore e dia slancio a tutto ciò che accade.

Per capire cosa intendiamo con il termine "storia", immaginiamo: Maxim diventa cliente del concessionario Neva Star: si è comprato una nuova auto. Quando stipula un contratto presso l'ufficio dell'azienda, il personale del concessionario auto lo informa dell'esistenza di un sistema online per i clienti in cui può vedere i suoi pagamenti, i pagamenti del prestito, i promemoria per l'ispezione tecnica e l'assicurazione, nonché le notizie sul concessionario auto.

Con questo approccio, iniziamo a "sciogliere" la storia. Nel processo di inventare la storia, è molto importante elaborare tutti gli scenari possibili.

Entrando nel sistema, Maxim vede il suo primo pagamento in concessionaria, le caratteristiche della sua auto, i documenti per l'auto, il nome del suo manager. Se il suo acquisto è soggetto a qualsiasi promozione, vedrà una notifica nel sistema sulle condizioni dell'azione (ad esempio, il lavaggio gratuito di un'auto di lusso durante il mese di agosto).

A casa, Maxim sta acquisendo maggiore familiarità con il sistema. Nel processo di incontro il sistema si adatta a Maxim e mostra le informazioni più rilevanti per lui.

Senza storia, non c'è prodotto, nessun progetto, nessuna interfaccia. Una storia coerente spiegherà il comportamento dell'utente e capirà ciò che gli manca.

Interagendo con un computer, una persona cerca di non trasformarsi in una macchina, ma piuttosto di umanizzare il sistema. Qualunque funzionalità appendi, senza emozioni una persona non sarà interessata. Le persone si aspettano dal computer nuove esperienze e reazioni alle loro azioni. Le belle storie evocano una risposta emotiva: come - non mi piace, veloce - lentamente, voglio - non voglio.

Brucia con un verbo

Prima di iniziare a disegnare qualcosa, discuti in una squadra una storia coerente che stai per risolvere. Aggiungi verbi per lo sviluppo della trama, in modo da aprire rapidamente lo script per il comportamento dell'utente. La componente lettera merita un'attenzione speciale. Analizza parole e formulazioni: non importa quali aggettivi e sostantivi appaiano nella storia, nulla accadrà senza verbi.

Le distrazioni nello stile di "sarebbe bello creare pulsanti" devono essere tagliate, perché allontanano l'idea da una storia coerente. Quando si lavora sull'interfaccia, tutti dovrebbero conoscere la trama dell'interazione dell'utente con il servizio e scorrerlo nella testa. Senza una storia coerente, non è possibile ottenere interfacce coerenti.

Fammi giocare!

Un rastrello popolare che puoi calpestare è dire "Al diavolo la teoria, fammi giocare!". Naturalmente, questo è anche un modo per imparare a progettare: padroneggiamo lo strumento e lungo la strada otteniamo l'abilità. Ma il problema è che lo strumento non ti consentirà di risolverlo correttamente, questo di solito è aiutato dalla conoscenza e dall'esperienza. E così da non perdere tempo a sistemare i programmi, ne parleremo brevemente.

La creazione di un'interfaccia complessa e buona è un processo che riunisce specialisti in vari campi. Ci vuole molto tempo, quindi lo sviluppo dell'interfaccia di un sito o programma è suddiviso in determinate fasi.

La divisione proposta non è universale. Ciascuna delle fasi può essere suddivisa in fasi secondarie. E via sottopassaggi secondari: ecco come appare il processo ancora più complicato, il che significa più costoso agli occhi dei clienti :-)

1. Raccolta dei dati

La raccolta dei dati è necessaria per comprendere chiaramente quale tipo di prodotto esiste al momento, cosa non soddisfa il cliente e quale risultato si aspetta dalla collaborazione. In questa fase di sviluppo dell'interfaccia del progettista del programma:

• comunica con un clientecomprendere il significato e la filosofia del programma;
• guardando gli sviluppi: prototipi già pronti (anche se esistono solo su un tovagliolo);
• analizza i programmi della concorrenza  (ed eventualmente conduce test di usabilità dei programmi della concorrenza);
• comportamenti interviste strutturate con i clienti  o potenziali clienti.

2. Progettazione

In questa fase, l'interfaccia di progettazione del programma è:

• definisce la griglia, i colori, i caratteri e lo sfondo;
• e spesso crea controlli personalizzati, come i menu a discesa.

Naturalmente, in ogni fase c'è una discussione e, se necessario, una revisione gratuita. Il tuo ordine  riceverai entrambi come file di immagine di Photoshopo nella forma Codice HTML o XAML.

4. Attuazione

Quando tutto è chiaro con l'interfaccia, la questione rimane per alcuni :) Di norma, i nostri clienti mantengono programmatori a tempo pieno e siamo attratti da varie attività relative all'interfaccia utente, dalla progettazione alla creazione di icone. Tuttavia, per quei clienti che non hanno i propri sviluppatori, offriamo lo sviluppo e il test di applicazioni Web e applicazioni mobili per iOS. Abbiamo un dipartimento permanente di sviluppatori e tester. Garantiamo: nessun libero professionista.

Nella fase di implementazione, sono in corso lo sviluppo e il testing (QA, non usabilità) del programma. Gli sviluppatori lo faranno chiaramente compresocome fare qualcosa, basato su file grafici (schizzi) e spiegazioni per loro. Altrimenti, finiremo e aggiungeremo.

Naturalmente, lo sviluppo è diviso nelle sue fasi, ma non li descriveremo qui per brevità.

5. Test di usabilità

Attrarre un buon progettista di interfacce per il progetto non eliminerà la necessità di condurre sistematicamente test di usabilità. Affidarsi solo al "ingegnoso progettista di interfacce" è dannoso per i seguenti motivi:

• ovviamente, dovresti cercare di attirare i migliori progettisti di interfacce (ad esempio VisualPharm :) per lavorare sul progetto :) Ma, sfortunatamente, questo non è sempre possibile. A volte prendono parte al tuo progetto   quelle persone che puoi attirare a luie non quelli con cui sogni di lavorare;
• il design non è una scienza esatta; anche se il tuo designer è un genio, non tutte le sue idee sono ugualmente buone. Pertanto, per ridurre il rischio, sarebbe logico sottoporre tutte queste idee alla verifica in condizioni reali con utenti reali. (ricorda, le nuove idee possono essere testate a costi minimi utilizzando tecniche come un prototipo di carta);
• come fanno generalmente i designer di interfacce a diventare buoni designer? Molto semplice: imparare dall'esperienza quali idee funzionano e quali no. ma i test sono necessari per ottenere questa esperienza, che sono condotti da esperti di usabilità;
• anche i migliori designer possono creare un prodotto di successo solo se risolvono il compito giusto. Un'interfaccia meravigliosa non aiuterà se la funzionalità è analfabeta. la comeprogettisti di interfaccescopri di cosa hanno bisogno gli utenti? La risposta è semplice: utilizzare la ricerca sull'usabilità;
• nessuno è perfetto.  Anche un ottimo design può essere migliorato se viene passato attraverso un processo graduale di miglioramento della qualità. In ogni fase, conduci test con gli utenti e, in base ai risultati, passo dopo passo, migliora la qualità dell'interfaccia utente.

• rapidamente: 2-7 giorni per test;
• a buon mercato  - uno o due ordini di grandezza più economici rispetto ai grandi studi;
• nel tuo pubblico di destinazione. La troveremo. Hai bisogno di americani del Midwest 30-55 anni, interessati alle spose russe? Per favore.

È possibile eseguire test di usabilità sia del prototipo che del prodotto finito. Raccomandazione generale - invece di un grande test fai molti piccoli test iterativi. Hanno fatto, testato, corretto, testato di nuovo. Ciò ti consentirà di trovare e correggere errori non ovvi.

Il tempismo

La durata del lavoro dipende sul numero di schermate. Progettare e progettare un singolo schermo richiede lo stesso tempo. Di solito abbiamo bisogno due giorniper creare   prototipo (o disegno) di uno schermoe altri cinque giorni per completare l'intero ordine. Pertanto, lo sviluppo (progettazione o progettazione) di cinque schermi richiederà 15 giorni lavorativi.

Effettuare correzioni su richiesta richiederà tempo aggiuntivo. Sebbene non vengano addebitati costi aggiuntivi per la modifica, possono influire sulle scadenze per il completamento di un progetto. Spesso le modifiche richiedono più tempo che direttamente per creare schermate.

Condurre test di usabilitàbisogno di circa 6 giorni lavorativi. Tutto dipende dal fatto che stiamo parlando di testare l'intera applicazione o di piccoli test iterativi.

costo del

Anche la progettazione e la progettazione di una singola schermata hanno lo stesso costo:

• design / design del primo schermo  vale la pena 48 800 r. La prima schermata è più costosa, in quanto è cruciale per l'intera applicazione. Durante lo sviluppo, dobbiamo tenere conto della struttura dell'intera applicazione;
• progettazione / progettazione di altri schermi – 18 350 r. per ciascuno.

Pertanto, lo sviluppo di un prototipo (o progetto) di cinque schermi avrà un costo di 48 800 rubli. + 18 350 rubli. x 4 \u003d 122 200 r.

stima costo del test di usabilità 52.500 rub. - 126 000 sfregamenti.

Grandi progetti

La descrizione sopra si applica ai progetti di sviluppo di piccole interfacce software. Grandi progetti  sarà utile da suddividere in attività secondarieed eseguire un ciclo per ciascuno di essi. Ad esempio, se stessimo sviluppando l'interfaccia di Skype, potremmo evidenziare i seguenti moduli:

• interfaccia di comunicazione vocale;
• interfaccia di comunicazione video;
• gestione elenco contatti;
• e così via.

Per ciascuno dei moduli elencati si consiglia di passare attraverso tutte le fasi , quindi vai al modulo successivo. Questo metodo di sviluppo è chiamato agile  (legge "agile"). È consuetudine rispettare e menzionare questa metodologia ogni volta che vuoi stupire clienti e belle ragazze :-)

Vorrei darti consigli semplici ma paradossali: non credere a tutto ciò che si dice sul design.

Il fatto è che il design nello sviluppo web per molte ragioni storiche si è sviluppato attraverso un mazzo moncone e rappresenta ancora una definizione vaga, mal descritta e mal compresa. La situazione sta gradualmente migliorando negli ultimi anni, ma c'è un sacco di lavoro esplicativo - e quindi, chiunque voglia capire il design deve girare la testa e non aver paura di mettere in discussione ogni comune, sembrerebbe, verità.

Esistono molte verità "comuni" e insieme danno origine a una serie terribile e terribile di miti del design: vorrei parlarne oggi il più importante.

Mito numero 1. Il design è un servizio aggiuntivo.

   Un importante designer di servizi pubblici

Molte persone pensano che la fase di progettazione sia un servizio aggiuntivo che può essere trascurato. Non è così.

Per cosa stiamo creando i prodotti IT? Se siamo nella nostra mente e nella buona memoria, li creiamo per la soluzione di problemi aziendali (nostri o dei nostri clienti - non è così importante); la soluzione di questi problemi aziendali, a sua volta, si basa sull'adempimento delle attività degli utenti create dal prodotto, tenendo conto delle condizioni di mercato, delle limitazioni tecnologiche e di tutto il resto.

Affinché il prodotto soddisfi tutte le condizioni, è necessario raccogliere molte informazioni contrastanti, non specifiche e difficili da raggiungere: parlare con tutti gli attori, studiare i processi aziendali correlati, conoscere sistemi esterni, guardare i concorrenti e così via, e sarebbe bello sistemare e riunire le informazioni raccolte in modo che tutti i membri del team abbiano una buona comprensione dell'input.

Successivamente, in base alle informazioni raccolte, è necessario elaborare un prodotto e inventarlo in modo tale da non contraddire le condizioni dell'attività, ma, al contrario, facilita la loro attuazione - e tale prodotto è un organismo complesso, in cui tutte le parti sono interconnesse. Il prodotto inventato, di nuovo, deve essere corretto correttamente in modo che sia il cliente che lo sviluppatore capiscano cosa otterranno alla fine (e in futuro potrebbero modificare questo prodotto).

È possibile realizzare qualsiasi tipo di prodotto complesso e utile, aggirando tutte queste fasi? D'accordo: è improbabile. Nel frattempo, tutti i processi descritti costituiscono ciò che viene chiamato design - analisi (analisi delle condizioni del problema), sintesi (formazione del prodotto) e fissazione (preparazione della corretta documentazione di progettazione).

Il design non può essere un servizio aggiuntivo.dal momento che è carne dalla carne dello sviluppo web e mira a un risultato comprensibile, e non a padroneggiare i budget o a lottare per tutto il bene contro tutto il male.

Mito numero 2. La progettazione è costosa

   Il project manager guadagna il budget dal cliente

Si ritiene che la fase di progettazione aumenti solo il costo del prodotto.

A questo proposito, adoro citare Karl Wigers, il patriarca dell'ingegneria dei sistemi, l'autore del meraviglioso libro "Sviluppo di requisiti software" e solo una persona intelligente.

Karl Wigers una volta condusse uno studio sul mercato americano dello sviluppo IT e lo calcolò il 40% dei budget di sviluppo è sprecato in mediae questi soldi non vanno persi per colpa di sviluppatori storti o clienti cattivi, ma semplicemente perché le due parti - il cliente e lo sviluppatore - proprio non potevano essere d'accordo tra loro.

Quaranta per cento - e questo è per l'America, dove regna una relazione completamente diversa tra il cliente e lo sviluppatore! Per la Russia, mi sembra, questa cifra è ancora più alta - circa una volta e mezza.

Inoltre, la corretta progettazione del sistema, secondo i calcoli degli stessi Wigers, richiede il 15-20% dei budget di sviluppo (e questa cifra è pienamente confermata dalla nostra esperienza).

Ne risulta un effetto interessante: spendiamo un 15-20% fisso nella progettazione, ma allo stesso tempo minimizziamo le spese “vuote” (lo stesso 40% del budget) che possono potenzialmente seppellire un progetto e, inoltre, ritardare notevolmente il tempo per ottenere un prodotto praticabile.

Pertanto, il costo di una corretta progettazione influenza paradossalmente il costo dell'intero progetto nel suo insieme: da un lato, la fase di progettazione non è gratuita e richiede un certo importo di budget, ma dall'altro riduce il costo dell'intero progetto a seguito della rimozione dei rischi associati a una cattiva idea e perché un prodotto imprevedibile.

Mito numero 3. Il design è la scrittura di TK

   Elefante fatto da TK

Si sente spesso che la progettazione è il processo di scrittura di TK, che può essere allegato al contratto. Non è così.

Come abbiamo scoperto durante l'analisi del mito precedente, la progettazione riduce al minimo i rischi di sviluppo. Riderai, ma questo è il suo unico e principale scopo - tutto il resto nasce armoniosamente da questo fatto:

• il design consente di tenere conto degli interessi degli utenti (e quindi minimizzare i rischi di sviluppo);
• il design consente di tenere conto degli interessi del cliente (e quindi minimizzare i rischi di sviluppo);
• il design consente di tenere conto di tutti i fattori esterni significativi (e quindi minimizzare i rischi di sviluppo);
• la progettazione consente alle parti di ottenere una visione unificata del prodotto (e quindi minimizzare i rischi di sviluppo);
• la progettazione consente di prevedere con precisione i tempi e i costi di sviluppo (e quindi ... beh, capisci).

Scrivere TK  - questo è solo uno degli strumenti che consente di fissare in modo univoco, sufficiente, sistematico e alienabile i requisiti del prodotto in un formato comprensibile per lo sviluppatore. Sì, questo strumento può essere definito il più importante, ma la fase di progettazione svolge un compito molto più importante - e questo deve essere ricordato.

Mito n. 4. Il design riguarda le interfacce utente.

Prodotto intuitivo

Per molte ragioni, la progettazione nel nostro (e non solo nel nostro) mercato dello sviluppo web è fortemente associata alle interfacce.

In effetti, le interfacce sono la parte più evidente del prodotto: è proprio con esso che gli utenti contatteranno chi eseguirà le loro attività con l'aiuto del prodotto e contribuirà così all'adempimento delle attività del cliente.

Su questa base è possibile considerare le interfacce l'unico obiettivo degno di progettazione? Certo che no: l'interfaccia è solo la parte superficiale dell'iceberg del prodotto, e se stiamo parlando di una progettazione adeguata, che minimizza davvero i rischi di sviluppo, dovremmo anche occuparci di ciò che sta accadendo all'interno del prodotto: la sua struttura dati, la sua logica comportamentale e le relazioni con l'esterno sistemi, interfacce amministrative e altro.

Interfaccia utente  - Questo è solo uno dei componenti del prodotto, che serve ad accedere agli utenti alle funzioni e ai dati del prodotto. È importante progettarlo, ma limitarlo solo a loro è dannoso.

Mito numero 5. Un manager può anche progettare

   Gestore profilo

Come abbiamo già scoperto, la progettazione è un processo complesso associato a un lavoro accurato e delicato. Affinché il progetto possa adempiere ai suoi compiti, questo lavoro deve essere eseguito nel modo più efficiente e ponderato possibile. La progettazione, in altre parole, richiede che l'appaltatore abbia un sistema di valori molto specifico, in cui la qualità del lavoro e la responsabilità personale saranno soprattutto.

Inoltre, il design viene spesso affidato ai manager come persone che riuniscono tutti i processi e i fili dello sviluppo. Sembrerebbe che tutto sia logico e corretto, ma un punto importante non viene preso in considerazione: i buoni manager hanno un sistema di valori completamente diverso, in cui i tempi del progetto e il suo budget sono in prima linea.

Nei grandi progetti, e in particolare nello sviluppo personalizzato, questo gioca uno scherzo molto crudele con i manager: se un manager affronta un dilemma, risolvere il problema associato al progetto nel suo insieme (ad esempio, tirare fuori un designer dal bere duro è una storia completamente reale, comunque) o risolvere il problema associato al design (per specificare il protocollo dati in modo più dettagliato nel ToR), quindi ogni manager sceglierà una soluzione che estinguerà gli incendi che infuriano qui e ora. In effetti, le specifiche tecniche incompiute influenzeranno da qualche parte nel lungo periodo, ma se l'incendio del progetto non si estinguerà in tempo, porterà alla perdita del progetto in questo momento. E, alla fine, come puoi scrivere TK con calma quando sei costantemente distratto dai clienti sulle sciocchezze?

E così sarà per tutto lo sviluppo. Se aggiungiamo l'aspetto professionale a questo aspetto di valore (dopo tutto, il progettista deve essere in grado di fare molto di ciò che il manager non deve sapere), allora è facile capire perché una persona separata, appositamente addestrata con il proprio sistema di valori dovrebbe essere coinvolta nella progettazione.

L'unica eccezione a questa regola è lo sviluppo interno. In condizioni in cui il manager ha un solo progetto e il problema di termini e budget non è così acuto, il manager può assumere le funzioni di un designer. È vero, in questo caso diventa un product manager - e questa è una storia separata che merita il suo articolo.

Mito n. 6. Gli psicologi devono progettare

   Il contenuto tecnico del prodotto secondo lo psicologo

Alcune aziende, anche le più grandi, credono che le persone con educazione psicologica dovrebbero essere coinvolte nella progettazione. Questo mito nasce dalla convinzione che il progettista dovrebbe difendere esclusivamente gli interessi degli utenti. Come abbiamo già scoperto, non è così: il progettista si occupa dell'intero prodotto nel suo insieme e tiene conto degli interessi sia degli utenti che del cliente, per non parlare delle specifiche del sistema. Tutto ciò richiede abilità tecniche, di cui la maggior parte degli psicologi è privata.

Un'altra cosa è che gli psicologi possono essere attratti dalla parte ristretta del design - lavorare con le interfacce o analizzare le preferenze dell'utente - ma tutto ciò dovrebbe avvenire sotto la supervisione di un progettista che terrà conto di tutti i dettagli tecnici e le sfumature.

Mito numero 7. La progettazione dovrebbe essere fatta dagli ingegneri.

Contrariamente al mito degli psicologi, esiste un mito sugli ingegneri: si dice che il progettista debba essere un programmatore. Come avrai già intuito, questa è anche una cattiva opzione: un programmatore sferico nel vuoto è in grado di riflettere sull'architettura generale del prodotto, ma è improbabile che sia in grado di rilevare con precisione gli utenti e comprendere le esigenze dei clienti. In realtà, mi sono imbattuto in tali sviluppatori, ma nella loro mentalità erano, piuttosto, designer che, per errore, sono diventati sviluppatori.

Come nel caso del mito precedente, gli sviluppatori possono essere coinvolti nella progettazione, ma solo sulla struttura dei dati e sulle descrizioni funzionali del prodotto sotto la supervisione del progettista (anche se il progettista deve farlo da solo, se necessario).

Chi è un designer?

Chi dovrebbero essere i designer? Questa è una domanda molto complessa, a cui posso rispondere brevemente in questo modo.

• Vale la pena accettare che non vengano insegnati altrove sui progettisti di sistemi "giusti".
• Molto spesso, il designer giusto nasce all'incrocio tra le arti liberali e le scienze tecniche.
• Molto spesso, un buon designer non sa di essere un buon designer e lavora nella specialità di sinistra, il che non gli piace.
• Un buon designer "non attivato" ha una storia schizofrenica, un'istruzione quasi tecnica, una visione ampia e la mentalità di un buon ingegnere classico.
• Il progettista deve comprendere designer, sviluppatori, clienti e utenti.
• Il progettista deve essere in grado di comunicare con le persone.

Personalmente, la mia esperienza dimostra che un designer è piuttosto un concetto gnnoe: addestrare il progettista gli strumenti e le tecniche necessarie possono essere relativamente rapidi (seriamente, da tre mesi a sei mesi), ma investire in lui il giusto sistema di valori e mentalità è quasi impossibile.

Ma ci sono persone così - ed è stato proprio per la loro ricerca e formazione che una volta ho creato la Gilda dei designer gratuiti, e questo è anche un argomento separato per la discussione.

Non esiste un approccio progettuale unico

   Il progettista non può sopportare le passioni sul progetto

Esistono molti approcci alla progettazione e un lettore inesperto può facilmente impazzire con un'abbondanza di tecniche, approcci e abbreviazioni generosamente conditi con un pasticcio terminologico (con tutte queste UX, UI, CX, HCD e altri IDDQD con analoghi in lingua russa storta).

Alcuni, tuttavia, stanno cercando di ricavare modelli di design universali, ma alla fine si scopre che nel tentativo di combinare i 20 approcci di design (condizionatamente) esistenti, alla fine otteniamo 21 approcci - e le metodologie sembrano iniziare a prodursi.

Gli esperti deducono su questa base che non esiste un unico approccio alla progettazione e che non può esserlo - dicono, tutto è strettamente individuale e quindi non c'è nulla da sistemare.

Questo è anche un mito che personalmente non mi soddisfa categoricamente. Esiste un unico approccio al design, ma richiede una conversazione separata, ampia e molto personale; quindi, con il tuo permesso, confuteremo questo mito un po 'più tardi - più vicino alla fine di settembre, quando il mio grande articolo su questo argomento sarà pubblicato su Cossa.

Invece di una conclusione

Quindi cosa abbiamo scoperto oggi?

• La progettazione costa e consente di ridurre il budget di sviluppo.
• Il design minimizza i rischi di sviluppo.
• Il design sostiene gli interessi del prodotto nel suo insieme.
• I designer dovrebbero essere coinvolti nella progettazione (questa è la verità, eh?).
• La progettazione è un processo ampio e complesso, che ha le sue leggi e approcci uniformi.
• Non credere a ciò che scrivono sul design - non aver paura di pensare da solo, offri le tue opinioni e difendi la tua visione.

E l'ultima richiesta: non prendere la mia parola nemmeno per me - sarò felice solo se non sarai in disaccordo con me e difenderai il tuo punto di vista: questa sarà un'occasione per una conversazione utile e grandiosa, durante la quale potrebbe apparire un'altra verità - ed è vero? non eccezionale?