Mobiilirakenduste turg on konkurentsist küllastunud. Suundumused muutuvad kiiresti, kuid ükski nišš ei saa kaua kesta, kui mängu ei tule mitu konkurenti. Nende tingimuste tulemuseks on mobiilirakenduste turu jaoks kõrge rikete protsent. Ainult 20% allalaaditud rakendustest näevad kasutajad pärast esimest kasutamist tagasi, samas kui pärast esimest kuud jääb kasutusse vaid 3% rakendustest.
Kui mõni rakenduse osa on ebasoovitav või selle mõistmise protsess on aeglane, paigaldavad kasutajad suurema tõenäosusega uue, selle asemel et oodata ebatäiusliku toote lõppu. Tarbija ei kaota rakendusest loobumisel midagi - välja arvatud disainerid Y arendajad . Miks siis nii paljud rakendused kokku kukuvad? Kas see on prognoositav nähtus, millega rakenduste disainerid ja arendajad peavad nõustuma? Kas see edukuse määr on klientide jaoks vastuvõetav? Mida on vaja, et teie kujundused jõuaksid 3% -ni õnnestunud rakendustest?
üsna sageli peate seda lauset kasutama klasside rühma programmile kättesaadavaks tegemiseks.
Levinumad vead ulatuvad järjepidevuse hoidmata jätmisest kogu rakenduse elu jooksul kuni kasutajate meelitamiseni. Kuidas saab rakendusi kujundada intuitiivse lihtsusega, muutumata korduvaks ja igavaks? Kuidas saab rakendus edastada kõik meeldivad üksikasjad, kaotamata silmist kõrgemat eesmärki? Enamik rakendusi elab ja sureb esimestel päevadel, nii et siin on kümme levinumat viga, mida disainerid saavad vältida.
Pärast allalaadimist jääb kasutamiseks ainult 3% mobiilirakendustest.
Üldine viga nr 1: halb esimene mulje
Sageli on esmakordne kasutamine või esimene päev koos rakendusega kõige kriitilisem periood potentsiaalse kasutaja ligimeelitamiseks. Esimene mulje on nii kriitiline, et see võib olla selle kümne ülejäänud osa lähtekoht. Kui miski pole õige või tundub segane või igav, kaotavad potentsiaalsed kasutajad kiiresti huvi; esmamulje korralikku tasakaalu on aga raske saavutada. Mõnel juhul võib pikk kasutuselevõtu protsess või vajalike funktsioonide avastamise protsess kasutajaid tüütada.
Kohe ahvatlev rakendus võib aga mööda minna vajadusest korraliku õpetuse järele ja soodustada segadust. Kohe intuitiivse rakenduse vahel, mis ühtlasi tutvustab kasutajatele kõige lõbusamaid ja kaasahaaravamaid funktsioone, tuleb leida tasakaal. Pidage meeles, et kui kasutajad tulevad teie rakendusse, näevad nad seda esimest korda. Oluline on korralik testimisprotsess, et teha kindlaks, kuidas teised teie rakendust algusest peale tajuvad. See, mis tundub disainimeeskonnale ilmne, ei pruugi nii olla uustulnukatele.
Puudulik integratsioon
Integreerimine või integreerimine on kasutaja oma rakendusse tutvustamise järkjärguline protsess. Ehkki see võib olla hea viis kellegi kiireks juhtimiseks, on rongile minek ka pikk protsess, mis takistab teie kasutajaid ja nende sisu. Need õpetused on sageli liiga pikad ja tõenäoliselt lähete neist läbi.
Mõnikord on kasutajad näinud, et teie rakendust kasutatakse avalikult või mõnes muus kohas nii, et nad saavad sellest korraga aru ja tahavad seda esimest korda kasutada. Seega võimaldab see omamoodi kiiret väljumisstrateegiat, et vältida rakenduse esmakordsest kokkukukkumisest. Veendumisprotsessi tõelise tõhususe tagamiseks peate kaaluma, milliseid väärtusi see võib edastada ja kuidas seda teha. Kasutajaprobleem peaks kasutaja kinnitamiseks näitama rakenduse väärtust, mitte lihtsalt selgitust.
Ärge koormake animatsiooni käivitamisel
Mõned disainerid otsustavad jätta hea esmamulje sissepääsuanimatsioonidega, mis paeluvad ja pimestavad uusi kasutajaid. Pidage siiski meeles, et iga kord, kui keegi soovib rakendust käivitada, peab ta sama asja nägema ikka ja jälle. Kui rakendusel on igapäevane funktsioon, väsitab see teie kasutajaid kiiresti. Kümme sekundit kellegi logost üle ekraani pühkimiseks ja võib-olla paar korda keerutamiseks pole mõne aja pärast tegelikult seda väärt.
Üldine viga nr 2: ilma sihtotstarbeta rakenduse kujundamine
Vältige lühikeste kavatsusteta disainiprotsessi sisenemist. Rakendused töötatakse välja ja arendatakse sageli selleks, et järgida suundumusi, mitte probleemi lahendamiseks, niši täitmiseks või eristava teenuse pakkumiseks. Mis on rakenduse eesmärk? Disaineri ja tema meeskonna jaoks mõjutab eesmärgi tajumine projekti kõiki samme. See tundlikkus juhib iga otsust rakenduse kaubamärgi või turunduse kohta, kasutades traadiraami vormingut ja esteetilist nuppu. Kui eesmärk on selge, siis rakenduse iga osa suhtleb ja toimib ühtse tervikuna. Seetõttu veenduge, et disaini- ja arendustiim arvestaks pidevalt oma otsuseid suurema eesmärgi piires. Projekti edenedes võib esialgne ambitsioon muutuda. See on hea, kui visioon jääb püsivaks.
Selle visiooni edastamine potentsiaalsetele kasutajatele tähendab, et nad saavad aru, millise väärtuse rakendus nende ellu toob. Seetõttu on see arusaam oluline, mida esmamuljega edasi anda. Küsimus on, kui kiiresti suudate kasutajaid veenda oma rakenduse nägemuses? Kuidas see parandab inimese elu või pakub mingit naudingut või lohutust. Kui seda ambitsiooni tõhusalt levitatakse, seni, kuni teie rakendus on tegelikult kasulik, jõuab 3% -ni .
Sageli tähendab juba olemasoleva turuga või nišitururakendusega liitumine seda, et uurimiseks on rakendusi, kui ise oma rakendust kujundate. Nii et olge ettevaatlik, kui otsustate juba turul olevale 'uue eesmärgi anda'. Uurige lihtsalt ülevaatamise asemel olemasolevate rakenduste turgu. Nii et minge üle olemasolevatelt toodetelt, selle asemel, et meeletult jäljendada.
asjade interneti turvaprobleemid
Üldine viga nr 3: Disaini kaardistamise raiskamine UX-is
Enne kujundustööde alustamist ärge unustage rakenduse UX-arhitektuuri hoolikat planeerimist. Juba enne traadistamise etappi jõudmist tuleb kaardistada rakenduse voog ja struktuur.
Disainerid on esteetika ja detailide tootmiseks sageli liiga põnevil. Selle tulemuseks on disainerite kultuur, kes üldiselt ei hinda UX-i ega rakenduses vajalikku loogikat ega navigeerimist. Võta aeglasemalt. Visandage esmalt rakenduse voog, enne kui muretsete liiga palju peenemate pintslitõmbe pärast. Rakendused ebaõnnestuvad sageli puudulike andmete asemel üldise voolu ja korralduse puudumise tõttu. Kui aga disainiprotsess algab, peaksite alati silmas pidama peamist eesmärki. Detailid ja esteetika peaksid siis selgelt esile kutsuma ülekaaluka kontseptsiooni.
asp.net core 2 ja angular 5
Levinud viga nr 4: rakenduse arenduseelarve arvestamata jätmine
Niipea, kui rakenduse sihtasutus on välja loositud, on hea aeg saada arendusmeeskonnalt hinnapakkumine. Nii ei jõua projekti lõpuni ja äkki peate hakkama kriitilisi funktsioone eemaldama. Disainikarjääri arendamisel võtke alati arvesse oma kontseptsioonide tavapäraseid ehitamiskulusid, et teie disainimõtlemine vastaks majanduslikele piirangutele. Eelarved peaksid olema kasulikud kujunduspiirangud, mille piires saate töötada.
Üldine viga nr 5: disainifunktsioonide ülekoormus
Loodetavasti muudab range traadiga raamimine selgelt vajaliku ja liigse funktsiooni vahel vahet. Platvorm on juba ülim “Šveitsi armee nuga”, nii et teie rakendus ei pea seda olema. Rakenduse funktsioonidega ülekoormamine võib mitte ainult põhjustada tõenäoliselt kasutuskogemuse moonutamist, vaid ka üleküllastatud rakendust on keeruline turustada. Kui rakenduse kasutamist on keeruline kokkuvõtlikult seletada, on kõige tõenäolisem, et rakendus üritab liiga teha. Funktsioonide alandamine on alati keeruline, kuid vajalik. Sageli võib parim strateegia olla varakult enesekindluse saavutamine ühe või mõne funktsiooniga ning uusi saab rakenduse hilisemas etapis 'testida'. Sel viisil segavad lisafunktsioonid vähem tõenäoliselt rakenduse elutähtsaid esimesi päevi.
Levinud viga nr 6: rakenduse konteksti tagasilükkamine
Kuigi enamikus disainibüroodes toimivad tingimused praktiliselt vaakumis, peavad rakenduste disainerid olema teadlikud laiemast kontekstist. Kuigi eesmärk ja ambitsioon on olulised, muutuvad need ebaoluliseks, kui neid ei käsitleta õiges kontekstis. Pidage meeles, et kuigi teie ja teie disainimeeskond tunnevad rakendust väga hästi ja kasutajaliides on ilmne, ei pruugi see uute kasutajate või erinevate demograafiliste rühmade puhul nii olla.
Võtke arvesse vahetut konteksti või olukorda, milles kavatsete rakendust kasutada. Kui kaua saab inimene sotsiaalset olukorda arvestades rakenduse kasutamist kaaluda? Mida nad võiksid antud olukorras veel kasulikuks pidada? Näiteks, UBER-liides paistab silma, kuna seda kasutatakse väga kiiresti. See tähendab, et enamasti pole muu sisu jaoks palju ruumi. See on täiuslik, sest kui kasutaja on sõpradega väljas ja peab reisi broneerima, siis pole tema vestlus selles protsessis kuigi palju katkenud. UBER peidab rakenduses suure hulga tugisisu, kuid see ilmub alles siis, kui stsenaarium seda nõuab.
Kes on rakenduse sihtrühm? Kuidas saaks kasutaja tüüp mõjutada rakenduse kujundust? Võib-olla peaksite arvestama, et konkreetne nooremale kasutajale mõeldud rakendus võib olla võimeline kasutama rohkem vabadusi, eeldades kasutaja teatud taset. Kui paljud funktsioonid võivad osutuda vajalikuks spetsiaalselt vähem tehnikat kasutavale kasutajale. Kas teie rakendusele on mõeldud juurdepääs kiiresti ja lühikese aja jooksul? Või on see palju sisu sisaldav rakendus, mis võimaldab kasutajatel mõnda aega selles viibida? Milline on disain seda tüüpi kasutusviisi edastamiseks?
Üldine viga nr 7: platvormidevahelise alahindamine
Rakendused arenevad sageli kiiresti vastuseks turumuutustele või konkurentide edenemisele. Selle tagajärjel tõmmatakse veebisisu mobiilsele platvormile. Jätkuv teema, mida te arvate praeguseks laialt mõistvat, juhtub nii tihti, et mobiilirakendused ja muu sisu teevad töölaua- või mobiiliplatvormide vahel halva ülemineku. Mobiilidisainil pole enam võimalik veebisisu ilma tagajärgedeta järk-järgult kaotada, lootuses kiiresti mobiilsideturule äri saada. Üleminek veebist mobiilile ei tähenda mitte ainult kõige vähendamist, vaid ka võimalust töötada vähemaga. Funktsioonid, navigeerimine ja sisu tuleb transportida minimaalse strateegiaga.
Teine levinud probleem ilmneb siis, kui rakenduste arendustiim soovib toodet korraga turule tuua kõigil platvormidel ja erinevate rakenduste poodide kaudu. Selle tulemuseks on sageli halb ühilduvus või üldiselt lollakas ja lihvimata rakendus. Mitme platvormi tasakaalustamist hõlmav võimlemine võib olla rakenduse käivitamisel liiga suur. Kuid mõnikord ei tee haiget, kui võtate selle aeglaselt ühe opsüsteemiga korraga ja parandate olulisi probleeme, enne kui muretsete platvormidevahelise ühilduvuse pärast.
css-meediumipäringu katkestuspunktid peaksid põhinema
Levinud viga nr 8: rakenduse kujundus on liiga keeruline
Kuulus arhitekt Mies Van der Rohe ütles kunagi: 'Parem on olla hea kui olla ainulaadne' . Enne kasti purustamist või kaunistuste lisamist veenduge, et teie disain vastab teie nõusolekule. Kui disainer leiab end kompositsiooni atraktiivsemaks või põnevamaks muutmiseks üksikasju lisamast, on neil valikutel tõenäoliselt vähe väärtust. Küsige kogu disainiprotsessi vältel pidevalt, kui palju ma võin ära võtta? Lisakujunduse asemel kujundage reduktiivselt. Mida pole vaja? See meetod on suunatud nii sisule, kontseptsioonile ja funktsioonile kui ka esteetikale.
Liigne keerukus on sageli disaini tulemus, mis rikub asjatult tavasid. Erinevad sümbolid ja liidesed on meie visuaalses ja kombatavas keeles standardsed. Kas teie toode saab tõesti nende standardite ümbertöötamisest kasu? Standardikoonid on osutunud üldiselt intuitiivseteks. Seetõttu on need sageli kiireim viis visuaalsete vihjete pakkumiseks ilma asjatut ekraani täitmata. Ärge laske oma disaini detailidel rakenduse tegelikku sisu ega toimimist katkestada. Rakendustele ei eraldata sageli piisavalt ruumi. Pindala vajadus on graafiline kontseptsioon, mis on ületanud nii digitaalse kui trükise, mistõttu ei tohiks seda alahinnata. Hoidke ekraanil olevate elementide vahel ruumi, et oleks tunda kogu tööd, mille panite navigeerimisse ja UX-i.
Üldine viga nr 9: disaini vastuolud
Kui disain on mõeldud uute standardite kasutuselevõtmiseks, peavad need olema kogu rakenduses vähemalt tasakaalus. Iga uus funktsioon või sisutükk ei pea tingimata olema võimalus uue kujunduskontseptsiooni tutvustamiseks. Kas tekstid on vormindatud ühtlaselt? Kas liideseelemendid käituvad kogu rakenduses prognoositavalt, kuid kenasti?
Kujunduse sidusus peab leidma tasakaalu ühises visuaalses keeles eksisteeriva vahel ning vältima esteetilist stagneerumist. Tasakaal intuitiivse järjekindluse ja igavuse vahel on peen joon.
Levinud viga nr 10: rakenduste beetatestide raiskamine
Kõik disainerid peaksid analüüsima oma rakenduste kasutamist mingisuguse tagasiside abil, et teada saada, mis töötab ja mis ei tööta. Levinud testimisviga on see, kui meeskond testib oma liikmeid beetatestimisega. Rakenduse mustanditesse süvenemiseks peate võtma värsked silmad.
Enne avalikkusele kuulutamist esitage beetatestijaid otsiv reklaam ja tehke koostööd valitud rühmaga. See võib olla suurepärane viis detailide silitamiseks, funktsioonide muutmiseks ja puuduva leidmiseks. Kuigi beetatestimine võib olla aeganõudev, võib see olla parem alternatiiv kui ebaõnnestunud rakenduse väljatöötamine. Eeldage, et testimine võtab mõne arendaja õigeks saamiseks sageli 8 nädalat. Vältige testijatena sõprade või töökaaslaste kasutamist, kuna nad ei saa rakendust vajaliku aususega kritiseerida. Rakenduse ajaveebide või veebilehtede kasutamine oma rakenduse ülevaatamiseks on veel üks viis, kuidas oma rakendust avalikus kohas ilma täieliku versioonita testida. Kui teil on raske oma rakenduse funktsioone madalamale versioonile üle viia, on see hea võimalus näha, millised elemendid on olulised või mitte.
Apache kaameli õpetus samm-sammult
Rakenduste kujundamise turg on lahinguväli, seega ei piisa lihtsalt õigete toodete kujundamisest. Leidke viis kasutajate varakult ühendamiseks - suhelge ja demonstreerige kriitilisi väärtusi ja omadusi nii kiiresti kui võimalik. Selleks peab disainimeeskonnal olema ühtne nägemus sellest, mida rakendus soovib saavutada. Selle ambitsiooni kindlakstegemiseks võib range jutuajamise protsess silitada seda, mis on ja mis pole hädavajalik. Mõelge, millist tüüpi kasutajad sobivad rakenduse jaoks paremini. Seejärel viimistlege ja viimistlege, kuni projekti lagunemiseta ei saa midagi muud eemaldada.
