Brief Website yang Berguna
Desain yang matang membutuhkan keputusan sebelum layar pertama dibuat.
Ringkasan kebutuhan situs web (brief) bukan daftar warna dan contoh tampilan. Dokumen ini menjawab alasan website dibangun, siapa yang akan menggunakannya, informasi apa yang dibutuhkan, dan tindakan apa yang diharapkan setelah pengunjung memahami isi.
Mulailah dari satu tujuan utama. Situs profil perusahaan dapat bertujuan membantu calon mitra memahami kapasitas perusahaan. Halaman arahan (landing page) dapat berfokus pada satu penawaran. Katalog dapat membantu pengguna menelusuri kategori dan mengirim permintaan. Tujuan yang jelas mencegah halaman dipenuhi bagian yang tidak memiliki fungsi.
Petakan pengguna dan konten
Tuliskan dua atau tiga kelompok pengguna utama, pertanyaan mereka, dan informasi yang perlu tersedia untuk menjawab pertanyaan itu. Kumpulkan logo, profil, deskripsi layanan, foto, data kontak, dokumen pendukung, dan ketentuan penggunaan. Tandai materi yang sudah final dan yang masih perlu ditulis.
Pisahkan kebutuhan wajib dan pengembangan
Buat dua daftar. Daftar pertama berisi kebutuhan yang harus tersedia ketika website diluncurkan. Daftar kedua berisi fitur yang dapat dikembangkan setelah penggunaan awal memberi data yang cukup. Cara ini membantu menjaga ruang lingkup, anggaran, dan target waktu tetap realistis.
Tutup brief dengan batas proyek: jumlah halaman, fungsi, integrasi, perangkat yang diprioritaskan, kebutuhan aksesibilitas, pihak penyedia konten, jumlah putaran revisi, target waktu, serah terima, akses akun, pemeliharaan, dan kriteria penerimaan. Seluruh rincian baru berlaku setelah disepakati oleh pihak terkait.
Tentukan hasil yang ingin diukur
Tujuan yang baik dapat diterjemahkan menjadi indikator. Website profil perusahaan mungkin mengutamakan keterbacaan layanan, permintaan kontak, atau akses dokumen. Katalog mungkin mengutamakan kemudahan menemukan kategori dan mengirim pertanyaan. Portal layanan mungkin mengutamakan penyelesaian tugas pengguna. Indikator tidak harus selalu berupa angka penjualan; yang penting, tim mengetahui perilaku apa yang menunjukkan bahwa website membantu pengguna.
Buat peta halaman sebelum membahas visual
Susun daftar halaman dan hubungan antarkonten. Untuk setiap halaman, tulis tujuan, audiens, pesan utama, tindakan yang diharapkan, dan materi yang dibutuhkan. Peta sederhana ini membantu menemukan duplikasi, halaman yang tidak memiliki fungsi, serta informasi yang belum tersedia. Struktur yang jelas juga memudahkan pembuatan navigasi, jejak navigasi (breadcrumb), dan tautan internal.
Pisahkan kebutuhan fungsional dan nonfungsional
Kebutuhan fungsional menjelaskan apa yang dapat dilakukan pengguna, misalnya mengirim formulir, mencari artikel, memfilter katalog, atau mengunduh dokumen. Kebutuhan nonfungsional menjelaskan kualitas yang diharapkan, seperti kecepatan, responsivitas, aksesibilitas, keamanan, pencadangan, kompatibilitas peramban (browser), dan kemudahan pemeliharaan. Dua kelompok ini perlu dicatat karena proyek dapat terlihat selesai secara visual tetapi belum siap digunakan bila kualitas teknisnya tidak diuji.
Definisikan data, privasi, dan keamanan sejak awal
Jika situs menerima formulir kontak atau konsultasi, tentukan data yang benar-benar diperlukan dan jangan meminta kata sandi, OTP, PIN, CVV, atau data lain yang tidak diperlukan untuk menangani permintaan. Dokumentasikan tujuan dan dasar pemrosesan, informasi kepada subjek data, masa penyimpanan, hak pengguna, pihak yang dapat mengakses, pengamanan, serta prosedur penghapusan sesuai peran dan ketentuan yang berlaku. Untuk akun administrator, gunakan mekanisme akses dan pemulihan yang aman. Untuk integrasi pihak ketiga, catat layanan yang digunakan serta dampaknya terhadap privasi, biaya, dan ketergantungan teknis.
Tuliskan standar aksesibilitas dan perangkat
Brief sebaiknya menyebutkan perangkat yang diprioritaskan, tetapi desain tetap perlu responsif. Cantumkan kebutuhan keyboard, kontras, label formulir, teks alternatif gambar, struktur judul bertingkat (heading), ukuran target sentuh, dan perilaku saat JavaScript tidak tersedia bila relevan. Aksesibilitas bukan lapisan dekorasi di akhir proyek; keputusan struktur dan komponen sejak awal akan menentukan kualitas hasil.
Jelaskan alur revisi dan kriteria penerimaan
Tentukan siapa yang memberi keputusan akhir, bagaimana komentar dikumpulkan, berapa putaran revisi yang termasuk ruang lingkup, dan perubahan apa yang dianggap sebagai permintaan baru. Kriteria penerimaan dapat berupa daftar yang dapat diperiksa: seluruh halaman utama tersedia, formulir diuji, tautan tidak putus, tampilan perangkat seluler stabil, metadata dasar terpasang, akses administrator diserahkan, serta cadangan dibuat dan uji pemulihan berhasil. Kriteria yang konkret mengurangi perbedaan persepsi mengenai arti “selesai”.
Rencanakan serah terima dan pemeliharaan
Serah terima tidak cukup dengan mengirim file. Catat domain, hosting, repositori kode, akun layanan, lisensi, konfigurasi, jadwal pembaruan, prosedur pencadangan, dan kontak dukungan. Pisahkan akun milik klien dari akun teknis pengembang. Tentukan pula siapa yang memperbarui konten, siapa yang menangani gangguan, dan bagaimana perubahan besar akan dikelola setelah masa proyek berakhir.
Daftar periksa ringkasan akhir
- Tujuan utama dan indikator keberhasilan.
- Kelompok pengguna dan kebutuhan informasinya.
- Peta halaman, konten, dan pemilik setiap materi.
- Fitur wajib, fitur tahap berikutnya, dan integrasi.
- Kebutuhan kinerja, perangkat seluler, aksesibilitas, keamanan, dan privasi.
- Ruang lingkup desain, jumlah revisi, jadwal, dan penanggung jawab keputusan.
- Kriteria penerimaan, serah terima, dokumentasi, dan pemeliharaan.
Ringkasan kebutuhan yang lengkap tidak berarti proyek tidak boleh berubah. Dokumen ini menyediakan garis dasar sehingga perubahan dapat dinilai secara sadar: apakah menambah manfaat, biaya, risiko, atau waktu. Dengan demikian, diskusi desain tetap fleksibel tanpa kehilangan kendali terhadap tujuan proyek.
Lanjut ke jasa website