Cara Mengelola Revisi Klien: Siklus Hidup Satu Revisi

Revisi yang terasa berantakan jarang soal kurang banyak feedback. Masalahnya lebih sering ada di tiga pertanyaan yang tidak terjawab jelas: feedback ini untuk versi yang mana, siapa yang mengerjakannya, dan apakah hasil perbaikannya sudah benar-benar diperiksa ulang atau baru sekadar dikerjakan. Revisi butuh status/progres yang bisa diikuti, bukan cuma percakapan yang berjalan maju.

Satu feedback yang bisa dikerjakan

Feedback yang bisa langsung dikerjakan biasanya menyebut empat hal: bagian yang dimaksud, masalah yang ditemukan, perubahan yang diminta, dan versi yang dirujuk. Feedback yang cuma menyebut kesan umum ("kurang pas", "kurang enak") memaksa creator menebak, dan tebakan yang salah berarti revisi harus diulang.

Siklus hidup satu revisi

1. 1. Versi 1 dikirim untuk review. Item berstatus "Menunggu review".
2. 2. Reviewer menemukan masalah. Reviewer membuat komentar pada bagian spesifik di Versi 1 — komentar berstatus "Perlu revisi", item berstatus "Perlu revisi".
3. 3. Creator mengerjakan perbaikan. Item bisa ditandai "Sedang direvisi" selama creator bekerja pada perbaikan yang diminta.
4. 4. Creator menandai komentar "Sudah diperbaiki". Ini status dari sisi creator — bukan konfirmasi dari reviewer bahwa perbaikannya sudah benar.
5. 5. Creator mengunggah Versi 2. Versi 1 tetap tersimpan sebagai riwayat, tidak tertimpa oleh Versi 2.
6. 6. Reviewer memeriksa ulang Versi 2. Item berstatus "Siap direview". Reviewer memeriksa apakah perbaikan di komentar yang ditandai "Sudah diperbaiki" sudah benar-benar sesuai.
7. 7. Reviewer menyatakan "Disetujui" atau membuka lagi. Kalau sesuai, komentar berstatus "Disetujui". Kalau belum, reviewer membuka lagi permintaan itu dan item kembali berstatus "Perlu revisi".

Reply, dikerjakan, dan diperiksa adalah tiga hal berbeda

Creator membalas "Siap Kak, saya perbaiki" belum berarti revisi selesai — itu baru komunikasi. Creator mengunggah versi baru belum otomatis berarti reviewer sudah menerima perbaikannya — itu baru pekerjaan dilakukan. Reviewer membuka dan melihat hasilnya belum otomatis berarti disetujui — reviewer masih perlu menyatakan keputusan secara eksplisit. Balasan creator, dengan sendirinya, tidak mengubah status permintaan revisi.

Tiga hal ini — komunikasi, pekerjaan dilakukan, dan keputusan reviewer setelah memeriksa ulang — perlu tetap terpisah. Menyamakan ketiganya adalah salah satu sumber paling umum dari "saya kira sudah selesai" di kedua sisi.

Kenapa feedback harus terhubung ke versi

Feedback yang dibuat di Versi 1 seharusnya tetap tercatat sebagai feedback untuk Versi 1, bukan lepas dari konteks versinya. Risikonya konkret: logo yang salah di Versi 1 sudah diperbaiki di Versi 2, tapi kalau reviewer baru membaca ulang komentar lama tanpa tahu itu dibuat untuk Versi 1, revisi bisa terlihat belum selesai padahal sudah. Menghubungkan setiap komentar ke versi tempat komentar itu dibuat menghilangkan ambiguitas ini — komentar lama tetap bisa dibaca sebagai riwayat, tanpa disalahartikan sebagai masalah yang masih ada di versi terbaru.

Contoh ilustratif: revisi salah ejaan pada headline

Contoh ilustratif, bukan kasus nyata: Versi 1 sebuah banner punya headline bertuliskan "Promo Spesiall". Feedback yang dibuat: "Pada headline utama tertulis 'Promo Spesiall'. Ubah menjadi 'Promo Spesial'." Creator memperbaiki ejaan tersebut dan mengunggah Versi 2. Reviewer memeriksa ulang khusus bagian headline itu, melihat ejaannya sudah benar, dan menandai komentar tersebut "Disetujui". Yang berubah: ejaan headline. Yang tetap: seluruh elemen desain lain di luar bagian yang direvisi. Revisi ditutup begitu reviewer menyatakan keputusannya, bukan begitu creator selesai mengedit.

Kapan revisi benar-benar selesai

Revisi belum selesai hanya karena creator sudah membaca, sudah membalas, atau bilang "selesai". Secara operasional, revisi selesai setelah: perubahan dilakukan, hasil baru (versi baru) tersedia, reviewer dapat memeriksa hasil tersebut, dan reviewer menyatakan permintaan itu sudah sesuai atau melanjutkan ke keputusan berikutnya.

Kalau feedback berubah di tengah jalan

Reviewer awalnya minta A, tapi setelah melihat hasil revisinya, ternyata minta B. Situasi ini perlu dibedakan: apakah B adalah bagian dari permintaan A yang belum sepenuhnya dikerjakan, atau benar-benar permintaan baru yang berbeda dari sebelumnya. Secara operasional, feedback baru sebaiknya dicatat sebagai permintaan baru kalau memang berbeda dari permintaan sebelumnya, supaya histori tetap terbaca — bukan ditumpuk begitu saja di atas permintaan lama seolah-olah itu revisi yang sama.

Revisi lama muncul lagi

Satu pola berbeda yang perlu ditangani beda juga: sebuah masalah sudah ditemukan di Versi 1, diperbaiki di Versi 2, tetap benar di Versi 3, tapi muncul lagi di Versi 4 — misalnya karena file lama tidak sengaja terpakai ulang saat proses lain. Ini bukan kasus "revisi belum pernah dikerjakan", karena riwayatnya menunjukkan revisi itu memang pernah selesai dan diperiksa. Riwayat per versi yang tidak saling menimpa membuat perbedaan ini bisa terlihat jelas, alih-alih dua kasus itu terlihat sama dari luar.

Kalau revisinya sudah selesai dan tinggal minta persetujuan akhir, baca cara meminta approval desain dari klien