Program Studi Bisnis Digital • FEB

Teknologi Web & Mobile

Pertemuan 6 — Menerjemahkan Desain UI/UX ke Teknologi

Bagaimana sebuah desain di Figma berubah menjadi aplikasi yang benar-benar bisa dipakai pelanggan — dan mengapa proses ini menentukan kecepatan serta biaya produk digital Anda.

RPS MINGGU 6 • 2X50 MENIT

Selamat datang kembali, Anda sudah masuk sepertiga jalan semester ini. Minggu lalu kita bicara tentang perencanaan dan pengembangan produk digital secara umum; hari ini kita masuk ke tahap yang jauh lebih konkret, yaitu bagaimana sebuah desain cantik di Figma benar-benar berubah menjadi aplikasi yang bisa Anda sentuh di layar ponsel. Bayangkan Anda seorang product manager di Tokopedia atau di sebuah startup UMKM digital: tim desain sudah membuat tampilan yang indah, tapi kalau Anda tidak paham bagaimana desain itu diterjemahkan menjadi kode, Anda akan kesulitan menilai apakah estimasi waktu developer masuk akal atau tidak. Pertemuan ini akan membekali Anda dengan kerangka berpikir itu, bukan untuk membuat Anda jadi programmer, tapi untuk membuat Anda jadi pengambil keputusan produk yang paham arsitektur di baliknya. Siapkan diri Anda, karena hari ini kita akan menghitung beberapa angka nyata dari dunia desain-ke-kode.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu menjelaskan proses penerjemahan desain UI/UX menjadi produk teknologi yang siap dipakai pengguna. Secara rinci:

CAPAIAN 1

ALUR KERJA

Menjelaskan tahapan dari wireframe → mockup → prototype → kode dan apa yang berubah di tiap tahap.

CAPAIAN 2

TERJEMAHAN

Memahami bagaimana HTML, CSS, dan JavaScript masing-masing menerjemahkan struktur, gaya, dan perilaku desain.

CAPAIAN 3

SISTEM

Menjelaskan peran design system dan design token dalam menjaga konsistensi desain-ke-kode dalam skala besar.

CAPAIAN 4

KEPUTUSAN

Menilai trade-off bisnis antara kesetiaan desain (pixel-perfect) dan kecepatan rilis produk.

Empat capaian ini adalah jembatan antara materi minggu lalu tentang perencanaan produk dan materi minggu depan tentang prototyping serta Minimum Viable Product. Pertama, Anda perlu paham alur kerja standar dari sketsa kasar sampai kode yang berjalan. Kedua, Anda perlu tahu bagaimana tiga bahasa dasar web — HTML, CSS, dan JavaScript — masing-masing bertanggung jawab menerjemahkan bagian berbeda dari sebuah desain. Ketiga, kita akan bahas design system, semacam "kamus visual" yang dipakai perusahaan seperti Gojek atau BCA agar aplikasi mereka konsisten di ratusan layar berbeda. Keempat, dan ini yang paling relevan untuk Anda sebagai calon manajer produk, kita akan bicara soal trade-off: kapan sebuah desain harus diikuti persis pixel demi pixel, dan kapan lebih baik dilonggarkan demi kecepatan rilis ke pasar.

Kenapa "Desainnya Bagus" Saja Tidak Cukup?

Bayangkan tim desain sebuah startup fintech membuat mockup aplikasi yang memukau di Figma. Tiga bulan kemudian, aplikasi rilis — dan tampilannya berantakan di banyak ponsel Android murah.

GEJALA 1

LAYAR PECAH

Tombol tumpang tindih di layar kecil — desain hanya diuji di satu ukuran layar.

GEJALA 2

TIDAK KONSISTEN

Warna tombol beda-beda di tiap halaman — tidak ada design system yang diikuti developer.

GEJALA 3

MOLOR & MAHAL

Developer bolak-balik bertanya ke desainer karena spesifikasi tidak jelas — waktu rilis molor berminggu-minggu.

Akar masalahnya bukan desainnya jelek — tapi proses menerjemahkan desain ke teknologi yang tidak sistematis. Itulah yang kita bedah hari ini.

Bagian 1 dari 3

Bahasa Desain: Dari Ide ke Blueprint

Sebelum ada satu baris kode pun ditulis, sebuah desain melewati beberapa tahap kematangan — dan setiap tahap punya tujuan komunikasi yang berbeda.

UI vs UX: Dua Istilah yang Sering Tertukar

Keduanya sering disebut bersamaan ("UI/UX"), padahal maknanya berbeda dan sama-sama penting saat diterjemahkan ke teknologi.

UI — USER INTERFACE

TAMPILAN

Apa yang dilihat & disentuh pengguna: warna, tombol, ikon, tata letak. Diterjemahkan terutama lewat CSS (gaya visual).

UX — USER EXPERIENCE

PENGALAMAN

Bagaimana rasanya memakai produk: alur navigasi, kecepatan, kemudahan. Diterjemahkan lewat struktur (HTML) & perilaku (JS).

Analogi sederhana: UI adalah tampilan sebuah toko — etalase, rak, pencahayaan. UX adalah pengalaman berbelanja di toko itu — apakah mudah menemukan barang dan membayar di kasir. Aplikasi Tokopedia bisa punya UI indah, tapi kalau alur checkout membingungkan, UX-nya buruk.

Ini adalah kebingungan paling umum di kalangan mahasiswa dan bahkan profesional pemula. UI, singkatan dari User Interface, adalah segala sesuatu yang bisa dilihat dan disentuh langsung oleh pengguna — warna tombol, jenis huruf, ikon, tata letak halaman. UX, singkatan dari User Experience, adalah keseluruhan rasa dan kemudahan saat memakai produk itu, termasuk alur perpindahan antar halaman dan seberapa cepat pengguna mencapai tujuannya. Contoh paling gampang, bayangkan aplikasi BCA mobile: UI-nya adalah warna biru khas BCA dan tombol-tombol yang rapi, sementara UX-nya adalah seberapa mudah Anda transfer uang dalam tiga langkah tanpa nyasar. Yang perlu Anda ingat, saat diterjemahkan ke kode, UI banyak berhubungan dengan CSS yaitu bahasa pengatur gaya visual, sementara UX lebih berhubungan dengan struktur halaman dan logika interaksi yang diprogram lewat JavaScript.

Tingkatan Kematangan Desain: Wireframe → Mockup → Prototype

Sebelum sampai ke developer, desain naik bertahap dalam fidelity (tingkat kedekatan dengan produk asli).

TIGA TAHAP KEMATANGAN DESAIN

Ketiga tahap ini seperti membangun rumah: wireframe adalah kerangka bangunan berupa kotak dan garis abu-abu, semata untuk menyepakati tata letak dan alur, belum peduli warna cat atau jenis lantai. Mockup adalah foto rumah yang sudah jadi dengan cat, lantai, dan dekorasi lengkap — tampilan visual final, tapi masih berupa gambar diam yang tidak bisa dijalankan. Prototype adalah rumah contoh yang siap dimasuki dan dicoba, di mana tombol bisa diklik dan berpindah halaman meski di baliknya belum ada kode sungguhan, hanya simulasi di dalam alat seperti Figma. Developer biasanya baru mulai menulis kode setelah mockup atau prototype disetujui, karena menulis kode dari wireframe saja terlalu berisiko banyak revisi. Ingat urutan ini baik-baik, karena minggu depan kita akan mendalami prototype lebih jauh saat membahas MVP.

Design System & Design Token: Kamus Visual Perusahaan

Design system adalah kumpulan aturan & komponen visual baku suatu produk. Isinya dipecah jadi satuan kecil terukur bernama design token.

TOKEN WARNA

#0E8A4F

Satu kode warna resmi "hijau brand" — dipakai di semua tombol utama, tak boleh diganti sembarangan.

TOKEN JARAK

8px, 16px, 24px

Satuan jarak (spacing) baku antar elemen — kelipatan 8, bukan angka bebas seperti 13px.

TOKEN HURUF

16 / 20 / 25px

Skala ukuran teks baku (type scale) — akan kita hitung sendiri dua slide lagi.

Design token inilah yang membuat aplikasi seperti Gojek terasa "satu keluarga" di halaman pesan makanan maupun pesan mobil — karena keduanya menarik dari token yang sama, bukan dirancang ulang tiap tim.

Bayangkan design system sebagai kamus resmi visual sebuah perusahaan, yang menyimpan aturan baku agar semua tim desain dan developer "berbicara dalam bahasa yang sama". Di dalam kamus itu ada satuan-satuan kecil bernama design token — misalnya token warna yang menetapkan satu kode warna resmi untuk hijau brand, token jarak yang menetapkan kelipatan delapan piksel antar elemen supaya tidak berantakan, dan token ukuran huruf yang menetapkan skala baku. Ketika developer menulis kode, mereka tidak menebak-nebak warna atau jarak, melainkan memanggil token yang sudah disepakati, sehingga aplikasi sebesar Gojek dengan puluhan tim bisa tetap terasa konsisten di semua halamannya. Bagi Anda sebagai calon manajer produk, mendorong tim untuk memakai design system sejak awal adalah investasi yang menghemat waktu developer secara signifikan di kemudian hari.

Hitung dari Nol: Grid System 12-Kolom

Desainer sering merancang di atas grid (kerangka kolom tak terlihat) agar tata letak rapi & konsisten. Mari hitung lebar 1 kolom dari kontainer selebar 1200px.

Langkah	Perhitungan	Nilai
1. Lebar kontainer (desktop)	ditetapkan tim desain	1200px
2. Kurangi margin kiri+kanan	1200 − (24 × 2)	1152px
3. Total lebar gutter (12 kolom = 11 celah)	11 × 24px	264px
4. Sisa lebar untuk kolom	1152 − 264	888px
5. Lebar 1 kolom	888 ÷ 12	74px

HASIL

1 KOLOM ≈ 74px

Elemen "4 kolom" → 4×74 + 3×24 = 368px

Sekarang kita hitung angka yang benar-benar dipakai desainer setiap hari. Kita mulai dari lebar kontainer standar desktop, seratus dua puluh sentimeter, maaf, seribu dua ratus piksel. Kurangi margin kiri dan kanan masing-masing dua puluh empat piksel, sisa seribu seratus lima puluh dua piksel. Dua belas kolom berarti ada sebelas celah atau gutter di antaranya, masing-masing dua puluh empat piksel, jadi total gutter dua ratus enam puluh empat piksel. Sisa lebar untuk kolom itu sendiri adalah delapan ratus delapan puluh delapan piksel, dibagi dua belas kolom, hasilnya tujuh puluh empat piksel per kolom. Kalau developer diminta membuat kartu produk yang "melebar empat kolom", dia tinggal menghitung empat dikali tujuh puluh empat ditambah tiga gutter dikali dua puluh empat, hasilnya tiga ratus enam puluh delapan piksel — inilah yang membuat komunikasi desainer-developer presisi, bukan kira-kira.

Coba Sendiri: Hitung Lebar Kolom Grid Anda

Ubah lebar kontainer, margin, dan jumlah gutter, lalu amati bagaimana lebar satu kolom grid berubah.

Handoff: Serah-Terima dari Desainer ke Developer

Handoff (serah-terima desain) adalah momen kritis: desain digital berubah jadi spesifikasi teknis yang bisa dibaca developer.

TANPA ALAT HANDOFF

TEBAK-TEBAKAN

Developer mengukur jarak & warna manual dari gambar — rawan salah, lambat, banyak revisi.

DENGAN FIGMA DEV MODE

SPESIFIKASI OTOMATIS

Klik satu elemen → keluar kode CSS, jarak piksel, dan kode warna persis — siap salin.

Dokumen handoff yang baik minimal memuat: ukuran & jarak tiap elemen, kode warna resmi, aset gambar siap unduh, dan catatan perilaku (misalnya "tombol berubah abu-abu saat tidak aktif").

Handoff adalah titik paling sering menjadi sumber miskomunikasi dalam proyek digital, karena di sinilah bahasa visual desainer harus berubah menjadi instruksi teknis yang presisi untuk developer. Tanpa alat bantu, developer harus menebak-nebak jarak antar elemen dan kode warna hanya dengan melihat gambar, yang jelas rawan kesalahan dan menyebabkan bolak-balik revisi seperti pada kasus fintech tadi. Sekarang, alat seperti Figma punya fitur bernama Dev Mode, yang memungkinkan developer mengklik satu elemen desain dan langsung mendapat kode CSS, jarak dalam piksel, serta kode warna yang persis sama, sehingga tinggal disalin ke kode program. Sebagai calon manajer produk, penting bagi Anda memastikan tim desain selalu menyiapkan dokumen handoff yang lengkap sebelum developer mulai bekerja, karena setiap jam yang dihemat di tahap ini akan berlipat jauh lebih besar di tahap pengembangan.

Bagian 2 dari 3

Dari Blueprint ke Kode Hidup

Setelah desain siap diterjemahkan, teknologi web mengambil alih — kita bedah bagaimana HTML, CSS, dan JavaScript masing-masing berperan.

Tiga Lapis Teknologi Web: Struktur, Gaya, Perilaku

Satu halaman web dibangun dari tiga bahasa dengan tugas terpisah — masing-masing menerjemahkan aspek berbeda dari desain.

HTML

STRUKTUR

HyperText Markup Language

Kerangka konten: judul, paragraf, tombol, gambar. Menerjemahkan wireframe.

CSS

GAYA

Cascading Style Sheets

Warna, jarak, font, tata letak. Menerjemahkan mockup (tampilan UI).

JAVASCRIPT

PERILAKU

Bahasa pemrograman interaktif

Klik, animasi, validasi form. Menerjemahkan prototype (interaksi UX).

Kesalahan umum manajer produk pemula: menganggap "kode" itu satu hal. Padahal ketiganya butuh keahlian & waktu estimasi berbeda — animasi kompleks di JavaScript jauh lebih mahal daripada mengubah warna di CSS.

Ini adalah pembagian tugas paling fundamental dalam pengembangan web, dan sangat penting Anda pahami sebagai calon pengambil keputusan produk. HTML berperan seperti kerangka bangunan, menentukan struktur konten yakni apa saja yang ada di halaman — judul, paragraf, tombol, gambar — dan ia menerjemahkan wireframe yang kita bahas tadi. CSS berperan seperti dekorasi dan cat bangunan, mengatur warna, jarak, jenis huruf, serta tata letak, dan ia menerjemahkan mockup atau tampilan visual UI. JavaScript berperan seperti sistem listrik dan mekanik bangunan yang membuat pintu otomatis bisa bergerak, mengatur perilaku interaktif seperti animasi, validasi formulir, dan respons terhadap klik pengguna, dan ia menerjemahkan prototype atau interaksi UX. Kesalahan yang sering saya lihat pada calon manajer produk adalah menganggap semua permintaan perubahan "kode" itu setara — padahal mengubah warna tombol di CSS bisa selesai dalam hitungan menit, sementara menambahkan animasi kompleks di JavaScript bisa memakan waktu berhari-hari.

Responsive Design: Satu Desain, Banyak Ukuran Layar

Responsive (tanggap ukuran layar) berarti tata letak menyesuaikan diri otomatis di HP, tablet, dan laptop — lewat titik ambang bernama breakpoint.

MOBILE-FIRST: RANCANG DARI LAYAR TERKECIL DULU

Responsive design menjawab kenyataan bahwa pelanggan Anda mengakses aplikasi dari ponsel Android murah, tablet, sampai laptop kantor, dengan ukuran layar yang sangat beragam. Titik ambang tempat tata letak berubah bentuk disebut breakpoint — misalnya di bawah tujuh ratus enam puluh delapan piksel dianggap mobile dan tampil satu kolom, antara tujuh ratus enam puluh delapan sampai seribu dua puluh empat piksel dianggap tablet dan tampil dua kolom, di atas itu dianggap desktop dan bisa memakai penuh dua belas kolom grid yang kita hitung tadi. Pendekatan modern yang disebut mobile-first berarti developer merancang dulu untuk layar terkecil, baru menambah kompleksitas untuk layar lebih besar — bukan sebaliknya. Ini penting secara bisnis karena riset menunjukkan mayoritas pengguna e-commerce Indonesia, termasuk Tokopedia dan Shopee, mengakses lewat ponsel, jadi kalau tampilan mobile terabaikan, Anda kehilangan mayoritas pelanggan.

Hitung dari Nol: Skala Ukuran Huruf (Type Scale)

Agar judul & teks terasa harmonis, desainer memakai rasio tetap antar ukuran huruf, bukan angka acak. Mari hitung skala dengan rasio 1,25 dari basis 16px.

Langkah	Perhitungan	Nilai
1. Ukuran dasar (teks isi/body)	ditetapkan desainer	16px
2. Ukuran judul kecil (h4)	16 × 1,25	20px
3. Ukuran judul sedang (h3)	20 × 1,25	25px
4. Ukuran judul besar (h2)	25 × 1,25	≈ 31px
5. Ukuran judul utama (h1)	31 × 1,25	≈ 39px

HASIL SKALA

16–20–25–31–39px

Rasio 1,25 (Major Third) — dipakai jadi token huruf

Sama seperti grid tadi, ukuran huruf yang terasa "enak dipandang" sebenarnya bukan kebetulan, melainkan hasil perhitungan rasio matematis. Kita mulai dari ukuran teks isi standar enam belas piksel, lalu kalikan berturut-turut dengan rasio satu koma dua lima untuk mendapatkan tingkatan judul berikutnya: dua puluh piksel untuk judul kecil, dua puluh lima piksel untuk judul sedang, kira-kira tiga puluh satu piksel untuk judul besar, dan kira-kira tiga puluh sembilan piksel untuk judul utama halaman. Rasio satu koma dua lima ini punya nama dalam teori musik, disebut major third, dan sering dipakai desainer karena terasa harmonis tanpa lompatan ukuran yang terlalu jauh. Ketika skala ini sudah disepakati, ia disimpan sebagai design token yang tadi kita bahas, sehingga developer tidak perlu menebak ukuran huruf sendiri — cukup memanggil token "h1" dan otomatis dapat tiga puluh sembilan piksel yang konsisten di seluruh aplikasi.

Coba Sendiri: Bangun Skala Tipografi Anda

Ubah ukuran dasar huruf dan rasio skala, lalu amati bagaimana tiap tingkatan judul dari h4 sampai h1 ikut membesar.

Component-Based UI: Membangun dari Balok Lego

Web modern dibangun dari komponen (blok UI yang bisa dipakai ulang) — bukan menulis ulang setiap tombol dari nol di setiap halaman.

TANPA KOMPONEN

TULIS ULANG

Tombol "Beli" ditulis manual di 50 halaman berbeda — ubah warna berarti edit 50 tempat.

DENGAN KOMPONEN

SATU SUMBER

Tombol "Beli" didefinisikan satu kali, dipakai ulang di 50 halaman — ubah sekali, berubah di semua.

Ini sebabnya perusahaan seperti Traveloka & Bank Jago punya "perpustakaan komponen" sendiri: investasi awal lebih besar, tapi produk baru bisa dirilis jauh lebih cepat di kemudian hari karena tinggal menyusun balok yang sudah ada.

Konsep komponen adalah alasan utama mengapa aplikasi besar bisa dikembangkan dengan cepat oleh banyak tim sekaligus tanpa kekacauan. Bayangkan tombol "Beli Sekarang" harus muncul di lima puluh halaman berbeda dalam sebuah aplikasi e-commerce; tanpa pendekatan komponen, developer menulis ulang kode tombol itu di setiap halaman, sehingga kalau suatu hari warnanya harus diubah, lima puluh tempat harus disunting satu per satu dan sangat rawan ada yang terlewat. Dengan pendekatan berbasis komponen, tombol itu didefinisikan sekali sebagai satu balok Lego yang bisa dipasang ulang di mana saja, sehingga mengubah satu definisi otomatis mengubah semua kemunculannya. Inilah alasan perusahaan seperti Traveloka atau Bank Jago berinvestasi membangun "perpustakaan komponen" sendiri di awal — biayanya lebih besar di depan, tapi setiap fitur baru setelahnya bisa dirakit jauh lebih cepat karena tinggal menyusun balok-balok yang sudah teruji. Sebagai manajer produk, memahami ini membantu Anda menjustifikasi investasi awal semacam ini ke pemangku kepentingan bisnis.

Aksesibilitas (a11y): Desain untuk Semua Pengguna

Aksesibilitas (sering disingkat a11y — a, 11 huruf, y) memastikan produk digital bisa dipakai pengguna dengan keterbatasan penglihatan, motorik, atau kondisi lain.

KONTRAS WARNA

≥ 4,5 : 1

Rasio kontras teks & latar minimal (standar WCAG) agar terbaca di bawah sinar matahari.

TAP TARGET

≥ 44px

Ukuran minimal tombol agar mudah disentuh jari — terutama pengguna lansia/UMKM di pasar.

TEKS ALT

ALT TEXT

Deskripsi teks pada gambar — dibaca screen reader untuk pengguna tunanetra.

Aksesibilitas bukan sekadar etika — ia juga keputusan bisnis: aplikasi yang sulit dipakai lansia atau pengguna keterbatasan berarti kehilangan segmen pasar yang nyata di Indonesia.

Aksesibilitas sering terlewat dalam diskusi desain-ke-teknologi, padahal ini menyangkut jutaan calon pengguna Anda. Standar internasional bernama WCAG menetapkan misalnya rasio kontras warna minimal empat koma lima berbanding satu antara teks dan latar belakang, supaya teks tetap terbaca oleh pengguna dengan penglihatan terbatas atau saat layar terkena sinar matahari terik di pasar tradisional. Ukuran tombol minimal empat puluh empat piksel juga penting supaya mudah disentuh jari, terutama bagi pengguna lansia yang di Indonesia kini semakin banyak bertransaksi digital lewat program dari bank maupun pemerintah. Teks alternatif atau alt text pada gambar memungkinkan pengguna tunanetra memakai pembaca layar untuk memahami isi gambar produk di sebuah toko daring. Sebagai calon manajer produk, Anda perlu memasukkan kebutuhan aksesibilitas ini ke dalam spesifikasi sejak tahap desain, bukan sebagai tambahan di akhir, karena memperbaikinya belakangan jauh lebih mahal.

Coba Sendiri: Uji Rasio Kontras Warna WCAG

Ubah warna teks dan latar, lalu amati apakah rasio kontrasnya lolos standar WCAG 4,5:1.

Bagian 3 dari 3

Kolaborasi Bisnis & Teknologi

Menerjemahkan desain ke teknologi bukan hanya soal teknis — ini juga soal keputusan bisnis: siapa yang terlibat, dan seberapa jauh kesetiaan pada desain harus dijaga.

Trade-off Bisnis: Pixel-Perfect vs Kecepatan Rilis

Pixel-perfect (implementasi persis sama dengan desain hingga piksel terakhir) terdengar ideal, tapi punya biaya nyata dalam waktu & uang.

PIXEL-PERFECT PENUH

LAMBAT, MAHAL

Cocok untuk produk brand-sensitif (bank, maskapai) di mana kepercayaan visual = kepercayaan bisnis.

"GOOD ENOUGH" & ITERATIF

CEPAT, MURAH

Cocok untuk MVP (Minimum Viable Product — produk minimum layak uji) startup tahap awal.

Keputusan ini bukan urusan developer sendiri — ini keputusan manajer produk: berapa banyak waktu-ke-pasar yang boleh dikorbankan demi kesempurnaan visual? Kita akan dalami MVP minggu depan.

Ini adalah salah satu keputusan paling penting yang akan sering Anda hadapi sebagai manajer produk digital. Pixel-perfect berarti setiap piksel di layar harus persis sama dengan file desain aslinya, dan ini masuk akal untuk produk yang sangat mengandalkan kepercayaan visual seperti aplikasi perbankan atau maskapai penerbangan, di mana ketidaksesuaian kecil bisa membuat pengguna curiga terhadap keamanan aplikasi. Namun bagi startup tahap awal yang sedang menguji apakah ide produknya laku di pasar, mengejar kesempurnaan pixel-perfect bisa jadi pemborosan waktu dan uang yang seharusnya dipakai untuk validasi cepat lewat produk minimum layak uji, yang akan kita bahas lebih dalam minggu depan. Keputusan mana yang diambil bukan urusan developer sendirian, melainkan keputusan bisnis yang harus diambil bersama oleh manajer produk, dengan mempertimbangkan berapa banyak waktu-ke-pasar yang rela dikorbankan demi kesempurnaan tampilan. Latihlah diri Anda untuk selalu bertanya "apakah kesetiaan penuh pada desain ini benar-benar diperlukan sekarang, atau bisa menyusul di iterasi berikutnya?"

Studi Kasus: Design System sebagai Aset Bisnis

Beberapa perusahaan digital Indonesia membangun design system mereka sendiri — dan menjadikannya keunggulan kompetitif, bukan sekadar dokumen desain.

TOKOPEDIA — "SOLID"

SATU SISTEM

Satu bahasa desain dipakai lintas fitur (jual, beli, dompet digital) sehingga pengguna tak perlu belajar ulang tiap fitur baru.

BANK JAGO

RILIS CEPAT

Fitur perbankan baru dirilis lebih cepat karena komponen UI (tombol, form) sudah teruji & siap pakai ulang.

Pelajaran untuk Anda: perusahaan yang menginvestasikan waktu di awal untuk membangun sistem desain-ke-kode yang rapi, justru bergerak lebih cepat di jangka panjang — kebalikan dari intuisi "buru-buru rilis dulu, rapikan nanti".

Mari kita lihat contoh nyata dari industri digital Indonesia agar konsep hari ini terasa lebih konkret. Tokopedia, misalnya, dikenal memiliki design system internal yang memastikan satu bahasa visual dipakai konsisten di seluruh fitur mereka, mulai dari jual-beli sampai layanan dompet digital, sehingga pengguna tidak perlu belajar ulang cara memakai aplikasi setiap kali ada fitur baru diluncurkan. Bank Jago, sebagai bank digital yang harus bergerak cepat menghadapi persaingan fintech, mengandalkan komponen UI yang sudah teruji supaya fitur perbankan baru bisa dirilis dalam hitungan minggu, bukan bulan, karena tim developer tidak perlu membangun tombol dan formulir dari nol setiap kali. Pelajaran pentingnya adalah, meskipun terasa kontraintuitif, perusahaan yang meluangkan waktu di awal untuk merapikan sistem desain-ke-kode justru bisa bergerak jauh lebih cepat dalam jangka panjang, dibandingkan perusahaan yang terus terburu-buru merilis tanpa fondasi yang rapi dan akhirnya terjebak memperbaiki kekacauan berulang-ulang. Ingat contoh ini ketika nanti Anda harus meyakinkan atasan untuk berinvestasi di fondasi teknis, bukan hanya fitur yang terlihat mata.

Latihan Diskusi Kelas

Kerjakan berpasangan (5 menit), lalu kita bahas bersama.

STUDI KASUS SINGKAT

Sebuah UMKM fesyen online meminta Anda menjadi konsultan produk digital. Mereka punya desain aplikasi mockup yang indah dari seorang desainer lepas, tapi anggaran pengembangan sangat terbatas dan mereka ingin rilis dalam 4 minggu untuk menangkap momentum Ramadan.

Bagian desain mana yang harus pixel-perfect, dan mana yang boleh "good enough" demi kecepatan?
Apakah mereka perlu membangun design system penuh, atau cukup daftar token warna & huruf sederhana?
Aspek aksesibilitas mana yang paling penting untuk segmen pasar mereka?

Latihan ini dirancang agar Anda benar-benar mempraktikkan kerangka berpikir hari ini pada situasi yang realistis, karena skenario UMKM fesyen dengan anggaran terbatas dan tenggat mepet ini sangat umum terjadi di Indonesia, terutama menjelang momentum belanja besar seperti Ramadan atau Harbolnas. Diskusikan dengan teman sebangku Anda selama lima menit: bagian mana dari desain yang benar-benar krusial secara bisnis sehingga layak diperjuangkan pixel-perfect, misalnya halaman pembayaran yang menyangkut kepercayaan, dan bagian mana yang boleh disederhanakan dulu demi mengejar tenggat empat minggu. Pikirkan juga apakah UMKM sekecil ini realistis membangun design system lengkap, atau cukup memulai dari daftar token warna dan huruf sederhana yang bisa berkembang nanti. Saya akan berkeliling mendengarkan diskusi Anda, dan setelah lima menit kita bahas beberapa jawaban bersama-sama di depan kelas.

Rangkuman & Menuju Pertemuan 7

CHEAT SHEET HARI INI

Wireframe → Mockup → Prototype: tiga tahap fidelity desain.
HTML/CSS/JS: struktur / gaya / perilaku.
Design system & token: kamus visual konsisten.
Grid 74px/kolom, skala huruf 16–39px: matematika di balik desain.
Pixel-perfect vs kecepatan rilis: keputusan bisnis, bukan teknis semata.

TUGAS SEBELUM PERTEMUAN 7

EKSPLORASI FIGMA

Buka contoh file Figma publik apa pun, identifikasi: 1 elemen wireframe, 1 token warna, dan 1 breakpoint yang terlihat. Bawa catatan singkat ke kelas.

Minggu depan (Pertemuan 7): Prototyping & Minimum Viable Product (MVP) — bagaimana membangun versi paling ramping dari sebuah produk untuk diuji ke pasar secepat mungkin.

Sebelum kita tutup, mari rangkum lima hal inti yang sudah kita bahas: tahapan fidelity desain dari wireframe sampai prototype, pembagian tugas HTML, CSS, dan JavaScript, peran design system dan token dalam menjaga konsistensi, dua perhitungan konkret yaitu lebar kolom grid tujuh puluh empat piksel dan skala huruf enam belas sampai tiga puluh sembilan piksel, serta keputusan bisnis soal pixel-perfect versus kecepatan rilis yang harus Anda ambil sebagai manajer produk kelak. Sebagai tugas ringan sebelum pertemuan berikutnya, silakan buka satu contoh file Figma publik yang bisa Anda cari daring, lalu coba identifikasi satu elemen yang tampak seperti wireframe, satu token warna yang konsisten dipakai berulang, dan satu titik breakpoint yang terlihat dari perubahan tata letak — bawa catatan singkat itu ke kelas berikutnya. Minggu depan kita akan melangkah lebih jauh ke topik prototyping dan Minimum Viable Product, di mana Anda akan belajar bagaimana membangun versi paling ramping dari sebuah produk untuk diuji secepat mungkin ke pasar sungguhan. Terima Kasih atas partisipasi Anda hari ini, sampai jumpa minggu depan.