Uno sviluppatore dovrebbe eseguire prototipi dell'interfaccia utente se non ci sono designer nel progetto?

Sto lavorando con un piccolo team che crea un'applicazione Web proprietaria e UX non è una priorità poiché le nostre persone saranno quelle che la gestiscono, ma cerchiamo di semplificare il loro lavoro.

Come sviluppatore, dovrei creare un mockup dell'interfaccia utente prima di iniziare a creare una nuova schermata? Niente di troppo elaborato, principalmente il layout generale per discuterne con i colleghi e avere un modello di riferimento. Lo stavo confrontando con la creazione di alcuni diagrammi UML prima di approfondire la scrittura del codice alla cieca.

Uno dei miei colleghi dice che è assurdo e non è il mio lavoro farlo.

Lavoro molto spesso in tali progetti e la risposta è un SI clamoroso e il più presto possibile.

Le persone trovano molto più facile criticare migliorare alcune bozze piuttosto che trovare una soluzione da zero. Quindi inizio a redigere in anticipo per due motivi:

• Dai agli esperti della materia un'impressione su come le informazioni potrebbero essere presentate.
• Mostra la mia attuale comprensione del problema e delle strutture informative.

In rari casi è stato anche bello avere delle prove del fatto che ho effettivamente consegnato quello che avevamo concordato ...

I modelli sono fantastici e non c'è motivo per cui uno sviluppatore non dovrebbe farli. (Può anche essere utile per uno sviluppatore fare una bozza approssimativa di un layout dell'interfaccia utente anche quando ci sono progettisti dell'interfaccia utente nel progetto.)

Consiglio vivamente di non creare modelli che assomiglino a schermi reali. Se li condividi con utenti finali che spesso si concentrano su cose che non contano come i colori e i temi. Quello che consiglio di fare è creare schizzi disegnati a mano su carta o lavagna. O se li vuoi al computer usa qualcosa come Pencil Project o Visio ( ecco alcuni stencil di Visio di Jonathan Abbett che sembrano disegnati a mano.)

Si assolutamente.

Non lasciare che qualcun altro ti dica come fare il tuo lavoro. E hai ragione, è molto simile a fare UML per il tuo modello di dati. Supponendo che tu sia uno sviluppatore, il tuo compito è fornire software di qualità. Se i modelli ti aiutano a farlo, allora fa parte del tuo lavoro.

Fai modelli a bassa fedeltà - non farli sembrare veri schermi. Perderai troppo tempo a regolare caratteri, pixel e bordi e i tuoi utenti ossessioneranno tali dettagli piuttosto che concentrarsi sulla funzionalità. Qualcosa come il balsamiq è ottimo per questo, non ci sono altri strumenti simili. Con il mockup in mano diventa molto più facile discutere le caratteristiche del progetto con i tuoi utenti e con gli altri membri del team di sviluppo.

Quando si progetta "una nuova schermata", si desidera prima discutere l'idea approssimativa dell'interfaccia utente con un utente e / o i propri colleghi. Non puoi discuterne con un utente "in codice" o "in UML", che semplicemente non funziona (non funzionerà nemmeno tra i programmatori). E dovresti aspettarti di dover buttare via i tuoi primi due o tre scetch, o almeno riorganizzare pesantemente gli elementi dell'interfaccia utente.

Quindi, se si dispone di uno strumento di progettazione grafica dell'interfaccia utente che consente di farlo rapidamente, ha senso utilizzarlo. Tuttavia, se è necessario codificare manualmente gli elementi dell'interfaccia utente e buttare via o riorganizzare gli elementi dell'interfaccia utente richiede un grande sforzo, ovviamente ha più senso non "codificare" prima l'interfaccia utente. Sarà molto più efficace creare mockup separati, sia usando uno strumento di disegno grafico, sia semplicemente usando carta e matita.

Non necessariamente. Ci sono almeno due ragioni per cui i modelli potrebbero essere di scarsa utilità.

In primo luogo, se esistono pratiche consolidate nel settore per quanto riguarda le cose che stai per fare, puoi semplicemente andare avanti e fare esattamente questo. Non spingerai avanti l'arte della progettazione dell'interfaccia utente, ma è altrettanto.

In secondo luogo, gli utenti finali spesso non sanno cosa è buono per loro e perché. Non possono dirlo fino a quando non iniziano a utilizzare il programma (con dati reali o fittizi). Nessuna quantità di modelli statici sarà di aiuto.

Con un framework Web modestamente flessibile, per "solo un'altra schermata dell'interfaccia utente, come le precedenti schermate N", puoi iniziare con un prototipo funzionante e riorganizzare mentre procedi. Fai un modello e discuti con i colleghi ogni volta che stai per fare qualcosa di elegante.

SEMPRE!

Lavoro per una piccola azienda e sono l'unica persona IT "soft". Faccio tutti i requisiti, la progettazione, la codifica, i test (anche se qualcuno convalida sempre i miei test), la progettazione del database ecc.

MAI TAGLIARE GLI ANGOLI SUI PASSAGGI DEL DESIGN - i tuoi utenti finali ti ringrazieranno. Ringrazierai anche te stesso, perché finirai per rielaborarlo per rendere felici gli utenti finali. Anche se il tuo mockup non è altro che un pezzo di carta scarabocchiato a mano, dà loro un'idea di cosa aspettarsi. Impiegare 10 minuti per scarabocchiare qualcosa può salvare una settimana di lavoro (stato lì, fatto quello)

Ti aiuta anche nella codifica. Ti dà la possibilità di pensare a ciò che devi fare, al modo più efficiente per realizzarlo e agli eventuali ostacoli che potrebbero essere sulla strada.

Ad esempio, potresti scoprire che il rapporto "semplice" che devi creare è più difficile di quanto pensassi perché non stai acquisendo una data sulla tabella xyz. Allarga anche i tuoi orizzonti e mostra che la tua squadra, i superiori o persino possono essere utilizzati per potenziali opportunità di carriera futura che fai più del minimo indispensabile e puoi uscire da quella scatola di "non è il mio lavoro" (<--- sul serio, NON essere quel ragazzo, lo odiamo tutti) o ti dà la possibilità di apprendere ulteriormente.

Diamo un'occhiata a questo in un modo più generale:

• La creazione di bozze è una buona idea?
• Chi dovrebbe creare le bozze?

La creazione di bozze è una buona idea?

La creazione di bozze offre principalmente 2 vantaggi. In primo luogo, fornisce attenzione, il che porta ad una accelerazione del lavoro effettivo svolto. In secondo luogo, rende molto più semplice discutere della direzione del lavoro prima che il lavoro sia completo.

L'aspetto negativo di creare una bozza è che utilizza il tempo. Ha poco senso trascorrere 2 ore a creare una bozza elaborata per qualcosa che richiede 4 ore per essere creata.

Nel tuo caso, il livello del modello deve tenere conto della quantità stimata di lavoro che va nel progetto e dei benefici del progetto. A seconda di questi, il tuo mockup può essere ovunque tra uno scarabocchio di 10 secondi su un post-it e un sito Web completamente interattivo. Per progetti molto grandi e costosi non è raro che interi team lavorino su una bozza per settimane e creino bozze della bozza mentre lo fanno.

Chi dovrebbe creare le bozze?

Non è necessaria una risposta elaborata qui: se si trae vantaggio dalla creazione di una bozza, si crea una bozza. Se beneficiate del fatto che qualcun altro stia preparando una bozza per voi, chiedete a qualcun altro di fare una bozza per voi.

Il tuo collega è assolutamente corretto. Le applicazioni interne hanno generalmente un aspetto predefinito. Anche per tali applicazioni, gli utenti non sono alla ricerca di un'interfaccia utente all'avanguardia. Tutto quello che vogliono è qualcosa che funzioni ed è ragionevolmente facile da usare. A meno che tu non preveda di cambiare radicalmente l'interfaccia utente (che ti sconsiglio vivamente ... per le app interne), basta seguire l'aspetto esistente. I modelli sono fantastici, ma nel tuo caso aumenteranno solo il dolore.