Crea il tuo Product System

Una visione di alto livello del tuo prodotto può aiutarti a mantere il focus, costruire rapidamente e ottimizzare le risorse.

Paolo Tripodi

Designer

Il Design System è una documentazione condivisa che raccoglie pattern funzionali e visivi di un prodotto digitale. Il suo scopo è assicurare agli utenti del prodotto un’esperienza coerente.

La prassi di creare questo tipo di documentazione è emersa quando le grandi aziende tecnologiche hanno iniziato ad avere la necessità di rafforzare il design dei propri prodotti per stare al passo con i competitor.

Da un certo punto di vista, si tratta di una soluzione nata per portare ordine all’interno di prodotti sviluppati in modo eccessivamente organico.

Oltre ad assicurare coerenza, riutilizzare gli elementi dell’interfaccia migliora l’efficienza di progettazione e sviluppo. Molte delle risorse—e dunque dei costi—impiegate per reinventare la ruota, vengono risparmiate ogni volta che si costruisce qualcosa di nuovo.

Non solo UI

D’altra parte, l’interfaccia è solo uno degli aspetti della user experience che il team deve gestire.

Lavorando con i nostri clienti, ci siamo accorti che spesso la mancanza di una compresione condivisa del prodotto origina frizione e distrazione.

“We’re all working on one system. Why do we form teams around the artifacts people produce instead of the problem they should be working together to solve?”

— Erika Hall

Qui di seguito proviamo a raccontarvi come aiutiamo le aziende a pensare al proprio prodotto in modo olistico, prendendo spunto dalle diverse tecniche e contributi che abbiamo trovato efficaci nel nostro percorso.


Che cos’è il Product System?

Il Product System—come si può intuire—estende l’idea alla base del Design System al prodotto nel suo insieme.

Si tratta di una documentazione condivisa che organizza gli elementi principali di un prodotto in una struttura semplice e accessibile. Include tutte le informazioni presenti in un Design System, ma considerate nel contesto più ampio del prodotto.

Perchè usarlo?

Lo scopo del Product System è aiutare il team a condividere un modello mentale condiviso del prodotto ed elaborare un linguaggio comune per progettare e costruire.

Va inteso come una struttura agile su cui iterare, più che una documentazione statica.

Le startup possono usare il Product System come uno strumento per mantere la giusta prospettiva sull’identità dell’azienda e sulle sue priorità. Aziende più mature possono usarlo come un modello utile a riorganizzare la conoscenza accumulata.

Com’è fatto?

Team e prodotti possono essere molto diversi, individuare una struttura unica che vada bene per tutti non è il nostro scopo. Il punto è iniziare ad approcciare il prodotto nel suo insieme, offrendo a tutti una visione di alto livello.

Qui vi proponiamo una possibile struttura per il vostro Product System. Potete utilizzarla così com’è oppure come punto di partenza per costruire la vostra.

Il modello che presentiamo è diviso in quattro sezioni:

  • Idea spiega perché il prodotto esiste e fornisce un modello che descrive com’è fatto.
  • Needs è il luogo dove descrivere le necessità degli utenti. La Ricerca va qui.
  • Language raccoglie tutto ciò che riguarda il Brand e i pattern di interazione e comunicazione.
  • Solutions riguarda ciò che stai costruendo, come lo costruisci e quali sono i prossimi passi. Qui va il processo, la mappa del prodotto e la roadmap.

Idea

La prima sezione fornisce informazioni di alto livello riguardo al prodotto, con lo scopo di coinvolgere nuove persone da zero.

Si divide a sua volta in tre sezioni:

Story

Vision e mission statement che gridano come la tua azienda sta cambiando il mondo sono inflazionati. D’altra parte, le persone sono naturalmente coinvolte dalle narrazioni.

Prova a raccontare la tua storia, racconta chi sono i founder dell’azienda e perché hanno deciso di iniziare a costruire questo prodotto.

Usa un breve testo o un video, qualsiasi cosa pensi sia più efficace. L’obiettivo è coinvolgere il team nel tuo scopo e chiarire in che direzione l’azienda intende muoversi.

Taking inspiration from Simon Sinek’s famous “Golden Circle”, we encourage our clients to start telling their Story explaining “Why” they exist and why should anyone care.

Model

Ovvero una descrizione schematica del prodotto ad alto livello. Lo scopo è spiegare le basi ad uno sconosciuto.

Puoi utilizzare qualsiasi schema, disegno o rappresentazione pensi sia più appropriata. Anche semplicemente del testo.

“To work together, we need to use language that makes sense to everyone involved.”

— Abby Covert

Al di là della rappresentazione che sceglierai, i concetti fondamentali che il modello dovrebbe descrivere sono due:

  1. Quali sono gli oggetti principali nel tuo prodotto.
  2. In che relazione si trovano tra loro.

Ad esempio, se il tuo prodotto è un client email, i tuoi oggetti potrebbero essere “Inbox”, “Lista”, “Mittente”, etc.

Scrivere una definizione esplicita di ogni oggetto è un grande passo per ridurre l’insicurezza linguistica nel team e accelerare la collaborazione.

Una volta che hai definito gli oggetti, scegli il diagramma più adatto a visualizzare la relazione tra loro.

Principles

Dato lo scopo descritto nella tua storia, i principi servono ad aiutare il team a capire come comportarsi per raggiungere quello scopo.

Per questo motivo, per definire principi efficaci è necessario prendere una posizione chiara su quali siano i comportamenti giusti.

L’obiettivo è fare in modo che ogni membro del team sia in grado di prendere la miglior decisione possibile ogni volta che si trova a dover a fare una scelta in autonomia.

Definire i tuoi principi può aiutarti anche ad approcciare il posizionamento del prodotto, dal momento che le tue scelte definiscono anche la tua posizione rispetto ai competitor.

Ecco un buon esempio da Medium:

Here are a few of the early design principles we crafted at Medium:

Direction over Choice. This principle was often referred to while we were designing the Medium editor. We purposely traded layout, type, and color choices for guidance and direction. Direction was more appropriate for the product because we wanted people to focus on writing, and not get distracted by choice.

Appropriate over Consistent. This might seem controversial, but when applied across devices, its purpose is clear. We were willing to break consistency if it was more appropriate for the OS, device, or context.

Evolving over Finalized. This is exemplified in the ability to share Medium drafts, write responses, and leave notes. The content on Medium should be antifragile, improving with use and evolving overtime. We did not want to design printed books for the internet.


Needs

Le necessità degli utenti dovrebbero essere la stella polare del team per decidere cosa fare, come farlo e quando. Lasciare che ciò che hai imparato si perda in un report è uno spreco, renderlo accessibile in qualsiasi momento aiuta a mantere il focus.

Dalle intuizioni al lavoro di Ricerca, usa ciò che hai imparato per definire le necessità degli utenti che vuoi soddisfare.

Un modo efficace per organizzare questa sezione è iniziare definendo le principali necessità di alto livello, per poi proseguire gerarchicamente con le necessità più specifiche.

Per ognuno dei bisogni, puoi includere un riferimento alla Ricerca qualitativa e quantitativa che lo riguarda.

Ricorda che non è questo il luogo per descrivere come pensi di soddisfare quei bisogni, si tratta solo di un riferimento chiaro ai problemi degli utenti.

At Moze, we use Jobs To Be Done to map customer’s needs.


Language

Questa sezione raccoglie informazioni sul linguaggio funzionale, visivo e testuale. Tutto ciò che si trova in un Design System.

Puoi suddividere il contenuto in due sezioni:

Brand

Gli elementi visivi e testuali del Brand (Brand Identity) dovrebbero essere il focus primario di questa sezione. Descrivi gli elementi e come utilizzarli all’interno del tuo prodotto e di tutti i touchpoint.

Ciò nonostante, se lo ritieni opportuno, puoi anche includere informazioni riguardo ai canali di acquisizione e alla strategia se pensi sia utile a facilitare la collaborazione del team.

Modules

Si tratta degli elementi funzionali e visivi dell’interfaccia utente. La tua UI Library. Se il tuo prodotto utilizza principalmente interfacce non-visive come voce e instant messaging, gli elementi utili a costruire le interazioni posso trovarsi qui ugualmente.

Atomic Design is still a good example of how you can structure your interface elements.

Solutions

Finalmente, è arrivato il momento del deploy. Elenca le tue soluzioni in questa sezione; descrivi come sono fatte, come fai a costruirle e quali sono le prossime cose da fare.

Includi ogni artefatto relativo al tuo prodotto principale, come lading page o tool strategici ad uso interno.

In breve, in questa sezione dovrebbe essere incluso tutto ciò che dev’essere costruito.

Le soluzioni poterbbero essere molte, non è necessario includere ogni singolo dettaglio. Di nuovo, lo scopo è quello di dare a tutti una visione di alto livello.

Process

Che sia Waterfall, Agile o Dual track, descrivi il processo che utilizzi per progettare e costruire soluzioni per le necessità dei tuoi utenti.

Product map

Gestire il tuo prodotto con le to-do-list può essere faticoso, rende difficile sapere se stai dimenticando qualcosa.

Prova invece a creare una mappa di alto livello di ogni soluzione, aiuterai il tuo team a capire cosa c’è da fare e a gestire le risorse.

User Story Mapping from Jeff Patton is the technique we use to map out solutions. Thanks Jeff!

Roadmap

Allinea tutti su quali siano le priorità condividendo una vista di alto livello della tua Roadmap. Un diagramma con il link al tuo tool di riferimento è quanto basta.


Come posso iniziare ad usare il Product System?

L’obiettivo del Product System così come è descritto qui e quello di portare chiarezza al team e facilitare il lavoro. Ciò può funzionare solo se i benefici superano gli sforzi.

Come indicazione generale per costruire il tuo Product System, il suo livello di sviluppo dovrebbe corrispondere 1:1 con il livello di maturità del tuo prodotto.

Piccoli passi

Ad esempio, i founder di una startup early stage potrebbe iniziare semplicemente stampando uno schema per appenderlo alla parete.

Da quel momento in poi, fare qualsiasi cosa di più dovrebbe sempre essere estremamente vantaggioso.

Tieni tutto in ordine

Questo dovrebbe essere il luogo dove condensare—non espandere—la conoscenza riguardo al prodotto per renderla accessibile e operativa.

Un membro del team dovrebbe spendere il minor tempo possibile per trovare ciò di cui ha bisogno, trovando utile al contempo consultarlo spesso.

Tienilo aggiornato

Rivedere il tuo Product System regolarmente è il motivo principale per costruire il proprio. Utilizzalo per facilitare la discussione sullo stato di salute del tuo prodotto, generare nuove idee e tenere traccia di ciò che impari lungo il cammino.



    Premi INVIO

    Useremo il tuoi dati unicamente per rispondere alla tua richiesta di contatto. Leggi l’informativa completa

    Non è stato possibile inviare la richiesta. Contattaci via email

    Procedi

    premi INVIO

    Grazie

    Ti contatteremo presto.