The following article is offered for informational purposes only, and is not intended to provide, and should not be relied on, for legal or financial advice. Please consult your own legal or accounting advisors if you have questions on this topic.

In Flex, siamo un piccolo team di ingegneri noto per superare le aspettative, con una forte propensione all'azione. Dopo alcuni anni di rapidi cambiamenti e pivot di prodotto, avevamo accumulato una notevole quantità di debito UX che iniziava a manifestarsi in un'esperienza goffa. 

Dovevamo ancora rilasciare rapidamente, ma con uno standard di qualità molto più elevato e una comprensione condivisa di cosa significasse realmente "qualità". Tuttavia, quando mi è stata proposta l'idea di creare un sistema di design, sono andato in modalità panico.

Avendo già costruito due sistemi di design, conoscevo le insidie che possono comportare: lavoro personalizzato non necessario, discussioni futili, documentazione obsoleta, ecc. Non avevamo il tempo o le risorse per farci coinvolgere dal bagaglio che i sistemi di design possono portare con sé. 

La Richiesta

La domanda è diventata rapidamente: "Come possiamo implementare un sistema di design 'leggero' — uno che offra valore senza rallentarci?"

La prima cosa che dovevamo fare era valutare cosa comportasse un sistema di design completo rispetto al sistema leggero che intendevamo costruire.

Sistemi di Design Normali e Completi

• Componenti personalizzati (pulsanti, modali, tabelle, ecc.)
• Strumenti personalizzati (configurazioni Storybook, infrastruttura interna)
• Processi/governance per le modifiche
• Costi di manutenzione elevati

Sistemi di Design Leggeri

• Solo i componenti e i pattern più utilizzati
• Facile da adottare — documentazione e codice risiedono dove gli sviluppatori già lavorano
• Sfrutta le librerie esistenti invece di costruire da zero (quando possibile)
• Ha standard per mostrare l'utilizzo

I Nostri Vincoli: Team piccolo, grandi obiettivi.

Abbiamo iniziato con una serie elegante di design che spaziavano da componenti a livello atomico (pulsanti, input, ecc.) a layout comuni e flussi a più passaggi. 

Durante questo processo, abbiamo fatto ogni sforzo per non creare nuovi componenti se non strettamente necessario. Sfruttare gli strumenti scelti era imperativo. Siamo una piccola azienda che produce un'enorme quantità di lavoro ogni settimana; l'ultima cosa di cui avevamo bisogno era di impantanarci in minuzie su problemi personalizzati derivanti da componenti personalizzati.

Sebbene le incongruenze visive fossero evidenti, un problema più profondo che avevo notato in Flex era la mancanza di un approccio unificato alla creazione di interfacce utente comuni, come i moduli. Si poteva entrare nel codebase e trovare cinque modi diversi in cui stavamo implementando le UI dei moduli. Era chiaro che avevamo bisogno di una serie di standard.

Creazione di una serie di standard unificati

In precedenza avevamo iniziato a lavorare su una sezione "cheat-sheet" per gli sviluppatori, per avere una raccolta di best practice da copiare/incollare. Questo è diventato il luogo perfetto per mostrare il nostro sistema di design emergente. Potevamo usare quest'area (successivamente rinominata "Playground") per consentire agli sviluppatori di visualizzare e utilizzare questi standard per le nostre UI più comuni per avviare il loro lavoro, e anche permettere ai designer di vedere che ciò che avevano costruito era effettivamente ciò che veniva utilizzato. Infine, avere questo integrato nella nostra app web (piuttosto che esternamente, tramite una piattaforma come Storybook) ha contribuito a garantirne l'utilizzo.

Tuttavia, la storia era appena iniziata. Avevamo un paio di draghi da sconfiggere prima:

1. Eravamo bloccati in una versione precedente della libreria UI scelta e sarebbe stato uno sforzo piuttosto erculeo aggiornarla. Questo cambiamento avrebbe interessato l'intera nostra app rivolta ai clienti e il nostro strumento interno, Alfred.
2. Dovevamo combinare i repository per co-localizzare le nostre app interne e web per garantire l'utilizzo del sistema di design tra le app.

Dopo aver completato queste tappe, abbiamo ri-tematizzato entrambe le app per adattarle ai nuovi design e lo slancio ha iniziato a crescere.

Moltiplicatori di forza

Dopo aver ri-tematizzato il nostro strumento interno, Alfred, e l'app web, abbiamo iniziato a creare una serie di best practice in Playground. Nel tempo, Playground ha racchiuso l'“80/20” dei nostri casi d'uso — un punto di riferimento unico per componenti, layout e utilità condivise.

‍

‍

Sebbene sapessimo che Playground sarebbe stato utile per gli sviluppatori per copiare/incollare componenti e avviare il lavoro, questa raccolta di standard si è rivelata perfetta per gli LLM per capire come dovrebbe essere generato il codice UI.

Ecco: Cursor

Poco dopo aver iniziato a costruire Playground, il nostro team frontend ha iniziato a utilizzare Cursor AI. Abbiamo creato il nostro Playground di riferimento per le regole di Cursor per usarlo come punto di partenza quando si genera qualsiasi codice basato su UI:

• Per esempi su come utilizzare i componenti del nostro sistema di design, consulta il Playground in `src/areas/playground`.
• Quando si implementano nuovi componenti come Drawers, Tables, Wizards, Layouts, ecc., copia il file così come è implementato nel Playground e usalo come punto di partenza nell'area su cui stai lavorando.
• La maggior parte delle volte non aggiornerai alcun file in `src/areas/playground`, ma semplicemente userai i componenti presenti come punti di partenza da copiare in nuove cartelle in `src/areas`.

Il nostro precedente sforzo di re-theming ha ripagato enormemente qui, poiché ha aperto la strada a Cursor per costruire interfacce utente coerenti con il nostro sistema di design senza dover consultare alcuna linea guida di stile.

Per approfondire ulteriormente il significato di "qualità frontend in Flex", abbiamo codificato gli standard su cui ci eravamo precedentemente accordati come team UI. Cursor fa riferimento a questo, oltre alle regole del Playground, in modo che l'LLM comprenda non solo cosa dovrebbe essere costruito, ma anche come costruirlo in congiunzione con i nostri vari strumenti e convenzioni. Ecco un estratto di come facciamo riferimento alla nostra attuale libreria UI, Mantine, dal nostro file di regole di Cursor:

• Usa Mantine come libreria di componenti React di base.
• Sfrutta appieno la libreria Mantine, inclusi componenti da `@mantine/core`, hook da `@mantine/hooks`, form con `@mantine/form`.
• Per i componenti, prova sempre a usare prima i componenti nelle nostre cartelle `components/core` o `components/composites`, altrimenti usa i componenti Mantine core ogni volta che è possibile.
• Evita di usare stili inline o classi — prova sempre prima a usare le prop di Mantine per stilizzare colori e colori di sfondo, spaziatura e dimensioni, ecc.
• Per i colori, usa sempre i colori del nostro tema Mantine (es. `theme.colors.yourColorHere[index]`).
• Per spaziatura e dimensioni, usa la funzione `rem()` di Mantine invece di valori in pixel o numerici, ad es. `gap={rem(12)}`

Risultati Flex

L'uso dell'IA insieme al nostro sistema di design ha rappresentato un punto di svolta su tutta la linea per creare e mantenere uno standard più elevato di velocità e qualità. La nostra recente funzionalità di Contabilità Clienti è stata realizzata interamente in tre settimane! 

Allo stesso modo, l'utilizzo del Playground come solida raccolta di componenti e pattern ha rafforzato il nostro standard di qualità, sia per gli sviluppatori che per gli LLM. Perseguendo un approccio più leggero alla costruzione di un sistema di design, siamo stati in grado di aggirare le numerose insidie spesso associate ai sistemi di design, preservando al contempo i vantaggi di coerenza e direzione.

Recentemente, abbiamo usato il Playground come risorsa educativa per mostrare come gli sviluppatori possano usare alternative a uno strumento di gestione dello stato che stiamo attivamente cercando di deprecate. Nel prossimo futuro, puntiamo ad allegare i nostri standard del Playground alla nostra build CI per garantire ulteriormente l'adozione.

Lezioni per altri team

Se sei in una fase iniziale, ecco cosa raccomandiamo:

• Inizia in piccolo: Concentrati sui componenti UI più utilizzati
• Evita lavori personalizzati: La maggior parte delle moderne librerie di componenti UI può essere utilizzata per avviare il tuo sistema di progettazione. Riserva il lavoro personalizzato per componenti e flussi di lavoro più complessi
• Sii specifico su cosa sia il "buono": Assicurati che il tuo team abbia un insieme di standard concordati sugli strumenti UI e sulle convenzioni di codifica, in modo da poterli codificare con gli strumenti AI
• Rendilo evidente al tuo team: Incorpora il tuo sistema di progettazione nel prodotto per assicurarti che venga utilizzato
• Rendilo accessibile per gli LLM: Assicurati che i tuoi strumenti AI possano facilmente fare riferimento al tuo sistema di progettazione e ai tuoi standard per garantire l'allineamento prima di generare codice

Considerazioni finali

Probabilmente non hai bisogno di un sistema di progettazione personalizzato o completo. Ne hai bisogno di uno utile.

In Flex, il nostro sistema di progettazione è diventato un moltiplicatore per l'ingegneria, il prodotto e il design. Ci ha aiutato a muoverci più velocemente con uno standard di qualità molto più elevato.

Per i team in fase iniziale che puntano sulla velocità e sugli strumenti AI, questo potrebbe essere uno degli investimenti infrastrutturali più intelligenti che si possano fare.

‍