Program Studi Bisnis Digital • FEB UNDIP • Desain UI & UX

Arsitektur Informasi & Alur Pengguna

Pertemuan 6 — Sitemap dan Diagram User Flow

Bagaimana kita menyusun peta struktur produk digital dan menggambar jalur langkah demi langkah yang dilalui pengguna, sebelum satu piksel wireframe pun digambar.

RPS MINGGU 6 • 2 × 50 MENIT

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu merancang arsitektur informasi produk digital melalui sitemap dan diagram alur pengguna (Sub-CPMK minggu 6). Secara rinci:

CAPAIAN 1

KONSEP

Menjelaskan definisi dan fungsi arsitektur informasi (information architecture) dalam proses UX.

CAPAIAN 2

SITEMAP

Menyusun sitemap (peta situs) sederhana untuk produk digital dengan hierarki yang jelas.

CAPAIAN 3

USER FLOW

Menggambar diagram user flow (alur pengguna) dengan notasi standar untuk satu tugas spesifik.

CAPAIAN 4

VALIDASI

Menjelaskan metode card sorting (pengurutan kartu) untuk memvalidasi struktur yang dirancang.

Mengapa Struktur yang Buruk Membuat Pengguna Kabur?

Bayangkan sebuah aplikasi UMKM fesyen lokal baru diluncurkan. Dalam minggu pertama, tim menerima tiga keluhan yang persis sama dari pengguna berbeda:

KELUHAN 1

TERSESAT

"Saya sudah 4 kali tap tapi belum ketemu menu ukuran baju."

KELUHAN 2

BINGUNG

"Tombol 'Checkout' dan 'Simpan ke Wishlist' letaknya terlalu mirip."

KELUHAN 3

BATAL BELI

"Sudah isi alamat, tiba-tiba diminta login lagi. Saya keluar aplikasi."

Akar masalah dari ketiganya sama: tidak ada peta struktur dan jalur pengguna yang dirancang sejak awal. Inilah yang akan kita perbaiki hari ini — dengan sitemap dan user flow, bukan tebak-tebakan setelah peluncuran.

Kasus ini sengaja saya buat realistis karena hampir selalu terjadi pada produk digital yang terburu-buru meloncat ke tahap desain visual tanpa merancang struktur lebih dulu. Keluhan pertama soal navigasi yang terlalu dalam adalah masalah arsitektur informasi. Keluhan kedua soal dua tombol penting yang mirip adalah masalah hierarki visual, akibat struktur yang tidak jelas. Keluhan ketiga, pengguna keluar aplikasi karena diminta login mendadak di tengah proses checkout, adalah kegagalan merancang user flow — seharusnya titik keputusan seperti "harus login atau tidak" sudah dipetakan sejak awal, bukan mengejutkan pengguna di tengah jalan. Ketiga masalah ini semuanya bisa dicegah kalau tim desain menyusun sitemap dan user flow sebelum membuat satu pun tampilan layar, dan itulah dua alat yang akan kita kuasai hari ini.

Bagian 1 dari 3

Fondasi Arsitektur Informasi

Apa itu arsitektur informasi, bagaimana skema pengelompokan konten disusun, dan pola-pola struktur navigasi yang umum dipakai.

Information Architecture Sitemap

Apa Itu Arsitektur Informasi (Information Architecture)?

Cara kita menyusun dan melabeli konten agar mudah ditemukan dan dipahami — the way we arrange the parts of something to make it understandable (Richard Saul Wurman).

ANALOGI DUNIA NYATA

RAK TOKO

Seperti rak di Indomaret: makanan ringan di satu lorong, minuman di lorong lain, masing-masing punya label rak yang jelas. Anda tidak perlu bertanya ke kasir untuk menemukan barang.

DI PRODUK DIGITAL

MENU & LABEL

Kategori produk, urutan menu, dan nama tombol di aplikasi adalah "rak" dan "label" versi digital — menentukan apakah pengguna cepat menemukan yang dicari.

Arsitektur informasi = kerangka tak terlihat di balik setiap aplikasi yang terasa "gampang dipakai". Sitemap dan user flow adalah dua cara utama kita menggambarkan kerangka itu di atas kertas.

Definisi klasik dari Richard Saul Wurman, salah satu pendiri disiplin ini, menyebut arsitektur informasi sebagai cara kita menyusun bagian-bagian sesuatu agar mudah dipahami. Analogi paling mudah adalah rak minimarket seperti Indomaret atau Alfamart: makanan ringan, minuman, dan alat mandi masing-masing punya lorong dan label sendiri, sehingga Anda bisa menemukan barang tanpa bertanya ke kasir. Di produk digital, "rak" itu berubah menjadi menu, kategori, dan label tombol. Kalau arsitekturnya buruk, pengguna akan merasa seperti masuk minimarket tanpa label rak sama sekali — bingung, lelah, dan akhirnya pergi. Sitemap dan user flow, yang akan kita pelajari sepanjang pertemuan ini, adalah dua cara konkret menggambarkan arsitektur informasi itu di atas kertas sebelum kita mendesain tampilan visualnya.

Skema Mengelompokkan Konten

Menurut Rosenfeld & Morville, ada dua jenis skema pengelompokan konten: eksak (pasti, tidak ambigu) dan ambigu (butuh penilaian/interpretasi).

SKEMA EKSAK

Alfabetis — daftar kontak HP, indeks buku
Kronologis — riwayat transaksi GoPay, linimasa berita
Geografis — cabang bank terdekat di Maps, kurir per kota

SKEMA AMBIGU

Berdasarkan topik — kategori "Elektronik" di Tokopedia
Berdasarkan tugas — menu "Bayar", "Transfer" di BCA mobile
Berdasarkan audiens — "Untuk Penjual" vs "Untuk Pembeli"

Kebanyakan aplikasi Indonesia mengombinasikan keduanya: menu utama berdasarkan tugas/topik (ambigu), tapi riwayat & daftar di dalamnya kronologis atau alfabetis (eksak).

Rosenfeld dan Morville, dalam buku klasik mereka tentang arsitektur informasi, membagi skema pengelompokan menjadi dua kelompok besar. Skema eksak itu pasti dan tidak butuh penilaian subjektif — kalau Anda mengurutkan kontak di ponsel secara alfabetis, semua orang akan sepakat urutannya sama. Riwayat transaksi GoPay yang disusun kronologis, atau daftar cabang bank terdekat yang disusun geografis di Google Maps, adalah contoh lain skema eksak. Sebaliknya, skema ambigu membutuhkan penilaian — mengapa "sepatu" masuk kategori "Fashion" dan bukan "Olahraga" di Tokopedia adalah keputusan desain, bukan fakta objektif. Coba amati aplikasi BCA mobile di ponsel Anda: menu utamanya seperti "Transfer", "Bayar", "Buka Rekening" itu dikelompokkan berdasarkan tugas, sebuah skema ambigu, sementara riwayat mutasi di dalamnya disusun kronologis, sebuah skema eksak. Kombinasi keduanya inilah yang akan kita pakai saat menyusun sitemap sendiri.

Empat Pola Struktur Navigasi

HIERARKIS • SEKUENSIAL • MATRIKS • HUB-AND-SPOKE

Empat pola ini adalah "kerangka rak" yang paling sering dipakai. Hierarkis berbentuk pohon bercabang, seperti struktur menu Tokopedia dari beranda ke kategori ke sub-kategori ke produk — paling umum untuk katalog besar. Sekuensial berbentuk garis lurus langkah demi langkah, cocok untuk proses seperti pendaftaran akun atau checkout yang harus dilalui berurutan. Matriks memungkinkan pengguna berpindah ke berbagai arah, cocok untuk aplikasi perbandingan data seperti dashboard analitik. Hub-and-spoke punya satu pusat dengan beberapa cabang sejajar yang semuanya kembali ke pusat, mirip menu utama aplikasi Gojek yang punya banyak layanan sejajar — GoRide, GoFood, GoPay — semuanya bisa diakses langsung dari beranda. Dalam praktiknya, satu aplikasi biasanya menggabungkan lebih dari satu pola sekaligus, dan itu wajar.

Sitemap: Definisi dan Fungsinya

Sitemap (peta situs) adalah diagram yang memetakan seluruh halaman/layar produk digital dan hubungan hierarkinya — jawaban visual dari pertanyaan "ada apa saja di aplikasi ini, dan bagaimana semuanya terhubung?"

FUNGSI SITEMAP

Menyamakan pemahaman tim (desainer, developer, klien) tentang cakupan produk
Mengungkap konten yang duplikat atau hilang sebelum desain visual dimulai
Dasar estimasi jumlah layar yang perlu di-wireframe (pertemuan 7)
Acuan navigasi utama (menu, tab) yang akan dibangun developer

SITEMAP BUKAN...

Bukan tampilan visual layar — itu tugas wireframe & mockup
Bukan urutan langkah pengguna — itu tugas user flow
Bukan daftar fitur teknis — fokusnya struktur konten & navigasi

Sitemap sederhananya adalah denah rumah dari sebuah produk digital: ia menunjukkan ada berapa ruangan atau halaman, dan pintu mana yang menghubungkan ruangan satu ke ruangan lain, tanpa menjelaskan warna cat atau posisi furnitur di dalamnya. Fungsinya sangat praktis. Pertama, sitemap menyamakan pemahaman seluruh tim, termasuk klien, tentang seberapa besar cakupan aplikasi yang akan dibangun — ini penting supaya tidak ada kejutan di tengah proyek. Kedua, sitemap sering mengungkap masalah tersembunyi, misalnya dua halaman yang isinya duplikat, atau justru ada kebutuhan konten yang lupa direncanakan. Ketiga, sitemap menjadi dasar estimasi berapa banyak layar yang perlu digambar di tahap wireframing minggu depan. Yang penting untuk Anda ingat: sitemap bukan tampilan visual, dan bukan urutan langkah pengguna — dua hal itu adalah topik terpisah yang masing-masing punya alatnya sendiri, dan user flow akan kita bahas di paruh kedua pertemuan ini.

Lima Langkah Menyusun Sitemap

WALKTHROUGH — DARI DAFTAR KONTEN MENTAH KE STRUKTUR RAPI

1. Inventarisasi konten — daftar SEMUA halaman/fitur yang mungkin ada (brainstorming, jangan disaring dulu).
2. Kelompokkan — kumpulkan konten yang berkaitan, idealnya divalidasi lewat card sorting (slide 11).
3. Susun hierarki — tentukan mana halaman utama (level 1), mana turunannya (level 2, 3, dst).
4. Beri label jelas — nama menu harus dikenali pengguna awam, hindari istilah internal tim.
5. Gambar & validasi — buat diagram kotak-dan-garis, lalu uji ke calon pengguna: "kalau cari X, Anda akan klik ke mana?"

Aturan praktis (heuristik Miller ~7±2): usahakan tiap level menu tidak lebih dari 7 item agar tidak membebani ingatan pengguna saat memindai pilihan.

Lima langkah ini bisa langsung Anda praktikkan minggu depan pada studi kasus kelompok. Langkah pertama, inventarisasi, artinya keluarkan semua ide konten tanpa menyaring dulu — tulis semua yang terpikirkan, baik yang penting maupun yang sepertinya sepele. Langkah kedua, kelompokkan konten yang berkaitan; cara paling objektif melakukannya adalah lewat card sorting yang akan kita bahas sebentar lagi, bukan sekadar tebakan tim desain. Langkah ketiga, susun hierarki dari yang paling penting di level teratas turun ke detail. Langkah keempat sering dilupakan tapi krusial: beri label yang dikenali pengguna awam, jangan pakai istilah internal seperti "modul CRM" kalau pengguna Anda adalah pedagang pasar yang tidak paham istilah itu. Langkah kelima, gambar dalam bentuk kotak dan garis lalu validasi langsung ke calon pengguna. Ingat juga aturan praktis dari psikolog George Miller: manusia rata-rata nyaman mengingat sekitar tujuh item sekaligus, jadi usahakan tiap level menu tidak melebihi angka itu.

Contoh: Sitemap Aplikasi UMKM Fesyen

STUDI KASUS — TOKO FESYEN "BATIK NUSA" (HIPOTETIS)

Mari kita lihat contoh konkret: sitemap hipotetis untuk toko fesyen batik bernama Batik Nusa. Dari Beranda, ada empat cabang utama — Kategori Produk, Akun Saya, Keranjang dan Checkout, serta Bantuan. Perhatikan, empat cabang ini sudah cukup di bawah tujuh item sesuai heuristik Miller yang kita bahas tadi. Di bawah Kategori Produk, ada tiga sub-kategori: Batik Cap, Batik Tulis, dan Aksesori — ini contoh skema topik yang ambigu, keputusan desain, bukan fakta objektif. Di bawah Batik Cap, akhirnya sampai ke Detail Produk dan Ulasan, yaitu level ketiga dari Beranda. Perhatikan kedalamannya: dari Beranda ke Detail Produk hanya butuh tiga klik. Ini prinsip penting — semakin dalam sebuah item terkubur, semakin besar kemungkinan pengguna menyerah mencarinya, sesuatu yang akan kita hitung dengan angka pasti nanti di bagian "Hitung dari Nol".

Card Sorting: Validasi Struktur dari Pengguna Asli

Card sorting (pengurutan kartu) adalah metode riset: peserta mengelompokkan kartu berisi nama konten ke dalam kategori yang menurut mereka masuk akal — bukan menurut tim desain.

OPEN CARD SORTING

TANPA KATEGORI

Peserta membuat & menamai kategori sendiri. Cocok di awal proyek untuk menemukan pengelompokan alami menurut pengguna.

CLOSED CARD SORTING

KATEGORI SUDAH ADA

Peserta memasukkan kartu ke kategori yang sudah ditentukan tim. Cocok untuk menguji ulang sitemap yang sudah dirancang.

Contoh praktik: sebelum menetapkan sitemap Batik Nusa di slide sebelumnya, tim bisa uji ke 8–10 calon pembeli: "kartu 'Cara Cuci Batik' ini menurut Anda masuk kategori apa?" — jawaban mayoritas menentukan label & posisi akhirnya, bukan asumsi tim.

Card sorting adalah cara paling langsung memastikan sitemap yang Anda susun masuk akal bagi pengguna sungguhan, bukan hanya masuk akal menurut tim desain yang sudah terlalu dekat dengan produknya sendiri. Ada dua jenis. Open card sorting dilakukan di awal proyek, ketika Anda belum punya kategori sama sekali — peserta bebas membuat dan menamai kelompoknya sendiri, dan pola yang muncul dari banyak peserta itulah yang menjadi dasar sitemap awal. Closed card sorting dilakukan setelah kategori sudah ditetapkan, untuk menguji apakah kategori itu sudah tepat — peserta tinggal memasukkan tiap kartu ke kategori yang sudah disediakan. Contoh sederhana: bayangkan kartu bertuliskan "Cara Cuci Batik" — apakah itu masuk kategori "Bantuan", "Produk", atau "Blog"? Jawaban dari delapan sampai sepuluh calon pembeli sungguhan akan jauh lebih dapat dipercaya daripada tebakan satu-dua orang di tim desain. Metode ini murah, cepat, dan bisa dilakukan bahkan dengan sticky note fisik atau aplikasi gratis.

Bagian 2 dari 3

Diagram Alur Pengguna (User Flow)

Bergeser dari struktur statis (sitemap) ke urutan dinamis: jalur langkah demi langkah yang dilalui pengguna untuk mencapai satu tujuan spesifik.

Sitemap = Peta | User Flow = Rute Perjalanan

User Flow: Definisi dan Bedanya dengan Sitemap

User flow (alur pengguna) adalah diagram yang menggambarkan urutan langkah seorang pengguna dari titik awal sampai mencapai satu tujuan spesifik — termasuk titik keputusan di sepanjang jalan.

SITEMAP VS USER FLOW — JANGAN TERTUKAR

Aspek	Sitemap	User Flow
Sifat	Statis — struktur keseluruhan	Dinamis — urutan satu tugas
Pertanyaan dijawab	"Ada apa saja di aplikasi ini?"	"Bagaimana cara pengguna sampai ke tujuan X?"
Cakupan	Seluruh halaman/layar	Hanya layar yang dilalui 1 tugas
Elemen kunci	Kotak (halaman) & garis hierarki	Kotak, panah, & titik keputusan

Ini pembeda yang paling sering tertukar oleh mahasiswa baru belajar UX, jadi mari kita luruskan dengan tabel ini. Sitemap sifatnya statis, ia menggambarkan struktur secara keseluruhan tanpa memedulikan urutan waktu — mirip daftar isi buku. User flow sifatnya dinamis, ia menggambarkan urutan waktu: langkah pertama, kedua, ketiga, sampai tugas selesai — mirip alur cerita dalam satu bab buku. Pertanyaan yang dijawab juga berbeda: sitemap menjawab "ada apa saja", sedangkan user flow menjawab "bagaimana cara sampai ke sana". Elemen kuncinya pun berbeda; user flow punya elemen tambahan yang tidak ada di sitemap, yaitu titik keputusan — misalnya "apakah pengguna sudah login atau belum" — yang akan menentukan jalur bercabang. Kita akan pelajari notasi standar untuk menggambar titik keputusan ini di slide berikutnya.

Notasi Standar Diagram User Flow

LIMA SIMBOL DASAR — DIPAKAI KONSISTEN DI SELURUH INDUSTRI

Konsistensi notasi penting: kalau tim developer melihat bentuk belah ketupat, mereka langsung tahu itu logika percabangan yang perlu di-coding — bukan sekadar tampilan layar biasa.

Lima simbol ini adalah standar internasional flowchart yang sudah dipakai puluhan tahun, dan dunia UX mewarisinya karena sangat efektif. Bentuk oval menandai titik mulai dan selesai sebuah alur. Bentuk persegi panjang menandai satu aksi atau satu tampilan layar, misalnya "Halaman Login". Bentuk belah ketupat menandai titik keputusan dengan jawaban ya atau tidak, misalnya "Sudah login?" — dan dari titik ini alur akan bercabang ke dua arah berbeda. Bentuk jajaran genjang menandai input, yaitu data yang dimasukkan pengguna, seperti mengisi alamat pengiriman. Terakhir, panah menandai arah dan urutan alur. Konsistensi notasi ini penting bukan hanya untuk desainer, tapi terutama untuk tim developer — begitu mereka melihat belah ketupat di diagram Anda, mereka langsung paham itu logika percabangan yang harus mereka tulis kodenya, bukan sekadar gambar dekoratif.

Contoh: User Flow Proses Checkout

STUDI KASUS — PEMBELIAN DI TOKO BATIK NUSA

Diagram ini menerapkan langsung lima notasi yang baru kita pelajari, untuk satu tugas spesifik yaitu membeli batik. Alur dimulai dari oval "Mulai", lalu pengguna melihat detail produk dan menambahkannya ke keranjang. Sampai di titik belah ketupat "Sudah login?" — inilah titik keputusan yang tadi saya sebut sebagai perbedaan utama user flow dari sitemap. Kalau jawabannya "Tidak", alur bercabang ke kiri menuju halaman login atau daftar akun, lalu kembali menyatu ke jalur utama. Kalau jawabannya "Ya", alur langsung lanjut ke pengisian alamat pengiriman. Perhatikan, kedua cabang ini akhirnya bertemu kembali di kotak "Isi Alamat Pengiriman" — inilah yang disebut alur menyatu kembali, sebuah pola umum dalam user flow. Setelah itu pengguna memilih metode pembayaran, dan alur berakhir di oval "Selesai". Coba hitung sendiri: dari Mulai sampai Selesai lewat jalur "Ya", ada berapa kotak aksi yang harus dilalui? Kita akan pakai angka ini di dua slide "Hitung dari Nol" berikutnya.

Hitung dari Nol: Efisiensi Klik pada Struktur Berbeda

Toko Batik Nusa punya 64 produk. Tim mempertimbangkan dua rancangan hierarki kategori — mana yang membuat pengguna lebih cepat sampai ke produk?

LANGKAH PERHITUNGAN

Langkah	Perhitungan	Nilai
Total produk yang dijangkau	—	64 produk
Struktur A: lebar 8 kategori/level	kedalaman = log₈(64)	2 klik
Struktur B: lebar 4 kategori/level	kedalaman = log₄(64)	3 klik
Selisih klik per pencarian	3 − 2	1 klik lebih banyak
Total klik ekstra/hari	1 × 1.000 pengguna	1.000 klik/hari

STRUKTUR TERPILIH

8 kategori × 2 level = 64 produk

Struktur A (lebih lebar, lebih dangkal) menang: hanya 2 klik ke produk apa pun, vs 3 klik pada Struktur B. Konsisten dengan prinsip "lebih lebar lebih baik daripada lebih dalam" dalam arsitektur informasi.

Mari hitung dengan angka pasti, bukan sekadar intuisi. Toko Batik Nusa punya total enam puluh empat produk yang harus bisa dijangkau dari beranda. Struktur A membagi produk menjadi delapan kategori di tiap level; karena delapan pangkat dua sama dengan enam puluh empat, pengguna hanya perlu dua kali klik untuk sampai ke produk manapun — klik pertama memilih kategori, klik kedua memilih produk. Struktur B membagi produk menjadi empat kategori tiap level; karena empat pangkat tiga juga sama dengan enam puluh empat, pengguna butuh tiga kali klik. Selisihnya satu klik per pencarian, kelihatannya kecil, tapi kalau dikalikan seribu pengguna yang mencari produk setiap hari, itu setara seribu klik ekstra per hari yang terbuang di seluruh basis pengguna. Inilah mengapa dalam arsitektur informasi ada prinsip klasik: lebih baik struktur yang lebar dengan sedikit level, daripada struktur yang dalam dengan banyak level, karena setiap level tambahan adalah gesekan bagi pengguna.

Coba Sendiri: Bandingkan Kedalaman Klik Lebar vs Dalam

Ubah jumlah produk dan lebar kategori per level, lalu amati berapa klik yang dibutuhkan pengguna untuk sampai ke produk.

Hitung dari Nol: Funnel Konversi Alur Checkout

Asumsi ilustratif ~10% pengguna keluar (drop-off) di tiap langkah alur checkout (heuristik funnel UX umum) — mari hitung berapa yang benar-benar menyelesaikan pesanan.

LANGKAH PERHITUNGAN (MULAI: 1.000 PENGGUNA)

Langkah	Perhitungan	Nilai
Mulai (Lihat Produk)	—	1.000 (100%)
Setelah Tambah Keranjang	1.000 × 90%	900
Setelah Isi Alamat	900 × 90%	810
Setelah Pilih Pembayaran	810 × 90%	729
Setelah Konfirmasi (Selesai)	729 × 90%	≈656

TOTAL KONVERSI CHECKOUT

65,6%

656 / 1.000 pengguna

Empat langkah tambahan (login, alamat, pembayaran, konfirmasi) "menguapkan" hampir 35% calon pembeli. Ini alasan tim produk (mis. GoTo, Shopee) terus berusaha memangkas jumlah langkah checkout.

Sekarang kita simulasikan dampak nyata dari panjangnya sebuah user flow. Anggap seribu pengguna mulai melihat produk. Secara heuristik umum di dunia funnel produk digital, setiap langkah tambahan kehilangan sekitar sepuluh persen pengguna — angka ini ilustratif, bukan data pasti Batik Nusa, tapi pola arah kehilangannya realistis. Setelah menambah ke keranjang, tersisa sembilan ratus. Setelah mengisi alamat, tersisa delapan ratus sepuluh. Setelah memilih metode pembayaran, tersisa tujuh ratus dua puluh sembilan. Setelah konfirmasi akhir, tersisa kira-kira enam ratus lima puluh enam pengguna yang benar-benar menyelesaikan pesanan, atau sekitar enam puluh lima koma enam persen dari yang memulai. Artinya, hampir tiga puluh lima persen calon pembeli hilang di tengah jalan hanya karena panjangnya alur. Inilah sebabnya perusahaan besar seperti Shopee dan GoTo terus-menerus berusaha memangkas jumlah langkah checkout — setiap langkah yang dihilangkan secara matematis menyelamatkan sekian persen pengguna yang tadinya akan kabur.

Coba Sendiri: Simulasikan Funnel Konversi Checkout Anda

Ubah jumlah langkah checkout dan tingkat drop-off per langkah, lalu amati berapa persen pengguna yang benar-benar menyelesaikan pesanan.

Tiga Kesalahan Umum dalam IA & User Flow

KESALAHAN 1

TERLALU DALAM

Menu lebih dari 3 level untuk mencapai konten penting. Bandingkan dengan Struktur A vs B di slide "Hitung dari Nol".

KESALAHAN 2

LABEL AMBIGU

Nama menu memakai istilah internal tim, mis. "Modul Fulfillment" alih-alih "Lacak Pesanan".

KESALAHAN 3

TANPA JALUR KELUAR

User flow tidak menyediakan tombol "Kembali"/"Batal" di titik keputusan — pengguna terjebak.

Cara mencegah ketiganya: validasi sitemap dengan card sorting (slide 11), uji label ke pengguna awam, dan selalu gambar jalur "batal/kembali" di setiap titik keputusan user flow.

Sebelum kita masuk ke sesi praktik, saya ingin merangkum tiga kesalahan yang paling sering saya temukan pada rancangan mahasiswa maupun praktisi pemula. Kesalahan pertama, struktur yang terlalu dalam, kita sudah buktikan dengan angka di slide sebelumnya bahwa setiap level tambahan membebani pengguna. Kesalahan kedua, label ambigu, terjadi ketika tim desain memakai istilah teknis internal yang tidak dipahami pengguna awam — bayangkan aplikasi UMKM memakai istilah "Modul Fulfillment" padahal penggunanya adalah pedagang pasar yang lebih paham kalau ditulis "Lacak Pesanan". Kesalahan ketiga, tidak menyediakan jalur keluar di titik keputusan, membuat pengguna merasa terjebak — misalnya di halaman login paksa tanpa tombol batal, seperti keluhan ketiga di slide pembuka kita tadi. Ketiganya bisa dicegah dengan disiplin yang sudah kita pelajari: validasi lewat card sorting, uji label ke pengguna asli, dan selalu sediakan jalur kembali.

Bagian 3 dari 3

Praktik & Persiapan Minggu Depan

Menerapkan sitemap dan user flow pada studi kasus kelompok Anda sendiri, sebagai fondasi wireframing di Pertemuan 7.

Latihan Kelompok

Latihan: Buat Sitemap & User Flow Kelompok Anda

INSTRUKSI — KERJAKAN BERSAMA KELOMPOK PROYEK AKHIR ANDA (20 MENIT)

1. Ambil produk UMKM/aplikasi yang sudah Anda pilih sejak pertemuan riset pengguna (pertemuan 3–4).
2. Susun sitemap: inventarisasi konten → kelompokkan → hierarki → label — maksimum 7 item per level.
3. Pilih satu tugas paling penting pengguna (mis. "memesan produk"), gambar user flow-nya dengan 5 notasi standar.
4. Sertakan minimal satu titik keputusan (belah ketupat) dengan jalur "kembali/batal".

Kumpulkan foto/scan sitemap & user flow kelompok Anda ke LMS sebelum kelas berakhir. Ini akan menjadi input langsung untuk membuat wireframe rendah-fidelitas di Pertemuan 7.

Sekarang giliran Anda praktik. Kembali ke kelompok proyek akhir yang sudah Anda bentuk sejak pertemuan riset pengguna, dan gunakan produk UMKM atau aplikasi yang sama yang sudah Anda riset sebelumnya — supaya semua pekerjaan Anda saling terhubung sampai akhir semester. Susun sitemap dengan mengikuti lima langkah yang kita pelajari tadi, dan ingat batas tujuh item per level. Lalu pilih satu tugas pengguna yang paling penting bagi bisnis tersebut, misalnya proses pemesanan, dan gambar user flow-nya lengkap dengan lima notasi standar yang sudah kita bahas, termasuk minimal satu titik keputusan dengan jalur kembali. Saya dan asisten akan berkeliling membantu kelompok yang kesulitan. Kumpulkan hasilnya ke LMS sebelum kelas berakhir, karena sitemap dan user flow ini akan langsung menjadi bahan mentah untuk membuat wireframe rendah-fidelitas pertama Anda di pertemuan ketujuh minggu depan.