Alberto Mucignat

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

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

Scritto il a proposito di User experience - 6 Commenti

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:

  • Non-designer che prendono decisioni sul design
  • Manager senza basi di design che prendono decisioni sul design.

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:

  • è possibile determinare delle “regole business” e accettare che vengano realizzate da chi ha competenze specifiche nel design?
  • è possibile lavorare in modo che alcune decisioni di business vengano prese durante la fase di design?
  • è possibile anche cambiare le decisioni business per supportare un design più innovativo?

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).

Tag: , , ,

6 commenti ↓

  • #1 Raffaella Roviglioni 16/12/2010 14:15

    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!

  • #2 Alberto 16/12/2010 14:17

    in bocca al lupo!

    ps: sul vino sono piuttosto esigente, come ben sai ;-)

  • #3 Panaghia 16/12/2010 14:48

    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.

  • #4 alessio 16/12/2010 15:23

    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.

  • #5 biccio 17/12/2010 15:15

    Applausi.

  • #6 Emanuele 20/01/2011 12:30

    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).

Commenta il post ↓