Complete Guide to Creating Mobile App Wireframes

Arvioitu aika: 1-2 tuntia. Suosittelen tämän harjoituksen tekemistä tärkeimpien sidosryhmien kanssa.

Aloitetaan siitä, että sinulle on annettu tehtäväksi luoda mobiilisovellus. Ensimmäinen asia, joka sinun tulisi kysyä, on: ”Minkä ongelman ratkaisen ja kenelle ratkaisen sen?”. Vastaukset tähän yhdistelmäkysymykseen luovat perustan suunnittelullesi, koska ne tarjoavat oivalluksia, jotka voivat ohjata suunnittelusi ominaisuuksia ja toimintoja. Nämä vastaukset auttavat sinua varmasti myös päättämään, mikä on suunnittelusi MVP (minimum viable product).

Tuotesuunnitelmassasi voi esimerkiksi olla paljon ominaisuuksia, mutta sinun on keskityttävä vain olennaisiin ominaisuuksiin, jotta sovelluksen ensimmäinen versio voidaan onnistuneesti lanseerata. Voit aloittaa kysymällä: ”Mitä ominaisuuksia ja toimintoja meidän on luotava, jotta kohderyhmämme voi suorittaa tavoitteensa/tehtävänsä?”

Vastaaksesi tähän kysymykseen voit luoda käyttäjävirran, joka perustuu pääkäyttäjäsi ”onnelliseen polkuun” (voit keskittyä kaikkiin ääritapauksiin myöhemmin). Suosittelen valkotaulua, johon kirjoitat ensin kaikki käyttäjän keskeiset vaiheet. Kun olet kirjoittanut nämä keskeiset vaiheet ylös, voit alkaa luoda korkean tason luonnoksia näistä vaiheista. Tämä auttaa sinua määrittämään, mitä mahdollisuuksia käyttäjä tarvitsee kussakin vaiheessa, ja pitää laajuuden hiipumisen loitolla.

Huomautus: Yritä estää itseäsi luonnostelemasta ilman, että kirjoitat ensin käyttäjävirtaa. Mielemme voi muuttua hyvin luovaksi ja pois raiteiltaan, jos hyppäämme suoraan luonnosteluun.

Tältä tämä harjoitus voi näyttää sen jälkeen, kun olet kirjoittanut käyttäjävirtasi ja luonut sen alle karkeat luonnokset. Muista, että sen ei tarvitse olla kaunis, mutta sen pitäisi välittää ideasi tarpeeksi, jotta voit siirtyä seuraavaan vaiheeseen, digitaalisiin rautalankakehyksiin.

Esimerkki 1

Esimerkki 2

Low-fidelity digital wireframes

Arvioitu aika: 2-3 päivää, riippuen MVP:n laajuudesta.

Kun olet saanut MVP:n rautalankakuviot selville, seuraava vaihe on luoda hieman yksityiskohtaisemmat rautalankakuviot. Voit luoda paperiprototyypin tai siirtyä suoraan digitaalisiin rautalankamalleihin (jos nopeus on tärkeää, siirryn yleensä digitaalisiin rautalankamalleihin).

Huomautus: Jos työskentelet vakiintuneen tuotemerkin kanssa, voi olla mahdollista käyttää osia olemassa olevasta suunnittelujärjestelmästä, jolloin voit siirtyä suoraan korkean uskottavuuden vaiheeseen 3.

Suosittelen, että luot luonnosteluharjoituksessasi löytämiäsi keskeisiä näytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytönäytöt.

Matalan tarkkuuden digitaalisia rautalankakehyksiä varten voit luoda yksinkertaisia muotoja valitsemallasi suunnittelutyökalulla ja käyttää perusfontteja rautalankakehysten luomiseen. Tarjolla on myös monia UI-paketteja, jotka voivat nopeuttaa tätä prosessia ja luoda matalan uskottavuuden malleja, jotka ovat visuaalisesti hieman houkuttelevampia. Suosittelen myös käyttämään keskikokoista piirtoalustaa, joka voisi toimia useimpien puhelinten näytön koossa. Jos sinulla on tietoja kohderyhmästäsi ja siitä, minkä kokoista puhelinta he pääasiassa käyttävät, käytä tätä näytön kokoa.

Käytän Adobe XD:tä (tai mitä tahansa suunnittelutyökalua, sillä useimmissa on sisäänrakennetut esiasetetut koot) käyttäessäni taiteilualustan kokoa 875 x 667 pikseliä, sillä se on näytön koon ”keskipolku” (erityisesti iPhonen osalta). Tämä koko toimii mielestäni hyvin iPhone 8:ssa ja iPhone X:ssä, ja se toimii mielestäni hyvin myös Androidissa.

Tässä on esimerkki low-fidelity-näytöistä toiminnassa:

Monet taidepöydät kuvastavat käyttäjävirtausta Adobessa XD:ssa.

Kun olet luonut low-fidelity-näytöt, testannut mallisi käyttäjillä ja saanut hyväksynnän sidosryhmiltä, olet nyt valmis luomaan high-fidelity-näytöt.

Vaihe kolme: High-fidelity-digitaaliset rautalankakehykset

Arvioitu kesto: 1+ viikkoa. Tämä riippuu siitä, onko sinulla käytössäsi suunnittelujärjestelmä vai luotko sen tyhjästä työn edetessä. Tämä vaihe kestää myös kauemmin, koska ruutuja lisätään todennäköisesti enemmän kuin low-fidelity-vaiheessa.

Tässä vaiheessa suunnitelmasi heräävät eloon! Se on myös vaihe, jossa suunnitelmasi alkavat todella näyttää toimivalta mobiilisovellukselta, jota voit prototyypittää, testata, iteroida, saada hyväksynnän ja lopulta luovuttaa kehitystiimille.

Harkinta:

• Jos tuotteella, jota työstät, on jo vakiintunut brändi, vedät värejä, kuvakkeita ja fontteja todennäköisimmin brändiohjeistuksesta.
• Jos työstämällänne tuotteella ei ole täysin vakiintunutta brändin ulkoasua, voit etsiä ja käyttää UI-pakettia nopeuttaaksesi suunnitteluprosessia.

Seuraavana pohdintakysymyksenä on, mistä näytöistä aloitat? Voit aloittaa:

• Keskeisistä näytöistä päänavigaatiosi jokaista osiota varten, tai;
• Keskeisistä käyttäjävirroista käyttäjää varten, tai;
• Priorisoi suunnittelemasi näytöt kehitysaikataulun järjestyksen perusteella (tyypillisesti aloitan tältä pohjalta, jotta voin työskennellä ketterässä menetelmässä varmistaen, että näytöt ovat valmiina luovutusta varten sitä mukaa kuin kehitystiimi tarvitsee niitä).

Tässä esimerkissä näytän prosessin, jossa käytetään vakiintunutta UI-pakettia Adobe XD:ssä. Ja aion aloittaa käyttäjän kirjautumisella/ilmoittautumisella ja profiilin luomisella, koska kehitystiimit, joiden kanssa olen työskennellyt, aloittavat sovelluskehitysprosessinsa yleensä käyttäjähallinnoinnista.

Valitsemassani UI Kitissä on jo vakiintunut väripaletti, merkkityylit ja yleiset UI-elementit (eli komponentit), jotka voidaan kopioida ja liittää rautalankakuvioihin.

Huomautus: Suosittelen, että muutat jo varhaisessa vaiheessa kaikki elementit, joita aiot käyttää uudelleen, komponenteiksi (tai symboleiksi). Tällä tavoin, jos sinun on muutettava takaisin-nuoli nuolesta ” ← ” porkkanaksi ”<”, voit muuttaa sen master-komponentin kautta ja saada sen päivittymään kaikkiin rautalankakehyksiin, eikä sinun tarvitse kopioida ja liittää muokkausta jokaiseen päivitettävään näyttöön.

Esimerkki väreistä, merkkityyleistä ja komponenteista:

Aloittaakseni prosessin alkuun aloittaisin rakentamaan sisäänkirjautumis-, sisäänkirjautumis- ja käyttäjäprofiilinäyttöjä:

Seuraavaksi aloittaisin maailmanlaajuisten navigointielementtien rakentamisen:

Tämän jälkeen alkaisin luoda korkean uskottavuuden johdotuksia sovelluksen kaikille käyttäjävirroille, aloittaen priorisoiduista virroista sen perusteella, miten ne on toimitettu kehitystyöhön (tai kaikista niistä kohdista, jotka vaativat vielä käyttäjätestausta).

Suosittelen luomaan erilliset suunnittelutiedostot kullekin keskeiselle käyttäjävirralle, jotta voit helposti prototyypittää ja jakaa ne kehitystyön kanssa työskennellessäsi ketterällä menetelmällä (eli yksi tiedosto käyttäjän rekisteröitymistä ja tilin luomista varten, yksi tiedosto viestinvälitystä varten, yksi tiedosto hakukokemusta varten jne.).

Kun suunnitelmat hyväksytään ja luovutetaan kehitystyölle, suosittelen luomaan yhden master-tiedoston, jossa on mukana kaikki ruudut ja master-komponentit. Kun työskennellään tiimeissä, suosittelen yleensä, että yksi henkilö vastaa master-tiedostosta sekaannusten vähentämiseksi. Näin jokainen tiimin jäsen tietää käyttävänsä hyväksyttyä master-tiedostoa, kun he työskentelevät luodessaan uusia ominaisuuksia ja virtauksia sovellukseen.

Tässä on esimerkiksi lintuperspektiivistä katsottuna erään projektini master-tiedosto. Huomaa, että olen ryhmitellyt ja järjestänyt näytöt käyttäjävirtojen ja kehitysprioriteetin mukaan. Jatkan tämän master-tiedoston täydentämistä, kun rakennan seuraavaa käyttäjävirtojen sarjaa.

Joitakin ohjenuoria parempien mobiilisovellusten luomiseksi

Nyt, kun olet tietoinen siitä, miten digitaalisten elämysten rautalankamallinnus aloitetaan, on aika tasoittaa suunnittelun lähestymistapaa. Jos luot käyttökokemusta mobiililaitteille iOS:n ja Androidin kaltaisiin käyttöjärjestelmiin, on syytä pitää mielessä joitakin keskeisiä näkökohtia. Seuraavassa on joitakin yleisiä vinkkejä (ja muutama henkilökohtainen mielipide) mobiilisovellusten suunnittelusta ja siitä, miten voit käyttää vähemmän aikaa suunnitteluun kullekin markkinoilla olevalle laitetyypille. Jos kaipaat lisää inspiraatiota, voit myös tutustua näihin verkkosivujen ja mobiilisovellusten rautalankamalliesimerkkeihin.

Olen vahvasti sitä mieltä, että muotoilun tulisi olla mahdollisimman kaikkialla läsnä. Kannustan siis aina, kun mahdollista, käyttöjärjestelmä-agnostiseen suunnitteluun. Tässä on syy:

• Jos käyttäjä vaihtaa Android-puhelimesta iPhoneen, hänen ei pitäisi joutua opettelemaan kahta eri tapaa käyttää sovellusta, joka ratkaisee saman tarpeen. Ratkaisun pitäisi olla edelleen sama. Tiedän, että eleiden välillä voi olla eroja ja laitekohtaisia mahdollisuuksia, mutta mielestäni sovelluksen pitäisi tarjota sama käyttöliittymä ja käyttäjävirta käyttöjärjestelmästä riippumatta. Eikä tärkeitä toimintoja pitäisi piilottaa liian syvälle kontekstivalikoihin; se on vain huonoa UX:ää.
• On kallista suunnitella, kehittää ja ylläpitää kahta (tai useampaa) täysin erilaista käyttökokemusta (varsinkin, kun käyttökokemus voisi olla sama alustasta riippumatta).
• Erilaisia käyttökokemuksia suunniteltaessa ja ylläpidettäessä käyttökokemukset voivat alkaa muuttua hyvin erilaisiksi. Tämä voi vahingoittaa brändiä ja vaikeuttaa palautteen ja ominaisuuksien seuraamista ja toteuttamista.

Miten siis luodaan ubiikkimuotoilua ja olla laiteagnostinen? Näin minä teen sen:

1. Käsittelen mobiilisuunnittelua ikään kuin suunnittelisin mobiiliverkkoon. Suunnitelmani ovat responsiivisia, koska näytön kokoja ja pikselitiheyksiä on loputtomasti (ne muuttuvat yhtä nopeasti kuin yritykset pystyvät niitä suunnittelemaan). Suunnittelijoina meillä ei ole aikaa suunnitella jokaista pikselitiheyttä varten, enkä usko, että asiakkaani haluavat muutenkin maksaa siitä ajasta. Niinpä käytän piirustustaulun leveyttä 375, joka toimii useimmille nykyaikaisille iPhone-malleille ja Androidille.
2. Käsittelen iPhone X:n ja iPhone 11:n oudon näytönmuodon käskemällä kehitystiimiä vain laajentamaan otsikon taustaväriä yläreunaan.
3. Olen onnekas, että minulla on käden ulottuvillani useita erilaisia puhelintyyppejä, joten voin sitten testata suunnitelmiani XD:n mobiilisovelluksen välityksellä USB:n avulla. Tämä on hyödyllistä, koska voin testata fonttikokoja, käyttöliittymän kosketuspisteitä ja näytön sisällön näkyvyyttä, kun näppäimistö on ylhäällä. Voin myös testata ”taittolinjaa” ja varmistaa, että tärkeä sisältö, kuten CTA:t ja tärkeä sisältö, pysyy näkyvissä eikä katoa näytön alareunasta.
4. Yritän käyttää vain yleispäteviä eleitä, esimerkiksi napauttamalla, pyyhkäisemällä, painamalla ja pitämällä. Mielestäni meidän pitäisi pystyä keskittymään parhaaseen käyttökokemukseen käyttöjärjestelmästä riippumatta.
5. Käytän SVG:tä kaikissa kuvakkeissa ja logoissa, jotta ne näyttävät hyvältä millä tahansa näytön resoluutiolla.
6. Käytän navigointi- ja valikkorakenteita, jotka ovat universaaleja eivätkä liian käyttöjärjestelmäkohtaisia.

Ainut kerta, kun joudun suunnittelemaan rautalankarunkoja, jotka ovat laitekohtaisia, on silloin, kun prototyyppejä luodessani kutsun natiivia laitetyyppistä funktiota, esim. kameraa. Sekin voi vaihdella puhelimesta ja käyttöjärjestelmästä riippuen.

Useimmat asiakkaani aloittavat iOS:llä. Testaamme ja validoimme suunnittelun, ja kun se on oikealla tiellä, kehitämme Androidille. Ja tiedätkö mitä? Yritämme olla muuttamatta käyttöliittymää tai käyttäjävirtoja lainkaan. Sen sijaan keskitymme brändiin, ulkoasuun, ominaisuuksiin ja toimintoihin sekä käyttäjävirtoihin. Kaikki palautuu tärkeimpään asiaan: keskeiseen käyttäjäkokemukseen.