Ricavare i componenti necessari da due viste del prodotto

Un sistema di design diventa più facile da usare quando il suo ambito iniziale deriva da attività reali dell’interfaccia. Parta quindi dalle viste di cui il prodotto ha davvero bisogno. Un lungo elenco di componenti possibili dice ancora poco sulle varianti che il gruppo dovrebbe utilizzare.

Rilevare due viste e le rispettive attività

Per l’esempio usiamo un portale clienti fittizio. Nella panoramica dei progetti, i clienti devono riconoscere e aprire un progetto. Nella vista di dettaglio devono leggerne lo stato e scaricare documenti approvati. Le due viste appartengono allo stesso prodotto, ma servono attività diverse.

Per ogni elemento visibile annoti scopo, contenuto e possibili stati. Una cornice simile non basta a giustificare un componente condiviso. Conta anche la corrispondenza di significato e comportamento.

Decidere la base comune e le composizioni separate

La scheda del progetto e la riga del file possono condividere piccoli elementi di base. Non devono per questo diventare lo stesso grande componente. Un’eccezione è sensata se una variante comune rende inutilmente meno chiara l’attività in questione.

Compilare concretamente una voce della libreria

Per l’indicatore di stato, l’esempio registra: uso nelle due viste del progetto; testo di stato ricavato dai dati del progetto; colore solo come rappresentazione aggiuntiva; nessuna azione di clic propria. Restano da chiarire i valori di stato necessari e la gestione delle traduzioni lunghe. Queste decisioni vanno risolte prima dell’implementazione, invece di essere nascoste da valori di esempio arbitrari.

Carbon descrive i componenti come soluzioni progettate e programmate per attività concrete dell’interfaccia. Applichi questa prospettiva anche alla scelta: documenti insieme scopo, varianti e limiti di un componente. Un nome presente nella libreria non basta come regola d’uso.

Verificare l’ambito iniziale nelle due viste

Inserisca prima i componenti scelti nei due progetti grafici. Controlli contenuti tipici e traduzioni lunghe; per gli elementi interattivi verifichi anche uso della tastiera e cambiamenti di stato. Annoti la versione utilizzata e le differenze mantenute deliberatamente. L’esempio offre un documento di lavoro, non una libreria già implementata. Il passo successivo è una selezione gestibile con i punti aperti chiariti, che il gruppo potrà poi implementare e verificare.

Fonti

• Carbon: Components Overview