che cosa fare quando UX richiede un design di evento brutto e contorto e non sai come implementarlo in modo pulito?

3

Mi è stato assegnato il compito di creare un'applicazione client desktop che recuperi i dati da apis web e li presenti all'utente.

Nell'ultimo mese circa, ho trascorso la maggior parte del mio tempo e delle mie energie portando in vita la funzionalità che UX ha descritto con due immagini.

Guardando le immagini, sembra un design semplice. Ci sono solo 4 controlli:

Un elenco a discesa che attiva un evento di selezione. Un altro elenco a discesa che viene popolato in base ai dati selezionati dal primo elenco a discesa e genera inoltre un evento di selezione. Due comandi radio che abilitano o disabilitano il secondo elenco a discesa. Un terzo elenco a discesa che, a seconda del pulsante di opzione selezionato per ultimo, viene popolato con i dati basati sul primo elenco a discesa o sul secondo elenco a discesa.

Non sembra difficile.

Ma poi quando effettivamente inizio a implementare questo disegno trovo che non conosco, per esempio, che cosa fare se l'utente seleziona il pulsante di opzione B (che dovrebbe abilitare il secondo elenco a discesa) ma il drop la lista in basso non ha elementi; in tal caso, impone di selezionare nuovamente il primo pulsante di opzione A? Visualizzo un messaggio di errore? Chiedo all'utente di intervenire?

Sono questi piccoli casi "d'angolo" che non salgono necessariamente alle persone che chiedono questi disegni che mi fanno chiedere se sono nella linea di business sbagliata o se sono bloccato a lavorare con persone che non lo fanno avere un'immagine chiara di ciò che vogliono o non sanno quello che vogliono, ma aspettati che io compili i punti senza fare il disegno UX da solo.

UX sta migliorando l'esperienza dell'utente, non l'esperienza del programmatore, l'ho capito, ma è questo il tipo di input che i programmatori dovrebbero ricevere da UX? I programmatori si aspettano sempre di riempire i punti, anche quando il comportamento corretto non è stato esplicitamente dichiarato?

    
posta J Smith 15.06.2014 - 16:01
fonte

3 risposte

6

In caso di dubbio, chiedere chiarimenti. Forse l'UX non sa che questi "casi d'angolo" sono possibili.

Per quanto riguarda l'esempio che scrivi, non penso che sia così complicato mentre lo dipingi. Solo dal buon senso, hai due opzioni:

  • Se non ci sono elementi per la casella personale, disabilita l'opzione B. Aggiungi un suggerimento (quando si passa il mouse o con un'icona), affermando che l'opzione B è disabilitata a causa di ciò.

  • Se c'è qualcosa che lo vieta (ad esempio, scoprire l'elenco di elementi è costoso e si desidera recuperarli solo una volta "l'opzione B" è selezionata, quindi non si sa prima di quello se la lista è vuota), quando "opzione B" è selezionata cambia il dropbown in un'etichetta che lo spiega all'utente.

Ovviamente, dipenderà da quanta libertà hai per fare il tuo lavoro. Se non hai affatto la libertà, fai il tuo lavoro come dichiarato e segnala eventuali problemi. Se non ci sono risposte, fai esattamente cosa è stato chiesto (ovviamente, allo stesso tempo, documenta tutto a CYA).

    
risposta data 15.06.2014 - 16:27
fonte
2

Stai riscontrando una lacuna nei requisiti (cosa fare quando X va storto). Questo non è raro, perché è molto difficile pensare a tutte le possibilità in anticipo.

Che cosa fare al riguardo è abbastanza semplice: chiedi al responsabile dei requisiti / storie degli utenti / ecc. di darti una guida su quale dovrebbe essere il risultato desiderato dal punto di vista dell'utente. Quindi lo implementa.

Se aspettare la risposta alla tua query ritarderebbe pericolosamente il progetto, allora dovresti implementare tutto ciò che è più facile da fare per ora e aprire un problema per creare un'implementazione corretta quando la risposta formale è nota.

    
risposta data 15.06.2014 - 16:30
fonte
1

Una delle cose che faccio in questi giorni è che chiedo esplicitamente al progettista UX di abbozzare i loro progetti di fronte a tutti noi al volo . In realtà mi sembra un buon senso e il primo UX Designer con cui ho lavorato lo ha fatto, anche abbozzando i suoi progetti alle riunioni aziendali e ne parliamo e facciamo domande come, "Cosa dovrebbe succedere se l'utente fa questo? " e poiché usava mezzi molto rapidi come matita / penna su carta o pennarello sulla lavagna, è stato facile per lei disegnare ciò che dovrebbe accadere molto rapidamente al volo.

Ed è stata un'esperienza così piacevole. L'ho dato per scontato e ho pensato che tutte le collaborazioni di progettazione UX avrebbero funzionato in questo modo.

Ma ho lavorato con due afterwords successivi e uno in particolare ha realizzato i più bei prototipi di Photoshop che praticamente assomigliavano a un prodotto finale, a parte il fatto che avrebbe passato un'intera settimana a lavorarci sopra e poi la società lo avrebbe portato a ulteriori progettiamo la nostra pagina web e saremo bloccati con domande di base come la tua e anche come, "Aspetta, come dovrebbe apparire l'interfaccia utente se è ridimensionata?" Ed era troppo impegnato per rispondere a loro ed eravamo in crisi e avremmo miseramente collegato tutti quei punti (che è qualcosa che dovresti fare se il progettista non è disponibile) solo per lui uscire dal bunker e diventare sconvolto dal fatto che abbiamo colmato tutte queste lacune.

Come risultato, ho iniziato a nutrire un strong disgusto per tali modelli elaborati e dall'aspetto grazioso all'inizio, perché richiedono troppo tempo al progettista per fare e non rispondere a tutte quelle domande che potremmo avere. In realtà preferisco un designer che disegni rettangoli e cose su una lavagna o un blocco note o persino un tovagliolo mentre collaboriamo e risolviamo le cose. Questo è molto veloce e lui / lei può disegnare al volo le sue idee per mostrarci cosa dovrebbe accadere in ogni singolo caso. Questo è il modo giusto di farlo ora nella mia esperienza se riesci a trovare un tale designer disposto a disegnare rapidamente e poi salvare il modello di bellezza per dopo.

Are programmers always expected to fill in the dots, even when the proper behavior hasn't been explicitly stated?

Sfortunatamente nella mia esperienza di solito è il caso, ma non è stato con quel primo designer che ho menzionato. Con lei era così chiaro che cosa avrebbe dovuto accadere in ogni caso d'uso, non perché li avesse anticipati tutti (spesso facevamo qualche pausa per riflettere su qualche caso d'uso che avevamo menzionato), ma perché era in grado di abbozzare così rapidamente le cose fuori e ci parla di poter illustrare al volo le sue soluzioni alle nostre domande. Quella era una collaborazione propria , non come, "Qui, ho passato una settimana a disegnare questa bellissima immagine - ora vai a codice."

    
risposta data 20.12.2018 - 01:26
fonte

Leggi altre domande sui tag