Master Brief · Action Plan · Design System
Sanad Mobile — Rider & Driver App
Satu dokumen yang menggabungkan analisis brief produk, rencana kerja desain, dan strategi design system Lamah UI. Ditulis agar bisa dibaca product manager, stakeholder, dan tim desain tanpa latar belakang teknis.
00 — Mulai di sini
Ringkasan untuk Stakeholder
Sanad adalah aplikasi ride-hailing di Libya. Aplikasinya sudah jalan — ada aplikasi Flutter, backend, sistem pembayaran, dan alur pemesanan yang berfungsi. Yang diminta bukan membangun dari nol, melainkan merancang ulang tampilan dan alurnya tanpa mengubah aturan bisnis yang sudah disetujui.
Ada dua aplikasi (untuk penumpang dan untuk sopir), ±31 area fitur, dan perkiraan 520–680 layar yang harus digambar. Semuanya harus dalam bahasa Arab dengan tata letak kanan-ke-kiri. Aplikasi ini dibangun di atas design system bernama Lamah UI yang sudah ada di kode — jadi tim desain tidak bebas memilih warna atau membuat komponen sendiri; mereka harus mengikuti sistem itu. Ada 15 data yang belum tersedia dan 9 keputusan bisnis yang belum diambil — keduanya memblokir pekerjaan.
23 area fitur
Wajib desain lengkap. Sudah ada atau dibutuhkan untuk rilis pertama.
7 area fitur
Dibangun belakangan, tapi desainnya tetap wajib selesai sekarang.
1 area fitur
Kartu virtual sopir. Cukup level konsep, tanpa mengunci provider.
Lima hal yang paling menentukan keberhasilan project ini
- Sopir menerima 100% tarif. Sanad tidak mengambil komisi — pendapatannya dari langganan sopir. Konsekuensinya untuk desain: tidak boleh ada satu pun angka atau kata di layar mana pun yang menyiratkan potongan.
- Bahasa Arab adalah produk utamanya, bukan terjemahan. Layout harus dibuat kanan-ke-kiri sejak awal. Membalik layout di akhir project akan merusak banyak hal — nomor telepon, plat kendaraan, nominal uang.
- “Selesai” punya definisi ketat. Sebuah alur baru dianggap selesai kalau semua kondisi tidak normal juga digambar: loading, kosong, offline, error, izin ditolak, waktu habis, dibatalkan, dan pemulihan setelah aplikasi ditutup. Ini yang membuat jumlah layar membengkak jadi ratusan.
- Design system-nya hidup di kode, bukan di Figma. Lamah UI adalah paket kode. Desainer tidak memilih warna — warna dihasilkan otomatis dari satu warna dasar. Apa pun yang tidak bisa dibuat dengan komponen Lamah harus dicatat sebagai permintaan perubahan sistem.
- Fitur berlabel “Future” bukan berarti nanti. Tujuh fitur ini implementasinya belakangan, tapi desainnya tetap harus lengkap di fase sekarang. Ini yang paling sering salah dijadwalkan.
1 · Warna dasar (seed color) Sanad belum ditentukan. Satu nilai warna ini menurunkan seluruh palet aplikasi. Tanpa ini, pembuatan token warna tidak bisa dimulai.
2 · Sembilan aturan bisnis untuk fitur Future belum disetujui — termasuk fare bidding, membership, penjadwalan, dan multi-stop. Desainnya bisa distruktur sambil menunggu, tapi tidak bisa difinalisasi.
01 — Kamus
Istilah Penting
Dokumen ini memakai sejumlah istilah teknis. Semuanya dijelaskan di sini agar tidak perlu menebak.
| Istilah | Artinya dalam bahasa sehari-hari |
|---|---|
| Rider / Driver | Penumpang dan sopir. Ada dua aplikasi terpisah untuk keduanya. |
| MVP | Versi pertama yang dirilis ke publik. “Current/MVP” = wajib ada di rilis pertama. |
| High-fidelity | Desain jadi yang detail dan siap dibangun — bukan sketsa kasar. |
| RTL | Right-to-Left. Tata letak kanan-ke-kiri, seperti tulisan Arab. Kebalikan dari layout Latin yang kiri-ke-kanan. |
| State | Kondisi sebuah layar. Satu layar bisa punya banyak kondisi: sedang memuat, kosong, error, offline, sukses. Masing-masing harus digambar. |
| Flow | Rangkaian layar untuk menyelesaikan satu tugas, misal “memesan perjalanan” dari awal sampai selesai. |
| Design system | Kumpulan komponen dan aturan visual yang dipakai berulang, supaya semua layar terlihat konsisten. |
| Lamah UI | Design system milik perusahaan yang dipakai Sanad. Bentuknya paket kode Flutter — bukan file Figma. |
| Token | Nilai desain yang diberi nama, misalnya “warna teks utama” atau “jarak 16px”. Dipakai agar perubahan bisa dilakukan di satu tempat. |
| Seed color | Satu warna brand utama. Dari warna ini, sistem menghasilkan seluruh palet secara otomatis. Sanad belum menentukan warnanya. |
| Komponen | Elemen UI yang bisa dipakai berulang — tombol, kartu, input, dialog. Lamah punya 37. |
| Gap | Kebutuhan Sanad yang belum ada komponennya di Lamah. Harus dicatat dan dibicarakan, bukan dibuat diam-diam. |
| Handoff | Serah terima dari desainer ke developer. Berisi ukuran, warna, perilaku — semua yang dibutuhkan untuk membangun. |
| Figma Variables | Fitur Figma untuk menyimpan token. Ganti satu nilai, semua layar ikut berubah. |
| Blnk | Sistem dompet digital yang dipakai Sanad. Sumber kebenaran untuk saldo — angka saldo tidak boleh dihitung sendiri oleh aplikasi. |
| MapLibre / Valhalla | Teknologi peta dan penunjuk arah yang dipakai Sanad. Bukan Google Maps — jadi tidak semua interaksi peta yang biasa kita lihat bisa dibuat. |
| Dirham / LYD | Uang disimpan sebagai bilangan bulat dirham. 1000 dirham = 1 Dinar Libya (LYD). |
02 — Fondasi
Model Bisnis & Aturan Kunci
Sanad tidak mengambil potongan dari tarif. Sopir menerima seluruh uang perjalanan. Sanad menghasilkan uang dengan menjual langganan bulanan ke sopir. Ini membedakan Sanad dari Grab atau Uber, dan punya konsekuensi besar untuk desain: tidak boleh ada apa pun di aplikasi yang membuat sopir mengira uangnya dipotong.
Pelanggaran atas aturan di bawah ini otomatis membatalkan desain, seberapa bagus pun tampilannya.
| Aturan | Artinya untuk desain |
|---|---|
| Sopir menerima 100% tarif | Dilarang menampilkan komisi, potongan platform, atau pembagian tarif di layar mana pun. |
| Pendapatan Sanad = langganan sopir | Langganan tidak boleh pernah digambarkan sebagai komisi atau potongan dari tarif. |
| Mayoritas penumpang bayar tunai | Tunai adalah jalur utama, bukan opsi sekunder. Tampilannya harus sama menonjol dengan dompet digital. |
| Pembayaran dompet = transfer dompet ke dompet | Tunai dan dompet harus terlihat sangat berbeda — jangan digabung dalam satu komponen yang ambigu. |
| Blnk adalah sumber kebenaran saldo | Saldo dompet tidak boleh dihitung dari daftar transaksi yang terlihat di layar. |
| Uang disimpan sebagai bilangan bulat dirham | 1000 = 1 LYD. Uji panjang angka pada tata letak kanan-ke-kiri. |
| Tarif dihitung oleh sistem | Penumpang tidak bisa mengubah tarif di versi pertama. Tarif perjalanan yang sudah selesai bersifat final. |
| Peta pakai MapLibre, rute pakai Valhalla | Dilarang memakai kontrol atau logo khas Google Maps / Mapbox. Semua interaksi peta harus bisa dibuat dengan MapLibre. |
| Persetujuan sopir ≠ langganan sopir | Dua kondisi terpisah. Sopir yang sudah disetujui tapi langganannya mati tidak menerima order — butuh tampilan khusus yang menjelaskan ini. |
| Uang tunai ≠ saldo dompet | Uang tunai yang dipegang sopir bukan saldo yang bisa dibelanjakan di Sanad. Jangan pernah dijumlahkan jadi satu angka. |
| Tidak ada pencairan otomatis | Jangan menyimpulkan adanya fitur pencairan otomatis dari proses pembayaran manual yang dilakukan admin. |
03 — Kerangka
Cara Fitur Dikelompokkan
Setiap fitur punya dua label yang berbeda dan sering tertukar: seberapa lengkap desainnya harus dibuat, dan kapan pembangunannya dijadwalkan. Sebuah fitur bisa dijadwalkan dibangun tahun depan tapi desainnya tetap wajib selesai bulan ini.
Seberapa lengkap desainnya
- High-fidelity required
- Seluruh alur, layar, kondisi, interaksi, dan komponen harus selesai di fase desain sekarang.
- Concept required
- Cukup pengalaman utama dan layar pokok. Detail menunggu keputusan bisnis atau regulasi.
Kapan dibangun
- Current / MVP
- Sudah ada, atau wajib untuk rilis pertama.
- Next
- Disetujui untuk dikerjakan tak lama setelah rilis pertama.
- Future
- Didesain sekarang, dibangun belakangan, satu per satu.
- Long-term
- Bergantung pada kemitraan, regulasi, atau keputusan bisnis di masa depan.
Fitur berlabel Future tetap menuntut desain lengkap sekarang. Kata “Future” menjelaskan kapan dibangun — bukan seberapa penting atau seberapa lengkap desainnya. Menunda mendesain fitur Future ke akhir project akan menciptakan lonjakan beban kerja yang tidak terkelola.
04 — Cakupan
Daftar Fitur Lengkap
Current / MVP Desain lengkap wajib
- Login penumpang & sopir
- Kode OTP & sidik jari / wajah
- Alur perjalanan penumpang
- Alur perjalanan sopir
- Peta, rute & navigasi
- Profil penumpang & sopir
- Notifikasi
- Riwayat & struk perjalanan
- Pembayaran tunai & dompet
- Dompet penumpang & sopir
- Pendaftaran & verifikasi dokumen sopir
- Langganan sopir
- Kode promo & voucher langganan
- Perjalanan khusus wanita
- Penilaian (rating)
- Tombol darurat & berbagi perjalanan
- Kontak darurat
- Tiket bantuan
- Syarat & Ketentuan
- Kebijakan Privasi
- Explore (jelajah tempat)
- Iklan
- Chat penumpang–sopir
- Perjalanan antar kota
Future Desain lengkap wajib sekarang
- Tawar-menawar tarif — penumpang mengajukan harga, sopir merespons
- Membership penumpang — paket berlangganan untuk penumpang
- Layanan pelajar — program khusus siswa/mahasiswa
- Preferensi layanan aksesibilitas — kebutuhan khusus penumpang
- Pemesanan terjadwal — booking untuk waktu yang akan datang
- Multi-tujuan — beberapa titik berhenti dalam satu perjalanan
- Libyan Voucher — disebut tanpa penjelasan; butuh klarifikasi
Aturan bisnis detail untuk semua fitur di atas membutuhkan persetujuan product owner sebelum desain final.
Long-term Konsep saja
Kartu virtual sopir — konsep untuk penemuan, kelayakan, aktivasi, detail kartu terlindungi, autentikasi, bekukan/aktifkan, transaksi, limit, bantuan, dan penutupan.
Konsep tidak boleh mengasumsikan bank, penyedia, jaringan kartu, model pendanaan, biaya, metode pencairan, atau persetujuan regulator. Harus terpisah dari uang tunai dan tidak menjanjikan fungsi yang belum disetujui.
05 — Prinsip
Prinsip Desain
Bahasa & arah
- Arab adalah bahasa utama; Arab & Inggris didukung sejak awal.
- Komunikasi tim, catatan, dan dokumentasi internal boleh berbahasa Inggris.
- Aplikasi didesain kanan-ke-kiri dengan teks Arab asli.
Hierarki & aksi
- Informasi penting harus jelas mendahului elemen dekoratif.
- Setiap tahap perjalanan menyajikan satu aksi utama yang jelas.
- Kedua aplikasi berbagi satu identitas visual, dengan navigasi berbeda per peran.
Realitas lapangan
Pembayaran tunai, sinyal buruk, dan lokasi GPS yang meleset adalah kondisi normal di Libya — bukan kasus langka. Desain harus tetap berfungsi dalam kondisi ini.
Kelengkapan & aksesibilitas
- Aksesibilitas wajib di seluruh rilis pertama.
- Kondisi loading, kosong, offline, error, izin, waktu habis, sukses, dan pemulihan harus disertakan.
06 — Penumpang
Rider App — Detail Kebutuhan
Tujuan aplikasi: membantu seseorang memesan, memahami, mengikuti, membayar, dan menilai perjalanan dengan ketidakpastian seminimal mungkin — dan tetap jelas ketika sinyal, GPS, ketersediaan sopir, atau saldo terbatas.
Current / MVP
Explore & Iklan
- Explore — cari dan jelajahi tempat pilihan per kategori. Detail tempat: gambar, deskripsi, lokasi, jarak, jam buka, dan tombol Get a Ride yang langsung menjadikannya tujuan.
- Iklan — iklan yang dikelola Sanad. Bisa berisi gambar, judul, deskripsi, lokasi, masa berlaku, tautan eksternal, dan Get a Ride bila terhubung ke lokasi.
Chat dalam aplikasi
- Penumpang dan sopir bisa bertukar pesan pada tahap perjalanan yang relevan. Kondisi wajib: belum dibaca, sedang terkirim, terkirim, gagal, coba lagi, tidak tersedia.
Akses & akun
- Nomor telepon Libya, verifikasi OTP, kirim ulang, OTP salah/kedaluwarsa, dan pemulihan sesi
- Perlindungan sidik jari/wajah opsional, dengan jalur cadangan bila perangkat gagal
- Ubah profil, keluar, dan hapus akun
- Syarat & Ketentuan dan Kebijakan Privasi
Beranda, peta & pemesanan
- Izin lokasi, lokasi saat ini, pencarian titik jemput/tujuan, konfirmasi pin, pratinjau rute
- Rumah, Kantor, tempat tersimpan, dan lokasi terkini — bisa ditambah, diubah, dihapus
- Kondisi: GPS lemah, izin ditolak, di luar area layanan, rute tidak ditemukan, offline, memuat, coba lagi
- Pilihan kelas kendaraan, estimasi jarak & waktu, tarif dari sistem, dan opsi yang tidak tersedia
- Opsi khusus wanita bila penumpang memenuhi syarat dan layanan tersedia
- Penawaran tarif kedaluwarsa, konfirmasi, gagal memesan, dan coba lagi
Tarif di versi pertama tidak bisa diubah penumpang. Pengalaman peta dan rute harus tetap bisa dibuat dengan MapLibre dan Valhalla.
Pencarian sopir, penjemputan & perjalanan berjalan
- Mencari, memperluas pencarian, sopir ditemukan, tidak ada sopir, kedaluwarsa, dibatalkan, dan pemulihan setelah koneksi kembali atau aplikasi di-restart
- Nama sopir, foto, rating, detail kendaraan, plat nomor, perkiraan tiba, dan tombol kontak
- Kondisi: sopir menuju lokasi, sudah tiba, perjalanan dimulai, sedang berjalan, selesai, dibatalkan
- Rute & lokasi langsung, status perjalanan yang jelas, tombol darurat, kontak darurat, dan berbagi perjalanan
Tombol darurat (SOS) adalah aksi mendesak dan tidak boleh digabung ke menu bantuan umum. Harus punya jalur akses sendiri.
Pembayaran & dompet
- Pembayaran tunai langsung ke sopir
- Pembayaran dompet lewat kode QR atau tautan khusus perjalanan yang dibuat sopir
- Pratinjau pembayaran, jumlah yang tepat, saldo tersedia, konfirmasi, memproses, sukses, gagal, saldo kurang, kode tidak valid/kedaluwarsa, dan sudah dibayar
- Saldo dompet, isi saldo, transaksi, detail transaksi, dan proses checkout yang fleksibel terhadap penyedia
Blnk adalah otoritas untuk saldo. Nilai dompet tidak boleh dihitung dari transaksi atau riwayat yang terlihat di layar.
Perjalanan antar kota & layanan aksesibilitas
- Antar kota — alur pemesanan khusus yang menampilkan kota asal, kota tujuan, titik jemput, rute, jarak, durasi, tarif, dan ketersediaan.
- Aksesibilitas — penumpang bisa meminta kendaraan ramah kursi roda atau layanan aksesibilitas lain, dan mengelola preferensinya.
Penyelesaian & layanan akun
- Penilaian sopir dan pemulihan bila pengiriman gagal
- Riwayat perjalanan, kondisi kosong, detail, rute, ringkasan pembayaran, struk, berbagi, dan bantuan terkait perjalanan
- Notifikasi dengan status dibaca/belum dibaca
- Tempat tersimpan, data pribadi, kontak darurat, dan preferensi biometrik
- Daftar tiket bantuan, pembuatan, percakapan, status, balasan, dan kondisi error
Future — desain lengkap wajib sekarang
Tawar-menawar tarif
Pilihan antara tarif tetap dan menawar, tarif acuan, tawaran penumpang, rentang yang diizinkan, konfirmasi, mencari, respons sopir, kedaluwarsa, pembatalan, harga terkunci, dan pembayaran. Tarif yang disepakati tetap terlihat sepanjang perjalanan.
Aturan rentang, tawaran balik, kedaluwarsa, pembatalan, dan kembali ke tarif tetap butuh persetujuan. Menawar tidak boleh memunculkan komisi atau pembagian tarif.
Membership penumpang
Penemuan, perbandingan paket, manfaat, kelayakan, pembelian, keanggotaan aktif, perpanjangan, gagal bayar, kedaluwarsa, pembatalan, dan riwayat. Harga dan manfaat harus ditandai jelas sebagai keputusan produk sampai disetujui. Terpisah dari langganan sopir.
Layanan pelajar & aksesibilitas
Penemuan layanan, pengumpulan kelayakan, penjelasan privasi, pemilihan saat memesan, umpan balik pencocokan, kondisi tidak tersedia, dan pengelolaan profil. Aksesibilitas aplikasi itu sendiri tetap wajib di rilis pertama dan terpisah dari layanan ini.
Pemesanan terjadwal
Pemilihan tanggal/waktu, titik jemput & tujuan, tampilan tarif, konfirmasi, detail perjalanan mendatang, pengingat, aturan ubah/batal, status penugasan sopir, penanganan bila tidak ada sopir, dan transisi ke perjalanan berjalan.
Multi-tujuan
Menambah, menghapus, dan mengurutkan titik berhenti sebelum berangkat; rute terbaru, estimasi tarif & durasi, batas jumlah titik, konfirmasi, aturan ubah/batal, dan transisi ke perjalanan berjalan. Sopir harus bisa melihat rute lengkap dan titik saat ini.
07 — Sopir
Driver App — Detail Kebutuhan
Tujuan aplikasi: membantu sopir menyelesaikan pendaftaran, menjadi siap menerima order, tetap berlangganan, menerima tawaran, menyelesaikan perjalanan dengan aman, mengumpulkan 100% tarif, dan memahami dompet serta pendapatannya.
Navigasi boleh dirombak, tapi akses cepat ke empat hal ini wajib dipertahankan: status online/offline, aksi perjalanan yang sedang berjalan, pendapatan, dan status langganan.
Current / MVP
Akses, pendaftaran & akun
- Nomor telepon Libya, OTP, pemulihan sesi, biometrik, keluar, dan hapus akun
- Formulir pribadi, kota, detail kendaraan, katalog mobil, foto kendaraan, dan dokumen wajib
- Kondisi dokumen: mengunggah, belum ada, menunggu, disetujui, ditolak, diganti, kedaluwarsa, perlu perbaikan, dikirim ulang
- Kondisi lamaran: progres, sedang ditinjau, disetujui, ditolak, ditangguhkan
Pendaftaran harus aman terhadap restart. Menutup atau membuka ulang aplikasi tidak boleh membuat langkah wajib terlewat.
Kesiapan & ketersediaan
- Persetujuan dan langganan adalah dua kondisi terpisah.
- Kondisi kesiapan: dokumen lengkap, langganan aktif, izin lokasi, koneksi internet, dan status online/offline.
- Setiap kondisi yang menghalangi sopir bekerja wajib menjelaskan alasannya dan memberi langkah selanjutnya.
Langganan & voucher promo
- Langganan saat ini, mulai/berakhir, status perpanjangan, dan paket yang tersedia
- Perbandingan paket dengan tampilan harian, mingguan, bulanan, atau per perjalanan
- Konfirmasi pembelian, saldo dompet, penanganan saldo kurang, memproses, aktivasi, gagal, peringatan perpanjangan, dan kedaluwarsa
- Kolom voucher opsional dengan kondisi valid, tidak valid, kedaluwarsa, kuota habis, dan harga akhir setelah diskon
Voucher promo sudah bagian dari rilis pertama, bukan fitur masa depan. Langganan tidak boleh pernah digambarkan sebagai komisi atau potongan tarif.
Tawaran order, perjalanan & navigasi
- Kondisi menunggu order, dan tawaran berbatas waktu berisi titik jemput, tujuan, jarak/ETA, tarif, detail layanan — dengan terima, tolak, waktu habis, sudah diambil sopir lain, dan koneksi terputus
- Navigasi ke titik jemput, sudah tiba, penumpang naik, mulai perjalanan, navigasi ke tujuan, selesai, dan pembatalan
- Ringkasan rute, panduan belok, penghitungan ulang rute, GPS hilang, pemulihan setelah aplikasi ditutup, konfirmasi untuk aksi tak sengaja, dan sinkronisasi tertunda
- Chat dengan penumpang pada tahap perjalanan yang relevan
Penagihan tarif
- Tunai — sopir mengonfirmasi uang sudah diterima
- Dompet — sopir membuat kode QR atau tautan khusus perjalanan
- Hitung mundur QR, kedaluwarsa, menunggu, dibayar, gagal, buat ulang bila diizinkan, sudah dibayar, dan penanganan perjalanan lama yang belum dibayar
Tarif perjalanan yang sudah selesai bersifat final dan tidak bisa diubah saat penagihan.
Dompet, pendapatan & layanan akun
- Saldo dompet Blnk, transaksi, detail transaksi, isi saldo, biaya/kredit langganan, dan pembayaran perjalanan lewat dompet
- Pendapatan tunai ditampilkan terpisah dari saldo dompet
- Riwayat perjalanan, filter, detail, rute, ringkasan pembayaran, struk, dan penilaian penumpang
- Tombol darurat, berbagi perjalanan, kontak darurat, notifikasi, profil sopir & kendaraan, status dokumen, tiket bantuan, dan preferensi biometrik
Uang tunai yang dikumpulkan dari penumpang bukan saldo Sanad yang bisa dibelanjakan, dan tidak boleh digabung dengannya. Tidak boleh ada potongan komisi yang ditampilkan.
Antar kota & perjalanan aksesibilitas
- Antar kota — sopir menerima tawaran antar kota yang teridentifikasi jelas: kota, titik jemput, tujuan, rute, jarak, durasi, tarif, dan aksi yang diperlukan.
- Aksesibilitas — sopir hanya melihat kebutuhan aksesibilitas yang perlu saja. Kelayakan sopir dan persyaratan layanan harus jelas.
Future — desain lengkap wajib sekarang
- Sisi sopir untuk tawar-menawar — tawaran penumpang, ringkasan perjalanan, sisa waktu, terima, tolak, kedaluwarsa, sudah diterima sopir lain, pemulihan koneksi, dan konfirmasi harga. Bila tawaran balik disetujui: kolom masukan, batas, respons, dan kedaluwarsa. Sopir tetap menerima 100% harga yang disepakati.
- Perjalanan pelajar & aksesibilitas — bagaimana hanya kebutuhan yang perlu dan aman secara privasi yang muncul di tawaran, penerimaan, penjemputan, dan perjalanan.
- Perjalanan terjadwal — tawaran/penugasan mendatang, detail, terima/tolak, pengingat, syarat persiapan & online, pembatalan oleh penumpang atau sistem, penanganan penumpang tidak muncul, dan transisi ke penjemputan normal.
- Perjalanan multi-tujuan — tampilan di tawaran, navigasi antar titik, penyelesaian titik, sisa rute, pembaruan ke penumpang, penanganan pembatalan, dan transisi ke tujuan akhir.
- Libyan Voucher — disebut tanpa penjelasan; butuh klarifikasi cakupan
Long-term — konsep saja
Kartu virtual sopir: konsep untuk penemuan, kelayakan, aktivasi, detail kartu terlindungi, autentikasi, bekukan/aktifkan, transaksi, limit, bantuan, kondisi tidak tersedia, dan penutupan.
Tidak boleh mengasumsikan bank, penyedia, jaringan kartu, model pendanaan, biaya, metode pencairan, atau persetujuan regulator. Harus terpisah dari uang tunai.
08 — Serah terima
Standar Serah Terima Desain
Daftar informasi yang wajib ada di file desain supaya developer bisa membangun aplikasi tanpa menebak apa pun. Ini juga berfungsi sebagai daftar periksa penerimaan pekerjaan desain — kalau salah satu poin belum ada, desain belum bisa dinyatakan selesai.
1 · Token & ukuran
- Pakai token dari Lamah UI
- Jangan pakai nilai warna langsung berulang di dalam layar
- Warna harus mendukung pergantian tema dan brand
- Jarak, ukuran, radius, dan dimensi komponen didefinisikan jelas
- Tiap gaya teks didokumentasikan: font, ukuran, ketebalan, tinggi baris, perataan
- Token atau komponen yang belum ada ditandai sebagai Lamah UI gap
2 · Ikon
- Semua ikon dalam satu halaman Figma yang rapi
- Hanya ikon yang benar-benar dipakai
- Sertakan nama, ukuran, varian, dan format ekspor
- Ikon yang sama untuk aksi yang sama
3 · Elemen interaktif
- Bedakan jelas mana yang bisa diklik dan mana yang tidak
- Beri catatan aksi untuk setiap tombol, ikon, kartu, kolom, tautan, dan gestur
- Jelaskan hasil atau tujuan tiap aksi
- Tampilkan kondisi normal, ditekan, terpilih, nonaktif, memuat, sukses, error
- Jelaskan perilaku kembali, tutup, konfirmasi, dan aksi yang menghapus data
4 · Perilaku scroll
- Arah scroll dan area yang bisa di-scroll
- Elemen yang tetap diam
- Header atau kontrol yang menempel
- Tombol bawah dan area aman layar
- Perilaku keyboard saat mengetik
- Gestur peta dan panel bawah bila relevan
5 · Konsistensi & kondisi wajib
- Layar sejenis memakai tata letak, komponen, istilah, dan pola yang sama
- Gunakan ulang komponen, jangan buat variasi kecil tanpa alasan
- Sertakan seluruh kondisi wajib
- Penamaan layar:
Aplikasi / Fitur / Kondisi
6 · Tinjauan dampak perubahan
- Setiap ada perubahan desain, tinjau semua layar terkait
- Semua layar dalam satu fitur di-update bersamaan
- Jaga konsistensi komponen saat mengubah bagian mana pun
7 · Kelengkapan alur
- Rancang perjalanan pengguna lengkap termasuk langkah antara
- Setiap aksi punya alur lengkap: pilih, unggah, ubah, hapus
- Jangan tinggalkan alur setengah jadi yang memaksa developer berasumsi
8 · Arab & RTL
- Layar final harus benar-benar kanan-ke-kiri
- Inggris hanya untuk kolaborasi dan catatan
- Teks final memakai bahasa Arab asli yang disetujui Sanad
- Gunakan katalog konten Arab–Inggris yang sudah ada
- Uji teks panjang dan campuran arah: nomor telepon, OTP, plat, nominal, kode voucher
Ketika ukuran, tipografi, token, ikon, interaksi, perilaku scroll, kondisi wajib, dan perilaku Arab RTL sudah terdokumentasi jelas dan sudah ditinjau bersama tim produk serta tim mobile.
09 — Volume
Perkiraan Jumlah Layar
Angka di bawah menghitung layar dan seluruh variasi kondisinya. Satu layar “Dompet” bisa menghasilkan 6–8 gambar karena harus ada versi memuat, kosong, error, saldo kurang, dan seterusnya. Ini perkiraan untuk perencanaan kapasitas, bukan angka kontrak.
| Aplikasi | Tahap | Perkiraan layar | Area terbesar |
|---|---|---|---|
| Rider | MVP | 196–256 | Beranda & peta, perjalanan berjalan, pembayaran |
| Future | 66–88 | Tawar-menawar, membership, terjadwal | |
| Total | 262–344 | ||
| Driver | MVP | 202–262 | Pendaftaran & dokumen, langganan, navigasi |
| Future + Long | 58–76 | Tawar-menawar, terjadwal, kartu virtual | |
| Total | 260–338 | ||
| TOTAL GABUNGAN | 522–682 | Belum termasuk varian tema terang/gelap | |
Lima area dengan beban terbesar
| Area | Est. | Kenapa besar |
|---|---|---|
| Pendaftaran & dokumen sopir | 30–40 | 9 kondisi dokumen × beberapa jenis dokumen, plus 5 kondisi lamaran, plus aman terhadap restart |
| Beranda, peta & tempat tersimpan (rider) | 22–28 | 8 kondisi lokasi berbeda plus pengelolaan tempat tersimpan |
| Perjalanan berjalan (rider) | 24–30 | 6 kondisi pencarian sopir + 6 kondisi perjalanan + pemulihan |
| Navigasi & perjalanan (driver) | 22–28 | Alur penuh plus GPS hilang, hitung ulang rute, pemulihan, sinkronisasi tertunda |
| Langganan & voucher (driver) | 20–26 | 9 kondisi pembelian + 5 kondisi voucher |
Volume sebesar ini tidak bisa diselesaikan dengan mendesain layar satu per satu. Ini alasan utama kenapa fase pertama harus dihabiskan untuk membangun sistem komponen dan template kondisi — bukan langsung menggambar layar.
10 — Eksekusi
Action Plan — 6 Fase
Durasi adalah estimasi untuk satu product designer, dan perlu disesuaikan dengan ukuran tim serta kecepatan pengambilan keputusan dari pihak Sanad.
Fase 0 Discovery & Penyelarasan ≈ 1–2 minggu
Tujuan: menghilangkan semua asumsi sebelum satu pixel pun digambar.
- Audit aplikasi yang berjalan sekarang — rekam setiap alur sebagai referensi fungsional.
- Audit Lamah UI: token dan komponen apa yang tersedia, apa yang kurang.
- Minta dan pelajari katalog konten Arab–Inggris yang sudah ada.
- Kumpulkan semua pertanyaan yang butuh keputusan dan kirim sebagai satu batch.
- Sepakati konvensi penamaan layar dan struktur file Figma.
Hasil: Laporan audit · Daftar kekurangan Lamah v1 · Daftar pertanyaan terbuka · Struktur file Figma
Fase 1 Fondasi — Token, Komponen & RTL ≈ 2–3 minggu
Tujuan: membangun sistem dulu, karena 500+ layar tidak bisa dikerjakan tanpa fondasi.
- Siapkan token Lamah di Figma, termasuk dukungan tema terang & gelap.
- Definisikan skala jarak, ukuran, radius, dan dimensi komponen.
- Dokumentasikan seluruh gaya teks Arab & Inggris.
- Bangun pustaka ikon dalam satu halaman.
- Bangun komponen inti dengan seluruh kondisinya.
- Bangun pustaka template kondisi — memuat, kosong, offline, izin, error, sukses. Ini pengungkit terbesar di project ini.
- Uji RTL sejak sekarang dengan teks Arab asli.
- Siapkan format tampilan uang dari dirham ke LYD.
Hasil: Pustaka token · Pustaka teks & ikon · Pustaka komponen inti · Template kondisi · Halaman uji RTL
Fase 2 Pemetaan Alur & Daftar Layar ≈ 1–2 minggu
- Petakan seluruh perjalanan pengguna kedua aplikasi, termasuk langkah antara, pembatalan, dan error.
- Untuk tiap alur, daftar kondisi wajibnya.
- Buat daftar layar final dengan penamaan yang konsisten.
- Tandai layar yang menunggu keputusan sebagai terblokir.
- Tinjau daftar bersama tim produk dan tim mobile.
Hasil: Diagram alur kedua aplikasi · Daftar layar final · Peta ketergantungan & blocker
Fase 3 Produksi MVP ≈ 8–12 minggu
Urutan disusun berdasarkan risiko: yang paling banyak aturan bisnisnya dikerjakan lebih dulu, supaya salah paham ketahuan di awal.
- Pendaftaran & verifikasi dokumen sopir — paling banyak kondisi, penentu apakah sopir bisa menerima order
- Kesiapan, langganan & voucher sopir — inti model bisnis
- Pembayaran & dompet kedua aplikasi
- Alur perjalanan kedua aplikasi
- Peta, rute & navigasi
- Login, OTP & biometrik
- Keselamatan — tombol darurat, berbagi perjalanan, kontak darurat
- Chat kedua sisi
- Antar kota kedua sisi
- Layanan aksesibilitas kedua sisi
- Explore & Iklan (penumpang)
- Riwayat, struk, penilaian, notifikasi, profil, bantuan, S&K, privasi
Hasil: Seluruh alur MVP dengan kondisi lengkap, beranotasi, dalam Arab RTL
Fase 4 Produksi Future & Konsep ≈ 4–6 minggu
- Tawar-menawar tarif — kedua sisi, dengan aturan yang sudah disetujui
- Membership penumpang — tandai harga & manfaat sebagai belum final
- Layanan pelajar & aksesibilitas — kedua sisi
- Pemesanan terjadwal — kedua sisi
- Multi-tujuan — kedua sisi
- Klarifikasi lalu kerjakan Libyan Voucher
- Kartu virtual sopir — konsep saja
Hasil: Alur Future lengkap · Konsep kartu virtual · Catatan asumsi yang ditandai jelas
Fase 5 Handoff, Review & Persetujuan ≈ 2–3 minggu, paralel
- Susun dokumen serah terima sesuai 8 poin di bagian 08 untuk setiap alur.
- Jalankan tinjauan dampak: pastikan semua layar dalam satu fitur konsisten.
- Audit aksesibilitas: kontras, skala teks, ukuran area sentuh, tema terang/gelap.
- Verifikasi tidak ada nilai warna yang ditulis manual.
- Tinjau bersama tim produk & mobile, lalu tandai alur sebagai siap dibangun.
- Serahkan daftar kekurangan Lamah final untuk ditindaklanjuti.
Hasil: Dokumen serah terima per alur · Audit aksesibilitas · Daftar kekurangan final · Daftar alur bersetujuan
11 — Persiapan
Yang Harus Disiapkan
A · Aset & akses yang diminta ke Sanad
- Akses pustaka Lamah UI — token, komponen, dokumentasi
- Definisi warna dasar (seed) dan aturan brand
- Katalog konten Arab–Inggris yang sudah ada
- Aplikasi yang berjalan + akun uji coba
- Aset brand: logo, palet, font Arab & Latin berlisensi
- Daftar dokumen wajib sopir + aturan verifikasinya
- Daftar paket langganan & konfigurasinya
- Aturan kelayakan perjalanan khusus wanita
- Katalog kelas kendaraan & daftar mobil
- Daftar kota yang didukung untuk antar kota
- Contoh data transaksi Blnk
- Kontak PIC: product owner, backend, mobile lead
B · Setup kerja sebelum mendesain
- Struktur file Figma disepakati
- Konvensi penamaan layar disepakati tertulis
- Font Arab final terpasang & diuji
- RTL sebagai bawaan kanvas, bukan dibalik di akhir
- Komponen format uang dirham → LYD
- Template kondisi yang bisa dipakai ulang
- Sistem anotasi untuk aksi dan perilaku scroll
- Pelacak kekurangan Lamah yang hidup sepanjang project
- Daftar pertanyaan terbuka dengan status per item
C · Pengetahuan teknis yang perlu dikuasai desainer
- Kemampuan & batasan MapLibre
- Karakteristik penunjuk arah Valhalla
- Model dompet Blnk
- Kemampuan RTL di Flutter
- Pola QR / tautan untuk pembayaran
- Perilaku biometrik di iOS & Android
- Standar aksesibilitas: kontras, skala teks, area sentuh
D · Disiplin harian
- Tidak ada warna yang ditulis manual
- Tidak ada alur setengah jadi
- Satu aksi utama jelas per tahap perjalanan
- Tunai dan dompet selalu terlihat berbeda
- Uang tunai tidak pernah dijumlahkan dengan saldo
- Tidak ada apa pun yang menyiratkan komisi
- Tombol darurat punya jalur sendiri
- Setiap kondisi yang menghalangi menjelaskan alasan + langkah berikutnya
- Setiap perubahan memicu tinjauan ke seluruh layar terkait
- Usulan perubahan perilaku selalu diajukan untuk disetujui dulu
12 — Blocker
Menunggu Keputusan Product Owner
Dokumen brief secara eksplisit menyatakan sembilan hal berikut belum final. Ajukan sebagai satu batch di Fase 0 — semakin cepat dijawab, semakin sedikit pekerjaan yang harus diulang.
| Fitur | Keputusan yang ditunggu |
|---|---|
| Tawar-menawar tarif | Rentang harga yang diizinkan, apakah boleh tawaran balik, aturan kedaluwarsa dan pembatalan, dan mekanisme kembali ke tarif tetap. |
| Membership penumpang | Harga dan daftar manfaat. Sampai disetujui, harus ditandai jelas sebagai keputusan produk. |
| Layanan pelajar & aksesibilitas | Bukti kelayakan, harga, persyaratan sopir, dan ketersediaan layanan. |
| Pemesanan terjadwal | Berapa lama sebelumnya bisa dipesan, harga, cara penugasan sopir, aturan pembatalan dan pengembalian dana. |
| Multi-tujuan | Maksimum jumlah titik, cara hitung tarif, apakah bisa diubah setelah berangkat, dan ketersediaan. |
| Perjalanan terjadwal (sopir) | Waktu penugasan, kelayakan sopir, aturan pembatalan, dan kompensasi. |
| Libyan Voucher | Disebut di daftar fitur sopir tanpa satu baris pun penjelasan. Butuh definisi cakupan penuh. |
| Kartu virtual sopir | Semuanya bergantung kemitraan dan regulasi. Desain harus tetap netral terhadap penyedia. |
| Perubahan perilaku produk apa pun | Setiap usulan perubahan harus didiskusikan dan disetujui sebelum masuk desain final. |
13 — Risiko
Risiko Utama
| Risiko | Dampak | Cara mengelolanya |
|---|---|---|
| Ledakan jumlah kondisi | 500+ layar. Mendesain satu per satu akan gagal di tengah jalan. | Bangun pustaka template kondisi di Fase 1. Jadikan setiap kondisi varian komponen, bukan layar baru. |
| RTL dikerjakan belakangan | Membalik layout di akhir merusak tata letak, ikon berarah, dan konten campuran seperti plat nomor dan OTP. | Desain RTL sebagai bawaan sejak layar pertama. Uji teks panjang di Fase 1. |
| Fitur Future ditunda desainnya | Desainnya tetap wajib sekarang. Menunda menciptakan lonjakan beban di akhir project. | Jadwalkan Fase 4 secara eksplisit dan lindungi waktunya. Kejar persetujuan sejak Fase 0. |
| Keputusan bisnis lambat | Lima fitur besar tidak bisa difinalisasi. | Kirim semua pertanyaan sebagai satu batch di awal. Kerjakan struktur alurnya dengan asumsi yang ditandai jelas sambil menunggu. |
| Lamah UI tidak lengkap | Komponen yang kurang memaksa improvisasi dan menghasilkan sistem yang tidak konsisten. | Audit lebih awal, jaga daftar kekurangan tetap hidup, dan eskalasi berkala — jangan diam-diam membuat komponen baru. |
| Batasan peta baru ketahuan belakangan | Interaksi peta yang ternyata tidak bisa dibuat harus didesain ulang setelah terlanjur jadi. | Validasi setiap konsep interaksi peta bersama tim mobile sebelum masuk desain detail. |
| Tunai dan dompet tercampur | Melanggar aturan finansial inti; berpotensi menyesatkan sopir soal uang yang bisa dibelanjakan. | Perlakukan sebagai dua sistem visual berbeda sejak level komponen, bukan sekadar label berbeda. |
| Perubahan navigasi menghilangkan akses cepat sopir | Brief mewajibkan akses langsung ke status online, aksi perjalanan, pendapatan, dan langganan tetap terjaga. | Jadikan empat akses ini sebagai batasan tetap pada setiap eksplorasi navigasi sopir. |
| Duplikasi layar menimbulkan inkonsistensi | Menghasilkan dua implementasi berbeda untuk fungsi yang sama. | Jalankan tinjauan dampak setiap ada perubahan; update seluruh layar dalam satu fitur bersamaan. |
14 — Konteks
Apa Itu Lamah UI
Lamah UI adalah kotak perkakas visual milik perusahaan: kumpulan tombol, kolom isian, kartu, dialog, dan aturan warna yang sudah jadi dan dipakai bersama di semua produk. Bedanya dengan design system pada umumnya, Lamah tersimpan di kode program, bukan di Figma. Artinya file Figma bukan tempat sistem ini didefinisikan — file Figma hanya cerminan dari sistem yang sudah ada.
Secara angka: paket kode Flutter berisi 37+ komponen, 220+ token dalam 6 lapisan, dan mesin tema yang menghasilkan seluruh palet warna dari satu warna dasar menggunakan ilmu warna HCT. Filosofinya: satu warna dasar mendandani seluruh aplikasi, satu benang emas menyatukan semua produk.
Setiap kali desainer menggambar sesuatu yang tidak bisa dibuat dengan komponen dan token Lamah, mereka sedang menghasilkan pekerjaan yang tidak bisa diimplementasi. Itulah definisi teknis dari “Lamah UI gap” yang diminta brief Sanad. Gap bukan hal buruk — tapi harus dicatat dan dibicarakan, bukan dibuat diam-diam.
Empat karakter sistem yang mengubah cara kerja
1 · Warna tidak dipilih, warna dihasilkan
Desainer tidak memilih warna. Mereka memilih satu warna dasar, lalu sistem menurunkan seluruh palet secara otomatis. Konsekuensinya: dilarang mengambil warna dengan eyedropper dari mana pun.
2 · Komponen tidak punya pengaturan warna
Dokumentasi Lamah menyatakan eksplisit: “tidak ada parameter warna. Kalau kamu butuh warna kustom, itu tanda sistem butuh varian baru.” Jadi tombol berwarna di luar 5 varian yang ada bukan pilihan desain — itu permintaan perubahan sistem.
3 · Mode gelap bukan sekadar dibalik
Latar gelap memakai rona warna dasar dengan saturasi sangat rendah, bukan abu-abu datar. Dan yang lebih penting: warna emas menggantikan warna dasar sebagai warna aksi utama di mode gelap, karena warna dasar sering terlalu gelap di atas latar gelap.
4 · Emas terkunci, tidak pernah diubah
#C2AC7B konstan di semua produk. Tidak boleh digelapkan, diterangkan, atau dicampur. Ia adalah benang brand. Untuk Sanad, ini berarti ada satu warna aksen dengan makna khusus yang harus dipakai dengan hemat.
Dokumentasi Lamah tidak menyebut adanya pustaka Figma resmi. Kalau ada — pakai, jangan bangun ulang. Kalau tidak ada — tim desain yang akan membangun cerminannya, dan itu pekerjaan 3 minggu sebelum satu layar pun digambar. Perbedaan jawaban ini bernilai berminggu-minggu kerja.
15 — Prinsip
Enam Aturan Kontrak Figma ↔ Kode
Enam aturan ini adalah inti strategi. Kalau tim hanya mengingat satu bagian dari dokumen ini, ingat bagian ini.
Aturan 01 Nama di Figma = nama di kode
Komponen Figma dinamai persis seperti komponen di program. Developer tidak boleh perlu menerjemahkan apa pun saat membaca desain.
Aturan 02 Layar hanya boleh memakai token bermakna
Ada tiga lapis token: nilai mentah, token bermakna, dan penggunaan di komponen. Layar hanya boleh mengikat ke lapis token bermakna. Ini menegakkan langsung larangan brief Sanad: jangan memakai nilai warna langsung di dalam layar.
Aturan 03 Tidak ada nilai yang diketik manual
Setiap warna, sudut, jarak, dan padding harus terikat ke token. Kalau nilai yang dibutuhkan tidak ada — itu bukan alasan mengetik angka, itu temuan kekurangan yang harus dicatat.
Aturan 04 Butuh warna baru = butuh varian baru = kekurangan
Ini pernyataan resmi dokumentasi Lamah, bukan tafsiran. Setiap kali desainer tergoda memberi warna kustom, hentikan dan tulis satu baris di daftar kekurangan.
Aturan 05 Melepas komponen adalah insiden, bukan teknik
Setiap komponen yang dilepas dari pustaka harus punya alasan tertulis. Dengan volume 500+ layar, pelepasan yang tidak terkontrol akan menghasilkan sistem yang tidak terkelola dalam hitungan minggu.
Aturan 06 Daftar kekurangan adalah hasil kerja, bukan catatan pribadi
Brief Sanad secara eksplisit meminta kekurangan Lamah diidentifikasi. Jadikan satu halaman Figma khusus plus satu tabel bersama. Setiap entri: nama, kebutuhan, komponen terdekat, layar terdampak, usulan, status.
16 — Struktur
Arsitektur File Figma
Pisah menjadi empat file, bukan satu file raksasa. Dengan 500+ layar, satu file akan berat dan mengunci kolaborasi.
| File | Isi | Alasan pemisahan |
|---|---|---|
| 01 · Foundations Dipublish | Token, gaya teks, efek, pustaka ikon, grid | Satu-satunya sumber token. File lain hanya mengonsumsi — perubahan menyebar otomatis. |
| 02 · Components Dipublish | 37 komponen Lamah + komponen kekurangan + template kondisi | Diaudit terpisah dari layar. Dipublish ke file rider & driver. |
| 03 · Rider | Alur & layar penumpang | ±262–344 layar. Butuh file sendiri agar tetap responsif. |
| 04 · Driver | Alur & layar sopir | ±260–338 layar. Tim bisa bergerak tanpa mengganggu file lain. |
Struktur halaman di dalam file layar
📐 00 · Cover & Changelog
🗺️ 01 · Flow Map — diagram seluruh perjalanan pengguna
📋 02 · Screen Inventory — daftar layar + status + blocker
🎨 03 · WIP — eksplorasi, bukan untuk handoff
✅ 10 · Login & Pendaftaran
✅ 11 · Beranda & Peta
✅ 12 · Alur Perjalanan
✅ 13 · Pembayaran & Dompet
✅ 14 · Keselamatan (SOS)
✅ 15 · Chat
✅ 16 · Explore & Iklan — penumpang saja
✅ 17 · Riwayat & Akun
🔮 30 · Future — Tawar-menawar
🔮 31 · Future — Membership / Terjadwal / Multi-tujuan
⚠️ 90 · Daftar Kekurangan Lamah
📤 91 · Catatan Serah TerimaAwalan angka menjaga urutan halaman tetap stabil. Emoji memberi pemindaian cepat: ✅ siap serah terima, 🔮 menunggu keputusan, ⚠️ butuh pembahasan.
17 — Token
Strategi Token di Figma
Bayangkan tiga lapis: nilai mentah (misalnya “biru tua #1A2F9E”), token bermakna (“warna aksi utama”), dan penggunaan (tombol memakai “warna aksi utama”). Desainer hanya menyentuh lapis tengah. Kalau brand berubah, cukup ubah lapis paling bawah — seluruh aplikasi ikut berubah tanpa menyentuh satu layar pun.
| Kelompok | Mode | Isi | Aturan pakai |
|---|---|---|---|
01 Raw | Tunggal | Tangga warna hasil warna dasar, emas, netral, warna status, nilai mentah | Disembunyikan dari publikasi. Hanya lapis Semantic yang boleh mereferensi. Tidak pernah dipakai langsung. |
02 Semantic | Terang · Gelap | 31 token bermakna: warna aksi, latar, teks, garis, pembatas | Satu-satunya kelompok yang boleh diikat komponen dan layar. Ganti mode = ganti tema. |
03 Scale | Tunggal | Jarak 14 tingkat, radius 10 tingkat, 4 tingkat bayangan, durasi & kurva animasi | Diikat ke padding, jarak, sudut, dan efek. Tidak punya mode karena tidak berubah antar tema. |
Penamaan token — cerminkan nama di kode
accent/primary → warna aksi utama (warna dasar)
accent/secondary → warna emas #C2AC7B
bg/primary → latar utama
bg/secondary → latar sekunder
text/primary → teks utama
text/secondary → teks redup
border/default → garis tepi
divider → garis pemisah
status/success · error · warning · info
space/s0 s2 s4 s8 s10 s12 s16 s20 s24 s32 s40 s48 s64 s80
radius/none xs sm image md fab lg dark-input xl pill
motion/duration-fast (150ms) · normal (300ms) · slow (500ms)Developer membaca warna dengan nama seperti textSecondary. Kalau token Figma bernama text/secondary, tidak ada terjemahan yang perlu terjadi. Kalau dinamai “Abu-abu 600”, itu menciptakan pekerjaan tambahan di setiap sesi serah terima selama berbulan-bulan.
18 — Warna
Seed Color & Cara Mendapatkan Warna yang Benar
Seed color adalah satu warna brand utama Sanad — satu nilai warna saja. Dari warna ini, sistem menurunkan seluruh palet aplikasi: warna tombol, latar, teks, garis, versi terang dan versi gelap. Di dalam kode, letaknya persis di satu baris ini:
LamahTheme.fromSeed(
seed: Color(0xFF101F79), ← INI seed color-nya
)Yang perlu ditanyakan ke product owner hanya dua: “warna brand utama Sanad hex-nya berapa?” dan “pakai emas bawaan atau ada aksen sendiri?” Nilai #101F79 di atas hanya contoh dari dokumentasi Lamah, bukan warna Sanad.
Figma tidak bisa menjalankan algoritma warna milik Lamah. Kalau warna dipilih dengan mata atau dengan plugin lain, hasil di Figma akan berbeda dari hasil di aplikasi — dan setiap layar yang dibuat akan salah warna. Ini kesalahan paling mahal yang bisa terjadi di awal project.
Prosedur yang benar — sekali jalan, sekitar dua puluh menit
- Konfirmasi warna dasar Sanad ke product owner.
- Konfirmasi apakah memakai emas bawaan
#C2AC7Batau aksen sendiri. - Minta developer menjalankan fungsi tema dengan warna itu untuk versi terang dan gelap, lalu mencetak seluruh 31 nilai warna.
- Masukkan kedua set itu ke kelompok token Semantic — set terang ke mode Terang, set gelap ke mode Gelap.
- Masukkan tangga warna ke kelompok Raw sebagai referensi, lalu kunci.
- Buat satu papan “Bukti Token”: sandingkan tangkapan layar aplikasi dengan tampilan Figma untuk memastikan warnanya identik sebelum produksi dimulai.
Hindari warna yang sangat terang atau pastel — kontrasnya lemah di mode terang. Lamah merekomendasikan warna pekat sedang-ke-gelap: navy, hijau, ungu, atau merah tua. Ada lapisan pengaman kontras, tapi jangan mengandalkannya. Kalau warna brand Sanad kebetulan terang, angkat ini sekarang, bukan setelah 200 layar jadi.
19 — Tipografi
Typography & Arabic
Lamah menyediakan tiga keluarga font: Zain (bawaan), Geist, dan Geist Mono. Skala ukuran berjalan dari 10px sampai 64px. Developer boleh mengganti font.
Keputusan yang harus diambil
- Sanad memakai Zain atau font sendiri? Zain mendukung Arab & Latin — kandidat kuat untuk produk berbahasa Arab.
- Angka mana yang dipakai: Arab (٠١٢٣) atau Latin (0123)? Ini menyentuh nominal uang, OTP, plat nomor, dan jarak — hampir setiap layar.
- Lisensi font untuk penggunaan komersial sudah aman?
Cara membangunnya di Figma
- Nama gaya teks mengikuti token, bukan peran:
body/md, bukan “Heading 1”. - Dokumentasikan tiap gaya: font, ukuran, ketebalan, tinggi baris, perataan.
- Buat pasangan Arab dan Inggris bila metriknya berbeda.
- Perataan bawaan untuk gaya Arab: kanan. Ini menghemat ribuan koreksi manual.
Ukuran teks terkecil di sistem Lamah adalah 10px. Untuk aksara Arab, ukuran ini di bawah ambang keterbacaan yang wajar — bentuk huruf Arab bergantung pada detail titik dan sambungan yang hilang di ukuran kecil. Brief Sanad mewajibkan aksesibilitas di seluruh rilis pertama. Rekomendasi: batasi 10px hanya untuk konten yang tidak penting, dan usulkan minimum 12px untuk teks Arab yang membawa arti.
20 — Skala
Ukuran, Sudut, Bayangan & Animasi
Jarak — 14 tingkat
0 · 2 · 4 · 8 · 10 · 12 · 16 · 20 · 24 · 32 · 40 · 48 · 64 · 80
Hanya nilai ini yang boleh dipakai untuk padding dan jarak antar elemen. Kalau tata letak menuntut 14 atau 28, itu tanda komposisinya perlu disesuaikan — bukan tanda untuk mengetik angka bebas.
Sudut — 10 tingkat
none 0 · xs 4 · sm 8 · image 12 · md 16 · fab 20 · lg 24 · dark-input 28 · xl 32 · pill 1000
Perhatikan nama-nama yang bermakna: image, fab, dark-input. Ada niat penggunaan yang melekat. Pakai image untuk gambar, meski md angkanya berdekatan.
Bayangan — 4 tingkat
none · sm · md · lg
Buat sebagai gaya efek di Figma, bukan bayangan lepas. Empat tingkat saja — jangan menciptakan tingkat kelima.
Animasi — 3 durasi, 3 kurva
cepat 150ms · normal 300ms · lambat 500ms
Beri catatan transisi dengan nama token, bukan angka. Contoh: “Panel bawah naik — durasi normal, kurva masuk.”
Tinggi tombol di Lamah: kecil 40px, sedang 48px, besar 56px. Standar minimum area sentuh adalah 44pt (iOS) / 48dp (Android) — artinya ukuran kecil ada di bawah ambang. Brief Sanad mewajibkan area sentuh yang memadai. Aturan kerja: jangan pernah pakai ukuran kecil untuk aksi utama. Untuk aplikasi sopir — di mana interaksi terjadi di dalam kendaraan — pertimbangkan ukuran besar sebagai bawaan, bukan sedang.
21 — Komponen
37 Komponen Lamah
Semua komponen harus dibangun ulang di Figma dengan nama dan pengaturan yang persis sama dengan versi kodenya.
| Kategori | Komponen |
|---|---|
| Tombol & Aksi (4) | Tombol (5 varian × 3 ukuran) · Tombol ikon (4 varian) · Tombol lingkaran · Tombol mengambang |
| Input & Kontrol (9) | Kolom teks · Sakelar · Kotak centang · Grup pilihan · Bilah pencarian · Dropdown dengan pencarian · Kontrol tersegmentasi · Chip · Chip pilihan |
| Navigasi (3) | Bilah atas · Navigasi bawah · Tab |
| Permukaan & Tata Letak (5) | Kartu (3 varian) · Baris daftar · Garis pemisah · Kartu media · Baris konten |
| Overlay & Umpan Balik (6) | Dialog · Panel bawah · Menu · Tooltip · Banner (4 varian) · Toast (3 varian) |
| Progres & Loading (3) | Bilah progres · Spinner (3 ukuran) · Rangka pemuatan |
| Tampilan Data (6) | Avatar (5 ukuran) · Lencana · Tag (6 varian) · Titik status (4 varian) · Indikator langkah · Kondisi kosong |
Contoh pemetaan — Tombol
| Pengaturan di Figma | Pilihan | Catatan |
|---|---|---|
variant | primary · secondary · tertiary · danger · gold | primary = isi penuh warna dasar · danger = merah untuk aksi menghapus · gold = brand/premium |
size | sm 40px · md 48px · lg 56px | ⚠️ sm di bawah ambang area sentuh |
state | default · pressed · disabled | Nonaktif dinyatakan tanpa aksi, bukan lewat sakelar “disabled” |
loading | true · false | Menampilkan spinner dan menonaktifkan sentuhan |
expanded | true · false | Selebar penuh induknya |
Semua varian berbentuk pil. Tidak ada pengaturan warna, padding, atau sudut — semuanya dari tema.
Urutan pembangunan — dua gelombang
Gelombang 1 (16 komponen, dipakai hampir di semua layar): tombol, tombol ikon, kolom teks, bilah atas, kartu, baris daftar, panel bawah, dialog, spinner, rangka pemuatan, kondisi kosong, toast, banner, pemisah, tag, titik status.
Gelombang 2 (20 komponen): navigasi bawah, tab, kontrol tersegmentasi, chip, chip pilihan, sakelar, kotak centang, grup pilihan, bilah pencarian, dropdown, avatar, lencana, indikator langkah, bilah progres, kartu media, baris konten, menu, tooltip, tombol mengambang, tombol lingkaran.
Gelombang 1 saja sudah cukup untuk memulai alur login dan pendaftaran sopir — dua alur pertama di rencana kerja.
22 — Kondisi
Strategi Menangani Ratusan Kondisi
Brief mewajibkan hingga 13 kondisi per alur. Kalau setiap kondisi digambar sebagai layar terpisah, satu layar “Dompet” jadi 7 layar yang harus di-update satu per satu setiap kali desain berubah. Solusinya: buat kondisi sebagai lapisan yang ditumpuk di atas layar dasar. Satu layar + 6 lapisan kondisi = 7 tampilan dari 1 sumber. Kalau desain dasarnya berubah, semuanya ikut berubah otomatis.
| Kondisi wajib | Komponen Lamah | Cara membangunnya |
|---|---|---|
| Memuat | Rangka pemuatan, spinner | Rangka untuk daftar, spinner untuk aksi |
| Kosong | Kondisi kosong | Satu komponen dengan pilihan konteks: belum ada perjalanan, tiket, notifikasi |
| Validasi | Kolom teks kondisi error | Sudah tercakup varian kolom. Tidak perlu layar terpisah. |
| Offline | Banner peringatan | Banner menetap di bawah bilah atas, dibuat sebagai lapisan yang bisa ditumpuk ke layar mana pun |
| Waktu habis / kedaluwarsa | Dialog, banner | Untuk tarif, OTP, dan QR kedaluwarsa. Sertakan tombol coba lagi di dalamnya. |
| Error | Banner, toast, dialog | Tetapkan satu aturan tegas: inline untuk kolom, banner untuk kondisi layar, dialog untuk yang memblokir |
| Sukses | Toast, dialog | Toast untuk konfirmasi ringan, dialog untuk pembayaran dan aktivasi langganan |
| Konfirmasi hapus | Dialog + tombol merah | Satu dialog dipakai ulang: hapus akun, batalkan perjalanan, hapus tempat tersimpan |
| Izin ditolak | belum ada | Perlu dibuat: ikon, alasan, langkah selanjutnya. Wajib untuk lokasi, kamera, notifikasi. |
| Pemulihan setelah restart | belum ada | Untuk pendaftaran sopir yang aman terhadap restart dan pemulihan perjalanan |
| Terblokir / belum siap | belum ada | Wajib menjelaskan alasan dan langkah yang benar |
23 — Kekurangan
Gap Analysis: Kebutuhan Sanad vs Lamah UI
Ada berarti Lamah sudah menyediakan dan bisa dipakai apa adanya. Parsial berarti bahan dasarnya ada tapi perlu dirakit. Kosong berarti belum ada sama sekali — perlu dibuat baru atau diusulkan ke tim Lamah. Bawa daftar ini ke tim Lamah di minggu pertama, bukan di bulan ketiga.
| Kebutuhan Sanad | Status | Catatan |
|---|---|---|
| Tombol, kolom isian, dialog, panel, toast, banner, daftar, kartu | Ada | Tercakup penuh oleh 16 komponen inti. Pakai apa adanya. |
| Kondisi kosong, rangka pemuatan, spinner | Ada | Tercakup. Cukup tambah varian konteks. |
| Indikator langkah pendaftaran | Ada | Verifikasi apakah mendukung kondisi ditolak/perlu perbaikan per langkah. |
| Status dokumen (9 kondisi) | Parsial | Bahan ada, tapi belum ada komponen baris dokumen dengan 9 kondisi dan tombol kirim ulang. |
| Pemilihan kelas kendaraan | Parsial | Butuh baris kaya: ikon kendaraan, ETA, tarif, penanda khusus wanita, kondisi tidak tersedia. |
| Panel bawah di atas peta | Parsial | Komponennya ada, tapi interaksi gestur peta ↔ panel belum terdefinisi. |
| Kartu paket langganan | Parsial | Butuh perbandingan paket, harga tercoret saat voucher aktif, penanda terpilih. |
| Kolom voucher + kondisi harga | Parsial | 5 kondisi voucher. Ini bagian rilis pertama, bukan fitur masa depan. |
| Kanvas peta, penanda, garis rute | Kosong | Kekurangan terbesar. Tidak ada komponen peta sama sekali. Harus dibangun dalam batas kemampuan MapLibre. |
| Kolom OTP tersegmentasi | Kosong | Dipakai di kedua aplikasi pada langkah pertama. Prioritas tinggi. |
| Tampilan nominal uang | Kosong | Konversi dirham ke LYD, posisi simbol mata uang di layout kanan-ke-kiri. |
| Kartu tawaran sopir + hitung mundur | Kosong | Tawaran berbatas waktu. Butuh cincin hitung mundur dan kondisi waktu habis / sudah diambil. |
| Tampilan QR pembayaran | Kosong | QR khusus perjalanan dengan hitung mundur, buat ulang, dibayar, gagal. Inti alur pembayaran. |
| Gelembung chat + status pesan | Kosong | 6 kondisi pesan. Dipakai di chat perjalanan dan tiket bantuan. |
| Bintang penilaian | Kosong | Untuk input dan tampilan. Perhatikan arah bintang di layout kanan-ke-kiri. |
| Tombol darurat (SOS) | Kosong | Brief mewajibkan tidak digabung ke bantuan. Butuh tampilan tersendiri + pengaman anti-tekan-tak-sengaja. |
| Banner kesiapan sopir | Kosong | Harus membawa alasan + langkah selanjutnya untuk 5 kondisi berbeda. |
| Banner panduan belok | Kosong | Instruksi arah, jarak, hitung ulang rute, GPS hilang. Harus sesuai keluaran Valhalla. |
| Kartu dompet vs pendapatan tunai | Kosong | Dua sistem uang yang wajib terlihat berbeda secara struktural, bukan cuma beda label. |
| Unggah foto dokumen & kendaraan | Kosong | Pemilih, pratinjau, progres unggah, coba lagi, ganti, alasan penolakan. |
Ada tiga jalur untuk setiap kekurangan. (a) Usulkan ke tim Lamah agar masuk ke sistem — terbaik untuk komponen yang berguna lintas produk seperti kolom OTP dan bintang penilaian. (b) Bangun sebagai komponen khusus Sanad dengan awalan nama yang jelas, tetap terikat penuh ke token Lamah — untuk yang spesifik ride-hailing seperti kartu tawaran dan QR. (c) Tunggu, bila menyangkut fitur yang belum disetujui. Putuskan jalurnya di depan, supaya tidak ada komponen yatim yang muncul belakangan.
24 — RTL
Strategi Kanan-ke-Kiri
Lamah mengklaim komponennya sudah mendukung tata letak kanan-ke-kiri. Yang tidak otomatis adalah keputusan desain di atasnya.
Setup di Figma
- Semua tata letak otomatis berarah kanan-ke-kiri sejak komponen pertama — bukan dibalik belakangan.
- Gaya teks Arab rata kanan sebagai bawaan.
- Buat halaman “Uji RTL” di file Foundations sejak minggu pertama.
- Ikon berarah (panah, kembali, chevron) dibuat sebagai komponen dengan pilihan arah.
Kasus uji wajib
- Nomor telepon Libya di dalam kalimat Arab
- Kode OTP — urutan digit saat diketik
- Plat kendaraan — campuran huruf Arab & angka
- Nominal LYD — posisi simbol mata uang
- Kode voucher — biasanya huruf Latin kapital
- Teks Arab panjang di tombol dan judul kartu
- Jarak & durasi, tanggal & waktu
Dukungan RTL Lamah menangani tata letak. Yang tidak ditangani: arah bilah progres dan indikator langkah, arah animasi masuk dan keluar, orientasi ikon berarah, arah gestur geser, urutan bintang penilaian, dan yang paling berbahaya — arah peta. Peta dan navigasi tidak pernah dibalik; hanya antarmuka di atasnya yang dibalik. Tulis aturan ini sebelum layar peta pertama dibuat.
25 — Emas
Aturan Pemakaian Warna Emas
#C2AC7B Emas adalah aset paling berharga sekaligus paling mudah disalahgunakan dalam sistem ini. Terkunci, tidak pernah diubah, hadir di semua produk perusahaan. Dokumentasi menyebut peruntukannya: aksi brand dan premium.
Pakai emas untuk
- Momen langganan sopir — paket, pembelian, aktivasi, status aktif
- Membership penumpang (fitur masa depan)
- Aksen brand di layar pembuka dan pengenalan
- Warna aksi utama di mode gelap — ini otomatis dari sistem, bukan pilihan desainer
Jangan pakai emas untuk
- Aksi perjalanan biasa — pakai tombol utama
- Apa pun di dekat tampilan tarif
- Penanda status atau tingkat urgensi
- Dekorasi tanpa makna
Brief melarang langganan digambarkan sebagai komisi atau potongan tarif. Karena emas adalah warna “premium” dalam sistem ini, menempatkan emas di dekat angka tarif menciptakan asosiasi visual yang persis dilarang secara verbal. Aturan bersih: emas boleh muncul di layar langganan dan membership, tidak pernah di layar tarif atau pembayaran perjalanan.
26 — Konvensi
Konvensi Penamaan & Anotasi
Penamaan layar — format wajib dari brief
Format: Aplikasi / Fitur / Kondisi
Rider / Wallet Payment / Insufficient Balance
Rider / Ride Request / Quote Expired
Rider / Home / Location Permission Denied
Driver / Onboarding / Document Rejected
Driver / Subscription / Voucher Expired
Driver / Offer / Already TakenPenamaan komponen
LButton — cerminan Lamah, nama identik
LTextField
SanadOtpInput — kekurangan, awalan jelas
SanadOfferCard
SanadMoneyDisplay
State/Loading/List — lapisan kondisi, dikelompokkan
State/Offline/BannerAwalan Sanad membuat kekurangan terlihat langsung di panel aset. Kalau di akhir project ada 20 komponen berawalan Sanad, itu tepat 20 baris yang harus dibicarakan dengan tim Lamah.
Anotasi wajib di tiap layar
| Kategori | Isi |
|---|---|
| Aksi | Setiap tombol, ikon, kartu, kolom, tautan, gestur: apa aksinya, ke mana, apa hasilnya |
| Kondisi elemen | Mana yang berlaku: normal, ditekan, terpilih, nonaktif, memuat, sukses, error |
| Scroll | Arah, area, elemen diam, header menempel, tombol bawah, area aman, perilaku keyboard |
| Token | Sebut nama token, bukan angka. “Jarak space/s16”, bukan “jarak 16”. |
| Animasi | Sebut nama durasi dan kurva |
| Navigasi | Perilaku kembali, tutup, konfirmasi, dan aksi yang menghapus data |
| Kekurangan | Tandai setiap komponen buatan sendiri dengan lencana ⚠️ + tautan ke daftar kekurangan |
27 — Setup
Urutan Setup — 3 Minggu Pertama
Ini adalah detail konkret dari Fase 1 di rencana kerja.
Minggu 1 — Fondasi tidak boleh salah
- Tanya tim Lamah: apakah sudah ada pustaka Figma resmi?
- Kunci warna dasar Sanad bersama product owner
- Konfirmasi: emas bawaan atau aksen sendiri
- Minta developer mencetak 31 nilai warna untuk mode terang & gelap
- Buat file Foundations, isi 3 kelompok token
- Putuskan font dan sistem angka (Arab vs Latin)
- Bangun gaya teks Arab & Inggris
- Bangun 4 gaya efek bayangan
- Buat halaman Uji RTL dan isi dengan 7 kasus uji
- Buat papan Bukti Token — bandingkan dengan aplikasi berjalan
- Buka daftar kekurangan dengan ~20 entri dari bagian 23
Minggu 2 — Komponen gelombang 1
- Buat file Components, sambungkan ke Foundations
- Bangun 16 komponen gelombang 1 dengan pengaturan yang tepat
- Bangun pustaka lapisan kondisi
- Bangun kolom OTP dan tampilan nominal uang — dua kekurangan yang paling awal dibutuhkan
- Uji setiap komponen di mode terang dan gelap
- Uji setiap komponen dengan teks Arab panjang
- Publikasikan pustaka, lalu tinjau bersama tim mobile
Minggu 3 — Komponen gelombang 2 & validasi
- Bangun 20 komponen gelombang 2
- Bangun kekurangan prioritas: kartu tawaran, QR pembayaran, baris dokumen, gelembung chat
- Rakit 3 layar percontohan: OTP, Dompet, Tawaran Sopir
- Serahkan ketiganya ke developer untuk uji implementasi nyata
- Perbaiki apa pun yang tidak bisa dibangun ulang dengan tepat
- Kirim daftar kekurangan v1 ke tim Lamah dan product owner
- Kunci konvensi penamaan & anotasi secara tertulis
Jangan mulai Fase 3 sampai seorang developer berhasil membangun ulang tiga layar percontohan hanya dengan komponen dan token Lamah — tanpa satu pun pertanyaan soal warna atau ukuran. Kalau uji ini gagal di 3 layar, ia akan gagal di 500.
28 — Data hilang
15 Data yang Belum Tersedia
Dokumentasi publik Lamah tidak mencantumkan beberapa nilai yang dibutuhkan untuk membangun pustaka Figma. Semuanya sudah diidentifikasi di sini agar bisa diminta sekaligus, bukan ditemukan satu per satu di tengah pengerjaan. Tidak satu pun boleh diisi dengan tebakan — file token yang menyertai dokumen ini sengaja memakai warna magenta mencolok sebagai penanda, supaya kalau ada yang lolos, langsung terlihat rusak.
| # | Yang belum ada | Minta ke | Memblokir |
|---|---|---|---|
| 1 | Warna dasar (seed color) | Product owner | Semuanya. Satu nilai yang menurunkan seluruh palet. |
| 2 | Emas bawaan atau aksen sendiri | Product owner | Semua permukaan aksen + seluruh mode gelap |
| 3 | 31 nilai warna, terang & gelap | Developer | Semua layar |
| 4 | ~11 nama token warna yang belum dipublikasi | Tim Lamah | Kelengkapan kelompok token |
| 5 | Tangga warna dari warna dasar | Developer | Kelompok token mentah |
| 6 | Nilai warna status (sukses/error/peringatan/info) | Developer | Banner, toast, tag, titik status |
| 7 | Skala ukuran teks antara 10px dan 64px | Tim Lamah | Setiap gaya teks |
| 8 | Ketebalan font, tinggi baris, jarak huruf | Tim Lamah | Setiap gaya teks |
| 9 | Nilai bayangan (4 tingkat) | Developer | Gaya efek |
| 10 | Nilai kurva animasi | Tim Lamah | Semua prototipe dan catatan animasi |
| 11 | Keputusan font & sistem angka Arab vs Latin | Product owner | Setiap gaya teks |
| 12 | Apakah sudah ada pustaka Figma Lamah resmi? | Tim Lamah | Menentukan membangun atau mengonsumsi — berminggu-minggu kerja |
| 13 | Apakah ada file ekspor token siap impor? | Tim Lamah | Kalau ada, setup token turun dari minggu jadi jam |
| 14 | Apakah indikator langkah mendukung kondisi ditolak? | Tim Lamah | Alur verifikasi dokumen sopir |
| 15 | Versi Lamah yang dipakai & jadwal rilis berikutnya | Tim Lamah | Mendesain untuk versi salah = pekerjaan ulang diam-diam |
29 — Penutup
Pertanyaan Terbuka — Kirim Minggu Ini
| Ke siapa | Pertanyaan | Kenapa mendesak |
|---|---|---|
| Product Owner Sanad | Warna brand utama Sanad hex-nya berapa? | Satu keputusan yang menurunkan seluruh palet. Tidak ada yang bisa dimulai tanpa ini. |
| Pakai emas bawaan atau aksen sendiri? | Mengubah warna aksen di seluruh sistem dan seluruh mode gelap. | |
| Angka Arab atau Latin? | Menyentuh tarif, OTP, plat nomor, jarak — hampir setiap layar. | |
| Mode gelap masuk rilis pertama? | Brief menyebut “harus dipertimbangkan”. Kalau wajib, jumlah layar berlipat. | |
| Tim Lamah | Apakah sudah ada pustaka Figma resmi? | Menentukan apakah 3 minggu pertama adalah membangun atau mengonsumsi. |
| Ada file ekspor token siap impor? | Kalau ada, setup token jadi hitungan jam, bukan minggu. | |
| Bagaimana proses mengusulkan komponen baru, berapa lama siklusnya? | Menentukan kekurangan diusulkan ke Lamah atau dibangun sendiri. | |
| Indikator langkah mendukung kondisi ditolak per langkah? | Pendaftaran dokumen sopir bergantung pada ini. | |
| Versi mana yang dipakai Sanad, kapan rilis berikutnya? | Mendesain untuk versi salah menciptakan pekerjaan ulang. | |
| Mobile Lead Sanad | Interaksi peta apa yang benar-benar bisa dibuat dengan MapLibre? | Kekurangan terbesar. Mendesain interaksi yang tidak bisa dibangun berarti kerja ulang mahal. |
| Bentuk keluaran panduan arah dari Valhalla seperti apa? | Menentukan struktur banner navigasi sopir. | |
| Data apa saja yang tersedia di transaksi Blnk? | Menentukan isi kartu transaksi dompet dan halaman detail. |
30 — Deliverable
Semua File
Empat file pendukung. Dokumen yang sedang kamu baca adalah gabungan dari semuanya — file di bawah dipakai saat butuh detail teknis atau untuk diimpor langsung ke perkakas.