Program Studi Bisnis Digital • FEB UNDIP

Desain UI & UX

Pertemuan 9 — Prinsip Desain Visual UI Bagian 2: Anatomi Komponen, Design System & Grid Layout

Membedah bagian-bagian sebuah tombol, merangkai aturan visual jadi satu design system (sistem desain terpadu), lalu mengukur grid layout dengan angka nyata.

RPS minggu 10 · 2x50 menit

Selamat pagi/siang, Anda semua. Minggu lalu kita sudah membahas Bagian 1 dari prinsip desain visual: Gestalt, psikologi warna, dan tipografi. Hari ini kita masuk Bagian 2, dan ini pertemuan yang saya anggap paling praktis di semester ini, karena kita akan membedah komponen antarmuka satu per satu — mulai dari tombol yang setiap hari Anda sentuh di aplikasi seperti Tokopedia atau BCA mobile. Setelah memahami anatominya, kita naik satu level ke design system, yaitu cara tim desain menjaga konsistensi ratusan komponen sekaligus. Terakhir kita akan menghitung sendiri struktur grid layout memakai angka nyata, supaya Anda tidak hanya paham konsepnya tapi juga bisa mengukurnya. Siapkan catatan, karena materi hari ini akan langsung terpakai saat Anda membuat mockup high-fidelity di pertemuan berikutnya.

Tujuan Pembelajaran Hari Ini

Melanjutkan Sub-CPMK prinsip desain visual, Anda diharapkan mampu menerapkan anatomi komponen, konsep design system, dan struktur grid pada rancangan UI. Secara rinci:

CAPAIAN 1

ANATOMI

Menguraikan bagian-bagian sebuah komponen UI (label, padding, ikon) dan lima state-nya (kondisi tampilan).

CAPAIAN 2

SISTEM

Menjelaskan design system (sistem desain) dan design token (nilai desain terkecil yang bisa dipakai ulang).

CAPAIAN 3

GRID

Menghitung struktur grid 12-kolom: lebar kanvas, margin, gutter (celah antar-kolom), dan lebar kolom.

CAPAIAN 4

TERAPAN

Menilai konsistensi komponen & grid pada aplikasi Indonesia nyata (Tokopedia, BCA mobile, dsb).

Bayangkan: Aplikasi Tanpa Aturan Visual

Sebuah startup e-commerce baru meluncurkan aplikasinya. Tiga developer mengerjakan tiga halaman berbeda tanpa panduan bersama:

HALAMAN BERANDA

TOMBOL BIRU

Sudut membulat penuh, ukuran besar, teks "Beli Sekarang".

HALAMAN KERANJANG

TOMBOL HIJAU

Sudut kotak tajam, ukuran kecil, teks "Checkout".

HALAMAN PROFIL

TOMBOL ABU

Sudut sedikit membulat, ukuran sedang, teks "Simpan".

Akibatnya: pengguna bingung mana yang bisa diklik, tim developer menghabiskan waktu menebak ukuran, dan brand terasa tidak profesional. Inilah masalah yang dipecahkan oleh anatomi komponen & design system hari ini.

Bagian 1 dari 3

Anatomi Komponen UI

Membedah bagian-bagian sebuah komponen antarmuka — label, padding, ikon, dan lima kondisi tampilannya — agar semua anggota tim memakai istilah yang sama.

Button Input Card

Apa Itu "Komponen" UI?

Komponen adalah unit antarmuka yang dipakai berulang — dirancang sekali, dipasang di banyak tempat.

CONTOH KOMPONEN UMUM

Button — tombol aksi (Beli, Kirim, Batal)
Input field — kolom isian teks/angka
Card — bingkai berisi produk/info ringkas
Navbar — bilah navigasi atas/bawah

PRINSIP ATOMIC DESIGN

Komponen tersusun berjenjang: atom (ikon, label) → digabung jadi molekul (satu baris input+label) → digabung jadi organisme (form login lengkap). Konsep dari Brad Frost, Atomic Design.

Anatomi Sebuah Tombol (Button)

BAGIAN-BAGIAN TOMBOL

Satu tombol punya lima kondisi tampilan (state): default, hover (kursor di atas), active (sedang ditekan), disabled (tak bisa diklik), dan focus (dipilih via keyboard).

Mari bedah satu tombol yang tampak sederhana ini. Perhatikan empat elemen: sudut radius menentukan seberapa membulat tepiannya, lebar tombol menentukan seberapa besar area yang bisa disentuh, padding adalah jarak kosong antara tepi tombol dengan label teks di dalamnya, dan tentu saja label teksnya sendiri, kadang ditambah ikon. Yang membuat desainer profesional berbeda dari pemula adalah kesadaran bahwa satu tombol sebenarnya punya lima kondisi tampilan berbeda, bukan cuma satu gambar statis. Default adalah tampilan normal saat tidak disentuh; hover muncul saat kursor mouse berada di atasnya; active muncul sepersekian detik saat benar-benar ditekan; disabled menandakan tombol sedang tidak bisa dipakai, misalnya sebelum form terisi lengkap; dan focus muncul ketika pengguna menavigasi pakai tombol Tab di keyboard, penting untuk aksesibilitas. Kalau kelima state ini tidak dirancang, pengguna kehilangan umpan balik penting tentang apa yang sedang terjadi.

Coba Sendiri: Uji Hukum Fitts pada Ukuran Tombol

"Lebar tombol" yang baru kita bedah menentukan seberapa mudah tombol itu disentuh. Ubah ukuran dan jarak target, lalu coba mini-game klik untuk merasakan sendiri Hukum Fitts.

Anatomi Kolom Isian (Input) & Kartu (Card)

INPUT FIELD

Label — nama data yang diminta ("Nomor HP")
Placeholder — contoh format, warna pudar
Border — berubah warna saat fokus/error
Helper text — petunjuk atau pesan galat di bawah kolom

CARD (KARTU PRODUK)

Thumbnail — gambar/foto produk
Judul & harga — informasi inti
Padding & shadow — jarak dalam & bayangan "mengambang"
Call-to-action — tombol kecil "Tambah ke Keranjang"

Perhatikan: setiap aplikasi belanja daring Indonesia — Tokopedia, Shopee, Blibli — memakai anatomi card yang nyaris identik, karena pola ini sudah terbukti paling mudah dipindai mata pengguna.

Setelah tombol, dua komponen lain yang paling sering Anda temui adalah kolom isian dan kartu. Pada kolom isian, label memberi tahu data apa yang diminta, placeholder menampilkan contoh format dengan warna pudar supaya tidak tertukar dengan isian sungguhan, border yang berubah warna memberi umpan balik saat kolom sedang difokus atau salah isi, dan helper text di bawahnya menjelaskan syarat atau pesan galat. Pada kartu produk, ada thumbnail sebagai gambar utama, judul dan harga sebagai informasi inti yang harus langsung terlihat, padding dan bayangan halus yang membuat kartu terasa mengambang dari latar, serta tombol aksi kecil di pojok. Menariknya, kalau Anda bandingkan Tokopedia, Shopee, dan Blibli, anatomi kartu produknya nyaris sama persis — ini bukan kebetulan, melainkan pola yang sudah teruji lewat riset pengguna bertahun-tahun.

Mengapa Konsistensi Komponen Penting?

SIGNIFIER

PETUNJUK VISUAL

Signifier adalah tanda yang memberi tahu pengguna "elemen ini bisa diklik" — misalnya warna solid, bayangan, atau garis bawah pada teks tautan.

AFFORDANCE

KEMUNGKINAN AKSI

Affordance adalah kemungkinan tindakan yang ditawarkan sebuah elemen. Tombol "ber-affordance" diklik; kolom teks "ber-affordance" diketik.

Kalau tombol beda-beda di tiap halaman (seperti skenario Slide 3), signifier-nya jadi tidak konsisten — pengguna harus belajar ulang pola visual setiap kali pindah halaman. Inilah alasan anatomi komponen harus distandarkan, bukan digambar ulang bebas.

Dua istilah ini sering tertukar, jadi mari kita luruskan. Signifier adalah petunjuk visual yang secara eksplisit memberi tahu pengguna bahwa sesuatu bisa dioperasikan — warna solid dan bayangan pada tombol adalah signifier bahwa itu bisa diklik, sedangkan garis bawah pada teks biasanya menandakan itu adalah tautan. Affordance adalah konsep yang lebih luas, yaitu kemungkinan tindakan yang sebenarnya ditawarkan oleh sebuah elemen, terlepas dari apakah pengguna menyadarinya atau tidak. Nah, kembali ke skenario startup tadi: kalau tombol "Beli Sekarang", "Checkout", dan "Simpan" semuanya terlihat berbeda, pengguna kehilangan sinyal yang konsisten tentang mana yang bisa diklik dan mana yang tidak, sehingga mereka harus berpikir ulang di setiap halaman. Inilah mengapa menstandarkan anatomi komponen bukan cuma soal estetika, tapi soal mengurangi beban kognitif pengguna.

Bagian 2 dari 3

Design System

Bagaimana ratusan komponen yang sudah kita bedah tadi dibungkus menjadi satu sistem aturan yang bisa dipakai seluruh tim, konsisten dari halaman pertama sampai halaman keseratus.

Design Token Component Library

Tiga Tingkat Kematangan Aturan Visual

DARI DOKUMEN STATIS SAMPAI SISTEM HIDUP

Design token (token desain) adalah nilai terkecil yang bisa dipakai ulang — misalnya --color-primary atau --spacing-md — fondasi dari ketiga tingkat di atas.

Diagram ini menunjukkan tiga tingkat kematangan yang biasanya dilalui sebuah tim desain. Paling dasar adalah style guide, biasanya berupa dokumen atau slide statis berisi daftar warna dan jenis font yang boleh dipakai — mirip pedoman merek. Naik satu tingkat, ada component library, yaitu kumpulan komponen siap pakai seperti tombol dan kolom input yang sudah dirancang dan bisa langsung diambil, biasanya dalam file Figma atau kode. Tingkat tertinggi adalah design system sesungguhnya: gabungan token desain, komponen, pola penggunaan, dokumentasi, dan yang terpenting, terhubung langsung ke kode produk sehingga menjadi satu sumber kebenaran tunggal bagi desainer maupun developer. Fondasi dari ketiganya adalah design token, nilai terkecil yang bisa dipakai berulang, misalnya nama variabel warna utama atau satuan jarak menengah, sehingga kalau warna brand berubah, cukup ubah satu token dan seluruh produk ikut berubah otomatis.

Hitung dari Nol: Skala Tipografi Modular

Design system butuh skala ukuran teks yang konsisten, bukan angka acak. Salah satu metode: kalikan ukuran dasar dengan rasio tetap (di sini 1,25 — dikenal sebagai "Major Third").

LANGKAH PERHITUNGAN (BASE 16PX × 1,25)

Langkah	Perhitungan	Nilai
Body text (dasar)	—	16px
H4	16 × 1,25	20px
H3	20 × 1,25	25px
H2	25 × 1,25	31px
H1	31 × 1,25	39px
Display	39 × 1,25	49px

HASIL: SKALA 6 TINGKAT

16→49px

6 ukuran, 1 rasio tetap

Semua desainer & developer memakai ukuran YANG SAMA — tidak ada lagi tebak-tebakan "judulnya 28px atau 30px ya?".

Sekarang kita buktikan dengan angka bagaimana design system menghasilkan skala tipografi yang konsisten. Kita mulai dari ukuran dasar teks isi, enam belas piksel — ini standar umum karena mudah dibaca di layar. Untuk mendapatkan ukuran judul level empat, kita kalikan enam belas dengan rasio satu koma dua lima, hasilnya dua puluh piksel. Ukuran ini kita kalikan lagi rasio yang sama untuk mendapatkan judul level tiga, menjadi dua puluh lima piksel. Begitu seterusnya berulang, sampai kita mendapatkan enam tingkat ukuran, dari enam belas piksel untuk teks isi sampai empat puluh sembilan piksel untuk judul display terbesar. Perhatikan bahwa saya membulatkan angka desimal supaya praktis dipakai developer. Manfaat metode ini adalah semua ukuran teks di seluruh aplikasi mengikuti hubungan matematis yang sama, sehingga terasa harmonis secara visual, dan tidak ada lagi perdebatan tim soal "judulnya dua puluh delapan piksel atau tiga puluh piksel" — jawabannya sudah ditentukan oleh rumus, bukan selera masing-masing orang.

Coba Sendiri: Susun Type Scale Anda Sendiri

Ubah ukuran dasar dan rasio skala, lalu amati bagaimana enam tingkat ukuran judul-ke-isi berubah otomatis.

Design System di Dunia Nyata

GLOBAL

MATERIAL DESIGN

Milik Google, dipakai di seluruh aplikasi Android. Dokumentasi publik lengkap dengan token warna, komponen, dan pedoman aksesibilitas.

GLOBAL

ANT DESIGN

Milik Alibaba, populer untuk dashboard & aplikasi bisnis (B2B). Banyak dipakai startup Indonesia karena open-source & siap pakai di kode React.

INDONESIA

DESIGN SYSTEM LOKAL

Tokopedia (internal), Gojek (Asphalt Design System), dan BCA mobile punya design system sendiri agar tampilan konsisten lintas ratusan fitur.

Titik temunya sama: satu sumber kebenaran untuk warna, tipografi, komponen, dan spasi — dipakai ribuan orang, jutaan pengguna, tanpa kehilangan konsistensi.

Supaya konsep ini tidak terasa abstrak, mari lihat contoh nyata. Material Design milik Google adalah salah satu design system paling terkenal di dunia, dipakai oleh hampir semua aplikasi Android dan didokumentasikan secara terbuka, sehingga bisa Anda pelajari sendiri di situs resminya. Ant Design dari Alibaba lebih fokus pada aplikasi bisnis dan dashboard, dan cukup populer di kalangan startup Indonesia karena sifatnya open-source dan langsung bisa dipasang di kode React. Di level lokal, Gojek punya design system bernama Asphalt yang menjaga konsistensi ratusan fitur dari pemesanan ojek sampai pembayaran GoPay, sementara Tokopedia dan BCA mobile juga punya sistem serupa secara internal. Yang penting Anda pahami, apa pun namanya, tujuannya sama: menjadi satu sumber kebenaran yang dipakai ribuan karyawan sekaligus, agar jutaan pengguna merasakan pengalaman yang konsisten setiap kali membuka aplikasi.

Bagian 3 dari 3

Grid Layout

Kerangka tak terlihat yang menata posisi setiap komponen di layar — kita akan menghitungnya sendiri dengan angka nyata, bukan menebak "kira-kira pas".

12 Kolom Gutter & Margin

Prinsip Grid 12-Kolom

TIGA KOMPONEN SEBUAH GRID

Standar industri untuk layar desktop: 12 kolom — mudah dibagi jadi 2, 3, 4, atau 6 blok yang rata.

Sebuah grid tersusun dari tiga komponen yang harus Anda kenali. Pertama, kolom, yaitu jalur vertikal tempat konten diletakkan — pada gambar ini ada dua belas kolom, standar yang paling umum dipakai industri karena angka dua belas bisa dibagi rata menjadi dua, tiga, empat, atau enam blok, sehingga sangat fleksibel untuk berbagai tata letak. Kedua, gutter, yaitu celah kosong di antara satu kolom dengan kolom berikutnya, fungsinya memberi jarak napas supaya konten tidak saling menempel. Ketiga, margin, yaitu jarak dari tepi kolom pertama dan terakhir ke tepi layar, memastikan konten tidak mepet ke pinggir. Mengapa dua belas kolom menjadi standar, bukan sepuluh atau lima belas? Karena fleksibilitas pembagiannya — bayangkan Anda ingin membuat tiga kartu produk sejajar, dua belas dibagi tiga sama dengan empat kolom per kartu, rapi tanpa sisa.

Hitung dari Nol: Lebar Satu Kolom Grid

Kanvas desktop lebar 1.280px, margin kiri-kanan masing-masing 64px, gutter 24px, grid 12 kolom (berarti 11 celah gutter di antaranya). Berapa lebar satu kolom?

LANGKAH PERHITUNGAN

Langkah	Perhitungan	Nilai
Lebar kanvas	—	1.280px
Area konten (kurangi 2 margin)	1.280 − (2 × 64)	1.152px
Total lebar 11 gutter	11 × 24	264px
Sisa untuk 12 kolom	1.152 − 264	888px
Lebar 1 kolom	888 ÷ 12	74px

HASIL AKHIR

74px

lebar 1 kolom grid

Kartu produk yang "melebar 4 kolom" berarti: (4×74) + (3×24 gutter di dalamnya) = 368px — angka pasti, bukan perkiraan mata.

Sekarang giliran Anda melihat bagaimana angka grid dihitung, langkah demi langkah, bukan ditebak. Kita mulai dari lebar kanvas desktop, seribu dua ratus delapan puluh piksel, ukuran umum untuk laptop standar. Karena ada margin di kiri dan kanan sebesar enam puluh empat piksel masing-masing, kita kurangi dua kali enam puluh empat dari kanvas, tersisa seribu seratus lima puluh dua piksel sebagai area konten. Dari area ini, kita masih harus menyisihkan ruang untuk sebelas celah gutter di antara dua belas kolom — sebelas dikali dua puluh empat sama dengan dua ratus enam puluh empat piksel. Setelah dikurangi, tersisa delapan ratus delapan puluh delapan piksel murni untuk dua belas kolom, dan ketika dibagi rata, satu kolom lebarnya tepat tujuh puluh empat piksel. Angka ini bukan sekadar latihan matematika — begitu Anda tahu satu kolom sama dengan tujuh puluh empat piksel, Anda bisa menghitung lebar kartu produk yang melebar empat kolom secara pasti, seperti yang saya tunjukkan di kartu hasil. Inilah bedanya desainer yang bekerja presisi dengan yang hanya menggeser-geser elemen sampai "kelihatan pas".

Coba Sendiri: Hitung Lebar Kolom Grid Anda Sendiri

Ubah lebar kanvas, margin, dan gutter, lalu amati bagaimana lebar satu kolom grid 12-kolom berubah.

Grid yang Berubah Sesuai Ukuran Layar

Jumlah kolom TIDAK selalu 12 — pada layar sempit, kolom dikurangi agar konten tetap terbaca (responsive breakpoint — titik ukuran layar tempat tata letak berubah).

MOBILE

4 kolom

< 480px (ponsel)

Gutter & margin diperkecil (~16px) agar layar sempit tak terlalu padat.

TABLET

8 kolom

481–1024px

Cukup ruang untuk 2 kartu produk sejajar, gutter ~20px.

DESKTOP

12 kolom

> 1024px

Grid penuh seperti dihitung di Slide 15, gutter 24px.

Angka-angka breakpoint di atas bersifat konvensi umum industri (bisa disesuaikan per proyek) — ~ menandai perkiraan yang lazim dipakai, bukan aturan baku tunggal.

Satu hal yang perlu Anda sadari: grid dua belas kolom yang tadi kita hitung hanya berlaku untuk layar desktop yang lebar. Ketika pengguna membuka aplikasi yang sama di ponsel, dua belas kolom yang sama akan membuat setiap kolom terlalu sempit untuk dibaca, sehingga desainer mengubah jumlah kolomnya di titik ukuran tertentu yang disebut breakpoint. Pada layar ponsel di bawah empat ratus delapan puluh piksel, grid biasanya disederhanakan jadi empat kolom saja, dengan gutter dan margin yang juga diperkecil supaya konten tidak terlalu padat. Pada tablet, ukurannya di antara empat ratus delapan puluh satu sampai seribu dua puluh empat piksel, grid biasanya delapan kolom, cukup untuk menampilkan dua kartu produk berdampingan. Baru pada layar desktop di atas seribu dua puluh empat piksel, grid penuh dua belas kolom seperti yang kita hitung tadi. Perhatikan saya memberi tanda kira-kira pada angka-angka ini, karena breakpoint bukan standar tunggal yang wajib — setiap perusahaan bisa menyesuaikan sedikit sesuai kebutuhan produknya.

Studi Kasus: Konsistensi di Aplikasi Indonesia

BCA MOBILE — GRID & KOMPONEN

Grid konsisten dari halaman saldo, transfer, sampai top-up pulsa
Tombol utama SELALU biru solid di posisi bawah layar
Kartu rekening pakai anatomi & radius sudut yang sama di semua fitur

TOKOPEDIA — DESIGN SYSTEM "BUNGA"

Design token warna & tipografi terdokumentasi untuk ratusan fitur
Kartu produk (Slide 7) memakai anatomi identik di semua kategori
Grid responsif: 12 kolom desktop → 4 kolom mobile otomatis

Konsistensi ini bukan kebetulan — hasil dari tim desain yang disiplin menerapkan anatomi komponen, design token, dan grid yang sudah kita pelajari hari ini.

Mari kita tutup materi inti dengan menghubungkan semua yang sudah kita pelajari ke aplikasi yang mungkin ada di ponsel Anda sekarang. Coba buka BCA mobile: perhatikan bagaimana tombol aksi utama selalu berwarna biru solid dan selalu diletakkan di posisi bawah layar, di halaman apa pun Anda berada — itu bukti anatomi komponen dan grid yang konsisten. Begitu juga Tokopedia, yang punya design system internal bernama Bunga; setiap kartu produk, dari kategori elektronik sampai fesyen, memakai anatomi kartu yang identik, dan grid-nya otomatis menyesuaikan dari dua belas kolom di desktop menjadi empat kolom di ponsel Anda. Ini semua bukan kebetulan atau keberuntungan, melainkan hasil kerja disiplin tim desain yang menerapkan tiga hal yang kita pelajari hari ini: anatomi komponen yang jelas, design token yang terdokumentasi, dan grid yang terukur presisi.

Latihan Kelas: Audit Mini Aplikasi

Instruksi (15 menit, berpasangan):

Pilih 1 aplikasi di ponsel Anda (Tokopedia, Gojek, BCA mobile, dll).
Screenshot 1 tombol utama — identifikasi 4 elemen anatominya (radius, lebar, padding, label/ikon).
Amati kartu produk/daftar — hitung perkiraan berapa kolom grid yang dipakai di layar Anda.
Catat 1 contoh INKONSISTENSI (jika ada) — beri saran perbaikan singkat.

Siapkan hasilnya untuk dibahas 5 menit terakhir kelas — beberapa pasangan akan diminta presentasi singkat.

Sekarang giliran Anda praktik langsung, dan saya sengaja membuat latihan ini singkat agar bisa langsung kita bahas bersama. Kerjakan berpasangan dengan teman sebangku. Pertama, pilih satu aplikasi apa saja di ponsel Anda yang sering dipakai. Kedua, ambil tangkapan layar satu tombol utama, lalu identifikasi empat elemen anatominya seperti yang kita bahas di Slide 6 — sudut, lebar, padding, dan labelnya. Ketiga, amati halaman yang menampilkan daftar atau kartu produk, lalu perkirakan berapa kolom grid yang sedang dipakai berdasarkan jumlah kartu yang sejajar. Keempat, dan ini bagian favorit saya, coba temukan satu contoh inkonsistensi kecil — mungkin ada tombol yang bentuknya sedikit berbeda dari tombol lain — lalu beri saran perbaikan singkat ala konsultan UX. Saya akan berkeliling membantu jika Anda kesulitan, dan beberapa pasangan akan saya minta presentasi singkat di lima menit terakhir.

Ringkasan Pertemuan 9

ANATOMI & SISTEM

Komponen = unit UI berulang (button, input, card)
5 state: default, hover, active, disabled, focus
Design system = token + komponen + pola + dokumentasi

GRID LAYOUT

Grid = kolom + gutter + margin
12 kolom desktop, lebar kolom bisa DIHITUNG persis
Breakpoint mengubah jumlah kolom per ukuran layar

Benang merah: anatomi komponen, design system, dan grid layout adalah tiga alat yang membuat rancangan UI Anda TERUKUR — bukan lagi "kira-kira", tapi presisi dan bisa dikomunikasikan ke developer.

Mari kita ringkas perjalanan hari ini. Kita mulai dari anatomi komponen, membedah tombol menjadi bagian-bagian kecilnya dan mengenal lima kondisi tampilan yang wajib dirancang. Lalu kita naik satu level ke design system, memahami bagaimana token desain, komponen, dan dokumentasi digabung menjadi satu sumber kebenaran yang dipakai seluruh tim, dengan contoh nyata dari Google, Alibaba, sampai Gojek dan Tokopedia. Terakhir kita masuk ke grid layout, di mana Anda sendiri sudah membuktikan dengan tangan bahwa lebar satu kolom grid desktop standar adalah tujuh puluh empat piksel — bukan angka tebakan, melainkan hasil perhitungan matematis sederhana. Benang merah dari ketiga topik ini adalah presisi: seorang desainer UI profesional tidak bekerja dengan perasaan "kira-kira sudah pas", melainkan dengan angka dan aturan yang bisa dikomunikasikan jelas ke developer.

Menuju Pertemuan Berikutnya

Anatomi + Design System + Grid = Fondasi Mockup High-Fidelity

Pertemuan 10: kita akan memakai ketiga fondasi hari ini untuk merancang mockup high-fidelity (rancangan visual detail, mendekati tampilan final) di Figma — anatomi komponen jadi elemen nyata, design system jadi acuan warna & font, grid jadi kerangka penempatan.

Bawa hasil audit mini Anda (Slide 18) — kita akan pakai sebagai bahan diskusi pembuka pertemuan berikutnya.

Sebagai penutup, saya ingin Anda melihat bagaimana tiga topik hari ini bukan pengetahuan yang berdiri sendiri, melainkan fondasi langsung untuk pertemuan berikutnya. Minggu depan kita akan masuk ke mockup high-fidelity, yaitu rancangan visual detail yang sudah sangat mendekati tampilan final aplikasi, dikerjakan di Figma. Di sana, anatomi komponen yang kita pelajari hari ini akan menjadi elemen-elemen nyata yang Anda susun, design system akan menjadi acuan warna dan font yang konsisten, dan grid layout akan menjadi kerangka tak terlihat yang menuntun penempatan setiap elemen. Tolong simpan hasil audit mini aplikasi yang Anda kerjakan tadi, karena kita akan memakainya sebagai bahan diskusi pembuka di pertemuan berikutnya. Sampai jumpa minggu depan, dan selamat mencoba mengamati aplikasi favorit Anda dengan mata seorang desainer UI.