Könyvajánló: 11+1 Lépés Ötletgazdáknak
Az elképzeléstől a mobil appig

A mostani posztomban egy könyvet ajánlok a figyelmedbe. Ezt “11+1 Lépés Ötletgazdáknak az elképzeléstől a mobil appig” címen írom. Olyanoknak szól, akik már régóta szeretnének egy mobil appot az ötletüknek, de nem tudják, hogy hogyan fogjanak bele? Milyen nehézségekkel találják szembe magukat? A könyv előkészületi állapotban van, azonban már most fel tudsz iratkozni rá. További infók lejjebb.

11+1 Lépés Ötletgazdáknak az elképzeléstől a mobil appig c. könyv

A tartalomból

Ha szeretnél értesülni a megjelenésről, mindenképpen iratkozz fel a https://borbelyviktor.hu oldalamon. Ekkor 20% kedvezménnyel is megajándékozlak a könyv árából.

Két nagy részre osztottam a mondanivalóját a könyvnek. Az első rész, amikor fel kell mérni, hogy mi van az ötletben. Kinek szól, mik az értékei? A második rész maga a megvalósítás, amikor már megvannak az alapok, és a gázpedálra kell lépni.

I. Felmérési szakasz

  1. Az alkalmazás-koncepció megtalálása
    1. Gondolkodjunk, keressünk ötletet
    2. Készítsünk rajzokat, terveket
  1. Felhasználói igények és piackutatás
    1. Derítsük ki, kinek készítjük
    2. Mások készítettek már hasonlót
    3. Perszónák készítése
  1. Bevételszerzés a mobilalkalmazással
    1. Fizetős letöltés
    2. In-app vásárlások
    3. Előfizetés
    4. Hirdetések
    5. Partneri programok
    6. Adatértékesítés
  1. Felhasználói élmény (UX) és felhasználói interfész (UI) tervezés
    1. A UX feladata
    2. A UI célja
    3. Játékosítás (Gamification)
  1. Interjúk és felhasználói történetek
    1. Barátok, család, ismerősök
    2. Fórumok, csoportok
    3. Szervezd ki a kérdezősködést
  1. Mobil alkalmazás, weboldal, PWA
    1. A natív mobil app
    2. Weboldal és PWA hasonlóságok
    3. A hátrány előnnyé fordítása

II. Megvalósítási szakasz

  1. Low-Code és No-Code megoldások
    1. Figma prototípus készítése
    2. FlutterFlow, egy teljes megoldás
    3. Convertify, weboldalból mobil app készítése
    4. Canva, a mindentudó
  1. Fejlesztő csapat összeállítása
    1. Az Innovátor szerepe
    2. Projekt menedzsment kicsiben
    3. Frontend, mobil fejlesztő
    4. Backend, felhőszolgáltatás fejlesztő
    5. Védd meg, ami a tiéd
  1. Mobilalkalmazások kapcsolata a külvilággal
    1. Adataink tárolása szerveren
    2. Szolgáltatókhoz kapcsolódás
    3. Automatizáljuk, amit tudunk!
  1. Az alkalmazás piaci bevezetése
    1. Mobil áruházak beállítása
    2. Felkészülés a frissítésekre
  1. A fejlesztés költségeinek becslése
    1. Kezdj kicsiben, az MVP
    2. Gondolkodj a jövőbeli növekedésre
    3. Tárhely szolgáltatók, licenszek
    4. Hirdetési költségek
  1. Jövőbeli trendek a mobilalkalmazás fejlesztésben
    1. A Mesterséges Intelligencia kihasználása
    2. Növekvő piac
    3. Virtuális terek
    4. A személyes biztonság felértékelődik

A fejezetek tartalmából

1. Az alkalmazás-koncepció megtalálása: Ez a fejezet arra ösztönzi az ötletgazdát, hogy először mélyüljön el, és részleteiben gondolkodja át alkalmazása alapvető ötletét és célját. A kezdeti fázisban az alkalmazás egyedi értékajánlatát, célközönségét és a versenytársakhoz való viszonyát kell feltárnia és minél jobban meghatároznia.

2. Felhasználói igények és piackutatás: Ebben a fejezetben az ötletgazda megtanulja, hogyan végezzen alapos piackutatást és derítse ki a felhasználói igényeket. Fontos, hogy megértsük, mit akarnak a potenciális felhasználók, és ismerjük, hogy milyen megoldások léteznek már a piacon.

3. Bevételszerzés a mobilalkalmazással: Egy jó program akkor tud életben maradni, ha bevételt termel. Az alkalmazásnak nem csak hasznosnak, hanem jövedelmezőnek is kell lennie. Ez a fejezet bemutatja a különböző bevételszerzési modelleket, és segít kiválasztani a legmegfelelőbbet az adott alkalmazáshoz.

4. Felhasználói élmény (UX) és felhasználói interfész (UI) tervezés: Az alkalmazásnak egyszerűnek és vonzónak kell lennie a felhasználók számára. Ebben a fejezetben példákat láthatunk arra, hogyan tervezzünk intuitív és felhasználóbarát felületeket, amelyek elősegítik a felhasználói elégedettséget és a hosszú távú elköteleződést.

5. Interjúk és felhasználói történetek: Ezen keresztül közelebb kerülhetünk a felhasználókhoz, megismerhetjük igényeiket, problémáikat, és jobban megérthetjük, hogyan használják (vagy használnák) az alkalmazást. Ezek a beszélgetések felbecsülhetetlen értékkel bírnak a terméktervezés során.

6. Mobil alkalmazás, weboldal, PWA – Egy innovátor számára fontos döntés, hogy milyen platformon jelenjen meg: mobilalkalmazás, weboldal vagy progresszív webalkalmazás (PWA), csak hogy a leggyakoribbakat említsük. A fejezet részletezi az egyes megoldások előnyeit és hátrányait. A költségektől kezdve, a frissíthetőségen át, egészen a fejlesztők megtalálásáig számos olyan aspektusa van a szoftveres termékfejlesztésnek, amit figyelembe kell venni. Ennek a résznek a végére már körvonalazódni fog, hogy mire van szüksége.

7. Low-Code és No-Code megoldások: Ma már különböző ingyenes, online és olcsó eszköztár áll rendelkezésre a tervezési folyamat megkönnyítésére. Akár anélkül, hogy mély programozási ismeretekkel rendelkeznénk.

8. Fejlesztő csapat összeállítása: Egy sikeres alkalmazás mögött mindig ott van egy ügyes csapat. Ha nincsen meg az alapos tudásod ezen a területen, meg kell találnod őket. Ez a fejezet segítséget nyújt abban, hogy hogyan válasszuk ki a megfelelő partnereket és fejlesztőket a projekthez. Beszéljünk közös nyelvet, hogy gyorsabban tudjunk haladni.

9. Mobilalkalmazások kapcsolata a külvilággal: Az alkalmazások gyakran kapcsolatban állnak más szolgáltatásokkal és rendszerekkel, például külső szerverekkel adatbázisokkal, API-kkal. Ez a fejezet segít megérteni ezeket a kapcsolatokat és integrációjukat.

10. Az alkalmazás piaci bevezetése: Miután elkészült az alkalmazás, a következő lépés annak bemutatása a világnak. Ez a fejezet bemutatja a mobilalkalmazások sikeres piaci bevezetésének alapvető stratégiáit és taktikáit.

11. A fejlesztés költségeinek becslése: Ez a fejezet arra fókuszál, hogyan határozzuk meg és kezeljük a mobilalkalmazás fejlesztésének költségeit. A fejlesztési költségek becslése nem könnyű feladat, mivel sok tényező befolyásolhatja őket, például az alkalmazás összetettsége, a kiválasztott technológiai stack, a csapat mérete és szakértelme, a tervezett időkeret, és még sok más. A fejezet bemutatja a költségbecslés alapvető módszereit, és tippeket ad arra, hogyan lehet a valóságnak megfelelő költségvetést tervezni.


+1 Jövőbeli trendek a mobilalkalmazás fejlesztésben: Az alkalmazásfejlesztés területe gyorsan fejlődik, és fontos, hogy képben legyél a legújabb trendekkel és technológiákkal. Nem is beszélve a 2023-as évben berobbant Mesterséges Intelligencia (AI) térhódításával. Mindezek mellett meghatározóak a chatbot és Kiterjesztett valóság (AR = Augmented Reality) appok. A mobil appok piaca dinamikusan növekszik, még sokáig meghatározó marad.

Lapozz bele!

Ha szeretnél értesülni a megjelenésről, mindenképpen iratkozz fel a https://borbelyviktor.hu oldalamon. Ekkor 20% kedvezménnyel is megajándékozlak a könyv árából.

Elérhető az Issuu.com-on:

Mobil app vagy Mobil website? Melyik a jobb választás?
A 2020-as év fellendítette a mobilozást

Melyiket válasszam? Mobil app vagy mobil website?
Néha nehéz választani a jó közül. forrás: pixabay.com

Elérkezett a mobilozás ideje – a mobilt használók már többen vannak, mint az asztali gépet használók. Ennek következményeként az üzleti élet felismerte, hogy a mobil kommunikációt hatékonyabban kell használnia, hogy új ügyfeleket vonzanak. Bár ez önmagában még nem elegendő! A mobil app-okat vagy az website-jainkat optimalizálni kell a jó felhasználói élmény érdekében. Melyikre fektessük a hangsúlyt, ha a költségeket szinten kell tartani?

A 2020-as év eseményei tovább erősítették azt a tendenciát, hogy az emberek már inkább mobil eszközökről interneteznek, érik el a digitális tartalmakat.

Mobile App-ok

A natív mobil app-ok meghatározott platformra készülnek, úgymint iOS vagy Android operációs rendszerre. A felhasználók letöltik és telepítik az eszközeikre, és általánosan elmondható, hogy a natív app-ok gyorsabb és érzékenyebb felhasználói élményt nyújtanak a mobil website társaiknál.

A felhasználói élmény

Többféle, interaktív módon lehet a felhasználókat elkötelezni

A mobil app lehetővé teszi, hogy a meglévő felhasználóidnak egy új csatornán keresztül tudsz értéket adni. Ahelyett, hogy ugyan azt a szöveget és képeket kellene néznie, mint egy website-on, az app-ok olyan funkciókat tartalmaznak, amik az app speciális részeivel is kapcsolatba kerülnek. Például, az Instagram felhasználók megnézhetik a képeket egy website-on, de nem tudnak feltölteni az app nélkül.

Személyre szabhatóság

A mobil app-ok lehetővé teszik, hogy amint letöltötték a felhasználók az app-ot, egyből személyre is szabhassák a saját ízlésük szerint. Az app-ok tudják követni a felhasználói használatot, ez arra használható fel, hogy egyéni ajánlatokat, frissítéseket javasoljanak. Ezáltal még értékesebb lesz a használója számára. Az app-ok az üzleti élet számára fontos, egyénre szabott kommunikációt tudnak folytatni a felhasználó érdeklődési körei, földrajzi helyzete, használati szokásai, stb. alapján. A Business of Apps felmérése alapján, a személyre szóló vagy un. dinamikus értesítések pozitív hatással voltak az elköteleződésre, a megnyitási hajlandóságra, és a konverzióra. Az egyedi beállítások lehetősége jó a felhasználónak is, mert így a legtöbbet hozhatja ki az app-ból.

Működik offline módban is

A mobil app-ok internet kapcsolat nélkül is használhatóak. Bár sok app-nak szüksége van internet hozzáférésre, hogy a feladataik legtöbbjét elvégezzék, még így is tudnak biztosítani bizonyos funkciókat vagy tartalmat, kapcsolat hiányában. Ezzel az előnnyel a felhasználóink hozzáférhetnek az információhoz bárhol, bármikor.

Intuitív felületek

A mobil app-ok általánosságban véve intuitívabb kezelőfelületet nyújtanak, ezáltal a feladataink is könnyebben elvégezhetőek. Az egyedien kialakított felület lehetőséget ad, hogy a felhasználók jobban elmerüljenek a mobilozásban. Egy adott operációs rendszert használók már hozzászoktak annak működéséhez, és ha egy app egy bizonyos platformra készül, akkor a felhasználók ott is azt kapják, amit megszoktak. Egy reszponzív website nem tudja ezt minden esetben megadni.

Használjuk ki az eszköz képességeit!

A mobil app-ok hozzáférnek az eszköz beépített funkcióihoz, úgymint a kamera, GPS, helymeghatározás. Ezeknek a kihasználása egy fejlettebb, kényelmesebb élményt nyújt.

Például a GPS adatok automatikus használata a személyszállító társaságoknak nagyban segíti az utazásra váró személy megtalálását. Ezzel lerövidítve a várakozási időt, és növelve az elégedettséget.

Reszponzív mobil website-ok

A Reszponzív mobil website-ok olyan website-ok, amik a különböző képernyőméretekhez igazodnak. Alapvetően, egy reszponzív website ugyan annak az általános website-nak egy különlegesen beállított változata, de ezáltal a mobil-on is jól használható.

A felhasználói élmény

Mindenki számára elérhető

A mobil app-okkal ellentétben, amik csak bizonyos platformokon működnek (iOS vagy Android), egy reszponzív website bármely mobil eszközön elérhető, függetlenül az operációs rendszerétől, feltéve, hogy van internet kapcsolat. Bár ne feledjük, hogy az internet elérés, annak minősége és a sebessége mind olyan tényező, ami befolyásolja a web-es élményt.

A reszponzív website-okat nem kell letölteni és telepíteni, valamint teljesen ingyenesek, nem úgy, mint néhány fizetős app az áruházakban.

Nem a felhasználónak kell frissítenie

Még egyszer, a mobil app-okkal ellentétben, a felhasználóiknak nem kell bajlódni az új verziókkal és azok frissítgetésével, ha a website-ból egy új javítás jön ki. Mivel a website-ok könnyen frissíthetőek, könnyű hibákat javítani rajtuk, ezért feltételezhetően a felhasználók nem fognak az egészből semmit észrevenni, és egyből élvezhetik az új, fejlettebb élményt.

Költséghatékony

A költséghatékonyság inkább üzleti szempontból előnyös, mint a felhasználók szemszögéből. A bonyolultságtól függően azonban egy reszponzív mobil website költséghatékonyabb lehet, mint a mobilalkalmazások fejlesztése. A költségek egy alapvető tényező, amit számításba kell venni, különösképpen, ha egy app-pal több platformon is jelen szeretnénk lenni.

A költségek csökkentésére ma már nagyon jó megoldások léteznek, amik lehetővé teszik, hogy a mobil app-unk mindkét platformra (iOS és Android) elérhető legyen, de nagyjából a teljes ár kb. 65-75%-árért. Ilyen keretrendszer a Flutter, ami most a legjobb választásnak számít.

Konklúzió: melyik a jobb?

Tisztán statisztikailag nézve a számok azt mutatják, hogy a mobil app-ok érik meg. Egy nem túl régi jelentés a Sensor Tower-től kiderítette, hogy a fogyasztás és a telepítések száma a mobil app használók körében jelentősen növekedett 2020 első felében, elérve az 50.1 Milliárd dollárt az App Store és Google Play áruházakban, összesítve. Míg ez a növekedés a COVID-19-nek és annak felhasználókra gyakorolt hatásainak tudható be, ez 23.4%-os növekedést mutat 2019 első feléhez képest és folyamatosan növekszik.

Ugyan ez a jelentés azt becsüli, hogy 71.5 Milliárd új app telepítés történt 2020 első felében. Ez 26.1%-os növekedést jelent az előző évhez képest (YoY), ami további ösztönzést adott a vállalatoknak, hogy app szolgáltatást fejlesszenek.

A megfelelő választás függ az üzleti céljainktól. Ha a célunk az, hogy mobilbarát tartalmat szolgáltassunk a széles közönségnek, akkor feltételezhetően egy mobil website elegendő számunkra. Amennyiben a nagyobb elköteleződés, a szorosabb kapcsolattartás és kommunikáció ami növeli a lojalitást, a mobil app jobb választásnak tűnik.

Sok esetben úgy dönthetünk, hogy mindkettőre szükségünk van, egy mobil app-ra és egy website-ra. Ha jól van kivitelezve a stratégia, mindkettő értéket adhat vállalkozásunkhoz. Tehát amikor a branded mobil stratégiáján dolgozol, a kérdés nem az lesz, hogy mobil app vagy website legyen, hanem inkább egy kétirányú megközelítés.

Létezik egy köztes megoldás is, ötvözve a két irány előnyeit és hátrányait, ez a PWA. Vagyis Progressive Web App. Erről bővebben írtam egy bejegyzésemben.

Ha mobil app fejlesztését fontolgatod, akkor keress fel bizalommal az elérhetőségeim egyikén, ahol egy ingyenes beszélgetés alkalmával meg tudjuk beszélni, hogy mire app-ra, vagy website-ra van szükséged?

UI/UX: a képernyők kidolgozása 5 hasznos tippel
A vizuális hierarchia eszköztára

a vizuális hierarchia segít a keresésben

A vizuális hierarchia segít a digitális felületek kialakításánál. Gondosan kell eljárni, hogy az megfelelő információk elérhetőek legyenek, ugyan akkor ne árassza el feleslegesen a felhasználót. Mindössze néhány másodperc alatt dönt a fogyasztó, hogy megérti-e, mi van az oldalon? Neki szól-e? Meg fogja-e találni rajta, amit keres? Egy kis odafigyeléssel sokat tudunk segíteni ezen.

A design4users cikke alapján készítettem el az írásomat.

A vizuális hierarchia

Azért, hogy a felhasználónak a tartalom egyértelmű legyen, a designerek a jól ismert vizuális hierarchia technikát alkalmazzák. Ez az egyik alapvető technika, amit a tervezés folyamán alkalmaznak. Ez alapvetően a Gestalt pszichológiai elméleten alapul, ami megvizsgálja a felhasználókat, hogy milyen benyomást kelt az egyes elemek egymáshoz való viszonya. Azt is megmutatja, hogy az emberek hogyan egységesítik az egyes vizuális elemeket csoportokba.

A vizuális hierarchia törekszik rá, hogy egy termékben a tartalmakat olyan formában mutassa a felhasználóknak, hogy abból kikövetkeztethető legyen a fontossági szintjük. Úgy szervezi a UI összetevőket, hogy az agyunk különbséget tudjon tenni az elemek között a fizikai különbözőségeik alapján, úgymint méret, szín, kontraszt, stílus, stb.

Egy UI elem vizuális megjelenése nagyban befolyásolja a felhasználói élményt egy termékben. Ha az összetevők egy nagy katyvaszra hasonlítanak, akkor az emberek nem tudnak navigálni a terméken belül, vagy megfelelően kapcsolatba kerülni vele. Továbbá, a strukturálatlan tartalom nehezen olvasható, ezért nehéz végigfutni, ezért külön erőfeszítésbe telik, hogy a keresett adatot megtalálják. Egy gyenge UX (User Experience) alacsony elégedettséghez vezet, aminek a következménye, hogy messze elkerülik.

Tipográfiai hierarchia

A UI tervezésnek meghatározó része a tartalmi leírás. Ezért a vizuális hierarchia gyakran a tipográfia függvénye. A szakértők elhatározták, hogy hangsúlyozzák a tartalom megjelenésének fontosságát, ezért létrehoztak egy külön rendszert rá: tipográfiai hierarchia.

A keretrendszer célja, hogy a lehető legjobban rendszerezze a tartalmat a felhasználó számára. A tervezők különböző módon használják és kombinálják a betűket, hogy ellentétbe hozzák a legjelentősebb és kiemelkedő tartalmi elemeket, amiket először észre kell venni azokkal, amik csak másodlagos hangsúllyal bírnak. A betűk méretét, színét, betű-családját, igazítását módosítják.

A tipográfiai hierarchia különböző tartalmi elemeket különböztet meg: fejlécek, alcímek, szövegtörzs, akció gombok (CTA = Call-to-Action), képaláírások, stb. A hatékony hierarchia kialakításáért ezeket az elemeket különböző szintekre kell bontani. Nézzük, mik ezek!

Elsődleges szint. Ide tartozik a legnagyobb típus, mint a fejléc. Az Elsődleges szint célja, hogy az alap információt megadja a felhasználónak és felhívja az emberek figyelmét a termékre.

Másodlagos szint. Ez azok a tartalmi elemek, amiket könnyedén kell tudnunk átfésülni. Ezek általában alcímek, képaláírások, ami segít könnyen értelmezni a tartalmat.

Harmadlagos szint. A szövegtörzs és néhány kiegészítő adat tartozik a harmadlagos szint kategóriájába. A designerek gyakran alkalmaznak viszonylag kis betűtípust, ami még megfelelően olvashatónak kell maradnia.

Mivel a tartalom a fő információforrás a UI-on, a designereknek fokozatosan kell elénk tárni az adatokat. Ha a fenti szegmentálást alkalmazzák, akkor a felhasználók könnyedén eljutnak az egyik részről a másikra, és az információt a megfelelő sorrendben értelmezik.

Fontos kiemelni, hogy a mobil készülékek kis képernyője nem teszi lehetővé mind a három szint alkalmazását. Ezért a tervezéskor a második szintet ki kell hagyni (alcímek), hogy a mobil UI kinézete átlátható maradjon.

A vizuális hierarchia eszköztára

Amikor a tervező kiválasztotta a tartalmi elemeket, itt az ideje, hogy a sorrendet megállapítsa. Vegyük sorra, hogy mi van a designer segítségére, hogy beállítsa a hatást.

Méret

Az egyik legerősebb eszköz a vizuális elem átalakítására a mérete. Ez az emberi elmében gyökerezik, hogy a nagyobb dolgok valahogyan fontosabbak a kisebbeknél. Ezért van, hogy a felhasználók figyelme automatikusan először a nagy szavakra vagy képekre vetődik.

Szín

A színnek nagy hatása van az érzékelésben, ezért kiváló a vizuális hierarchia kialakításánál.

A színeknek maguknak is megvannak a saját sorrendje, amit a felhasználó elméjére gyakorol hatása határoz meg. Vannak feltűnő színek, mint a vörös, narancs, fekete, amelyek könnyen vonzzák a tekintetet. A másik véglet a gyenge, vagy lágy színek, mint a fehér és krém színek, amik inkább háttérként működnek jobban.

Kontraszt

A sorrendiség magán az ellentéten alapul. Egy elem kontrasztban áll egy másikkal, és így látja a felhasználó a különbségeket közöttük. Az ellentételezés létrehozható a képi különbözőségekkel: méret, szín, stílus. Mégis, ajánlott, hogy az ellentételezést tartsuk egyensúlyban, hogy az egyik elem ne nyomja el teljesen a másikat.

Üres terek

Nagyon sok képi elem jelenhet meg az interfészen, és hogy mindegyik észrevehető legyen a szemnek, ezért szükség van privát térre. Az üres terek (negative space), vagy holt terek, az egyes elemek közti teret jeleni az összeállításban. Néhány tervező nem tekinti a kompozíció részének, de a szakértők előszeretettel alkalmazzák a megfelelő összhang kialakításáért.

Közelség

Feljebb már említettem, a vizuális hierarchia a Gestalt alapelveken nyugszik, ezért a tervezők különös figyelmet fordítanak az egyes elemek a közelségére (proximity). Ahogy az emberek hajlamosak a vizuális elemeket csoportokba egyesíteni, ezért a UI elemeket úgy kell elhelyezni, hogy a felhasználók kategorizálni tudják őket. Ha néhány elem egy bizonyos távolságban vannak, akkor ezt a felhasználók csoportoknak érzékeli. A designerek a közelséget egy eszközként tudják használni, ami segít a tartalmat kisebb kategóriákra bontani.

Ismétlődés

Ha az emberek úgy vélik, hogy néhány elem hasonlít egymásra, akkor automatikusan egy csoportként egyesítik őket. Ez az, ahogy az ismétlődés működik. A designerek megismételnek bizonyos mintázatokat a különböző objektumokon azzal a céllal, hogy a felhasználók egyesítsék őket.

Láthatjuk, hogy a vizuális hierarchia az alapja egy hatékony információs architektúrának. Amikor a UI elemek strukturáltak és szervezettek, az emberek élvezettel használnak egy terméket, és ez hatékonyabb lesz a problémájuk megoldásában.

Borítókép: carlevarino

A kezdetek: egy app alapjai

fontos az alap összetevők meghatározása egy app alapjai eseténben is

Laza talajra nehéz tartós várat építeni. Kellenek a jó alapok a mindennapjainkban, amikre tudunk építkezni. Olyan stabil állások, ami az előre nem várt terheléseket képesek kibírni. Ez a digitális termékek előállításánál sincsen másképpen. Egy app alapjai is ilyenek. Könnyebben módosíthatóak fizikai társaiknál, mert nem kőbe vésett alkotások. Mindazonáltal az alkotóiknak ugyan olyan pontosan kell eljárniuk az elejétől fogva, mint egy felhőkarcolónál.

A bevezetőben említett párhuzammal azt érzékeltettem, hogy bizony sok kidobott munkaórától kíméli meg magát az a szoftver fejlesztő, aki időt szán a részletek kidolgozására.

Folytatva az előző cikkben bemutatott Trivia Game kvíz mobil app alapjai után, bemutatom, hogy én hogyan szoktam nekifogni a részletek meghatározásának.

A funkcionalitás behatárolása

Fontos, hogy egy mobil alkalmazás egy feladatot oldjon meg, de azt jól tudja. Ez egy közhelyes kijelentés. Ez igaz a kezdeti időkre. Miért? Mert az első felhasználóink ebből fogják megtudni az üzenetünket, amit közvetíteni szeretnénk. Azt, hogy pontosan mit fog a mi app-unk megoldani nekik. Ennek jól felismerhetőnek és egyértelműnek kell lennie. Ez a UX (User eXperience) terülébe tartozik.

A Trivia Game egy kvíz játék alkalmazás, ami hétköznapi kérdéseket mutat meg, de a válaszok már korántsem egyértelműek.

Az alapok után aztán jöhet további meghatározás: többen is játszhatják; kihívások formájában; internet nélkül is működjön; motiválja a játékost közben, stb.

A legkisebb egység

Ezekből könnyedén látszik, hogy a legkisebb egység egy kérdés (trivia). Egy olyan kis adatszerkezet, ami köré szervezhető a termék.

Fontosnak tartom, hogy struktúrákban gondolkodjak. Ez olyan, mintha egy dobozt hordoznánk körbe. Az, hogy mi van a dobozban, nem lesz érdekes a postásnak. Csak a végén annak, aki megnézni. Kivehetek, beletehetek dolgokat (adatok) később bármikor. Ezt, a játék elemi egységét, egy kvíz “feladványon” keresztül mutatom be.

Egy kvíz “feladványhoz” a következő részleteket tárolom:

  • kérdés egyedi, rendszer-azonosítója (1)
  • kérdés címe (2)
  • maga a megoldandó feladvány szövege, vagy egy kép (3)
  • hány pont jár érte (4)
  • mi a nehézségi szintje (5)
  • milyen témákhoz tartozhat (tag) (6)
  • mi a helyes megoldás hozzá (7)
  • a különböző nyelvek jelölése (8)

Ezek nem elsőre, nem egyszerre kerültek meghatározásra, hanem a működés alapján, amit a következő fejezetben fejtek ki.

Mi a működési mechanizmus?

A játék menete az, hogy valahogyan a telefonra kerül a feladványok halmaza. Előre telepített, vagy az első induláskor, az internetről tölti le magának a játék. Ezeket azonosítani lehet (1).

A játékos beállíthatja magának, hogy milyen témában (6), milyen nehézségi szinten (5) játszik.

A program ezután elkezdi feldobálni a kérdéseket (2, 3) egy megjelenítő felületen. A válaszokat egyből kiértékeli a pontszám (4) és a megoldókulcs (7) alapján. Ebből összeáll a játszmán elért pontszám, és a játékos szintet léphet. Vagy kap egy jelvényt. Vagy amit csak beleterveztünk.

Azért, hogy ne legyen unalmas a játék, a már korábban játszott kérdéseket nem, vagy csak nagyon ritkán sorsolja be újra. Erről a kvíz azonosítójának (1) a megjegyzésével lehet gondoskodni.

Hogyan tovább az MVP után?

Az egyszerű működés később sokféle irányba elvihető. Nem gond az, ha picit túl van tervezve a játék. (Én legalábbis szeretek túltervezni.) Az a jó, ha ugyan azt az adatot 2-3-4-féleképpen fel tudom használni. Ez a “származtatott adatok” fogalma. Lehetőleg olyan dolgot tartsunk nyilván, amiből több minden eldönthető, és nem kell más adattal együtt módosítanunk. Ez eléggé ködös megfogalmazás, mutatok egy példát rá.

Ha tároljuk egy adatbázisban egy kvíz listáját, és van egy mező, hogy volt-e már játszva, akkor jobb, ha oda nem azt jegyezzük meg róla, hogy igen/nem. Helyette szerencsésebb, ha egy dátumot írunk, hogy mikor játszotta, egyébként pedig üres. 1 adattal máris több infót kaptunk:

  1. volt-e játszva?
  2. mikor volt játszva?
  3. milyen sorrendben játszotta őket?
  4. ha csinálunk egy versenyt belőle, és más játékoséval vetjük össze, akkor egy sorrend is felállítható, és így tovább.

Álljon itt egy jótanács:

Minél előbb kerekítsük le az elképzelést, és álljunk ellen a további funkciók hozzáadásának. Ez csak tovább fogja bonyolítani a megoldást, és elhúzza az első bemutatható változat időpontját.

A dokumentáció a segítségünkre legyen

Az ügyféltől jövő követelményeket a specifikáció dokumentuma írja le. Ebben főként a: “MIT? szeretnének elkészíteni” kérdésre kapunk választ. Ezt feldolgozva, megrágva egy szervező (architekt) által, kialakulnak elképzelések a: “HOGYAN? -ra” egy design dokumentum formájában.

Lényeges, hogy a szükséges alap infókat tartalmazza. Ne egy kisregényt írjunk, de adjon elegendő támpontot a később érkezőknek, akik csatlakoznak a fejlesztéshez. Érthető és lényegre törő legyen. Ha túl hosszú, és senki soha sem olvassa el, akkor haszontalan volt koptatni a billentyűzetet. (A témában a DigitalHungary.hu hasábjain írtam már.)

Remélem hasznosnak találtad a módszereimet, amiben leírtam egy app alapjai kialakításánál mire figyelek oda. Ha tetszett, tarts velem a következő részre. Akkor a felületek tervezésével, megoldásaival jelentkezem.

Borítókép: Icons8 Team / Unsplash.com

Hihetetlen, ezekből a lépésekből áll egy mobil app fejlesztés

mobil app fejlesztés fontos kelléke a vázlat

Az öt alap lépésről korábban már írtam egy cikksorozatot. Most egy konkrét mobil app fejlesztés menetét vezetem végig. Az elején kezdve, az ötlettől, a tervezésen át, a kiadásig.

Gondolkodjunk, keressünk ötletet!

Szerencsére ezzel nem szokott gondom lenni. Elképzelésekből nincsen hiány. Érdemes addig csavarni az ötletet, amíg valami igazán eredeti nem jön ki belőle. Egy jelentéktelennek tűnő “ötlet-magból” kiindulva, nagyon szerteágazó dolgok jöhetnek ki.

Ebben az esetben én egy TV reklámból vettem az ötletemet. Egy családi társasjáték, ami egy műanyag doboz, ami beszél a játékosokhoz, és bár annak tűnő, de mégsem hétköznapi kérdésekről kell eldönteni, hogy igaz vagy hamis.

Ez elsőre nem eredeti ötlet, számos ilyen alkalmazás van már a Store-okban.

Ezen a vonalon tovább gondolkozva jöttek egymásra az elképzelések. Honnan lesznek ilyen kérdések? Hogyan fog működni? Egy személy, vagy többen játszhatják? Ha többen, akkor a baráti asztal körül, vagy online? Ha online, ki lehet hívni valakit párbajra? Ha párbaj, akkor abban az adott időpontban kell lejátszani, vagy később is ráér? Ha később is jó, akkor nem lehetne, hogy egyszemélyesként is lehet játszani, és minden nap adott időpontban szól? Nem lehetne, hogy ezt átvigyem egy napi kihívásba? És így tovább…

Érezhető, hogy ebbe az egyszerű alapgondolatba mennyi minden beleférhet, ha kellően sokat foglalkozom vele. Elsőre egy egyszerűbb csomagot fogtam meg ebből, és így álltam neki.

Készítsünk hozzá rajzokat, terveket

Az elképzeléseimet vethettem volna papírra is. Sok helyen ezt javasolják, bár én már türelmetlenül vártam, hogy vizuálisan megfogalmazzam, ami a fejemben volt.

A tervezésre általában a Figma online szerkesztőjét használom. Ez kiváló 2 designer együttműködésére. Bárkivel meg tudom osztani a terveimet átnézésre. Nincsen korlátja. Ami még nagyon jó benne, hogy tudok mobilos drótvázat (wireframe) csinálni.

Először az adott témában gyűjtök vizuális részleteket. Keresek olyan app-okat, színeket, ikonokat, betűtípusokat, amikből majd összeépítem a művemet. Ezt itt tudod megnézni. A drótvázat pedig ide tettem. Ebben tulajdonképpen létre tudok hozni érzékeny felületeket, amik kattinthatóak, és átvisznek egy másik képernyőre. Olyan mintha máris működne 🙂

Mennyi időt fog igénybe venni, mire elkészül?

Ekkor szoktam nyitni egy Google spreadsheet-et a számításoknak. Megosztok egy letölthető változatot, hogy támpontot adjon a szükséges feladatok listájáról. Ez nem teljes, és a számok is mintaként szolgálnak. Összetett lista, az látszik rajta. Ezeket lehetne még jóval tovább részletezni.

a számítások táblázata

Hol fog életre kelni?

Nos, főként mobil alkalmazások fejlesztésével szeretek foglalkozni. Ha kell, a háttér részét is elkészítem Kotlin nyelven, Spring Boot web-alkalmazást. Szóval most a Google Firebase felhőszolgáltatását vettem elő. Ez tud mindent (sőt!), amire nekem szükségem lesz.

Szükségem lesz a kérdések tárolására, hogy folyamatosan újabb és újabb kérdéseket tudjak betölteni.

A felhasználók regisztrációja a későbbiekben szükséges lehet. Ez még alakulni fog.

Idáig fogok eljutni

Előre pörgetve az eseményeket, egy alap, un. MVP (Minimal Valuable Product = Minimálisan Használható Termék) így néz ki. Ezen már érződik a koncepció. Körvonalazódnak a színek, formák, elhelyezések.

Ebben a sorozatban tovább haladok a mobil app fejlesztés megvalósításával. Beszélni fogok az apró részletekről, döntésekről. Ha követed az írásomat, látni fogod, hogy hogyan alakul ki a végleges változat.

Amennyiben megtetszett, és te is szeretnél egy hasonlót magadnak, keress meg, beszélgessünk az álmaid mobil alkalmazásáról!

Borítókép: Halacious / Unsplash.com

money from wallet

Legjobb érvek egy mobil-alkalmazás megrendelése mellett
Ezeket ellenőrizd, mielőtt megrendeled

mobil-alkalmazás vagy weblap legyen

Az elmúlt több, mint 10 évben, amikor megjelentek az okos telefonok, egy új formátumot hoztak magukkal: az app-okat. Miben nyújt többet egy mobil-alkalmazás egy responsive weblap helyett? Ha komoly elhatározásunk van egy mobil-alkalmazás megrendelése mellett, akkor az elképzelésünknek már csak a pénztárcánk szabhat határt. Ár-érték arányban hogyan teljesítenek a jól bejáratott weblapokhoz képest? Ezt a témát járom körül.

Mit mutatnak az alkalmazás-áruházak statisztikái

Kezdjük a száraz számokkal, mert azok ritkán tévednek. A statista.com mutatóit megnézve, látható, hogy a mobil-alkalmazások letöltései töretlenek. Évről évre a bővülő készülékszám mellett az app letöltések is bővülnek.

mobil-alkalmazások letöltésének száma világszerte
A mobil-alkalmazások letöltésének száma világszerte 2016 és 2019 között

Az Apple App Store 2020 júniusi kimutatása szerint a letöltések 50%-át a következő kategóriák teszik ki: Játékok (22%), Üzleti (10%), Oktatás (9%), Életmód (9%). Ebből körvonalazódik, hogy melyek a nyerő irányok. A lista végéről nézve érdekes kép rajzolódik ki: Hírek, Orvoslás, Fotó és Videó, Sport, Social Networking, Vásárlás, Zene, stb. Kb. 2-3%-ot jelent minden egyes kategória. Az alacsony részesedés magyarázható azzal, hogy a hírekre ott van a web; fotó és videó, zenelejátszó alapból jár a telefonra, előre telepítve.

Az digitális termékekre költött fogyasztói kiadásokat mutatja az alábbi grafikon. Ha az EMEA régiót nézzük (Europe, Middle-East, Africa), akkor az előre vetített bővülés több, mint 150%-os 2018-ról 2022-re.

mobil-alkalmazásokra vonatkozó fogyasztói költések világszerte
A mobil-alkalmazásokra vonatkozó fogyasztói kiadások világszerte 2017-ben, 2018-ban és 2022-ben, régiónként, milliárd USD-ben.

2018-ban a globális mobilalkalmazások bevétele több mint 365 milliárd USD volt. 2023-ban a mobil alkalmazások várhatóan több, mint 935 milliárd dollár bevételt generálnak fizetett letöltések és alkalmazáson belüli hirdetések révén.

mobil-alkalmazások bevétele világszerte
A mobil-alkalmazások bevétele 2014 és 2023 között világszerte, milliárd USD-ben.

A Freemium (Free + Premium) üzleti modell jól bevált a gyártóknak. Töltsd le ingyenesen, és ha már elkötelezett vagy, akkor apró költésekkel fizetek ki az egészet.

A fentiek alapján látható, hogy megfelelő bevételszerzési stratégiával lehet jelentősebb bevételeket generálni.

Ezeket számold bele egy mobil-app projektbe

Eldöntötted, hogy mégis belevágsz. Egy mobil-alkalmazás megrendelése a végszó!

A következő feladatokat kell számolni:

  • Projekt tervezése
  • Felhasználói élmény tervezése (UX design)
  • Felületek tervezése (UI design)
  • Megvalósítás, ami általában a legnagyobb részét teszik ki a munkának
  • Marketing feladatok: előtte, induláskor, utána
  • Az alkalmazások frissítése (legalább fél évente), hibajavítások

A fejlesztési idő, és ezáltal a költségek egy része egy jó kereszt-platformmal (cross-platform) csökkenthetőek. Nem mindegy, hogy kétszer kell egy alkalmazást megírni, vagy egyszer, és Androidra vagy iOS-re csak igazítani apróságokat.

Én a Flutter kereszt-platformot használom. Ennek előnyeiről itt írtam korábban. Létezik számos másik, ezeket előtte érdemes egyeztetni a megrendelővel, hogy milyen funkciókat vár. Vannak-e korlátai, amik nem, vagy csak körülményesen teljesíthetőek?

A költségek csak az egyik szempont

Előfordul, hogy egy cégnek egy mobil app egy névjegyet jelent. Ki lehet tenni, megmutatni, hogy ilyen is elérhető a portfóliójában. Ez egyfajta presztízs dolog.

Ne feledkezzünk meg a megkívánt funkciókról. Szeretnénk-e ismétlődő értesítéseket küldeni a felhasználóinknak, ami a marketingre fordított költségeinket javíthatja. Kell-e bele GPS funkció? Netán egy magával ragadó játékot álmodtunk meg? Fontos, hogy offline is bármikor elő tudja kapni a felhasználó?

Segítségképpen összegyűjtöttem egy listát, hogy ötleteket adjon, hogy miket kell mérlegelni a döntés előtt. A listában számos szempont szerepel, amiket érdemes átgondolni. A funkciólista alapján kirajzolódik, hogy mire lesz szükségünk: app vagy weblap?

Ellenörző-lista : Mikor van szükségem mobil app-ra?

Az email címed megadásával elfogadod az Adatkezelés tájékoztatót, és feliratkozol a hírleveleimre.

Az első hírlevélben a beállításait módosíthatod.
Kérem Az Ingyenes Ellenörző-listámat

Ide kérem a letöltési linket:

Remélhetőleg a cikk segített egy sikeres döntés előkészítésében, és spórolni a költségeken.

Ha maradt még kérdésed, akkor egyeztessünk egy ingyenes megbeszélést, ahol tovább pontosíthatod a céljaidat.

Borítókép: Allef Vinicius | Unsplash

TOP5 tipp a mobil-alkalmazás megrendelőnek
A mobil-alkalmazás vagy web alkalmazás közül melyik kell nekem?

mobil-alkalmazás és webalkalmazás a képernyőkön

A digitális világ megállíthatatlan fejlődést mutat. Kezdetben csupán kiváltságosoknak járt az azonnal üzenetküldés (e-mail őse a ’90-es évek elején), mára szinte már ódivatúnak tűnhet. Gyorsan változik, ahogyan kommunikálunk egymással. A weblapokkal az a helyzet, hogy ma már bárki tud indítani egy oldalt, viszont a mobil app-ok berobbantak az életünkbe és egyre nagyobb szeletet követelnek. Mobil-alkalmazás megrendelőként hogyan dönts el, mikor melyikre van szükséged? Ezt járom körül a cikkemben.

Fejlesztési idő

Hosszabb idővel kell számolni egy mobil alkalmazás megvalósításakor, szemben egy weboldal leprogramozásával. Az idő szoros kapcsolatban van a költségekkel, amire lejjebb visszatérek.

Egy mobil app-ot mindkét ismert platformra el kell készíteni. Ehhez általában kell a két platform ismerete, de ebben segítségünkre jön a Flutter keretrendszer. Írd meg egyszer a kódot, és fordítsd le natívan mindkét operációs rendszerre – ígérik a keretrendszer fejlesztői.

A felhasználói élmény

Ma már többnyire online vagyunk, észre sem vesszük, hogy használjuk. Egy honlap esetében alapvető, hogy kell neki kapcsolat, mert a szervertől kapja az adatokat. A szerver állítja elő az oldalakat. Alkalmazás esetén nem biztos, hogy le kell tölteni, mert már a készüléken van az adat.

Van, hogy gyorsan kellene egy infó, de Offline vagyunk. Ettől a mobil app még tud jól működni. Elérhető benne a címtárunk, a jegyzeteink, a kedvenc játékunk. Majd amikor ismét lesz internet, akkor szinkronizál a szerverrel. Ha a kapcsolat hiánya miatt a felhasználónak rossz élménye van, akkor nekünk natív megoldásban kell gondolkoznunk.

Emiatt elmondható, hogy a mobil alkalmazást bárhol lehet használni. Ezt várjuk tőle. Legyen ott a zsebemben az infó, mindig elérhetően.

Használjuk a telefon képességeit!

Amikor veszünk egy új készüléket, akkor többnyire az képességeit akarjuk kihasználni az alkalmazásainkban. A natív megoldások ezekhez hozzáférést kapnak, úgy mint: GPS helymeghatározás, ujjlenyomat olvasó, SMS-ek olvasása, Névjegyzék, NFC, a telefonon tárolt file-ok, stb.

Ezzel szemben a webes megoldással ezekről le kell mondanunk. Ha tudjuk nélkülözni őket, akkor ez nem egy fájó pont.

Biztonsági kérdés

Web alkalmazás a böngészőben fut, nem lehet mindig megvédeni a kódunkat. Egy weblapot bárki könnyedén publikálhat pár perc alatt, nincsen különösebb ellenőrzés.

Ezzel szemben a mobil-alkalmazás áruházak előszűrést végeznek, hogy minél kevesebb ártalmas app kerülhessen ki. 100%-os védelem ugyan nincsen, de nehezebb visszafejteni a működést és kihasználni az esetleges gyenge pontokat.

Ehhez párosul még, hogy az app telepítésekor a jogosultságokat is el kell fogadni, illetve később ki-, be kapcsolhatóak. Nagyobb kontrollunk van a beállításoknál.

A költségek hogy állnak?

Az online piacon nagy a versengés. Ki tud előbb kijönni egy új termékkel, koncepcióval, ötlettel? Mennyibe időbe telik, míg egy adott termék bemutatható?

A fentiek alapján ez a saját lehetőségeink kérdése, hogy mit választunk. Elfogadható élmény mellett egy gyors visszajelzés kell? Vagy már igazoltuk, hogy a megoldásra szüksége van a piacnak, és hajlandóak vagyunk egy kiváló élményért mélyebben a pénztárcánkba nyúlni?

A natív megoldásnál szokásos kérdésként merül fel: Android vagy iOS verziót akarunk? Lehetőleg mindkettőre. Itt adódna a válasz, hogy akkor biztosan egy kétszeres szorzóval kell számolnunk, dupla fejlesztési idő, csapat, stb. Nos, a jó hír, hogy erre vannak kiváló megoldások, és például a Flutter keretrendszerrel ez alapból jár. Mobil-alkalmazás megrendelőként ezekről jó, ha tudsz!

Fontos szem előtt tartani, hogy az a jó alkalmazás, amit sokan és visszatérően használnak.

Összegzés

A fenti felsorolásból leszűrhető, hogy nem minden áron van szükség egy natív mobilos megoldásra. Ha egy gyors prototípus kell csak, arra vannak más megoldások. Amennyiben egy responsive weboldalt már jól bejárattunk, és szeretik a felhasználóink, akkor megmaradhatunk annál.

Egy mobil app akkor elengedhetetlen, ha a mobil telefonunk nyújtotta lehetőségeket ki akarjuk aknázni. Ez elengedhetetlen, ha kamera vagy mikrofon kell. Értesítéseket akarunk küldeni a felhasználóinknak. A fotógalériához vagy a névjegyekhez kell a hozzáférés. Fontos számunkra, hogy tökéletes élményt nyújtson, akadozás-mentesen a programunk.

Ha mobil-alkalmazás megrendelőként egy új termékben gondolkozol, és gondolatébresztő után további kérdések merültek fel benned, akkor javaslom, hogy vedd fel velem a kapcsolatot. Egy ingyenes konzultáció alakalmával szakmai hozzáértéssel tudlak segíteni a döntésed meghozatalában.

Borítókép: Marvin Meyer / Unsplash

Így tervezz mobil alkalmazást 5 lépésben – 5. rész
Élesre állítás

Elérkeztünk a befejező részéhez az 5 részes “Így tervezz mobil alkalmazást 5 lépésben” cikksorozatomnak. Az előző részben az MVP kialakításáról volt szó. Ha lemaradtál róla, olvasd el, megéri! Tovább haladunk a végtermék legyártásában, és nem maradt más hátra, mint a kiadás.

Éles alkalmazás publikálása

Végre! Oly’ sokat vártál rá … számtalan álmatlan éjszaka … lemondás a hétvégi ágyban szundikálásról … de elkészült a nagy mű! Anyukád büszke lehet rád!

Persze álmodban sem gondoltad volna, hogy innentől kezdve pár hetente meg fogod ismételni roham tempóban az alkalmazás különböző verzióinak kiadását.

De térjünk vissza az első, felemelő pillanathoz! Kell egy ütős egysoros (one-liner) a Store leírásába. Ha ezen túljut a kedves felhasználó (nomeg a világ legszuperebb app címén), akkor egy kisebb esszében sorolod fel, hogy miért a te appod a legjobb a világon. Van már egy pár ezer hasonló a piactéren (de csak hasonló, mert a tiéd legalább az ikonban különbözik), de mégiscsak ezt éri meg a legjobban letölteni.

Kelleni fognak még képernyőképek, bár manapság már a 2 percnél nem hosszabb videók mennek. Rövid, tömör, lényegre törő.

Ja, hogy ingyenes az app? Miből lesz itt bevétel? Még jó, hogy beintegráltál reklám bannereket és videókat, amivel a felhasználóidat ki fogod kergetni a világból.

Sajnos statisztikai alapon a következő user interakciókat kell túlélnie egy appnak:

  1. a Storeban a keresési találatban elől kell végezni, hogy észrevegyék
  2. kellően jól rate-eltnek kell lennie (legalább 4)
  3. érdekes a címe (ASO-zott)
  4. ha a te appod a nyertes idáig, akkor remélhetőleg nem lett túl nagy méretű a telepítője, és lesz ideje kivárni, amíg letöltődik és települ
  5. nos, ha nem, akkor lehet, hogy a telepítés már a háttérfolyamatokban éri a kedves felhasználót
  6. pár nap múlva észreveszi, hogy ő bizony tényleg telepítette az kicsikédet
  7. vagy törli azonnal, mert kiderült, hogy ez foglalta el a tárhelyet a telóján, és emiatt nem ment ez az utolsó macskás fotó a chatben
  8. vagy megnyitja, és nem omlik össze azonnal. Ez mindenképpen jó ómennek bizonyul
  9. lehet, hogy összesen 2x fogja megnyitni: először és utoljára. Az alkalmazások sorsa ez. Kell gyorsan valami, letöltjük és már dobjuk is el. Hacsak!

Hacsak, az elejétől kezdve nem egy szolgáltatást céloztál, amihez mellesleg van egy app is. Enélkül nem tudja igénybe venni az szolgáltatásodat. Lehet, hogy egy honlap is elegendő rá, de egy mobil app az mégiscsak egy “Mobil App”. Egy honlappal összehasonlítva más az érzet, amikor nyomogatod. Ez kétségtelen.

A végére értem az egyes szempontoknak. Van számos buktató benne, de ha ezekben segítségre van szükséged, beszélgessünk a te ötletedről.

Végszónak pedig álljon itt az ismert képlet:

Ötlet Megvalósítás = Termék

Köszönöm, hogy kitartottál, és követted egy termék útját az ötlettől a késztermékig.

Szeretnéd megpróbálni, de nem tudod, hogy hogyan fogj neki? Szükséged van friss ötletekre, nézőpontokra? Jó lenne egy szakmabelivel átbeszélni a részleteket? Keress meg bátran, és beszélgessünk a dédelgetett álmodról, hogy mielőbb megvalósult termék lehessen belőle.

Ha most nem érdekes számodra egy beszélgetés, de követnéd az írásaimat, akkor iratkozz fel a hírlevelemre, hogy értesülj az új részekről. Kíváncsi vagyok a véleményedre, írd meg nekem!

Így tervezz mobil alkalmazást 5 lépésben – 4. rész
MVP létrehozása

Ez az 5 részes “Így tervezz mobil alkalmazást 5 lépésben” cikksorozatom 4. része. Az előző részben az UI tervezésről volt szó. Ebben a részben a legkorábban bemutatható termék-kezdemény létrehozásáról fogunk beszélgetni.

MVP létrehozása

A Minimal Valuable Product (mostanában az MLP = Minimal Lovable Product is felütötte a fejét) egy olyan kis termék kezdemény, ami már megáll a saját lábán. Egy-két dolgot tud még csak, de azt biztosan. Azt nyújtja, amit ígér. Fontos szem előtt tartani a “funkció a forma fölött” elvet. Nem baj, ha kicsit rusnya, de működjön. Természetesen vannak a használhatóságra negatívan ható tervezési gyengeségek, de ezeket most nem érintem.

Gondolj arra, hogy a szabó sem a végén adja oda a kész öltönyt, amikor már nem lehet rajta módosítani. Elhív egy próbára, amikor már össze van fércelve nagyjából az anyag, de még lehet módosítani rajta. Eleve neked is mások lesznek az elvárásaid egy ilyen félkész ruhadarabbal kapcsolatban. Még a kréta nyoma látható, ami a szabásból visszamaradt. Kilógnak cérnaszálak, de ezektől fejben el tudsz vonatkoztatni. Kényelmes lesz? Az a szín, amire gondoltam? A kivágás akkora lesz az elején, ahogyan megálmodtam?

Jó, a lényeg érthető. Kis lépésekből építjük fel az induló termékünket. Pár hetes ciklusokban (iterációkban) finomítjuk, teszteltetjük különféle csoportokkal. Milyen hosszú legyen egy iteráció? Nos, itt eltérnek a vélemények, de érdemes heti bontásban gondolkozni. Adódik ebből a legrövidebb az 1 hét legyen, de ne haladja meg az 4 hetet. Ez még belátható funkciómennyiség, amit lehet követni. Ez nagyban függ a saját, vagy a csapat ritmusától. Én a 2 heti verziózást követem, ami eddig bevált. Így kellően pörgős, de azért van idő szusszanásra. Ebbe még az is belefér, ha közben egy patch-et (hirtelen foltozást) kell kiadni.

Tesztelés, visszajelzés

Az MVP-t oda lehet adni ismerősöknek, barátoknak, családnak, hogy vegyék kézbe. Lehet szervezni bemutató eseményeket, interjúkat, ahol fontos visszajelzéseket gyűjthetsz be. Ha meg tudod oldani, vedd fel videóra a felhasználó első találkozását a termékeddel. Sokat tanulhatsz belőle. Írd fel a kérdéseket. Meg fogod látni, hogy ebből ki fog rajzolódni egy mintázat.

Hány fővel kell ezt elvégeztetni? A szakmában az átlag a 3-7 db interjú már elégségesnek szokott mutatkozni. Ekkor kiderülnek a fő hibák, ami számodra nem volt egyértelmű a fejlesztés során. Ha tudod, válassz a célközönségedből minél változatosabb személyiségeket, így átfogóan lefeded a leendő piacodat. Összegezve a találatokat, ezek egyben meghatározzák a következő időszak fejlesztési tervét is. Ez már egy, a valós felhasználói közösségtől jövő visszajelzés, ami innentől nem találgatásokra épülít (empírikus módszer).

A következő, egyben befejező részben az alkalmazás publikálása lesz terítéken. Ha tetszett ez a rész, iratkozz fel a hírlevélre, hogy értesülj az új részekről. Kíváncsi vagyok a véleményedre, írd meg nekem!

Így tervezz mobil alkalmazást 5 lépésben – 3. rész
Felületek tervezése

Ez az 5 részes “Így tervezz mobil alkalmazást 5 lépésben” cikksorozatom 3. része. Az előző részben az ötlet validálásáról volt szó. Következzék a felhasználói felületek (UI) tervezése.

Mostanra eljutottál oda, hogy pontosan tudod, hogy kinek, és mit szeretnél előállítani. Az öteltedet bemutattad másoknak is. Ha nem csak a családi-baráti körben, akkor hivatalosan is validáltad! Ez az! Most már nincs más hátra, mint egy szerethető digitális terméket formálj belőle.

Ez egyszerűnek hangzik, hiszen annyi eszköz érhető el ehhez, hogy pillanatok alatt ki lehet dobni a vázlatot, ha nem tetszik és újat csinálni helyette. Ez mondjuk a nehézsége is egyben, mert honnan fogod tudni, hogy mikor kellően jó?

A játékosítás

Ez most hogyan jön ide, kérdezhetnéd? Nem játékot akarok készíteni, csupán egy használható terméket. Nos, nem is erről van szó. A játékosítás, vagy más néven gamification nem túl régi fogalom. Ez Pusztai Ádám, hazai játékosítási szakértő szavai után szabadon kb. így hangzik: “Játékos elemek alkalmazása, alapvetően nem játék környezetben.” Na, ezzel nem léptünk előrébb. Akkor mi is ez? Nagyjából arról van szó, hogy a tervezés során odafigyelünk a felhasználóra, hogy benne tartsuk egy folyamatban, mégha nem is kellően izgalmas, pl. egy villany-számla befizetése.

Ennek egész tudománya van, ezt most nem fogom részletezni, de olyanokra gondoljuk, hogy:

  • a felhasználó tudja, hogy melyik képernyőn van, és innen hogyan tud továbblépni
  • mindig kap visszajelzést egy action után: gomb színe változik; felugró ablakban infó, stb.
  • tudja, hogy hol tart a folyamatban (haladás jelző: 3. oldalon áll az 5-ből, tehát még 2-t kell kitöltenie, pl. egy formon)
  • valamilyen szükségletét elégíti ki; problémáját oldja meg; veszteségét minimalizálja; birtokolhat valamit; bátorítást kap, stb.

Erről majd bővebben írok egy másik bejegyzésemben. Ennyi szakmai felkészítés után jöjjön a lényeg, a csillogó-villogó felületünk, amivel elkápráztatjuk a felhasználónkat.

Felületek tervezése

A tervezés miatt nem kell feltétlenül megtanulni egy új eszközt. Ha ez sok időbe, energiádba kerülne, vesd el ezt az irányt! Sokkal többre mész azzal, ha rövid idő alatt láthatóvá teszed a fő képernyőket. Emelj ki egyes részleteket, amiket fontosnak tartasz. Játszadozz a logóval, az elrendezésekkel!

Léteznek erre kiváló eszközök. Nem is gondolnád, hogy a jól bevált kockás (vagy sima) füzet bőven megteszi az elején. Egy marék színes filccel/tollal csodákra vagy képes. Ez a legtermészetesebb, ami kéznél van. Bátorítalak rá, hogy az első pár tervet kézzel rajzold meg. Utána jó emlék lesz visszanézni ezeket, amikor már működik a termék.

Kezdésként fogod a telefonodat, ráteszed a papírra, körberajzolod, és már meg is van az 1:1 méretarányos sablonod. Már csak a képernyőt kell belerajzolni. Ebben az a jó, hogy ezzel a módszerrel könnyedén le tudsz gyártani 10-20-100 képernyőt rövid idő alatt. Egyszerű, igaz!?

Az a jó eszköz, amit könnyedén és szívesen használsz.

Na jó, te mégis tech srác vagy, akkor ide valami nagyágyú kell. Ott van a Figma, vagy az InVision ingyenesen is kiválóan használható online szerkesztők. Csoportos együttműködésre nagyszerűen használatóak. A tervek megoszthatóak egymással, csakúgy mint egy OneDrive-os doksi. Egy linken keresztül akár telefonon is kipróbálhatóak. Meglepően gazdag élményt nyújtva.

Ha Mac-es vagy, akkor a Sketch havi $9-ért már a tiéd lehet. Az Apple híres a designereknek készült eszközeiről, és ez is egy kiváló eszköz.

Az Axure egy másik fizetős program, ami megéri az árát. Kifejezetten prototypeing-ra van, drótvázak tervezésére.

A klasszikus Adobe XD toolja biztosan jóval több funkcióval érkezik, mint amire valaha is szükséged lesz. Szép áttűnések, responzív felületek, animációk, interakciók hozhatók létre vele. Érdemes kipróbálni.

Szándékosan hagytam a végére az Android Studio-ba (AS) jól integrálódó Flutter UI kitet. Ha van affinitásod a kódoláshoz (remélhetőleg ez így van), akkor ajánlom ezt a kombinációt is. A Flutter nem csak AS-ban, hanem a Visual Studio Code (VS Code) programban is kiváló támogatást kap néhány kiegészítő telepítésével. Amennyiben ebben az irányban indulsz el, akkor lényegében az alkalmazásod fele már megvan. Legalábbis a felületek, és néhány kezdetleges interakció az indulásnak. Ez aztán tovább fejleszthető, és a teljes alkalmazás lefejlesztésére jó. Ráadásként egyből Android-ra és iOS-re. Az optimális működésről pedig a keretrendszer gondolkodik. Neked csak a fantáziádra kell hagyatkozni.

A következő részben az MVP-vel folytatjuk. Ha tetszett ez a rész, iratkozz fel a hírlevélre, hogy értesülj az új részekről. Kíváncsi vagyok a véleményedre, írd meg nekem!