Ci sono un gran numero di articoli che insegnano come i designer possono dire di no . Si tratta principalmente di liberi professionisti e di come interagire con clienti difficili. Ci sono anche articoli con suggerimenti per trattare con i Product Manager. Tuttavia, che dire di quando supporti un sistema di progettazione? Cosa fare in caso di richieste contrastanti di altri designer o sviluppatori.

Non so ancora cosa sto facendo...

Se non sei un esperto e stai appena iniziando a creare da zero un sistema di progettazione per la tua azienda, potresti non sapere che direzione prendere. Ovviamente puoi leggere diversi articoli con ricette su " come iniziare ", ma a volte non c'è niente di meglio dell'esperienza personale. Provare qualcosa, commettere errori a volte e imparare dagli errori. Essere aperti a cose nuove. Sii una persona "Sì, proviamo".

Devi essere il più flessibile possibile in una situazione del genere. Tuttavia, documenta le tue decisioni se non vuoi che le decisioni riuscite rimangano "magia nera" e quelle fallimentari restino una coincidenza sconosciuta.

Non intendo solo scrivere la decisione stessa, ma come tu (o altri) ci arrivate. Argomenti, ecc. Sì, questo può essere, a volte, difficile. Soprattutto quando la decisione è stata intuitiva (sensazione viscerale). Tuttavia, se impari a mettere in discussione te stesso e gli altri, alla fine puoi iniziare a capire la fonte dell'idea.

Tale documentazione ti consentirà di comprendere ulteriormente le relazioni di causa ed effetto e di apprendere cosa funziona e cosa no. E la prossima volta se vedi che una nuova proposta si adatta a uno schema noto (o va nella stessa direzione), sarai in grado di farlo notare agli altri. Cioè, imparerai a dare ragioni ragionate contro soluzioni rischiose.

L'ho già visto da qualche parte...

Puoi sempre chiedere esempi alla comunità quando si tratta di decisioni sbagliate . Ai designer (e a molte altre professioni) piace fare elenchi di cosa non fare .

C'è un'ampia sezione trasversale di articoli nella categoria " 10 peggiori decisioni di progettazione " e simili. Tuttavia, per quanto riguarda i sistemi di progettazione, le più importanti saranno le descrizioni delle pratiche "buone/cattive", "schemi", "da fare e da non fare", ecc. Ed è meglio cercarle nella documentazione dei sistemi di progettazione aperti.

Spesso tali documenti forniscono argomenti concisi ma concisi a favore o contro una particolare soluzione e possono essere di grande aiuto nell'analisi delle situazioni che si verificano nel sistema. E anche nel tuo lavoro di progettazione quotidiano.

Le cose da fare e da non fare sono un elemento chiave di qualsiasi documentazione di progettazione di un sistema e prima inizi a documentare le pratiche "buone/cattive" per il tuo sistema, più domande e fraintendimenti sarai in grado di evitare.

“ Se non è documentato, non esiste ”

La documentazione è un impegno. Ma anche indicazioni su “cosa potrei/dovrei fare”. Dopotutto, spesso i progettisti prendono decisioni discutibili perché non sono consapevoli di ciò che dovrebbe e non dovrebbe essere fatto all'interno del sistema di progettazione. In sua assenza, l'affermazione "tutto è possibile" è un pensiero ragionevole.

Ma qui è importante sottolineare: la documentazione non riguarda i divieti. La documentazione è progettata per spiegare come funziona il sistema e indicare ragionevolmente cosa vale la pena fare e cosa no. Di conseguenza, se il progettista (o lo sviluppatore) è guidato solo da "Mi piace così" e contraddice la documentazione, hai un motivo ragionevole e giustificabile per rifiutare, facendo riferimento alla documentazione.

La documentazione aiuta a dare il buon esempio agli altri per argomentare le proprie idee. E trasforma le idee in soluzioni che ti aiuteranno a portare il tuo sistema di progettazione a un livello superiore.

Libreria del progetto ≠ Sistema del progetto

Spesso sorgono problemi quando gli utenti (o collaboratori) non capiscono cosa sia un sistema di progettazione e lo considerano una libreria di progettazione. Molti progettisti sono abituati a gestire librerie di progettazione standard e devono modificarle per adattarle alle proprie esigenze.

“Mi piace questo UI-Kit, ma è stato creato senza alcuna considerazione per i miei casi d'uso e quindi ho bisogno di personalizzarlo”. Sembra abbastanza ragionevole, vero? Sì, se parliamo di soluzioni di terze parti di cui tu (o qualcun altro) utilizzerai solo una piccola parte. Ma nel caso di un sistema di progettazione interno, ciò potrebbe portare al caos.

Qualcosa di simile a questo, ma un po' diverso...

Secondo me, la cosa più difficile è quando gli utenti richiedono piccole modifiche. Piccoli cambiamenti:

• Aggiunta la possibilità di utilizzare le icone nelle intestazioni.
• Modificare l'ordine dei blocchi nell'elenco.
• Mostra 3 pulsanti invece di 2 (definiti da un componente).

• Coerenza dell'approccio con altri componenti.
• La complessità dell'implementazione nel codice e nei componenti di progettazione (Figma, Sketch, ecc.).

Innanzitutto, devi capire se il modello si interseca con qualche altro componente. Per fare ciò, è necessario conoscere a memoria tutti i componenti e il loro comportamento o esaminare ciascuno di essi e vedere se la proposta è in conflitto con qualcuno degli altri componenti. Se ci sono i minimi conflitti, è necessario discutere la proposta non isolatamente, ma nel contesto del comportamento di più componenti. Questo può spesso richiedere di invitare più persone nella discussione.

La complessità dell'implementazione

Molto spesso, quella che sembra una soluzione semplice nel design può richiedere uno sforzo enorme nello sviluppo. Forse perché l'architettura attuale non è abbastanza flessibile. Forse va solo contro gli standard / gli approcci di base utilizzati nello sviluppo. Teoricamente, quasi tutto è possibile, ma alcune cose richiederanno uno sforzo maggiore. In una situazione del genere, potrebbe essere necessario capire quanto siano importanti questi cambiamenti: "Nice to have" o "critical needs".

Siamo servi, non dittatori

Il sistema di progettazione è un prodotto . Ma è molto specifico. Mentre il successo della maggior parte dei prodotti può essere misurato da quanti soldi guadagnano, per un sistema di progettazione l'indicatore principale è quanti utenti lo usano e quanto semplifica la loro vita. In altre parole, un sistema di progettazione è "Il prodotto più onesto" . E questo comporta molte responsabilità. Non dobbiamo solo trarre il meglio da ciò che i clienti desiderano, ma anche aiutarli a comprendere le conseguenze di ogni decisione discutibile:

• una mancanza di flessibilità nella prospettiva
• ritardi nello sviluppo della soluzione (a causa della complessità della soluzione e della sua manutenzione)
• la necessità di modifiche a cascata ad altri componenti o accordi
Stewarding Design System Contributi

In definitiva, il sistema di progettazione riguarda gli utenti (designer e sviluppatori). Quindi devi essere molto attento a loro. Dopotutto, senza di loro non siamo nessuno. E se le modifiche sono ragionevoli e non interrompono nulla, perché non farle?

Tutti i motivi per dire "no" riguardano solo la garanzia di creare il prodotto di cui gli utenti hanno bisogno, non quello che vogliono.

Alla domanda sull'input dei clienti nello sviluppo della Ford Model T, Henry Ford disse notoriamente: "Se avessi chiesto alle persone cosa volevano, avrebbero detto cavalli più veloci".

Grazie per aver letto! Restiamo in contatto! Connettiti con me su LinkedIn e seguimi su Dribbble e qui su Medium per ulteriori contenuti relativi al design.