Product Design e UI/UX

Design system

Un'unica fonte condivisa per l'aspetto e il comportamento del tuo prodotto. Token, componenti e documentazione che mantengono design e codice coerenti man mano che il tuo prodotto e il tuo team crescono.

Parliamo del tuo progettoParla del tuo design system

Chi ha bisogno di un sistema condiviso

Una semplice modifica, come un nuovo colore del brand o uno stile di focus migliore, deve essere apportata schermata per schermata in ogni prodotto, perché design e codice non condividono più le stesse parti. Un design system offre a ogni team lo stesso set mantenuto di parti da cui costruire.

  • Organizzazioni in cui più squadre rilasciano UI per lo stesso prodotto contemporaneamente
  • Aziende che integrano prodotti acquisiti o sviluppati separatamente in un'unica famiglia di prodotti
  • Team di piattaforma frontend a cui viene chiesto di trasformare la UI condivisa in un pacchetto versionato e mantenuto

La coerenza che designer e sviluppatori condividono

Quando ogni team crea i propri pulsanti, moduli e modali, i prodotti divergono: schermate incoerenti, lavoro ripetuto e correzioni di accessibilità fatte in un punto ma non in un altro. Costruiamo design system che collegano design e codice: token, librerie Figma, componenti in codice e documentazione, con una governance che mantiene il sistema aggiornato. È adatto ai prodotti SaaS in crescita, alle aziende con più prodotti e ai team in transizione verso un nuovo frontend. Possiamo consegnare solo la parte di design o l'intero sistema dal design al codice.

Audit assistiti dall'AI, standard di proprietà degli esperti

Come l'IA assiste

  • Inventaria le tue schermate e il tuo codebase, elencando componenti duplicati e colori e spaziature scritti direttamente nel codice.
  • Redige la documentazione dei componenti, le linee guida d'uso ed esempi di codice che designer e ingegneri potranno revisionare.
  • Genera lo scaffolding di componenti in codice, storie Storybook e test a partire dai design approvati, sotto la revisione dell'ingegneria.
  • Segnala colori, spaziature e componenti fuori sistema nelle pull request, così la deriva viene individuata durante la code review.

Di cosa si occupano i nostri esperti

  • Designer e ingegneri sono proprietari dell'architettura dei token, della denominazione e della strategia di theming.
  • Gli ingegneri definiscono l'API, il comportamento e gli stati di ciascun componente e revisionano ogni modifica assistita dall'AI.
  • L'accessibilità viene verificata per ogni componente: comportamento da tastiera, focus, ruoli ARIA, contrasto e output degli screen reader.
  • Le persone sono proprietarie della governance: cosa entra nel sistema, versioning, deprecazione e regole di contribuzione.

Cosa contiene ogni livello del sistema

Livelli tipici per un sistema web multi-prodotto; il tuo audit decide cosa va in ciascuno.

  • Token e temi

    • Valori base per colore, scala tipografica, spaziatura e raggio degli angoli
    • Alias semantici come surface, border e danger che i componenti utilizzano
    • Temi chiaro, scuro e di brand creati scambiando i valori degli alias
    • Token di motion per durata ed easing, condivisi con le specifiche di interazione
    • Esportazioni in variabili CSS e, dove necessario, in formati iOS e Android

  • Componenti e stati

    • Pulsanti, input, select, modali e tabelle costruiti solo a partire dai token
    • Una specifica per componente: props, varianti, stati e comportamento da tastiera
    • Nomi delle varianti Figma che corrispondono alle props del componente codificato
    • Parti composite come date picker e combobox, assemblate da componenti più piccoli

  • Pattern, linee guida e governance

    • Pattern che combinano componenti: layout di form, filtraggio, azioni in blocco, onboarding
    • Linee guida su quando usare ogni pattern, e quando no
    • Percorso di contribuzione: proposta, revisione del design e del codice, poi un rilascio versionato
    • Stato del componente, da bozza a deprecato, con note di migrazione per le modifiche che introducono incompatibilità

Come costruiamo un design system

  1. 01

    Audit

    Inventariamo la tua UI e il tuo codice attuali con analisi assistita dall'AI, poi concordiamo le priorità: cosa standardizzare per primo e cosa dismettere.

  2. 02

    Fondamenta

    Token per colore, tipografia, spaziatura e movimento, con regole di denominazione e theming concordate tra designer e ingegneri.

  3. 03

    Componenti

    Componenti progettati in Figma e, quando previsto nello scope, costruiti in codice, ciascuno revisionato per comportamento e accessibilità al momento della consegna.

  4. 04

    Documentare e adottare

    Documentazione, regole di contribuzione e una guida pratica con i tuoi team, poi supporto alla migrazione man mano che i prodotti passano al sistema.

Due modi di lavorare con gli strumenti AI

L'AI aiuta a sintetizzare la ricerca consentita e a esplorare i design. Scegli dove può elaborare la tua ricerca e i tuoi file.

Non sei sicuro? Te ne consiglieremo uno durante la definizione dell'ambito. Confronta le opzioni di delivery AI

Cosa ricevi

Un sistema per design e codice

  • Audit e inventario dell'interfaccia utente

    Un catalogo dei componenti, pattern e stili che già possiedi, con duplicati, incoerenze e lacune di accessibilità prioritizzati.

  • Design token

    Token di colore, tipografia, spaziatura, raggio, elevazione e movimento, con temi chiari, scuri o di brand, esportati per web, iOS e Android secondo necessità.

  • Libreria di componenti Figma

    Componenti con varianti, proprietà e ogni stato di interazione, costruiti sui token e denominati in modo da corrispondere al codice.

  • Componenti in codice

    Componenti in React o nel tuo framework, con prop tipizzate, test e comportamento accessibile, pubblicati come pacchetto versionato quando previsto nello scope.

  • Sito di documentazione

    Storybook o un sito di documentazione personalizzato con esempi dal vivo, indicazioni d'uso, cosa fare e cosa evitare e note di accessibilità per ciascun componente.

  • Governance e versioning

    Regole di contribuzione, fasi di revisione, note di rilascio e un processo di deprecazione, così il sistema cambia in modo controllato.

Richieste tipiche di design system

Scenari tipici che definiamo, non case study di clienti.

  • Un rebrand su più prodotti

    Un'azienda con un'app web, un'app mobile e uno strumento di amministrazione sta cambiando i colori del proprio brand. Spostiamo prima i colori in token tematizzati, così ogni prodotto recupera la nuova palette dallo stesso punto.

  • Figma e codice non allineati

    I designer mantengono una libreria Figma che gli sviluppatori hanno smesso di usare, mentre i componenti React portano la propria spaziatura e i propri colori. Facciamo l'audit di entrambi, concordiamo quale versione di ogni componente diventa lo standard e allineiamo i nomi affinché design e codice corrispondano.

  • Una correzione di accessibilità per ogni prodotto

    Una revisione dell'accessibilità rileva problemi di focus e tastiera nel date picker, nel modale e nel dropdown utilizzati in più prodotti. Li correggiamo una volta nei componenti condivisi, documentiamo il comportamento da tastiera previsto e pubblichiamo una versione che ogni prodotto può adottare.

Cosa non copre questo ingaggio

  • La progettazione delle singole schermate del tuo prodotto non fa parte di questo lavoro; la UI schermata per schermata è Figma & Visual Design, che può costruire sul sistema.
  • I token di motion sono inclusi; la progettazione delle transizioni, dei gesti e della coreografia che li utilizzano è Interaction Design.
  • Lo spostamento delle schermate esistenti di ogni prodotto sul sistema è sviluppo di prodotto, con ambito definito separatamente; il sistema viene fornito con note di migrazione e il supporto che concordiamo.
  • Un sistema necessita di un proprietario designato dalla tua parte dopo il passaggio di consegne, o di un accordo di manutenzione concordato con noi; senza di esso, la deriva ritorna.

Come il sistema supporta build, QA e rilasci

  • Gli ingegneri costruiscono a partire da parti condivise

    Gli sviluppatori compongono le schermate a partire da componenti e token testati invece di ricostruirli, e le modifiche al design si mappano direttamente nel codice.

  • QA a livello di componente

    I componenti portano con sé le proprie verifiche di regressione visiva e di accessibilità, così i test di rilascio possono concentrarsi sui percorsi e sulle regole di business.

  • Rilasci di sistema controllati

    Pacchetti versionati, changelog e note di migrazione permettono a ciascun prodotto di adottare gli aggiornamenti di sistema in modo deliberato, non di sorpresa.

  • Mantenuto man mano che cresci

    Possiamo mantenere il sistema dopo il lancio: aggiungendo componenti, revisionando i contributi e mantenendo design e codice allineati.

FAQ

Domande frequenti

Abbiamo già bisogno di un design system?

Di solito conviene quando più persone progettano o costruiscono il prodotto, quando gli stessi componenti vengono ricostruiti in modi diversi o quando gestisci più di un prodotto o piattaforma. Per un prodotto in fase iniziale, potremmo consigliare un inizio più leggero: token e componenti principali, estesi man mano che il prodotto cresce.

Potete costruire sui nostri componenti esistenti?

Sì. Facciamo l'audit di ciò che hai, manteniamo ciò che funziona, standardizziamo il resto e colmiamo le lacune. La migrazione può essere graduale, così il lavoro sul prodotto non si ferma mentre viene introdotto il sistema.

Costruite la libreria in codice, o solo la parte Figma?

Entrambe le cose. Un incarico solo di design ti fornisce la libreria Figma, i token e le linee guida di implementazione per i tuoi sviluppatori. Se vuoi anche i componenti in codice, i nostri ingegneri li costruiscono e testano nel tuo stack. L'hosting per il sito di documentazione viene concordato separatamente.

Dove viene elaborato il nostro codice quando l'AI aiuta a costruire i componenti?

Questo viene concordato prima dell'inizio del lavoro. Con l'ingegneria AI privata / locale, l'elaborazione AI viene eseguita su modelli ospitati privatamente all'interno di un confine concordato. Con l'ingegneria Claude Code / OpenAI Codex, gli agenti di codifica commerciali operano secondo impostazioni concordate di account, gestione dei dati e conservazione. In entrambi i casi, gli ingegneri revisionano ogni modifica.

Costruisci un sistema che i tuoi team utilizzeranno

Parlaci dei tuoi prodotti, dei tuoi team e della tua attuale UI. Ti consiglieremo da dove iniziare, da un audit fino a un sistema completo dal design al codice.

Parliamo del tuo progettoPianifica il tuo design system