Proyek website sering terasa jelas di kepala satu orang, tetapi menjadi kabur ketika harus diterjemahkan ke tim internal, designer, developer, content writer, procurement, dan vendor. Kalimat seperti “kami ingin website yang modern, cepat, SEO-friendly, dan bisa meningkatkan leads” terdengar masuk akal, tetapi belum cukup untuk menentukan apa yang sebenarnya harus dibangun.

Website brief adalah alat untuk mengubah keinginan tersebut menjadi konteks dan keputusan yang bisa dipakai bersama. Brief yang baik tidak harus menjawab semuanya sejak awal. Justru, ia harus membedakan mana yang sudah diputuskan, mana yang merupakan constraint, siapa yang bertanggung jawab, dan pertanyaan apa yang masih perlu dijawab lewat discovery.

Panduan ini ditujukan untuk Marketing Manager yang perlu menyiapkan website brief sebelum meminta proposal, memulai redesign, atau menyelaraskan tim internal dengan vendor. Di bagian akhir, Anda akan mendapatkan template yang bisa langsung disalin dan diadaptasi.

Website brief bukan daftar fitur

Kesalahan paling umum adalah memperlakukan brief sebagai wishlist: halaman apa saja yang ingin dibuat, fitur apa yang terlihat menarik, dan referensi website apa yang disukai. Informasi itu berguna, tetapi belum menjelaskan alasan di balik proyek atau bagaimana keputusan akan dievaluasi.

Brief yang lebih kuat menghubungkan empat lapisan: outcome bisnis, audience dan journey, scope dan requirement, lalu constraint serta acceptance criteria. Dengan urutan ini, vendor punya ruang untuk merekomendasikan solusi tanpa kehilangan batas proyek.

Brief menjadi lebih mudah dieksekusi ketika setiap requirement dapat ditelusuri kembali ke outcome, pengguna, dan constraint.

Alt text: Diagram empat lapisan website brief: outcome bisnis, audience dan journey, scope dan requirement, serta constraint dan acceptance criteria.

Delapan bagian yang sebaiknya ada dalam website brief

1. Konteks bisnis dan alasan proyek dimulai sekarang

Jelaskan kondisi yang memicu proyek. Apakah website lama sulit dikelola? Positioning berubah? Ada layanan baru? Tim ingin meningkatkan kualitas leads? Perusahaan sedang masuk pasar baru? Konteks ini membantu vendor memahami masalah yang perlu dipecahkan, bukan sekadar output yang diminta.

2. Outcome bisnis dan ukuran keberhasilan

Tuliskan satu tujuan utama dan beberapa indikator pendukung. Hindari tujuan seperti “website lebih bagus”. Gunakan bentuk yang dapat diamati, misalnya meningkatkan jumlah inquiry yang memenuhi kriteria, mengurangi ketergantungan pada tim sales untuk menjelaskan layanan dasar, atau memudahkan tim marketing menerbitkan landing page tanpa developer.

3. Audience prioritas dan journey

Tidak perlu menulis persona sepanjang tiga halaman. Cukup jelaskan siapa pengguna prioritas, konteks mereka ketika datang ke website, pertanyaan atau keraguan utama, dan tindakan yang perlu mereka selesaikan. Untuk bisnis B2B, stakeholder yang meneliti layanan bisa berbeda dari orang yang memberi approval akhir.

4. Scope halaman, konten, dan fungsi

Pisahkan struktur informasi dari fitur. Untuk halaman, tuliskan tipe atau template yang dibutuhkan, bukan hanya jumlah URL. Untuk fungsi, jelaskan kebutuhan dalam bahasa tugas pengguna: “pengunjung dapat mengirim brief dan menerima konfirmasi” lebih berguna daripada “buat form canggih”.

5. Konten, SEO, analytics, dan integrasi

Tentukan siapa menulis copy, menyiapkan asset, melakukan migrasi, menentukan redirect, memasang metadata, mengatur Search Console, GA4/GTM, CRM, email marketing, WhatsApp, payment, atau sistem lain. Hal-hal ini sering menjadi dependency yang tidak terlihat pada timeline awal.

6. Constraint, asumsi, dan hal yang tidak termasuk

Constraint membantu vendor memilih solusi yang realistis: budget range, deadline eksternal, teknologi yang wajib dipakai, kebijakan keamanan, legal, kemampuan tim internal, atau keterbatasan data. Tuliskan juga asumsi yang belum tervalidasi dan out-of-scope awal supaya tidak berubah diam-diam menjadi komitmen.

7. Governance, timeline, dan responsibility

Sebutkan siapa PIC harian, siapa pemilik keputusan, siapa reviewer legal/brand/IT, dan berapa lama SLA feedback internal yang realistis. Banyak timeline gagal bukan karena development lambat, tetapi karena keputusan dan material datang terlambat.

8. Acceptance criteria dan handover

Definisikan apa arti “selesai”. Contoh: form mengirim data ke CRM dan menampilkan success state; redirect prioritas diuji; event utama muncul di DebugView; halaman dapat diedit oleh role tertentu; dokumentasi dan akses akun diserahkan. Acceptance criteria mengubah ekspektasi subjektif menjadi pemeriksaan yang bisa dilakukan bersama.

Pisahkan scope, responsibility, dan unknown

Tidak semua hal harus dipastikan sebelum vendor terpilih. Yang penting adalah statusnya terlihat. Satu requirement dapat masuk ke salah satu dari tiga kelompok: sudah termasuk scope, menjadi tanggung jawab tim klien, atau masih perlu discovery. Pemisahan ini membuat proposal lebih mudah dibandingkan dan mengurangi asumsi tersembunyi.

Gunakan tiga kolom untuk membedakan scope pasti, dependency klien, dan area yang masih membutuhkan discovery.

Alt text: Diagram scope boundary canvas dengan tiga kolom: in scope, client responsibility, dan discovery atau unknown.

Contoh: dari brief kabur menjadi brief yang bisa ditindaklanjuti

Terlalu kabur	Lebih operasional
“Website harus modern.”	“Visual perlu terasa profesional dan teknis untuk buyer B2B; keputusan desain harus mengikuti brand guideline dan tetap nyaman dibaca di mobile.”
“Butuh SEO.”	“Migrasi mempertahankan URL prioritas bila memungkinkan, redirect lama dipetakan, sitemap dan metadata dasar disiapkan, lalu Search Console diverifikasi setelah launch.”
“Harus banyak leads.”	“CTA utama pada service page adalah request consultation; submit harus masuk ke CRM, memiliki success state, dan dapat dibedakan dari klik kontak biasa di analytics.”
“Launch Oktober.”	“Target go-live minggu pertama Oktober; konten final dari tim marketing paling lambat 10 hari kerja sebelum UAT. Jika dependency terlambat, tanggal launch perlu dievaluasi ulang.”

Template website brief siap salin

Gunakan template berikut sebagai titik awal. Jawaban pendek tetapi jelas lebih berguna daripada paragraf panjang yang tidak menghasilkan keputusan. Jika suatu bagian belum diketahui, tulis “perlu discovery” dan tambahkan siapa yang perlu membantu menjawabnya.

1. Ringkasan proyek

• Apa yang sedang dibuat atau diperbarui? ______________________________
• Mengapa proyek ini dimulai sekarang? ______________________________
• Apa perubahan bisnis yang harus didukung website? ______________________________

2. Outcome dan success criteria

• Outcome utama: ______________________________
• Indikator pendukung: ______________________________
• Apa yang akan membuat proyek dianggap gagal meskipun website berhasil launch? ______________________________

3. Audience dan journey

• Audience prioritas: ______________________________
• Pertanyaan/keberatan utama mereka: ______________________________
• Tindakan utama yang perlu diselesaikan: ______________________________
• Sumber traffic utama yang diperkirakan: ______________________________

4. Scope dan struktur

• Tipe halaman/template: ______________________________
• Fungsi utama: ______________________________
• Integrasi: ______________________________
• Kebutuhan mobile/responsive khusus: ______________________________
• Bahasa/region: ______________________________

5. Konten, SEO, dan measurement

• Owner copy dan asset: ______________________________
• Konten yang perlu dimigrasikan: ______________________________
• Kebutuhan redirect/SEO foundation: ______________________________
• GA4/GTM/key events: ______________________________
• CRM atau sistem tujuan data: ______________________________

6. Constraint dan boundary

• Budget range: ______________________________
• Deadline atau tanggal eksternal: ______________________________
• Teknologi/security/legal constraint: ______________________________
• Out of scope: ______________________________
• Asumsi yang belum tervalidasi: ______________________________

7. Governance dan responsibility

• PIC harian: ______________________________
• Final approver: ______________________________
• Reviewer lain: ______________________________
• SLA feedback internal: ______________________________
• Client responsibility: ______________________________

8. Acceptance dan handover

• Kriteria penerimaan fungsi utama: ______________________________
• Browser/perangkat prioritas: ______________________________
• Akses/source/account yang harus diserahkan: ______________________________
• Dokumentasi/training: ______________________________
• Support atau warranty setelah launch: ______________________________

Lima kesalahan yang membuat brief justru membingungkan

• Mengunci solusi terlalu cepat. Brief mengatakan “harus memakai teknologi X” tanpa menjelaskan constraint yang membuat teknologi tersebut wajib.
• Menyamakan referensi dengan requirement. Website kompetitor boleh menjadi bahan diskusi, tetapi jelaskan bagian apa yang relevan: struktur, tone, interaksi, atau model kontennya.
• Tidak menyebut siapa yang menyiapkan konten. Copy, foto, legal text, product data, dan asset sering menjadi critical path proyek.
• Tidak membedakan must-have dan nice-to-have. Semua item terlihat sama penting sehingga scope sulit diprioritaskan ketika budget atau timeline berubah.
• Tidak menulis apa yang belum diketahui. Unknown yang disembunyikan akan muncul kembali sebagai revisi, change request, atau keterlambatan.

Cara menggunakan brief saat memilih vendor

Brief bukan dokumen yang dikirim lalu dilupakan. Gunakan versi yang sama sebagai referensi pada tiga momen: saat meminta proposal, saat discovery, dan saat kickoff. Perubahan penting setelah itu masuk ke decision log atau change request supaya konteks keputusan tidak hilang.

• Kirim brief yang sama ke vendor yang dibandingkan agar proposal punya baseline yang setara.
• Minta vendor menandai asumsi, exclusion, dependency, dan bagian yang menurut mereka masih terlalu kabur untuk diestimasi.
• Bandingkan proposal berdasarkan scope dan responsibility, bukan hanya jumlah halaman atau harga total.
• Setelah vendor dipilih, revisi brief bersama menjadi baseline proyek dan tambahkan acceptance criteria yang lebih detail.
• Simpan keputusan baru beserta tanggal, owner, dan dampaknya pada scope/timeline supaya revisi tidak bergantung pada ingatan.

Brief yang baik membuat diskusi lebih tajam, bukan lebih panjang

Website brief tidak perlu menjadi spesifikasi teknis lengkap. Fungsinya adalah memberi konteks yang cukup agar tim dan vendor dapat mengajukan pertanyaan yang benar, membuat estimasi yang masuk akal, serta mengetahui batas keputusan. Jika brief terlalu detail sampai mencoba mendesain solusi sebelum discovery, ia justru dapat membatasi pilihan. Jika terlalu umum, vendor harus mengisi kekosongan dengan asumsi.

Targetnya adalah titik tengah: outcome jelas, audience prioritas diketahui, boundary proyek terlihat, dependency punya owner, dan unknown ditandai. Dari sana, sitemap, UX, teknologi, konten, dan roadmap dapat dibentuk bersama berdasarkan kebutuhan yang nyata.

Perlu menyusun scope website sebelum meminta proposal? Website Consultation membantu tim Anda memetakan tujuan, scope, responsibility, dan pertanyaan discovery sebelum keputusan desain atau teknologi dikunci. Mulai Website Consultation via WhatsAppBawa brief yang sudah ada, daftar kebutuhan, atau contoh proposal vendor agar diskusi dimulai dari konteks nyata.

FAQ

Berapa panjang website brief yang ideal?

Tidak ada jumlah halaman baku. Untuk proyek website perusahaan yang tidak terlalu kompleks, brief beberapa halaman yang fokus biasanya cukup sebagai baseline. Detail teknis dapat berkembang lewat discovery. Yang penting adalah keputusan, constraint, dependency, dan unknown terlihat.

Apakah website brief sama dengan sitemap?

Tidak. Sitemap hanya menjelaskan struktur halaman. Brief memberi konteks yang lebih luas: tujuan bisnis, audience, scope, requirement, content ownership, timeline, budget, governance, dan acceptance criteria.

Apakah vendor boleh mengubah brief?

Vendor sebaiknya tidak mengubah tujuan bisnis sepihak, tetapi mereka justru perlu menantang asumsi dan memberi rekomendasi terhadap struktur atau solusi. Brief adalah baseline diskusi, bukan kontrak desain yang tidak boleh dipertanyakan.

Apakah budget harus ditulis di brief?

Jika ada batas budget atau range realistis, mencantumkannya membantu vendor menyusun scope dan prioritas yang sesuai. Jika budget belum final, setidaknya jelaskan constraint dan bagaimana keputusan budget akan dibuat.

Kapan brief perlu diperbarui?

Perbarui ketika outcome, scope, timeline, responsibility, atau constraint berubah secara material. Setelah proyek berjalan, perubahan penting sebaiknya juga dicatat dalam decision log agar alasan dan dampaknya tetap dapat ditelusuri.