Contenuto
- 01. L'ho progettato in questo modo per un motivo
- 02. MVP!?!? È tutto MVP!
- 03. Questo richiederà quanto tempo?!?!?
- 04. Cosa intendi con "Non posso farlo!"?
- 05. Il test di usabilità NON è facoltativo
- 06. Mi dicono di nuovo come progettare!
- Qualunque altra cosa?
Sappiamo che gli sviluppatori possono sentirsi frustrati dai designer, soprattutto quando il designer progetta qualcosa che è impossibile da costruire. Ma c'è molto di cui i designer si sentono frustrati con gli sviluppatori.
Il design è spesso visto come una "soft skill" che riguarda un'opinione sull'estetica, non regole rigide, tanto meno la logica rigorosa del codice. Eppure i designer lavorano per anni per perfezionare un mestiere, non solo per lanciare idee disinformate. Tuttavia, essere in grado di spiegare e articolare il "metodo dietro la follia del design" non è sempre facile, e raramente veloce, il che porta a numerose frustrazioni del progetto. Fortunatamente, di solito c'è un modo per allentare la tensione.
01. L'ho progettato in questo modo per un motivo
Il problema: Il designer trascorre settimane a creare composizioni visive e documenti delle specifiche meticolosamente realizzati, solo per vederli apparentemente ignorati dallo sviluppatore. Oltre a ignorare le specifiche, alcuni sviluppatori consentono semplicemente che le impostazioni predefinite del browser rimangano invariate se non sono esplicitamente stabilite nella documentazione, non solo mostrate nelle composizioni visive.
Il designer presume che lo sviluppatore esaminerà attentamente le composizioni e cercherà di farle corrispondere a "pixel perfetti". Tuttavia, questo generalmente porta a interfacce che si sentono anguste o mal organizzate, nonostante i migliori sforzi dei progettisti.
La soluzione: I progettisti non dovrebbero dare per scontato nulla e sapere che la documentazione non è mai sufficiente. Una buona guida alla progettazione è il primo passo verso l'eliminazione di questo problema, ma i progettisti devono anche lavorare fianco a fianco con gli sviluppatori, rivedendo regolarmente il loro lavoro per assicurarsi che sia ciò che è inteso in una revisione di accettazione del progetto quando lo sviluppatore si sente a proprio agio con ciò loro hanno fatto.
02. MVP!?!? È tutto MVP!
Il problema: Lo sviluppatore ha un tempo limitato per creare il prodotto finale, anche meno per ogni sprint, quindi darà la priorità a caratteristiche e funzionalità in base al "prodotto minimo praticabile" che soddisferà le specifiche del prodotto. La maggior parte dei progettisti, tuttavia, vede il prodotto come un insieme integrato, non una serie di componenti ad incastro. Ma l'MVP spesso non viene definito fino alla fase di sviluppo, quindi può sembrare che gli sviluppatori stiano prendendo le decisioni in base alle loro esigenze di pianificazione piuttosto che alle esigenze degli utenti e dei prodotti.
La soluzione: L'MVP deve essere definito durante le fasi iniziali del prodotto, ed essere veramente il prodotto minimo praticabile, non solo il più facile da realizzare, per le diverse fasi di sviluppo / sprint. I designer possono lavorare per creare un prodotto che viene costruito in più fasi, piuttosto che completato tutto in una volta. Ciò dovrebbe anche rendere più facile per gli sviluppatori pianificare di conseguenza.
03. Questo richiederà quanto tempo?!?!?
Il problema: Il progettista ha trascorso mesi a pianificare, ricercare e creare progetti per soddisfare le esigenze degli utenti, solo per sentirsi dire che ci vorrà molto più tempo del previsto a causa di programmi di progetto contrastanti, carenza di personale e il temuto creep dell'ambito.
La soluzione: Uno dei fatti di qualsiasi progetto di sviluppo dell'interfaccia utente è che lo sviluppo arriva per ultimo ed è generalmente ridotto nel tempo dai passaggi precedenti (non ho mai saputo che le fasi di scoperta, definizione o progettazione andassero più velocemente del previsto per dare più tempo allo sviluppo) .
Un modo per aggirare questo è attraverso Agile abbinato a Lean UX per consentire lo sviluppo in parallelo con il design, consentendo agli sviluppatori di iniziare prima che il design sia completamente bloccato. Questo approccio non è privo di rischi (potrebbe essere necessario riconsiderare il design) ma generalmente porta a risultati più rapidi e project manager più felici. E davvero, non è quello che vogliamo tutti?
04. Cosa intendi con "Non posso farlo!"?
Il problema: Il designer ha creato un'esperienza davvero interessante, ma lo sviluppatore la dà un'occhiata e proclama: "Non funzionerà mai". Uno dei motivi per cui gli sviluppatori potrebbero non essere in grado di fare qualcosa è perché non può essere fatto, ma il più delle volte è uno di altri due motivi: 1) ci vorrebbe troppo tempo, più a lungo del progetto, o 2) lo sviluppatore semplicemente non lo fa non so come farlo.
La soluzione: Se non può essere fatto, non può essere fatto e il progettista deve ripensare alla soluzione. Se ci vorrà troppo tempo, il team deve decidere se ridimensionare o prendersi il tempo necessario. Ma, se lo sviluppatore semplicemente non sa come farlo funzionare, il designer dovrà mostrare loro esempi di luoghi in cui funziona la tecnica desiderata. Trovo che CodePen.io sia il mio posto migliore quando ho bisogno di mostrare "opere d'arte esistenti" ai miei sviluppatori.
05. Il test di usabilità NON è facoltativo
Il problema: Per molti sviluppatori "usabilità" significa che funziona come definito dai requisiti. Se i progettisti vogliono testare qualcosa, dovrebbero farlo prima che lo sviluppatore trascorra lunghe ore a costruire l'interfaccia utente secondo le specifiche. Tuttavia, solo così tanti test di usabilità possono essere eseguiti con prototipi cartacei e cliccabili. Spesso, il test di usabilità più efficace viene eseguito durante lo sviluppo.
La soluzione: Pianifica i picchi di test di usabilità in qualsiasi progetto Agile con iterazioni che forniscono feedback nello sviluppo del prodotto.
06. Mi dicono di nuovo come progettare!
Il problema: Uno sviluppatore legge un articolo sull'usabilità di Jakob Nielsen e improvvisamente diventa un esperto di usabilità e design. I designer passano anni a sviluppare le proprie capacità, conoscenze e attitudini. Un problema è che, poiché tutti hanno un '"opinione" sul design (informati o meno) in alcuni progetti - specialmente dove potrebbe esserci un team UX di uno - la loro voce è spesso soffocata.
La soluzione: Questo non è un problema facile da risolvere, poiché ha più a che fare con le dinamiche interpersonali e di gruppo che con la logica e la ragione reali. Il modo migliore che ho trovato per affrontare queste situazioni è semplicemente ascoltare senza mettermi sulla difensiva. Lascia che dicano la loro e considera ciò che dicono.
Quello che hanno da dire ha un merito? Faglielo sapere e poi spiega perché hai scelto di seguire il percorso che hai fatto, riconoscendo anche che sei in disaccordo con le "migliori pratiche" esistenti come prescritto altrove. Spesso gli sviluppatori vogliono semplicemente sentire come se il designer li stesse semplicemente ascoltando.
Qualunque altra cosa?
Ho delineato le sei frustrazioni che vedo comunemente i designer avere con gli sviluppatori e in precedenza ho descritto le sei frustrazioni che gli sviluppatori hanno con i designer. Cosa ne pensi e puoi aggiungere alla lista? Si prega di suggerire soluzioni nei commenti qui sotto affinché tutti noi possiamo trarre vantaggio dalla vostra esperienza.
Parole: Jason Cranford Teague
Jason Cranford Teague è Senior Creative Director presso Capital One e insegna workshop su experience design per sviluppatori, sviluppo per design e pensiero progettuale temporale.
Come questo? Leggi questo...
- 5 cose che il tuo portfolio deve avere
- Come avviare un blog
- Scarica i migliori font gratuiti
