Specifikacija mobilne aplikacije: predloga na eni strani

Specifikacija mobilne aplikacije: kratek odgovor

Dobra specifikacija mobilne aplikacije, ko delaš svojo lastno aplikacijo, gre na eno stran. Odgovori na deset vprašanj: za koga, kateri problem, katera glavna funkcija, kako aplikacija služi denar, kaj se zgodi brez računa, kateri podatki morajo preživeti, na kateri platformi, kaj ni del prve različice, kako boš vedel, da deluje, in s katerimi omejitvami. Predloga za kopiranje je spodaj. Lahko pa tudi preneseš predlogo in njeno preverjalno tabelo (.md), brez registracije.

Predloge na 40 straneh, ki jih najdeš na spletu, so napisane za drug namen: za naročnika, ki aplikacijo naroči pri izvajalcu in potrebuje pogodbeni dokument. Ti pa si hkrati tisti, ki odloča, in tisti, ki gradi, pogosto s pomočjo AI. Tvoja specifikacija služi dvema stvarema: da sprejmeš odločitve, preden začneš programirati, in da Claudu, ChatGPT-ju ali Cursorju daš jasen kontekst, da zgradijo pravo aplikacijo.

Objavljam svoje iOS aplikacije. Solys, budilka z mini igrami, in TradaZen, simulator trgovanja, sta na App Store. Nolera in Clic je Apple zavrnil, nato sem ju popravil. To je metoda, ki jo uporabljam pri vsaki od njih, in to je tista, ki ti jo predlagam tukaj.

Zakaj ena stran zadostuje za zamejitev tvoje aplikacije

Dolg dokument daje občutek, da si napredoval. V praksi ga napišeš enkrat, redko ga ponovno prebereš, projekt pa se od njega oddalji že v prvih tednih. Eno stran pa prebereš v dveh minutah pred vsako delovno sejo.

Omejen prostor ima tudi koristen učinek: prisili te, da se odločiš. Če odgovor preseže dva stavka, to pogosto pomeni, da odločitev še ni sprejeta. Bolje, da to odkriješ na listu papirja kot v svoji kodi tri tedne pozneje.

In nazadnje, ena stran je prava velikost za AI. Lahko jo v celoti prilepiš v pogovor ali jo shraniš v kontekstno datoteko projekta. Kratek dokument olajša pregled in zmanjša protislovna navodila. Ne zagotavlja pa, da jim bo AI sledil: njegove predloge preveri glede na ta okvir.

Kaj mora vsebovati specifikacija mobilne aplikacije?

Na vsako od teh vprašanj odgovori v enem ali dveh stavkih.

1. Kdo uporablja aplikacijo in v kakšni situaciji? Ne »18- do 35-letniki«. Raje konkretna oseba v konkretnem trenutku dneva.
2. Kateri problem aplikacija rešuje, v enem stavku? Če potrebuješ »in še«, opisuješ dve aplikaciji.
3. Katera je TA glavna funkcija prve različice? Ena sama. Ostale bodo počakale na številke. Stran MVP iOS aplikacije razloži, kako izbrati.
4. Kako aplikacija služi denar? Naročnina, enkratni nakup ali brezplačno. Ta odgovor spremeni aplikacijo že od prvega zaslona. Če omahuješ, preberi naročnina ali enkratni nakup za iOS aplikacijo.
5. Kaj lahko narediš brez ustvarjanja računa? Če zgodaj odločiš, kaj je dostopno brez registracije, ti ne bo treba predelovati celotnega uvajanja.
6. Kateri podatki morajo preživeti menjavo telefona? To je vprašanje, ki odloči, ali potrebuješ backend, kot je Supabase, ali pa lahko vse ostane na napravi.
7. Samo iOS ali iOS in Android? Moj nasvet, ko začenjaš: najprej iOS. Zakaj, razložim v iOS in Android aplikacija hkrati.
8. Kaj je izrecno IZVEN prve različice? Najkoristnejši del dokumenta. Prekine debate, še preden se začnejo, tako s samim sabo kot z AI.
9. Kako boš vedel, da deluje? En sam signal, merljiv v tednih po izidu: začeti brezplačni preizkusi, naročniki, uporabniki, ki se vračajo.
10. Katere so tvoje dejanske omejitve? Čas, ki ga lahko temu nameniš vsak teden, tvoja oprema in tvoj Apple Developer račun, ki stane 99 $ na leto. Nimaš Maca? To te ne ustavi, kot razložim v objavi iOS aplikacijo brez Maca.

Predloga specifikacije za kopiranje

To predlogo kopiraj v zapisek ali v besedilno datoteko v korenu projekta, nato zamenjaj vsako vrstico.

• Začasno ime aplikacije: …
• Za koga: oseba, ki … v trenutku, ko …
• Rešeni problem, v enem stavku: …
• Glavna funkcija različice 1: …
• Kaj uporabnik vidi, ko prvič odpre aplikacijo: …
• Poslovni model: naročnina / enkratni nakup / brezplačno, in kaj je plačljivo: …
• Brez računa lahko: …
• Podatki, ki se ohranijo med dvema telefonoma: nobeni / …
• Platforma: najprej iOS (Android pozneje, če številke sledijo)
• Izven različice 1: …, …, …
• Signal uspeha: …
• Stack: React Native, Expo, Supabase, če potrebuješ račune, RevenueCat za naročnine
• Omejitve: … ur na teden, Apple Developer račun odprt ali ne, Mac ali ne
• Aplikacije, katerih izkušnja mi je všeč, in zakaj: …

Dodaj tri do pet posnetkov zaslona aplikacij, ki so ti všeč, z besedo o tem, kaj ti je pri njih všeč. To pove več kot celostna grafična podoba, tako tebi kot AI.

Specifikacija ni seznam želja. Je seznam sprejetih odločitev.

Primer: izpolnjena stran za izmišljeno aplikacijo

Da vidiš pričakovano raven podrobnosti, je tu predloga, izpolnjena za aplikacijo, izmišljeno za primer: časovnik za učenje.

• Za koga: študent, ki se zvečer uči sam in po desetih minutah izgubi zbranost.
• Problem: ne zdrži delovne seje, ne da bi prijel telefon.
• Glavna funkcija: zagnati časovno merjeno sejo in videti svoj niz zdržanih dni.
• Prvi zaslon: en sam gumb za začetek seje.
• Poslovni model: naročnina za podrobno statistiko, osnovna seja brezplačna.
• Brez računa: vse, razen varnostne kopije med dvema telefonoma.
• Izven različice 1: skupinski način, lestvica med prijatelji, pripomočki (widgeti), različica za Android.
• Signal uspeha: uporabniki, ki se vračajo več dni zapored.

Opazi, kaj namerno manjka: noben seznam dvajsetih zaslonov, nobena vsiljena barva, nobena arhitektura. Te odločitve bodo prišle med gradnjo, stran pa ti služi za preverjanje, da ostajajo v službi glavne funkcije.

Kako s specifikacijo voditi AI

Tukaj ti stran prinese največ. AI, ki programira brez konteksta, ugiba, in pogosto ugane neko drugo aplikacijo, ne tvoje.

Stran vstavi v stalni kontekst projekta. Claude Code bere datoteko CLAUDE.md v korenu, Cursor ima svoje datoteke s pravili. Tja prilepi svojo specifikacijo, skupaj s stackom. Vsaka zahteva potem izhaja iz iste osnove.

Ko AI pretirava, citiraj razdelek »izven različice 1«. Asistenti radi predlagajo dodatne funkcije: temni način, deljenje, obvestilo. Tvoj seznam izključitev ti da pripravljen odgovor: ne zdaj.

Zahtevaj načrt, ki spoštuje stran. Pred večjim delom napiši: »to je moja specifikacija, predlagaj načrt za glavno funkcijo, ne programiraj še«. Takoj opaziš, če se načrt oddaljuje od tega, kar si odločil.

Naj pregleda stran, ne samo kode. Vprašaj: »katera vprašanja v tej specifikaciji so nejasna ali protislovna?«. To je podcenjena uporaba AI in ti prihrani tedne dela v napačno smer.

Če želiš več o tej temi, sem pasti in preverjanja podrobno opisal v ustvari iOS aplikacijo z AI.

Odločitve spremeni v merila za preverjanje

Glavna funkcija mora imeti opazen rezultat. Za izmišljeni časovnik iz tega primera je »časovnik deluje« preveč ohlapno. Raje napiši: »Zaženem sejo, prikaže se preostali čas, lahko jo ustavim in po ponovnem odprtju aplikacije najdem zadnjo končano sejo.« Posebej se odloči, ali mora časovnik teči tudi pri zaklenjenem zaslonu: ta izbira lahko spremeni tehnično delo.

Za vsako funkcijo dodaj tri vrstice: dejanje, pričakovani rezultat, dokaz. Dokaz je lahko avtomatiziran test za izračun ali preverjanje na napravi za potek. Zapiši tudi, kaj ni bilo testirano. Ta mala tabela prepreči, da bi zamenjal dokončan zaslon s funkcijo, pripravljeno za uporabo.

Tukaj je izpolnjena tabela za naš izmišljeni časovnik. To so merila za preverjanje, ne že opravljeni testi:

Odločitev iz zamejitve	Kaj testirati	Pričakovani rezultat
Osnovna seja je dostopna brez računa	Namesti aplikacijo in zaženi sejo brez registracije	Noben obrazec za registracijo ne blokira začetka
Opuščena seja se ne šteje v niz	Ustavi sejo pred koncem, nato odpri zgodovino	Nobena končana seja ni dodana
Zgodovina ostane na napravi	Končaj sejo, zapri in ponovno odpri aplikacijo	Seja se prikaže samo enkrat, s pravilnim trajanjem
Osnovni časovnik deluje brez omrežja	Vklopi letalski način in končaj sejo	Časovnik in lokalno shranjevanje ostaneta uporabna
Podrobna statistika je plačljiva	Odpri statistiko brez naročnine	Prikaže se ponudba; osnovna seja ostane dostopna

Teme, ki so še nejasne, postanejo odločitve, ki jih je treba sprejeti. Na primer: kaj storiti, če uporabnik med sejo zaklene zaslon ali spremeni uro na telefonu? Ne dovoli, da agent tiho izbere sam. Zapiši želeno vedenje, nato primer dodaj v tabelo. Da to preverjanje organiziraš na pravi namestitvi, uporabi vodič testiraj svojo iPhone aplikacijo s TestFlight.

Odloči, kaj odstraniti, ko prva različica preraste okvir

Vzemi vsako funkcijo in si postavi vprašanje: »Ali lahko uporabnik brez nje še vedno doseže obljubljeni rezultat?« Pri našem časovniku lahko lestvica med prijatelji počaka. Najti končano sejo je nujno, če obljubljaš niz dni. Zaslon za naročnino postane nujen samo, če statistiko dejansko prodajaš že v tej različici.

Odločitev in njen razlog zapiši v dnevnik predloge za prenos. K tej izbiri se lahko vrneš po testih, ne da bi izgubil razlog za prvotni obseg. Vodič ustvari aplikacijo s Claude Code nato pokaže, kako to zamejitev spremeniti v omejene in preverljive zahteve.

Za izkušnjo iz prakse: TradaZen je po objavi spremenil obseg. Zamejitev služi temu, da izdaš merljivo prvo različico, nato pa o naslednji odločaš na podlagi resničnih odzivov.

Past kataloga funkcij

Naravni refleks je našteti vse, kar bo aplikacija »morala početi«: zemljevid, klepet, obvestila, priporočila, način brez povezave. Ta katalog je najzanesljivejši znak projekta, ki ne bo dokončan, iz preprostega razloga: vsaka funkcija, dodana pred izidom, zamakne trenutek, ko ti pravi uporabniki povedo, kaj šteje.

Dobra prva različica naredi eno stvar in jo naredi dobro. Pazi pa na nasprotno skrajnost: Apple zahteva, da aplikacija ponudi več kot zapakirano spletno stran, v skladu s pravilom 4.2 App Review Guidelines. Ena sama glavna funkcija, da; prazna lupina, ne: to je razlog za guideline 4.2.

Česa specifikacija mobilne aplikacije ne sme vsebovati

• Celotne celostne grafične podobe. Za začetek zadošča nekaj referenčnih posnetkov zaslona.
• Urnika dan za dnem. Še nimaš informacij, da bi se ga držal. Tedenski cilj zadošča.
• Podrobne tehnične arhitekture. Izberi preizkušen stack, podrobnosti pa naj se odločijo med gradnjo.
• Funkcij »za pozneje«, pomešanih z ostalim. Vse gredo v razdelek izven različice 1.

Kdaj posodobiti specifikacijo?

Preberi jo na začetku vsakega delovnega tedna. Posodobi jo samo, ko se odločitev spremeni iz pravega razloga: test na tvojem iPhonu, ki pokaže, da zaslon ne deluje, odziv testerja, Applova omejitev, odkrita med potjo. Če jo spreminjaš vsak dan, ne zamejuje več ničesar.

Ko je prva različica objavljena, stran postane osnova za naslednjo: kar je bilo izven različice 1, se premakne gor, razvrščeno glede na to, kar ti povedo številke. Celoten pregled poti, od ideje do objave, je na strani ustvari iPhone aplikacijo.

Od strani do objavljene aplikacije

Če si odgovoril na deset vprašanj, si že opravil delo, ki ga veliko projektov preskoči. Naprej sledi gradnja glavne funkcije, testiranje na tvojem iPhonu, priklop naročnin in priprava dokumentacije za Apple.

To je pot iOS Kit, v štirih korakih, ki jim slediš v svojem tempu: prvi služi izbiri aplikacije, ki lahko prinaša denar, njenega občinstva in cene, tvoja specifikacija pa je njegovo izhodišče.

Ne veš, ali je tvoja ideja pripravljena, da gre na eno stran? Brezplačna diagnostika ti pove, kaj danes blokira tvoj projekt in kateri korak se lotiti najprej. Domača stran nato pokaže, kako ustvariti mobilno aplikacijo iz te zamejitve, s Claude Code.

Ne obljubljam ti ne zaslužka ne objave: odobri Apple, o ostalem pa odloči trg. Tudi brez kompleta ti ta predloga zadošča za začetek.

Pogosta vprašanja

Kako napisati specifikacijo za mobilno aplikacijo?

Specifikacijo omeji na eno stran: deset vprašanj, en ali dva stavka na odgovor. Nanašajo se na občinstvo, problem, glavno funkcijo, poslovni model, kaj se zgodi brez računa, podatke, ki morajo preživeti, platformo, kaj je izven prve različice, signal uspeha in omejitve. Če odgovor preseže dva stavka, to pogosto pomeni, da odločitev še ni sprejeta.

Kateri program uporabiti za pisanje specifikacije aplikacije?

Preprost zapisek ali besedilno datoteko v korenu projekta: vanjo kopiraš predlogo, nato zamenjaš vsako vrstico. Lahko pa tudi preneseš predlogo in njeno preverjalno tabelo (.md), brez registracije. Da z njo vodiš AI, jo nato shrani v kontekstno datoteko projekta.

Ali aplikacija potrebuje specifikacijo na 40 straneh?

Ne, ko delaš svojo lastno aplikacijo: ena stran zadošča. Predloge na 40 straneh, ki jih najdeš na spletu, so napisane za naročnika, ki aplikacijo naroči pri izvajalcu in potrebuje pogodbeni dokument. Ti odločaš in gradiš: tvoja stran služi temu, da sprejmeš odločitve pred programiranjem in daš AI kontekst.

Kako dati specifikacijo AI, ki programira?

Stran vstavi v stalni kontekst projekta: Claude Code bere datoteko CLAUDE.md v korenu, Cursor ima svoje datoteke s pravili. Ko AI pretirava, citiraj razdelek »izven različice 1«. Pred večjim delom zahtevaj načrt, ki spoštuje stran, brez takojšnjega programiranja.

Kako preveriti, ali funkcija ustreza specifikaciji?

Za vsako funkcijo dodaj tri vrstice: dejanje, pričakovani rezultat in dokaz. Dokaz je lahko avtomatiziran test za izračun ali preverjanje na napravi za potek. Zapiši tudi, kaj ni bilo testirano, da ne zamenjaš dokončanega zaslona s funkcijo, pripravljeno za uporabo.

Česa ne smeš dati v specifikacijo aplikacije?

Štiri stvari, ki se jim izogni: celotna celostna grafična podoba, urnik dan za dnem, podrobna tehnična arhitektura in funkcije »za pozneje«, pomešane z ostalim. Za začetek zadošča nekaj referenčnih posnetkov zaslona, za urnik pa tedenski cilj. Funkcije za pozneje gredo vse v razdelek izven različice 1.