De ce atât de multe proiecte încep cu soluția
Un brief frecvent începe așa:
„Avem nevoie de o aplicație.”
Întrebarea utilă este alta:
Ce trebuie să poată face utilizatorul și de ce varianta actuală nu îi permite să facă acel lucru suficient de bine?
Poate că răspunsul final va fi într-adevăr o aplicație iOS și Android.
Dar poate fi și:
- un website mai bun;
- un web app;
- un portal pentru clienți;
- un formular inteligent;
- automatizarea unui proces;
- integrarea unor sisteme existente;
- sau simplificarea unui serviciu care a devenit inutil de complicat.
Dacă alegem tehnologia înainte să înțelegem problema, riscăm să construim foarte eficient lucrul greșit.
Când o aplicație mobilă are sens
Există câteva situații în care argumentul pentru mobile devine mult mai puternic.
Utilizatorul revine frecvent
Instalarea unei aplicații presupune un mic cost pentru utilizator.
Trebuie să o găsească, să o descarce, eventual să creeze un cont și să îi ofere spațiu pe telefon.
Costul acesta merită atunci când există un motiv real să revină: banking, fitness, transport, productivitate, mesagerie, instrumente profesionale folosite constant, produse cu experiențe recurente.
Cu cât utilizarea este mai rară, cu atât browserul devine mai greu de învins.
Telefonul este contextul natural de utilizare
Unele produse ar pierde mult din utilitate dacă ar fi gândite în primul rând pentru desktop.
De exemplu, atunci când utilizatorul trebuie să interacționeze cu produsul:
- în mișcare;
- într-un magazin;
- într-un vehicul;
- la un eveniment;
- pe teren;
- în timpul unei activități;
- în situații în care laptopul nu este realist.
În aceste cazuri, mobile nu este doar un format mai mic.
Este contextul produsului.
Ai nevoie de capabilitățile dispozitivului
Aplicațiile native devin relevante când produsul beneficiază semnificativ de funcții precum camera, GPS, senzori, biometrie, Bluetooth, stocare locală, notificări, funcționare offline sau integrarea mai profundă cu sistemul de operare.
Dar și aici trebuie pusă întrebarea:
Avem nevoie de această funcție sau doar ar fi interesant să o avem?
Diferența dintre cele două poate însemna luni de development.
Offline-ul este important
Un produs care trebuie să funcționeze fără conexiune constantă poate avea motive foarte bune să fie aplicație.
Acest lucru este relevant inclusiv pentru produse în care confidențialitatea sau controlul local asupra datelor reprezintă o parte din valoarea oferită.
În asemenea cazuri, arhitectura tehnică poate deveni parte din poziționarea produsului — este exact decizia din jurul căreia a fost construit AuthorAZ.
Notificările au valoare reală
Push notifications pot fi extrem de utile.
Pot fi și foarte enervante.
O aplicație nu devine justificată doar pentru că organizația vrea un nou canal prin care să trimită mesaje utilizatorului.
Notificarea trebuie să ajute utilizatorul să facă ceva important la momentul potrivit.
Altfel, butonul „Disable notifications” va rezolva rapid strategia.
Când probabil nu ai nevoie de o aplicație
Semnalele sunt la fel de importante.
Utilizarea este ocazională
Dacă cineva interacționează cu serviciul o dată sau de două ori pe an, este greu de justificat instalarea.
Gândește-te la:
- solicitarea unui document;
- verificarea unei informații;
- înscrierea la un eveniment;
- completarea unui formular;
- solicitarea unei oferte;
- configurarea ocazională a unui produs.
Un link poate fi mai valoros decât o iconiță pe telefon.
Produsul este în principal informațional
Dacă funcția principală este consumul de conținut, un website responsive bine construit poate fi suficient.
Aplicația nu creează automat engagement.
Nici faptul că iconița există pe homescreen.
Nu există încă suficientă utilizare
Dacă produsul web abia are utilizatori, o aplicație mobilă nu rezolvă automat problema.
Poate doar să distribuie aceeași lipsă de adopție pe încă două platforme.
Înainte să construiești iOS și Android, merită să înțelegi de ce vin oamenii, de ce revin, unde abandonează și ce problemă ar rezolva versiunea mobilă.
Motivul principal este prestigiul
„Ar trebui să avem și noi o aplicație.”
Este unul dintre cele mai scumpe moduri de a începe un proiect digital.
O aplicație nu este o dovadă că organizația este modernă.
Un produs util este.
Aplicație mobilă sau web app?
Uneori alegerea reală nu este între „aplicație” și „nimic”.
Este între o aplicație mobilă și un web app.
Un web app rulează în browser, dar poate oferi o experiență mult mai apropiată de un produs decât de un website tradițional.
Poate include conturi, dashboards, date personalizate, workflow-uri, formulare complexe, plăți, colaborare și alte funcționalități interactive.
Avantajul important este accesul imediat.
Utilizatorul deschide un link.
Nu trebuie să treacă prin App Store sau Google Play.
Pentru multe MVP-uri și produse B2B, acest lucru poate reduce atât costul, cât și fricțiunea.
Dar un PWA?
Un Progressive Web App poate ocupa o zonă intermediară.
Poate fi instalat de pe web, poate funcționa în anumite condiții offline și poate oferi o experiență apropiată de cea a unei aplicații.
Nu este soluția universală.
Capabilitățile și comportamentul pot varia în funcție de platformă, iar integrarea cu sistemul de operare nu este identică cu cea a unei aplicații native.
Dar merită analizat înainte de a presupune că două aplicații separate reprezintă singura opțiune.
Ce trebuie decis înainte să înceapă developmentul
Problemele costisitoare apar rar pentru că un buton are nuanța greșită.
Apar când produsul nu a fost definit suficient înainte să înceapă construcția.
Înainte de development trebuie să fie suficient de clare câteva lucruri.
Problema
Ce încercăm să rezolvăm?
Nu „să lansăm o aplicație”.
Ce devine mai simplu, mai rapid, mai sigur sau mai util pentru utilizator?
Utilizatorul
Cine va folosi produsul? În ce context? Cât de des? De pe ce dispozitiv? Cu câtă răbdare? Cu ce nivel de cunoștințe?
Acțiunea principală
Care este lucrul cel mai important pe care trebuie să îl poată face?
Dacă produsul are 28 de funcții „principale”, probabil nu are încă una.
Modelul de utilizare
Produsul este zilnic, săptămânal, ocazional, sezonier sau folosit doar într-un anumit moment al relației cu clientul?
Frecvența poate schimba complet alegerea platformei.
Datele
Ce informații colectăm? Unde sunt stocate? Ce trebuie sincronizat? Ce poate rămâne local? Ce este sensibil? Cine are acces?
Aceste întrebări nu ar trebui lăsate pentru finalul proiectului.
Integrarea
Trebuie produsul să comunice cu CRM-ul, ERP-ul, plățile, sistemul de autentificare, baza de date existentă, alte aplicații sau servicii externe?
Uneori „aplicația” este partea simplă.
Restul sistemului este proiectul adevărat.
MVP nu înseamnă produs prost
Una dintre cele mai utile discipline înainte de construcție este definirea MVP-ului.
Minimum Viable Product nu înseamnă „facem ceva ieftin și vedem noi după”.
Înseamnă:
Care este cea mai mică versiune a produsului care poate testa valoarea esențială în condiții reale?
Pentru asta trebuie să separăm ce este indispensabil, ce este important, ce poate veni mai târziu și ce nu ar trebui construit deloc.
Ultima categorie este subestimată.
Fiecare funcție adăugată înseamnă nu doar development inițial, ci și design, testare, mentenanță, documentație, suport, analytics, actualizări și posibil noi dependențe tehnice.
O funcție pe care nu o construiești nu trebuie întreținută niciodată.
Native, cross-platform sau web?
Abia după ce produsul este suficient de clar merită aleasă tehnologia.
Native
Aplicații construite specific pentru iOS și Android.
Pot oferi integrarea cea mai profundă cu platforma și performanță foarte bună, dar presupun de regulă mai multă complexitate și resurse.
Cross-platform
O bază comună de cod poate alimenta aplicații pentru ambele platforme.
Pentru multe produse, aceasta poate fi o alegere foarte eficientă.
Dar alegerea framework-ului trebuie făcută în funcție de produs, nu pentru că este tehnologia preferată a echipei.
Web
Poate fi cea mai bună soluție dacă distribuția ușoară, accesul instant și independența față de magazinele de aplicații sunt mai importante decât integrarea profundă cu dispozitivul.
Nu există o tehnologie „mai modernă” în abstract.
Există tehnologia potrivită problemei.
Costul real nu este doar developmentul
Când estimezi costul unei aplicații, bugetul inițial este doar o parte.
Mai există:
- mentenanță;
- actualizări ale sistemelor de operare;
- backend;
- hosting;
- servicii externe;
- securitate;
- analytics;
- customer support;
- operarea prezenței în App Store și Google Play;
- bug fixing;
- dezvoltarea funcțiilor viitoare.
De aceea, o întrebare bună nu este doar „cât costă să construim aplicația?”.
Ci:
Ce ne angajăm să operăm în următorii trei ani?
Aici produsele excesiv construite încep să își trimită factura.
Aplicația poate fi corectă și totuși ideea să fie greșită
Poți avea un design bun, cod bun, performanță bună și zero motive pentru care cineva să folosească produsul.
Developmentul nu poate rezolva o problemă de product-market fit.
Nici UX-ul.
Nici brandingul.
Înainte să investești în construcție, merită testate ipotezele care pot invalida întregul proiect.
De exemplu: vor oamenii această funcție? Este problema suficient de importantă? Ar folosi produsul suficient de des? Există o soluție mai simplă? Sunt dispuși să schimbe comportamentul actual?
Dacă răspunsurile nu sunt clare, un prototip poate avea mai multă valoare decât primele zece săptămâni de development.
Cinci întrebări înainte să construiești o aplicație
- Ce problemă concretă rezolvă?
- De ce trebuie rezolvată pe telefon?
- Cât de des va folosi utilizatorul produsul?
- Ce poate face aplicația semnificativ mai bine decât web-ul?
- Ce putem elimina din prima versiune fără să distrugem valoarea produsului?
Dacă răspunsul la întrebarea 2 sau 4 este vag, merită analizate și celelalte opțiuni înainte să înceapă construcția.
Nu începe cu „aplicația”
Începe cu problema.
Apoi cu utilizatorul.
Apoi cu produsul.
Abia după aceea cu platforma.
În multe proiecte, această ordine pare să încetinească începutul.
În realitate, evită lunile în care o echipă întreagă accelerează în direcția greșită.
Nu începem cu codul. Începem cu produsul.