Veebiarendus samm-sammult: kuidas projekt lähteülesandest avaldamiseni käib

Kui tellite uue kodulehe või e-poe, on kõige raskem ette näha mitte hinda, vaid seda, mis juhtub pärast lepingu allkirjastamist. Veebiarendus ei ole üks suur töö, mis ühel päeval valmis saab. See on rida etappe, millest igaühes on vaja ka teie otsuseid, sisu ja ligipääse.

Selles artiklis käime läbi, kuidas veebiarenduse projekt meie juures tavaliselt kulgeb: kaardistusest ja sisust kuni testimise, avaldamise ja hoolduseni. Iga etapi juures ütleme, mida me teeme ja mida vajame teie käest. Kui olete alles otsustamas, kas üldse eritellimusel lehte teha, lugege enne meie juhendit kodulehe tegemisest: eritellimus või mall.

Veebiarenduse etapid ühe pilguga

Etapp	Mis toimub	Mida vajame teilt	Tulemus
Kaardistus	Eesmärk, sihtrühm, lehtede struktuur, liidestused	Lähteülesanne, ligipääs olemasolevatele süsteemidele	Kokkulepitud ulatus
Sisu	Tekstid, pildid, tooteandmed	Sisu või otsus, kes selle loob	Sisu, millele saab kujunduse ehitada
Kujundus	Põhilehtede ja peamise tegevusvoo kujundus	Tagasiside ühe inimese kaudu	Kinnitatud kujundus
Arendus	Lehe ehitamine testkeskkonnas	Vastused küsimustele, testandmed	Töötav leht eelvaates
Testimine	Kiirus, ligipääsetavus, telefonid, vormid	Enda läbiproovimine	Parandatud vigade nimekiri
Avaldamine	Domeen, ümbersuunamised, analüütika, Search Console	Domeeni ja kontode ligipääsud	Leht on avalik
Hooldus	Uuendused, parandused, edasiarendus	Omanik, kes teatab muudatustest	Leht püsib korras

Järgnevalt iga etapp lähemalt.

1. Kaardistus: mida leht peab tegema

Enne kui keegi midagi joonistab või kirjutab, lepime kokku, milleks leht on olemas. Üks peamine tegevus: broneering, hinnapäring, ost, kõne. Kõik muu lehel toetab seda.

Kaardistuses paneme paika:

• lehtede ja keelte arvu;
• peamise tegevusvoo sammud;
• millised süsteemid on juba kasutusel (broneerimis- või kassasüsteem, e-poe platvorm, CRM, raamatupidamine) ja kas nendega tuleb liidestada;
• kes ja kui tihti lehte pärast muudab;
• mis läheb esimesse versiooni ja mis jääb hilisemaks.

Viimane punkt on kõige olulisem. Enamik venivaid projekte venib sellepärast, et ulatus kasvab vaikselt töö käigus. Parem on avaldada väiksem leht õigel ajal ja lisada ülejäänu hiljem.

Mida vajame teilt: lähteülesannet (küsimused selleks leiate kodulehe tegemise juhendist), ligipääsu olemasolevale lehele ja süsteemidele ning ühte inimest, kes teeb otsused.

2. Sisu enne kujundust

See on etapp, mida kõige sagedamini alahinnatakse. Kujundus, mis on tehtud näidisteksti peale, laguneb, kui päris tekst on kolm korda pikem või pilte pole.

Sisu hulka kuulub:

• tekstid igale lehele ja igas keeles;
• fotod ja video, õigustega nende kasutamiseks;
• logo ja brändi värvid;
• tooteandmed, hinnad, lahtiolekuajad, kontaktid;
• õiguslikud tekstid: privaatsuspoliitika, küpsiste teave, müügitingimused.

Kui sisu pole olemas, tuleb enne otsustada, kes selle loob. Kui teie, siis millal. Kui keegi teine, siis kes ja millise eelarvega. Kõige kallim variant on see, kus sisu „tuleb hiljem“ ja kujundust tuleb seetõttu kaks korda teha.

Mitmekeelse lehe puhul on iga keel eraldi sisu. Masintõlge võib olla hea mustand, aga avaldada tasub ainult seda, mille keeleoskaja on üle lugenud.

Mida vajame teilt: sisu või selget otsust, kes selle teeb ja millal.

3. Kujundus

Kujundame esmalt põhilehed ja peamise tegevusvoo. Mitte iga alamlehte eraldi, vaid need mallid, millest ülejäänud lehed koosnevad. Telefonivaade on kujunduses algusest peale, mitte hiljem lisatud.

Kui leht toetub liikumisele, nagu meie demolehel Lõke (väljamõeldud restoranibränd, mille tegime müügidemoks, mitte kliendi töö), proovime liikumist varakult päris brauseris. Staatiline pilt ei näita, kas kerimine tundub hea.

Tagasiside kohta üks praktiline soovitus: koondage see ühe inimese kaudu. Kui viis inimest annavad eraldi vastukäivaid kommentaare, peab keegi need niikuinii kokku viima, ja parem, kui see olete teie, mitte arendaja.

Mida vajame teilt: koondatud tagasisidet ja kujunduse kinnitust enne arenduse algust.

4. Arendus

Arenduse ajal ehitame lehe testkeskkonda, mille aadressi te saate. Nii näete edenemist päris brauseris ja telefonis, mitte ainult ekraanipiltidel. Testkeskkond on otsingumootoritele suletud.

Tööriistad valime töö järgi. Lõke on tehtud Vite'i, GSAP-i, Lenise ja OGL-iga ilma suure raamistikuta. AMPSU e-pood ja retseptiplatvorm töötavad Next.js-i, Medusa, Directuse ja Stripe'iga. Meie teine demo, 3D House Demo, näitab viie korteriga maja otse selle Revit-mudelist koos reaalajas lõigetega. See on samuti demo, mitte kliendi tellimus.

Liidestused (maksed, tarne, broneeringud, CRM) ehitame ja testime testrežiimis enne, kui need päris andmetega kokku puutuvad. AMPSU puhul testisime retseptiplatvormi eraldi eelvaatekeskkonnas päris poe taustsüsteemi vastu, nii et töötav pood ei saanud häiritud.

Mida vajame teilt: kiireid vastuseid küsimustele, testkontosid või -andmeid liidestatavatest süsteemidest ning järjekindlust. Uued soovid lähevad nimekirja, mitte otse töösse.

5. Testimine: kiirus, ligipääsetavus ja telefonid

Testimine ei ole viimane päev enne avaldamist. Osa sellest käib kogu arenduse ajal, aga enne avaldamist teeme eraldi läbimängu.

Kiirus ja Core Web Vitals

Google'i Core Web Vitals juhendi järgi on hea tulemus LCP kuni 2,5 sekundit, INP kuni 200 millisekundit ja CLS kuni 0,1. Mõõdame Lighthouse'i ja PageSpeed Insightsiga, aga ka päris telefonis mobiilse andmesidega, sest arendaja arvuti on alati kiire.

Pärast avaldamist tasub vaadata ka päris külastajate andmeid, mis kogunevad aja jooksul. Laboritulemus ja päris kasutajate kogemus ei ole alati samad.

Ligipääsetavus

Kontrollime vähemalt järgmist:

• kõik tegevused saab teha klaviatuuriga ja fookus on nähtav;
• piltidel on sisukas alternatiivtekst;
• teksti ja tausta kontrast on piisav;
• vormiväljadel on sildid ja veateated on arusaadavad;
• kes on oma seadmes liikumise vähendanud, näeb animatsiooni asemel rahulikku versiooni.

See ei ole ainult hea tava. Euroopa ligipääsetavusnõuded puudutavad alates 2025. aasta juunist ka paljusid e-poode ja muid veebiteenuseid (mikroettevõtetele on erandid). Täpsemad nõuded tasub oma valdkonna jaoks üle kontrollida.

Telefonid ja brauserid

Proovime lehte päris iOS-i ja Androidi seadmetes, mitte ainult brauseri telefonivaates. Eriti vormid, maksed ja kõik, mis sõltub puudutusest või kerimisest.

Mida vajame teilt: käige ise peamine tegevus läbi, nagu teeks seda klient. Te märkate asju, mida arendaja ei näe, sest teate, kuidas teie kliendid mõtlevad.

6. Avaldamine: kontrollnimekiri

Avaldamine on lühike, aga siin juhtuvad kõige kallimad vead: kadunud otsingupositsioonid, töötamata vormid ja päringud, mis jõuavad valesse postkasti. Meie nimekiri:

• Ümbersuunamised. Kui vana lehe aadressid muutuvad, suunab iga vana aadress püsiva (301) ümbersuunamisega uuele. Google kirjeldab seda saidi kolimise juhendis.
• Indekseerimise lubamine. Testkeskkonna noindex ja robots.txt keelud on eemaldatud.
• Search Console. Leht on Google Search Console'is kinnitatud ja sitemap esitatud.
• Analüütika ja nõusolek. Analüütika töötab ja käivitub ainult siis, kui külastaja on selleks nõusoleku andnud.
• Vormid ja teavitused. Iga vorm on proovitud ja kiri jõuab õigesse postkasti.
• Liidestused päris režiimis. Maksed, tarne ja broneeringud on testrežiimist välja lülitatud ja üks päris tehing tehtud.
• Pealkirjad ja kirjeldused. Igal lehel on oma pealkiri ja kirjeldus, mitmekeelsel lehel õiged keeleviited.
• Domeen ja SSL. DNS on muudetud, HTTPS töötab ja www ning ilma www-ta aadress viivad samasse kohta.
• 404-leht. Olematu aadress viib abistavale lehele, mitte tühjale veateatele.
• Varukoopia ja tagasivõtmine. On teada, kuidas vajadusel eelmise versiooni juurde tagasi minna.

Avaldame tööpäeva alguses, mitte reede õhtul. Nii jõuame esimese päeva jooksul reageerida, kui midagi ootamatut juhtub.

Mida vajame teilt: ligipääsu domeeni haldusele, Google'i kontodele ja makse- või tarnepartnerite päris kontodele. Soovitame, et kõik kontod oleksid teie nimel ja meil oleks ainult ligipääs.

7. Pärast avaldamist: hooldus ja edasiarendus

Koduleht ei ole pärast avaldamist valmis ehitis, pigem töötav tööriist. Sõltuvused vajavad uuendamist, partnerite liidesed muutuvad, sisu vananeb.

Esimestel nädalatel vaatame:

• Search Console'is, kas uued lehed indekseeritakse ja vanad aadressid suunatakse õigesti;
• kas vormidest ja broneeringutest tuleb päringuid;
• kas mõni leht on aeglasem, kui testis tundus.

Pikemas plaanis leppige kokku, kes vastutab uuenduste ja turvaparanduste eest ning kuidas tellite uusi muudatusi. Kood, domeen ja majutus peaksid kuuluma teile, et saaksite vajadusel ka arendajat vahetada.

Mida vajame teilt: ühte inimest, kes annab teada, kui äris midagi muutub: uus toode, uued lahtiolekuajad, uus partner.

Millal me pole teile õige partner

Kogu see protsess on mõistlik, kui leht on osa teie müügist. Alati ei ole see nii:

• Vajate lihtsat visiitkaarti. Kolm lehte ja kontaktivorm saab hästi valmis mõnel valmisplatvormil ja tõenäoliselt odavamalt.
• Sisu pole ja keegi ei hakka seda tegema. Siis ei päästa lehte ka parim arendus. Alustage sisust.
• Tähtaeg on nädala pärast. Korralik kaardistus, testimine ja avaldamine võtavad aega. Kiirustades jäävad tavaliselt välja just testimine ja ümbersuunamised.
• Soovite kõike ise ja iga päev muuta. Siis tasub valida platvorm, mille sisuhaldus on teile tuttav, või rääkida sellest kohe kaardistuses.

Kokkuvõte

Hea veebiarendus on etteaimatav: kaardistus, sisu, kujundus, arendus, testimine, avaldamine ja hooldus, igaüks oma selge tulemusega. Suurimad viivitused tulevad tavaliselt puuduvast sisust, hajusast tagasisidest ja kasvavast ulatusest, mitte koodist. Kui teate ette, mida igas etapis teilt oodatakse, läheb projekt kiiremini ja leht jõuab avaldamiseni terve.

Meie tehtud lehti saate ise avada ja proovida meie töödes. Kui plaanite uut lehte või vana uuendamist, kirjutage meile. Käime koos läbi, mida teie leht peab tegema, ja ütleme ausalt, kas selleks on vaja eritellimust.