I progettisti e gli ingegneri possono usare un'unica fonte di verità? Parte 1.

L'incubo ricorrente per designer e ingegneri (Parte 1 di 2)

Sei un designer.

Il tuo ultimo progetto, proprio come ogni progetto precedente, è finito in una spirale di caos.

È iniziato con il tuo file vettoriale pulito che illustrava le schermate principali, ma è finito come settimane avanti e indietro con ingegneri e parti interessate. Tutti volevano avere voce in capitolo. Tutti hanno trovato qualcosa che mancava. Tante parti dell'interfaccia utente hanno molti stati - non c'è da meravigliarsi se ti sei dimenticato di disegnare un'intera tavola da disegno per ognuno di loro! Inoltre - il Primo Ministro ti stava minacciando con tutte le scadenze. Oh, e il tuo strumento vettoriale ha iniziato a rimanere in ritardo con oltre 100 tavole da disegno che descrivono dettagliatamente gli stati che la gente ha chiesto di vedere. Le cose sono diventate rapidamente frenetiche! Proprio quando pensavi di avere un certo controllo su questo casino, gli sviluppatori hanno terminato il primo set di funzionalità. Hai sentito il sangue scorrere sul tuo viso - niente sembra nel modo in cui dovrebbe. La tipografia era tutta incasinata. I colori sono spenti.

Ti sei chiesto, "Perché gli ingegneri non riescono a fare le cose nel modo giusto?" Dopo tutto, hai inviato loro il tuo progetto vettoriale accompagnato da una specifica CSS generata da questo nuovo strumento alla moda. Gli ingegneri hanno detto di aver usato le specifiche e che dovresti smettere di usare gli strumenti di illustrazione vettoriale per la progettazione dell'interfaccia utente, ma non sei d'accordo. Tutti nella tua comunità di progettazione Slack utilizzano questo strumento.

Inizi ad alzare la voce quando noti che il tuo selettore di date sembra completamente diverso. Dicono che hanno già un selettore di date e la codifica di uno nuovo ritarderebbe il progetto, probabilmente porterebbe a più bug e probabilmente sarebbe terribile anche per gli utenti. Non hai idea di cosa stiano parlando. La tua libreria di simboli vettoriali non ha questo selettore di date che hanno menzionato. E per aggiungere la beffa al danno, non hanno nemmeno creato questa fantastica animazione per la quale hai inviato loro una GIF. Apparentemente ci vorranno almeno due settimane per ricreare.

Ti senti sconfitto. Utilizzi gli strumenti che sembrano essere popolari e tuttavia non sei mai in grado di offrire le esperienze che hai pianificato. Il processo sembra interrotto.

Sei un ingegnere.

Il tuo ultimo progetto, proprio come ogni progetto precedente, è finito in una spirale di caos. I designer, ancora una volta, non hanno specificato tutti gli stati dei componenti, ma hanno generato un allarme quando hai riempito gli spazi vuoti con hover e stati attivi in ​​base alle classi che avevi già nei tuoi file CSS. La tua impazienza ha colpito il soffitto in una riunione di 3 ore sulle incongruenze tra le immagini vettoriali e il codice reale. Hai fatto del tuo meglio per spiegare che le illustrazioni statiche create in quei file vettoriali non possono essere ricreate con precisione nel codice. I browser e gli strumenti vettoriali vivono in mondi completamente diversi e le cose avranno sempre un aspetto diverso. I designer non volevano ascoltare e attaccavano costantemente il tuo team con il concetto di "pixel perfect design". Volevi dire che sarebbe perfetto per i pixel se usassero strumenti che usano effettivamente i CSS per lo styling. Tuttavia, ti sei fermato. Hai avuto questa discussione (argomento) prima. Speri ancora che un giorno i progettisti capiranno, che agli utenti non importa dei loro file vettoriali perfetti, gli utenti sperimentano solo ciò che è stato creato nel codice. A meno che i designer non inizino a lavorare più vicino al codice, le cose saranno sempre rotte.

Hai alzato gli occhi quando hanno portato il problema di un selezionatore di date. Il team ha fatto lo sforzo di creare una libreria modulare di componenti che vengono riutilizzati in tutte le interfacce. Risparmia molto tempo a tutto il tuo team, migliora decisamente l'esperienza utente (tutti i componenti sono testati correttamente) e ci sono meno bug nel sistema. Non è colpa tua se i progettisti hanno difficoltà a sincronizzarsi con questa realtà. Se te lo chiedessero, diresti che provare a disegnare manualmente tutti i componenti che già esistono nel codice è un'idea terribile e sarà sempre fonte di errori. Non ascoltano.

E la goccia finale - ancora una volta hanno disegnato alcune animazioni in uno strumento che genera un GIF. Si aspettano davvero che tu codifichi qualcosa mentre guardi una GIF lunga 5 secondi? Non solo è un processo terribile, ma per quanto riguarda la scadenza del progetto? Che dire delle prestazioni di questa fantasia animazione?

Ti senti sconfitto. Stai ancora guardando un'altra lunga notte cercando di recuperare il ritardo con tutte le modifiche da apportare. Sai che il risultato finale sarà una delusione e vorresti che le cose fossero più unificate. Questo processo è completamente interrotto.

Strumenti sbagliati. Processi sbagliati.

Suona familiare? Questo è lo stato dello sviluppo del prodotto digitale nel 2019.

Designer e ingegneri esprimono i loro pensieri e idee con strumenti privi di compatibilità e sincronicità. Gli sviluppatori lavorano con le tecnologie di produzione finali specifiche per la piattaforma, i progettisti utilizzano spesso strumenti di illustrazione vettoriale (Sketch, Figma, XD ...) per progettare rappresentazioni statiche di interfacce.

Quei due non potrebbero essere più diversi e meno compatibili:

  • Diversi motori di rendering utilizzati, ad esempio, in un browser e uno strumento di illustrazione vettoriale, causano differenze irrisolvibili nella resa dei caratteri, nei colori e nei gradienti.
  • L'animazione di tavole da disegno statiche con strumenti che emettono GIF (ad es. Principio) porta a un processo spesso doloroso e lento di tradurre una GIF in codice performante e affidabile.
  • La mancanza di connessione tra componenti codificati e strumenti di illustrazione vettoriale blocca l'adozione dei sistemi di progettazione e porta a un'esperienza di prodotto incoerente, errata e costosa.

L'output errato di uno strumento di progettazione porta all'input errato fornito al processo di sviluppo. Quelli combinati danno come risultato un output errato vissuto dagli utenti. Finché l'ingresso rimane errato, il risultato finale non sarà soddisfacente.

Lascia che ti dia un'analogia. Immagina di cuocere una torta. Stai guardando l'immagine di una bella torta al limone in un ricettario. La prima cosa da fare è prendere una tazza di farina. Ti senti creativo, quindi, invece, strappi la ricetta dal libro e la fai a pezzi. Hmm ... Sembra farina ed è fatta con le stesse cose dell'illustrazione nel libro: deve portare a un delizioso dessert, giusto? No. L'input è completamente errato e, a meno che tu non lo sostituisca con cose reali, quella torta farà ammalare la tua cara famiglia. Per non parlare del gusto orribile.

Cuocere la torta con ingredienti veri. Foto di Alexandra Golovac su Unsplash.

I designer devono tornare alla realtà e "cuocere la torta" con ingredienti reali, non immagini di ingredienti. E gli strumenti di progettazione devono essere in grado di produrre gli ingredienti reali ... non semplici immagini.

Ecco un'idea: non dare la colpa ai designer. Non dare la colpa agli ingegneri. Dai la colpa agli strumenti di progettazione che sono bloccati nel paradigma sbagliato e impediscono all'industria di progredire verso un design unificato: il processo di ingegneria.

Dai un'occhiata alla seconda parte di questo articolo su come risolvere questo incubo in corso.