it-swarm-eu.dev

Come ti assicuri di aver coperto l'intero sito nel tuo lavoro?

Sono un praticante relativamente recente e, sebbene la qualità del mio lavoro sia piuttosto buona, ho ancora un grande arretramento (secondo me): mi manca sempre qualcosa o due quando realizzo o riparo un sito web.

Ciò che intendo è quando fornisco il lavoro richiesto, scopro in seguito che ho dimenticato di progettare un'interazione, includere un collegamento, includere un elemento, correggere l'aspetto di un elemento o addirittura saltare un'intera pagina sepolta in profondità nel sito web.

Quindi, come fai ad assicurarti di aver coperto tutto nel tuo lavoro?

14
Mashhoor

Non puoi.

Il meglio che puoi fare è avere un solido processo di analisi, progettazione e documentazione che coinvolga tutti coloro che hanno bisogno di essere coinvolti sia da aziende, team di sviluppo e utenti, rivederli, rivederli di nuovo, ottenere un collega/collega per rivedere il tuo lavoro, quindi disporre di processi per la revisione del progetto durante le fasi di sviluppo, test e manutenzione per rilevare eventuali omissioni o errori.

12
Nathanael Boehm

Innanzi tutto simpatizzo e concordo con le altre risposte. Vorrei aggiungere che questa è una delle situazioni in cui le metodologie agili hanno un grande vantaggio secondo me. Forse non è del tutto rilevante per la tua situazione se lavori da solo, ma in un tradizionale processo a cascata, spesso è facile perdere le cose perché i requisiti tendono a cambiare nel tempo e le cose vengono lasciate cadere e raccolte quando cambiano le priorità. È particolarmente vero per un sito di grandi dimensioni con molti contenuti o funzionalità complesse.

Tuttavia, con un processo agile in genere stai lavorando su una sezione alla volta o costruendo a strati. Quindi, quando si passa alla successiva iterazione, è un buon momento per il tuo cliente o qualcun altro (forse il team UAT in un ambiente di sviluppo più ampio) per rivedere e testare il lavoro già completato prima che il prodotto nel suo insieme venga rilasciato. In questo modo puoi tornare a tutto ciò che è stato perso o ha bisogno di più lavoro in seguito. È possibile dividere lo sviluppo nel suo insieme in blocchi gestibili.

4
Colin Franks

Questa è una grande risorsa correlata a questo http://www.useit.com/papers/heuristic/heuristic_evaluation.html

In generale, la valutazione euristica è difficile da eseguire per un singolo individuo perché una persona non sarà mai in grado di trovare tutti i problemi di usabilità in un'interfaccia. Fortunatamente, l'esperienza di molti progetti diversi ha dimostrato che persone diverse hanno problemi di usabilità diversi.

4
Allan Caeg

Sono d'accordo con Nathanael, non puoi.

Comunque ci sono alcuni consigli che potrebbero esserti utili. Chiedi a un esperto (collega, amico) di esaminare il tuo lavoro. È così salutare che consiglio di farlo ogni volta. Fai un breve test di usabilità. Usa la checklist (puoi crearne una tua o esistente) per controllare la qualità. Puoi anche provare a eseguire casi d'uso solo per assicurarti che l'interfaccia funzioni davvero. Tutto ciò aumenta la probabilità di trovare qualcosa che ti sei perso.

2
Kostya

Sono d'accordo che la peer review sia la migliore. È anche utile se spieghi i tuoi progetti ad altri, ne hai una discussione. Anche dire queste cose ad alta voce è spesso utile per me.

E consiglierei di controllare i progetti da diversi punti di vista (utente, sviluppatore, visual designer, ecc.).

2
Zoltán Gócza

Potrebbe aiutarti a riposare più facilmente se hai riconsiderato quale sia l'obiettivo del lavoro di progettazione che facciamo.

Ricorda che la grafica, i wireframe, la persona, ecc. Non sono l'obiettivo dei designer. L'obiettivo è avere un prodotto davvero eccezionale. I primi sono solo strumenti di comunicazione che aiutano a trasformare i secondi in realtà.

Avere una documentazione di progettazione completa e accurata al 100% non è ciò a cui dovremmo puntare. Dovremmo cercare di fornire le giuste informazioni in modo che tutti i soggetti coinvolti possano lavorare insieme per creare un prodotto davvero eccezionale.

Avere un buon processo con un sacco di feedback, test e con l'intera squadra che capisce gli obiettivi del progetto sarà molto più efficace di otto raccoglitori di documentazione di progettazione che nessuno leggerà coprendo ogni possibile interazione e stato di errore in dettaglio esaustivo :-)

2
adrianh

Fai una demo

Fai finta che un pubblico molto interessato ti stia facendo davvero delle belle domande e dedica un'ora o due a rispondere a quelle domande dimostrando il sistema. Trovo più bug in questo modo rispetto a qualsiasi altro modo.

Peer Review

Qualcun altro penserà diversamente da te, farà clic in modo diverso e guarderà un sistema in modo diverso. Meno puoi dire a questa persona - il tuo secondo set di occhi - meglio è. Non vuoi guidarli accidentalmente lungo il percorso attraverso il sistema che segui sempre se non è necessario per spiegare loro il sistema.

Cambia l'ambiente

Installa il sito su un altro server. Utilizzare un browser diverso o una versione del browser diversa. Utilizzare un sistema operativo diverso. Elimina i cookie, disattiva JavaScript, blocca i cookie e riprova.

Usa un profilo di prova

Una breve descrizione di alto livello ti aiuta a visitare tutte le funzionalità di cui hai bisogno. Troppi dettagli e ti concentrerai sul test a spese della ricerca dei problemi. Anche il mantenimento di un test dettagliato richiede molto tempo. Troppi dettagli e ti perderai le aree critiche del sistema.

Rivedi il tuo lavoro ... Di nuovo

Di recente ho visto un video di grande imprenditore in cui dicevano " La differenza tra Buono e Grande è di 10 minuti ." Che hanno spiegato significa che quando scrivi la tua email completa, non la mandi. Prendi un caffè, aggira il blocco, quindi rileggi l'e-mail completa e prova il tuo sistema ancora una volta dal punto di vista della persona a cui lo stai inviando. Nel software, quella differenza potrebbe essere di 2 ore invece di 10 minuti, ma ottieni l'idea.

2
GlenPeterson

"Quindi, come assicurate di aver coperto tutto nel vostro lavoro?"

Adotti una metodologia di sviluppo del design che tenga conto di questa inevitabilità.

Questo problema si presenta di solito in una cascata (quello che chiamo processo di "catena di montaggio") in cui le cose vengono firmate prima ancora che una riga di codice venga scritta.

È impossibile progettare ogni interazione completamente su carta. Gran parte delle decisioni di progettazione dell'interazione devono essere prese con un codice funzionante. E dal momento che non hai ancora un codice funzionante, è inevitabile che ci manchino delle cose.

Idealmente, lavoreresti in un sistema più agile in cui stai progettando come codice come scritto e sia tu che lo sviluppo siete in grado di modificare le cose mentre procedete.

1
DA01

Le cose davvero difficili a cui prestare attenzione sono i messaggi di errore, poiché spesso vengono attivati ​​solo da un determinato set di input.

Spesso è necessario simulare il comportamento degli utenti "non conformi" per farli apparire (o rendersi conto che avrebbero dovuto apparire e non ...)

Ad esempio cose che affrontano il formato irregolare dei codici postali britannici ...

0
PhillipW