Mobilalkalmazás specifikáció: egyoldalas sablon

Mobilalkalmazás specifikációja: a rövid válasz

Ha a saját appodat készíted, egy jó mobilalkalmazás-specifikáció elfér egy oldalon. Tíz kérdésre válaszol: kinek szól, milyen problémát old meg, mi a fő funkció, hogyan termel pénzt az app, mi történik fiók nélkül, milyen adatoknak kell megmaradniuk, melyik platformra készül, mi marad ki az első verzióból, honnan tudod, hogy működik, és milyen korlátaid vannak. A másolható sablon lejjebb található. A vázlatot és az ellenőrző táblázatát (.md) le is töltheted, regisztráció nélkül.

A neten talált 40 oldalas sablonok más célra készültek: annak az ügyfélnek, aki egy fejlesztőtől rendel appot, és szerződéses dokumentumra van szüksége. Te egyszerre döntesz és építesz, gyakran AI segítségével. A te specifikációd két dologra való: hogy kódolás előtt meghozd a döntéseket, és hogy a Claude, a ChatGPT vagy a Cursor tiszta kontextust kapjon, és a megfelelő appot építse meg.

Saját iOS appokat adok ki. A Solys, egy minijátékos ébresztőóra, és a TradaZen, egy tőzsdei szimulátor, fent vannak az App Store-ban. A Nolerát és a Clicet az Apple elutasította, aztán kijavítottam őket. Mindegyiknél ezt a módszert alkalmazom, és most neked is ezt ajánlom.

Miért elég egy oldal a saját appod megtervezéséhez?

Egy hosszú dokumentum azt az érzést kelti, hogy haladtál. A gyakorlatban egyszer megírod, ritkán olvasod újra, és a projekt már az első hetekben eltávolodik tőle. Egy oldalt viszont két perc alatt átfutsz minden munkamenet előtt.

A helyszűkének hasznos hatása is van: döntésre kényszerít. Ha egy válasz két mondatnál hosszabb, az gyakran azt jelenti, hogy a döntés még nem született meg. Jobb ezt egy papíron felfedezni, mint a kódodban, három héttel később.

Végül egy oldal pont jó méret az AI-nak. Bemásolhatod egészben egy beszélgetésbe, vagy beteheted a projekted kontextusfájljába. Egy rövid dokumentumot könnyebb átnézni, és kevesebb benne az ellentmondásos utasítás. Azt viszont nem garantálja, hogy az AI követni is fogja: ellenőrizd a javaslatait ehhez a kerethez képest.

Mit tartalmazzon egy mobilalkalmazás specifikációja?

Mindegyik kérdésre egy-két mondatban válaszolj.

1. Ki használja az appot, és milyen helyzetben? Nem „a 18-35 évesek”. Inkább egy konkrét ember, a napja egy konkrét pillanatában.
2. Milyen problémát old meg az app, egy mondatban? Ha kell az „és még”, akkor két appot írsz le.
3. Mi AZ első verzió fő funkciója? Csak egy. A többi megvárja a számokat. Az iOS app MVP oldal elmagyarázza, hogyan válassz.
4. Hogyan termel pénzt az app? Előfizetés, egyszeri vásárlás vagy ingyenes. Ez a válasz már az első képernyőtől megváltoztatja az appot. Ha bizonytalan vagy, olvasd el: előfizetés vagy egyszeri vásárlás egy iOS appnál.
5. Mit lehet csinálni fiók létrehozása nélkül? Ha korán eldöntöd, mi érhető el regisztráció nélkül, nem kell újraépítened az egész belépési folyamatot.
6. Milyen adatoknak kell túlélniük egy telefoncserét? Ez a kérdés dönti el, kell-e backend, például Supabase, vagy maradhat minden a készüléken.
7. Csak iOS, vagy iOS és Android? A tanácsom kezdőként: először iOS. Hogy miért, azt az iOS és Android app egyszerre cikkben részletezem.
8. Mi marad kifejezetten KI az első verzióból? Ez a dokumentum leghasznosabb része. Elvágja a vitákat, mielőtt kialakulnának, saját magaddal és az AI-jal is.
9. Honnan fogod tudni, hogy működik? Egyetlen jel, ami a megjelenést követő hetekben mérhető: elindított ingyenes próbaidőszakok, előfizetők, visszatérő felhasználók.
10. Mik a valódi korlátaid? Mennyi időt tudsz rá szánni hetente, milyen eszközeid vannak, és az Apple Developer fiókod, ami évi 99 dollárba kerül. Nincs Maced? Ez nem akadály, ahogy a iOS app kiadása Mac nélkül cikkben elmagyarázom.

A másolható specifikációsablon

Másold be ezt a sablont egy jegyzetbe vagy egy szövegfájlba a projekted gyökerében, aztán töltsd ki minden sorát.

• Az app ideiglenes neve: …
• Kinek: egy embernek, aki … amikor …
• A megoldott probléma, egy mondatban: …
• Az 1. verzió fő funkciója: …
• Amit a felhasználó lát, amikor először megnyitja az appot: …
• Üzleti modell: előfizetés / egyszeri vásárlás / ingyenes, és mi a fizetős: …
• Fiók nélkül lehet: …
• Két telefon között megőrzendő adatok: nincs / …
• Platform: először iOS (Android később, ha a számok igazolják)
• Kimarad az 1. verzióból: …, …, …
• A siker jele: …
• Stack: React Native, Expo, Supabase, ha fiókok kellenek, RevenueCat az előfizetésekhez
• Korlátok: … óra hetente, van-e már Apple Developer fiók, van-e Mac
• Appok, amelyeknek szeretem az élményét, és miért: …

Tegyél mellé három-öt képernyőképet olyan appokról, amelyeket szeretsz, egy-egy szóval arról, mi tetszik bennük. Ez többet mond egy arculati kézikönyvnél, neked és az AI-nak is.

A specifikáció nem kívánságlista. Hanem a meghozott döntések listája.

Példa: kitöltött oldal egy kitalált apphoz

Hogy lásd, milyen részletességre van szükség, íme a sablon kitöltve egy példának kitalált appra, egy tanulási időzítőre.

• Kinek: egy egyetemistának, aki este egyedül tanul, és tíz perc után elkalandozik.
• Probléma: nem bír ki egy tanulási blokkot anélkül, hogy a telefonjához nyúlna.
• Fő funkció: időzített tanulási blokk indítása, és a megtartott napok sorozatának megjelenítése.
• Első képernyő: egyetlen gomb egy blokk indításához.
• Üzleti modell: előfizetés a részletes statisztikákért, az alap blokk ingyenes.
• Fiók nélkül: minden, kivéve a két telefon közötti mentést.
• Kimarad az 1. verzióból: csoportos mód, rangsor a barátok között, widgetek, Android-verzió.
• A siker jele: felhasználók, akik több egymást követő napon visszatérnek.

Figyeld meg, mi hiányzik szándékosan: nincs húszképernyős lista, nincsenek kötelező színek, nincs architektúra. Ezek a döntések építés közben jönnek, az oldal pedig arra jó, hogy ellenőrizd: továbbra is a fő funkciót szolgálják.

Hogyan irányítsd az AI-t a specifikációddal?

Itt hozza a legtöbbet az oldalad. Egy kontextus nélkül kódoló AI találgat, és gyakran egy egészen másik appot talál ki, mint a tiéd.

Tedd az oldalt a projekt állandó kontextusába. A Claude Code beolvas egy CLAUDE.md fájlt a gyökérből, a Cursornak saját szabályfájljai vannak. Másold be oda a specifikációdat a stackeddel együtt. Így minden kérés ugyanabból az alapból indul.

Hivatkozz a „kimarad az 1. verzióból” részre, amikor az AI túlzásba esik. Az asszisztensek szívesen javasolnak plusz funkciókat: sötét módot, megosztást, értesítést. A kizárási listád kész választ ad: most nem.

Kérj olyan tervet, ami tiszteletben tartja az oldalt. Egy nagyobb munka előtt írd be: „itt a specifikációm, javasolj tervet a fő funkcióhoz, még ne kódolj”. Azonnal látod, ha a terv eltávolodik attól, amit eldöntöttél.

Ne csak a kódot nézesd át vele, hanem az oldalt is. Kérdezd meg: „ebben a specifikációban mely kérdések homályosak vagy ellentmondásosak?”. Ez az AI egyik alábecsült felhasználási módja, és heteknyi rossz irányba végzett munkától kímél meg.

Ha tovább mennél ebben a témában, a buktatókat és az ellenőrzéseket a iOS app készítése AI-jal cikkben részleteztem.

A döntések átalakítása elfogadási kritériumokká

Egy fő funkciónak megfigyelhető eredménnyel kell járnia. A példa kitalált időzítőjénél „az időzítő működik” túl homályos. Írd inkább ezt: „Elindítok egy blokkot, megjelenik a hátralévő idő, le tudom állítani, és az app újranyitása után megtalálom az utolsó befejezett blokkot.” Külön döntsd el, hogy az időzítőnek zárolt képernyőnél is futnia kell-e: ez a döntés megváltoztathatja a technikai munkát.

Minden funkcióhoz írj három sort: művelet, elvárt eredmény, bizonyíték. A bizonyíték lehet automatizált teszt egy számításnál, vagy ellenőrzés a készüléken egy folyamatnál. Azt is jegyezd fel, mit nem teszteltél. Ez a kis táblázat megakadályozza, hogy összekeverd a kész képernyőt a használatra kész funkcióval.

Íme egy kitöltött táblázat a kitalált időzítőnkhöz. Ezek ellenőrizendő kritériumok, nem már sikeres tesztek:

Tervezési döntés	Mit tesztelj	Elvárt eredmény
Az alap blokk fiók nélkül elérhető	Telepítsd az appot, és indíts egy blokkot regisztráció nélkül	Semmilyen regisztrációs űrlap nem akadályozza az indítást
A félbehagyott blokk nem számít bele a sorozatba	Állíts le egy blokkot a vége előtt, majd nyisd meg az előzményeket	Nem kerül be új befejezett blokk
Az előzmények a készüléken maradnak	Fejezz be egy blokkot, zárd be, majd nyisd meg újra az appot	A blokk egyszer jelenik meg, a helyes időtartammal
Az alap időzítő hálózat nélkül is működik	Kapcsold be a repülőgép módot, és fejezz be egy blokkot	Az időzítő és a helyi mentés használható marad
A részletes statisztikák fizetősek	Nyisd meg a statisztikákat előfizetés nélkül	Megjelenik az ajánlat; az alap blokk továbbra is elérhető

A még homályos témákból meghozandó döntések lesznek. Például: mi történjen, ha a felhasználó blokk közben lezárja a képernyőt vagy átállítja a telefon óráját? Ne hagyd, hogy az ágens csendben döntsön. Írd le a kívánt viselkedést, aztán vedd fel az esetet a táblázatba. Ahhoz, hogy ezt az átvételi tesztet egy valódi telepítésen szervezd meg, használd az iPhone app tesztelése TestFlighttal útmutatót.

Mit vegyél ki, ha az első verzió túlnő?

Vedd sorra a funkciókat, és tedd fel a kérdést: „Nélküle is megkapja a felhasználó a megígért eredményt?” Az időzítőnknél a barátok közötti rangsor várhat. Egy befejezett blokk visszakeresése viszont szükséges, ha napi sorozatot ígérsz. Egy előfizetési képernyő csak akkor válik szükségessé, ha már ebben a verzióban ténylegesen árulod a statisztikákat.

Jegyezd fel a döntést és az okát a letölthető sablon naplójában. Tesztek után visszatérhetsz erre a döntésre anélkül, hogy elveszítenéd, miért ilyen lett az eredeti terjedelem. Az alkalmazás készítése Claude Code-dal útmutató ezután megmutatja, hogyan alakítsd ezt a tervet szűk, ellenőrizhető kérésekké.

Egy gyakorlati tapasztalatért: a TradaZen a megjelenése után módosította a terjedelmét. A tervezés arra való, hogy kiadj egy mérhető első verziót, aztán valódi visszajelzések alapján dönts a következőről.

A funkciókatalógus csapdája

A természetes reflex az, hogy felsorolod mindazt, amit az appnak „tudnia kell”: térkép, chat, értesítések, ajánlói program, offline mód. Ez a katalógus a legmegbízhatóbb jele egy olyan projektnek, ami sosem készül el, egy egyszerű okból: minden, a megjelenés előtt hozzáadott funkció késlelteti azt a pillanatot, amikor valódi felhasználók megmondják neked, mi számít.

Egy jó első verzió egy dolgot csinál, és azt jól. Vigyázz azért a másik végletre is: az Apple elvárja, hogy egy app többet nyújtson egy becsomagolt weboldalnál, az App Review Guidelines 4.2-es szabálya szerint. Egyetlen fő funkció: igen; üres héj: nem. Ez a 4.2-es guideline szerinti elutasítási ok.

Mi ne kerüljön egy mobilapp specifikációjába?

• Teljes arculati kézikönyv. Kezdetben elég néhány referencia-képernyőkép.
• Napra lebontott ütemterv. Még nincs meg hozzá az információd, hogy tartsd. Elég egy heti cél.
• Részletes technikai architektúra. Válassz egy bevált stacket, a részletek pedig dőljenek el építés közben.
• „Későbbre” szánt funkciók a többi közé keverve. Ezek mind a „kimarad az 1. verzióból” részbe kerülnek.

Mikor frissítsd a specifikációdat?

Olvasd át minden munkahét elején. Csak akkor frissítsd, ha egy döntés valódi okból változik: egy teszt az iPhone-odon, ami megmutatja, hogy egy képernyő nem működik, egy tesztelői visszajelzés, egy útközben felfedezett Apple-korlát. Ha minden nap módosítod, akkor már semmit sem keretez.

Az első verzió megjelenése után az oldal a következő verzió alapja lesz: ami kimaradt az 1. verzióból, előrébb kerül, aszerint rendezve, amit a számok mondanak. Az ötlettől a megjelenésig tartó út áttekintése a iPhone app készítése oldalon található.

Az oldaltól a megjelent appig

Ha megválaszoltad a tíz kérdést, már elvégezted azt a munkát, amit sok projekt kihagy. A folytatás: megépíteni a fő funkciót, tesztelni az iPhone-odon, bekötni az előfizetéseket és előkészíteni az anyagot az Apple-nek.

Ez az iOS Kit útja, négy lépésben, a saját tempódban: az első arra való, hogy kiválaszd a pénzt hozó appot, a közönségét és az árát, és ennek a kiindulópontja a te specifikációd.

Nem tudod, hogy az ötleted elfér-e már egy oldalon? Az ingyenes diagnózis megmondja, mi akasztja meg ma a projektedet, és melyik lépéssel kezdj. A kezdőlap aztán megmutatja, hogyan készíts mobilappot ebből a tervből, Claude Code-dal.

Nem ígérek se bevételt, se megjelenést: az Apple dönt a jóváhagyásról, a többiről pedig a piac. A kit nélkül is elég ez a sablon az induláshoz.

Gyakori kérdések

Hogyan írj specifikációt egy mobilalkalmazáshoz?

Tartsd egy oldalon a specifikációdat: tíz kérdés, válaszonként egy-két mondat. A kérdések a közönségről, a problémáról, a fő funkcióról, az üzleti modellről, a fiók nélküli használatról, a megőrzendő adatokról, a platformról, az első verzióból kimaradó dolgokról, a siker jeléről és a korlátokról szólnak. Ha egy válasz két mondatnál hosszabb, az gyakran azt jelenti, hogy a döntés még nem született meg.

Milyen programban írd meg az app specifikációját?

Egy egyszerű jegyzetben vagy egy szövegfájlban a projekted gyökerében: bemásolod a sablont, aztán kitöltöd minden sorát. A vázlatot és az ellenőrző táblázatát (.md) le is töltheted, regisztráció nélkül. Ha AI-t irányítasz vele, utána tedd be a projekted kontextusfájljába.

Kell egy 40 oldalas specifikáció egy apphoz?

Nem, ha a saját appodat készíted: elég egy oldal. A neten található 40 oldalas sablonok annak az ügyfélnek szólnak, aki egy fejlesztőtől rendel appot, és szerződéses dokumentumra van szüksége. Te döntesz és építesz: az oldalad arra való, hogy kódolás előtt meghozd a döntéseket, és kontextust adj az AI-nak.

Hogyan add át a specifikációt egy kódoló AI-nak?

Tedd az oldalt a projekt állandó kontextusába: a Claude Code beolvas egy CLAUDE.md fájlt a gyökérből, a Cursornak saját szabályfájljai vannak. Hivatkozz a „kimarad az 1. verzióból” részre, amikor az AI túlzásba esik. Egy nagyobb munka előtt kérj olyan tervet, ami tiszteletben tartja az oldalt, egyelőre kódolás nélkül.

Hogyan ellenőrizd, hogy egy funkció megfelel-e a specifikációnak?

Minden funkcióhoz írj három sort: a műveletet, az elvárt eredményt és a bizonyítékot. A bizonyíték lehet automatizált teszt egy számításnál, vagy ellenőrzés a készüléken egy folyamatnál. Azt is jegyezd fel, mit nem teszteltél, hogy ne keverd össze a kész képernyőt a használatra kész funkcióval.

Mit ne írj bele egy app specifikációjába?

Négy dolgot kerülj: teljes arculati kézikönyvet, napra lebontott ütemtervet, részletes technikai architektúrát, és a többi közé kevert „későbbre” szánt funkciókat. Kezdetben elég néhány referencia-képernyőkép, az ütemezéshez pedig egy heti cél. A későbbre szánt funkciók mind a „kimarad az 1. verzióból” részbe kerülnek.