Food Trucks Stockholm Sweden

Hur man skapar ett product requirement document för en mobile app

Bra idéer är inte korta efterfrågan. Varje företag har sin syn på att bli nästa Uber eller Airbnb. Men verkligheten är att detta inte är en enkel uppgift. Om du vill skapa en produkt som säljer måste du bygga något som tillgodoser de uppenbara och inte så uppenbara behoven hos din publik.

Ett Product Requirement Document (PRD) kan hjälpa dig att uppnå detta.

Vad är Product Requirement Document?

Så, vad är ett dokument för produktkrav? Ett Product Requirement Document (PRD) definierar värdet och syftet med en mobilapp till dina produkt- och utvecklingsteam. Detta dokument är grunden för en framgångsrik produkt, som beskriver affärslogik, listar tekniska specifikationer och i slutändan hjälper ditt utvecklingsteam att förvandla ditt tidiga koncept till en fullt fungerande app.

Ny uppmaning till handling

Produktgrupper använder en PRD för att kommunicera vad man ska bygga, vem produkten är för och hur det gagnar slutanvändaren. Detta dokument styr utvecklingen av en produkt genom att ge en gemensam förståelse för avsikten bakom en produkt. Om dina produkt- och utvecklingsteam inte förstår din publik och deras smärtpunkter, hur kan de leverera produkter som löser rätt användarproblem? Ett produktkravsdokument klargör alla dina idéer innan något utvecklingsarbete påbörjas.

Även om det finns olika sätt att organisera dokumentet, tycker vi att det är fördelaktigt att inkludera affärskrav och tekniska krav, samt några andra överväganden som kommer att förbereda ditt teknikteam för att få din produkt på marknaden.

Den här artikeln guidar dig genom att skriva en PRD och fungerar som ett exempel på vad som gör ett imponerande kravdokument.

För att komma igång, ladda ner vår anpassningsbara PRD-mall .

Affärskrav

Företagskrav är kriterier som är nödvändiga för att uppfylla organisatoriska mål. Vanligtvis beskriver de hur produkten eller lösningen tillgodoser företagets och dess användares behov.

Följande överväganden som ska ingå vid kartläggning av företagskrav:

  • Vad är syftet med appen eller produkten? Vad försöker du åstadkomma?
  • Vilka är de nuvarande problemen som det kommer att lösa?
  • Hur kommer det att förbättra den nuvarande processen? Kommer det att underlätta en ny process?
  • Vad är produkt visions förklaringen?
  • Behöver appen startas från grunden, eller kan du utnyttja befintliga tillgångar?
  • Vad ska appen kunna göra? Vad är produktens kärn funktionalitet?
  • Vilka funktioner behöver den?
  • Vad är intäktsgenerering eller affärsmodell?
  • Finns det riktlinjer för branding och design att följa?
  • Är frågan genomförbar?

Mobil app mål

För det första kräver ditt produktkrav att du beskriver vad du vill att produkten ska göra samt produktens kärnmål. För den första versionen av valfri mobilapp rekommenderas att du fokuserar på ett enda problem som dina målanvändare upplever. Genom att koncentrera sig på ett kärnproblem är det lättare att skapa en kort produktvision för mobilappen och skapa exakta framgångsmått.

Inkludera användar flöden

I ditt produktkravsdokument måste du inkludera användarflödet i din app för varje typ av användare (till exempel admin, vanlig användare och gästanvändare). Från början till slut, hur kommer varje användargrupp att interagera med produkten?

Att skapa detaljerade användarresor är en samarbetsprocess och bör omfatta en affärsanalytiker, en användarupplevelsedesigner, en utvecklare och en produktchef. Kartläggning av användares resor hjälper till att kommunicera alla möjligheter i appen ur användarens perspektiv. Att skapa rätt berättande beröringspunkter är viktigt för att förfina produktens funktionalitet.

Behöver du hjälp med att kartlägga användarens flöde för din produkt? Att delta i en Design & Discovery-workshop ger dig en visuell lösning som beskriver användarupplevelsen och användargränssnittet för din produkt. Prata med en mobilexpert om att skapa användarresor idag. Starta en konversation.

Vad är ditt produkt visions uttalande?

En vision uttalande definierar en tydlig riktning mot mobilappens slutmål. Utöver det beskriver ett visionuttalande lösningen på problemet som dina avsedda användare står inför. I ditt visionuttalande måste du inkludera vem produkten är för, vad användaren försöker åstadkomma, hur produkten kommer att lösa användarens smärtpunkter och hur produkten skiljer sig från konkurrerande appar på marknaden.

Skapa en lista över funktioner

Den första versionen av din mobilapp måste erbjuda en enkel och intuitiv användarupplevelse. Att välja funktioner för din mobilapp är en planeringsprocess som kräver att du definierar produktvision, mål och teman helt. Vissa standardfunktioner kan inkludera:

  • Registrering och inloggning
  • Ombordstigning
  • Startbild
  • Navigering
  • Bildgallerier
  • Formulär
  • Integration av sociala medier
  • Sociala flöden
  • Produktmenyer
  • Kundvagnar och betalningar
  • Lojalitetskort
  • Bokningssystem
  • Kalenderintegrationer
  • Pushnotifikationer
  • Inbyggd video
  • Inbyggda kartor
  • Enhetens maskinvaruåtkomst
  • Appanalys

Listan ovan är endast en liten lista över potentiella funktioner du kan behöva. Att förstå hur en användare ska navigera genom din app är avgörande för att identifiera nödvändiga funktioner som möjliggör en sömlös användarupplevelse.

Vad är din intäktsmodell?

Det finns flera intäktsgenereringsstrategier värda att utforska. Den strategi du väljer beror på vilken typ av app du utvecklar, din målanvändare och till och med det mobila operativsystem du vill använda. Det finns fem konventionella intäktsmodeller:

  • Reklam
  • Betala per nedladdning
  • Köp i appen
  • Freemium
  • Prenumerationer

Produkt- och tekniska specifikationer

Produkt- och tekniska specifikationer beskriver de systemiska och funktionella behoven för att produkten ska uppnå de önskade funktionerna och funktionerna.

Bestäm följande i produkt- / tekniska specifikationer för ditt mobilapps kravdokument:

  • Vilka plattformar kommer appen att använda (iOS, Android eller Windows)?
  • Vilka operativsystem versioner bör stödja den?
  • Vilka är dina nuvarande tjänster, servrar, databaser?
  • Vilka är dina underhållsbehov? Behöver du stödja det för framtiden?
  • Hur länge ska appen fungera innan en översyn behövs?
  • Har du aktuell dokumentation om API / tjänster?
  • Har du aktuella Apple-, Google- eller andra utvecklar konton / referenser?
  • Har du befintliga provisionerings profiler?
  • Finns det andra uppgifter som behövs eller redan finns (analyssystem eller plattformar)?

Välja en plattform

Den idealiska metoden för utveckling är att lansera på båda plattformarna; det är dock inte alltid möjligt. Ibland måste du först utveckla för en plattform och introducera en andra plattform senare av skäl som tidsbegränsningar, budget och resursbegränsningar.

Både iOS och Android erbjuder tydliga fördelar, men lockar också kontrasterande användare. När du bestämmer vilken plattform som är bäst för din mobilapp är en viktig fråga att ställa: vad är syftet med din applikation? Är användarvolymen den viktigaste identifieraren för framgång för din app, eller är ditt fokus på att driva engagemang? Att välja lämplig plattform beror på målet du försöker uppnå och hur du planerar att tjäna pengar på din mobilapp.

Inkludera dina underhålls- och uppgraderings krav

Gör inte misstaget att tro att ditt projekt är klart efter lanseringen. Åtminstone måste du planera för kostnaden för att underhålla din app för att åtgärda buggar och uppfylla systemkrav. I din PRD, inkludera en långsiktig produktvision som tar hänsyn till användarnas krav, produktförbättringar och nya funktioner för framtida iterationer av produkten.

Beroenden

Beroenden är alla aspekter som produkten eller produktteamet förlitar sig på för att uppfylla målen. Dessa kan inkludera:

  • Hårdvara som appen kommer att köras på / kommunicera med.
  • Service / API-dokumentation
  • Profil / konto / plattforms information
  • Alla program från tredje part som din app är beroende av
  • Eventuella flödesscheman, dokument eller information relaterad till produkten

Antaganden

Antaganden avser vanligtvis hur produktgrupper misstänker att användare kommer att bete sig eller interagera med sin produkt. Det är dock viktigt att ta med antaganden om produktens affärsmässiga och tekniska aspekter i detta avsnitt. I ett tidigt skede av ett projekt antas kunskap, erfarenhet eller aktuell information. Exempel på dessa antaganden kan vara:

X% av användarna ser tillräckligt med värde i produkten för att bli vanliga användare
Tekniska krav A fungerar på det senaste operativsystemet
Vi kan utveckla produkten inom en föreslagen tidsram

Begränsningar

Begränsningar är de begränsningar som team måste arbeta inom, vanligtvis relaterade till omfattning, budget och tid. De kan dock också inkludera aspekter som risktolerans, resurser / personal och kvalitetskrav.

Submission

Ditt krav på mobilapp ska innehålla alla tekniska tillgångar och information som krävs för Apples inlämning av App Store och inlämning av Google Play. Att definiera dessa krav i ett tidigt skede av ett projekt kommer att påskynda inlämningsprocessen avsevärt när produkten är redo att släppas. Även om dessa kommer att variera beroende på vilka appbutiker som skickas till, nedan är tillgångarna och informationen som ska inkluderas för Apple App Store och Google Play.

Allmänna tillgångar

  • Ikoner med stödda storlekar (iOS: @ 1x @ 2x @ 3x bilder | Android: mdpi, hdpi, xhdpi, xxhdpi)
  • Stänkskärmar av rekommenderade storlekar (iOS: @ 1x @ 2x @ 3x bilder | Android: mdpi, hdpi, xhdpi, xxhdpi)
  • Skärmdumpar i rätt dimensioner och språk
  • Appbeskrivningar på obligatoriska språk
  • Sökord på önskade språk
  • Lista över enheter och OS-versioner som stöds

Apple App Store

  • iTunes Connect-kontoåtkomst
  • Företags / enhetens namn
  • App Store-listans namn
  • Sökord
  • Paket-id / SKU
  • Demokonto för granskare
  • Beskrivning
  • Support-URL
  • Marknadsförings-URL
  • Integritetspolicy
  • Appkategori
  • Upphovsrättsinformation
  • Kontaktinformation
  • Appikon (1024 × 1024)
  • App Store-distributionsprofil
  • App Store-distributionskodsidentitet
  • Skärmdumpar (rätt storlekar baserat på enheter)

Google Play

  • Tillgång till Google Play-utvecklare
  • Butiksförteckningens namn
  • Betald / gratis
  • Kort beskrivning
  • Full beskrivning
  • Appikon (512 × 512)
  • Funktionsgrafik (1024 × 500)
  • Apptyp
  • Appkategori
  • Innehållsbetyg
  • Kontakta e-post
  • Integritetspolicy
  • Skärmdumpar (rätt storlekar baserat på enheter)

Saker att tänka på för ditt produktdokument

När du skriver ditt produktkrav ska du tänka på några överväganden. För det första är det viktigt att använda en mängd olika erfarenheter och insikter som kommer från flera teammedlemmar. Att samla in denna input hjälper dig att utveckla omfattande definitioner för olika delar av PRD-mallen.

För det andra, när du fyller i PRD-mallen, se till att hålla dina svar och definitioner för varje beskrivet avsnitt på hög nivå. Medan detaljer är användbara, kom ihåg att även om specifika krav kan tyckas uppenbara för dig, kan andra som tittar på dokumentet ha ett helt annat perspektiv. Att eliminera branschspecifika termer kommer att säkerställa att alla enkelt kan förstå dokumentet. När produkten utvecklas och kraven förändras är det viktigt att alla förstår vad du försöker kommunicera för att utveckla en framgångsrik mobilprodukt.

Slutgiltiga tankar

Tänk på att de bästa dokumenten för produktkrav är anpassningsbara. Även om detta kan verka kontraintuitivt, är det inte lätt att göra en PRD perfekt. Det är därför det är så viktigt att följa en struktur. Börja processen med de allmänna kriterierna, din slutanvändare, problemet du löser. Då blir allt mer specifika, detaljerade funktioner och önskade funktioner för en MVP. De allmänna kriterierna är vad som ställs i sten, men när du går igenom processen, var beredd att anpassa dina mer specifika krav.

Det slutgiltiga målet med att skapa ett dokument för mobilappskrav är att ge en grund för en framgångsrik produkt. För att ge ditt team den ammunition som behövs för att få ditt projekt från marken, se till att du kartlägger alla affärs- och tekniska krav och klargör alla beroenden, begränsningar och antaganden. Under utvecklingen kommer frågor att komma upp, även med det mest noggranna dokumentet om produktkrav.

Under processen att definiera produkten är det viktigt att alltid fokusera på att leverera överlägset värde till marknaden. Det är lätt att bli distraherad av konkurrenter, kunder och arkitektoniska frågor, och medan du behöver förstå dessa behov, när det gäller att definiera en bra produkt, kom alltid ihåg att fokusera på värdet.


Posted

in

, , ,

by

Comments

One response to “Hur man skapar ett product requirement document för en mobile app”

  1. akshat bakliwal Avatar

    Thank you for the information. Online Training

Leave a Reply to akshat bakliwal Cancel reply

Your email address will not be published. Required fields are marked *