ui/ux

UICode Low-code: egy Figma plugin, ami Flutter kódot generál
Terjedőben a Low-code megoldások

Viktor
Tetszetős szlogen: mindenki azt végezze, amihez ért!

A UICode egy olyan low-code Figma plugin, ami képes elég jó Flutter kódot generálni. A mai UI tervezők a Figma online eszközt használják, ami kitűnő prototípus építésre, wireframe építésre. Tovább finomítva, egy bemutatható alkalmazást adhatunk a célcsoportunk kezébe. A UICode ezen túlment, és a népszerű Flutter keretrendszerhez készített egy plugin-t, amivel már kódot is tudunk generálni. Az, hogy mire elegendő, megnéztem.

A Flutter 2.0 alig pár hete, március 3-án debütált. Nagyon várta a közösség, hiszen olyan fantasztikus funkciókat kapott, hogy a Web végre stable, azaz éles környezetben is bevethető. Ezen kívül 3 desktop OS-re is megkapta ugyan ezt a státuszt: Linux, Windows, macOS.

Előkészületek

Nem célom most a Figma lehetőségeit taglalni. Ezeket jól ismerjük. Én személy szerint nagyon szeretem, mert gyorsan lehet vele haladni. Kitűnő intuitív funkcionalitásával az ingyenes verzió bőven kielégíti a szükségleteimet. De a havi 12 USD sem drága érte, ha valaki komolyan gondolja.

Elkészítettem az alábbi két egyszerű képernyőt, hogy ezen teszteljem a lehetőségeket. Szándékosan nem vittem túlzásba, hiszen alap dolgokat akartam megnézni a UICode low-code lehetőségeivel.

Figma egyszerű prototípus
Két egyszerű képernyő a Figmában

Mit tud a UICode Low-code plugin-ja?

Telepítsük a UICode low-code plugin-t. Ez innen telepíthető a Figma-ba. Nekem Google Chrome-ban működött jól, Firefox-ban például meg sem szólalt.

Ezután, hogy egy valós alkalmazás érzetét keltsem, beállítottam néhány kattintható gombot, és áttűnést tettem hozzá.

Figma prototípus bedrótozása
Navigáció a képernyők között

Ezután a Figmában a Menü -> Plugins -> UICode pont alatt érhető el, és nyílik meg ez a képernyő. Először rákérdez, hogy a tervünkből melyik képernyőket szeretnénk használni. Ezeket bejelölve néhány automatikus csoportosítást elvégez.

A UI Elements fülön kiválasztva a Frame 1-et megtalálja a szövegeket, és a gombokat. A gombokat az alapján sorolja oda, hogy van-e interakció vele. De ha nem ismerné fel, ez előfordul, akkor az Edit button-nal tudtam hozzáadni másikat.

Az Assets-ben a képeket tudjuk belistáztatni vele. Általában elsőre megtalálja őket.

UICode low-code beállítások
A UICode low-code plugin elvégzi a rendszerezést helyettünk

Ha ezekkel megvagyunk, akkor jöhet a kódgenerálás! A Frames tabon kattintsunk a Download project gombra. Elkészíti az állományokat. Még egyszer a Download gombra kell kattintani, hogy le is töltse. Nem mellesleg becslést ad, hogy hány órát spóroltunk meg ezzel. Mégha nem is pontos, de minden esetre elgondolkoztató. Nem is beszélve a sokkal összetettebb kinézeteknél.

UICode letöltés
Projekt file-ok elkészítése és letöltése

Egy ZIP állományt kapunk, amit csak bepattintunk az Android Studióba, és már indíthatjuk is a build-et. Mivel a Web már elérhető, ezért én inkább a Chrome-ban néztem meg.

A kész munka
A megtervezett kinézetet jól visszaadja

A végeredmény

Átnézve a kódot, felemás az érzetem. Sajnos Stack és Padding elemekkel operál. Ez nem túl szerencsés a különböző képernyőméretekre nézve. Konkrét pixelekben adja meg a szélességeket, távolságokat a képernyő tetejétől.

Jobban megnézve a használt csomagokat, a reszponzív méretezéshez a Flutter ScreenUtil csomagot használja. Ez viszont már egy jobb megoldásnak mondható. A csomag készítői nem mondanak kevesebbet, minthogy elfogadható kinézetet (“resonable layout”) készít a képernyőnkhöz és a betűkhöz. Valóban, amikor átméretezésre kerül a képernyő, vele együtt a kinézet is elfogadható marad. Természetesen akkor, ha az eredeti képernyő arányok közelében maradunk.

A keletkezett kód nem kellően struktúrált. Felismeri a képernyőket, és megfelelően elnevezi. Viszont az egyes komponenseket ömlesztve hozza létre a kódban. (Láttam ennél sokkal rosszabb megoldást az Adobe XD-ben, ahol minden SVG volt. A kód emiatt kellőképpen átláthatatlan.)

A kérdés, hogy ez használható-e kiindulásként? Úgy gondolom, hogy egy próbát megér, bár talán nem ebben a verziójában. Kezdésnek biztató, de a Flutter pont attól nagyon jó, hogy viszonylag komplex felületeket (widget) gyorsan lehet létrehozni benne.

Letölthető példák:

UICode_sample1_webLetöltés

A web-es példát kicsomagolva, egy Python webszerveren könnyedén futtatható böngészőben:

Python 2 — python -m SimpleHTTPServer 8000

Python 3 — python -m http.server 8000

Böngészőben a http://localhost:8000 címen tudjuk megnyitni.

UICode_sample1Letöltés

Konklúzió

A UICode egy low-code megoldást hozott, de még nem tökéletes.

Amennyiben sikerül megoldani, hogy:

  • alap architekturális megoldásokat bevezet az elemek rendszerezésére
  • a gombokat, összetett komponenseket (Component) ki tudja renderelni
  • színkódokat kiszervezi
  • a lehető legújabb verziójú csomagokat (package) és keretrendszert használják

ez egy jó kezdeményezés lesz.

A produktivitást nagyban növeli, ha egy designer elkészített művészi megoldását a lehető leghűbben tovább tudja folytatni egy fejlesztő. Nem kell kidobni vagy újrakezdeni a munkát, hanem ahol az egyikük befejezte, a másik onnan folytatja.

Ha további kérdésed lenne erről az eszközről, vagy magáról a mobil app fejlesztésről, a kapcsolati oldalamon vagy LinkedIN-en elérhető vagyok.

Érdekelnek a lehetőségek

Ha tetszett az írásom, ajánlom figyelmedbe a további érdekességeket is:

2021 csodafegyvere: gamification avagy játékosítás

Viktor
A Candy Land gamification, más néven játékosítás megoldásra egy jó példa.
forrás: Candy Land – Google Play Store

Az elmúlt év eseményei új hozzáállást, új szokásokat honosított meg sokunknál. Új hobbijaink lettek a szobai létre kárhoztatva. Kimutatták kutatások, hogy nagyban nőtt a mobiltelefon nyomkodásával töltött időnk. Természetesen a játékok taroltak, a videóhívás app-ok mellett is. A cikkemben ez előbbit veszem górcső alá, hogy mivel érték el ezt a játékkészítők. Nagy titkot nem árulok el, ha azt mondom: játékosítás, vagy nemzetközi nevén gamification.

Egy korábbi cikkemben feldolgoztam ezt, bár a másik oldalról elkezdve. Abban a cikkemben arról írtam, hogy

“Játékos elemek alkalmazása, alapvetően nem játék környezetben.”

A kutatómunka

Célirányosan keresgéltem a Play Store-on a játékok között, hogy tapasztalatot gyűjtsek az un. idle/casual click típusú játékok körében, hogy hogyan alkalmazzák a játékosítás, avagy gamification elemeit. Belebotlottam a Candy Land nevű játékba. A “candy” kulcsszóra kb. 250 találat jött fel, azonban engem megfogott a kedves megjelenése. Rendben, valahol el kellett kezdenem a sok mézes-mázas játék közül. Telepítettem. Szigorúan szakmai szempontokat figyelemben véve 🙂

Az app 45 Mb-os letöltési mérete kellemes meglepetés volt. Annak tükrében, hogy amikor elindítottam, mit kaptam cserébe.

Grafika és zene

Egy fülbemászó zenével indulunk. Egy nagy gomb van a közepén, el sem tudjuk téveszteni, hogy mi legyen a következő lépés. Itt álljunk meg egy gondolat erejéig. A képernyőn megkapom egyből a 3 kérdésemre a válaszomat:

  1. Hol járok?
  2. Mit lehet csinálni?
  3. Hogyan tudok tovább haladni?

Ez egy szűrő, hogy mennyire megnyerő az egész számomra. Természetesen tovább léptem, hiszen játszani akartam.

Egyből egy elemekkel tűzdelt térkép jött velem szembe. A szokásos részletek jól azonosíthatóak, ha megvizsgáljuk őket:

  • hol vagyok én? Avatár a képernyő alján
  • földrészek vannak, ahogy feljebb tekerek a térképen. Már alig várom, hogy elindulhassak. Vajon mi lehet arra? (várakozás, korlátozás érzése)
  • A képernyő tetején feltűnik a “szívecske”, ami az életerőmet mutatja. A + jel utal valami feltölthetőségre.
  • A sárga “coin”-ok pedig a Candy Land valutámat mutatja. Ebből lehet életerőt, előrehaladást, stb. vásárolni. Rábökve egyből bejön a Coin Shop, ahol vehetünk is ilyet.
A Candy Land játékban fontos a térkép
Központi eleme a térkép

Játékmenet

A Candy Land játékmenete igazán ért a játékosítás / gamification megoldásaihoz.

Nem maradtam egyedül, megkaptam minden segítséget, ha elakadnék. Most már van célom: Gyűjtsem össze a pontokat! Ennél világosabb cél nem is lebeghetne a szemem előtt. Kezdjük is!

Kell egy cél
Extráink a játék közben

A készletek szűkösek, takarékoskodni kell vele. Ezt a Moves (lépések) jelzi. Ha elfogy, vége a körnek. Jobbra fent mutatja az összegyűjtendő pontokat. Ezt kell elérni. Észrevettem magamon, hogy elkezdtem logikázni, hogy hogyan tudnám mielőbb összeszedni. Nem volt elégséges az egyszerű “lehúzom az ujjamat, és kész” stratégia.

A Candy Land játéktere
A jól átlátható játéktér

A fenti képen van pár elem, amiket fokozatosan kaptam meg. Nem egyszerre zúdította rám a lehetőségeket. Először megtanított egy kis lépést, aztán nehezített. Ha már ez is jól ment, bedobott egy új elemet.

Ez is fontos ismérve a játékosításnak. Legyen gyors sikerélmény (quick win), érezzem úgy, hogy kapok jutalmat. Ezek az apró vállonveregetések elmélyítik a bizalmat. Apropó, sikerélmény. Az elején megkaptam a segítséget azáltal, hogy villogtak azok a cukorkák, amikre ha rányomtam, biztosan meglett a 3 egysorban. Ez a későbbiekben eltűnik, de addigra már az ujjaimban van az összes kombináció.

A képernyő alján feltűnnek az extrák, amiket bevethettem (miután feloldottam őket). Ez a szabad választás látszatát keltik. Ezek olyan trükkös elemek, amik nem igazi választások (álválasztások), tehát a játék szempontjából nem ad kiemelkedő előnyt, viszont pszichológiailag úgy érzem, hogy mégis rajtam múlott.

A pályát sikeresen teljesítve egy szusszanásnyi időre értékeljük, hogy mennyire ügyesek voltunk. Mennyi pontot szereztünk (nincsen jelentősége a játék során), megkaptunk a kitűzőinket, mehetünk a következő szintre.

Szép munka a pálya végén
Szép munka!

Megvásárolható cukorkák

Megvehető az előrehaladás
Megvásárolhatjuk a továbbhaladásunkat

Ezeknek a típusú játékoknak fontos eleme, hogy a haladásunkat tudjuk gyorsítani. Vagy sokat játszunk, vagy megvesszük a coin-t. Ezeket beszerezhetjük, ha megnézünk egy videót. Ha sok van belőle, akkor most elkölthetjük.

Próbáljuk újra
Vagy tovább folytatjuk a gyűjtögetést

Egyből melléteszem, hogy ennek Ft-ban is kifejezhető értéke van. A játéknak egy fontos része ezek beszerzése. Ha kellően messzire jutottunk, biztosan nem akarjuk már otthagyni a további pályákat. Ez az elveszett haszon elvén alapuló megoldás. Ezt is kiválóan alkalmazza.

Látható, hogy egy videó mégnézéséért cserébe mennyi coin-t kapunk.

Fontos része a pénzen megvásárolható kiegészítők
A bolt

Nos, a játékot ugyan nem pörgettem ki a hétvége alatt, hiszen nagyon sok pályája van, viszont minden szinten kapok új elemeket. Folyamatosan benntart a folyamatban azáltal, hogy a menetek pörgősek, gyorsak. Van visszacsatolás. A tárgyak vásárlásával, vagy átváltásával azt az érzetet kelti, hogy fejlődöm.

Candy Land – Free puzzle game

Ha játszanál egy jót a KingIT Solutions játékával, akkor a Play Store-on megtalálod.

Én most zúztam nyomkodni!

Az új élmény: Adaptive eXperience (AX) (2021)
Új év, új kihívások 2021-re

Viktor
Az Adaptive Experience összekapcsolódása a fizikai és virtuális térben
forrás: CX Insight / Unspalsh.com

Az elmúlt 2020-as év számos új alkalmazást adott nekünk, amiket meg kellett tanulnunk. Voltak olyanok, amik a semmiből tűntek fel. Mások letűntek, és vesztesként kikoptak a napi használatból. A számos új felület megtanított alkalmazkodni, naponta újat tanulni. Belemerülni a digitális világba. Olyanoknak is, akik eddig viszolyogtak az okos eszközöktől. Vajon az Adaptive experience segíthet ezen?

Hangzatos neveket hozott az elmúlt 10-15 év, amikor sorra jelentek meg az okos képernyők. Olyan felületeket kellett készíteniük a designereknek, amik intuitívak. Ezen a téren sokat köszönhetünk az Apple-nek, ahol mindig is fontos volt a jó kezelhetőség. Mára etalonnak számítanak az iránymutatásaik. Nyugodt szívvel támaszkodhatunk a vizuális megjelenítési rendszereikre. A színek, formák, mozgások kognitív hatásaival sokat kísérleteztek, hogy tökéletes élményt nyújtsanak.

Megismertünk foglamakat UX (User Experience), CX (Customer Experience), ami mind azt szolgálta, hogy a felhasználó minél jobban része legyen egy termékenek, és a termék szolgálja ki az igényeit. Minél egyszerűbb módon. Ez jóval korábbra nyúlik vissza, a II. világháború időszakára.

Vannevar Bush az 1930-es években a “memex” ötletével állt elő, ami tuljadnoképpen egy személyes könyvtár (tároló) víziója volt. 1945-ös publikációja utána azonban hamar felismerte, hogy az emberi elme nehezen fog megbírkózni a rendelkezésre álló elképesztő méretű adatmennyiséggel. Élete során azon dolgozott, hogy az ember-gép minél természetesebb harmóniáját, és együttműködését megalkossa. Egy ilyen következmény volt az egér.

Mi az Adaptive experience?

A termékek, felületek tervezői sok ezer munkaórát töltenek el vele, hogy felhasználóbaráttá, szerethetővé tegyék azt a majdani felhasználóknak. A szoftverek előnyben vannak a fizikai társaikhoz képest, hiszen aránylag könnyen módosíthatóak. Fizikai terméknél jó példa a személyre szabhatóságnak, amikor pl. az autó színét mi válaszhatjuk ki. A kárpitozást. Milyen extrák legyenek az autónkban. Úgy érezhetjük, hogy van beleszólásunk. Valamelyest egyedivé tehetjük. Ezért még fizetünk is többletet. Tehát igény van a testreszabhatóságra.

A szoftverek terén ez valamelyes könnyebb. A Google keresőnk megtanulja a témáinkat, és azokat helyezi előbbre a találati listában. Olyan cikkeket kapunk, ami az érdeklődési körünknek megfelel. A chat alkalmazásunk háttérszínét beállíthatjuk.
Ezek alig észrevehető apróságok, de mégis megszemélyesítik az igényeinket.

Az kevésbé látható trend, hogy egy alkalmazás felületét szabhatnám a magam igényeire. Annyi felülettel kell már kapcsolatba lépnünk. Csak beszélgetésre van 5-6 db, amit használok magam is. Naptárak. Képszerkesztők, stb.


Eljön-e az idő, hogy az engem érdeklő funkciókat tegyem fel egy felületre, a többit pedig rejtsem el?
Az alkalmazások között váltva ugyan ott találjam meg a kedvenc funkciómat, amit minden alkalmazásban ugyan onnan érek el?
Át tudom-e mozgatni az ikonokat? Az ismerőseim listáját magam rendezhetem, hogy mit lássak?


Ezek ugyan ellent mondanak a tervezők terveinek, hogy egyedi felületet készítsenek. Mégis, felismerhető legyen a funkció, egyértelmű legyen.

A funkció szempontú megközelítés

Tovább boncolgatva az Adaptive experience kérdését, az ilyen újításnak a célját kell megvizsgálni. Mit ad ez hozzá az élményhez? Egyszerűsít? Könnyít bármit is? A Virtual Reality vagy Augmented Reality kifejezetten egy ilyen terület.

Van-e igény olyan eszközre, ahova be van kötve az összes pl. chat alkalmazás. Én nem feltétlenül azt akarom megmondani, hogy melyikkel érem el az ismerősömet, csak hogy küldjek neki üzenetet. Lehet-e valamilyen szempont alapján a legrelevánsabb csatornán elküldeni?

Vagy pl. a képeim szerkesztése. Minden app egy kicsit egyedi, mindegyik másban erős. Tudom-e úgy használni ezeket a funkciókat, hogy összesíti egy felületen a beállításokat az összes telepített app közül? Hogy melyik tud vicces szemüveget rátenni, vagy a hátterét megváltoztatni, nem lényeges. Valamelyik végezze el nekem.

Az, hogy egy ilyen gondolkozás elindul-e, nem tudom. A 2021-es év viszont további kihívásokat fog tartogatni számunkra, hogy a virtuális világban elmerülve hogyan fogunk tudni könnyedén eligazodni. Nem a húszonéves korosztályról van csak szó. Gondolni kell a korosztályok skálájának másik végére is. Ne elidegenedés, hanem egyre jobb bevonásuk legyen a kitűzött cél. Létezik erre W3C ajánlás, amit érdemes lesz 2021 során egyre szorosabban követni és beépíteni, hiszen új felhasználókat nyerhetünk meg általa.

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

Viktor
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

Viktor
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

Viktor
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

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

Viktor

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!

Feliratkozom a hírlevélre

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

Viktor

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!

Feliratkozom a hírlevélre

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

Viktor

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!

Feliratkozom a hírlevélre

Így tervezz mobil alkalmazást 5 lépésben – 2. rész
Validálás

Viktor

Ez az 5 részes “Így tervezz mobil alkalmazást 5 lépésben” cikksorozatom 2. része. Az első részben az ötlet kitalálásáról volt szó. Következzék az ötletünk validálása.

Validálás

Az előbbi lépés, amikor még csak ötletelünk, sokszor elegendő lehet, hogy kiderüljön, működne-e? A leírt terveket, rajzokat meg tudjuk mutatni egy pár ismerősünknek, és fontos visszajelzéseket kaphatunk tőlük. Persze nem árt odafigyelni, hogy kitől kapjuk a visszajelzést.

A 3F (Friends-Family-Fools) véleménye könnyen téves útra vihet téged. Ezt hosszasan elemzi Rob Fitzpatrick: Anyu teszt (Mom test) című könyvében. A lényeg, hogy a közeli hozzátartozóidtól, barátaidtól biztosan nem fogod megkapni a valós véleményeket, hiszen nem akarnak majd letörni és elvenni a kedvedet. (Ki merne ilyet felvállalni manapság?) A könyv alapján a lényeg, amit mond, hogy ne jövőbeli ígéretekre, hanem a múltban megtörtént eseményekre alapozzunk. Mit jelent ez pontosan?

Párbeszéd Anyukád és közted (tévút):

Te: Szia Anya!
Anyu: Helló Kicsim!
Te: Képzeld, festettem egy nagyon szép képet. Mit szólsz hozzá, te megvennéd tőlem?
Anya: Húú, de gyönyörű! Persze, hogy fizetnék érte. Ezzel még sokra viheted. – és el…
Te: Köszi, tudtam, hogy tetszeni fog.

Nos, ígérni bárki tud. Nyilvánvaló, hogy nem akart téged megbántani, hiszen bátorítani szeretne. Így nem megy bele abba a játékba, hogy letörjön az elején. Érezhető, hogy ebből nem lesznek milliós darabszámú eladásaid.

Párbeszéd Anyukád és közted (anyu-teszt):

Te: Szia Anya!
Anyu: Helló Kicsim!
Te: Képzeld, festettem egy nagyon szép képet. Mit szólsz hozzá?
Anya: Húú, de gyönyörű! Kinek festetted?
Te: Igazából magamnak. Te szoktál hasonló képeket vásárolni? Bár igaz, nem látok hasonlót sem a házunkban.
Anya: Nem igazán. Újszerű ez a stílus tőled, de ilyet biztosan nem tennék ki a lakásba.
Te: Mi az, ami nem tetszik benne?
Anya: Az például, hogy …
Te: Köszi, tudtam, számíthatok a véleményedre.

Itt látható, hogy egészen másképpen alakult a beszélgetés. Az anya sem érezte, hogy feltétlenül áradoznia kellene a festményről. Egy objektívebb síkra terelődött a beszélgetés, amiben kiderült az igazság a munkával kapcsolatban. Siker!

Ha elfogytak a 3F klub tagjai, akkor hogyan lehet még további infókhoz jutni? Olvass fórumokat, blogokat az adott témában. Regisztrálj be egy oldalra, csatlakozz egy csoporthoz, és ott kérdezz. Aztán csak figyelj, hogy milyen válaszok érkeznek. Ez már jó kiinduló lehet, és tovább finomíthatod az ötletedet. Ez lehetőséget ad arra is, hogy egy részpiacra (niche, ejtsd: nís) szükítsd a te megoldásodat, mert te nem akarod MINDENKI problémáját megoldani. Te a “24-26 éves, pályájukat most kezdő egyetemet végzett, férfi, városban élő, programozóknak akarsz mobil fejlesztési kurzust adni.”. Ez csak egy példa, de látható, hogy mennyire specifikusan fogalmaztam meg.

Ezek persze csak néhány példája annak, ahogyan tudod validálni. Az interjúztatás (f-2-f, O3), a kérdőív kitöltetése, a mobil app marketeken a review-k átolvasása tovább színesítik a képet.

A begyűjtött válaszok alapján körvonalazhatod magadnak azokat a személy-csoportokat (perszóna), akikre tudsz vizualizálni, miközben kidolgozod az apró részleteket, vagy amikor a post-okat írod, vagy a hirdetéseket szövegezed.

A következő részben a felületekkel 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.

Feliratkozom a hírlevélre