La Retorica Procedurale come elemento fondante della Vision di prodotto
Una scelta di design spesso va oltre la risoluzione di uno specifico problema e si accosta maggiormente ad una dichiarazione di intenti verso una specifica visione del mondo.
Quando apriamo un editor di testo digitale, ci troviamo davanti a una pagina bianca virtuale. Questa scelta apparentemente innocua - replicare il formato di una pagina fisica in un ambiente digitale - ha plasmato per decenni il nostro modo di pensare alla scrittura. Il foglio A4 verticale, i margini, le interruzioni di pagina: sono tutti vincoli ereditati dal mondo fisico che continuiamo ad utilizzare anche quando non esistono più limiti materiali. La "pagina" diventa così non solo un'area di lavoro, ma un modello mentale che influenza il modo in cui organizziamo i pensieri, strutturiamo i contenuti e concepiamo il documento stesso.
Questo singolo esempio rivela un principio fondamentale del software: ogni scelta procedurale incorporata in un’interfaccia, plasma profondamente non solo il modo in cui lavoriamo, ma il modo stesso in cui pensiamo. Le interfacce non sono mai neutre: veicolano sempre una particolare visione del mondo, un modo specifico di organizzare l'informazione, di strutturare il lavoro e di collaborare.
Il fenomeno assume dimensioni ancora più significative nel mondo del software B2B, dove le scelte progettuali incorporate nei sistemi aziendali oltre ad influenzare singoli comportamenti, ridefiniscono interi processi organizzativi. Quando un'azienda adotta un nuovo software, non sta semplicemente acquisendo uno strumento ma sta abbracciando, spesso inconsapevolmente, una particolare filosofia di come il lavoro dovrebbe essere organizzato, di come le decisioni dovrebbero essere prese, di come le persone dovrebbero collaborare.
Questa dimensione retorica del software, la sua capacità di persuadere e trasformare attraverso le procedure che incorpora, è il tema centrale di questa riflessione. Un tema che diventa cruciale soprattutto per chiunque si occupi di progettare o implementare soluzioni dedicate alle aziende, dove ogni decisione di design ha il potenziale di trasformare profondamente il modo in cui intere organizzazioni operano e evolvono.
Il concetto di Retorica Procedurale è stato formalizzato nel 2007 da Ian Bogost nel suo libro "Persuasive Games", ma le sue radici affondano più in profondità. Già negli anni '80, con l'avvento dei personal computer, studiosi come Terry Winograd e Fernando Flores avevano iniziato a esplorare come il design del software potesse influenzare il modo in cui le persone pensano e lavorano. La loro opera "Understanding Computers and Cognition" (1986) fu tra le prime a suggerire che i software non sono strumenti neutri, ma artefatti che incorporano specifiche visioni del mondo.
La Retorica Procedurale si distingue dalla retorica classica, che si concentra sul potere persuasivo delle parole e delle immagini, concentrandosi su come le regole, i processi e le strutture incorporate nel software costituiscano esse stesse una forma di persuasione. Quando un software impone un particolare flusso di lavoro o suggerisce un certo modo di organizzare le informazioni, sta in realtà argomentando per una specifica visione di come il lavoro dovrebbe essere svolto.
Quando siamo impegnati nella progettazione, diventa fondamentale avere ben chiara la visione rispetto al prodotto che su cui si sta lavorando e il suo impatto. La nostra vision infatti opera contemporaneamente su due livelli. Il primo è esplicito: le funzionalità che dichiariamo, il valore che promettiamo, il modo in cui ci posizioniamo sul mercato. Ma esiste un secondo livello, più sottile ma non meno potente: il modo in cui le nostre scelte procedurali influenzano l'organizzazione.
Prendiamo l'esempio di un software per la gestione dei progetti. A livello esplicito, potremmo promuovere funzionalità come la pianificazione delle attività, la gestione delle risorse, il tracking del tempo. Ma ad un livello più profondo, le nostre scelte procedurali stanno definendo come i team dovrebbero collaborare, quali informazioni sono considerate importanti, come dovrebbero essere prese le decisioni e persino quali ruoli dovrebbero esistere nell'organizzazione.
Quando azienda adotta un nuovo software, innesca una trasformazione che va ben oltre la semplice digitalizzazione degli strumenti di lavoro. È come introdurre una nuova lingua in un'azienda: non cambiano solo le parole, ma il modo stesso di pensare e comunicare.
Il software non si limita a replicare in digitale i processi esistenti, ma li ripensa dalle fondamenta. Prendiamo un altro esempio pensando ad un sistema CRM: un applicativo di questo genere va oltre il semplice trasferimento di contatti da un archivio cartaceo ad uno digitale. Il sistema introduce nuove procedure operative standardizzate, ridefinisce chi può fare cosa e quando, crea nuove interconnessioni tra reparti che prima operavano in modo isolato. Un commerciale si trova così a dover documentare ogni interazione con il cliente, permettendo al marketing di personalizzare le comunicazioni e al supporto di avere un quadro completo della relazione.
A tutti gli effetti introdurre un nuovo software si può considerare come l’aggiunta di un nuovo membro del team, uno che ha idee molto precise su come il lavoro dovrebbe essere svolto. Questo catalizza l'emergere di nuovi modelli di collaborazione: reparti che prima comunicavano raramente si trovano a dover coordinare le loro attività quotidianamente, mentre le priorità operative si ridefiniscono. Ciò che prima era considerato secondario - come la documentazione puntuale delle attività - diventa improvvisamente centrale. I modelli di governance evolvono per adattarsi a questa nuova realtà, con nuovi processi decisionali e nuove catene di responsabilità.
Nell’approcciarci ad un nuovo progetto, la nostra vision e la riflessione sulla Retorica Procedurale, ci richiede quindi di riflettere e considerare una serie di domande più profonde. Non si tratta solo di domandarsi "cosa deve fare questa feature?" o "come dovrebbe funzionare?", ma di esplorare le sue implicazioni più ampie per l'organizzazione.
Come cambierà il modo in cui le persone collaborano? Una nuova funzionalità di commenti in un documento condiviso, ad esempio, non è solo un modo per aggiungere note: potrebbe ridefinire completamente il processo di review, spostando discussioni che prima avvenivano in riunioni fisiche in uno spazio asincrono e digitale.
Oppure, quali comportamenti stiamo implicitamente incoraggiando o scoraggiando? Un sistema di notifiche apparentemente innocuo può creare una cultura dell'urgenza costante, mentre un workflow di approvazione troppo rigido potrebbe soffocare l'innovazione e l'iniziativa individuale.
E ancora, quali gerarchie e strutture di potere stiamo costruendo? La scelta di chi può vedere quali informazioni, chi può approvare cosa, chi ha accesso a quali funzionalità, non sono decisioni meramente tecniche: sono scelte che plasmano la struttura organizzativa stessa.
È importante essere consapevoli di quale cultura organizzativa siamo promotori, considerando che ogni funzionalità porta con sé una visione implicita di come il lavoro dovrebbe essere svolto, di cosa è importante e di cosa non lo è, di come le persone dovrebbero interagire e collaborare.
All’interno di questo contesto, i vincoli sono potenti strumenti di design, spesso sottovalutati nella loro capacità di plasmare comportamenti e processi organizzativi. Un vincolo non è semplicemente una limitazione tecnica: è una dichiarazione di intenti, una scelta che definisce il possibile e l'impossibile all'interno di un'organizzazione.
Pensiamo ad un semplice campo obbligatorio in un form: oltre ad essere una scelta di interfaccia, è una dichiarazione di ciò che l'organizzazione considera essenziale. Quando decidiamo che non si può procedere senza inserire certi dati, stiamo di fatto stabilendo priorità, definendo standard di qualità, imponendo una particolare disciplina nel processo.
Allo stesso modo, quando decidiamo di non implementare certe funzionalità, stiamo implicitamente suggerendo dei comportamenti. L'assenza di una funzione di "inoltra a tutti" in un sistema di messaggistica aziendale non è per forza una mancanza: può essere una scelta precisa che promuove una comunicazione più mirata e responsabile.
I vincoli più potenti sono spesso quelli che non si notano, che vengono percepiti come naturali. L'impossibilità di modificare un documento dopo l'approvazione, la necessità di seguire un workflow predefinito, la visibilità limitata di certe informazioni: sono tutte scelte che, attraverso la loro apparente naturalezza, plasmano profondamente il modo in cui un'organizzazione opera.
Ragionare sulla Retorica Procedurale, ci porta quindi alla necessità di accompagnare la nostra visione di prodotto, incorporando fin da subito le reali necessità della popolazione di utenti a cui il software è indirizzato. La user research nel B2B assume quindi un significato più ampio e strategico rispetto al B2C. Oltre a comprendere le preferenze degli utenti al fine di ottimizzare i flussi di lavoro, ci aiuta a decifrare la "grammatica organizzativa", il modo in cui un'azienda pensa, opera e si evolve.
Questo richiede un approccio etnografico al design research: dobbiamo immergerci nel contesto organizzativo, osservare non solo cosa le persone fanno, ma come costruiscono significato attorno alle loro azioni. I workaround che gli utenti sviluppano, le pratiche informali che emergono, le "regole non scritte" che governano le interazioni: sono tutti elementi cruciali per comprendere la vera natura dell'organizzazione.
Solo attraverso questa comprensione profonda possiamo progettare software che non si limiti a imporre una nuova logica procedurale, ma che sappia dialogare con quella esistente, evolvendola in modo organico. Le interviste contestuali, l'osservazione partecipante, i workshop di co-design si trasformano da strumenti di raccolta dati, a momenti di dialogo tra la logica del software e quella dell'organizzazione.
In definitiva
Comprendere la Retorica Procedurale nel B2B trasforma profondamente il modo in cui pensiamo al software enterprise. Non stiamo semplicemente costruendo strumenti: stiamo plasmando il futuro delle organizzazioni, influenzando il modo in cui le persone lavorano, collaborano e pensano.
Questa consapevolezza porta con sé una grande responsabilità. Ogni decisione di design, ogni workflow implementato, ogni vincolo introdotto ha il potenziale di trasformare profondamente le dinamiche organizzative. Come architetti di questi sistemi, dobbiamo essere consapevoli che stiamo disegnando non solo interfacce e funzionalità, ma i contorni stessi delle organizzazioni del futuro.
La sfida più grande, e allo stesso tempo la più stimolante, è trovare il giusto equilibrio tra standardizzazione e flessibilità, tra controllo e autonomia, tra efficienza e adattabilità. Non esistono risposte universali, ma la consapevolezza della dimensione retorica del nostro lavoro ci permette di affrontare queste sfide con maggiore profondità e sensibilità.
Il successo nel B2B non si misura solo in termini di funzionalità implementate o di efficienza operativa. Il vero successo sta nella capacità di catalizzare trasformazioni positive, di abilitare nuovi modi di lavorare, di aprire nuove possibilità. In questo senso, la Retorica Procedurale non è solo uno strumento di analisi, ma una lente attraverso cui reimmaginare il ruolo stesso del software nelle organizzazioni moderne.