Mockup: codifica vs disegno?

9

Non si tratta di web design ma di interfaccia in generale. È meglio codificare Interface Mockup o "disegnarli" in un programma di grafica, come GIMP, Photoshop, ecc.?

website-design  interface-design  design-process 
— Christopher
fonte
3
Mi viene sempre detto "disegna la tua interfaccia, se lo fai in Photoshop o qualunque cosa la gente penserà che tu sia più lontano di quello che sei realmente. Lascia i tuoi modelli apparentemente imprecisi, abbassa semplicemente le basi in modo che il tuo cliente sappia cosa aspettarsi e poi espandi sulla tua interfaccia utente in seguito. "
— Hanna,
1
Dipende interamente dal progetto. Non esiste una risposta "migliore" universale.
— DA01,

Risposte:

14

Ponetevi queste domande:

  • Quanti layout / opzioni dell'interfaccia utente puoi esplorare in 30 minuti tramite la codifica? Quanti ne puoi esplorare disegnando?

  • Ogni quanto tempo ottieni un design dell'interfaccia utente esattamente nel primo tentativo? Se non molto spesso, quanto è facile / veloce cambiare uno schizzo rispetto a un modello codificato?

  • Riesci a identificare istantaneamente un colore solo guardando il suo codice hex / rgb (non solo un'ipotesi di palla da baseball, ma la tonalità / colore esatti)? Quando immagini un colore nella tua mente, puoi immediatamente tradurlo in esadecimale? Quanto velocemente puoi scegliere una combinazione di colori digitando i codici esadecimali rispetto a un vero selettore di colori?

Il fatto che tu stia ponendo questa domanda mi dice che molto probabilmente sei un programmatore, non un designer, attraverso la formazione. Se tu fossi un designer, sarebbe assurdo quanto sviluppare un'applicazione senza pianificare la struttura della classe, la progettazione del database, l'architettura dell'applicazione, ecc. E saltare direttamente al codice - e se sei uno sviluppatore esperto, allora sai che tipo di problemi provoca questo tipo di sviluppo dal basso.

Allo stesso modo, se passi direttamente al codice senza prima progettare l'interfaccia utente, i risultati non saranno belli, se non altro perché non è pratico perfezionare un buon design codificando alla cieca.

— Lèse majesté
fonte
L'OP potrebbe parlare dell'utilizzo di un editor di codice WYSIWYG, con esso puoi scegliere i colori o persino "disegnare" gli oggetti ...
— jackJoe,
2
In realtà, la codifica senza prima progettare l'interfaccia utente è una tecnica abbastanza valida. Cioè, ovviamente, se "codificare" non significa parti dell'interfaccia utente o UX :). La maggior parte delle API e delle librerie sono progettate in realtà senza prendere in considerazione l'interfaccia utente, sarebbe semplicemente poco pratico.
— thebodzio,
1
@lese, stai lanciando un metodo a cascata. Che può essere OK, ma la tendenza in questi giorni è quella di diventare agili, in cui è molto probabile che tu stia lavorando nel codice dal primo giorno.
— DA01,
@ DA01: stai lavorando al codice dal primo giorno, ma stai ancora applicando una metodologia top-down. Non c'è nulla di agile che dica che non è possibile pianificare l'architettura dei dati o definire l'interfaccia utente prima della codifica (che penso che la maggior parte delle aziende agili preferisca a UML, diagrammi di classe, ecc.).
— Lèse majesté,
2
@thebodzio: Sì, certo, ecco a cosa serve la separazione delle preoccupazioni. Ma non mi riferisco alla codifica del backend. Quando dico codifica in termini di parte progettuale della domanda (non l'analogia di programmazione che ho usato per illustrare il punto - lo so, un po 'confuso), intendo codificare il mockup (CSS + HTML o qualunque sia il tuo linguaggio UI ).
— Lèse majesté,
5

Vorrei votare per "disegnare" per primo. Nella GUI, il layout / presentazione corretti è la chiave e richiede la progettazione di mezzi visivi. Progettare la GUI visivamente ti consente di cambiare rapidamente il tuo design senza dover "immaginare" ogni cambiamento, "tradurlo in codice" e infine testarlo. Anche l'altro è possibile, ma raramente è meglio (ad esempio il progetto è estremamente piccolo, come solo un paio di pulsanti e sei familiare e abituato a lavorare a livello di "codice"; durante la progettazione possono emergere alcuni schemi, che possono essere solo riutilizzato con leggera modifica).

Se stai progettando un toolkit specifico per il widget, puoi anche utilizzare alcune applicazioni "Designer GUI", se disponibili. Accelererà ancora di più il processo di progettazione della GUI, perché mostra esattamente come apparirà la GUI progettata nel programma in esecuzione e può esportare una descrizione della GUI pronta all'uso a livello di presentazione.

— thebodzio
fonte
2
"e sei familiare e abituato a lavorare a livello di" codice "-> È importante che il team UI / UX possa lavorare a livello di codice. Ogni designer non deve essere un programmatore, ma il team deve essere in grado di costruire tutto ciò che progetta e comprendere l'ingegneria tanto quanto il design visivo.
— DA01,
Posso essere d'accordo fintanto che intendi una squadra nel suo insieme. Penso che, quando stai semplicemente progettando UI / UX, non codificandolo, la conoscenza del funzionamento interno del codice può effettivamente trattenerti, perché tenderai ad evitare alcune potenziali soluzioni solo perché le considererai "troppo difficili da strumento". Significa che i tuoi progetti possono essere spogliati di alcune idee geniali, perché "il pensiero del toolkit" bloccherà parti della tua immaginazione. Poi di nuovo ... è solo un lato della lama :) Inoltre, la domanda riguardava solo i "modelli".
— thebodzio,
1
Sento molto l'argomento "trattenerti", ma trovo che provenga solo da visual designer che sono ostinatamente contrari all'apprendimento del codice del livello di presentazione. Queste persone tendono anche a spostarsi verso il fare tutto in Flash. :) Mi piace suggerire che non è diverso dal design di stampa. Sapere come funziona la stampa non ti "trattiene" come designer di stampa. Piuttosto, ti impedisce di creare file che soffocano il RIP o fanno urlare la stampante per una copertura dell'inchiostro del 300%. Si tratta solo di comprendere il mezzo e i suoi vincoli associati.
— DA01,
1
WYSIWYG non è per facilitare il "pensiero visivo". È per permettere alle persone che non vogliono imparare qualcosa di inerte. ;) Per quanto riguarda i vincoli, definiscono il mezzo. Un architetto in grado di disegnare immagini straordinarie, ma che non comprende le basi di carichi e campate, viene trattenuto in larga misura ... poiché nulla di ciò che disegnano può essere effettivamente costruito.
— DA01,
1
(e molta della mia opinione è stata formata lavorando con o su team UX che non hanno idea di come costruire qualcosa con cui escono. Non stanno innovando per la maggior parte del tempo ... ma piuttosto progettando solo una mezza idea soluzioni che non sono pratiche in termini di implementazione, tempistiche, utenti o budget [che sono tutti ulteriori vincoli che, anziché essere "muri" sono ciò che aiuta a definire la soluzione di progettazione]) PS: buona discussione!
— DA01,
3

Per la progettazione dell'interfaccia utente ho tre fasi con obiettivi diversi:

  1. Abbozzare. Innanzitutto, vuoi farti un'idea di base su quali elementi ci saranno e come si adatteranno insieme. Qualsiasi dettaglio fine o perfezionismo estetico in questa fase è una distrazione. Uso una lavagna e una grassa penna cancellabile, quindi è impossibile distrarsi da troppi dettagli e è facile scarabocchiare un sacco di idee diverse e ricominciare in qualsiasi momento. Ho sentito parlare di persone che fanno solo schizzi su piccoli post-it o usano solo la mano (ad es. Mano sinistra se si è destrorsi) per sforzarsi di non prestare alcuna attenzione all'estetica e concentrarsi al 100% sull'idea e la funzione. (immagine non mia, di Frank Prendegast )

Foto del wireframe di lavagna

  1. (2!) Simulazione.In secondo luogo, vuoi dare un'occhiata in basso e ricevere feedback, scoprendo il più possibile le intuizioni delle persone e le risposte non sollecitate prima di iniziare il lungo lavoro di implementazione. Questo dovrebbe essere in qualunque cosa tu lavori più efficacemente poiché se lo stai facendo nel modo giusto, dovresti tornare spesso al tavolo da disegno, cercare critiche e mirare a identificare il maggior numero possibile di problemi imprevisti. Se sei una pazza macchina di codifica ed è quello in cui lavori più comodamente, allora la codifica va bene, ma la maggior parte delle persone lavorerà più velocemente in qualcosa come Fireworks, Photoshop, software di wireframing dedicato o forse un builder basato su interfaccia utente come Flash Catalyst (va bene se il prodotto finale non è Flash, l'obiettivo è ottenere un buon feedback prima di iniziare l'implementazione).

  2. (3!) Implementazione. Infine, implementate la cosa e mirate a farlo in un modo che vi consenta di ottenere più feedback in anticipo e spesso.

Queste tre parti del ciclo del progetto hanno obiettivi diversi, quindi se si tratta di un grande progetto ha senso utilizzare lo strumento più adatto per il lavoro in ogni fase.

— user56reinstatemonica8
fonte
2

Questa domanda è un po 'vaga e, come tale, come lo sono le risposte.

Inoltre, i progetti varieranno selvaggiamente, così come i team.

Detto questo, non esiste un "migliore". Si tratta di utilizzare tutti gli strumenti in un flusso di lavoro che ha più senso per te e il tuo team.

In generale, direi che questo è il tipo di flusso di lavoro a cui dovresti puntare:

  1. Schizzo. Matita + carta. Lavagne. Iterate. Lavora con il maggior numero possibile di membri del team.
  2. modelli low-fi. Potrebbe essere PSD, potrebbe essere visio. Potrebbe essere di carta. L'utente prova questi.
  3. Arrivare alla costruzione di prototipi. È qui che vuoi iniziare a fare il più possibile nel codice di lavoro. Salta su Photoshop di cui hai bisogno e estrailo nel codice il più velocemente possibile. Continua test utente / iterazione.
— DA01
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.