Un buon software, o meglio per definire un software buono, questi deve possedere un certo numero di caratteristiche (colgo l’occasione per incitarvi a commentare quali sono secondo voi queste caratteristiche… ne potrebbe nascere un articolo sul wiki). Se l’user del vostro prodotto è un “utente generico”, sicuramente sarà indispensabile la caratteristica “Stupid Proof”. Ossia, tutti quegli accorgimenti, la gestione di tutte quelle problematiche, che non sono relegate al problema in se, ma all’interazione prodotto-“utente generico”. Ad esempio:

“bisognerà sempre, e in modo quanto più esplicito, far capire all’utente generico che l’operazione che sta compiendo non è corretta”

Se il campo data blocca il focus in cui l’utente ha immesso 30/02/2006. State sicuri che vi contatterà per dirvi che il programma non funziona.

“qual’ora il prodotto sia già in produzione, bisognerà dare particolare attenzione alle modifiche dell’interfaccia grafica”

Supponete di avere un menu con 4 voci, e inserite la nuova voce come 3-ultima. State sicuri che il cliente vi contatterà per dirvi che il programma (es.: la stampa che era legata alla 3-ultima voce) non funziona più.

Beh questi sono solo alcuni esempi, resto in attesa dei Vostri

Fletto i muscoli e sono nel vuoto.