Esiste un sistema di specifiche per la progettazione grafica?

Esiste un sistema di specifiche di progettazione comunemente usato per presentare un progetto grafico a un cliente prima di iniziare l'implementazione? La mia sfida riguarda in particolare gli invii (PDF A4, HTML inviati per posta), ma sono felice di ricevere informazioni da altri domini (web design, pubblicità, ...)

Il mio obiettivo è presentare un documento che il cliente potrebbe firmare e rappresentare il progetto reale. Una volta che il documento è stato firmato, possiamo iniziare l'implementazione; e hanno pochissimo rischio che il cliente non sia soddisfatto del prodotto reale; o richiedere molte modifiche in seguito.

In particolare, sto cercando di evitare più round trip dopo l'implementazione in cui il cliente chiede: "Puoi spostare questa scatola un po 'a sinistra?", "Hum, puoi spostarla un po' in basso?", "Può l'immagine potrebbe essere un po 'più blu? "," Hum, questo campo può essere un po' più grande? "," Funziona bene in GMail, ma non sono contento di Lotus Notes! "

Capisco che gli approcci iterativi, fatturati come Tempo e Materiale, o con uno sforzo limitato, probabilmente sono più adatti a questo. (e se li usi, come designer professionista, per favore fatemelo sapere anche io). Tuttavia, in alcuni progetti, il cliente ha bisogno di un approccio a cascata per alcuni motivi. Mi piacerebbe sapere come gestire al meglio quei casi.

Non puoi fare Agile con la stampa. Non c'è iterazione. Una volta acceso, è acceso.

Tuttavia, il processo di progettazione fino a quel momento può essere iterativo come desideri. Assicurati di fatturare di conseguenza, ovviamente.

In genere vengono creati mock-up (per la progettazione di stampa, può essere semplice come le stampe laser a colori). Ad un certo punto, si desidera che i modelli "finali" vengano firmati.

Quindi passa alla prestampa, dove dovrebbe essere creata una "prova" che è essenzialmente il modello, ma le dimensioni effettive e il colore effettivo. Questo deve quindi essere verificato sia dal progettista che dal cliente. Se va bene, allora è il tuo documento finale. Inizia le macchine da stampa!

Se stiamo parlando di design digitale (e-mail, web) ...

Quindi la mia risposta è un po 'diversa. Per il lavoro sul web, non esiste una "prova" in quanto non è un mezzo fisico incastonato nella pietra. Come tale, incoraggio vivamente a spostare LONTANO dai documenti di approvazione e ad adottare invece una metodologia Agile. Questa può essere una sfida dato che così tanti clienti e organizzazioni hanno ancora familiarità con i vecchi modelli di caduta d'acqua in cui sono avvenute le approvazioni in punti molto specifici lungo la strada.

Indaga su "Lean UX" per trarre ispirazione su come lavorare il design nel modello agile.

Dopo aver letto l'ottima risposta di DA , e poiché sto usando Scrum (Agile) per lo sviluppo web e la progettazione di interfacce, volevo condividere la mia esperienza in questi due casi.

Perché facciamo software, lavoriamo con Scrum Sprint. Ci è voluto un po 'di tempo per adattare la metodologia al lato progettuale del processo (la parte più difficile per me è stata quella di calibrare i tempi, è abbastanza difficile immaginare quanto tempo dovrebbe impiegare qualcosa di creativo!).

Quello che faccio ora è il seguente: di solito ho un grosso arretrato per l'interfaccia utente . I compiti al suo interno vanno dalla ricerca e dai modelli alla revisione, esecuzione e test. Nella pratica, deridere di solito significa creare immagini piatte e condividerle con il team. Abbiamo incontri mattutini ogni giorno, quindi a volte li usiamo per discutere delle proposte.

Discutere se stesso e la "forma" che assume non è così importante (e-mail, riunioni), l'importante è questo: una volta che una task card viene spostata nella colonna "Fine", non può tornare indietro. Se dobbiamo apportare nuove modifiche, creiamo una nuova carta in Inaspettato o la lasciamo per lo Sprint successivo. Tutti nel team si sono abituati a questo, non sposti una carta su Fatto finché non sei sicuro che sia effettivamente fatto (teniamo un elenco di cose da controllare prima di spostare una carta, solo per essere sicuri). Se vengono aggiunte nuove funzionalità o si devono ripensare le cose, le istruzioni vengono aggiunte al backlog e scegliamo il momento migliore per eseguirle.

Ora, questo probabilmente non è qualcosa che puoi effettivamente fare con i singoli clienti, quindi la mia risposta è limitata a uno scenario diverso (a meno che tu non possa addestrare i tuoi clienti in Scrum e loro possano avere accesso alla scheda Attività!). Per i singoli clienti, penso che una comunicazione chiara e un buon contratto che ti proteggano da infinite modifiche sia l'approccio migliore che puoi adottare.