[🤖] Desain hasilnya terus berubah: alasan saya membutuhkan DESIGN.md

✨ Ringkasan GPT-5.6 Sol

Hasil brosur selalu berbeda dan itu membawa saya kepada DESIGN.md. Namun, kebutuhan akan konsistensi desain sebenarnya sudah lama saya rasakan dan saya terapkan dengan cara sendiri di proyek pribadi lain. Ini adalah catatan tentang menghubungkan standar yang tersebar itu ke dalam format yang dapat terus dibaca oleh AI.

Desainnya berubah setiap kali saya membuat brosur

Setelah kembali dari libur panjang, saya melanjutkan pekerjaan membuat brosur di perusahaan tempat saya bekerja sekarang. Setelah sibuk mengelola koordinator dan worker sampai brosurnya sendiri tidak selesai tepat waktu, saya menyederhanakan cara kerja, tetapi desainnya masih mengganggu pikiran. Bahkan dalam PPT yang sama, suasana setiap halaman berubah-ubah, dan setiap versi baru seperti menghasilkan desain baru.

Proyek-proyek lain pun tidak jauh berbeda. Saya mencoba menciptakan konsistensi dengan meminta AI mencari referensi dan contoh desain yang bagus, atau membagikannya sendiri. Kadang saya hanya berharap undian gacha acaknya memberi hasil yang bagus. Yang kembali justru hasil kelas D tanpa konsistensi dan sangat berbau AI.

Saya tidak ingin menghasilkan satu layar yang sekadar tampak bagus setiap kali. Saya ingin warna, hierarki teks, jarak, dan rasa komponen yang sama berlanjut ke halaman dan versi berikutnya. Namun, brosur itu tidak memiliki standar tersebut. Setiap kali menerima referensi, AI kembali menebak suasananya dari awal.

Ini bukan pertama kalinya saya melihat masalah tersebut

Jika dipikir kembali, kebutuhan akan konsistensi desain bukan baru kali ini saya rasakan. Pada Juli 2025, saya sudah menulis catatan tentang cara membangun sistem desain untuk vibe coding. Saat itu pun saya memikirkan alur untuk mendesain dengan Figma AI, menyimpan layar dan kode sebagai referensi, merapikan tipografi serta palet warna, lalu membandingkannya dengan hasil nyata.

Di Tadak Bible, saya tidak berhenti pada pemikiran. Sejak Januari 2026, saya mulai mengumpulkan warna, tipografi, dan tema di satu tempat. Saya mendokumentasikan arah seperti biru pastel dan lavender, suasana tenang dan hangat, serta keterbacaan layar pengetikan Alkitab. Setelah itu saya membuat BibleColors, BibleTypography, serta token jarak, sudut, ikon, dan gerakan, lalu menerapkannya pada berbagai layar. Saya juga menambahkan pemeriksaan agar layar baru tidak kembali membuat warna dan ukuran huruf sembarangan.

Artinya, saya sebenarnya sudah tahu mengapa sistem desain diperlukan. Di dalam Tadak Bible, saya sudah cukup jauh mengikat warna, jenis huruf, dan komponen bersama produk melalui kode dan dokumentasi.

Masalahnya, pengalaman itu tidak berlanjut ke proyek dan hasil lain. Standar Tadak Bible tersebar di dokumen, kode Flutter, dan pemeriksaannya sendiri. Tidak ada format umum yang bisa langsung dibaca AI ketika memulai proyek web atau PPT baru untuk meneruskan rasa desain yang sama. Di setiap proyek, saya kembali mencari referensi, melempar contoh, dan menunggu hasil yang bagus.

Saya mencoba menghubungkan standar yang tersebar dengan DESIGN.md

Kemudian saya menemukan katalog ko/design.md yang merangkum sistem desain layanan Korea sebagai konteks LLM,¹ serta repositori DESIGN.md dari Google Labs Code.²

Dari nama dan contohnya, saya mendapat gambaran kasar tentang file tersebut. Sepertinya itu adalah tempat untuk mencatat warna, jenis huruf, jarak, komponen, dan suasana keseluruhan agar AI dapat merujuknya setiap kali membuat desain. Saya berpikir dapat memindahkan standar desain yang sudah dibuat di Tadak Bible ke bentuk yang bisa terus dibaca oleh Agent, lalu mengelola proyek lain dengan cara yang sama.

Masalahnya, di sini pun saya melewati detail dengan pemahaman kira-kira. Saya meminta AI mencari tahu apa itu DESIGN.md, mempelajari contohnya, dan membuat sesuatu yang serupa. Setelah itu saya berlalu begitu saja dengan anggapan bahwa riset dan penerapannya pasti sudah cukup. Saya tidak memeriksa sendiri ruang lingkup yang dijelaskan dokumentasi resmi, apakah file yang dibuat mematuhinya, atau apakah hasil nyata benar-benar menjadi konsisten secara visual.

Fakta bahwa AI membaca tautan dan membuat file yang tampak masuk akal tidak sama dengan memiliki standar desain yang saya inginkan. Tidak memeriksa perbedaan itu adalah kesalahan saya.

Saya hampir memasukkan seluruh perencanaan produk ke DESIGN.md

Tanpa benar-benar memeriksa ruang lingkup DESIGN.md, saya mencoba menyusun semua layar dan alur per pengguna, status, izin, serta pemulihan produk berikutnya di dalam DESIGN.md. Codex menerima perluasan itu apa adanya dan mulai membuat DESIGN.md per peran serta aturan terpisah.

Ada sesuatu yang terasa salah. UI-nya seperti tidak benar-benar ditangani, jadi saya kembali meminta agar contoh Google Labs Code yang paling saya tekankan diperiksa lebih dahulu.

Setelah membaca materi aslinya, batasnya menjadi jauh lebih jelas. DESIGN.md dari Google Labs Code adalah format yang terus menyampaikan identitas visual produk kepada Agent pemrograman. YAML dapat memuat token desain yang akurat, sedangkan isi Markdown menjelaskan alasan penggunaan warna, jenis huruf, dan bentuk tersebut, serta bagaimana keseluruhan desain seharusnya terlihat, terasa, dan berperilaku.³

Kata berperilaku di sini tidak berarti menyerap seluruh perencanaan produk. Peran pengguna, perjalanan, izin, pengecualian, pemulihan, struktur layar, dan verifikasi tetap perlu dibahas secara rinci dalam dokumentasi produk biasa. Detail per peran yang awalnya ingin saya buat bukanlah isi yang harus dibuang; tempatnya hanya di docs/, bukan di bawah nama DESIGN.md.

Mengikuti format berbeda dengan menyalin desain

Setelah memperbaiki batas tersebut, ada satu hal lagi yang perlu saya pastikan. Menjadikan Google Labs Code sebagai standar bukan berarti menyalin desain contoh dari repositorinya lalu menerapkannya ke semua proyek.

Yang diberikan Google adalah format DESIGN.md dan cara menafsirkannya, bukan isi desainnya. Warna, jenis huruf, dan suasana dalam contoh hanyalah identitas visual contoh tersebut. DESIGN.md untuk proyek nyata harus memuat standar visual yang berasal dari pengguna, lingkungan, merek, dan referensi yang saya pilih untuk produk itu. Katalog ko/design.md juga merupakan bahan untuk rujukan dan perbandingan; menyalin desain apa pun tidak otomatis menjadikannya identitas produk kami.

Karena itu, saya memperbaiki aturan bersama dan Skill perencanaan produk. DESIGN.md hanya dibuat ketika identitas visual benar-benar masuk dalam ruang lingkup, sedangkan peran, perjalanan, izin, pemulihan, dan desain layar terperinci tetap berada di dokumentasi produk biasa. Saya menghapus arah DESIGN.md per peran yang semula dibuat semaunya, dan templat akhir juga lolos pemeriksaan resmi Google.

Kali ini, saya menemukan DESIGN.md untuk mengurangi gacha desain, tetapi arti DESIGN.md sendiri malah saya serahkan kepada gacha AI. Jika saya memberikan tautan, berkata “cari tahu dan terapkan”, lalu percaya hanya karena sebuah file sudah muncul, AI akan mengisi semua bagian kosong yang tidak saya periksa dengan caranya sendiri.

Satu file DESIGN.md tidak otomatis menghasilkan desain yang bagus. Khusus untuk PPT, saya tetap perlu membuat master slide dan contoh tata letak yang nyata, lalu memeriksa apakah hasil render mengikuti standar tersebut. Namun, jika standar visual yang saya terima untuk setiap produk disimpan sebagai sumber kanonis di DESIGN.md, setidaknya AI tidak akan sesering itu mengundi ulang suasana dari layar kosong.

Saya sudah lama memahami perlunya konsistensi desain. Di Tadak Bible, saya bahkan sudah membangun sistem desain. Baru kali ini saya menemukan format yang dapat dibaca Agent untuk membawa pengalaman tersebut ke proyek dan hasil lain, lalu akhirnya menghubungkannya dengan nama DESIGN.md.

Referensi

1. ko/design.md, katalog sistem desain layanan Korea. Katalog ini menyediakan desain khas layanan Korea sebagai konteks LLM. ↩

2. Google Labs Code, DESIGN.md. Repositori ini memperkenalkan format identitas visual yang dapat terus dirujuk oleh Agent pemrograman. ↩

3. Google Labs Code, spesifikasi DESIGN.md. Spesifikasi ini mendefinisikan struktur, bagian standar, dan aturan pemeriksaan untuk token desain YAML serta alasan desain dalam Markdown. ↩