Alur Pembuatan Website: 6 Tahap dari Brief sampai Serah Terima

Alur pembuatan website yang jelas membagi proyek menjadi beberapa tahap. Setiap tahap punya hasil yang bisa Anda periksa: dokumen kebutuhan, rancangan struktur, desain, versi uji, lalu paket serah terima. Jadi, Anda tidak hanya mendengar kabar "proyek sedang berjalan". Anda bisa melihat hasil nyata sebelum proyek lanjut ke tahap berikutnya.

Artikel ini untuk pemilik bisnis, pengelola sekolah, atau travel umrah yang akan memesan website. Fokusnya bukan berapa lama pengerjaannya. Fokusnya adalah apa yang perlu disepakati, diperiksa, dan diserahkan di setiap tahap, supaya masalah tidak menumpuk menjelang website diluncurkan.

Tentukan peran dan cara memberi persetujuan

Sebelum pekerjaan dimulai, sepakati dulu siapa yang mengambil keputusan. Banyak proyek molor bukan karena masalah teknis. Penyebabnya, masukan datang dari banyak orang dan saling bertentangan. Misalnya, bagian pemasaran ingin banner besar, sementara pimpinan ingin halaman yang ringkas.

• Satu penanggung jawab dari pihak Anda. Orang ini mengumpulkan masukan dari tim, seperti pemasaran, operasional, dan pimpinan. Lalu ia menyampaikannya ke penyedia jasa sebagai satu keputusan.
• Satu saluran komunikasi resmi. Misalnya email atau satu grup proyek. Keputusan penting dicatat tertulis, jangan hanya disampaikan lewat telepon.
• Batas waktu tinjauan. Tentukan berapa hari kerja yang Anda butuhkan untuk menanggapi setiap hasil. Persetujuan yang terlambat ikut menggeser jadwal.
• Jumlah putaran revisi. Sepakati sejak awal berapa kali desain atau konten boleh direvisi dalam ruang lingkup pekerjaan.

Langkah pertama Anda: tunjuk satu orang penanggung jawab sebelum rapat awal dengan penyedia jasa.

Alur pembuatan website dalam 6 tahap

Nama tahapnya bisa berbeda di setiap penyedia jasa, tetapi urutannya umumnya sama. Yang penting, setiap tahap punya hasil yang bisa Anda periksa dan setujui.

1. Penggalian kebutuhan

Tahap ini menjawab tiga pertanyaan: website dibuat untuk siapa, apa yang ingin dicapai, dan pekerjaan apa yang tidak termasuk. Panduan layanan digital Pemerintah Inggris (GOV.UK Service Manual) menekankan hal serupa pada fase discovery, yaitu fase pengenalan masalah. Di fase ini, tim memahami pengguna, mengenali batasan seperti kontrak dan sistem lama, lalu menyepakati apa yang bukan bagian dari masalah.

Hasil yang perlu disetujui: dokumen kebutuhan. Isinya tujuan, target pengunjung, daftar halaman awal, dan alur utama, misalnya pengunjung mengisi formulir lalu admin menerima datanya. Dokumen ini juga mencatat kebutuhan sambungan ke sistem lain dan hal yang masih perlu dipastikan, termasuk akses ke layanan pihak ketiga. Bila Anda belum punya brief, checklist brief website bisa membantu menyusunnya.

2. Penawaran dan ruang lingkup

Dari dokumen kebutuhan itu, penyedia jasa menyusun penawaran. Periksa apakah penawaran menyebut daftar halaman, fitur, jumlah revisi, dan siapa yang menyiapkan konten. Cek juga tahap pembayaran serta apa saja yang diserahkan di akhir proyek. Penawaran yang hanya berisi angka total tanpa rincian sulit dibandingkan. Panduan cara membandingkan penawaran website menjelaskan poin yang perlu dicek.

Hasil yang perlu disetujui: ruang lingkup tertulis, jadwal per tahap, dan daftar hasil serah terima.

3. Struktur dan desain

Mulailah dari struktur. Bentuknya peta halaman dan rancangan kasar (wireframe), yaitu sketsa sederhana yang menunjukkan urutan informasi dan letak tombol. Mengubah struktur di tahap ini jauh lebih mudah daripada setelah halaman dibangun. Setelah struktur disetujui, barulah tinjau desain visual untuk tampilan laptop dan ponsel.

Hasil yang perlu disetujui: wireframe halaman utama dan desain final. Pastikan desain juga menunjukkan keadaan yang sering terlupa. Contohnya formulir yang gagal dikirim, pesan kesalahan, halaman tidak ditemukan, serta judul atau teks yang panjang.

4. Pengembangan dan demo

Website dibangun di lingkungan uji (staging), yaitu salinan website yang belum dibuka untuk umum. Mintalah demo berkala dengan skenario bisnis nyata, jangan sekadar melihat-lihat halaman. Contohnya: pelanggan mengirim permintaan penawaran, lalu admin menerima notifikasi dan datanya tersimpan.

Lingkungan uji sebaiknya dikunci dengan kata sandi. Menurut Google, kata sandi memastikan hanya orang yang berhak yang bisa membuka isinya. Sementara itu, tag noindex hanya mencegah halaman muncul di hasil pencarian. Pastikan juga tag noindex di staging tidak ikut terbawa ke website produksi, yaitu website yang dibuka pengunjung.

Hasil yang perlu disetujui: fungsi website berjalan sesuai skenario yang disepakati di tahap pertama.

5. Pengujian dan peluncuran

Sebelum domain diarahkan ke website baru, lakukan pengujian menyeluruh bersama penyedia jasa. Rinciannya ada di bagian checklist di bawah.

Hasil yang perlu disetujui: daftar temuan uji yang sudah diperbaiki dan persetujuan tertulis untuk tayang.

6. Serah terima dan masa pendampingan

Setelah website tayang, penyedia jasa menyerahkan akses, dokumentasi, dan materi sesuai kesepakatan. Lalu mereka melatih orang yang akan mengelola konten. Di tahap ini juga ditegaskan bedanya perbaikan kesalahan, maintenance rutin, dan pengembangan baru.

Cara menangani perubahan di tengah proyek

Perubahan hampir selalu muncul. Ada fitur yang baru terpikir, atau pimpinan meminta tampilan yang berbeda. Perubahan itu wajar, asalkan dicatat. Caranya:

1. Tulis permintaan perubahan secara singkat: apa yang diubah dan apa alasannya.
2. Minta penyedia jasa menghitung dampaknya terhadap jadwal dan biaya sebelum dikerjakan.
3. Putuskan apakah perubahan dikerjakan sekarang, ditunda sampai setelah peluncuran, atau dibatalkan.
4. Simpan keputusan itu bersama dokumen ruang lingkup.

Fitur yang tidak mendesak lebih aman dikumpulkan dalam daftar untuk tahap pengembangan berikutnya. Dengan begitu, peluncuran tetap sesuai jadwal. Prioritas selanjutnya bisa Anda tentukan dari cara pengunjung benar-benar memakai website.

Checklist pengujian sebelum website tayang

Pengujian tidak cukup hanya dengan membuka beberapa halaman. Pakai daftar berikut sebagai titik awal:

• Isi dan kontak. Periksa ejaan, nomor telepon, alamat, jam operasional, dan tautan media sosial resmi.
• Fungsi utama. Kirim formulir, coba tombol WhatsApp, dan pastikan data atau notifikasi benar-benar sampai ke tim. Uji juga keadaan gagal, misalnya saat kolom wajib dibiarkan kosong.
• Tampilan ponsel. Coba di beberapa ponsel dan browser. Jangan hanya mengecilkan jendela browser di laptop.
• Aksesibilitas dasar. Aksesibilitas artinya website tetap bisa dipakai orang dengan keterbatasan, misalnya penglihatan lemah. Panduan Easy Checks dari W3C WAI menyarankan beberapa pemeriksaan cepat. Contohnya judul halaman yang jelas, teks pengganti untuk gambar, susunan judul bagian yang rapi, dan kemampuan memakai situs hanya dengan keyboard. Kontras warna teks normal juga disarankan minimal 4,5:1 terhadap latar. W3C mengingatkan bahwa pemeriksaan ini belum termasuk evaluasi aksesibilitas yang lengkap.
• Kecepatan. web.dev menetapkan batas "baik" untuk Core Web Vitals, yaitu ukuran kecepatan dan kenyamanan halaman dari Google. Isi utama halaman (LCP) sebaiknya tampil paling lama 2,5 detik. Respons saat tombol diklik (INP) sebaiknya 200 milidetik atau kurang. Pergeseran tata letak saat halaman dimuat (CLS) sebaiknya 0,1 atau kurang.
• Kesiapan pencarian. Pastikan tag noindex dari staging sudah dihapus. Bila website baru menggantikan website lama dengan alamat halaman yang berbeda, Google menyarankan dua hal. Petakan alamat (URL) lama ke URL baru, lalu pasang pengalihan permanen (301) di server.
• Keamanan dan cadangan. Pastikan sertifikat SSL aktif, akun admin memakai kata sandi kuat, dan backup sudah dijadwalkan. Fungsi keduanya dibahas di artikel SSL dan backup website.
• Rencana jika ada masalah. Tentukan cara kembali ke versi sebelumnya. Tentukan juga siapa yang memantau website pada hari-hari pertama setelah tayang.

Isi paket serah terima website

Serah terima menentukan apakah Anda bisa mengelola website sendiri atau terus bergantung pada satu orang. Bayangkan programmer lama sulit dihubungi, padahal hanya dia yang tahu kata sandi hosting. Karena itu, pastikan daftar berikut tertulis dalam ruang lingkup sejak awal, lalu dicentang saat serah terima:

• Akses akun. Domain, hosting atau server, panel admin, email, Google Search Console, dan alat analitik pengunjung. Idealnya, akun utama terdaftar atas nama perusahaan Anda.
• Kode dan file desain. Sesuai kesepakatan, misalnya repositori (tempat penyimpanan kode program) dan file desain.
• Dokumentasi. Panduan menambah atau mengubah konten, cara menangani formulir yang masuk, dan daftar layanan pihak ketiga yang dipakai beserta masa berlakunya.
• Pelatihan. Sesi singkat untuk pengelola konten. Sebaiknya direkam agar bisa diputar ulang oleh staf baru.
• Kesepakatan setelah tayang. Bedakan tiga hal: perbaikan kesalahan pada fitur yang sudah disepakati, maintenance rutin (pembaruan, backup, pemantauan), dan pengembangan fitur baru. Ketiganya biasanya punya aturan dan biaya yang berbeda.

Website yang sudah tayang bukan berarti pekerjaan selesai selamanya. Catat masukan dari pengunjung dan tim. Lalu tentukan perubahan berikutnya berdasarkan masalah yang benar-benar ditemukan.

Pertanyaan yang sering diajukan

Berapa banyak revisi desain yang wajar?

Tidak ada angka baku. Yang penting, jumlah putaran revisi tertulis dalam ruang lingkup. Setiap revisi juga sebaiknya dikirim sebagai satu daftar masukan yang sudah disatukan oleh penanggung jawab.

Apakah konten harus siap sebelum desain dimulai?

Tidak harus seluruhnya, tetapi struktur dan contoh konten utama sebaiknya sudah ada. Desain yang dibuat dengan teks contoh sering perlu diubah. Penyebabnya, konten asli ternyata jauh lebih panjang atau lebih pendek.

Apa bedanya staging dan website produksi?

Staging adalah salinan website untuk pengujian yang belum dibuka untuk umum. Website produksi adalah versi yang dibuka pengunjung di domain utama. Perubahan sebaiknya dicoba dulu di staging sebelum dipindahkan ke produksi.

Siapa yang sebaiknya memegang akun domain dan hosting?

Sebaiknya perusahaan Anda yang menjadi pemilik akun. Penyedia jasa cukup diberi akses tambahan bila diperlukan. Cara ini memudahkan bila suatu saat Anda berganti pengelola website.

Referensi

• GOV.UK Service Manual: How the discovery phase works
• Google Search Central: Control what you share with Google
• Google Search Central: Block Search indexing with noindex
• Google Search Central: Site moves with URL changes
• W3C WAI: Easy Checks – A First Review of Web Accessibility
• web.dev: Web Vitals

Sedang menyiapkan website perusahaan, sekolah, atau travel? Anaverse bisa membantu menyusun alur kerja dan ruang lingkupnya bersama Anda. Pelajari layanan pembuatan website bisnis dan company profile, lalu hubungi tim Anaverse dengan membawa contoh alur kerja dan kebutuhan utama Anda.