Cara Desainer Menggunakan Claude: Brief, Teks UI, Kritik, dan Dokumen Handoff

Claude bisa menerima gambar, jadi Anda bisa memasukkan screenshot sebuah frame Figma, wireframe, atau layar yang sudah rilis dan langsung menanyakan hal-hal tentangnya: apakah hierarki ini masuk akal, apakah primary action-nya jelas, apakah ini sesuai dengan pola yang digunakan di layar sebelumnya.

Claude membaca piksel seperti orang yang sekilas melihat screenshot, bukan mem-parsing struktur layer atau properti komponen file Figma Anda. Claude tidak akan tahu design token, component library, atau frame mana yang 'asli' kecuali Anda memberitahunya. Perlakukan ini sebagai bacaan kedua yang cepat, bukan reviewer yang memahami design system Anda.

Versi paling berguna dari ini adalah yang sempit: satu layar, satu pertanyaan spesifik. 'Apakah error state di sini sudah jelas' menghasilkan jawaban yang lebih tajam daripada 'review seluruh flow ini,' sama seperti rekan tim memberikan jawaban yang lebih baik saat Anda menanyakan sesuatu yang spesifik daripada menyerahkan seluruh file kepadanya.

Misalnya sebuah proyek dimulai seperti kebanyakan proyek lain: sebuah thread Slack dengan product manager, percakapan di lorong yang hanya separuh diingat, dan beberapa baris di ticket yang tidak sepenuhnya sejalan satu sama lain. Daripada menatap template brief yang masih kosong, tempelkan semuanya ke Claude sebagai bahan mentah dan minta Claude memilah sinyal dari noise.

Minta langsung bagian-bagian yang dibutuhkan sebuah brief: apa sebenarnya masalah yang sedang dipecahkan, batasan apa yang sudah disebutkan (deadline, keterbatasan platform, aturan brand), apa yang dianggap sebagai keberhasilan, dan apa yang masih belum terselesaikan. Claude sering memunculkan kontradiksi yang Anda lewatkan, seperti batasan yang disebutkan sekali di awal thread tapi kemudian hilang begitu saja.

Hasilnya bukan versi final. Ini adalah draft pertama yang sudah terorganisir, bukan halaman kosong, yang artinya proses editing yang Anda lakukan setelahnya adalah mempertajam konten yang nyata, bukan menciptakan struktur dari nol. Itulah penghematan waktu yang sesungguhnya: bukan proses menulisnya, melainkan melewati tahap halaman kosong.

Membaca tentang alur kerja ini dan benar-benar menjalankannya adalah dua kemampuan yang berbeda. Jalur awal di bawah ini dirancang untuk menutup kesenjangan itu dalam tiga pelajaran singkat, dengan urutan berikut.

Mulai dengan "Tiga Cara Menggunakan Claude" dari course Tiga Mode, pelajaran lima menit yang membahas perbedaan antara chat singkat, sesi co-work bolak-balik yang lebih panjang, dan Claude Code. Sebagian besar pekerjaan desain, entah itu pertanyaan kritik, proses teks, atau brief, berada di dua mode pertama, jadi pelajaran ini membantu Anda memilih mode yang tepat daripada sekadar memakai tab mana pun yang sedang terbuka.

Lalu lanjutkan ke "Konteks adalah Segalanya" dari Prompting Strategis, juga lima menit. Ini adalah pelajaran yang mengubah brief yang generik menjadi brief yang benar-benar mencerminkan proyek Anda: membahas apa yang perlu ditempelkan (catatan Anda yang asli, brand voice Anda, layar yang spesifik) sehingga Claude tidak menebak-nebak konteks yang memang tidak pernah diberikan.

Selesaikan dengan "Loop Iterasi" dari Kuasai Dasar-Dasar, pelajaran enam menit tentang memperlakukan jawaban pertama Claude sebagai draft, bukan keputusan final. Bagi seorang desainer, ini adalah perbedaan antara menerima begitu saja set pertama opsi teks UI yang diberikan Claude dan benar-benar mempersempit delapan opsi menjadi dua lewat beberapa ronde follow-up.

Kesenjangan antara jawaban yang generik dan jawaban yang berguna hampir selalu terletak pada konteks yang Anda berikan. Khusus untuk pekerjaan desain, itu berarti menempelkan hal-hal yang ada di kepala atau file Anda tapi tidak pernah masuk ke dalam prompt singkat: catatan rapat yang sebenarnya, bukan ingatan Anda tentangnya, pedoman brand voice Anda jika sudah tertulis, dan screenshot yang spesifik, bukan deskripsi sebuah layar.

Ini juga berarti spesifik tentang scope. "Review flow ini" mengundang jawaban yang kabur dan berantakan. "Lihat layar konfirmasi dan beri tahu saya apakah secondary action bersaing dengan primary action" mengundang jawaban yang berguna. Semakin sempit pertanyaannya, semakin layak untuk ditanyakan.

Jika Anda akan menanyakan jenis pertanyaan yang sama berulang kali, seperti pemeriksaan aksesibilitas yang sama di setiap layar baru atau panduan tone yang sama untuk setiap teks UI, lebih baik tulis konteks itu sekali dan gunakan kembali, daripada menjelaskan ulang brand voice Anda di setiap percakapan.

Claude tidak menghasilkan UI yang siap produksi, tidak memanipulasi file Figma Anda, dan tidak menghafal panduan brand Anda kecuali Anda menempelkannya. Claude juga tidak bisa memvalidasi kehalusan visual seperti mata yang sudah terlatih; Claude bernalar tentang struktur, hierarki, dan kejelasan dari apa yang tampak di gambar, bukan tentang apakah sesuatu terasa pas di level piksel.

Untuk aksesibilitas, perlakukan pemeriksaannya sebagai tahap awal, bukan sign-off. Pekerjaan aksesibilitas yang sesungguhnya membutuhkan tools pemeriksaan kontras, pengujian screen reader, dan sering kali review dari spesialis, terutama untuk apa pun yang dirilis ke audiens luas. Jangan memberi tahu stakeholder atau compliance reviewer bahwa sebuah desain sudah diperiksa aksesibilitasnya hanya karena Claude melihat sebuah screenshot.

Kehati-hatian yang sama berlaku sebelum apa pun dikirim ke klien, pelanggan, atau rekan tim: baca apa yang dihasilkan Claude sebelum Anda mengirimkannya. Dokumen handoff dengan catatan interaksi yang salah tapi terasa yakin lebih buruk daripada tidak ada dokumen sama sekali, karena engineer akan membangun berdasarkan dokumen itu.

Claude juga hanya akan sebaik apa yang Anda berikan. Brief yang ditulis dari prompt dua baris akan terasa generik; brief yang ditulis dari transkrip percakapan asli atau kumpulan catatan asli akan benar-benar mencerminkan proyek tersebut.