Una delle conseguenze più diffuse del passaggio dalla fase di design a quella di implementazione è la perdita di parte delle informazioni che erano state acquisite nel processo di analisi dei requisiti.

La documentazione, chiara e non superflua

Le informazioni e i processi raccolti devono essere riportati a schermo e formalizzati nella maniera più semplice possibile, senza risultare ambigui, in maniera tale da conservare intatta la logica e l'espressività che hanno nella loro forma libera. Un semplice disegno non basta a tale scopo, a prescindere dal livello di dettaglio che si riesce a raggiungere.

Nella nostra esperienza abbiamo verificato che ciò che fornisce maggior supporto agli sviluppatori è dato dalla parte statica che presenta minime contaminazioni di ui, come flows o wireframes, correlati di commenti e note inerenti alle iterazioni alle quali sono stati sottoposti e in cui risultino chiare le transizioni e i passaggi di stato fondamentali.

Ultimo aspetto, ma non per importanza: la documentazione prodotta non deve essere prolissa e non deve essere contenuta in un unico file monolitico.

La forza del dialogo

I wireframe, i prototipi e in generale qualsiasi supporto che viene fornito agli sviluppatori deve essere preventivamente analizzato e discusso con loro, preferibilmente in più iterazioni. Solo in questo modo possiamo renderci conto di eventuali carenze o addirittura errori, evitando che questi si trasformino in bug o feature mal implementate durante la stesura del codice.

Affinchè tale processo possa risultare utile, tutti i soggetti coinvolti nel confronto devono partecipare attivamente eprimendo le loro opinioni e i loro dubbi senza alcuna forzatura o forma di soggezione.

Il rispetto degli accordi e delle convenzioni

L'opera di stesura della documentazione è un patto tra designer e sviluppatore. Molte delle features e degli elementi vengono battezzati con un nome; i vincoli, le validazioni e il comportamento dell'interfaccia grafica viene esplicitato. E' importante che tutto ciò venga preservato e mantenuto in un corretto ordine, poiché a causa di imprevisti o carenza di tempo spesso ci si trova a dover fare modifiche "al volo", senza che queste possano essere preventivamente documentate prima di procedere alla loro effettiva implementazione.

E' importante che il designer conosca le terminologie e i limiti tecnici più importanti lato sviluppo e che filtri per i developer le informazioni che potrebbero causare un sovraccarico nel processo di ragionamento; è altresì fondamentale che chi sviluppa non prenda decisioni di sua spontanea volontà senza prima averle sottoposte al vaglio del gruppo di lavoro, il che non significa schedulare una riunione ad ogni piccola perplessità, ma semplicemente sollevare anche un piccolo quesito e attendere una risposta.