Komplet vejledning i at lave trådmodeller til mobilapps

Overslag over tid: 1-2 timer. Jeg anbefaler, at du laver denne øvelse med de vigtigste interessenter.

Lad os starte med den forudsætning, at du har fået til opgave at skabe en mobilapp. Det første, du bør spørge dig selv om, er: “Hvilket problem løser jeg, og hvem løser jeg det for?” Svarene på dette sammensatte spørgsmål vil danne grundlaget for dit design, fordi de vil give indsigt, der kan styre egenskaberne og funktionerne i dine designs. Disse svar vil helt sikkert også hjælpe dig med at beslutte, hvad MVP (minimum viable product) skal være for dit design.

For eksempel kan du have en masse funktioner på produktkøreplanen, men du behøver kun at fokusere på de essentielle funktioner for at lancere den første version af appen med succes. Du kan starte med at spørge: “Hvilke funktioner og features skal vi skabe, så vores målgruppe kan fuldføre deres mål/opgave?”

For at besvare dette spørgsmål kan du oprette et brugerflow baseret på din primære brugers “lykkelige vej” (du kan fokusere på alle edge cases senere). Jeg anbefaler et whiteboard, hvor du først skriver alle de vigtigste trin for brugeren ud. Når du har skrevet disse nøgletrin ned, kan du begynde at lave skitser på højt niveau af disse trin. Dette hjælper dig med at bestemme, hvilke affordances brugeren har brug for på hvert trin på vejen og holder scope creep på afstand.

Note: Prøv at stoppe dig selv fra at skitsere uden først at skrive brugerflowet. Vores hjerner kan blive meget kreative og komme ud af sporet, hvis vi springer direkte ud i skitsering.

Her er, hvordan denne øvelse kan se ud, efter at du har skrevet dit brugerflow ud og lavet grove skitser under det. Husk, at det ikke behøver at være kønt, men det skal formidle dine idéer nok til, at du kan gå videre til næste trin, digitale wireframes.

Eksempel 1

Eksempel 2

Eksempel 3

Stræk to: Low-fidelity digitale wireframes

Overslagsmæssig tid: 2-3 dage, afhængigt af MVP’ens omfang.

Når du har fået styr på dine MVP wireflows, er det næste skridt at lave lidt mere detaljerede wireframes. Du kan oprette en papirprototype eller gå direkte til digitale wireframes (hvis det skal gå hurtigt, plejer jeg at springe til digitale wireframes).

Note: Hvis du arbejder med et etableret brand, kan det være muligt at bruge komponenter fra et eksisterende designsystem, og du kan springe direkte til high-fidelity, trin 3, nedenfor.

Jeg anbefaler, at du opretter artboards for de vigtigste skærmbilleder, som du har afdækket i din skitseøvelse. Antallet af skærme, du har brug for, vil stige, efterhånden som du bevæger dig gennem wireframing-processen fra skitsering, low-fidelity wireframes til high-fidelity wireframes.

For de digitale wireframes med lav fidelitet skal du bruge et designværktøj efter eget valg til at skabe enkle former og bruge grundlæggende skrifttyper til at skabe dine wireframes. Der findes også mange UI-kits derude, som kan fremskynde denne proces og skabe low-fidelity-designs, der er lidt mere visuelt tiltalende. Jeg anbefaler også, at du bruger en median artboard-størrelse, der kan fungere på tværs af de fleste telefonskærmstørrelser. Hvis du har data om din målgruppe, og hvilken telefonstørrelse der overvejende bruges af dem, så gå med den skærmstørrelse.

Jeg bruger en artboardstørrelse på 875 x 667px, når jeg bruger Adobe XD (eller et hvilket som helst designværktøj, da de fleste har forudindstillede størrelser indbygget), da det er “midtervejen” for skærmstørrelser (især for iPhone). Jeg synes, at denne størrelse fungerer godt for iPhone 8 og iPhone X, og jeg synes også, at det fungerer godt for Android.

Her er et eksempel på low-fidelity-skærme i aktion:

Når du har oprettet dine low-fidelity-skærme, testet dine designs med brugere og fået godkendelse fra interessenterne, er du nu klar til at oprette high-fidelity-skærme.

Stræk tre: High-fidelity digitale wireframes

Overslagsmæssig tid: 1+ uger. Dette afhænger af, om du har et designsystem på plads, eller om du skaber det fra bunden, mens du arbejder. Dette trin tager også længere tid, da der sandsynligvis vil blive tilføjet flere skærme end i low-fidelity-fasen.

Dette trin er det, hvor dine designs kommer til live! Det er også den fase, hvor dine designs virkelig begynder at ligne en fungerende mobilapp, som du kan lave en prototype af, teste, iterere, få godkendt og derefter i sidste ende overdrage til udviklingsteamet.

Overvejelser:

• Hvis det produkt, du arbejder på, allerede har et etableret brand, vil du højst sandsynligt trække farver, ikoner og skrifttyper fra brand guidelines.
• Hvis det produkt, du arbejder på, ikke har et fuldt etableret brand look and feel, kan du bruge finde og bruge et UI-kit til at fremskynde din designproces.

Den næste overvejelse er, hvilke skærme du starter med? Du kan starte med:

• Nøgleskærme for hver sektion af din hovednavigation, eller;
• Nøglebrugerstrømme for brugeren, eller;
• Prioriter de skærme, du designer, ud fra rækkefølgen af udviklingsplanen (det er typisk her, jeg starter, så jeg kan arbejde i en agil metode og sørge for at have skærme klar til aflevering, efterhånden som udviklingsteamet har brug for dem).

I dette eksempel vil jeg vise processen med at bruge et etableret UI-kit i Adobe XD. Og jeg vil starte med brugerlogin/tilmelding og profiloprettelse, fordi de udviklingsteams, jeg har arbejdet med, typisk starter med brugerstyring i deres appudviklingsproces.

Det UI-kit, jeg valgte, har allerede en etableret farvepalet, tegnstile og fælles UI-elementer (aka komponenter), som kan kopieres og indsættes i wireframes.

Note: Jeg anbefaler, at du tidligt i forløbet omdanner alle elementer, som du planlægger at genbruge, til komponenter (eller symboler). På den måde kan du, hvis du har brug for at ændre pilen tilbage fra en pil ” ← ” til en gulerod “<“, ændre den via masterkomponenten og få den opdateret på tværs af alle wireframes i stedet for at skulle kopiere og indsætte redigeringen på hvert enkelt skærmbillede, der skal opdateres.

Eksempel på farver, tegnstile og komponenter:

For at starte processen ville jeg begynde at bygge onboarding-, sign in- og brugerprofilskærmene op:

Dernæst ville jeg begynde at opbygge globale navigationselementer:

Efter dette ville jeg begynde at skabe high-fidelity-ledninger for alle brugerstrømme for appen, begyndende med prioriterede strømme baseret på levering til udvikling (eller for elementer, der stadig har brug for brugertest).

Jeg anbefaler at oprette separate designfiler for hver af de vigtigste brugerstrømme, så du nemt kan lave prototyper og dele dem med udviklingen, når du arbejder i en agil metode (dvs. én fil til brugerregistrering og kontooprettelse, én fil til messaging, én fil til søgeoplevelse osv.).

Når design bliver godkendt og afleveret til udvikling, anbefaler jeg at oprette én masterfil med alle skærme og masterkomponenter. Når der arbejdes i teams, anbefaler jeg typisk, at én person er ansvarlig for masterfilen for at mindske forvirring. På den måde ved hvert teammedlem, at de trækker fra den godkendte masterfil, når de arbejder på at skabe nye funktioner og flows til appen.

For eksempel er her et fugleperspektiv af en masterfil til et af mine projekter. Bemærk, at jeg har grupperet og ordnet skærmbillederne efter brugerflow og udviklingsprioritet. Jeg vil fortsætte med at tilføje til denne masterfil, efterhånden som jeg opbygger den næste sekvens af brugerstrømme.

Nogle vejledende principper for at skabe bedre mobilapps

Nu, hvor du ved, hvordan du kommer i gang med wireframing af dine digitale oplevelser, er det tid til at højne niveauet i din designtilgang. Hvis du skaber en oplevelse til mobile enheder på styresystemer som iOS og Android, er der nogle vigtige overvejelser, som du skal være opmærksom på. Her er nogle overordnede tips (og et par personlige holdninger) om design af mobile apps, og hvordan du kan bruge mindre tid på at designe til hver type enhed på markedet. Hvis du søger yderligere inspiration, kan du også tjekke disse wireframe-eksempler på websteder og mobilapps.

Jeg har en stærk tro på, at et design skal være så allestedsnærværende som muligt. Så når det er muligt, opfordrer jeg til et operativsystem agnostisk design. Her er hvorfor:

• Hvis en bruger skifter fra en Android-telefon til en iPhone, skal vedkommende ikke skulle lære to forskellige måder at bruge en app på, som løser det samme behov. Løsningen skal stadig være den samme. Nu ved jeg godt, at der kan være gestusforskelle og enhedsspecifikke affordances, men jeg mener, at en app bør tilbyde den samme brugergrænseflade og brugerflow uanset styresystem. Og vigtige funktioner bør ikke være skjult for dybt i kontekstuelle menuer; det er bare dårlig UX.
• Det er dyrt at designe, udvikle og vedligeholde to (eller flere) helt forskellige oplevelser (især når oplevelsen kunne være den samme uanset platform).
• Når man designer og vedligeholder de forskellige oplevelser, kan oplevelserne begynde at blive meget forskellige. Det kan skade brandet og gøre det sværere at spore og implementere feedback og funktioner.

Så hvordan skaber man allestedsnærværende designs og er agnostisk over for enheder? Her er, hvordan jeg gør det:

1. Behandler mine mobile designs, som om jeg designer til mobilt web. Mine designs er responsive, fordi der findes uendelige skærmstørrelser og pixeltætheder (disse ændrer sig lige så hurtigt, som virksomhederne kan konstruere dem). Som designere har vi ikke tid til at designe til alle pixeltætheder, og jeg tror ikke, at mine kunder ønsker at betale for den tid alligevel. Så jeg bruger en artboardbredde på 375, hvilket fungerer for de fleste moderne iPhone-modeller og Android.
2. Jeg håndterer den mærkelige skærmform på iPhone X og iPhone 11 ved at bede udviklerteamet om blot at udvide header-baggrundsfarven til toppen.
3. Jeg er heldig at have flere forskellige telefontyper inden for min rækkevidde, så jeg kan derefter teste mine designs via XD-mobilappen ved hjælp af en USB. Det er nyttigt, fordi jeg kan teste skriftstørrelser, UI-berøringspunkter og synligheden af skærmindholdet, når tastaturet er oppe. Jeg kan også teste “fold”-linjen og være sikker på, at vigtigt indhold, f.eks. CTA’er og vigtigt indhold, forbliver synligt og ikke forsvinder ud af bunden af skærmen.
4. Jeg forsøger kun at bruge bevægelser, der er universelle, f.eks. tap, swipe, tryk og hold. Jeg mener, at vi bør kunne fokusere på den bedste brugeroplevelse uanset OS.
5. Jeg bruger SVG’er til alle ikoner og logoer, så de ser godt ud på alle skærmopløsninger.
6. Jeg bruger navigations- og menustrukturer, der er universelle og ikke for OS-specifikke.

Den eneste gang, jeg er nødt til at designe wireframes, der er enhedsspecifikke, er, når jeg laver prototyper og kalder en native enhedsfunktion, f.eks. kameraet. Selv det kan variere fra telefon til telefon og OS.

De fleste af mine kunder starter med iOS. Vi tester og validerer designet, og når det er på rette spor, så udvikler vi til Android. Og ved du hvad? Vi forsøger slet ikke at ændre UI’en eller brugerflowet. I stedet fokuserer vi på branding, look and feel, funktioner og funktioner samt brugerflow. Det hele kommer tilbage til det vigtigste: den centrale brugeroplevelse.