TL;DR Sommario

• Molti (la maggior parte?) team di prodotti digitali non hanno una leadership incentrata sul design e/o le risorse necessarie per sottoporsi a un'importante riprogettazione del prodotto (o per applicare un nuovo sistema di progettazione in modo completo).
• Tuttavia, una trappola comune dei designer in queste organizzazioni è quella di progettare modelli "ideali", ambiziosi che rappresentino un cambiamento importante nel sistema: ovvero, "progettiamo il miglior sistema a cui possiamo pensare", invece di un sistema che migliorerà al meglio il prodotto esistente.
• Il mio approccio preferito è meno "rivoluzione", più "evoluzione": facendo crescere un sistema dalle radici del prodotto esistente (piuttosto che forzare un cambiamento rivoluzionario), otterrai un'esperienza utente più coerente, prevedibile e user-friendly molto più velocemente .

Le aziende dispongono di risorse limitate per facilitare la modifica del design

Organizzazioni come Airbnb e Apple ci hanno dimostrato che un approccio al prodotto basato sul design può portare a esperienze meravigliose e, ehi, a volte anche al successo commerciale! E aziende come MailChimp e Google (con il lancio di Material Design ) hanno svolto un lavoro ammirevole correggendo il corso in un cambiamento di design positivo e completo.

Spesso quando i team di progettazione parlano di sistemi di progettazione, queste sono le aziende che hanno in mente: "Ciò di cui abbiamo bisogno è un Material Design per [il nostro prodotto]!" Roba molto eccitante, ma è un compito arduo per un team con risorse ingegneristiche limitate e molto richieste che hanno già un arretrato carico: vorrebbero avere un prodotto ben progettato, ma prima devono lavorare su [X, Y, e progetti Z]... tutti che probabilmente hanno storie di "ROI" più chiare rispetto ai cambiamenti di progettazione.

Suona familiare? Per me lo fa, specialmente nelle organizzazioni di livello medio-alto in cui preferisco lavorare.

Quindi, sei un designer che lavora con un "budget" ingegneristico limitato. Hai grandi idee per il tuo prodotto, oltre a nuovi modelli, comportamenti ed estetica che non vedi l'ora di implementare. Ma quando fai un passo indietro e guardi il tuo intero prodotto oggi, ecco come ti senti al riguardo:

Eccolo: hai le tue grandi esperienze utente principali, che nel tempo sono state affiancate a pagine, flussi e altri rami di prodotto di pari livello. Questi sono stati costruiti nel corso di mesi o anni, da vari addetti ai prodotti con varie direzioni di progettazione. Alcune di queste funzionalità sono state probabilmente create come soluzioni MVP: “i nostri clienti ne hanno bisogno ora! Aggiungeremo 'design' più tardi” — e da allora non siamo stati toccati. Tutto questo è stato costruito con le migliori intenzioni per l'utente e l'azienda, ma come sistema di progettazione, potresti avere a che fare con un nido di esperienze.

Allora, come fai tu, product designer, a dare forma a questa cosa?

Rivoluzione: raggiungere il nirvana del design in un colpo solo

Vive la rivoluzione! Quando sei seduto in Sketch davanti al tuo display Apple Thunderbolt, questa è una trappola emotiva facile in cui rimanere intrappolati: “se solo potessi ricominciare da zero, potrei far cantare questo prodotto! ”. Ma come pensi di implementarlo effettivamente? Probabilmente qualcosa del genere:

Ottimo lavoro: hai ottenuto il tuo sistema di progettazione perfetto! Analizziamo questo approccio per l'applicazione di un sistema di progettazione.

Professionisti

• Il tuo prodotto ora ha il design dei nostri sogni! È MAGICO!
• Hai progettato tutto in una volta, con gli stessi designer nella stanza, quindi è tutto super coeso e ponderato. È COSÌ PIACEVOLE!

• Questo ... praticamente non funziona mai in questo modo.
• Tonnellate di risorse dovevano essere dedicate per un lungo periodo di tempo.
• Questo è stato progettato nel vuoto (che fosse ben studiato o meno), quindi non considera alcune sfide del mondo reale che inevitabilmente scoprirai una volta che gli utenti reali inizieranno a usarlo.
• Infine (ma forse soprattutto ), i tuoi utenti/clienti hanno dovuto utilizzare la vecchia versione scadente del tuo prodotto per mesi o anni , solo per affrontare un improvviso e massiccio cambiamento nel design del prodotto ogni volta che rilasci questa nuova cosa.

Il modello "North Star": raggiungere il nirvana del design del prodotto, un meraviglioso blip alla volta

Quindi, il tuo team sta progettando la sua esperienza di prodotto ideale, ma si scopre che non hai le risorse necessarie per una rivoluzione del design unilaterale. Immagina! Ma ora che abbiamo progettato questi fantastici modelli, comportamenti e regole, iniziamo ad applicarli in modo opportunistico mentre lavoriamo comunque sulle pagine e sulle funzionalità dei prodotti. Qui non va niente:

Va bene, abbiamo un po' di movimento qui, e alla fine di questo processo abbiamo delle esperienze davvero belle con il nostro prodotto (anche se stiamo ancora portando con noi anche dei bagagli).

Professionisti

• Guarda i tuoi sogni di design diventare realtà nel tuo prodotto, anche se si tratta solo di pezzi.
• Molto più realistico dell'intera rivoluzione del design.
• In un lontano futuro (e se sei riuscito a mantenere le stesse preferenze di design in questi anni) potresti vedere il resto del prodotto completare la forma. Forse.

• Cambiamenti più radicali richiedono più risorse per ogni modifica (man mano che si aprono casi limite, restrizioni tecniche, ecc.), quindi il tasso di cambiamento è più lento rispetto a quando si utilizzavano modelli vecchi o modificati in modo più conservativo.
• Alla fine hai ottenuto un ottimo design, ma guarda le fasi di transizione di questo progetto: sono mesi o anni che i tuoi utenti e clienti utilizzano questo prodotto davvero irregolare , in cui l'esperienza e lo stile possono cambiare drasticamente da uno schermo all'altro. Stai davvero progettando in modo che il tuo lavoro possa finalmente dare i suoi frutti tra anni ? Non la pensavo così.
• Nel momento in cui la maggior parte del tuo prodotto è migrata a questo nuovo sistema, tu (e il resto della comunità del design) probabilmente vi siete spostati in termini di ciò che è considerato un design dell'interfaccia utente buono, comune o addirittura alla moda. Tutto quel lavoro e sei ancora bloccato con un design (esatto, il tuo "nuovo design") che ha qualche anno.

In termini di stile e comportamento, questi sono molto diversi , quindi se stai migrando parti della tua UX poco a poco, avrai forme e input notevolmente diversi presentati nel tuo prodotto. È un piccolo esempio che rappresenta un problema più grande nell'apportare modifiche radicali al progetto in modo frammentario.

Ma c'è speranza! Puoi evitare modifiche di progettazione difficili e sciatte progettando un sistema che si basa su ciò che hai. Si potrebbe anche dire che dovresti "evolvere" il tuo prodotto da dove si trova oggi...

It's Evolution, Baby : arrivare a un prodotto migliore, più velocemente, apprezzando quello che hai

Per un team di progettazione con un budget di progettazione limitato, consiglio di creare (o migliorare) il sistema di progettazione prendendo il meglio di ciò che il prodotto fa già e basandosi su di esso. Anche se sei il primo progettista di un piccolo team di startup, qualcuno (sia esso un progettista, un responsabile del prodotto o uno sviluppatore) ha scelto di prendere queste decisioni sull'interfaccia utente per motivi reali. I tuoi passaggi varieranno a seconda dello stato attuale del tuo prodotto, ma il processo inizia in questo modo:

1. Scopri il tuo attuale sistema di progettazione (se presente) : da dove provengono i componenti? Esiste un foglio di stili o una libreria di base da qualche parte nella tua organizzazione? Come sono organizzati? Chi lo ha costruito? Chi lo usa di più e quali parti di esso usano? Quando devono andare fuori strada senza di essa?
2. Fai un inventario dei modelli e dei comportamenti che vedi nel tuo prodotto : come presenti diversi tipi di informazioni agli utenti? In che modo gli utenti scelgono ciò che vogliono vedere? Come inseriscono le informazioni? Per gli elementi dell'interfaccia: vedi schede, schede, elenchi o moduli? In quali situazioni viene fuori ogni elemento?
3. Annota le regole che il tuo prodotto sembra seguire; poi inasprisci tu stesso le regole: da qualche parte dietro tutto il debito di progettazione, c'è una logica nel modo in cui il tuo prodotto è stato assemblato. Comprendi le regole di progettazione che il tuo prodotto sembra seguire, quindi raddoppiale. " Sembra che usiamo le tabelle per molte cose, incluso quando gli utenti devono scegliere con cosa interagire " forse si trasforma in una regola: " usiamo le righe della tabella per consentire agli utenti di scegliere tra elementi correlati ma indipendenti ".
4. Ottieni il consenso del/i tuo/i team: comunica la tua valutazione e il tuo piano. La costruzione del consenso è più facile a dirsi che a farsi, ma il fatto che tu abbia costruito questo sistema dal prodotto esistente renderà questa conversazione e transizione più facili rispetto a quando crei schemi e regole nuovi di zecca. Sicuramente molte di queste parti interessate hanno anche contribuito all'aspetto attuale del prodotto, quindi questo percorso è più rispettoso dei loro ruoli e di tutta la conoscenza organizzativa incorporata nei progetti esistenti.
5. Inizia a costruire con questo sistema: ora che conosci le regole da seguire e gli schemi da utilizzare, specifica questi schemi e inizia a seguire le regole! La prossima volta che i tuoi ingegneri inseriranno una tabella, una carta, un modulo, ecc., assicurati che sia quell'elemento specificato e che lo stiano usando nel modo giusto. Col tempo, più parti della tua interfaccia utilizzeranno questo nuovo sistema di progettazione, ma dovrebbe fondersi relativamente bene con le parti più vecchie dell'interfaccia.

Professionisti

• TANTO VERDE . Basando il nuovo sistema liberamente sui modelli esistenti, si arriva a "buono" più velocemente.
• Le "buone esperienze" si mescolano relativamente bene con le "vecchie esperienze", creando un'esperienza più fluida - sì, anche durante quei difficili mesi e/o anni di transizione.
• Un cambiamento meno radicale significa che puoi applicare i tuoi nuovi componenti e modelli più velocemente. Quindi, quando sono tutti collegati al sistema, puoi modificarli e aggiornarli a livello di sistema: ciò aumenta le probabilità che tu riesca a tenere il passo con i Jones della porta accanto (cioè i tuoi concorrenti) in seguito una volta che inevitabilmente ottengono una nuova interfaccia utente propria.
• Un cambiamento meno radicale può anche essere positivo dal punto di vista dell'utente: gli utenti notoriamente non amano il cambiamento (vedi ogni riprogettazione di Facebook, mai, o una riprogettazione su larga scala del tuo strumento B2B preferito), quindi evitare enormi balzi può mitigare gli urti nella tua relazione con il tuo utenti/clienti.
• Questo è meno dispendioso in termini di risorse e più naturale per la tua organizzazione organica. Al contrario della "rivoluzione" e delle gigantesche iniziative esecutive, questo può mantenere meglio la buona volontà del team. Fa sembrare giusto fare un buon design , piuttosto che sembrare un sacco di lavoro davvero difficile.

• Nessuno!
• Stavo solo scherzando. Come puoi vedere, in questo modello non siamo effettivamente arrivati ​​alla fase "ideale" del nirvana del design. Il modello "Evolution" più conservativo ci ha permesso di ottenere un buon design più velocemente e più facilmente, ma forse non abbiamo colto alcune opportunità di "grande idea" che altrimenti avremmo potuto avere.
• A volte, lavorare in piccolo e non pianificare una "grande visione" può farti perdere alcune dipendenze e/o opportunità in seguito nell'evoluzione del tuo sistema di progettazione. Ci sono modi per mitigare questo - ad esempio, avendo una sorta di visione diversa da "fare piccoli passi" - di cui parlerò in un post più dettagliato più avanti.
• A volte il "vecchio" design del prodotto nel tuo prodotto è davvero pessimo, quindi potrebbe non essere nemmeno un buon punto di partenza. (Questa è una strada mentale allettante da seguire, ma ti scoraggerei dal farlo: nella maggior parte dei casi, se stai lavorando su un prodotto di successo anche moderato, allora qualcosa nel vecchio design funziona bene, che tu lo preferisca o no ).

Il tuo compito è migliorare le esperienze che i tuoi clienti e utenti hanno con il tuo prodotto. Se punti alla luna su ogni piccolo progetto e poi bruci un sacco di risorse di ingegneria per trasformare quei cambiamenti in realtà, potresti "spendere" male quelle risorse e quindi limitare la quantità di lavoro che puoi fare per migliorare altre cose per i tuoi utenti . Rendere perfetto il flusso di un utente è meglio che rendere buoni i flussi di tre utenti ? Forse per te, ma probabilmente non per i tuoi utenti.

Essendo più realistico con il tuo sistema di progettazione, costruendolo dalle basi esistenti e mantenendolo favorevole alla transizione, puoi adottare più rapidamente un nuovo sistema e tu (e i tuoi utenti) potete iniziare a raccogliere i frutti.

Quindi, vai avanti ed evolvi!

Aggiornamento (circa un anno dopo)

Ho scritto un altro pezzo su questo sistema di progettazione su cui stavo lavorando per Hired, lo stesso progetto che ha ispirato questo pezzo "Evolution" un anno prima.

Ho ammorbidito un po' la mia posizione su un approccio "simile a una stella polare" date alcune lezioni da quel progetto, ma gli inquilini principali di questo post sono ancora validi: nella maggior parte dei casi, Evolution è ancora l'approccio responsabile per i tuoi utenti, il tuo prodotto e la tua organizzazione.