Come evitare le cattive pratiche nella progettazione di iOS e Android

Quante persone in media hai visto utilizzare contemporaneamente dispositivi iOS e Android? I numeri ufficiali secondo questo studio oscillano tra il 10% e il 20%, ma la cifra include anche gli utenti Mac, non solo gli utenti mobili. In pratica, le persone tendono a utilizzare un solo telefono o tablet in un determinato periodo di tempo. Se capita di utilizzare due dispositivi, il più delle volte, entrambi eseguiranno lo stesso sistema operativo.

Ciò significa che non è necessario creare copie pixel-perfette del design dell'interfaccia utente di un'app, cercando di adattarsi a entrambe le piattaforme, complete di decine di dimensioni dello schermo, proporzioni e risoluzioni diverse (non alziamo nemmeno le tacche, le barre di stato , barre di navigazione, pulsanti hardware, ecc.).

Al contrario, anche se un utente sta guardando la stessa app sia su iOS che su Android, è probabile che preferisca provare la sensazione nativa su entrambi. Questo è il motivo per cui l'approccio adottato da molti project manager e product owner nello sviluppo mobile è spesso non ottimale e deve essere messo a punto.

Perché questo è ancora un problema?

Ma perché le parti interessate e i manager continuano a prendere decisioni che spesso degradano l'esperienza dell'utente, minando così i propri prodotti? Era comprensibile all'inizio del decennio quando tutti stavano ancora facendo i conti con lo sviluppo di iOS e Android, eppure questo fastidioso problema persiste ancora oggi.

Il motivo principale di questa situazione in arrivo potrebbe essere la preoccupazione espressa dai project manager e dagli sviluppatori di dispositivi mobili che i loro utenti potrebbero confondersi se vedono la stessa app su un'altra piattaforma e si rendono conto che non fornisce esattamente la stessa sensazione e interfaccia utente. È giusto dire che in una certa misura questa linea di pensiero ha senso, poiché un certo grado di somiglianza è necessario e benvenuto. Tuttavia, spingersi troppo oltre e, in casi estremi, creare cloni esatti di app per piattaforme diverse tende in realtà a fare molto più male che bene.

L'obiettivo finale dovrebbe essere quello di trovare il giusto equilibrio: non forzare la coerenza pixel-perfetta, ma attenersi a idee di progettazione comuni e mantenere la mappa di navigazione dell'app simile per entrambe le piattaforme; fornire le stesse funzionalità e lo stesso flusso di lavoro, ma cercare di attenersi al comportamento nativo ove possibile.

Tutti amano un pulsante personalizzato o un'animazione di fantasia qua e là, ma gli elementi nativi sono ciò a cui le persone sono abituate e trovano più facile e intuitivo da usare.

Concentrati sugli utenti, non sull'aspetto

Per trovare un buon approccio per affrontare questo dilemma, dovremmo iniziare dalla fine della linea: l'utente finale. La ricerca ci dice che gli utenti Android e iPhone sono persone molto diverse e se puntiamo a un'esperienza utente ottimale, dovremmo cercare di entrare nei loro modelli di utilizzo.

Partendo dal budget medio che le persone decidono di spendere in tecnologia al mese ( iPhone: $ 100,88, Android: $ 50,83 ) , passando per il numero di selfie che fanno al giorno iPhone: 12, Android: 7 e arrivando ai messaggi che inviano ogni giorno iPhone : 57, Android: 26 , è facile notare che le differenze sono sostanziali, al punto che possiamo concludere che esiste una divergenza nel comportamento, che guida il modo in cui le persone utilizzano i propri dispositivi.

Quindi, su cosa dovremmo concentrarci quando progettiamo applicazioni per entrambe le piattaforme contemporaneamente?

Prima di tutto, scegli gli elementi nativi, ove possibile. Anche se si utilizza un framework multipiattaforma, la maggior parte dei componenti si basa su viste native pure; quindi, a meno che tu non abbia davvero bisogno di qualcosa di personalizzato, attieniti alle basi. Alle persone piace usare ciò a cui sono abituate e risparmierai un po' di tempo di sviluppo per funzionalità più importanti (e revisioni del codice!).

Le visualizzazioni personalizzate possono sicuramente conferire carattere e unicità alla tua app, purché mantengano le stesse idee generali e la stessa sensazione di utilizzo di quelle generiche: troppo poco e la tua app è noiosa, troppo ed è inutilmente appariscente e difficile da usare.

A volte, anche un piccolo tocco con una visualizzazione personalizzata leggermente diversa può essere un punto di svolta per la tua app, ma se riempi tutte le schermate con nuovi elementi che gli utenti possono esplorare, potrebbero essere sopraffatti e perdersi durante la ricerca di informazioni importanti. Non a caso questi piccoli tocchi si chiamano “polacchi!”

Come avvicinarsi a diversi componenti di progettazione

Come regola generale, ricorda sempre che ogni piattaforma ha le sue linee guida di progettazione. La serie di approcci di Android sta calpestando il Material Design, mentre Apple si fida di Human Interface Design. Entrando nei componenti specifici che dovremmo considerare quando pianifichiamo il nostro design, ci sono diverse parti principali su cui concentrarsi:

1. Stile generale: a meno che non si tratti di un'applicazione multipiattaforma, dovremmo considerare di seguire le linee guida di stile generali per ciascuna piattaforma. Nel complesso, i design di iOS tendono ad essere più piatti, mentre Android adotta un approccio più stratificato.

   Storicamente, le piattaforme mobili si influenzano a vicenda da un decennio o più e puoi facilmente individuare alcuni concetti Android in iOS e viceversa. Ad esempio, quando i sensori di impronte digitali hanno iniziato ad apparire nel mondo mobile, i produttori stavano ( e stanno ancora ) sperimentando le dimensioni e la posizione del sensore, cercando di renderlo confortevole per il maggior numero possibile di utenti. Allo stesso tempo, anche designer e sviluppatori si stavano adattando alla nuova funzionalità, quindi alla fine, gli elementi visivi e il feedback sono per lo più identici su entrambe le piattaforme (salvo alcuni approcci esotici).

2. Specifiche hardware e modelli di navigazione: questo è probabilmente uno degli esempi più sorprendenti degli aspetti negativi della clonazione a titolo definitivo dell'app. La maggior parte dei dispositivi Android ha ancora la comodità di una barra di navigazione aggiuntiva (hardware o software su dispositivi diversi), incluso un pulsante Indietro. Poiché iOS non lo fornisce, le applicazioni devono considerare dove e quando fornire il pulsante Indietro, di solito nell'angolo in alto a sinistra di ogni schermata.

   Il pulsante del menu (il pulsante quadrato in questo esempio) può anche fornire funzionalità aggiuntive per le app Android. Dove è rilevante? Ad esempio, quando si apre il menu delle impostazioni o una funzione di navigazione simile.

   

   Fino a poco tempo, gli iPhone presentavano anche il tradizionale pulsante Home di Apple, ma dall'introduzione di iPhone X, è stato messo da parte e il flusso in iOS è ora basato sui gesti. Se lo scorrimento è una parte importante della tua app, assicurati di fornire una protezione sufficiente tra il bordo del contenitore dell'app e l'area di scorrimento consentita per evitare complicate coincidenze di scorrimento.

   Nel caso in cui la tua app si basi su funzionalità specifiche dell'hardware come Bluetooth, NFC o cuffie cablate, dovresti sempre considerare la gamma di diverse specifiche hardware che stai supportando. Cerca di fornire un feedback adeguato all'utente quando tenta di interagire con una funzione specifica. Se per qualche motivo devi fornire una funzionalità specifica per l'hardware solo per una delle due piattaforme, assicurati di informare i tuoi utenti della differenza.

3. Elementi globali (barre di stato, intestazioni, ecc.): i componenti che appaiono su tutte le pagine del tuo progetto, come la barra di stato, l'intestazione di navigazione e così via, dovrebbero mirare rigorosamente a fornire una sensazione nativa, quindi non dovremmo cambiare l'altezza e lo stile di quelle barre. Ci sono piccole differenze nello stile degli elementi globali su entrambe le piattaforme. Ad esempio, Android utilizza il testo allineato a sinistra mentre iOS sceglie un titolo centrato. La barra di stato è un componente nativo, quindi non devi preoccuparti di questo, ma tieni a mente diverse tacche e proporzioni dello schermo quando pianifichi la sezione superiore della tua app.

   

   

4. Navigazione: le buone vecchie linee guida di progettazione dei materiali di Google suggeriscono di utilizzare la navigazione del menu a scomparsa nelle applicazioni Android, con la navigazione in basso in arrivo, ma comunque un'opzione praticabile. iOS tende a utilizzare esclusivamente una barra delle schede, che può limitare le opzioni di navigazione di primo livello ma fornisce una visione chiara di tutte contemporaneamente. In questo caso, entrambi i sistemi operativi forniscono componenti simili che possono essere utilizzati a seconda della complessità della tua app, ma la differenza visiva nei due sistemi dovrebbe naturalmente indirizzarti, ad esempio la barra di navigazione globale in Android e la sua mancanza in iOS.

   La rapida evoluzione dell'hardware mobile negli ultimi anni ha introdotto molte variabili e incognite: telefoni a schermo intero, notch di diverse forme e dimensioni, maggiore utilizzo dei gesti per la navigazione a livello di dispositivo e così via. Tutte queste modifiche forniscono una potenza senza precedenti all'utente, ma possono essere una seccatura quando cerchiamo di capire tutti i casi d'uso di un determinato schermo nella nostra app. Date queste preoccupazioni, un buon approccio per evitare confusione per i nostri utenti sarebbe mantenere i modelli di navigazione semplici e coerenti, senza sovraccaricare l'app con troppi gesti, barre e opzioni di scorrimento multidirezionale.

   

5. Tipografia: entrambe le piattaforme hanno i loro caratteri tipografici predefiniti: San Francisco per iOS e Roboto per Android. A meno che tu non stia cercando un carattere personalizzato, strettamente abbinato allo stile generale dell'app, dovresti attenerti alle impostazioni predefinite. Tieni presente che gli utenti potrebbero cambiare il loro carattere di sistema predefinito e ciò non influirà sulle visualizzazioni che hai personalizzato con un carattere tipografico specifico.

   Ad esempio, gli utenti dislessici potrebbero non divertirsi nella tua app se hanno sostituito il carattere predefinito con un carattere che soddisfi specificamente le loro esigenze. Se stai supportando utenti che potrebbero utilizzare caratteri non latini (come cirillico, arabo, ecc.), assicurati che i tuoi caratteri personalizzati forniscano anche quei caratteri extra. Se ti piacciono i giochi, probabilmente hai visto quelle classifiche con punteggi alti raggiunti da giocatori russi i cui nomi si distinguono per il loro diverso carattere. Questo è solo un piccolo errore commesso durante la fase di sviluppo, non una "funzione" per giocatori specifici e, sebbene probabilmente non farà in modo che gli utenti abbandonino la tua app, può sicuramente comportare un peggioramento dell'esperienza utente o causare reclami o recensioni negative.

   

6. Altri componenti: pulsanti, transizioni dello schermo, animazioni, micro-interazioni, fogli di azione, avvisi e tutti gli altri tipi di controlli di flusso esulano dallo scopo di questo articolo, ma dovrebbero seguire il principio generale che abbiamo applicato finora ad altri elementi di progettazione: entrambe le piattaforme scoraggiano elementi personalizzati eccessivi, in quanto potrebbero distrarre e confondere l'utente; quando si tratta di design, la prima impressione è solitamente l'ultima per molti utenti ed è per questo che è così importante attirare l'attenzione degli utenti fin dall'inizio e farli sentire a casa, per così dire.

Nel mondo reale, puoi vedere alcune eccezioni molto popolari alle regole di cui abbiamo discusso: applicazioni iOS che seguono le linee guida sulla progettazione dei materiali e alcuni prodotti Android che seguono le linee guida dell'interfaccia umana di Apple, ma queste app hanno il loro stile collaudato. Gli utenti hanno familiarità con le app e il loro design e per loro ha senso fornire una sensazione leggermente più personalizzata.

Approccio multipiattaforma fatto bene

D'altra parte, se il tuo progetto è basato su una soluzione multipiattaforma (come React Native, Flutter, Xamarin e così via), dovresti considerare quale sarebbe la piattaforma principale su cui vuoi concentrarti e iniziare da lì.

Negli ultimi anni, questi nuovi framework hanno fornito enormi miglioramenti della produttività nello sviluppo di applicazioni multipiattaforma. Sempre più aziende stanno passando a questo paradigma di sviluppo, in quanto fornisce un time-to-market più breve, un rapporto costo-efficacia superiore e meno barriere tecniche, con gli svantaggi principali che sono il supporto limitato delle funzionalità e l'esperienza utente non ottimale in alcuni casi.

Mentre praticamente tutte le soluzioni precedenti per lo sviluppo multipiattaforma erano basate su visualizzazioni web e quindi presentavano seri problemi di reattività su molti dispositivi, oggigiorno possiamo utilizzare componenti nativi anche in approcci multipiattaforma. Questo importante miglioramento ha influenzato il mercato in molti modi e ha portato tutte le piattaforme mobili un passo avanti verso l'unificazione dell'esperienza visiva dell'utente su vari dispositivi e piattaforme.

Se decidi di optare per una soluzione multipiattaforma, puoi iniziare come in un'app nativa standard costruendo lo scheletro della tua app. Una volta che hai impostato e funzionante le tue priorità principali (configurazione delle dipendenze di base, creazione di un MVP, raggiungimento di traguardi specifici del progetto, rilascio della prima versione, ecc.), puoi facilmente separare i tuoi progetti principali per le due applicazioni, utilizzando la piattaforma- strumenti specifici forniti da ciascun framework. A seconda delle dimensioni della tua squadra e del lasso di tempo disponibile, potresti anche considerare di includere quelle modifiche nella versione 1, solo per evitare confusione futura quando le cose non sembrano più le stesse in una determinata versione della piattaforma.

Dopo tutto, dovresti valutare quale di questi principi sarà valido per la tua app. Come in quasi tutti gli sforzi nel nostro settore, dovresti cercare di seguire le linee guida, regolandole leggermente per adattarle alle tue esigenze specifiche. Ad esempio, se la navigazione nel cassetto è ciò che ha davvero senso per la tua semplice app a cinque schermi, non è necessario trovare soluzioni complicate per ciascuna piattaforma. Rendi ovvio e facile per l'utente riconoscere i tuoi pulsanti e strumenti personalizzati, siano essi componenti chiave o solo piccole personalizzazioni.

Un buon design rispetta le abitudini degli utenti

Per riassumere, possiamo ripetere qualcosa che già sappiamo: un buon design è il design che rispetta le abitudini degli utenti in ogni sistema operativo. Solo un po' di lucidatura alla fine potrebbe fare la differenza tra un'app media e un'ottima app.

Molte volte, la tua app non fornirà abbastanza funzionalità uniche per conquistare gli utenti solo con i contenuti. La maggior parte delle persone descriverà la propria decisione di scegliere un prodotto piuttosto che un altro con "una sensazione viscerale". Questa categoria di utenti basa le proprie scelte principalmente su come si sentono quando utilizzano l'app, valutando implicitamente la reattività, la scelta generale dello stile, la tavolozza dei colori e le singole componenti visive che vedono sullo schermo.

Pertanto, cerca di assicurarti che il tuo prodotto si distingua non solo in virtù delle sue straordinarie caratteristiche, ma anche con un imballaggio di alta qualità che corrisponda alla qualità dei servizi che fornisce.