
De fem byggstenarna i ett user flow, hur du ritar ett och hur du genererar ett redigerbart flödesdiagram från en enkel beskrivning.
Varje produkt har vägar som folk följer för att få något gjort: registrera sig, betala, bjuda in en kollega, återställa ett lösenord. Ett user flow gör de vägarna synliga innan du lägger design- och utvecklingstid på dem.
Kort svar: Ett user flow är en karta över stegen någon tar för att slutföra en uppgift i en produkt: skärmar, handlingar och beslutspunkter, från ingång till slutläge. Det visar varje möjlig väg, även de som misslyckas. Du gör ett genom att skriva ner utlösaren, stegen i ordning, varje beslut som en ja/nej-fråga och slutlägena, och sedan rita dem som ett sammanhängande flöde.
Ett user flow är diagrammet över en enda uppgift, sedd från användarens sida. Det börjar där personen kommer in (en annons, en länk, ett tomt läge), går genom skärmarna och handlingarna, grenar sig vid varje beslut och slutar i ett tydligt resultat: klart, avbrutet eller fel. Ett flöde täcker en uppgift. "Hela appen" är inget user flow; "en ny användare skapar sitt första projekt" är det.
Team ritar dem av två skäl. Innan bygget avslöjar flödet saknade skärmar och återvändsgränder medan de är billiga att fixa. Efter lansering är flödet kartan du lägger bredvid din analytics: om 40 % hoppar av vid steget där man väljer plan vet du exakt vilken ruta det är.
Fem element räcker för nästan alla flöden. Det lilla ordförrådet är det som håller diagrammet läsbart.

Snabbaste vägen: skriv flödet som text först och bry dig om rutor sen. Logiken avgör om diagrammet håller; layouten gör det bara läsbart.
Steg 4 avgör de flesta flöden. Ett flöde utan förgreningar är en broschyr: det visar demovägen och gömmer produkten. Felvägarna är själva anledningen att göra diagrammet.
De tre blandas ihop för att alla har pilar. De svarar på olika frågor.
Tre format, en rad var
|Format|Vad det visar|Bäst för|
|---|---|---|
|User flow|Skärmar, handlingar och beslut i en uppgift|Designa eller granska en funktion|
|User journey map|Faser, känslor och kontaktpunkter över tid|Förstå kunden, inte skärmarna|
|Flödesschema|Vilken process som helst, utan användare eller skärmar|Interna processer och systemlogik|
Ett user flow är ett flödesschema med åsikter: rutorna är skärmar, aktören är användaren, slutlägena är produktresultat. Om det du kartlägger inte har en människa som gör val är ett vanligt flödesschema eller en processkarta det bättre formatet.

Kan du skriva flödet som text behöver du inte rita det alls. I SketchMind, en AI-whiteboard, väljer du Flow i Create with AI, beskriver uppgiften på vanligt språk och får en redigerbar flow-frame på din board på cirka 20 sekunder. Samma skrivande som ger ett bra flöde ger en bra prompt: utlösaren, stegen i ordning, besluten som ja/nej-frågor, slutlägena med misslyckandena. Fältet tar upp till 3 000 tecken, du kan bifoga en PDF på upp till 5 MB (en spec, en researchsammanfattning) och klistra in upp till tre publika länkar; resultatet skrivs utifrån dem. På en board som redan har anteckningar eller frames bygger "Use this board's content" vidare på det som finns. Framen förblir redigerbar: att döpa om en skärm eller lägga till en gren är en direkt redigering, och du kan presentera flödet direkt från boarden.
Senast uppdaterad: 8 oktober 2026. Kontrollerad mot den aktuella SketchMind-appen.
Ett user flow visar skärmar och beslut i en uppgift; en user journey map täcker hela relationen över tid, med känslor och kontaktpunkter utanför produkten. Flows är för att bygga, journeys för att förstå.
Rektanglar för skärmar och handlingar, romber för beslut, rundade former för ingång och slutlägen. Viktigare än konventionen är att använda samma form för samma sak hela vägen.
En uppgift ryms oftast i 5 till 15 steg. Över 20 kartlägger du förmodligen flera uppgifter samtidigt; dela upp dem i separata flöden.
Ja. I SketchMind väljer du Flow i Create with AI och beskriver uppgiften: utlösare, steg, beslut som ja/nej-frågor, slutlägen. På cirka 20 sekunder landar en redigerbar flow-frame på din board.
Nej. Rita dem för flöden med riktiga förgreningar eller riktig risk: onboarding, betalning, allt där användare misslyckas. En linjär funktion med två skärmar behöver inget diagram.