Complete Guide to Creating Mobile App Wireframe

A becsült idő: 1-2 óra. Javaslom, hogy ezt a gyakorlatot a legfontosabb érdekelt felekkel együtt végezzük el.

Kezdjük azzal a feltevéssel, hogy Önt egy mobilalkalmazás létrehozásával bízták meg. Az első dolog, amit meg kell kérdeznie: “Milyen problémát oldok meg, és kinek oldom meg?”. Az erre az összetett kérdésre adott válaszok fogják megalapozni a tervezését, mert olyan meglátásokat nyújtanak, amelyek a tervei jellemzőit és funkcióit irányíthatják. Ezek a válaszok minden bizonnyal segítenek majd annak eldöntésében is, hogy mi lesz a tervezésed MVP-je (minimum életképes termék).

Ezek például előfordulhat, hogy a termék ütemtervében sok funkció szerepel, de az alkalmazás első verziójának sikeres elindításához csak a lényeges funkciókra kell koncentrálnod. Kezdheti azzal a kérdéssel, hogy “Milyen funkciókat és funkciókat kell létrehoznunk ahhoz, hogy a célközönségünk el tudja végezni a célját/feladatát?”

A kérdés megválaszolásához létrehozhat egy felhasználói folyamot az elsődleges felhasználó “boldog útja” alapján (az összes szélsőséges esetre később összpontosíthat). Javaslom, hogy használjon egy táblát, amelyre először írja fel a felhasználó összes kulcsfontosságú lépését. Amint ezeket a kulcsfontosságú lépéseket leírta, elkezdheti elkészíteni a lépések magas szintű vázlatait. Ez segít meghatározni, hogy a felhasználónak milyen affordanciákra van szüksége az egyes lépéseknél, és távol tartja a scope creep-et.

Megjegyzés: Próbáljon megálljt parancsolni a vázlatkészítésnek anélkül, hogy előbb leírná a felhasználói folyamatot. Az elménk nagyon kreatívvá válhat és letérhet a helyes útról, ha rögtön a vázlatkészítésbe vetjük magunkat.

Íme, így nézhet ki ez a gyakorlat, miután megírta a felhasználói folyamatot és durva vázlatokat készített alatta. Ne feledje, nem kell szépnek lennie, de eléggé át kell adnia az elképzeléseit ahhoz, hogy továbbléphessen a következő lépésre, a digitális drótvázlatokra.

Példa 1

Példa 2

3. példa

Kettes lépés: Alacsony hűségű digitális drótvázak

becsült idő: 2-3 nap, az MVP terjedelmétől függően.

Ha már kitaláltad az MVP drótvázát, a következő lépés a kissé részletesebb drótvázak elkészítése. Készíthet papíralapú prototípust, vagy rögtön a digitális drótvázlatokba is belevághat (ha a gyorsaság a lényeg, én általában a digitális drótvázlatokba ugrok).

Megjegyzés: Ha egy bevált márkával dolgozik, lehetséges, hogy egy meglévő tervezési rendszer elemeit használja fel, és rögtön a nagy hűségű, 3. lépésbe ugorhat.

A vázlatkészítés során feltárt kulcsképernyőkhöz érdemes artboardokat készíteni. A szükséges képernyők száma a vázlatkészítés, az alacsony hűségű drótvázak és a magas hűségű drótvázak közötti drótvázlatkészítési folyamat során egyre nőni fog.

Az alacsony hűségű digitális drótvázakhoz használja az Ön által választott tervezőeszközt egyszerű formák létrehozásához, és használjon alapvető betűtípusokat a drótvázak elkészítéséhez. Számos UI-készlet is létezik, amelyek felgyorsíthatják ezt a folyamatot, és vizuálisan kicsit vonzóbb, alacsony hűségű terveket hozhatnak létre. Azt is javaslom, hogy olyan közepes artboard méretet használjon, amely a legtöbb telefon képernyőméretén működhet. Ha vannak adatai a célközönségéről és arról, hogy milyen telefonméretet használnak túlnyomórészt, akkor ezt a képernyőméretet használja.

Az Adobe XD (vagy bármelyik tervezőeszköz, mivel a legtöbbben előre beállított méretek vannak beépítve) használatakor 875 x 667px méretű artboardot használok, mivel ez a képernyőméretek “középútja” (különösen iPhone esetében). Úgy tapasztalom, hogy ez a méret jól működik az iPhone 8 és az iPhone X esetében, és úgy tapasztalom, hogy Android esetében is jól működik.

Itt egy példa a low-fidelity képernyőkre működés közben:

Mihelyt elkészítette az alacsony hűségű képernyőket, tesztelte a terveket a felhasználókkal, és megkapta az érintettek jóváhagyását, készen áll a nagy hűségű képernyők létrehozására.

Harmadik lépés: Nagy hűségű digitális drótvázak

A becsült idő: 1+ hét. Ez attól függ, hogy van-e már kialakított tervezési rendszere, vagy menet közben, a semmiből hozza létre. Ez a lépés azért is tart tovább, mert valószínűleg több képernyőt kell hozzáadni, mint az alacsony hűségű fázisban.

Ez a lépés az, amikor a tervei életre kelnek! Ez az a fázis, amikor a tervei valóban elkezdenek úgy kinézni, mint egy működő mobilalkalmazás, amelyet prototípusként használhat, tesztelhet, iterálhat, jóváhagyást kaphat, majd végül átadhatja a fejlesztőcsapatnak.

Megfontolások:

• Ha a terméknek, amelyen dolgozik, már van egy kialakult márkája, akkor a színeket, ikonokat és betűtípusokat valószínűleg a márkairányelvekből veszi.
• Ha a termék, amin dolgozik, nem rendelkezik teljesen kialakult márkaarculattal, akkor kereshet és használhat egy UI-készletet, hogy felgyorsítsa a tervezési folyamatot.

A következő megfontolás az, hogy milyen képernyőkkel kezdjen? Kezdheted:

• Kulcsképernyőkkel a fő navigáció egyes szakaszaihoz, vagy;
• Kulcsképernyőkkel a felhasználó számára, vagy;
• Priorizáld a képernyőket, amelyeket a fejlesztési ütemterv sorrendje alapján tervezel (én jellemzően ezzel kezdem, így agilis módszerrel dolgozhatok, ügyelve arra, hogy a képernyők készen álljanak az átadásra, amint a fejlesztőcsapatnak szüksége van rájuk).

Ebben a példában egy Adobe XD-ben létrehozott UI-készlet használatának folyamatát fogom bemutatni. És a felhasználói bejelentkezéssel/regisztrációval és profilkészítéssel fogom kezdeni, mert a fejlesztőcsapatok, akikkel eddig dolgoztam, általában a felhasználókezeléssel kezdik az alkalmazásfejlesztési folyamatot.

A választott UI-készlet már rendelkezik egy kialakult színpalettával, karakterstílusokkal és közös UI-elemekkel (más néven komponensekkel), amelyeket a drótvázakba másolva és beillesztve használhatunk.

Megjegyzés: Már a korai szakaszban javaslom, hogy az újrafelhasználásra szánt elemeket alakítsuk át komponensekké (vagy szimbólumokká). Így, ha a vissza nyilat ” ← ” nyílról “<” sárgarépára kell változtatnia, akkor a mester komponenssel megváltoztathatja, és ez az összes drótvázban frissül, nem kell a szerkesztést minden egyes frissítendő képernyőre másolnia és beillesztenie.

Példa a színekre, karakterstílusokra és komponensekre:

A folyamat megkezdéséhez én a beszállási, bejelentkezési és felhasználói profil képernyők kiépítését kezdeném:

A következő lépésként a globális navigációs elemek kiépítését kezdeném el:

Ezek után elkezdeném az alkalmazás összes felhasználói áramlásának nagy hűségű vezetékeinek létrehozását, kezdve a fejlesztőknek való átadás alapján priorizált áramlásokkal (vagy minden olyan elemmel, amely még felhasználói tesztelést igényel).

Az egyes kulcsfontosságú felhasználói áramlásokhoz külön tervezési fájlokat ajánlok létrehozni, hogy agilis módszerrel dolgozva könnyen tudjon prototípust készíteni és megosztani a fejlesztőkkel (pl. egy fájl a felhasználói regisztrációhoz és fiók létrehozásához, egy fájl az üzenetküldéshez, egy fájl a keresési élményhez stb.).

Amint a terveket jóváhagyják és átadják a fejlesztésnek, javaslom, hogy hozzon létre egy mesterfájlt az összes képernyővel és mesterelemmel. Ha csapatban dolgozunk, általában azt javaslom, hogy egy személy legyen felelős a mesterfájlért, hogy csökkentsük a zűrzavart. Így minden csapattag tudja, hogy a jóváhagyott mesterfájlból merít, amikor az alkalmazás új funkcióinak és folyamatainak létrehozásán dolgozik.

Itt van például az egyik projektem mesterfájljának madártávlatú nézete. Vegye figyelembe, hogy a képernyőket felhasználói folyamat és fejlesztési prioritás szerint csoportosítottam és rendeztem. Ezt a mesterfájlt a felhasználói folyamatok következő sorozatának kialakításakor tovább fogom bővíteni.

Néhány vezérelv a jobb mobilalkalmazások létrehozásához

Most már tudja, hogyan kezdjen hozzá a digitális élmények drótvázának kialakításához, itt az ideje, hogy szintet lépjen a tervezési megközelítésben. Ha mobileszközökre készítesz élményt, olyan operációs rendszerekre, mint az iOS és az Android, van néhány kulcsfontosságú szempont, amelyet szem előtt kell tartanod. Íme néhány általános tipp (és néhány személyes vélemény) a mobilalkalmazások tervezéséről, valamint arról, hogyan töltsön kevesebb időt a piacon lévő egyes eszköztípusokra való tervezéssel. Ha további inspirációra vágyik, nézze meg ezeket a weboldalakra és mobilalkalmazásokra vonatkozó drótváz-példákat is.

Erős meggyőződésem, hogy egy dizájnnak a lehető legáltalánosabbnak kell lennie. Ezért amikor csak lehetséges, az operációs rendszer-agnosztikus tervezést szorgalmazom. Íme, miért:

• Ha egy felhasználó Androidos telefonról iPhone-ra vált, nem szabad, hogy két különböző módon kelljen megtanulnia használni egy alkalmazást, amely ugyanazt az igényt oldja meg. A megoldásnak továbbra is ugyanannak kell lennie. Tudom, hogy lehetnek gesztusbeli különbségek és eszközspecifikus lehetőségek, de úgy gondolom, hogy egy alkalmazásnak ugyanazt a felhasználói felületet és felhasználói folyamatot kell kínálnia, függetlenül az operációs rendszertől. És a fontos funkciókat nem szabad túl mélyen elrejteni a kontextuális menükben; ez csak rossz UX.
• Drága két (vagy több) teljesen különböző élmény megtervezése, fejlesztése és karbantartása (különösen, ha az élmény platformtól függetlenül ugyanaz lehetne).
• A különböző élmények tervezése és karbantartása során az élmények nagyon különbözővé válhatnak. Ez árthat a márkának, és megnehezítheti a visszajelzések és funkciók nyomon követését és megvalósítását.

Hogyan lehet tehát mindenütt elérhető designt létrehozni és eszköz-agnosztikusnak lenni? Én így csinálom:

1. A mobilterveimet úgy kezelem, mintha mobil webre terveznék. A terveim reszponzívak, mert végtelen számú képernyőméret és pixelsűrűség létezik (ezek olyan gyorsan változnak, ahogy a cégek meg tudják tervezni őket). Tervezőként nincs időnk arra, hogy minden pixelsűrűségre tervezzünk, és nem hiszem, hogy az ügyfeleim egyébként is fizetni akarnak ezért az időért. Ezért 375-ös artboard-szélességet használok, ami a legtöbb modern iPhone-modell és Android esetében működik.
2. Az iPhone X és az iPhone 11 furcsa képernyőformáját úgy kezelem, hogy a fejlesztőcsapatnak azt mondom, hogy csak a fejléc háttérszínét hosszabbítsák meg a tetejére.
3. Szerencsés vagyok, hogy több különböző telefontípus is elérhető közelségben van, így aztán az XD mobilalkalmazáson keresztül USB segítségével tesztelhetem a terveimet. Ez azért hasznos, mert tesztelhetem a betűméreteket, a felhasználói felület érintési pontjait és a képernyő tartalmának láthatóságát, amikor a billentyűzet fel van hajtva. A “fold” vonalat is tesztelhetem, és meggyőződhetek arról, hogy a fontos tartalmak, például a CTA-k és a fontos tartalmak láthatóak maradnak, és nem tűnnek el a képernyő aljáról.
4. Igyekszem csak olyan gesztusokat használni, amelyek univerzálisak, pl. tap, swipe, press and hold. Úgy gondolom, hogy a legjobb felhasználói élményre kell koncentrálnunk, függetlenül az operációs rendszertől.
5. SVG-ket használok minden ikonhoz és logóhoz, hogy azok bármilyen képernyőfelbontáson jól nézzenek ki.
6. Uniális és nem túl operációs rendszer-specifikus navigációs és menüstruktúrákat használok.

Az egyetlen alkalom, amikor eszközspecifikus drótvázakat kell terveznem, amikor prototípust készítek és egy natív eszközfunkciót hívok, például a kamerát. Még ez is változhat telefononként és operációs rendszerenként.

A legtöbb ügyfelem iOS-sel kezdi. Teszteljük és validáljuk a dizájnt, és ha már jó úton halad, akkor fejlesztünk Androidra. És tudod mit? Igyekszünk egyáltalán nem változtatni a felhasználói felületen vagy a felhasználói folyamatokon. Ehelyett a márkaépítésre, a megjelenésre, a funkciók és funkciók, valamint a felhasználói folyamatokra összpontosítunk. Minden visszatér a legfontosabb dologhoz: az alapvető felhasználói élményhez.