Program Studi Bisnis Digital • FEB UNDIP

Desain UI & UX

Pertemuan 14 — Iterasi Desain Berbasis Feedback dan Persiapan Presentasi Proyek Akhir

Menutup usability testing minggu lalu dengan mengubah temuan menjadi perbaikan nyata, lalu menyusun presentasi proyek akhir yang meyakinkan dosen dan calon pengguna.

RPS MINGGU 15 • 2×50 MENIT

Selamat datang di pertemuan terakhir sebelum presentasi akhir, Anda semua sudah melewati perjalanan panjang — dari riset pengguna, wireframe, mockup, sampai usability testing minggu lalu. Hari ini kita akan menutup lingkaran itu: bagaimana mengubah catatan hasil testing yang menumpuk menjadi keputusan desain yang jelas dan bisa dieksekusi. Bayangkan Anda baru saja mengetes prototipe aplikasi UMKM seperti Tokopedia Seller versi mini, dan tiga dari lima peserta bingung mencari tombol "Tambah Produk" — pertanyaannya bukan sekadar "apa yang salah", tapi "apa yang kita perbaiki dulu, dan bagaimana kita membuktikan ke dosen bahwa keputusan itu berdasar data, bukan tebakan". Paruh kedua pertemuan ini kita pakai untuk menyiapkan presentasi proyek akhir Anda — struktur cerita, apa yang dinilai, dan bagaimana menunjukkan proses desain Anda secara meyakinkan. Siapkan catatan hasil usability testing kelompok Anda, karena kita akan langsung mempraktikkan cara mengolahnya hari ini.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu mengolah hasil usability testing menjadi iterasi desain terprioritas, dan menyusun presentasi proyek akhir yang solid. Secara rinci:

SISI ITERASI

Mengolah temuan usability testing jadi daftar masalah yang jelas
Memprioritaskan perbaikan dengan matriks Impact-Effort
Menerapkan siklus Build-Measure-Learn pada iterasi kedua

SISI PRESENTASI

Menyusun struktur cerita presentasi proyek akhir yang runtut
Memahami rubrik penilaian yang dipakai dosen
Berlatih menyampaikan before/after desain secara meyakinkan

Bagian 1 dari 4

Dari Catatan Testing ke Daftar Masalah

Mengapa hasil usability testing sering "hilang begitu saja" tanpa proses yang benar — dan bagaimana merapikannya.

Mengapa Iterasi Itu Bukan Opsional

Desain UI/UX bersifat siklikal, bukan garis lurus. Usability testing tanpa tindak lanjut = riset yang sia-sia.

Tanpa iterasi: tim menganggap desain "sudah jadi" setelah satu kali mockup high-fidelity, lalu kaget saat pengguna nyata bingung memakainya — seperti aplikasi yang diluncurkan lalu langsung dapat rating 2 bintang di Play Store karena navigasi membingungkan.

Dengan iterasi: setiap temuan testing diolah, diprioritaskan, diperbaiki, lalu (idealnya) diuji ulang. Produk digital besar seperti aplikasi Gojek atau Shopee melalui ratusan siklus kecil seperti ini setiap tahun.

Riset → Desain → Uji → Iterasi → Uji lagi

Merapikan Temuan: Affinity Mapping

Kumpulkan semua catatan observer, lalu kelompokkan isu yang mirip menjadi satu tema — teknik yang sama dengan affinity map yang pernah kita pakai untuk riset pengguna.

Menilai Tingkat Keparahan (Severity)

Tidak semua masalah usability sama beratnya. Beri skala keparahan 0–4 (adaptasi skala Nielsen) sebelum memutuskan mana yang diperbaiki dulu.

Skala	Arti	Contoh
0	Bukan masalah usability	Preferensi warna pribadi peserta
1	Kosmetik, perbaiki jika sempat	Ikon sedikit tidak sejajar
2	Minor, prioritas rendah	Label tombol kurang jelas tapi bisa ditebak
3	Major, prioritas tinggi	Peserta gagal menyelesaikan checkout tanpa bantuan
4	Catastrophic, wajib diperbaiki	Aplikasi crash saat submit pembayaran

Skala ini penting supaya tim tidak menghabiskan waktu memperbaiki hal-hal kecil sementara masalah besar dibiarkan. Perhatikan contohnya: kalau di aplikasi seperti Shopee ada peserta yang menyebut ikonnya "kurang cantik", itu skala satu — kosmetik, bukan darurat. Tapi kalau peserta sampai gagal menyelesaikan proses checkout dan menyerah tanpa bantuan fasilitator, itu skala tiga, harus jadi prioritas tinggi karena langsung mengancam konversi penjualan. Skala empat, yang paling gawat, biasanya berupa error teknis seperti aplikasi crash — kalau ini terjadi di dunia nyata pada aplikasi pembayaran seperti GoPay, dampaknya bisa berupa kehilangan kepercayaan pengguna secara masif. Saat kelompok Anda mengolah catatan testing minggu lalu, cobalah beri angka skala ini pada setiap temuan sebelum lanjut ke langkah prioritas berikutnya.

Memprioritaskan Perbaikan: Matriks Impact-Effort

Sama seperti saat kita memilih ide dari sesi ideasi, gunakan kembali Impact-Effort Matrix — kali ini untuk memilih perbaikan mana yang dikerjakan lebih dulu.

Anda sudah pernah memakai matriks ini di pertemuan lima saat memilih ide dari sesi Crazy 8's — sekarang kita pakai logika yang sama untuk memilih perbaikan hasil testing. Sumbu vertikal adalah seberapa besar dampaknya bagi pengalaman pengguna, sumbu horizontal seberapa besar usaha tim untuk mengerjakannya. Perbaikan seperti memperbesar ukuran font atau memperjelas label tombol biasanya masuk kuadran "quick win" — dampaknya terasa tapi effort-nya kecil, jadi kerjakan lebih dulu. Sebaliknya, merombak total alur checkout aplikasi e-commerce butuh waktu desain ulang dan pengujian lagi, jadi masuk kuadran proyek besar yang perlu direncanakan terpisah, mungkin di luar cakupan tugas akhir semester ini. Dengan waktu terbatas menjelang presentasi akhir, kelompok Anda sebaiknya fokus mengeksekusi kuadran quick win terlebih dahulu supaya ada bukti perbaikan nyata yang bisa ditunjukkan.

Hitung dari Nol: Skor Prioritas Perbaikan

Kelompok mencatat 5 temuan testing pada prototipe aplikasi UMKM. Hitung skor prioritas = Severity (0–4) × Frekuensi (jumlah peserta yang mengalami, dari 5).

Langkah	Perhitungan	Nilai
1. Temuan A — tombol "Tambah Produk" tak terlihat	Severity 3 × Frekuensi 4	12
2. Temuan B — font harga terlalu kecil	Severity 2 × Frekuensi 5	10
3. Temuan C — ikon keranjang tertukar dengan wishlist	Severity 3 × Frekuensi 3	9
4. Temuan D — warna status pesanan ambigu	Severity 2 × Frekuensi 2	4
5. Temuan E — spasi antar-kartu produk kurang rapi	Severity 1 × Frekuensi 1	1

PRIORITAS UTAMA

Temuan A

Skor 12 — tertinggi, perbaiki lebih dulu

Mari kita hitung bersama. Skor prioritas sederhana ini mengalikan tingkat keparahan dengan jumlah peserta yang mengalami masalah tersebut, sehingga kita punya angka objektif, bukan sekadar perasaan tim. Temuan A, tombol "Tambah Produk" yang tak terlihat pada prototipe aplikasi mirip Tokopedia Seller, punya severity 3 dan dialami 4 dari 5 peserta, jadi skornya 3 dikali 4 sama dengan 12 — tertinggi di antara semua temuan. Bandingkan dengan temuan E, soal spasi antar-kartu produk yang kurang rapi, yang hanya severity 1 dan dialami 1 peserta saja, skornya cuma 1. Dengan cara menghitung seperti ini, kelompok Anda punya alasan yang bisa dipertanggungjawabkan ketika dosen bertanya "kenapa kalian memperbaiki ini duluan" — jawabannya bukan "menurut kami", tapi "berdasarkan skor prioritas dari data testing".

Bagian 2 dari 4

Menjalankan Iterasi: Build-Measure-Learn

Dari daftar prioritas ke perubahan desain yang benar-benar dieksekusi.

Siklus Build-Measure-Learn

Kerangka dari metodologi Lean Startup ini cocok untuk iterasi cepat menjelang tenggat proyek akhir.

Siklus ini punya tiga tahap sederhana yang berulang. Build berarti benar-benar mengubah mockup di Figma sesuai daftar prioritas yang sudah Anda hitung tadi — misalnya membesarkan tombol "Tambah Produk" dan memindahkannya ke posisi yang lebih terlihat. Measure berarti menguji ulang perubahan itu, tidak perlu lima peserta lagi seperti testing formal, cukup dua atau tiga orang teman sekelas atau tetangga kos untuk validasi cepat. Learn berarti menyimpulkan apakah masalah tadi benar-benar hilang atau justru muncul masalah baru — kadang perbaikan di satu tempat memunculkan kebingungan di tempat lain, ini hal yang wajar dalam desain. Untuk proyek akhir dengan waktu terbatas, Anda tidak perlu menjalankan siklus ini berkali-kali sampai sempurna — cukup satu putaran penuh yang terdokumentasi dengan baik sudah menunjukkan pemahaman Anda tentang proses iteratif.

Mendokumentasikan Before & After

Presentasi minggu depan akan jauh lebih meyakinkan kalau Anda bisa menunjukkan perubahan konkret, bukan cuma mengatakan "kami sudah memperbaiki".

SIMPAN VERSI LAMA

Screenshot mockup sebelum diubah, beri label jelas "v1" atau tanggal testing.

CATAT ALASAN

Hubungkan setiap perubahan ke temuan spesifik — "tombol diperbesar karena 4/5 peserta tak melihatnya".

SIMPAN VERSI BARU

Screenshot mockup setelah diubah, letakkan berdampingan dengan versi lama.

Latihan Kelompok: Olah Temuan Anda Sendiri

Waktu: 15 menit. Gunakan catatan usability testing kelompok Anda dari pertemuan minggu lalu.

INSTRUKSI

Kelompokkan temuan mentah menjadi 3–5 tema (affinity mapping)
Beri skala severity 0–4 pada tiap temuan
Hitung skor prioritas (severity × frekuensi) untuk 3 temuan teratas
Tentukan 1 perbaikan "quick win" yang akan dieksekusi minggu ini

Fasilitator akan berkeliling — siapkan pertanyaan bila skala severity terasa ambigu.

Bagian 3 dari 4

Menyusun Presentasi Proyek Akhir

Struktur cerita, rubrik penilaian, dan cara menyampaikan proses desain secara meyakinkan.

Apa yang Dinilai dalam Presentasi Proyek Akhir

Memahami rubrik membantu Anda mengalokasikan waktu presentasi dengan tepat, bukan hanya memamerkan tampilan visual.

Komponen	Yang Dicari Dosen	Bobot (ilustrasi)
Proses riset & empati pengguna	Persona, journey map, insight riset dipakai nyata	~25%
Kualitas desain visual	Konsistensi, hierarki, keterbacaan, Design System	~25%
Bukti usability testing & iterasi	Before/after, alasan perbaikan berbasis data	~30%
Kejelasan presentasi	Struktur cerita, kekompakan tim, menjawab pertanyaan	~20%

Bobot bersifat ilustrasi umum — selalu cek rubrik resmi yang dibagikan dosen pengampu untuk angka pasti.

Perhatikan bahwa bukti usability testing dan iterasi punya porsi terbesar dalam ilustrasi rubrik ini, sekitar tiga puluh persen — ini menegaskan mengapa pertemuan hari ini begitu penting. Banyak kelompok menghabiskan waktu presentasi hanya memamerkan tampilan visual yang indah, padahal itu cuma seperempat dari penilaian. Sebaliknya, kelompok yang bisa menunjukkan "kami awalnya mendesain begini, ternyata pengguna bingung di titik ini, lalu kami ubah menjadi begini dan hasilnya membaik" biasanya mendapat apresiasi lebih tinggi, karena itu bukti nyata proses berpikir yang dipelajari sepanjang semester. Saya tekankan sekali lagi, angka persentase di tabel ini adalah ilustrasi umum saja untuk membantu Anda mengalokasikan waktu — rubrik resmi dengan bobot pasti akan dibagikan terpisah oleh dosen pengampu mata kuliah ini.

Struktur Cerita: Enam Babak

Susun presentasi sebagai cerita, bukan katalog slide acak — ikuti alur logis dari masalah ke solusi.

1–2

Masalah & Riset
Siapa pengguna, apa masalahnya, bukti dari wawancara/persona

3–4

Solusi Desain
Wireframe ke high-fidelity, Design System, alasan keputusan visual

5–6

Bukti & Rencana
Hasil testing, iterasi before/after, langkah lanjutan produk

Pikirkan presentasi Anda seperti enam babak cerita pendek, bukan sekadar urutan slide yang mengikuti kronologi tugas mingguan. Babak pertama dan kedua menjawab pertanyaan "untuk siapa produk ini dan masalah apa yang kita selesaikan" — tunjukkan persona dan insight riset paling kuat, jangan menampilkan semua data mentah. Babak ketiga dan keempat menunjukkan bagaimana solusi desain menjawab masalah itu, lengkap dengan alasan di balik pilihan warna, tipografi, atau komponen Design System yang dipakai. Babak kelima dan keenam, yang sering diabaikan kelompok lain, adalah bukti bahwa desain itu benar-benar diuji dan disempurnakan, ditutup dengan rencana lanjutan jika produk ini benar-benar dikembangkan — misalnya fitur apa yang akan ditambahkan berikutnya, mirip roadmap produk di startup sungguhan.

Hitung dari Nol: Alokasi Waktu Presentasi 10 Menit

Kelompok mendapat slot presentasi 10 menit plus tanya-jawab. Bagi waktu proporsional mengikuti enam babak cerita.

Langkah	Perhitungan	Nilai
1. Total waktu presentasi	Slot yang diberikan	10 menit
2. Masalah & Riset (20% dari total)	20% × 10 menit	2 menit
3. Solusi Desain (35% dari total)	35% × 10 menit	3,5 menit
4. Bukti Testing & Iterasi (35% dari total)	35% × 10 menit	3,5 menit
5. Penutup & Rencana Lanjutan (10% dari total)	10% × 10 menit	1 menit

TOTAL PENGECEKAN

2 + 3,5 + 3,5 + 1

= 10 menit — pas dengan slot yang diberikan

Mari kita hitung alokasi waktu supaya presentasi kelompok Anda tidak melebar ke satu bagian saja. Dengan slot sepuluh menit, bagian masalah dan riset cukup dua menit sebab dosen sudah cukup familiar dengan tahap awal proyek Anda dari tugas-tugas sebelumnya, dua puluh persen dikali sepuluh menit sama dengan dua menit. Bagian solusi desain dan bagian bukti testing dengan iterasi masing-masing mendapat porsi terbesar, tiga puluh lima persen dikali sepuluh menit sama dengan tiga koma lima menit, karena inilah inti yang paling ingin dilihat dosen sesuai rubrik tadi. Sisanya, sepuluh persen atau satu menit, untuk penutup dan rencana lanjutan. Kalau kita jumlahkan kembali, dua tambah tiga koma lima tambah tiga koma lima tambah satu, hasilnya tepat sepuluh menit — cocok dengan slot yang diberikan. Latihan dengan stopwatch sungguhan sebelum hari presentasi supaya alokasi ini benar-benar tercapai, bukan hanya rencana di atas kertas.

Kesalahan Umum yang Menurunkan Nilai

Hindari jebakan ini — semuanya sering terjadi pada kelompok mahasiswa tahun-tahun sebelumnya.

Membaca slide kata per kata alih-alih menjelaskan dengan bahasa sendiri seperti presentasi pitching startup di depan investor.

Menampilkan puluhan screenshot mockup tanpa penjelasan alasan desain di baliknya.

Tidak menyebut satu pun temuan usability testing — seolah desain langsung sempurna sejak awal.

Anggota kelompok tidak kompak; hanya satu orang bicara sementara yang lain diam saat ditanya.

Empat jebakan ini konsisten muncul dari pengalaman menilai presentasi mahasiswa tahun-tahun sebelumnya, jadi pelajari baik-baik. Membaca slide kata demi kata membuat presentasi terasa kaku dan monoton — bayangkan bedanya dengan founder startup yang melakukan pitching ke investor Shark Tank Indonesia, mereka bercerita dengan percaya diri, bukan membacakan teks. Menumpuk screenshot tanpa penjelasan membuat dosen bertanya-tanya "kenapa desainnya begini", padahal itu justru kesempatan Anda menunjukkan pemikiran desain yang matang. Tidak menyebut temuan usability testing sama sekali adalah kesalahan paling fatal karena seolah-olah proyek Anda tidak pernah diuji ke pengguna nyata — padahal bukti pengujian itulah yang membedakan proyek akademik yang matang dari sekadar tugas menggambar mockup. Terakhir, pastikan semua anggota kelompok siap menjawab pertanyaan, karena dosen sering sengaja bertanya ke anggota yang diam untuk memastikan pembagian kerja benar-benar merata.

Bagian 4 dari 4

Latihan & Persiapan Akhir

Simulasi singkat dan checklist terakhir sebelum hari presentasi.

Simulasi Mini: 3 Menit per Kelompok

Latihan menyampaikan ringkasan proyek dalam waktu singkat — versi padat dari presentasi 10 menit minggu depan.

INSTRUKSI SIMULASI

Satu perwakilan kelompok maju, waktu ketat 3 menit (gunakan stopwatch)
Wajib sebut: masalah pengguna, 1 solusi kunci, 1 bukti hasil testing
Kelompok lain memberi 1 masukan singkat setelah tiap sesi
Fasilitator mencatat poin yang perlu diperkuat sebelum presentasi asli

Rangkuman & Menuju Presentasi Akhir

RINGKASAN HARI INI

Rapikan temuan testing dengan affinity mapping & skala severity
Prioritaskan dengan skor severity × frekuensi dan Impact-Effort Matrix
Jalankan iterasi lewat siklus Build-Measure-Learn
Susun presentasi sebagai cerita 6 babak, dokumentasikan before/after

TUGAS SEBELUM PRESENTASI

Selesaikan minimal 1 iterasi "quick win" beserta dokumentasi before/after
Susun slide presentasi mengikuti struktur 6 babak
Latihan waktu dengan stopwatch, target tepat 10 menit
Pastikan seluruh anggota kelompok siap menjawab pertanyaan

Selamat menyelesaikan proyek akhir — perjalanan Anda sejak riset pengguna hingga hari ini adalah bukti nyata proses desain yang matang.

Kita telah sampai di penghujung materi mata kuliah Desain UI dan UX semester ini. Hari ini Anda belajar bahwa desain yang baik tidak pernah selesai sekali jadi, melainkan melalui proses merapikan temuan, memprioritaskan perbaikan dengan data, mengeksekusi iterasi, lalu mengomunikasikannya secara meyakinkan. Sebelum presentasi minggu depan, pastikan kelompok Anda menyelesaikan keempat tugas di kartu sebelah kanan ini — terutama dokumentasi before/after, karena itulah bukti paling kuat dari kerja keras Anda sepanjang semester. Saya bangga melihat perjalanan Anda semua dari pertemuan pertama yang membahas dasar UI dan UX, sampai hari ini Anda sudah mampu berpikir dan bekerja seperti tim desain produk sungguhan di industri seperti Tokopedia, Gojek, atau startup rintisan sekalipun. Sampai bertemu di hari presentasi akhir — siapkan diri Anda sebaik mungkin.