Guide · UX og apps
App design: sådan designer I en app, der føles rigtig på iOS og Android
App design er arbejdet med at bestemme, hvordan en app skal fungere og se ud: flows, navigation, skærme og detaljer, tilpasset en lille touchskærm og konventionerne på iOS og Android. Designfasen udgør typisk en mindre del af budgettet, men den afgør, hvor meget der skal bygges om bagefter. Her får I processen, platformsforskellene, navigationsmønstre, fejl og priser.
11 min. læsning · Opdateret 1. oktober 2026
Der er to måder, en app oftest bliver designet forkert på. Den første er hjemmesiden, der er skrumpet ned: samme menu, samme lange tekster og samme formularer, bare smallere. Den anden er kopien: "vi vil have noget, der ligner konkurrentens app", uden at nogen har spurgt, om jeres brugere har de samme opgaver. Begge dele kan se pæne ud på en præsentation og føles forkerte i hånden. Godt app design starter med de få ting, brugeren skal kunne gøre hurtigt, igen og igen, med én tommelfinger, på en telefon der måske har dårligt signal.
Hvad er app design, og hvordan adskiller det sig fra webdesign?
App design dækker både UX, altså hvordan appen fungerer, og UI, altså hvordan den ser ud. Forskellen på de to har vi en hel guide om under UX vs UI design. Det, der gør apps særlige, er konteksten: brugeren har installeret appen, er ofte logget ind og kommer tilbage mange gange. Det betyder, at hastighed og genkendelighed vægter tungere end at forklare og overbevise. Samtidig har telefonen funktioner, som en hjemmeside kun har delvis adgang til, fx push-beskeder, kamera, Face ID og offline-adgang.
Webdesign
- Mange nye besøgende fra Google og annoncer
- Skal forklare, overbevise og blive fundet
- Mus, tastatur og touch
- Menu i toppen, lange sider der scrolles
App design
- Tilbagevendende brugere, der allerede kender jer
- Skal gøre gentagne opgaver hurtige
- Én tommelfinger, ofte på farten
- Navigation i bunden, korte skærme med ét formål
Hvordan foregår app design trin for trin?
1. Forstå brugerne
Interviews, supportdata og mål. Hvem bruger appen, hvornår og til hvad?
2. Brugerflows
De 3–5 vigtigste opgaver tegnes som flows fra start til mål.
3. Wireframes
Skitser af skærmene uden farver, med rigtige tekster og navigation.
4. Visuelt design
Farver, typografi, ikoner og komponenter, inkl. mørk tilstand.
5. Prototype og test
Klikbar prototype på en rigtig telefon, testet med fem brugere.
6. Overlevering
Komponenter, tilstande og tokens klar til udviklerne.
Det trin, der oftest springes over, er nummer fem. En prototype i Figma kan åbnes på en telefon og føles næsten som den rigtige app, og fem brugere afslører de fleste store problemer på en eftermiddag. Det er langt billigere at flytte en knap i en prototype end i en app, der ligger i App Store. Forskellen på wireframes, mockups og prototyper gennemgår vi i guiden wireframe, mockup og prototype, og hvordan testen køres i brugertest med fem personer.
Hvilke designregler gælder for iOS og Android?
De vigtigste forskelle mellem Apples Human Interface Guidelines og Googles Material Design. Begge opdateres løbende, så tjek den aktuelle version.
| Emne | iOS | Android |
|---|---|---|
| Tilbage | Tilbage-knap øverst til venstre og swipe fra venstre kant | Systemets tilbage-gestus eller -knap |
| Hovednavigation | Fanebjælke i bunden | Navigationsbjælke i bunden, evt. skuffemenu |
| Mindste trykflade | 44 × 44 punkter | 48 × 48 dp |
| Systemskrift | SF Pro, med Dynamic Type | Roboto, med skalering af skrift |
| Korte beskeder | Alerts og bannere | Snackbars og dialoger |
| Push-tilladelse | Brugeren skal altid spørges | Skal spørges fra Android 13 |
Jeres designer skal kende retningslinjerne indgående, så I selv kan nøjes med hovedpunkterne. Fordelen ved at følge dem er, at brugerne allerede ved, hvordan appen virker, fordi den opfører sig som alle de andre apps på deres telefon. Vi bygger apps i React Native, hvor én kodebase dækker både iOS og Android, og hvor mange komponenter som datovælgere, tastatur og tilbage-funktion automatisk følger platformen. Designet laves derfor én gang, med enkelte bevidste tilpasninger pr. platform.
Hvilket navigationsmønster passer til jeres app?
De mest brugte navigationsmønstre i apps. De fleste apps kombinerer to: en fanebjælke til hovedområder og en stak til at gå i dybden.
| Mønster | Brug det når | Pas på |
|---|---|---|
| Fanebjælke i bunden | Appen har 3–5 hovedområder, brugeren skifter mellem | Flere end fem faner bliver trange og svære at ramme |
| Stak (push) | Brugeren går fra liste til detalje til redigering | For mange niveauer gør det svært at finde tilbage |
| Skuffemenu (hamburger) | Mange sjældent brugte sektioner, fx indstillinger | Det, der gemmes væk, bliver brugt mindre |
| Bundark (bottom sheet) | Hurtige valg eller detaljer uden at forlade skærmen | Lange formularer i et bundark føles klemte |
| Faner i toppen | Varianter af samme indhold, fx "aktive" og "afsluttede" | Svære at nå med tommelfingeren på store telefoner |
Vores holdning er enkel: hvis appen har mere end én hovedopgave, så brug en fanebjælke i bunden med tre til fem faner, og læg resten under en "Mere"- eller profilfane. Skuffemenuen er fristende, fordi alt kan være der, men netop derfor bliver den et sted, hvor funktioner gemmes og glemmes. Navngiv fanerne med ord, brugerne selv bruger, og hav altid både ikon og tekst.
Hvad skal være på plads, før app-designet går i gang?
- Én sætning om, hvem appen er til, og hvilket problem den løser.
- De 3–5 vigtigste opgaver, brugeren skal kunne udføre i første version.
- Hvordan I måler succes: fx antal bookinger, færre opkald eller aktive brugere pr. uge.
- Brugertyper: kunder, medarbejdere, administratorer, og hvad hver især skal kunne.
- Hvilke systemer appen skal tale med, fx e-conomic, MobilePay eller jeres eget ERP.
- Om der er brug for login, betaling, push-beskeder, kamera eller offline-adgang.
- Brand-materiale: logo, farver, skrifttyper, billeder og tone.
- Hvem hos jer der godkender design, og hvor hurtigt de kan svare.
Hvilke fejl ser vi oftest i app design?
- Login først: brugeren skal oprette en konto, før de har set, hvad appen kan.
- Alle tilladelser på én gang ved første opstart: push, placering og kamera, før der er en grund.
- Ingen plan for dårligt signal: skærme der fryser, og indtastninger der forsvinder.
- Fast skriftstørrelse: appen knækker, når brugeren har sat større tekst i telefonens indstillinger.
- Tekster der ikke er skrevet til mobil: lange afsnit, hvor én sætning ville være nok.
- Admin-siden er glemt: der er ingen steder at rette data, svare kunder eller sende beskeder.
- Ingen tomme tilstande og fejlbeskeder: kun "de lykkelige flows" er designet.
Onboarding og tilladelser
Spørg om tilladelser i det øjeblik, de giver mening. Bed om adgang til kameraet, når brugeren trykker "scan kvittering", og om push-beskeder, når de har booket en tid og gerne vil have en påmindelse. Forklar med én sætning, hvad de får ud af det, før systemets dialog vises. Siger brugeren nej, skal appen stadig fungere, og det skal være nemt at slå funktionen til senere. Det samme gælder onboarding: tre korte skærme, der viser værdien, er nok, og de skal kunne springes over.
Hvad koster app design?
Typisk tidsforbrug for designdelen af en app, beregnet med freelance UX-priser på 600–750 kr. i timen. Antallet af brugertyper og skærme driver prisen mest.
| Omfang | Typiske timer | Typisk pris |
|---|---|---|
| Afgrænset app, 10–15 skærme, én brugertype | 40–70 | 24.000–52.000 kr. |
| Mellemstor app, 20–40 skærme, to brugertyper | 80–150 | 48.000–112.000 kr. |
| Stor app med designsystem og flere brugertest | 150+ | 90.000 kr. og op |
Tallene er for design alene, når det købes separat. Hele appen ligger på det danske marked typisk på 50.000–150.000 kr. for en simpel app og 150.000–500.000 kr. for en mellemkompleks, og designet er en del af det. Et eksempel: en servicevirksomhed vil have en app, hvor kunder kan booke, flytte og betale for besøg. Det er tre hovedopgaver, én brugertype og et admin-panel på web. Designet lander i den første række, og hos os ligger hele løsningen inklusive design og udvikling i en af vores app-pakker fra 28.000 kr. plus drift. Læs hele prisbilledet i hvad koster en app.
Har I brug for en app i butikkerne, eller er en webapp nok?
Før I designer en app, er det værd at spørge, om brugerne vil installere den. Kunder, der bruger jer hver uge, gør det gerne. Kunder, der handler to gange om året, gør det sjældent, og her kan en mobilvenlig webløsning eller en PWA være et bedre første skridt. Medarbejdere installerer det, de bliver bedt om, så interne apps er ofte et oplagt valg, især når der er brug for kamera eller offline-adgang. Vi har sammenlignet mulighederne i webapp vs native app. Vælger I en app i butikkerne, så læs også om godkendelse i App Store, fordi visse designvalg påvirker, om appen bliver godkendt.
Hvordan arbejder vi med app design hos Ceptiv?
Hos os designer og bygger det samme senior-team appen, så det, der er tegnet i Figma, er det, der ender i hånden på brugeren. Vi starter med flows og wireframes med rigtige tekster, tester en klikbar prototype på telefonen og bygger derefter i React Native til både iOS og Android. For Kirppu byggede vi blandt andet en label-app ved siden af standbooking og et lejerpanel, og den slags værktøjer kræver præcis den form for enkle, hurtige flows, som denne guide handler om. Se, hvordan vi arbejder under React Native app-udvikling, eller få en fast pris inden for 24 timer.
