Questo è un post ironico e sarcastico. Una parodia insomma. L’ho scritto perché scrivere è terapeutico e sono stanco di vedere gente che tenta, compiaciuta, di infilare dei cubi dentro fori triangolari. Come chi applica la metodologia Agile un po’ a tutto, anche a campi che con la programmazione non c’entrano un fico secco. Oppure quelli per cui il framework di riferimento è una religione. E chi confonde l’ideazione e l’innovazione con la presunzione di sapere di cosa ha bisogno la gente. È un post dedicato anche a chi crede di aver capito i principi Agile, ma fa solo cargo cult. Quindi è il manifesto del design goffo, impacciato, claudicante, quello che proprio non riesce a essere agile. Per sicurezza, leggete anche il manifesto Agile, quello vero, non è mica male. La colonna sonora sono gli Amo Amo.


Stiamo scoprendo modi migliori di fare design, facendo design.
Non ci avevamo pensato finora, troppe riunioni inutili.
Grazie a questa novità del lavorare sul serio, abbiamo capito che:

Se scegli gli strumenti e i processi perché sono di moda o perché lo fa Google, le persone e le interazioni andranno in vacca.
Se il tuo prodotto funziona, ma non serve a nessuno, forse era meglio documentarsi prima.
Se collaborare con il cliente significa prostituirsi, allora era meglio negoziare un contratto.
Se non sai neppure mettere in piedi un piano decente, come farai a rispondere al cambiamento?

I principi del design goffo

Noi seguiamo questi principi:

La nostra massima priorità è capire qual è il problema che vogliamo risolvere.
Per farlo, muoviamo il culo e andiamo a conoscere gli utenti.
Ché le user stories stanno ai bisogni degli utenti come la masturbazione sta al sesso.

Noi non crediamo che tutti siano designer, a meno che non lo siano.
Per questo, vi chiediamo di tacere di ciò di cui non potete parlare.
Anche voi manager, grazie.

Le dimensioni dei dati non contano, conta come li usi.
Un imbecille data driven, è sempre un imbecille.
Per questo, noi crediamo negli small data.

Noi affermiamo che l’eccellenza artigianale sia fondamentale.
E che abbia bisogno di tempo e pensiero.
Non usiamo la velocità come alibi per la mediocrità.

Noi pensiamo che la cultura umanistica sia imprescindibile.
Se credi che il congiuntivo sia un’infezione dell’occhio, non sarai mai un bravo designer.

Noi crediamo che l’etica non sia negoziabile.
Per questo non progettiamo trappoloni digitali.

Coming soon altri principi…

Ultimo aggiornamento 21 Ottobre 2021.

Mostra commentiNascondi i commenti

2 Commenti

  • Francesco
    Posted 17 Settembre 2021 at 09:45 0Likes

    Quanto pensi che il coinvolgimento dei designer in metodologie Agile utilizzate da team dev possa aver influito negativamente sulla capacità di analizzare veramente i bisogni degli utenti?

    Nella mia esperienza, mi è capitato più volte vedere team in cui le user stories venivano auto-generate da chi poi doveva realizzare il prodotto.

    • Marco Bertoni
      Posted 17 Settembre 2021 at 10:01 0Likes

      Ciao Francesco, è esattamente questo il punto. Le user stories, così come sono usate nello sviluppo del software, andrebbero chiamate programmer’s inferences (oppure Product Owner inferences). L’utente è rimosso dall’equazione con una naturalezza disarmante. A peggiorare le cose c’è il fatto che noi oggi facciamo Manager-centered design, altro che Human-centered ;).

      Il tema dell’inclusione a forza della componente di design in una metodologia nata per la programmazione è quello che chiamo sforzarsi di infilare un cubo in un foro triangolare.

      I vantaggi di un approccio Agile che non sia cargo cult, sono evidenti. Tornare al waterfall è impensabile. Ma questa ibridazione forzata, per me non funziona. Bisogna sforzarsi di piegare il metodo e inventare qualcosa di nuovo, al posto di seguire una prassi come fosse una religione.

Commenta