Progettare con il codice: un approccio moderno alla progettazione (sfide di sviluppo)

Questo articolo è stato gentilmente supportato dai nostri cari amici di UXPin, la cui missione è consentire le migliori esperienze utente unendo design e ingegneria in un mondo di sviluppo prodotto migliore e più veloce. Grazie!

L'attrito nella cooperazione tra designer e sviluppatori sta alimentando una discussione in continua evoluzione vecchia quanto il settore stesso. Abbiamo fatto molta strada fino a dove siamo oggi. I nostri strumenti sono cambiati. I nostri processi e le nostre metodologie sono cambiati. Ma i problemi di fondo spesso sono rimasti gli stessi.

Uno dei problemi ricorrenti che tendo a vedere spesso, indipendentemente dal tipo e dalle dimensioni della squadra, è mantenere una fonte affidabile di verità . Anche l'assunzione delle persone migliori e l'utilizzo di comprovate soluzioni standard del settore spesso ci lascia con il disgusto che qualcosa sicuramente avrebbe potuto essere fatto meglio. La famigerata "versione finale" è spesso distribuita su documentazione tecnica, file di progettazione, fogli di calcolo e altri luoghi. Mantenerli tutti sincronizzati è solitamente un compito noioso e scoraggiante.

Nota : questo articolo è stato scritto in collaborazione con il team UXPin. Gli esempi presentati in questo articolo sono stati creati nell'app UXPin. Alcune delle funzionalità sono disponibili solo sui piani a pagamento. La panoramica completa dei prezzi di UXPin può essere trovata qui.

Il problema con gli strumenti di progettazione

Parlando di mantenere una fonte di verità, l'inefficienza degli strumenti di progettazione viene spesso indicata come uno dei punti deboli più logoranti. Gli strumenti di progettazione moderni si stanno evolvendo e si evolvono rapidamente con enormi sforzi. Ma quando si tratta di costruire un ponte tra progettazione e sviluppo, non è raro avere l'impressione che molti di questi sforzi siano basati su presupposti errati.

La maggior parte dei moderni strumenti di progettazione si basa su modelli diversi rispetto alle tecnologie utilizzate per implementare i progetti in seguito. Sono costruiti come editor grafici e si comportano come tali. Il modo in cui i layout vengono creati ed elaborati negli strumenti di progettazione è in definitiva diverso da qualsiasi cosa abbiano da offrire CSS, JavaScript e altri linguaggi di programmazione. La creazione di interfacce utente utilizzando la grafica vettoriale (o anche raster) è una continua congettura su come e se ciò che si crea debba essere trasformato in codice in un secondo momento.

I designer spesso finiscono per lamentarsi del fatto che le loro creazioni non vengono implementate come previsto. Anche gli sforzi più coraggiosi verso un design perfetto per i pixel non risolvono tutti i problemi. Negli strumenti di progettazione, è quasi impossibile immaginare e coprire tutti i casi possibili. Il supporto di stati diversi, la modifica della copia, le varie dimensioni del viewport, le risoluzioni dello schermo e così via, forniscono semplicemente troppe variabili variabili per coprirle tutte.

Oltre a ciò, arrivano alcuni vincoli e limitazioni tecniche . Essendo un designer senza una precedente esperienza di sviluppo, è immensamente difficile prendere in considerazione tutti i fattori tecnici. Ricorda tutti i possibili stati degli input. Comprendere i limiti del supporto del browser. Prevedi le implicazioni sulle prestazioni del tuo lavoro. Design per l'accessibilità, almeno in un certo senso molto più ampio del contrasto cromatico e delle dimensioni dei caratteri. Essendo consapevoli di queste sfide, accettiamo una certa quantità di congetture come un male necessario.

Ma gli sviluppatori spesso devono dipendere anche da congetture. Le interfacce utente simulate con editor grafici raramente rispondono a tutte le loro domande. È lo stesso componente di quello che abbiamo già o no? Devo trattarlo come uno stato diverso o come un'entità separata? Come dovrebbe comportarsi questo progetto quando X, Y o Z? Possiamo farlo in modo leggermente diverso in quanto sarebbe più veloce ed economico? Ironia della sorte, chiedere in primo luogo a chi ha creato i progetti non è sempre utile. Non di rado, non lo sanno neanche loro.

E di solito, non è qui che finisce la portata della crescente frustrazione . Perché poi ci sono anche tutti gli altri . Manager, stakeholder, team leader, venditori. Con la loro attenzione e capacità mentale distese tra tutti gli strumenti e i luoghi in cui vivono le varie parti del prodotto, lottano più di chiunque altro per comprenderlo bene.

Esplorare i prototipi, capire perché alcune caratteristiche e stati mancano nei progetti e distinguere tra ciò che manca, ciò che è un lavoro in corso e ciò che è stato consapevolmente escluso dall'ambito sembra quasi impossibile. Anche ripetere rapidamente ciò che è già stato fatto, visualizzare il tuo feedback e presentare le tue idee sembra quasi impossibile. Ironia della sorte, strumenti e processi sempre più sofisticati sono rivolti a designer e sviluppatori per lavorare meglio insieme ; fissano il livello ancora più in alto e la partecipazione attiva ai processi per le altre persone ancora più difficile.

Le soluzioni

Innumerevoli capi del nostro settore hanno lavorato per affrontare quei problemi che hanno portato a nuovi paradigmi, strumenti e concetti. E infatti molto è cambiato in meglio. Diamo una rapida occhiata e quali sono alcuni degli approcci più comuni alle sfide delineate.

Progettisti di codifica

"I designer dovrebbero programmare?" è una domanda cliché discussa un numero infinito di volte attraverso articoli, conferenze e tutti gli altri media con nuove voci nella discussione che spuntano con regolarità stabile di tanto in tanto. C'è un presupposto comune che se i designer "sapere programmare" (non iniziamo nemmeno a soffermarci su come definire "saper programmare" in primo luogo), sarebbe più facile per loro creare progetti che prendano il vincoli in considerazione e sono più facili da implementare.

Alcuni andrebbero anche oltre e direbbero che dovrebbero svolgere un ruolo attivo nell'attuazione. A quel punto, è facile saltare alle conclusioni che non avrebbe senso saltare del tutto l'utilizzo degli strumenti di progettazione e semplicemente "progetta nel codice".

Per quanto l'idea possa sembrare allettante, raramente si rivela nella realtà. Tutti i migliori progettisti di codifica che conosco utilizzano ancora strumenti di progettazione. E questo non è sicuramente dovuto alla mancanza di competenze tecniche. Per spiegare il perché è importante evidenziare una differenza tra l'ideazione, lo schizzo e la costruzione della cosa reale.

Finché ci sono molti casi d'uso validi per la "progettazione nel codice" , come l'utilizzo di stili e componenti predefiniti per creare rapidamente un'interfaccia completamente funzionale senza preoccuparsi affatto degli strumenti di progettazione, la promessa di libertà visiva illimitata è offerta dagli strumenti di progettazione ha ancora un valore innegabile. Molte persone trovano lo schizzo di nuove idee in un formato offerto dagli strumenti di progettazione più facile e più adatto alla natura di un processo creativo. E questo non cambierà a breve. Gli strumenti di progettazione sono qui per rimanere e per rimanere per sempre.

Sistemi di progettazione

La grande missione dei sistemi di progettazione, una delle più grandi parole d'ordine del mondo del design digitale negli ultimi anni, è sempre stata esattamente questa: limitare le congetture e le ripetizioni, migliorare l'efficienza e la manutenibilità e unificare le fonti di verità. Sistemi aziendali come Fluent o Material Design hanno lavorato molto per sostenere l'idea e dare slancio all'adozione del concetto tra grandi e piccoli giocatori. E in effetti, i sistemi di progettazione hanno contribuito a cambiare molto in meglio. Un approccio più strutturato allo sviluppo di una raccolta definita di principi di progettazione, modelli e componenti ha aiutato innumerevoli aziende a creare prodotti migliori e più sostenibili .

Tuttavia, alcune sfide non sono state risolte immediatamente. La progettazione di sistemi di progettazione con strumenti di progettazione popolari ha ostacolato gli sforzi di molti nel raggiungere un'unica fonte di verità. Invece, è stata creata una pletora di sistemi che, anche se unificati, esistono ancora in due fonti separate e incompatibili: una fonte di progettazione e una fonte di sviluppo. Mantenere la parità reciproca tra i due di solito si rivela un compito doloroso, ripetendo tutti i punti dolenti più odiati che i sistemi di progettazione stavano cercando di risolvere in primo luogo.

Design e integrazioni di codice

Per risolvere i problemi di manutenibilità dei sistemi di progettazione è presto arrivata un'altra ondata di soluzioni. Concetti come i design token hanno iniziato a prendere piede. Alcuni erano pensati per sincronizzare lo stato del codice con i progetti, come le API aperte che consentono di recuperare determinati valori direttamente dai file di progetto. Altri erano pensati per sincronizzare i progetti con il codice, ad esempio generando componenti negli strumenti di progettazione dal codice.

Poche di queste idee hanno mai ottenuto un'adozione diffusa. Ciò è molto probabilmente dovuto al discutibile vantaggio di possibili benefici rispetto ai necessari costi di ingresso di soluzioni ancora altamente imperfette. La traduzione automatica dei progetti in codice pone ancora enormi sfide per la maggior parte dei casi d'uso professionali. Anche le soluzioni che consentono di unire il codice esistente con i progetti sono state fortemente limitate.

Ad esempio, nessuna delle soluzioni che consentono di importare componenti codificati negli strumenti di progettazione, anche se visivamente fedele all'origine, replicherebbe completamente il comportamento di tali componenti. Nessuno fino ad ora.

Unione di design e codice con UXPin

UXPin, essendo un'app di progettazione matura e completa, non è un nuovo attore nella fase degli strumenti di progettazione. Ma i suoi recenti progressi, come la tecnologia Merge, sono ciò che può cambiare le probabilità di come pensiamo agli strumenti di progettazione e sviluppo.

UXPin con la tecnologia Merge ci consente di portare componenti reali e live nel design preservandone sia la grafica che la funzionalità, il tutto senza scrivere una singola riga di codice. I componenti, anche se incorporati nei file di progettazione, si comporteranno esattamente come le loro controparti reali, perché sono le loro controparti reali. Questo ci consente non solo di ottenere una perfetta parità tra codice e design, ma anche di mantenere i due sincronizzati ininterrottamente.

UXPin supporta le librerie di progettazione dei componenti React archiviati nei repository git, nonché una solida integrazione con Storybook che consente l'utilizzo di componenti da quasi tutti i framework front-end più diffusi. Se desideri provarlo tu stesso, puoi richiederne l'accesso sul sito Web UXPin:

• Richiedi l'accesso a UXPin con tecnologia Merge →

L'unione di componenti live con progetti in UXPin richiede sorprendentemente pochi passaggi. Dopo aver trovato il componente giusto, puoi posizionarlo sull'area di disegno con un clic. Si comporterà come qualsiasi altro oggetto all'interno dei tuoi progetti. Ciò che lo renderà speciale è che, pur essendo parte integrante dei design, ora puoi usarlo e personalizzarlo come faresti nel codice .

UXPin ti dà accesso alle proprietà del componente, ti consente di modificarne i valori e le variabili e di riempirlo con i tuoi dati. Una volta avviato il prototipo, il componente si comporterà esattamente come previsto, mantenendo tutti i comportamenti e le interazioni.

Nei tuoi progetti puoi combinare e abbinare un numero illimitato di librerie e sistemi di progettazione . Oltre ad aggiungere una tua libreria, puoi anche scegliere tra un'ampia varietà di librerie open source disponibili immediatamente come Material Design, Fluent UI o Carbon.

Usare un componente "così com'è" significa anche che dovrebbe comportarsi in base al cambiamento del contesto, come la larghezza della finestra. In altre parole, tali componenti sono completamente reattivi e adattabili.

Nota : se desideri saperne di più sulla creazione di design veramente reattivi con UXPin, ti consiglio vivamente di consultare questo articolo.

Il contesto può anche significare un tema. Chiunque abbia provato a costruire (e mantenere!) un sistema di progettazione a tema in uno strumento di progettazione, o almeno creare un sistema che consenta di passare facilmente da un tema chiaro a uno scuro, sa quanto sia complicato e quanto imperfetto sia il tema. i risultati di solito lo sono. Nessuno degli strumenti di progettazione è ben ottimizzato per la creazione di temi pronti all'uso e i plug-in disponibili volti a risolvere il problema sono lontani dal risolverlo completamente.

Poiché UXPin con la tecnologia Merge utilizza componenti reali e live, puoi anche tematizzarli come componenti reali e live . Non solo puoi creare tutti i temi di cui hai bisogno, ma cambiarli può essere veloce come scegliere il tema giusto da un menu a discesa. (Puoi leggere di più sul cambio di tema con UXPin qui.)

Vantaggi

UXPin con tecnologia Merge consente un livello di parità tra design e codice raramente visto prima. Essere fedeli alla fonte in un processo di progettazione porta vantaggi impeccabili per tutti i lati del processo. I designer possono progettare con sicurezza sapendo che ciò che realizzano non verrà interpretato erroneamente o sviluppato in modo errato. Gli sviluppatori non devono tradurre i progetti in codice e confondersi con casi limite inespliciti e scenari scoperti. Inoltre, tutti possono partecipare al lavoro e prototipare rapidamente le proprie idee utilizzando componenti live senza alcuna conoscenza del codice sottostante. Raggiungere processi più democratici e partecipativi è molto più a portata di mano.

L'unione del tuo progetto con il codice potrebbe non solo migliorare il modo in cui i designer collaborano con gli altri componenti del team, ma anche perfezionare i loro processi e pratiche interni. UXPin con la tecnologia Merge può essere un punto di svolta per coloro che si concentrano sull'ottimizzazione degli sforzi di progettazione su larga scala , a volte indicati come DesignOps.

L'uso della giusta fonte di verità rende inspiegabilmente più facile mantenere la coerenza tra i lavori prodotti da persone diverse all'interno del team, aiuta a mantenerli allineati e risolve i problemi giusti insieme a un insieme comune di strumenti. Niente più "simboli distaccati" con una manciata di variazioni non richieste.

In conclusione, ciò che otteniamo sono enormi risparmi di tempo . I progettisti risparmiano tempo utilizzando i componenti con sicurezza e le loro funzionalità fuori dagli schemi. Non devono aggiornare i file di progettazione man mano che i componenti cambiano, né documentare il loro lavoro e "agitare le mani" per spiegare le loro visioni al resto del team. Gli sviluppatori risparmiano tempo ottenendo i componenti dai progettisti in un modo immediatamente digeribile che non richiede congetture e armeggi aggiuntivi.

I responsabili dei test e del controllo qualità risparmiano tempo cercando incongruenze tra design e codice e cercando di capire se l'impianto è avvenuto come previsto. Le parti interessate e gli altri membri del team risparmiano tempo grazie a una gestione più efficiente e a una navigazione più semplice di tali team. Meno attrito e processi senza interruzioni limitano la frustrazione tra i membri del team.

Svantaggi

Tuttavia, sfruttare questi vantaggi comporta alcuni costi di ingresso. Per utilizzare in modo efficiente strumenti come UXPin nel processo, è necessario disporre di un sistema di progettazione esistente o di una libreria di componenti . In alternativa, puoi basare il tuo lavoro su uno dei sistemi open source che fornirebbe sempre un certo livello di limitazione.

Tuttavia, se ti impegni in primo luogo a costruire un sistema di progettazione, l'utilizzo della tecnologia UXPin con Merge nel tuo processo comporterebbe costi aggiuntivi minimi o nulli. Con un sistema di progettazione ben costruito, l'adozione di UXPin non dovrebbe essere una lotta, mentre i vantaggi di un tale cambiamento potrebbero rivelarsi drastici.

Sommario

L'adozione diffusa di sistemi di progettazione ha affrontato i problemi degli sviluppatori di media e dei designer con cui lavorano. Attualmente, possiamo osservare uno spostamento verso processi più unificati che non solo trasformano il mezzo ma anche il modo in cui lo creiamo. Usare gli strumenti giusti è fondamentale per quel cambiamento. La tecnologia UXPin with Merge è uno strumento di progettazione che consente di combinare la progettazione con componenti di codice live e riduce drasticamente il divario tra la progettazione e lo sviluppo dei domini in cui operano.

Dove Avanti?

• UXPin Merge: integrazione di libri di fiabe
  Scopri come l'integrazione di Storybook può aiutare il tuo team di prodotti e provalo!
• Fusione UXPin: integrazione Git
  Richiedi l'accesso per vedere come funziona l'integrazione con il repository Git.
• Breve video esplicativo su UXPin Merge
  Nell'ambito di "Sistemi di progettazione interattiva: Webinar con Johnson & Johnson".
• Design con codice: UXPin Merge Tutorial
  Un tutorial introduttivo a UXPin con la tecnologia Merge.
• Design reattivo con UXPin Merge
  Una guida alla prototipazione di esperienze completamente reattive con UXPin con la tecnologia Merge.