Alberto Mucignat

Alberto Mucignat


Random thoughts around web stuffs (è tutto un equilibrio sopra la follia)

dicembre: 2016
L M M G V S D
« Nov    
 1234
567891011
12131415161718
19202122232425
262728293031  

Categorie


Manager e non-designer fanno fallire il design (?)

AlbertoAlberto

Scopro solo ora una ricerca di Scott Berkun fatta nel 2008 sulle cause che portano al fallimento del design (via UX Movement).

Le due cause principali sono:

Da notare che il 49% degli intervistati sono manager o gestiscono dei team nelle aziende.

Ora, personalmente anch’io credo ci sia un problema quando un manager entra a gamba tesa e decreta un cambiamento nel design senza avere una minima idea di cosa comporti, semplicemente perché “secondo lui bisogna fare così”.

E non parliamo di colori o stile, parliamo spesso di interazioni, struttura e testi delle pagine: in questo caso per proporre dei cambiamenti pertinenti occorre avere approfondite nozioni di design.

C’è da dire che nei prodotti digitali il business viene fatto attraverso il design, quindi è necessario (ripeto: necessario) coinvolgere manager e stakeholder nel processo di design.

C’è una frase della presentazione di Berkun (pdf, 6MB) che mi è rimasta impressa:

“In many organizations, design is not seen as a critical thinking skill, it is thought of as a process for execution once the hard decisions are made.” -Designer

Ecco, questo è forse un punto importante: vedere il design come una pura e semplice execution del business è un errore clamoroso. Il design È business, specialmente nel caso dei prodotti digitali (ricordate: The experience is the product).

Per concludere, ai manager/stakeholder (non designer) vorrei porre alcune domande:

E un consiglio ai designer: cercate di capire quali sono gli obiettivi e le regole del business, perché il “gioco” del design è proprio quello di riuscire a creare un prodotto efficace per il business (altrimenti si chiama “arte” e i vostri prospect sono le gallerie, le case d’aste e i filantropi collezionisti).

Comments 6
  • Raffaella Roviglioni
    Posted on

    Raffaella Roviglioni Raffaella Roviglioni

    Author

    Alberto, tu _non hai idea_ di cosa significhi questo post (e i riferimenti) per me.
    Meglio di un regalo di Natale inaspettato!

    Come minimo ti regalo una bottiglia di vino (in alternativa, smetto di commentare il tuo blog :P).

    GRAZIE!


  • Alberto
    Posted on

    Alberto Alberto

    Author

    in bocca al lupo!

    ps: sul vino sono piuttosto esigente, come ben sai 😉


  • Panaghia
    Posted on

    Panaghia Panaghia

    Author

    Succede spesso quando il committente si impone su scelte di interazione e design, è risaputo.

    Ci sono tonnellate di articoli ux interessanti che cercano di spiegare come il problema stia nel fatto che non sia affatto facile immedesimarsi nell’utente medio e comprendere la scarsa propensione a voler utilizzare un prodotto che esula dai comuni design pattern, mentre il committente (specialmente se proviene da una professione molto creativa) ha in mente approcci molto fantasiosi. Mira a rendere il suo prodotto “unico”, creando talvolta delle soluzioni pessime dal punto di vista pratico per l’usabilità, non essendo un esperto in materia.


  • alessio
    Posted on

    alessio alessio

    Author

    Questo post è pieno di verità 🙂
    Per mia esperienza il design e il debug sono due aspetti fondamentali (e forse non a caso alle estremità del processo creativo/realizzativo) che vengono sempre trascurati in nome del Just in Time (o dell’ansia del boss).
    Mi è capitato molto spesso di dover realizzare features che non sono mai state utilizzate e aver progettato intere sezioni di applicazioni basandomi su design e specifiche che puntualmente venivano cambiate dopo l’implementazione. per non parlare della frequente mancanza di comunicazione/scambio tra i reparti di design e produzione, per cui nel corso di un anno un flusso di registrazione e login viene riprogettato in modo diverso per ogni progetto senza riutilizzo dei flussi e tantomeno del codice.
    credo pero’ che alla base di questo problema ci sia la cultura aziendale. l’azienda ha un forte imprinting dettato dal suo board, soprattutto se l’azienda è medio piccola. Avendo lavorato in diverse aziende ormai riconosco l’impronta che viene data al prodotto se il boss proviene dal settore IT piuttosto che dall’editoria o dalla comunicazione. Quello che mi rammarica è la bassa attitudine a farsi contaminare da chi ha un vissuto professionale diverso e quindi potrebbe portare valore di conoscenza e non essere mero esecutore di task.
    In alcune realtà dove ho lavorato i project manager che devono seguire la realizzazione di progetti web sono persone che vengono da scienze della comunicazione. E quindi hanno un punto di vista dell’applicazione web molto poco applicativo e sono poco propensi vedere i progetti da un punto di vista strutturale, cosa che culturalmente sarebbe molto piu’ facile da fare se il project manager fosse un architetto.


  • biccio
    Posted on

    biccio biccio

    Author

    Applausi.


  • Emanuele
    Posted on

    Emanuele Emanuele

    Author

    In certi casi dovrebbe essere garantito il diritto di sciopero… Soprattutto se si tiene conto del fatto che poi il prodotto che ne scaturisce finirà nel portfolio del designer e non in quella del manager… (oltre al fatto primario che non sarà un buon prodotto, ovviamente).