UI și UX pentru aplicații mobile și site-uri: ce alegi și de ce

Imaginează-ți trei persoane care folosesc același serviciu de programări. Una a găsit afacerea pe Google și vrea să afle oferta și prețul. Alta este deja clientă și vrea să mute vizita de marți pe joi. La recepție, un angajat caută un interval liber între zeci de rezervări. Lucrează cu aceleași servicii și date, dar au nevoie de ecrane organizate diferit.

Diferențele de design pornesc de la ce vrea persoana să facă, cum interacționează cu dispozitivul și ce comportamente îi sunt familiare. Dimensiunea ecranului contează, dar designul mobil presupune mai mult decât micșorarea paginii de desktop.

Vom urmări acest serviciu imaginar pentru a vedea de ce navigarea, formularele, performanța și accesibilitatea cer alegeri diferite pe fiecare platformă și cum putem verifica dacă ele îi ajută pe oameni.

Imaginea de copertă este o ilustrație editorială generată cu AI, nu o captură dintr-un produs realizat pentru un client.

1. Ce înseamnă UI și UX și unde intervine platforma

UI, interfața cu utilizatorul, cuprinde textele, butoanele, câmpurile, meniurile și listele prin care folosim produsul, inclusiv felul în care semnalează o eroare sau răspund la apăsare. UX, experiența utilizatorului, privește întregul parcurs: cum descoperă persoana serviciul, ce înțelege, cât efort depune și dacă reușește ce și-a propus. Un buton poate arăta impecabil într-un proces de rezervare confuz.

O aplicație mobilă nativă folosește tehnologiile și componentele platformei pentru care este construită. Un site mobil se deschide în browser pe un ecran mic; același site poate arăta diferit pe desktop. O aplicație web pune accent pe lucrul cu date și pe acțiuni repetate, cum se întâmplă într-un CRM. O aplicație web progresivă, PWA, poate adăuga instalarea și funcții precum accesul offline, în funcție de implementare și de suportul platformei.

Aceste categorii se suprapun: un site poate include un instrument complex, iar o aplicație nativă poate afișa pagini web. Eticheta „aplicație” sau „site” nu explică singură cum ar trebui să-l folosească oamenii.

Un client poate compara atent mai multe servicii pe telefon, iar un angajat poate petrece ore într-o aplicație de tabletă. Înainte de a desena ecranele, merită să înțelegi ce face dificile aceste situații.

2. Proiectează separat prima vizită și revenirea

La prima vizită, omul nu cunoaște denumirile serviciilor și încă nu știe dacă poate avea încredere în afacere. Site-ul trebuie să explice ce primește, cui i se potrivește oferta, cât costă și cum poate continua. Informațiile sunt necesare și când ajunge direct la un serviciu din căutare, fără să fi văzut prima pagină.

Pentru clientul care revine în fiecare săptămână, aceleași explicații pot însemna derulare în plus. El își cunoaște abonamentul și caută următoarea programare, un document sau butonul de reprogramare. Acestea își au locul pe primul ecran. Detaliile despre serviciu rămân la îndemână, dar nu trebuie recitite la fiecare vizită.

Distincția se aplică ambelor platforme. Un utilizator nou al aplicației are nevoie de explicații, iar un client care revine pe site poate aprecia sediul și serviciul păstrate. Instalarea nu dovedește că persoana cunoaște oferta, după cum deschiderea browserului nu înseamnă că o vede prima dată.

Instalarea cere, la rândul ei, un efort: persoana trebuie să găsească aplicația, să o descarce și să-i facă loc pe telefon. Beneficiul ar trebui să justifice acest pas. Pentru o rezervare anuală, un site ușor de folosit poate fi suficient; pentru coordonarea zilnică a programărilor, o aplicație dedicată poate merita chiar dacă o folosesc puțini oameni.

O PWA oferă o altă variantă, dar instalarea și funcționarea offline sunt aspecte distincte. Ghidul MDN despre instalarea PWA explică faptul că un service worker este folosit adesea pentru acces offline, fără să fie o cerință a instalării. Produsul trebuie proiectat și testat pentru fiecare promisiune.

Întrebarea practică este ce devine mai simplu la a doua și la a zecea utilizare: rezervarea, găsirea documentelor, reprogramarea? Aceste avantaje explică nevoia unei aplicații mai bine decât evitarea browserului.

3. Navigarea trebuie să explice unde ești și unde revii

Arhitectura informației stabilește cum grupăm serviciile, conținutul și acțiunile. Un site public poate avea multe pagini accesibile separat din căutare. Aplicația pentru clienți poate avea câteva secțiuni principale: programări, beneficii, mesaje și cont. Numărul redus ajută numai dacă omul intuiește în care dintre ele găsește ceea ce caută.

Bara de navigare de jos poate fi utilă pe telefon, inclusiv pe web. Totuși, o destinație și o comandă au roluri diferite. „Programări” deschide o secțiune; „Programează o vizită” începe o acțiune. Apple recomandă folosirea barelor cu file pentru secțiunile principale, cu etichete clare și păstrarea contextului de navigare în fiecare secțiune. Amestecarea comenzilor cu destinațiile face comportamentul mai greu de anticipat.

Butonul Înapoi merită aceeași atenție. Pe web, utilizatorul se bazează pe istoricul browserului. O interfață care schimbă conținutul prin JavaScript trebuie să păstreze acel comportament; MDN explică integrarea cu History API. Dacă persoana a filtrat serviciile după un anumit sediu, a deschis un rezultat și apoi revine, se așteaptă să găsească aceeași selecție. Păstrarea poziției în listă o poate scuti și de o nouă căutare printre rezultate.

În Android, Înapoi și navigarea către nivelul superior pot avea sensuri diferite, mai ales după intrarea printr-un link direct. Principiile oficiale de navigare descriu aceste diferențe. Prototipul trebuie să acopere și intrarea din notificări, e-mail sau altă aplicație.

Un link către o programare trebuie să deschidă acea programare, inclusiv după autentificare, dacă este necesară. Trimiterea persoanei pe ecranul principal, unde trebuie să caute din nou, întrerupe scurtătura promisă de link.

4. Adaptează interacțiunea pentru atingere, pointer și tastatură

Degetul acoperă o parte din ecran și este mai puțin precis decât cursorul unui mouse. Două comenzi alăturate, precum „Reprogramează” și „Anulează”, au nevoie de zone ușor de atins și de suficient spațiu între ele. Zona activă poate fi mai mare decât pictograma vizibilă, atât timp cât nu se suprapune cu cea a butonului vecin.

Valorile recomandate trebuie citite cu unitățile și contextul lor. Ghidul actual Apple pentru accesibilitate indică pentru iOS și iPadOS o dimensiune implicită de 44 × 44 pt și una minimă de 28 × 28 pt. Android recomandă minimum 48 dp pentru țintele interactive. WCAG 2.2, criteriul 2.5.8, definește la nivel AA 24 × 24 pixeli CSS, cu excepții privind spațierea și anumite contexte. Punctele, dp și pixelii CSS nu sunt pixeli fizici interschimbabili. Un prag minim nu stabilește singur dimensiunea confortabilă pentru orice sarcină.

Pe desktop, un ecran mare nu garantează folosirea mouse-ului. Există laptopuri tactile, tablete cu tastatură și persoane care folosesc tehnologii asistive. Dacă prețul complet sau butonul de anulare apare numai la trecerea cursorului peste un rând, unii utilizatori îl pot rata. Comenzile esențiale trebuie să fie accesibile și prin celelalte moduri de interacțiune.

Telefonul introduce și constrângeri de poziționare: margini rezervate de sistem, decupaje, indicatorul gesturilor și tastatura virtuală. O comandă fixată jos poate ajuta accesul frecvent, dar poate acoperi ultimul câmp al formularului. Testează interacțiunea cu tastatura deschisă și în orientări diferite. Confortul nu se decide dintr-o singură captură de ecran.

5. Schimbă organizarea, nu doar dimensiunile

Pe telefon, deschizi de obicei detaliile unei programări dintr-o listă. Într-o fereastră mare, lista poate rămâne în stânga, iar detaliile se pot afișa în dreapta. Recepționerul compară astfel mai multe rezervări fără să memoreze fiecare oră sau să sară mereu între ecrane. Clientului care confirmă o singură vizită, aceeași cantitate de informație i-ar putea îngreuna alegerea.

Ghidul Android pentru aplicații adaptive descrie înlocuirea unor componente și schimbarea numărului de panouri în funcție de spațiul ferestrei. Include și postura dispozitivelor pliabile, densitatea și mărimea textului. Această logică este utilă și pentru web: o interfață bună reorganizează informația când spațiul o cere.

Structura merită schimbată când informația devine greu de urmărit. Denumiri precum „telefon” și „tabletă” sunt doar repere: o fereastră îngustă pe desktop poate cere aceeași ordine liniară ca un telefon. Prețul, data și acțiunea principală trebuie să-și păstreze importanța.

Tipografia susține această adaptare. Textul prea mic economisește spațiu vizual cu prețul citirii dificile. Rândurile foarte lungi pe desktop îngreunează urmărirea paragrafului; titlurile uriașe pe mobil pot împinge informația utilă prea jos. Verifică textele reale, inclusiv traducerile, numele lungi și mărirea fontului.

Cantitatea de informație de pe ecran depinde de ce are omul de făcut. Un tabel poate fi potrivit pentru compararea orelor, specialiștilor și stărilor rezervărilor. Dacă transformi fiecare rând într-un card înalt, comparația poate cere multă derulare. Pe ecrane mici, poți păstra coloanele esențiale și deschide separat detaliile sau poți lăsa tabelul să se deruleze într-o zonă delimitată, în care posibilitatea de derulare este ușor de observat.

Pentru serviciul nostru de programări, alegerile ar putea arăta astfel:

6. Formularele bune reduc efortul fără să ascundă decizia

Pe telefon, tastarea cere mai mult efort, iar tastatura ocupă o parte bună din ecran. Începe prin eliminarea întrebărilor inutile. Verificarea disponibilității cere serviciul, sediul și data; adresa de facturare poate aștepta. Când motivul unei întrebări nu este evident, explică de ce ai nevoie de informație.

Folosește etichete persistente și configurarea potrivită a câmpurilor pentru e-mail, telefon sau date personale. Tutorialul W3C despre etichetarea controalelor explică asocierea programatică dintre etichetă și câmp, utilă atât tehnologiilor asistive, cât și activării controlului. Un exemplu afișat în câmp poate ajuta, dar dispare la completare și nu înlocuiește eticheta.

Completarea automată și managerii de parole scutesc utilizatorul de tastare repetată. Și modul de alegere a datei contează: un calendar este util pentru programarea de săptămâna viitoare, dar devine obositor dacă trebuie să răsfoiești zeci de ani pentru data nașterii. Formatul așteptat trebuie explicat dinainte, iar într-un formular lung persoana trebuie să poată găsi ușor câmpurile de corectat.

Împărțirea în pași poate clarifica un proces complex: alegi serviciul, apoi ora, apoi completezi datele de contact. Fiecare pas aduce însă încă o trecere între ecrane, iar verificarea alegerilor anterioare poate deveni mai grea. Pe desktop, un formular scurt poate fi mai ușor de parcurs și verificat pe o singură pagină. Numărul de clicuri spune doar o parte din poveste; contează cât de sigur este omul pe fiecare alegere.

Un cont este util pentru păstrarea istoricului, dar cererea de a crea unul poate opri o primă rezervare simplă. Dacă permiți rezervarea fără cont, explică unde va primi clientul confirmarea și cum o va găsi ulterior. Când autentificarea este necesară, inclusiv după recuperarea parolei, persoana ar trebui să poată continua de unde a rămas.

Salvarea unei rezervări nefinalizate poate ajuta după o întrerupere. Merită însă ales atent ce se păstrează, unde și pentru cât timp. Păstrarea serviciului și sediului ales nu ridică aceleași probleme ca stocarea unui document sensibil pe un dispozitiv folosit de mai multe persoane.

Erorile trebuie să spună ce se poate corecta și să păstreze informația validă. După un eșec de trimitere, un formular gol obligă utilizatorul să repete munca. La final, prezintă un rezumat cu serviciul, data, locul, costul și condițiile relevante înaintea confirmării. Rapiditatea nu justifică ascunderea consecințelor.

7. Performanța se simte și după încărcarea ecranului

Un site descarcă prin rețea conținutul și fișierele necesare afișării. O aplicație instalată are nevoie de timp pentru pornire, procesare și acces la date. Poate afișa imediat meniurile, dar să întârzie afișarea orelor disponibile. Un site bine construit poate permite citirea ofertei cât timp se încarcă funcțiile secundare. Contează ce poate face utilizatorul în timpul așteptării.

Pentru web, Core Web Vitals urmăresc încărcarea conținutului principal, răspunsul la interacțiune și stabilitatea vizuală. Pragurile recomandate sunt LCP de cel mult 2,5 secunde, INP de cel mult 200 milisecunde și CLS de cel mult 0,1, evaluate la percentila 75. Sunt repere tehnice utile; nu arată singure dacă persoana a înțeles prețul sau a rezervat serviciul potrivit.

După apăsarea butonului de rezervare, persoana are nevoie de un răspuns clar: cererea se trimite, a fost confirmată sau a apărut o problemă. Un indicator care se învârte fără sfârșit nu o ajută să decidă ce urmează. Pentru operațiuni mai lungi, mesajul poate explica ce continuă în fundal și dacă utilizatorul poate părăsi ecranul între timp.

Uneori, serverul a creat rezervarea, dar confirmarea nu a ajuns la telefon. O nouă apăsare nu ar trebui să creeze încă o rezervare. Pentru asta, designul și implementarea trebuie gândite împreună: interfața are nevoie să poată verifica rezultatul primei cereri și să arate programarea existentă.

Testarea pe dispozitive mai lente și conexiuni variabile, cu date realiste, scoate la iveală aceste momente. O animație fluidă nu compensează pierderea formularului când revii din altă aplicație. Viteza ajută numai dacă poți continua ceea ce ai început.

8. Ce poți face când nu ai conexiune

„Funcționează offline” poate însemna citirea unei programări, completarea unei fișe sau modificarea unei rezervări. Afișarea unei copii locale este mai simplă decât garantarea disponibilității unui interval pe care altcineva îl poate rezerva simultan.

Și site-urile pot oferi acces offline. MDN explică rolul service worker-elor și al stocării locale. Echipa trebuie totuși să decidă ce date descarcă, cât timp rămân valabile și cum rezolvă modificările care se contrazic. Aceleași întrebări apar și într-o aplicație nativă.

Interfața trebuie să distingă trei situații: informație salvată pe dispozitiv, modificare în așteptarea sincronizării și operațiune confirmată de server. Pentru programări, „cerere salvată, se va trimite când revine conexiunea” are alt înțeles decât „programare confirmată”. Folosește o formulare care reflectă garanția reală.

Stabilește și ce se întâmplă dacă datele s-au schimbat între timp. Dacă intervalul a fost ocupat, arată conflictul și oferă alternative, păstrând preferințele deja introduse. Nu transforma o eroare de sincronizare într-un mesaj generic care obligă persoana să înceapă din nou.

Pentru personal, o listă a modificărilor încă netrimise poate fi esențială. Angajatul trebuie să vadă ce a rămas pe dispozitiv și dacă poate închide aplicația fără să piardă munca. Echipa trebuie să stabilească și ce se întâmplă cu aceste date când utilizatorul iese din cont sau intră cu alt cont. O machetă cu toate programările sincronizate nu răspunde la aceste întrebări.

Întreruperile apar și cu o conexiune bună: persoana răspunde unui mesaj sau confirmă o plată în aplicația băncii. La revenire, este util să găsească opțiunile deja completate, cu o nouă verificare a informațiilor care se pot schimba. Ora selectată ieri s-ar putea să nu mai fie disponibilă astăzi.

9. Cere permisiuni în momentul în care beneficiul este clar

Accesul la locație, cameră sau notificări poate scurta câțiva pași, dar îi cere persoanei să acorde încredere produsului. Dacă toate permisiunile apar imediat după deschidere, ea trebuie să decidă înainte să înțeleagă la ce îi folosesc. Cererea are mai mult sens când apare ca urmare a unei acțiuni alese de utilizator.

Apple recomandă cererea accesului atunci când funcția îl necesită, cu o explicație concretă. Pentru un serviciu de programări, locația poate fi cerută după alegerea „Găsește sediul apropiat”. Introducerea manuală a localității păstrează utilitatea dacă accesul este refuzat. Pentru o fotografie atașată, cererea camerei apare când persoana alege să fotografieze documentul.

Permisiunea poate fi refuzată sau revocată ulterior. Interfața trebuie să recunoască această stare și să explice alternativa disponibilă. Repetarea insistentă a solicitării consumă încrederea fără să rezolve motivul refuzului.

O notificare întrerupe ziua cuiva, așa că merită stabilit ce eveniment o justifică și când trebuie trimisă. Un memento de programare și o ofertă promoțională răspund unor așteptări diferite. Utilizatorul are nevoie de control asupra lor, iar deschiderea mementoului ar trebui să ducă la programarea respectivă. Informația importantă trebuie să rămână disponibilă și în produs, inclusiv pentru cei care nu primesc notificări.

Nu considera notificările exclusiv native. WebKit documentează Web Push pentru aplicațiile web adăugate pe ecranul principal în iOS și iPadOS, cu solicitarea permisiunii după o interacțiune directă. Suportul depinde de platformă și context. Înainte de a promite o funcție PWA, verifică dispozitivele, versiunile, browserele și modul de instalare vizate de produs.

10. Accesibilitatea începe cu primele ecrane

Componentele native și elementele HTML semantice oferă un punct de plecare bun: comunică ce este un control și cum poate fi folosit. Personalizarea trebuie să păstreze și aceste comportamente. De exemplu, o zonă desenată ca un buton are nevoie de un nume pe care îl poate anunța cititorul de ecran, de o stare clară și de un mod corect de activare.

Pe web, verifică ordinea de citire, titlurile, etichetele, navigarea cu tastatura și focalizarea după deschiderea sau închiderea unui dialog. În aplicații, verifică experiența cu cititorul de ecran și preferințele de mărire a textului. Testarea necesită și conținut realist: o etichetă scurtă poate masca problema pe care o dezvăluie o explicație în română.

WCAG explică rearanjarea conținutului la o lățime echivalentă cu 320 pixeli CSS, cu excepții pentru conținutul care necesită două dimensiuni. Scopul este ca mărirea să nu oblige persoana să urmărească fiecare rând prin derulare în două direcții. Un tabel poate avea propria zonă de derulare fără să forțeze întreaga pagină în acel comportament.

Gesturile trebuie să aibă alternative când sarcina permite. Criteriul WCAG privind tragerea elementelor cere o variantă cu pointer unic, fără tragere, cu anumite excepții. Pentru mutarea unei programări, o comandă „Schimbă ora” poate completa interacțiunea prin tragere. Suportul exclusiv prin tastatură nu rezolvă automat această nevoie.

Suprapunerile trebuie verificate și cu tastatura. Criteriul WCAG privind focalizarea neacoperită cere la nivel AA ca un control focalizat să nu fie ascuns complet de conținutul creat de autor. În practică, urmărește vizibilitatea întregului control când există bare fixe sau bannere.

Contrastul, focalizarea vizibilă și respectarea preferinței pentru mișcare redusă fac parte din aceeași verificare. O programare anulată, de exemplu, trebuie să aibă o etichetă explicită, chiar dacă rândul ei este și roșu. Aceste detalii ajută oamenii să folosească interfața; verificarea lor face parte dintr-o evaluare mai amplă, necesară pentru a susține o declarație de conformitate.

11. Păstrează identitatea fără să reinventezi convențiile

O identitate consecventă poate folosi aceleași principii de tipografie, culoare, ton și ierarhie pe mai multe platforme. Consecvența nu cere ca fiecare control să arate și să funcționeze identic. Clientul aduce deja așteptări din sistemul și browserul folosite.

Într-o aplicație iOS, un selector familiar sau un panou care se deschide de jos poate fi înțeles fără explicații suplimentare. În Android, navigarea ar trebui să urmeze comportamentul platformei. Pe web, utilizatorul se așteaptă să poată deschide un link într-o filă separată. Merită păstrate aceste obiceiuri atunci când adaptezi identitatea vizuală la fiecare mediu.

Sistemul de design ar trebui să documenteze reguli comune pentru acțiunea principală, erori, stări în așteptare și confirmări. Componentele pot arăta diferit pe fiecare platformă, păstrând aceleași sensuri.

Designul trebuie să acopere și momentele în care nu există încă informații de afișat: prima vizită, o căutare fără rezultate, încărcarea, accesul restricționat sau o eroare. În locul unei liste goale, mesajul „Nu ai încă programări” poate fi urmat de un link pentru prima rezervare. O ilustrație singură lasă persoana să ghicească ce urmează.

Documentarea reduce deciziile contradictorii între produse. În ghidul despre un sistem de design consecvent analizăm construirea unei baze comune. Poți începe cu elementele repetate și regulile observate, apoi extinde sistemul când apar nevoi reale.

12. Același serviciu de programări, trei experiențe diferite

Să reunim aceste alegeri pentru serviciul nostru ipotetic: o afacere care oferă consultații în mai multe sedii.

Pe site, un vizitator ajunge din căutare direct la un serviciu. Pagina explică pentru cine este, ce include, durata, prețul și condițiile. Alegerea sediului și verificarea disponibilității sunt vizibile fără instalare. Pe desktop, poate compara serviciile în paralel; pe telefon, ordinea liniară urmărește pașii rezervării. Linkul serviciului poate fi trimis altcuiva fără explicații suplimentare.

În aplicația mobilă pentru clienții care revin, primul ecran arată următoarea programare, adresa și ce se mai poate schimba. „Reprogramează” păstrează serviciul și preferințele cunoscute, dar cere confirmarea noului interval. Secțiunile principale au etichete clare, iar utilizatorul regăsește detaliile deschise când se întoarce într-o secțiune. Mementoul duce la programarea potrivită. Copia offline arată când a fost actualizată și nu promite o oră nouă înainte de confirmarea serverului.

În aplicația web pentru personal, prioritatea este coordonarea. Calendarul, lista și detaliile pot ocupa panouri distincte într-o fereastră largă. Filtrele după sediu, specialist și stare permit identificarea problemelor. Utilizatorul poate opera cu tastatura, vede conflictul dintre două modificări și confirmă acțiunile cu consecințe importante. Pe tabletă, panourile se reorganizează fără dispariția informației esențiale.

Toate trei folosesc aceleași reguli de disponibilitate, termene și confirmare. Diferă ordinea informațiilor și scurtăturile către acțiunile frecvente. Dacă „confirmat” înseamnă într-un loc că cererea a fost trimisă și în altul că ora este rezervată, clientul și recepționerul se vor înțelege greșit. Aceleași date și aceleași denumiri trebuie să aibă același sens pe toate ecranele.

13. Alege prin ipoteze verificabile și teste complete

Alegerea începe cu oamenii: cine va folosi produsul, cât de des, în ce condiții și ce nu reușește să facă acum? De aici poți stabili ce funcții au nevoie de acces la dispozitiv, ce trebuie să meargă offline și cum va ajunge produsul la utilizatori. Comparația trebuie să includă costul dezvoltării, dar și mentenanța, suportul și testarea fiecărei platforme.

Un site poate fi alegerea potrivită pentru descoperire și acces ocazional. O aplicație nativă poate susține o sarcină frecventă și integrări importante. O PWA poate acoperi un set relevant de nevoi dacă suportul real corespunde cerințelor. Produsele pot combina aceste medii, cu un rol clar pentru fiecare. Ghidul despre site-uri concepute pentru mobil și analiza momentului potrivit pentru o aplicație iOS dezvoltă aceste două direcții.

Apoi formulează o ipoteză pe care o poți verifica: utilizatorul ar trebui să găsească serviciul potrivit, să finalizeze rezervarea și să înțeleagă confirmarea fără ajutor. Într-o sesiune de testare poți urmări unde ezită, unde greșește și dacă reușește să continue după o întrerupere. Măsoară finalizarea, erorile, timpul necesar și revenirea pentru situații comparabile. Eliminarea unui clic ajută prea puțin dacă omul nu mai înțelege ce a ales.

Utilizatorii unei aplicații instalate au trecut deja printr-un proces de adoptare. Comportamentul lor nu poate fi comparat direct cu al tuturor vizitatorilor noi ai site-ului pentru a demonstra superioritatea platformei. Sesiunile calitative pot identifica probleme concrete, dar nu stabilesc singure o creștere a conversiei pentru întreaga populație.

Testează traseul complet pe telefon, tabletă și desktop, cu tastatura, text mărit, teme diferite, conexiune slabă, permisiuni refuzate și sesiune expirată. Include intrarea prin link direct, revenirea în istoric, trimiterea repetată și sincronizarea. Un prototip clarifică structura; o implementare funcțională verifică promisiunile despre date și dispozitiv.

Dacă pregătești un astfel de produs, discută cu noi despre public, fluxuri și constrângeri. Putem porni de la ce au oamenii de făcut și de la dificultățile lor, apoi să alegem interfețele pe care echipa le poate construi și întreține bine.