La prototipazione… che parola! Ci fa sentire all’avventura, alla scoperta! Come software engineer adoro i prototitpi!

Si sperimenta, si prova, si è in un territorio inesplorato e si lavora con la creatività.

Nel nostro viaggio di ricerca del valore per il cliente significa che finalmente possiamo aprire il nostro IDE preferito e sviluppare? No! Sarebbe troppo bello, vero? Qui stiamo ancora creando un prototipo.

Prima partiamo con delle narrative ad alto livello, degli scenari utente a cui dare una forma con dei software wireframe (es.: Figma, Adobe XD…) o in modo ancora più semplice con delle slide. Tutti questi sono passi per rifinire la soluzione ed esserne convinto prima che possa essere mostrato.

Quando sveliamo il prototipo a qualcuno dobbiamo essere pronti a ricevere soprese e cattive notizie.

Eh già… se non abbiamo doti di design, user experience ed esperienza nel settore particolarmente spiccate probabilmente proporremo qualcosa con ampi margini di miglioramento! È capitato a chiunque di implementare qualcosa che poi viene bocciato dagli utenti perché poco pratico o che non risolve completamente il problema. Ma c’è sempre una buona notizia! In questa fase di prototipazione i cambiamenti sono ancora economici rispetto alla fase di sviluppo vero e proprio. Per cui, meglio scoprire queste cose prima che poi.

Dopo un po’ di iterazioni col prototipo possiamo iniziare a sviluppare? Sì, ma con molta astuzia. Ti ricordi il less is more? Gli utenti ci hanno detto cosa piace loro e forse tra le mani abbiamo un’idea che funziona. Abbiamo mostrato loro tante feature, grazie al prototipo, che ci sono state validate. Ma sappiamo anche che gli utenti possano credere di aver capito o colto i benefici o le funzionalità che desiderano ma potrebbe non essere così. Ah! Che dannazione questi utenti! Sembra che conoscano tutte i modi per farci impazzire… Però, proviamo a pensare a quando noi siamo utenti o clienti. C’è qualche acquisto che abbiamo fatto perché catturati da una qualche feature wow che poi nella quotidianità usiamo raramente e invece adoperiamo altre feature meno luccicanti o a cui non avevamo pensato in un primo momento? O peggio ancora… un acquisto che credevamo fondamentale ma poi l’abbiamo relegato e dimenticato in un angolo del ripostiglio?

È esattamente per queste dinamiche che dobbiamo interiorizzare il costruire il meno possibile e il costruire per imparare.

Sharing is caring

Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!