Perché eseguire il rendering dei progetti?
Come usi i mockup, in particolare i mockup di alta qualità (non wireframe), nel tuo processo di progettazione e perché / li consiglieresti?
Sono uno sviluppatore, in passato i proprietari dei prodotti a volte davano requisiti sotto forma di prototipi, ma anche in questo caso generalmente mi ha colpito il fatto che avrebbe potuto essere comunicato senza tutto il lavoro extra (0 abilità artistiche con una penna e lo schizzo di carta sarebbe stato sufficiente).
La scorsa settimana stavo guardando alcuni video di YouTube per trarre ispirazione dal design per un progetto secondario / hobby su cui sto lavorando e mi sono ritrovato a emulare parte di ciò che stavano facendo, ma mi sono fermato quando mi sono reso conto che lo sforzo non era proseguito. La maggior parte del software di progettazione che ho visto assomiglia più a Photoshop che a un browser Web, quindi il normale lavoro su tela / tavolozza non si traduce facilmente in (S) CSS: non ho mai (* non dai primi anni 2000) lavorato un progetto che utilizzava un'immagine di sfondo, quindi non sono sicuro del ruolo che lo schizzo gioca in un ciclo di vita di progettazione / sviluppo?
Non sto battendo i designer o il lavoro che fai - Ricordo Internet alla fine degli anni '90 e non voglio tornare indietro, sto solo lottando per capire perché le aziende spendono così tanto tempo / denaro per generare arte digitale di alta qualità - che poi deve essere tradotto in immagini, HTML e CSS?
Risposte
Penso che lo scenario ideale sia avere designer che codificano il front-end. Ma la realtà è che la maggior parte dei designer non lo fa. Tuttavia, ci sono sempre più posti in cui questa è la norma.
Dal punto di vista del designer, i design servono principalmente a 3 obiettivi principali:
- Critica all'interno del team
- Prova con gli utenti
- Discuti con i clienti
Gli schizzi di carta non possono essere utilizzati per nessuno dei precedenti, anche i wireframe sono difficili da capire per i clienti e alcuni utenti. Poiché ogni elemento ha il suo scopo, disegnare su carta (come disegnare su una lavagna) è il migliore per facilitare una rapida discussione su qualcosa di minore o un'idea, non può rappresentare cose come il marchio, l'aspetto grafico.
Un altro punto in cui brilla è ritrarre le prime idee approssimative da modificare rapidamente. Ci sono cose chiamate prototipazione in carta, o modelli di prodotti in cartone, ecc. Sono spesso usati per scorrere uno scenario e avere un'idea di come ci si sente ad usare il prodotto e se la visione ha dei grossi buchi. È facile perdere cose importanti quando non si recitano.
Ora, entrambi i prototipi hifi e html / css diretti soddisfano i punti precedenti. Dipende solo dal progettista e dai processi interni dell'azienda. Non esiste una regola che stabilisca che i prototipi hi-fi sono un must.
Ciò che usi dipende da ciò di cui hai bisogno e dai vincoli del progetto. Hai bisogno di comunicare qualcosa che può essere fatto disegnando su carta? Per favore, fallo, non perdere tempo. Fallo in qualsiasi momento in qualsiasi momento del progetto. Hai bisogno di testare con gli utenti? i clienti capiscono solo roba hi-fi? I designer vivono in html / css? Sentiti libero di saltare Photoshop / Figma / Sketch, ecc. Hai un cliente che richiede di esplorare 2 strade molto diverse? costa meno iterare sugli strumenti di prototipazione? Quindi salta per un po 'html / css.
In molti modi, il flusso di codice wireframe> photoshop> è legacy. Gli strumenti ora stanno fondendo wireframe e Photoshop con regole logiche. Alcuni di questi strumenti di prototipazione iniziano a complicarlo così tanto (in pratica diventano rappresentazioni visive del codice) che ti chiedi se sia più veloce solo farlo direttamente su javascript (che è se sei tecnico). Sono sicuro che questa evoluzione continuerà a muoversi sempre più solo in codice. Il campo si sta evolvendo, entrano molte nuove persone che non sono tecniche. E gli strumenti che vedi sono adatti a loro, non ai front-dev.
C'è anche questo concetto di fedeltà. Più qualcosa assomiglia al prodotto finale, più le persone credono di non poter fornire feedback e modifiche. Si tratterranno anche se dici loro che è giusto dare. Quindi un wireframe inviterà naturalmente più di qualcosa che sembra lucido e finito. Mostrare a un cliente un design raffinato potrebbe non darti il feedback che cerchi. Ma ancora una volta, potresti invece codificare un wireframe. Nessuno sta dicendo che non puoi.
Perché i designer non lo fanno esclusivamente per comunicare con gli sviluppatori, ma piuttosto per comunicare con utenti e bistecche.
Come provi una soluzione di design che hai scritto con carta e penna? Come scopri quale soluzione genera una conversione migliore? Come fai a sapere se devi adattare la tua soluzione perché gli utenti hanno difficoltà a capire, ecc.?
I progettisti lo fanno in modo da poter elaborare qualcosa insieme ai portabistecche, che di solito sono persone di tipo visivo e anche per convalidare il loro lavoro testandolo con gli utenti.
Alla fine la soluzione di progettazione viene trasferita agli sviluppatori e strumenti come sketch, adobe xd ecc. Forniscono un modo con uno sforzo piuttosto piccolo per comunicare attributi di stile ecc. Agli sviluppatori dal lavoro che hai già fatto.
Abbiamo rinunciato ai progetti di rendering effettivi nel mio lavoro alcuni anni fa. siamo passati ai prototipi rapidi utilizzando proxy / mock json come backend. i nostri stakeholder hanno la sensazione di una vera app e possono criticarla fin dall'inizio senza che sia stato sviluppato alcun codice di backend. Siamo tutti anche bravi progettisti dell'interfaccia utente e usiamo bootstrap come base. Dopo che il nostro prototipo è stato fatto / approvato, iniziamo il backend perché il front-end è letteralmente già fatto. Usiamo un framework javascript personalizzato chiamato atomic stack scritto da Tyree Jackson. Controlla!