Evitarea practicilor rele în designul iOS și Android

Câți oameni medii ați văzut folosind atât dispozitive iOS, cât și dispozitive Android în același timp ? Cifrele oficiale conform acestui studiu variază între 10% și 20%, dar cifra include și utilizatorii de Mac, nu doar utilizatorii de telefonie mobilă. În practică, oamenii tind să folosească un singur telefon sau tabletă într-o anumită perioadă de timp. Dacă se întâmplă să folosească două dispozitive, de cele mai multe ori, ambele vor rula același sistem de operare.

Ceea ce înseamnă aceasta este că nu este nevoie să faci copii perfecte pentru pixeli ale designului UI al unei aplicații, încercând să se potrivească ambelor platforme, complet cu zeci de dimensiuni diferite de ecran, raporturi de aspect și rezoluții (să nu aducem nici măcar crestături, bare de stare , bare de navigare, butoane hardware etc.).

Dimpotrivă, chiar dacă un utilizator se uită la aceeași aplicație atât pe iOS, cât și pe Android, sunt șanse că ar prefera să experimenteze sentimentul nativ pe ambele. Acesta este motivul pentru care abordarea adoptată de mulți manageri de proiect și proprietari de produse în dezvoltarea mobilă este adesea suboptimă și trebuie ajustată.

De ce este încă o problemă?

Dar de ce părțile interesate și managerii iau în continuare decizii care degradează frecvent experiența utilizatorului, subminându-și astfel propriile produse? Era de înțeles la începutul deceniului, când toată lumea încă se apropia de dezvoltarea iOS și Android, dar această problemă enervantă persistă până în prezent.

Motivul principal pentru apariția acestei situații ar putea fi îngrijorarea exprimată de managerii de proiect și dezvoltatorii de telefonie mobilă că utilizatorii lor ar putea fi confuzi dacă văd aceeași aplicație pe o altă platformă și își dau seama că nu oferă exact același sentiment și interfață de utilizare. Este corect să spunem că, într-o anumită măsură, această linie de gândire are sens, deoarece un anumit grad de similitudine este necesar și binevenit. Cu toate acestea, ducerea prea departe și, în cazuri extreme, realizarea de clone exacte de aplicații pentru diferite platforme tinde de fapt să facă mult mai mult rău decât bine.

Scopul final ar trebui să fie să găsești echilibrul potrivit - nu forțați consistența perfectă a pixelilor, ci rămâneți la idei de design comune și păstrați harta de navigare a aplicației dvs. similară pentru ambele platforme; oferiți aceleași caracteristici și același flux de lucru, dar încercați să rămâneți la comportamentul nativ ori de câte ori este posibil.

Toată lumea iubește un buton personalizat sau o animație elegantă ici și colo, dar elementele native sunt cu care oamenii sunt obișnuiți și le consideră mai ușor și mai intuitiv de utilizat.

Concentrați-vă pe utilizatori, nu pe aspect

Pentru a găsi o abordare bună pentru a aborda această dilemă, ar trebui să începem de la capătul liniei - utilizatorul final. Cercetările ne spun că utilizatorii de Android și iPhone sunt oameni foarte diferiți și, dacă țintim UX optim, ar trebui să încercăm să intrăm în tiparele lor de utilizare.

Pornind de la bugetul mediu, oamenii decid să cheltuiască pe tehnologie pe lună ( iPhone: 100,88 USD, Android: 50,83 USD ) , trecând la numărul de selfie-uri pe care le fac pe zi iPhone: 12, Android: 7 și ajungând la mesajele pe care le trimit în fiecare zi iPhone : 57, Android: 26 , este ușor de observat că diferențele sunt substanțiale, până la punctul în care putem concluziona că există o divergență în comportament, care determină modul în care oamenii își folosesc dispozitivele.

Deci, pe ce ar trebui să ne concentrăm atunci când proiectăm aplicații pentru ambele platforme în același timp?

În primul rând, alege elemente native acolo unde este posibil. Chiar dacă utilizați un cadru multiplatform, majoritatea componentelor se bazează pe vederi native pure; deci, cu excepția cazului în care aveți nevoie cu adevărat de ceva personalizat – rămâneți la elementele de bază. Oamenilor le place să folosească ceea ce sunt obișnuiți și veți economisi ceva timp de dezvoltare pentru funcții mai importante (și recenzii de cod!).

Vizualizările personalizate pot aduce cu siguranță caracter și unicitate în aplicația dvs., atâta timp cât păstrează aceleași idei generale și sentimentul de utilizare ca și cele generice - prea puțin și aplicația dvs. este plictisitoare, prea mult și este inutil de strălucitoare și greu de folosit.

Uneori, chiar și o mică atingere cu o vizualizare personalizată ușor diferită poate schimba jocul pentru aplicația dvs., dar dacă umpleți toate ecranele cu elemente noi pe care utilizatorii să le exploreze, aceștia s-ar putea să devină copleșiți și să se piardă în timp ce caută informații importante. Nu este o coincidență aceste mici atingeri se numesc „polish!”

Cum să abordați diferitele componente de proiectare

Ca regulă generală, amintiți-vă întotdeauna că fiecare platformă are propriile linii directoare de proiectare. Setul de abordări Android calcă pe Material Design, în timp ce Apple are încredere în Human Interface Design. Intrând în componentele specifice pe care ar trebui să le luăm în considerare atunci când ne planificăm designul, există câteva părți principale pe care să ne concentrăm:

1. Stil general: cu excepția cazului în care vorbim despre o aplicație multiplatformă, ar trebui să luăm în considerare respectarea regulilor generale de stil pentru fiecare platformă. În general, modelele iOS tind să fie mai plate, în timp ce Android optează pentru o abordare mai stratificată.

   Din punct de vedere istoric, platformele mobile se influențează reciproc de un deceniu sau mai mult și puteți identifica cu ușurință unele concepte Android în iOS și invers. De exemplu, atunci când senzorii de amprentă au început să apară în lumea mobilă, producătorii au experimentat ( și încă fac ) experimente cu dimensiunea și locația senzorului, încercând să-l facă confortabil pentru cât mai mulți utilizatori. În același timp, designerii și dezvoltatorii se adaptau și la noua caracteristică, așa că, în cele din urmă, elementele vizuale și feedback-ul sunt în mare parte identice pe ambele platforme (cu excepția unor abordări exotice).

2. Specificații hardware și modele de navigare: acesta este probabil unul dintre cele mai izbitoare exemple de negative ale clonării directe a aplicației dvs. Majoritatea dispozitivelor Android au în continuare confortul unei bare de navigare suplimentare (fie hardware sau software pe diferite dispozitive), inclusiv un buton înapoi. Deoarece iOS nu oferă acest lucru, aplicațiile trebuie să ia în considerare unde și când să furnizeze butonul înapoi, de obicei în colțul din stânga sus al fiecărui ecran.

   Butonul de meniu (butonul pătrat din acest exemplu) poate oferi și funcționalități suplimentare pentru aplicațiile Android. Unde este relevant? De exemplu, când deschideți meniul de setări sau o funcție similară de navigare.

   

   Până de curând, iPhone-urile prezentau și butonul de pornire tradițional al Apple, dar de la introducerea iPhone X, acesta a fost marginit, iar fluxul în iOS se bazează acum pe gesturi. Dacă glisarea este o parte importantă a aplicației dvs., asigurați-vă că oferiți suficientă pernă între marginea containerului aplicației și zona de glisare pe care o permiteți pentru a evita coincidențele dificile de glisare.

   În cazul în care aplicația dvs. se bazează pe funcționalități specifice hardware, cum ar fi Bluetooth, NFC sau căști cu fir, ar trebui să luați în considerare întotdeauna gama de specificații hardware diferite pe care le acceptați. Încercați să oferiți feedback adecvat utilizatorului atunci când încearcă să interacționeze cu o anumită caracteristică. Dacă dintr-un motiv oarecare trebuie să oferiți o funcție specifică hardware doar pentru una dintre cele două platforme, asigurați-vă că informați utilizatorii despre diferența.

3. Elemente globale (bare de stare, anteturi etc.): componentele care apar pe toate paginile designului dvs., cum ar fi bara de stare, antetul de navigare și așa mai departe, ar trebui să vizeze strict să ofere un sentiment nativ, așa că nu ar trebui să ne schimbăm înălțimea și stilul acelor bare. Există diferențe minore în modul în care elementele globale sunt stilate pe ambele platforme. De exemplu, Android folosește text aliniat la stânga, în timp ce iOS alege un titlu centrat. Bara de stare este o componentă nativă, așa că nu trebuie să vă faceți griji, dar țineți minte diferite crestături și raporturi de aspect ale ecranului atunci când planificați secțiunea superioară a aplicației.

   

   

4. Navigare: liniile directoare vechi Google de design de materiale sugerează să optați pentru navigarea prin meniul sertar în aplicațiile Android, cu navigarea de jos în urmă, dar fiind totuși o opțiune viabilă. iOS tinde să folosească numai o bară de file, care vă poate limita opțiunile de navigare de nivel superior, dar oferă o vizualizare clară a tuturor acestora simultan. În acest caz, ambele sisteme de operare oferă componente similare care pot fi utilizate în funcție de complexitatea aplicației dvs., dar diferența vizuală dintre cele două sisteme ar trebui să vă direcționeze în mod natural - de exemplu, bara de navigare globală în Android și lipsa acesteia în iOS.

   Evoluția rapidă a hardware-ului mobil din ultimii ani a introdus multe variabile și necunoscute: telefoane pe tot ecranul, crestături de diferite forme și dimensiuni, utilizarea sporită a gesturilor pentru navigarea la nivelul întregului dispozitiv și așa mai departe. Toate aceste modificări oferă utilizatorului o putere fără precedent, dar pot fi o durere atunci când încercăm să descoperim toate cazurile de utilizare ale unui anumit ecran în aplicația noastră. Având în vedere aceste preocupări, o abordare bună pentru a evita confuzia pentru utilizatorii noștri ar fi păstrarea tiparelor de navigare simple și consecvente, fără a supraîncărca aplicația cu prea multe gesturi, bare și opțiuni de glisare în mai multe direcții.

   

5. Tipografie: ambele platforme au fonturile lor implicite - San Francisco pentru iOS și Roboto pentru Android. Cu excepția cazului în care alegeți un font personalizat, strâns potrivit cu stilul general al aplicației, ar trebui să rămâneți la valorile implicite. Rețineți că utilizatorii își pot schimba fontul implicit de sistem și acest lucru nu va afecta nicio vizualizare pe care le-ați personalizat cu un anumit tip de literă.

   De exemplu, utilizatorii dislexici s-ar putea să nu aibă cel mai bun timp în aplicația dvs. dacă au înlocuit fontul implicit cu un font care le satisface în mod special nevoile. Dacă susțineți utilizatori care ar putea folosi fonturi non-latine (cum ar fi chirilice, arabă etc.), asigurați-vă că fonturile dvs. personalizate oferă și acele caractere suplimentare. Dacă ești pasionat de jocuri, probabil ai văzut acele clasamente cu scoruri mari obținute de jucătorii ruși ale căror nume ies în evidență datorită fontului diferit. Aceasta este doar o greșeală minoră făcută în timpul fazei de dezvoltare, nu o „funcție” pentru anumiți jucători și, deși probabil că nu îi va face pe utilizatori să renunțe la aplicația dvs., poate duce cu siguranță la o experiență degradată a utilizatorului sau poate duce la plângeri sau recenzii slabe.

   

6. Alte componente: butoanele, tranzițiile ecranului, animațiile, micro-interacțiunile, foile de acțiune, alertele și toate celelalte tipuri de controale ale fluxului depășesc domeniul de aplicare al acestui articol, dar ar trebui să urmeze principiul general pe care l-am aplicat altor elemente de design până acum - ambele platforme descurajează elementele personalizate excesive, deoarece ar putea distrage atenția și deruta utilizatorul; când vine vorba de design, prima impresie este de obicei ultima pentru mulți utilizatori și de aceea este atât de important să atragem atenția utilizatorilor încă de la început și să îi facem să se simtă acasă, ca să spunem așa.

În lumea reală, puteți vedea câteva excepții foarte populare de la regulile pe care le-am discutat - aplicații iOS care urmează liniile directoare Material Design și unele produse Android care merg pentru ghidurile Apple pentru interfața umană, dar acele aplicații au propriul lor stil dovedit. Utilizatorii sunt familiarizați cu aplicațiile și designul acestora și, pentru ei, este logic să ofere un sentiment puțin mai personalizat.

Abordare multiplatformă făcută corect

Pe de altă parte, dacă proiectul dvs. se bazează pe o soluție multiplatformă (cum ar fi React Native, Flutter, Xamarin etc.), ar trebui să luați în considerare care ar fi platforma principală pe care doriți să vă concentrați și să începeți de acolo.

În ultimii ani, aceste noi cadre au oferit îmbunătățiri masive ale productivității în dezvoltarea de aplicații multiplatforme. Tot mai multe companii trec la această paradigmă de dezvoltare, deoarece oferă un timp mai scurt de lansare pe piață, o eficiență superioară a costurilor și mai puține bariere tehnice, principalele dezavantaje fiind suportul limitat pentru funcții și UX suboptim în unele cazuri.

În timp ce practic toate soluțiile mai vechi pentru dezvoltarea multiplatformă s-au bazat pe vizualizări web și, prin urmare, au întâmpinat probleme serioase de reacție pe multe dispozitive, în prezent putem folosi componente native chiar și în abordări multiplatforme. Această îmbunătățire majoră a afectat piața în multe feluri și a adus toate platformele mobile cu un pas mai aproape de unificarea experienței vizuale a utilizatorului pe diferite dispozitive și platforme.

Dacă decideți să alegeți o soluție multiplatformă, puteți începe ca într-o aplicație nativă standard, construind structura aplicației dvs. Odată ce aveți prioritățile principale puse în funcțiune (configurarea dependențelor de bază, construirea unui MVP, atingerea reperelor specifice proiectului, lansarea primei versiuni etc.), vă puteți separa cu ușurință proiectele principale pentru cele două aplicații, folosind platforma- instrumente specifice pe care le oferă fiecare cadru. În funcție de dimensiunea echipei și de intervalul de timp disponibil, ați putea chiar să luați în considerare includerea acelor modificări în versiunea 1, doar pentru a evita confuzia viitoare când lucrurile nu mai arată la fel într-o anumită versiune a platformei.

După ce ați spus și făcut totul, ar trebui să evaluați care dintre aceste principii va fi valabil pentru aplicația dvs. Ca în aproape orice activitate din industria noastră, ar trebui să încercați să urmați instrucțiunile, în timp ce le ajustați ușor pentru a se potrivi nevoilor dumneavoastră specifice. De exemplu, dacă navigarea în sertare este ceea ce are sens pentru aplicația dvs. simplă cu cinci ecrane, atunci nu trebuie să veniți cu soluții complicate pentru fiecare platformă. Faceți evident și ușor pentru utilizator să vă recunoască butoanele și instrumentele personalizate, indiferent dacă sunt componente cheie sau doar personalizări minore.

Designul bun respectă obiceiurile utilizatorilor

Pentru a rezuma, putem repeta ceva ce știm deja — un design bun este designul care respectă obiceiurile utilizatorilor în fiecare sistem de operare. Doar puțină lustruire la sfârșit ar putea face diferența între o aplicație medie și o aplicație grozavă.

De multe ori, aplicația dvs. nu va oferi suficiente funcții unice pentru a câștiga utilizatorii numai cu conținut. Majoritatea oamenilor își vor descrie decizia de a alege un produs în locul altuia cu „un sentiment instinctiv”. Această categorie de utilizatori își bazează alegerile în primul rând pe modul în care se simt atunci când folosesc aplicația, evaluând implicit capacitatea de răspuns, alegerea generală a stilului, paleta de culori și componentele vizuale individuale pe care le văd pe ecran.

Prin urmare, încercați să vă asigurați că produsul dvs. iese în evidență nu numai datorită caracteristicilor sale uimitoare, ci și prin ambalaj de înaltă calitate, care să se potrivească cu calitatea serviciilor pe care le oferă.