Il redesign di Seejay

Web design nell’era Post PSD

Francesco Improta
6 min readMar 12, 2015

Negli ultimi mesi ho avuto l’opportunità e il piacere di lavorare per Seejay, una startup italiana nata nel 2013 sviluppando una web app dedicata al mercato del User Generated Content. L’applicazione consente di raccogliere, organizzare e pubblicare immagini, video, audio, testi dai social network per costruire in tempo reale lo storytelling intorno a qualsiasi tema o argomento.

Ho accettato con entusiasmo questo progetto per 3 motivi:

  1. c’è un prodotto vero — con le proprie caratteristiche, rivolto ad un mercato e ad una utenza specifica;
  2. l’esperienza d’uso pone evidenti sfide di design;
  3. la collaborazione si basa su un “contratto agile”, non a corpo (hurray!);

Team

Oltre al sottoscritto, nel ruolo di Designer, il gruppo di lavoro ha visto la partecipazione di tutto il team di Seejay:

  • Carlo Brunelleschi, CEO e Co-Founder di Seejay
  • Fabrizio Ferreri, COO e Co-Founder
  • Andrea Ortis, CTO
  • Fabrizio Di Bella, Web designer

Abbiamo lavorato principalmente da remoto: io nel mio studio di Roma, il team di Seejay nella sede ospitata presso il TIM #WCAP Accelerator di Catania.

Kickoff meeting: esercizi, aspettative e pianificazione

Il progetto parte in una caldissima giornata siciliana di fine Settembre durante la quale si tiene il kickoff meeting. Ho intervistato il team per conoscere meglio il prodotto e capire cosa avrebbero voluto realizzare. La giornata è proseguita con esercizi di design come la Design Studio Metholodgy e la KJ technique. È stato un momento importante sia per conoscersi che per allineare tutto il team sulle future attività del progetto.

Design exercises svolti durante il kickoff meeting

Le giuste aspettative

Entrare nella cosidetta Post PSD Era è un problema di aspettative. Il tipico workflow nel web design prevede l’invio al cliente di una “preview” da approvare. Questa preview consiste in un mockup di una o più pagine e contiene tutto: tipografia, spaziature, griglia, contenuti (reali e/o lorem ipsum). Il problema con documenti di questo tipo è mantenere il focus su gli elementi veramente importanti, mentre il cliente si concentra su i più piccoli dettagli.

Il primo, vero cambiamento è parlare con il cliente con onestà e chiarezza. Quale occasione migliore del meeting di kickoff?

Non importa quanto sia grande il team di lavoro. Siamo persone e come tali ognuna diversa dall’altra. Dal momento che si lavora insieme, tutti devono condividere lo stesso vocabolario, parlare la stessa lingua.

Una parte della giornata è stata quindi dedicata al tema del processo di design e del valore consegnato al cliente. Mostrando loro alcuni esempi di progetti precedenti e case studies internazionali, tutti sapevano cosa aspettarsi nelle prossime settimane.

Sketching

Site-wide patterns e moduli

Una prima fase del lavoro è stata dedicata all’esplorazione dei site-wide patterns. I numerosi insights prodotti durante il kickoff meeting tramite la Design Studio Methodology si sono rivelati preziosi per progettare la struttura dell’interfaccia utente.

Moduli della pagina Storia per desktop
Patterns dello step Search & Curate, il processo di creazione di una storia

HTML Wireframes

Ho utilizzato questi sketch per creare i corrispettivi wireframes HTML, impostando atomi, molecole e organismi seguendo la metodologia indicata da Brad Frost in Atomic Design.

Abbiamo quindi testato tutti i wireframes direttamente nel browser dei dispositivi mobile, tablet e desktop.

Un prototipo per ogni scenario

Successivamente abbiamo aumentato la fedeltà dei nostri deliverables costruendo diversi prototipi interattivi, ciascuno dei quali focalizzati su un scenario d’uso:

  1. First visit e Signup
  2. First login
  3. Creating a story
  4. Publishing a story

L’accoppiata Sketch + InVision si è rivelata la scelta migliore per velocità di realizzazione e risultato prodotto. È stato possibile testare ed interagire con il prototipo da remoto, valutando le soluzioni proposte e approvando ogni singola iterazione.

Visual Direction

Definire il nuovo linguaggio visivo per Seejay è stato un passaggio fondamentale del progetto. L’utilizzo degli element collages al posto dei full-comp mockups ci ha permesso di esplorare direzioni creative diverse per poi scegliere quella adatta sia al sito web che all’interfaccia dell’applicazione.

Element collage

Il vantaggio di utilizzare gli element collages deriva dal fatto che non si investe tempo per la realizzare di ogni singola pagina. Il focus è invece concentrato su di un set di elementi molto specifici (ad esempio i site-wide patterns).

Questo approccio snellisce il processo di visual design, favorisce la comunicazione e la collaborazione durante il feedback, riduce i tempi di produzione.

Full comps

Abbiamo prodotto anche alcuni mockup completi riguardo le pagine/sezioni più critiche, come il processo di creazione di una storia e la pagina pubblica della storia. Sempre tramite InVision abbiamo reso i mockup interattivi. Questo ci ha permesso di validare ancora una volta le scelte fatte.

Atomic Design e Pattern Library

L’ultima parte del mio lavoro per Seejay mi ha visto impegnato sul front-end. Ho creato una Pattern Library per raccogliere tutti i componenti dell’interfaccia, specificando per ciascuno il markup HTML e CSS.

Anche per lo sviluppo del front-end è stata utilizzata la metodologia di Atomic Design. Gli organismi, le molecole e gli atomi dell’interfaccia definiti durante la fase di sketching si sono evoluti nella versione finale definita con il visual design.

La library è diventata subito un punto di riferimento per gli sviluppatori durante tutto il lavoro di implementazione con il backend.

Approccio iterativo

Abbiamo adottato un approccio iterativo incrementale, organizzando il lavoro in iterazioni settimanali, prevedendo per ciascuna un momento dedicato alla condivisione e alla review del lavoro. Questa pratica ci ha permesso di condividere costantemente il progetto condividendo la direzione, recependo feedback e trovando insieme soluzioni progettuali specifiche.

In pratica, abbiamo fissato la giornata di venerdì per la consegna della singola iterazione, e la giornata del lunedì seguente per la discussione ed approvazione.

Abbiamo completato il progetto in 12 iterazioni di lavoro contro le 8 stimate all’inizio. Le stime non funzionano. Il contratto agile ci ha consentito di gestire il cambiamento bilanciando i rischi per entrambe le parti.

--

--

Francesco Improta

Senior Product Designer at Italian Department for Digital Transformation. I love hiking, astronomy and coding. I’m a dad in the real life.