Pensare ai requisiti di un sito web
Siamo nella fase di strategia[[Strategia di architettura dell’informazione]], e dobbiamo delineare i requisiti che il sito web che stiamo sviluppando avrà.
Ad essere sincero inizia ad andarmi un po’ stretta questa categorizzazione così schematica e rigida delle varie fasi, e sento il bisogno di qualcosa più flessibile, probabilmente agile è la risposta.
Comunque, ad un certo punto della strategia dovremo delineare quelle che saranno le varie funzioni del sito, che ci mettiamo dentro? Attenzione bene ho detto funzioni, non pagine.
In un sistema non ucd, si usa un modello di tipo top-down, il (o i) designer presentano una serie di funzioni da approvare al cliente, mentre un sistema bottom-up queste sono scelte insieme al cliente che diventa partecipante attivo. Forse chiamarli sistemi sistemi top-down e bottom-up non è la cosa più corretta, ma non mi veniva in mente niente altro che ci si avvicinasse così tanto.
Top-down
Comer già accennato il metodo top-down consiste in un qualcosa creato da pochi verso molti. Volendo fare un esempio generico, i contenuti di un sito web sono considerati top-down, perché sono scritti da poche persone e poi vengono letti da molti.
Un approccio di questo tipo consiste nel fornire al cliente già tutto quello che noi pensiamo poi gli servirà nel sito, esempio: un form di contatti, un sistema per gestire tramite corriere gli ordini effettuati nel loro sito, e chi più ne ha più ne metta, e il cliente deve solo accettare o negare passivamente queste cose, cosa che di solito non è in grado di fare perché non ha ben chiaro quello che il suo sito deve fare, non è stato considerato il sito come un valore aggiunto ma solo come un orpello e quindi va bene tutto. Colorato mi raccomando, che deve fare bella figura.
0 commenti
