Mobiilisovelluksen määrittelydokumentti: yhden sivun malli

Mobiilisovelluksen määrittelydokumentti: lyhyt vastaus

Kun teet omaa sovellustasi, hyvä mobiilisovelluksen määrittelydokumentti mahtuu yhdelle sivulle. Se vastaa kymmeneen kysymykseen: kenelle, mikä ongelma, mikä päätoiminto, miten sovellus tienaa, mitä tapahtuu ilman tiliä, minkä datan pitää säilyä, mille alustalle, mikä jää ensimmäisen version ulkopuolelle, mistä tiedät, että se toimii, ja millä rajoitteilla. Kopioitava malli on alempana. Voit myös ladata pohjan ja sen tarkistuslistan (.md) ilman rekisteröitymistä.

Netistä löytyvät 40-sivuiset mallit on kirjoitettu toiseen käyttöön: asiakkaalle, joka tilaa sovelluksen toimittajalta ja tarvitsee sopimusdokumentin. Sinä olet sekä päättäjä että tekijä, usein tekoälyn avulla. Määrittelysi tekee kaksi asiaa: se lukitsee päätökset ennen koodaamista ja antaa Claudelle, ChatGPT:lle tai Cursorille selkeän kontekstin, jotta ne rakentavat oikean sovelluksen.

Julkaisen omia iOS-sovelluksiani. Solys, minipelejä sisältävä herätyskello, ja TradaZen, kaupankäyntisimulaattori, ovat App Storessa. Apple hylkäsi Noleran ja Clicin, ja ne korjattiin. Käytän tätä menetelmää jokaisessa niistä, ja sitä ehdotan myös sinulle.

Miksi yksi sivu riittää oman sovelluksen rajaamiseen

Pitkä dokumentti antaa vaikutelman edistymisestä. Käytännössä se kirjoitetaan kerran, luetaan harvoin uudelleen, ja projekti karkaa siitä jo ensimmäisinä viikkoina. Yhden sivun taas luet kahdessa minuutissa ennen jokaista työsessiota.

Tilarajoituksella on myös hyödyllinen sivuvaikutus: se pakottaa päättämään. Jos vastaus venyy yli kahden lauseen, päätöstä ei usein ole vielä tehty. Parempi huomata se paperilla kuin koodissa kolme viikkoa myöhemmin.

Lisäksi yksi sivu on tekoälylle sopiva koko. Voit liittää sen kokonaan keskusteluun tai tallentaa projektisi kontekstitiedostoon. Lyhyt dokumentti on helpompi tarkistaa ja vähentää ristiriitaisia ohjeita. Se ei takaa, että tekoäly noudattaa niitä: tarkista sen ehdotukset tätä raamia vasten.

Mitä mobiilisovelluksen määrittelydokumentin pitää sisältää?

Vastaa jokaiseen kysymykseen yhdellä tai kahdella lauseella.

1. Kuka sovellusta käyttää ja missä tilanteessa? Ei "18-35-vuotiaat". Vaan tietty ihminen tiettynä hetkenä päivässään.
2. Minkä ongelman sovellus ratkaisee, yhdellä lauseella? Jos tarvitset sanat "ja lisäksi", kuvaat kahta sovellusta.
3. Mikä on ensimmäisen version SE päätoiminto? Vain yksi. Muut odottavat lukuja. Sivu iOS-sovelluksen MVP kertoo, miten valita.
4. Miten sovellus tienaa? Tilaus, kertaosto tai ilmainen. Tämä vastaus muuttaa sovellusta ensimmäisestä näkymästä lähtien. Jos epäröit, lue tilaus vai kertaosto iOS-sovellukselle.
5. Mitä voi tehdä luomatta tiliä? Kun päätät ajoissa, mitä saa käyttää ilman rekisteröitymistä, sinun ei tarvitse rakentaa koko käyttöönottopolkua uudelleen.
6. Minkä datan pitää säilyä puhelimen vaihdossa? Tämä kysymys ratkaisee, tarvitsetko Supabasen kaltaisen backendin vai voiko kaikki pysyä laitteella.
7. Pelkkä iOS vai iOS ja Android? Neuvoni aloittelijalle: iOS ensin. Kerron syyt artikkelissa iOS- ja Android-sovellus yhtä aikaa.
8. Mikä on nimenomaisesti ensimmäisen version ULKOPUOLELLA? Dokumentin hyödyllisin osio. Se katkaisee väittelyt ennen kuin ne syntyvät, niin itsesi kuin tekoälyn kanssa.
9. Mistä tiedät, että se toimii? Yksi signaali, mitattavissa julkaisua seuraavina viikkoina: aloitetut ilmaiset kokeilut, tilaajat, palaavat käyttäjät.
10. Mitkä ovat todelliset rajoitteesi? Aika, jonka voit käyttää viikossa, laitteistosi ja Apple Developer -tilisi, joka maksaa 99 $ vuodessa. Eikö sinulla ole Macia? Se ei ole este, kuten selitän artikkelissa iOS-sovelluksen julkaisu ilman Macia.

Kopioitava määrittelymalli

Kopioi tämä malli muistiinpanoon tai tekstitiedostoon projektisi juureen ja korvaa jokainen rivi.

• Sovelluksen työnimi: …
• Kenelle: henkilö, joka … silloin kun …
• Ratkaistu ongelma, yhdellä lauseella: …
• Version 1 päätoiminto: …
• Mitä käyttäjä näkee avatessaan sovelluksen ensimmäistä kertaa: …
• Ansaintamalli: tilaus / kertaosto / ilmainen, ja mikä on maksullista: …
• Ilman tiliä voi: …
• Puhelinten välillä säilytettävä data: ei mitään / …
• Alusta: iOS ensin (Android myöhemmin, jos luvut sen oikeuttavat)
• Version 1 ulkopuolella: …, …, …
• Onnistumisen signaali: …
• Stack: React Native, Expo, Supabase jos tarvitaan tilejä, RevenueCat tilauksiin
• Rajoitteet: … tuntia viikossa, Apple Developer -tili avattu vai ei, Mac vai ei
• Sovellukset, joiden käyttökokemuksesta pidän, ja miksi: …

Lisää kolmesta viiteen kuvakaappausta sovelluksista, joista pidät, ja sana siitä, mikä niissä miellyttää. Se kertoo enemmän kuin graafinen ohjeisto, niin sinulle kuin tekoälylle.

Määrittelydokumentti ei ole toivelista. Se on lista tehdyistä päätöksistä.

Esimerkki: täytetty sivu kuvitteelliselle sovellukselle

Jotta näet odotetun tarkkuustason, tässä malli täytettynä esimerkkiä varten keksitylle sovellukselle, opiskeluajastimelle.

• Kenelle: opiskelija, joka lukee iltaisin yksin ja herpaantuu kymmenen minuutin jälkeen.
• Ongelma: hän ei pysty pitämään työsessiota koskematta puhelimeensa.
• Päätoiminto: käynnistää ajastettu sessio ja nähdä putkensa onnistuneista päivistä.
• Ensimmäinen näkymä: yksi painike session aloittamiseen.
• Ansaintamalli: tilaus yksityiskohtaisiin tilastoihin, perussessio ilmainen.
• Ilman tiliä: kaikki, paitsi varmuuskopio puhelinten välillä.
• Version 1 ulkopuolella: ryhmätila, kaverien välinen tulostaulu, widgetit, Android-versio.
• Onnistumisen signaali: käyttäjät, jotka palaavat useana päivänä peräkkäin.

Huomaa, mitä tarkoituksella puuttuu: ei kahdenkymmenen näkymän listaa, ei pakotettuja värejä, ei arkkitehtuuria. Nämä valinnat syntyvät rakentaessa, ja sivun avulla tarkistat, että ne palvelevat päätoimintoa.

Miten käytät määrittelyä tekoälyn ohjaamiseen

Tässä sivusi maksaa itsensä takaisin eniten. Tekoäly, joka koodaa ilman kontekstia, arvaa, ja usein se arvaa jonkin muun sovelluksen kuin sinun.

Laita sivu projektin pysyvään kontekstiin. Claude Code lukee juuressa olevan CLAUDE.md-tiedoston, Cursorilla on omat sääntötiedostonsa. Liitä sinne määrittelysi ja stackisi. Silloin jokainen pyyntö lähtee samasta pohjasta.

Viittaa "version 1 ulkopuolella" -osioon, kun tekoäly tekee liikaa. Avustajat ehdottavat mielellään lisätoimintoja: tumman tilan, jakamisen, ilmoituksen. Poissulkulistasi antaa valmiin vastauksen: ei nyt.

Pyydä suunnitelma, joka noudattaa sivua. Ennen isoa urakkaa kirjoita: "tässä on määrittelyni, ehdota suunnitelma päätoiminnolle, älä koodaa vielä". Huomaat heti, jos suunnitelma poikkeaa päättämästäsi.

Pyydä sitä tarkistamaan sivu, ei vain koodia. Kysy: "mitkä tämän määrittelyn kysymyksistä ovat epämääräisiä tai ristiriitaisia?". Se on aliarvostettu tapa käyttää tekoälyä, ja se säästää viikkojen työn väärään suuntaan.

Jos haluat syventyä aiheeseen, kävin sudenkuopat ja tarkistukset läpi artikkelissa iOS-sovelluksen tekeminen tekoälyllä.

Päätösten muuttaminen hyväksymiskriteereiksi

Päätoiminnolla pitää olla havaittava lopputulos. Tämän esimerkin kuvitteelliselle ajastimelle "ajastin toimii" on liian epämääräinen. Kirjoita mieluummin: "Käynnistän session, jäljellä oleva aika näkyy, voin pysäyttää sen ja löydän viimeisimmän päättyneen session avattuani sovelluksen uudelleen." Päätä erikseen, pitääkö ajastimen jatkua näytön ollessa lukittuna: tämä valinta voi muuttaa teknistä työtä.

Lisää jokaiselle toiminnolle kolme riviä: toiminto, odotettu tulos, todiste. Todiste voi olla automaattinen testi laskennalle tai tarkistus laitteella käyttöpolulle. Kirjaa myös, mitä ei ole testattu. Tämä pieni taulukko estää sekoittamasta valmista näkymää käyttövalmiiseen toimintoon.

Tässä täytetty taulukko kuvitteelliselle ajastimellemme. Nämä ovat tarkistettavia kriteerejä, eivät jo läpäistyjä testejä:

Rajauksen päätös	Testattava	Odotettu tulos
Perussessio on käytettävissä ilman tiliä	Asenna sovellus ja käynnistä sessio rekisteröitymättä	Mikään rekisteröitymislomake ei estä aloittamista
Keskeytetty sessio ei lasketa putkeen	Pysäytä sessio ennen loppua ja avaa historia	Päättyneitä sessioita ei lisätä
Historia pysyy laitteella	Päätä sessio, sulje sovellus ja avaa se uudelleen	Sessio näkyy kerran ja oikealla kestolla
Perusajastin toimii ilman verkkoa	Laita lentotila päälle ja päätä sessio	Ajastin ja paikallinen tallennus pysyvät käytettävissä
Yksityiskohtaiset tilastot ovat maksullisia	Avaa tilastot ilman tilausta	Tarjous näytetään; perussessio pysyy käytettävissä

Vielä epäselvistä asioista tulee tehtäviä päätöksiä. Esimerkiksi: mitä tehdään, jos käyttäjä lukitsee näytön tai muuttaa puhelimen kellonaikaa session aikana? Älä anna agentin valita hiljaa. Kirjoita haluttu käytös ja lisää tapaus taulukkoon. Kun järjestät tämän testauksen oikealla asennuksella, käytä opasta iPhone-sovelluksen testaus TestFlightilla.

Mitä karsia, kun ensimmäinen versio paisuu

Käy jokainen toiminto läpi ja kysy: "Saako käyttäjä ilman sitä silti luvatun tuloksen?" Ajastimessamme kaverien välinen tulostaulu voi odottaa. Päättyneen session löytäminen on välttämätöntä, jos lupaat päiväputken. Tilausnäkymästä tulee välttämätön vain, jos todella myyt tilastoja jo tässä versiossa.

Kirjaa päätös ja sen syy ladattavan mallin lokiin. Voit palata valintaan testien jälkeen menettämättä alkuperäisen rajauksen perusteluja. Opas sovelluksen tekeminen Claude Codella näyttää sitten, miten tämä rajaus muutetaan rajatuiksi ja tarkistettaviksi pyynnöiksi.

Kokemuksena kentältä: TradaZenin laajuus muuttui julkaisun jälkeen. Rajauksen tarkoitus on saada ulos mitattava ensimmäinen versio ja päättää seuraavasta todellisen palautteen perusteella.

Ominaisuusluettelon ansa

Luonnollinen refleksi on listata kaikki, mitä sovelluksen "pitää tehdä": kartta, chat, ilmoitukset, suosittelu, offline-tila. Tämä luettelo on luotettavin merkki projektista, joka ei valmistu, yksinkertaisesta syystä: jokainen ennen julkaisua lisätty toiminto lykkää hetkeä, jolloin oikeat käyttäjät kertovat, mikä on tärkeää.

Hyvä ensimmäinen versio tekee yhden asian ja tekee sen hyvin. Varo kuitenkin päinvastaista liioittelua: Apple vaatii, että sovellus on enemmän kuin paketoitu verkkosivu, App Review Guidelinesin säännön 4.2 mukaan. Yksi päätoiminto kyllä; tyhjä kuori ei: se on guideline 4.2:n hylkäysperuste.

Mitä mobiilisovelluksen määrittelyyn ei kuulu

• Täydellinen graafinen ohjeisto. Muutama referenssikuvakaappaus riittää alkuun.
• Päiväkohtainen aikataulu. Sinulla ei vielä ole tietoja sen noudattamiseen. Viikkotavoite riittää.
• Yksityiskohtainen tekninen arkkitehtuuri. Valitse koeteltu stack ja anna yksityiskohtien ratketa rakentaessa.
• "Myöhemmin"-toiminnot muun sekaan. Ne kaikki kuuluvat version 1 ulkopuolella -osioon.

Milloin määrittely päivitetään?

Lue se jokaisen työviikon alussa. Päivitä se vain, kun päätös muuttuu todellisesta syystä: iPhonellasi tehty testi näyttää, ettei näkymä toimi, testaajan palaute, matkan varrella paljastunut Applen rajoite. Jos muutat sitä joka päivä, se ei enää rajaa mitään.

Kun ensimmäinen versio on julkaistu, sivusta tulee seuraavan pohja: version 1 ulkopuolelle jääneet nousevat esiin lukujen mukaan järjestettyinä. Kokonaiskuva polusta ideasta julkaisuun on sivulla iPhone-sovelluksen tekeminen.

Sivulta julkaistuun sovellukseen

Jos vastasit kymmeneen kysymykseen, olet jo tehnyt työn, jonka moni projekti ohittaa. Seuraavaksi rakennat päätoiminnon, testaat sen iPhonellasi, kytket tilaukset ja valmistelet aineiston Applelle.

Tämä polku on iOS Kitin sisältö, neljä vaihetta omaan tahtiisi: ensimmäisessä valitaan sovellus, joka voi tuottaa, sen yleisö ja hinta, ja määrittelysi on sen lähtöpiste.

Etkö tiedä, onko ideasi valmis mahtumaan yhdelle sivulle? Ilmainen diagnoosi kertoo, mikä projektiasi tänään jarruttaa ja mihin vaiheeseen tarttua ensin. Etusivu näyttää sitten, miten mobiilisovellus tehdään tästä rajauksesta Claude Codella.

En lupaa tuloja enkä julkaisua: Apple hyväksyy, ja markkinat päättävät loput. Ilman kittiäkin tämä malli riittää alkuun.

Usein kysytyt kysymykset

Miten mobiilisovelluksen määrittelydokumentti kirjoitetaan?

Pidä määrittely yhdellä sivulla: kymmenen kysymystä, yksi tai kaksi lausetta vastausta kohden. Ne koskevat yleisöä, ongelmaa, päätoimintoa, ansaintamallia, mitä tapahtuu ilman tiliä, säilytettävää dataa, alustaa, ensimmäisen version ulkopuolelle jäävää, onnistumisen signaalia ja rajoitteita. Jos vastaus venyy yli kahden lauseen, päätöstä ei usein ole vielä tehty.

Millä ohjelmalla sovelluksen määrittely kannattaa kirjoittaa?

Pelkkä muistiinpano tai tekstitiedosto projektisi juuressa: kopioit mallin ja korvaat jokaisen rivin. Voit myös ladata pohjan ja sen tarkistuslistan (.md) ilman rekisteröitymistä. Tekoälyn ohjaamista varten tallenna se sitten projektisi kontekstitiedostoon.

Tarvitaanko sovellukselle 40-sivuinen määrittely?

Ei, kun teet omaa sovellustasi: yksi sivu riittää. Netistä löytyvät 40-sivuiset mallit on kirjoitettu asiakkaalle, joka tilaa sovelluksen toimittajalta ja tarvitsee sopimusdokumentin. Sinä päätät ja rakennat: sivusi lukitsee päätökset ennen koodaamista ja antaa tekoälylle kontekstia.

Miten määrittely annetaan koodaavalle tekoälylle?

Laita sivu projektin pysyvään kontekstiin: Claude Code lukee juuressa olevan CLAUDE.md-tiedoston, Cursorilla on omat sääntötiedostonsa. Viittaa "version 1 ulkopuolella" -osioon, kun tekoäly tekee liikaa. Ennen isoa urakkaa pyydä sivua noudattava suunnitelma koodaamatta vielä.

Miten tarkistat, että toiminto noudattaa määrittelyä?

Lisää jokaiselle toiminnolle kolme riviä: toiminto, odotettu tulos ja todiste. Todiste voi olla automaattinen testi laskennalle tai tarkistus laitteella käyttöpolulle. Kirjaa myös, mitä ei ole testattu, jotta et sekoita valmista näkymää käyttövalmiiseen toimintoon.

Mitä sovelluksen määrittelyyn ei pidä laittaa?

Neljä vältettävää asiaa: täydellinen graafinen ohjeisto, päiväkohtainen aikataulu, yksityiskohtainen tekninen arkkitehtuuri ja "myöhemmin"-toiminnot muun sekaan. Muutama referenssikuvakaappaus riittää alkuun, ja aikatauluksi riittää viikkotavoite. Myöhemmät toiminnot kuuluvat kaikki version 1 ulkopuolella -osioon.