En fullständig guide för att skapa trådramar för mobilappar

Beräknad tidsåtgång: 1-2 timmar. Jag rekommenderar att du gör den här övningen tillsammans med viktiga intressenter.

Låt oss börja med förutsättningen att du har fått i uppdrag att skapa en mobilapp. Det första du bör fråga dig är: ”Vilket problem löser jag och för vem löser jag det?”. Svaren på denna sammansatta fråga kommer att lägga grunden för din design eftersom de kommer att ge insikter som kan styra egenskaperna och funktionerna i din design. Svaren kommer också säkert att hjälpa dig att bestämma vad MVP (minimum viable product) ska vara för din design.

Till exempel kan du ha många funktioner på produktkalkylplanen, men du behöver bara fokusera på de viktigaste funktionerna för att framgångsrikt lansera den första versionen av appen. Du kan börja med att fråga ”Vilka funktioner och egenskaper behöver vi skapa för att vår målgrupp ska kunna slutföra sitt mål/uppgift?”

För att besvara den här frågan kan du skapa ett användarflöde baserat på den ”lyckliga vägen” för din primära användare (du kan fokusera på alla edge cases senare). Jag rekommenderar en whiteboard där du först skriver ut alla viktiga steg för användaren. När du har skrivit ner dessa nyckelsteg kan du börja skapa skisser på hög nivå av dessa steg. Detta hjälper dig att bestämma vilka affordances användaren behöver vid varje steg och håller scope creep i schack.

Note: Försök att hindra dig själv från att skissa utan att först skriva användarflödet. Våra hjärnor kan bli väldigt kreativa och komma ur spår om vi hoppar direkt in i skissandet.

Här kan den här övningen se ut efter att du har skrivit ut ditt användarflöde och skapat grova skisser under det. Kom ihåg att det inte behöver vara vackert, men det ska förmedla dina idéer tillräckligt för att du ska kunna gå vidare till nästa steg, digitala wireframes.

Exempel 1

Exempel 2

.

Exempel 3

Steg två: Digitala wireframes med låg trovärdighet

Beräknad tid: 2-3 dagar, beroende på omfattningen av MVP:n.

När du väl har fått reda på hur MVP:n ska gå till, är nästa steg att skapa något mer detaljerade wireframes. Du kan skapa en pappersprototyp eller gå direkt till digitala wireframes (om det går snabbt brukar jag hoppa till digitala wireframes).

Notera: Om du arbetar med ett etablerat varumärke kan det vara möjligt att använda komponenter från ett befintligt designsystem och du kan hoppa direkt till high-fidelity, steg 3 nedan.

Jag rekommenderar att du skapar artboards för de nyckelskärmar som du upptäckte i din skissövning. Antalet skärmar du behöver kommer att öka allteftersom du rör dig genom wireframing-processen från skissande, wireframes med låg trovärdighet till wireframes med hög trovärdighet.

För de digitala wireframes med låg fidelitet använder du valfritt designverktyg för att skapa enkla former och använda grundläggande typsnitt för att skapa dina wireframes. Det finns också många UI-kit där ute som kan påskynda den här processen och skapa low fidelity-designs som är lite mer visuellt tilltalande. Jag rekommenderar också att du använder en medelstor artboardstorlek som kan fungera på de flesta skärmstorlekar på telefoner. Om du har uppgifter om din målgrupp och vilken telefonstorlek som används mest av dem, så använd den skärmstorleken.

Jag använder en artboardstorlek på 875 x 667px när jag använder Adobe XD (eller vilket designverktyg som helst eftersom de flesta har förinställda storlekar inbyggda) eftersom det är den ”medelväg” som gäller för skärmstorlekar (särskilt för iPhone). Jag tycker att den här storleken fungerar bra för iPhone 8 och iPhone X, och jag tycker att den fungerar bra för Android också.

Här är ett exempel på skärmar med låg trovärdighet i praktiken:

När du har skapat dina låg-fidelitetsskärmar, testat dina konstruktioner med användare och fått godkännande från intressenterna är du nu redo att skapa hög-fidelitetsskärmar.

Steg tre: Digitala wireframes med hög-fidelitet

Beräknad tid: 1+ veckor. Detta beror på om du har ett designsystem på plats eller om du skapar det från grunden under arbetets gång. Det här steget tar också längre tid eftersom det sannolikt kommer att läggas till fler skärmar än i låg-fidelitetsfasen.

Det är i det här steget som din design kommer till liv! Det är också den fas där dina designer verkligen börjar se ut som en fungerande mobilapp som du kan ta fram en prototyp av, testa, iterera, få godkännande för och sedan, i slutändan, lämna över till utvecklingsteamet.

Överväganden:

• Om produkten du arbetar med redan har ett etablerat varumärke, kommer du troligen att hämta färger, ikoner och typsnitt från varumärkesriktlinjerna.
• Om produkten du arbetar med inte har ett helt etablerat varumärkesutseende kan du använda hitta och använda ett UI-kit för att påskynda din designprocess.

Nästa övervägande är vilka skärmar du börjar med? Du kan börja med:

• Nyckelskärmar för varje sektion i din huvudnavigation, eller;
• Nyckelanvändarflöden för användaren, eller;
• Prioritera skärmarna du designar baserat på ordningen i utvecklingsschemat (det är vanligtvis så här jag börjar, så att jag kan arbeta i en agil metod och se till att ha skärmar som är redo att överlämnas när utvecklingsteamet behöver dem).

I det här exemplet ska jag visa hur man använder ett etablerat UI-kit i Adobe XD. Och jag kommer att börja med inloggning/registrering av användare och skapande av profiler eftersom utvecklingsteam som jag har arbetat med vanligtvis börjar med användarhantering i sin apputvecklingsprocess.

Det UI-kit som jag valde har redan en etablerad färgpalett, teckenstilar och gemensamma UI-element (även kallade komponenter) som kan kopieras och klistras in i alla trådramar.

Anm.: I ett tidigt skede rekommenderar jag att du förvandlar alla element som du planerar att återanvända till komponenter (eller symboler). På så sätt kan du, om du behöver ändra bakåtpilen från en pil ” ← ” till en morot ”<”, ändra den via huvudkomponenten och få den uppdaterad i alla wireframes i stället för att behöva kopiera och klistra in redigeringen på varje skärm som behöver uppdateras.

Exempel på färger, teckenstilar och komponenter:

För att påbörja processen skulle jag börja bygga ut skärmarna för onboarding, inloggning och användarprofil:

Nästan skulle jag börja bygga upp globala navigationselement:

Efter detta skulle jag börja skapa högtrohetskablar för alla användarflöden för appen, och börja med prioriterade flöden baserade på leverans till utveckling (eller för objekt som fortfarande behöver användartester).

Jag rekommenderar att du skapar separata designfiler för vart och ett av de viktigaste användarflödena så att du enkelt kan skapa prototyper och dela dem med utvecklingen när du arbetar med en agil metod (dvs. en fil för användarregistrering och skapande av konton, en fil för meddelanden, en fil för sökupplevelsen osv.).

När designerna godkänns och överlämnas till utvecklingen rekommenderar jag att du skapar en masterfil med alla skärmar och masterkomponenter. När man arbetar i team rekommenderar jag vanligtvis att en person ansvarar för masterfilen för att minska förvirringen. På så sätt vet varje lagmedlem att de hämtar från den godkända masterfilen när de arbetar med att skapa nya funktioner och flöden för appen.

Till exempel, här är en fågelperspektivbild av en masterfil för ett av mina projekt. Observera att jag har grupperat och ordnat skärmarna efter användarflöde och utvecklingsprioritet. Jag kommer att fortsätta att lägga till den här masterfilen när jag bygger ut nästa sekvens av användarflöden.

Några vägledande principer för att skapa bättre mobilappar

Nu när du vet hur du kan komma igång med wireframing av dina digitala upplevelser, är det dags att nivåera upp din designstrategi. Om du skapar en upplevelse för mobila enheter, på operativsystem som iOS och Android, finns det några viktiga överväganden att tänka på. Här är några övergripande tips (och några personliga åsikter) om hur man utformar mobilappar och hur man spenderar mindre tid på att utforma för varje typ av enhet på marknaden. Om du letar efter ytterligare inspiration kan du också kolla in de här wireframe-exemplen för webbplatser och mobilappar.

Jag har en stark övertygelse om att en design bör vara så allestädes närvarande som möjligt. Så när det är möjligt uppmuntrar jag till en operativsystem-agnostisk design. Här är varför:

• Om en användare byter från en Android-telefon till en iPhone ska de inte behöva lära sig två olika sätt att använda en app som löser samma behov. Lösningen ska fortfarande vara densamma. Nu vet jag att det kan finnas gestskillnader och enhetsspecifika affordances, men jag anser att en app bör erbjuda samma användargränssnitt och användarflöde oavsett operativsystem. Och viktiga funktioner bör inte döljas för djupt i kontextuella menyer; det är bara dålig UX.
• Det är dyrt att utforma, utveckla och underhålla två (eller flera) helt olika upplevelser (särskilt när upplevelsen skulle kunna vara densamma oavsett plattform).
• När man utformar och underhåller de olika upplevelserna kan upplevelserna börja bli väldigt olika. Detta kan skada varumärket och göra det svårare att spåra och implementera feedback och funktioner.

Så hur skapar man allmängiltig design och är enhetsagnostisk? Så här gör jag:

1. Behandla min mobila design som om jag designade för mobilwebben. Mina konstruktioner är responsiva eftersom det finns oändliga skärmstorlekar och pixeltätheter (dessa förändras lika snabbt som företagen kan konstruera dem). Som designers har vi inte tid att designa för varje pixeltäthet och jag tror inte att mina kunder vill betala för den tiden i alla fall. Så jag använder en artboardbredd på 375, vilket fungerar för de flesta moderna iPhone-modeller och Android.
2. Jag hanterar iPhone X:s och iPhone 11:s udda skärmform genom att säga till utvecklingsteamet att bara utöka bakgrundsfärgen för rubriken uppåt.
3. Jag har turen att ha flera olika typer av telefoner inom räckhåll, så jag kan sedan testa mina designer via XD-mobilappen med hjälp av en USB. Detta är användbart eftersom jag kan testa teckensnittsstorlekar, UI-beröringspunkter och synligheten av skärminnehållet när tangentbordet är uppe. Jag kan också testa ”fold”-linjen och vara säker på att viktigt innehåll, som CTA:er och viktigt innehåll, förblir synligt och inte försvinner i botten av skärmen.
4. Jag försöker att bara använda gester som är universella, t.ex. knacka, svepa, trycka och hålla. Jag tycker att vi ska kunna fokusera på den bästa användarupplevelsen oavsett operativsystem.
5. Jag använder SVGs för alla ikoner och logotyper så att de ser bra ut på alla skärmupplösningar.
6. Jag använder navigations- och menystrukturer som är universella och inte alltför operativsystemspecifika.

Den enda gången jag måste utforma trådramar som är enhetsspecifika är när jag prototyperar och anropar en inhemsk funktion på en enhet, som kameran. Även det kan variera från telefon till telefon och operativsystem.

De flesta av mina kunder börjar med iOS. Vi testar och validerar designen och när den väl är på rätt spår utvecklar vi för Android. Och vet du vad? Vi försöker att inte ändra användargränssnittet alls, eller användarflödena. I stället fokuserar vi på varumärket, utseendet och känslan, egenskaperna och funktionerna samt användarflödena. Allt kommer tillbaka till det viktigaste: den centrala användarupplevelsen.