Sekarang saya lebih sering mendesain dengan Claude daripada Figma
(blog.janestreet.com)- Beralih dari menulis dokumen spesifikasi dan mockup Figma ke alur kerja desain yang langsung mewujudkan ide di kepala menjadi fitur prototipe yang benar-benar berfungsi
- Dulu skeptis terhadap LLM seperti Copilot, Cursor, dan Gemini, tetapi setelah bergabung dengan Jane Street menyadari bahwa bantuan AI itu esensial
- Claude memungkinkan iterasi gratis tanpa batas, sehingga bahkan setelah 50 kali perubahan tetap bisa melakukan penyempurnaan detail seperti tombol Submit, shortcut, dan revisi copy tanpa keluhan
- Desainer pun bisa, seperti engineer, membuat sendiri proof of concept (POC) yang berfungsi agar orang lain bisa langsung mencobanya dan menilai
- Dengan memusatkan seluruh upaya pada hasil akhir yang nyata, pendekatan ini menghapus pekerjaan sampingan di tahap perantara dan berujung pada model kolaborasi baru
Beralih dari skeptisisme terhadap LLM
- Selama bertahun-tahun bersikap skeptis terhadap LLM, dan setiap kali memakainya hasilnya mengecewakan
- Tahun lalu mencoba Copilot dan Cursor untuk memodifikasi game buatan sendiri, tetapi keduanya gagal menghasilkan perubahan yang benar-benar berjalan
- Di tempat kerja sebelumnya membuat outline product brief dan wireframe dengan Gemini, tetapi semuanya akhirnya dibuang
- Semua area tempat LLM dicoba adalah hal-hal yang sebenarnya sudah dikuasai, dan hasilnya lebih buruk daripada mengerjakannya sendiri
- Setelah bergabung dengan Jane Street musim panas lalu, terasa jelas bahwa dukungan AI itu penting
- Karena ada banyak area baru yang masih belum dikuasai, seperti OCaml dan Bonsai
- Kejutan terbesar adalah berubahnya alur kerja desain, yaitu area yang paling dikuasai
Alur kerja berpusat pada prototipe
- Alih-alih menulis dokumen spesifikasi, membuat mockup Figma, menyusun proposal, dan meninjau implementasi bersama developer, kini langsung membangun sendiri fitur prototipe yang menjalankan fungsi yang dimaksud
-
Alur kerja nyata
- Menuliskan masalah dan usulan dalam bentuk teks
- Membuka editor, menjalankan build, server, dan Claude, lalu memakai penjelasan tadi sebagai prompt
- Membuat fungsi dasar berjalan terlebih dahulu untuk membuktikan kemungkinan implementasinya
- Mengulang sebanyak yang diinginkan
- Mendorong perubahan ke environment pengembangan dan mengumpulkan masukan pengguna
- Mengajukan feature—padanan pull request di perusahaan ini—yang sudah memiliki tampilan dan perilaku yang diinginkan
- Prototipe di dalam codebase nyata terbukti lebih baik daripada mockup atau dokumen dalam hampir semua hal
Contoh prototipe input JSQL
- Baru-baru ini membuat prototipe yang menambahkan prompting LLM ke input JSQL
- JSQL adalah dialek SQL internal yang dipakai pada berbagai alat untuk pengguna
- Prototipe itu benar-benar berfungsi, lalu dipakai, diuji, dan dihidupi selama beberapa hari
- Claude memungkinkan iterasi gratis tanpa batas, jadi tidak masalah meski berubah pikiran untuk ke-50 kalinya atau meminta revisi kecil
- Menyempurnakan tombol Submit, menambahkan shortcut keyboard, mengubah copy, menyesuaikan prompt, dan menambahkan pesan konfirmasi generatif
- Di tempat kerja sebelumnya, perbaikan seperti ini akan membutuhkan bolak-balik engineering dan desain selama beberapa hari hingga beberapa minggu, atau bahkan tidak pernah terjadi
- Seluruh upaya dicurahkan untuk meningkatkan hasil nyata, bukan untuk pekerjaan sampingan seperti membuat komponen Figma atau merapikan format dokumen
Proses memantapkan alur kerja
- Butuh waktu untuk sampai ke pendekatan ini
- Pada awal bergabung, AI hanya dipakai untuk pekerjaan kecil seperti memperbaiki cacat kecil UX
- Untuk ide yang lebih besar masih tetap memakai Figma dan dokumen, dan percobaan dengan Claude sering gagal
- Dalam dua bulan terakhir, momen untuk meraih Figma menurun drastis
- Kombinasi peningkatan model, bertambahnya keterampilan pribadi, dan pemilihan cakupan yang tepat membuat AI mulai efektif untuk pekerjaan besar juga
- Selain prompt JSQL, ada banyak prototipe lain yang menangani perubahan untuk pengguna, model data, dan library, beberapa di antaranya memiliki diff lebih dari 2000 baris
- Setelah merancang di Figma lalu mengimplementasikan prototipe interaktif, atau untuk sebagian app baru bahkan sepenuhnya melewati Figma dan mengiterasi desain visual dengan Claude sejak awal
Kekuatan baru bagi desainer
- Engineer bisa langsung membuat proof of concept yang berfungsi saat punya ide, tetapi desainer biasanya harus lebih dulu meyakinkan orang lain
- Ide seperti "prompting LLM langsung di dalam input JSQL" bahkan belum jelas kelayakannya saat dimulai, jadi jika meminta orang lain membuat prototipe, itu bisa menjadi pemborosan waktu
- Bisa juga usulan itu ternyata tidak benar-benar memenuhi kebutuhan pengguna
- Ketika ide benar-benar diwujudkan dengan Claude, orang lain jadi jauh lebih mudah menilai dengan langsung mencobanya
Tantangan dalam cara review
- Kekurangannya adalah reviewer menerima fitur yang sudah jadi
- Muncul pertanyaan apakah mereka akhirnya hanya meninjau kode tanpa punya ruang memberi masukan pada fiturnya sendiri
- Ini mirip dengan situasi di ranah desain ketika menerima wireframe detail dari PM lalu hanya diminta untuk "membuatnya terlihat bagus"
- Harapannya, usulan dibuat sejelas dan selengkap mungkin, sambil tetap ingin rekan engineer ikut beriterasi di ranah desain seperti ketika bekerja dari mockup Figma
-
Solusi saat ini
- Melihat feature dengan cara yang berbeda, lalu menuliskan panduan singkat di penjelasannya
- Prototipe adalah dokumen usulan yang hidup, kodenya bersifat sekali pakai, dan peran reviewer adalah memberi masukan tentang desain serta pengalaman pengguna
- Pada akhirnya reviewer mengambil alih ide tersebut dan mengimplementasikannya dalam feature terpisah, merujuk pada prototipe tetapi memiliki penuh production code
- Masih terus mencari bentuk yang terasa masuk akal dan baik
Kekhawatiran dan ketegangan yang terasa akrab
- Ada kekhawatiran bahwa mendesain dengan Claude bisa membuat seseorang keluar dari pola pikir yang lentur dan kreatif, lalu terjebak dalam pemikiran iteratif yang dibatasi oleh hasil yang dianggap bisa dibuat Claude
- Ini mungkin tidak masalah untuk alat matang yang berubah secara bertahap, tetapi saat mengerjakan hal baru bisa membuat ide-ide penting terlewat
- Ini adalah ketegangan yang terasa akrab, dan terhubung dengan perdebatan tahun 2011 tentang "haruskah desainer menulis kode"
- Para pengkritik berargumen bahwa begitu mulai memrogram, akan lebih sulit membuat perubahan besar pada ide
- Namun karena sama-sama menyukai pembuatan website dan pemrograman, tetap terus menulis kode
- Ketika framework frontend seperti React menjadi umum dan pengembangan makin kompleks, pilihan akhirnya mengarah ke spesialisasi
- Proyek pribadi masih tetap dibuat dengan React, dan itu membantu komunikasi dengan developer
- Sebagian besar waktu kerja tetap dihabiskan untuk Figma dan dokumen
- Jika bergabung ke Jane Street sebelum era LLM, kemungkinan akan tenggelam lebih dalam di Figma
- Ada sedikit pengalaman dengan JavaScript, tetapi OCaml dan Bonsai benar-benar baru sehingga kontribusi teknis akan terasa di luar jangkauan
- Sebaliknya, kini bisa kembali membuat hasil nyata, kembali ke medium itu terasa menyenangkan, dan kebebasan untuk mencoba apa pun terasa jauh lebih besar
1 komentar
Komentar Hacker News
Dari sisi bisnis, mereka sudah sering datang membawa solusi yang mereka pikirkan sendiri sebagai bentuk requirement, dan biasanya seperti alat Rube Goldberg, jadi harus di-reverse-engineer lewat percakapan dulu untuk sampai ke requirement yang sebenarnya
Ke depannya, sepertinya mereka akan datang membawa solusi yang sudah “siap” dan “berfungsi”, dan akan makin tidak terbuka terhadap ajakan untuk melihat desain dan arsitektur secara menyeluruh
Kemungkinan akan jadi, “Kan tinggal dibuat begini saja. Sudah hampir selesai, kenapa masih perlu X engineer?”
Kekurangannya, pihak bisnis tidak paham kenapa aplikasi itu tidak bisa langsung dijalankan di produksi begitu saja
Tekanan seperti “kan bisa dipercepat pakai AI” akan makin besar, dan pada akhirnya ini akan bergantung pada dinamika organisasi yang sehat atau tidak
Sisi positifnya, idenya sudah diuji jauh lebih menyeluruh dibanding sketsa di atas serbet
Claude kemungkinan besar sudah menanyakan edge case dan keputusan desain, dan ada peluang besar pada titik tertentu mereka secara eksplisit bilang, “anggap saja itu tidak penting” atau “setelah dicoba beberapa kali, interaksi ini kurang bagus, tolong ubah”
Saat ini tekanan “apa masalahnya, tinggal deploy saja” masih kuat, bodoh, dan mematahkan semangat sehingga nyaris jadi rugi bersih, tapi kalau nanti stabil, bisa saja menjadi keuntungan bersih untuk proyek-proyek masa depan
Perbaikan kecil itu misalnya layout rusak kalau lebar browser tidak tepat 1920px, filter dan sorting kadang tidak jalan dengan benar, atau nilai baru tidak terbarui dengan benar di aplikasi setelah tindakan tertentu
Terlepas dari masalahnya, pihak bisnis mengira mereka sudah menyelesaikan 95%, jadi dari awal berasumsi bahwa “developer berpengalaman pasti bisa cepat membereskannya”
Orang jadi terbiasa dengan hasil yang mereka punya, dan makin sulit menerima perubahan dari mixing profesional yang baru
Memang ada PM, CSM, dan TAM yang punya insting untuk menerjemahkan masalah pelanggan menjadi fitur produk yang usable, tetapi kalau definisi masalah dilewati dan organisasi fungsi lain dipaksa membuat solusi, biasanya itu berakhir jadi bencana yang membuang banyak sumber daya engineering dan sumber daya lain
Kalau seseorang datang membawa solusi, ada risiko besar baru setelah berbulan-bulan membangun software yang layak dioperasikan kita sadar bahwa pelanggan membencinya, tidak menyelesaikan masalah mereka, atau malah menciptakan masalah baru
Bukan di tempat saya sekarang, tetapi di tempat lama saya, hal seperti ini bahkan sampai dideploy ke produksi meski membawa kehilangan data dan masalah keamanan
Setahu saya Jane Street adalah investor Anthropic, jadi hal itu perlu diperhitungkan
Ada juga fakta bahwa pada Juli 2025, regulator pasar modal India SEBI menuduh Jane Street melakukan manipulasi pasar lewat beberapa entitas dan melarang akses mereka ke pasar
Wajar saja, peti uang yang besar pasti butuh banyak dashboard
Di sini, si desainer tampaknya mengambil pendekatan yang keliru dan terlihat terjebak dalam kekaguman pada engineer, ingin membuat prototipe sedalam dan serealistis mungkin
Padahal itu bukan bagian terpenting dari pekerjaan desain
Yang paling penting adalah memastikan yang dibuat itu memang hal yang benar
Pertanyaan seperti “kenapa perlu kotak input JSQL? sebenarnya yang diinginkan apa? alternatifnya apa?” sering kali lebih baik dipecahkan lewat sketsa pena dan kertas, rapat, observasi, dan diskusi
Itu lebih baik daripada terlalu cepat mengerucut ke desain tertentu lalu masuk ke perdebatan seperti tombolnya di kiri atau kanan, atau detail perilaku LLM seperti apa
Meski tentu saja, bisa jadi memang itulah yang mereka ingin orang pikirkan
Kadang saya melihat ini juga
Saat ini LLM tidak bisa melihat melampaui pengulangan, jadi saya harus berpikir out of the box dan berkata, “bagaimana kalau dilihat dari sudut pandang ini?” baru tiba-tiba muncul cara desain yang baru
Kadang saya harus membuat diagram alur agar LLM bisa melihat melampaui tahap progresnya sendiri
Dari kalimat “Claude memberi saya iterasi gratis tak terbatas yang tidak peduli kalau saya berubah pikiran untuk ke-50 kalinya atau meminta revisi kecil,” memangnya dia tidak membayar Claude?
Studio desain kecil juga mirip, dan sering kali bukan ditagih per jam seperti developer
Saya menjawab dengan jujur bahwa saya benar-benar buruk dalam desain, dan bahkan kesulitan mengekstrapolasi design system
Sangat sulit bagi saya untuk mencapai titik yang terlihat oke, dan dalam prosesnya hampir selalu malah saya buat lebih buruk
Desainer yang mewawancarai saya menganggapnya personal dan menekan saya
Sebelumnya juga pernah mirip begitu
Para desainer tidak suka dengan pertanyaan yang terus-menerus tentang tampilannya harus seperti apa, dan maunya serah-terima sekali lewat lalu selesai
Bahkan di agensi marketing dan periklanan, saya harus terus berdebat untuk meminta contoh bagaimana hal-hal yang tidak ada di spesifikasi desain itu seharusnya terlihat
Bukan berarti saya pasti benar, tetapi itu memang tumit Achilles besar bagi saya
Jadi ketika saya mendengar “gratis, iterasi tak terbatas, tidak peduli”, yang terlintas duluan bagi saya adalah waktu dan kesabaran, bukan uang
Bolt yang saya pakai untuk prototyping tidak pernah marah
Mungkin tidak menghasilkan desain terbaik, tetapi jauh lebih baik daripada yang bisa saya buat sendiri, dan setelah selesai bisa diberikan ke desainer sungguhan untuk diperbaiki lagi
Sampai saat itu, saya tidak perlu khawatir membuat seseorang kesal
Saya sudah memakai Claude Design untuk frontend.
Bentuk dan nuansa hasilnya sudah cukup bagus, tetapi desainnya sering terlihat mirip dan umumnya mengikuti pola klise web modern.
Saya penasaran apakah ada yang pernah mencoba eksperimen kreatif yang tidak lazim dengan ini.
Sejauh ini saya menghabiskan sekitar 3 minggu dan masih belum selesai, tetapi Anda akan menangkap maksudnya.
Seperti halnya ada boilerplate SaaS selama 10 tahun terakhir, ada juga boilerplate LLM yang dipelajari dari internet.
Meski begitu, jika cukup banyak campur tangan manual, apa pun tetap mungkin dilakukan.
Menarik bahwa ia bisa menyesuaikan saat diberi kebutuhan, dan membuat pilihan aman saat tidak diberi arahan.
Jika Anda akan menilai estetika output serta pengalaman pengguna dan kontennya, tetapi hampir tidak memberi prompt soal estetika, ya yang Anda dapat hanya default aman.
Ia bagus dalam membuat desain yang terasa seperti tiruan bootstrap/tailwind, tetapi bagian itu memang perlu didorong secara sadar.
Untuk halaman web sederhana, saya mulai menjadikan gaya visual sebagai satu-satunya fokus pada iterasi awal.
Tinggal beri instruksi spesifik agar tidak terlihat standar, lalu beri contoh gaya situs web yang diinginkan.
Kalau sedikit diutak-atik, hasilnya terasa lebih kreatif, tetapi tetap perlu rekayasa prompt.
Ini direkomendasikan oleh desainer yang sangat dihormati dan berpengalaman, dan sekarang mereka hampir sepenuhnya membuat prototipe di Claude lalu menyempurnakannya di Figma jika sudah suka.
Wajar saja kalau meminta UI umum tanpa prompt gaya yang detail, hasilnya juga desain umum.
Keuntungan di sini adalah desainer belajar coding.
Selalu terasa aneh bagi saya bahwa desainer membentuk software tanpa tahu bagaimana software dibuat.
Sebagai catatan, saya juga seorang desainer.
Hanya saja, mendesain lewat kode adalah pendekatan berpusat pada teknologi.
Jika tujuan desain adalah membentuk keluaran agar sesuai dengan tujuan manusia, bisa juga dikatakan lebih baik tidak memulai dari aturan kaku kode.
Bukan karena hasil yang enak dilihat, tetapi untuk mendorong pemikiran ke depan, pena dan kertas masih sulit dikalahkan.
Sekarang kita pada dasarnya bisa coding dengan suara, jadi saya kembali lagi ke vibe coding dan membangun produk, dan rasanya luar biasa.
Atasan saya masih mencoba memahami situasi baru ini, tetapi pembagian peran lama tampaknya mulai mati.
Menurut saya, berada di persimpangan itu adalah posisi terbaik saat ini.
Rasanya seluruh hidup saya telah mempersiapkan momen ini.
Bagi desainer, ini mungkin seperti Figma di mana Anda melihat hasil lalu merevisinya dengan bahasa alih-alih editor visual.
Istri saya adalah manajer produk di FAANG, dan timnya sangat mengandalkan AI untuk vibe coding potongan software yang tadinya akan mereka kerjakan dengan Word atau Excel.
Mereka tidak belajar coding, dan tidak pernah melihat kode itu sedetik pun.
Pendekatan bahwa “prototipe adalah dokumen usulan yang hidup, kodenya boleh dibuang, dan tugas reviewer adalah memberi umpan balik pada desain serta pengalaman pengguna.
Pada akhirnya reviewer mengambil idenya lalu mengimplementasikannya sebagai fitur terpisah, menjadikan prototipe sebagai referensi, tetapi tetap memiliki kode produksi sendiri” menyelesaikan masalah yang selalu saya alami di semua POC.
Ini pendekatan yang sangat bagus.
Saat membahas isu spesifik dari produk tertentu, memang mudah menyebutnya “dokumen usulan”.
Namun tetap ada sangat banyak desainer yang memakai Figma untuk mendefinisikan dan memelihara sistem desain lintas produk dan platform, dan dalam kasus itu Figma adalah sumber kebenaran.
Tim kami juga bekerja seperti ini, dan saya seorang engineer frontend, tetapi sejujurnya saya sangat merindukan cara lama.
Karena spesifikasi tertulis digantikan oleh prototipe yang berjalan, sekarang ada beban kognitif tambahan: saya harus membaca kodenya dan menilai perubahan mana yang memang dimaksudkan, dan mana noise yang harus dibuang.
Saya menerima PR yang dihasilkan lalu harus memutuskan apakah akan melakukan perubahan yang diperlukan atau membangunnya ulang dari nol, dan apa pun pilihannya tetap menimbulkan gesekan.
Pernah juga banyak perubahan tak disengaja ikut dihasilkan, lalu setelah saya menghabiskan waktu memindahkannya lewat implementasi ulang, belakangan saya mendengar, “Oh, maaf, itu sebenarnya bukan yang mau diubah.”
Saya paham bahwa ini memberi lebih banyak kuasa, tetapi juga merampas sebagian kesenangan yang dulu saya rasakan dalam pekerjaan ini dan mengubahnya jadi sumber pusing.
Tim desain dan produk melakukan vibe desain dan coding fitur atau pengalaman dengan Claude, membuat prototipe dengan cepat, lalu membawanya ke hadapan pelanggan untuk mendapat masukan dengan waktu engineering yang minimal.
Itu hebat.
Namun mungkin mengejutkan bahwa secara keseluruhan ini tidak terlalu membantu peluncuran jadi lebih cepat.
Menurut saya alasannya adalah karena kita kehilangan proses berpikir di sepanjang jalan.
Tidak sedikit pemikiran yang sekarang dialihdayakan ke model bahasa.
Ia menutupi celah dalam prompt dan mengisi perilaku yang tidak disebutkan secara eksplisit dengan halusinasi.
Dulu kita akan berhenti di titik-titik seperti “ini kurang pas”, “bagaimana saya menyampaikan ide ini”, atau “bagaimana dengan kasus ini”, tetapi sekarang itu menghilang, dan detail-detail seperti itu ditunda sampai setelah semuanya dibuat dengan rapi.
Tentu kita bisa memperbaiki proses dan meninjau cara memanfaatkan teknik baru ini dengan lebih baik, tetapi apakah ini lebih baik daripada sebelumnya? Saya tidak yakin.
Itu sedang ditinggalkan.
Sekarang orang backend juga mengerjakan frontend.
Itu salah pahamnya.
Apakah Anda memelototi assembly yang dihasilkan compiler? Tidak.
Lalu kenapa Anda melihat kode ini?
Kita hanya menaikkan lapisan abstraksi.
Saya juga sering memakai pendekatan yang sama
Bahkan sebelum AI pun saya melakukannya secara manual
Mula-mula duduk bersama pengguna hanya dengan pena dan kertas, lalu cepat membuat POC atau demo frontend, membiarkan pengguna mencobanya, lalu menyesuaikannya sampai berjalan sesuai yang diinginkan
Bagi saya, membuat demo frontend cepat dalam bentuk kode, bukan kualitas produksi, sering kali sudah lebih cepat daripada membuat interaksi yang presisi di Figma
Karena interaksinya bisa sepenuhnya berjalan, saya bisa menangkap jauh lebih banyak kasus tepi dari sisi pengalaman pengguna
Sekarang berkat Claude Code, membuat prototipe sekali pakai jadi lebih cepat, tetapi bedanya tidak terlalu besar
Karena 80% dari keseluruhan waktu dipakai untuk berdiskusi dengan pengguna dan memikirkan bagaimana seharusnya sesuatu bekerja, Claude kira-kira hanya memangkas separuh dari 20% sisanya dibanding saat saya membuatnya sendiri dengan cepat
Versi pertama memang lebih cepat, tetapi iterasinya lebih lambat ketika belum benar-benar memahaminya
Edwin, senang melihat tulisanmu terbit
Saya ingat kita pernah ikut hackathon bersama sekitar 2012/2013
Kemampuan untuk mencapai prototipe yang berfungsi dengan lebih cepat sangat memberdayakan, meskipun ada godaan untuk langsung merilis ide yang belum matang begitu saja
Kebutuhan desain dan pengalaman pengguna mendapat manfaat besar ketika kita bisa melampaui storyboard dan wireframe untuk benar-benar menyentuh dan mengalami alur yang nyata