Come e perché creare un nuovo sito web o applicazione

Troppo spesso si parte in quarta nello sviluppo di un nuovo progetto. Ma non ci si è mai dati risposta a delle semplici questioni che sono di fondamentali per un nuovo progetto.

Per fortuna ultimamente ho davvero tantissime richieste di progettazione e sviluppo di nuove idee, siano essi siti web o applicazioni o progetti innovativi. E alcuni percorsi mentali e critiche che vanno fatti si basano sempre su alcuni punti fermi dell’analisi che è necessaria in questi casi.

E allora, di fronte a domande che possono sembrare banali, non si trova risposta con tanta semplicità e alcuni presupposti dati per scontati non lo sono poi tanto.

La conversione

Siete liberi di non crederci ma 8 volte su 10 un Cliente non ha idea di quale sia l’obiettivo di conversione del suo progetto. Per conversione si intende_“cosa ti aspetti di ottenere dal sito sito e dagli utenti che lo visitano?”_.

La risposta può non essere complicata: anzi, non deve esserlo!

Si deve avere ben chiaro quale sia l’obiettivo del progetto: sia anche l’acquisizione di un contatto o l’acquisto di un prodotto; l’acquisizione di un utente che diventa cliente.

Personas, queste sconosciute

Per chi stiamo realizzando questo progetto? chi sono i nostri utenti? che tipo di utenti andremo ad intercettare? come si comportano? cosa si aspettano? cosa vogliono, amano o detestano?

Fare l’identikit di queste persone – per l’appunto personas– è necessario e fondamentale per capire come approcciarci alle soluzioni tecniche e pratiche del progetto.

Non essere consapevoli di “chi si trova dall’altra parte” equivale a fallimento certo. Ma, seppure si ha un’idea delle tipologie di utente del progetto, è importante focalizzare i punti chiave di questi soggetti, formalizzare le informazioni a disposizione e averle sempre di riferimento nelle fasi successive di progettazione. Anche, poi, in fase di testing.

La customer journey

Una volta concepita l’idea di base e compreso cosa si vuole ottenere è fondamentale studiare la customer journey.

Si tratta di analizzare tutti quei percorsi che effettua l’utente (o il cliente) all’interno del sito web: accesso tramite home page, da motore di ricerca o da social; accesso a una pagina specifica; ricerca dei contatti o dell’acqusito.

Facciamo un esempio pratico e banale: siamo una azienda di servizi e vogliamo creare un sito web per mostrare i nostri servizi, vogliamo che potenziali clienti ci trovino tramite ricerca sui motori di ricerca, vogliamo quindi che ci contattino tramite la compilazione del modulo di richiesta preventivo.

In questo caso l’obiettivo di conversione è l’acquisizione di un contatto qualificato tramite la compilazione di un modulo di contatto dettagliato. L’utente deve arrivare al sito tramite una precisa ricerca di parole chiave, quindi un attento posizionamento sui motori di ricerca e, una volta arrivato sul sito deve poter trovare agevolmente le informazioni circa i servizi offerti e quindi poter trovare agevolmente il modulo da compilare.

Ci sarebbe anche da discutere su come realizzare il modulo per renderlo più efficace… ma diciamo che questa è un’altra storia.

In base a questi processi è possibile quindi andare a studiare sia una architettura dei contenuti che una interfaccia grafica che vadano a soddisfare tutte questi percorsi.

I vincoli

Una piccola nota va fatta anche per quello che riguarda i vincoli che un progetto può incontrare.

Indubbiamente, a prescindere da quanto possa essere bello, interessante e fico il progetto ci sono degli ostacoli che difficilmente è possibile aggirare o superare.

Banalmente i vincoli di budget che possono portare a un drastico ridimensionamento del progetto iniziale per mancanza di risorse, siano esse tecniche (server, dispositivi, materiale) o umani (personale, sviluppatori, risorse esterne).

Anche se presi meno in considerazione gran parte dei problemi derivano da vincoli tecnici e di piattaforma che possono dipendere sia dalle persone, come l’ignoranza in materia o la bassa conoscenza del contesto tecnico, sia dal contesto di sviluppo del progetto, come l’impossibilità tecnica di realizzarlo in tempi e modi che rientrino nelle stime.

Banalizziamo con questa libera citazione da una delle email che mi è arrivata: rifacciamo Facebook ma fatto meglio!?

L’architettura dei contenuti

Quando tutte le premesse al progetto dicono che il tutto è fattibile si entra in contesto che ritengo sempre un po’ ambiguo.

Per architettura dei contenuti intendo quello studio che va nel dettaglio di cosa ci va dentro il progetto, quello che l’utente vede e legge. Ma soprattutto come lo legge, ovvero le gerarchie, l’organizzazione di questi contenuti, la struttura della navigazione, da chi scaturisce cosa.

Esempio banale: le pagine. Ok, ci sono delle pagine: quali sono le più importanti? ci sono sottopagine? e se ci sono c’è contenuti per ognuna di esse? c’è uno schema logico di gestione del contenuto? immagine, titolo, paragrafo?

Altro esempio banale: abbiamo i servizi! Bene: quali sono? ci sono descrizioni? dovremmo prevedere una pagina per ogni singolo servizio? e nella pagina genitore (perché ci sarà una pagina genitore) come ci comportiamo con l’elencazione dei servizi e cosa mostriamo?

La bussola per questo lavoro dovrebbe essere la comprensione dei punti di forza e di debolezza del progetto.

In tutto questo contesto, se si lavora con una grande struttura, confluiscono le “esigenze” e i pensieri di diversi professionisti: il developer che deve poi gestire tutti i contenuti e creare delle strutture informatiche che permettano di organizzarli e gestirli; i copywriter che devono poi andare a scrivere i contenuti secondo dei modelli e che devono fare ricerche in merito; grafici che devono produrre assets; esperti del settore che devono studiare il mercato…

Ma soprattutto dovrebbe essere il Cliente ad avere una visione chiara e saper rispondere a questi quesiti. Se non sai cosa mostrare, quali sono i tuoi punti di forza e di debolezza, allora cosa vuoi comunicare ai tuoi clienti?

L’interfaccia grafica

Ok: ci siamo! Solo a questo punto allora possiamo davvero preoccuparci di “fammi vedere qualcosa”.

Non che sia banale!
Tutto l’impianto grafico deve essere allineato ai punti di cui prima: il target, l’identità aziendale, il mezzo di comunicazione, l’obiettivo di conversione.

E cominciamo a dare i nomi alle cose:

• schetch;
• wireframe;
• design;
• prototipo lo-fi;
• prototipo hi-fi;
• produzione.

Schetch

Il primo passaggio, per quanto rudimentale è quello di andare ad abbozzare il progetto grafico anche solo su carta e quindi cominciare a ragionare sui vari punti da prendere in considerazione e valutare se un’idea copra i requisiti del progetto;

Wireframe

È uno stato di definizione degli spazi e ingombri ben strutturato, basato su misure e calcoli precisi, necessario a comprendere se tutto sta al posto giusto nei termini tecnici imposti;

Design

È la fase in cui lo studio degli spazi è graficato e l’impianto prende realmente l’aspetto grafico che ci si aspetterebbe;

Prototipo lo-fi

Una volta strutturato l’aspetto statico del progetto è ora di impegnarsi in una implementazione più profonda, ci si concentra sui concetti di base che sono stati concepiti e studiati nelle fasi precedenti per cominciare a dare una impressioni realistica del funzionamento generale dell’interfaccia.

Prototipo hi-fi

Direi che ora abbiamo veramente ogni tipo di elemento per poter creare un prototipo del progetto davvero funzionante, davvero vicino a quello che sarà il prodotto finale.

Una fase in cui sono fondamentali i test e i feedback di tutto il team (fosse anche solo il committente e il programmatore) che ha lavorato al progetto.

Produzione

Quando il prototipo è pronto per essere rilasciato al pubblico (il target di cui si parlava prima), allora si va produzione.

Qui il problema più importante, più “grave”, è superare gli ostacoli tecnici e di immaginazione di chi si ha davanti. Spesso un wireframe non viene percepito.

Wow, siamo online!

Beh, il lavoro è sostanzialmente finito. Sia esso un sito, un blog o una app ora l’utenza ha a disposizione questo sistema.

Tutto il processo ha portato alla realizzazione completa del progetto e alla sua pubblicazione. Ora è il momento di farlo lavorare e lasciare che il pubblico lo veda e lo usi.

Cavolo, siamo online…

Ok… avere fatto tutto, precisamente, puntualmente, perfettamente… ma non c’è garanzia che sia tutto corretto: le premesse potrebbero essere sbagliate, delle analisi magari non erano precise o dei punti non sono stati valutati col giusto peso.

Come in ogni cosa, ovviamente ci possono essere problemi. E allora entra in gioco la fase di post-rilascio, quella in cui vengono analizzati i primi dati, si ricevono feedback e si valutano i risultati.

Un progetto, qualsiasi esso sia, va aggiornato e manutenuto. Il che vuol dire prevedere sempre un periodo di assestamento in cui qualcosa potrebbe andare storto o, più semplicemente, vanno limati alcuni aspetti di cui, magari, non si avevano abbastanza dati nella prima fase di analisi.

Si riparte da capo, allora, e magari all’orizzonte ci sarà una versione 2 del progetto, migliorata e aumentata.

Alcuni processi di sviluppo sono basati proprio su questo ciclo: si rilasciano versioni minimali del progetto e, di volta in volta, c’è uno step di avanzamento. Questo comporta tempi minori per i rilasci e focus molto precisi sull’obiettivo più piccolo dell’intero progetto.

Credits: UXFlow Web Kit Design by Ofspace Digital Agency