Come disegnare UI responsive a basso budget

Da dove partire per progettare una UI responsive “minima” per un software quando non c’è tempo o non c’è budget? A cosa dare priorità per ottenere un frontend professionale, senza investire risorse eccessive? Vediamo insieme qualche suggerimento per progettare l’essenziale.

In merito al responsive design si possono leggere moltissime opinioni e gli articoli e i video a riguardo sono innumerevoli. Molte sono best practices teoriche, a volte incompatibili con i vincoli reali di un progetto. Mi riferisco in particolare alle esigenze di molte aziende che offrono servizi di sviluppo software e che spesso gestiscono progetti a budget limitato.

Nella quasi totalità dei casi della mia esperienza personale (limitata sì, ma reale e che ho toccato con mano), questo significa una cosa: prima di tutto, si taglia il design. Il motivo è presto detto: l’azienda cliente spesso è soddisfatta quando il software è presentabile e in produzione. Nelle complesse (e spesso disorganizzate) dinamiche aziendali del cliente non c’è posto per un progetto Figma, perfetto in ogni sfumatura della UX/UI, ma non funzionante.

Tagliare il design non implica necessariamente fare un lavoro esteticamente “brutto” (concedetemi la semplificazione, credo che i designer capiscano cosa intendo), o assemblato senza criterio. In Dreamonkey, questa occorrenza corrisponde approssimativamente alla necessità di tenere il designer sul progetto il minor tempo possibile.

Meno tempo può significare fare le stesse cose, ma di fretta, oppure curare solamente le parti imprescindibili e lasciare le finezze per contratti evolutivi futuri (sperando che interessi al cliente!). Quasi sempre questi tagli includono il design delle diverse viewport per documentare la UI responsive. Vediamo dunque come gestire questo aspetto tirandone fuori il meglio possibile.

Mobile o Desktop, questo è il dilemma

Fin da subito adottiamo un approccio molto pragmatico. Quando inizia un nuovo progetto, la prima discriminante – banale, se volete – è definire quale sia la destinazione davvero indispensabile per partire. Mobile o Desktop? La risposta è semplice: se è possibile, entrambe. Se il budget non lo consente, bisogna per forza fare un’eliminatoria e integrare la parte mancante in futuro, se e quando nuove risorse verranno destinate al progetto.

Molto spesso è facile capire a cosa rinunciare. Soprattutto nel caso di software a uso interno aziendale o per target di utenti particolari. Molti software pensati per mansioni lavorative da ufficio sono utili quasi esclusivamente da desktop. Altre app prevedono una fruizione intersecata con altre attività e, per loro natura, risultano utili – se non imprescindibili – solo da mobile. Naturalmente ogni caso ha le sue peculiarità, ma in uno scenario restrittivo, di solito cliente e fornitore sono in grado di scegliere in modo intuitivo.

Non si tratta di quello che sarebbe meglio fare, ma di quello che effettivamente si può fare per quel progetto in quello specifico frangente. Che sia desktop, mobile, o un mix delle due, si deve comunque affrontare anche un altro tema: per quali viewports realizzare i mockup statici della UI?

Pianificare le viewports in modo pragmatico

Esistono centinaia di devices diversi e altrettante viewports. Per il designer della software house media, strutturare un progetto che le prenda in considerazione tutte, progettando mockup statici e specifiche ben documentate per l’handoff al team di sviluppo è pura utopia. A meno che non si tratti di un designer impiegato a tempo pieno in una startup o in un’azienda in cui si deve occupare di un singolo prodotto software. Quando nella software house media inizia un nuovo progetto – specialmente a basso budget – tutto questo è impensabile.

Come spesso accade, nella software house media, il designer lavora da solo, circondato da sviluppatori. Si occupa di varie cose (UI, graphic design, copywriting…), gestisce più progetti e si destreggia per mantenere la consistency di ogni software che gli passa per le mani. Tutto questo tra cambi di direzione, interruzioni e limitazioni tecniche dettate dal codice, in una ruota di eterno multitasking.

Quindi è proprio vero che il design dovrebbe considerarle tutte in dettaglio? In un mondo perfetto sì, ma siamo onesti, quando succede davvero? Lasciamoci alle spalle questa retorica e parliamoci chiaro.

Quali viewports scegliere per progettare la UI

Dati i limiti di tempo e budget che caratterizzano molti progetti, al più, il designer può ambire a un buon compromesso tra responsiveness e manutenibilità scegliendo un gruppo base di viewports sulle quali concentrarsi. Questa scelta si basa su meri criteri logici e, salvo rare eccezioni, è applicabile a tantissimi progetti senza troppi problemi.

Quando un progetto Figma include una viewport desktop e una mobile è già un buon risultato. Quando si aggiunge una viewport per tablet è ancora meglio. Da qui in poi, aumentare il numero di viewports renderà i vostri developers più felici, ma si tratta di uno scenario per progetti con budget importanti e sostenuti nel lungo periodo da una solida vision strategica del cliente (in altre parole: pronto a investire).

Coprire devices come smartwatches e schermi ultra wide (più di 1920 pixel) in molti casi è considerabile un nice to have. Specialmente i primi, sono una necessità rara nel ramo del B2B.

UI per viewports wide screen

Quanto agli schermi più grandi, in molti settori lavorativi si vedono solo occasionalmente, per via del loro costo (le esigenze dell’impiegato medio raramente giustificano l’investimento). L’estensione della UI responsive anche agli schermi ultra wide implica anche alcuni possibili problemi.

Alcune immagini, come header o altre superfici fotografiche progettate per estendersi, potrebbero sgranare a causa della dimensione eccessiva, a meno che non si preveda l’uso di immagini estremamente grandi. Le immagini molto grandi tuttavia non sono sempre disponibili. Inoltre, pesano di più, e il loro uso comporta una serie di ottimizzazioni per evitare che impattino negativamente sulle performance delle viewport più piccole, dove il loro uso è dannoso per i tempi di caricamento.

Un altro problema riguarda il rapporto tra superficie e dimensione degli elementi della UI. Viewport troppo ampie contenenti UI troppo piccole possono diventare fastidiose da consultare. Infatti l’utente potrebbe essere costretto a cercare le informazioni su una superficie troppo ampia (qualcuno ha detto come burro spalmato su troppo pane, per caso?), impattando sulla sua attenzione.

Al contrario, una UI responsive progettata per scalare in ogni sua componente, su quella dimensione, potrebbe comunque risultare fastidiosamente grande, ingombrante e tediosa da scrollare.

È sottinteso che i criteri per giudicare i confini di questi problemi meriterebbero più spazio, ma può essere materia per un altro articolo. In questo frangente limitiamoci a fornire una linea guida rapida per definire il perimetro dell’operatività.

Per le ragioni elencate, come soluzione alternativa rapida e priva di controindicazioni catastrofiche, è preferibile limitare la UI del software a una viewport massima di 1920 pixel, impostando dei semplici margini a destra e sinistra per le viewport più grandi. Questi riempiranno (es. di bianco) lo spazio in eccesso. Il limite a 1920 è giustificato dal fatto che spesso, nello spettro di viewports che eccedono il tablet, le persone adottano un laptop dallo schermo più piccolo e nel caso di desktop è raro vedere negli uffici schermi più grandi.

UI mobile per smartphone

Per quanto riguarda le viewports per smartphone la scelta è molto ampia (basta guardare i preset delle artboards di Figma o le opzioni per la viewport degli strumenti per sviluppatori di Chrome). Per progetti a budget limitato devi sceglierne una. Anche più di una, in realtà, ma dipende da quanto sei rapido a disegnare su Figma (o con altri software) e cosa è stato venduto al cliente. Nella mia esperienza, quasi sempre una viewport è sufficiente per un progetto più che dignitoso.

Un’opzione è partire dalla viewport standard più piccola, comunemente considerata quella dell’iPhone 5 e dell’iPhone SE (Special Edition), ovvero 320x568 pixel. È una viewport estremamente piccola che impone molti vincoli spaziali, ma ti darà la sicurezza di rendere fruibili i contenuti anche sui dispositivi più datati.

Uno dei contro di questa scelta è che, durante la revisione dei mockup (su Figma, su Zeplin, etc.), il cliente potrebbe voler vedere una viewport più grande, dal feeling “moderno”. Diciamolo, la dimensione di iPhone 5 è meno “effetto wow” di altri smartphone, ma come progettisti dovremmo dare la precedenza alla funzionalità. Se il budget ci limita, questa dovrebbe essere la prima scelta razionale, a prescindere dai desideri estetici del cliente.

Se sei fortunato e la situazione te lo permette, integra altri mockup con viewports mobile più grandi, magari optando per una larghezza dai 400 pixel o più. In questo caso non ho particolari suggerimenti su quale scegliere. Assicurati solo di trovare una giusta via di mezzo tra la viewport più piccola e la viewport che, a livello teorico, adotteresti per la più piccola UI dei tablet.

UI per tablet

Per quanto possano variare di dimensione, le viewports di tablet diversi non saranno mai estremamente distanti le une dalle altre. Dovendone scegliere una soltanto, bisogna battezzare lo sweet spot tra smartphone e desktop che fa al caso nostro.

Ci sono tablet che per misure sono praticamente assimilabili a laptop (Surface Pro 8, 1440x960 pixel) o a smartphone (iPad Mini 8.3, 744x1133 pixel). È vero che alcune interazioni potrebbero richiedere ulteriore attenzione ma, in caso di vincoli stringenti, probabilmente non è a queste viewports che devi prestare attenzione.

Per esempio, una buona viewport potrebbe essere la via di mezzo, come quella di iPad Pro (834x1194 o 1024x1366). Ponendoti a metà strada tra smartphone e desktop, e lavorando con gli sviluppatori per definire alcuni ridimensionamenti fluidi della tua UI, riuscirai a mitigare i problemi sulle viewports intermedie.

Il più delle volte, quando si è alle strette, anche la modalità landscape può essere considerata un nice to have. Sia per tablet che per smartphone.

Conclusioni sulle viewports “on a budget”

Definire su quale fascia di budget considerare questo approccio o offrire di più al cliente dipende dalle risorse e dal metodo dell’azienda che si fa carico del progetto. Sta all’esperienza di ciascuno capire quando è opportuno passare alla modalità on a budget.

Ovviamente questi accorgimenti non salveranno tutti i tuoi utenti da occasionali situazioni di UI sottoperformante ma ti aiuteranno a gestire i casi limite, che è già un buon punto di partenza. Ti guideranno nel definire in che dimensione realizzare i tuoi mockup statici per l’handoff agli sviluppatori su Figma o Zeplin.

Probabilmente servirà qualche seduta di confronto con gli sviluppatori per limare le sbavature di UI più evidenti, ma questo fa sempre parte del gioco. Invece, per tutti i progetti coperti da investimenti più corposi e continuativi si aprono molte possibilità più dettagliate, ma questa è un’altra storia!

Se sei uno sviluppatore o lavori in un’azienda dove urge un intervento di miglioramento della responsiveness, contattaci, saremo felici di aiutarvi a migliorare il design del vostro software.