Tesler Law untuk Onboarding SaaS Indonesia: Cara Memindahkan Beban Kompleksitas dari Pengguna ke Sistem di 2026

TL;DR: Tesler Law atau Law of Conservation of Complexity menyatakan setiap aplikasi punya kompleksitas yang tidak bisa dihilangkan, hanya dipindahkan. Untuk SaaS Indonesia di 2026, ini berarti form abandonment dan onboarding drop-off bukan masalah memotong field, tapi memindahkan validasi, enrichment, dan pengambilan keputusan dari pengguna ke sistem.

Ada satu pola yang berulang di hampir setiap audit onboarding SaaS yang saya lakukan. Tim produk minta pengguna mengisi 12-18 field karena "data ini diperlukan untuk personalisasi". Hasilnya, completion rate onboarding stuck di 30-40 persen. Tim lalu memotong jadi 6 field, completion naik tipis, tapi data jadi kurang lengkap dan tim sales mengeluh kualitas lead turun.

Masalahnya bukan jumlah field. Masalahnya: siapa yang menanggung kompleksitas. Inilah inti Tesler Law.

Apa itu Tesler Law

Larry Tesler, peneliti UI di Xerox PARC, menyimpulkan tahun 1980-an bahwa kompleksitas dalam software ibarat hukum kekekalan energi: tidak hilang, hanya berpindah. Kalau pengguna mengisi form sederhana di permukaan, di balik layar ada sistem yang melakukan validasi, geocoding, atau perhitungan rumit.

Pertanyaan inti yang ditanyakan Tesler Law: siapa yang seharusnya menanggung beban, pengguna atau sistem? Beban di sisi pengguna disebut interaction cost dan dibayar berulang oleh setiap pengguna. Beban di sisi sistem disebut implementation cost dan dibayar sekali oleh tim engineering. Untuk konteks lebih luas, baca Tesler Law dan Cognitive Load.

Ekonomi Tesler Law: 1 jam waktu engineering yang menggeser kompleksitas ke sistem sering menghemat ribuan jam waktu pengguna selama lifecycle produk. ROI-nya hampir selalu positif.

Tiga Lapisan Kompleksitas dalam Onboarding SaaS

Setiap baris kanan adalah implementasi Tesler Law. Engineering menanggung sekali, pengguna untung berulang.

Studi Kasus: Atmo (LMS) dan Pemindahan Validasi

Saat membangun platform LMS Atmo untuk klien institusi pendidikan, kami menghadapi masalah klasik. Onboarding peserta butuh 16 data: nama, NIK, alamat lengkap, asal sekolah, kelas, dan seterusnya. Versi pertama menampilkan semua di satu halaman dengan validasi setelah submit. Completion rate hanya 38 persen di mobile.

Setelah refactor sesuai Tesler Law, kami pindahkan beban:

1. NIK divalidasi real-time dengan format mask 4-4-4-4. Error muncul di field, bukan setelah submit.
2. Alamat hanya butuh kode pos. Sistem auto-isi kelurahan, kecamatan, kota, provinsi via API geocoding. Pengguna tinggal verifikasi.
3. Asal sekolah pakai dropdown dengan search dan autocomplete dari database 200 ribu sekolah Indonesia. Pengguna ketik 3 huruf, sistem yang mencari.
4. Kelas dan jurusan jadi dropdown dependent yang muncul setelah sekolah dipilih, bukan field bebas.

Hasil 90 hari pertama: completion rate naik dari 38 persen ke 71 persen. Jumlah field yang ditampilkan ke pengguna sebenarnya hanya turun dari 16 ke 14, perubahan kecil. Yang berubah besar adalah berapa banyak kompleksitas yang harus diproses pengguna sendiri.

Cara Menerapkan Tesler Law di Onboarding Anda

Audit onboarding Anda dengan tiga pertanyaan ini per field atau step:

Pertama, apakah data ini bisa di-fetch otomatis? Login OAuth Google atau LinkedIn memberi nama, email, foto, kadang job title. Itu 3-4 field yang bisa dihapus dari form. Untuk pemahaman dasar OAuth, lihat OAuth (Open Authorization).

Kedua, apakah validasi bisa dilakukan saat ketik? Format email, format nomor HP, format NIK semua bisa divalidasi inline. Pengguna tahu masalah saat masih di field, bukan setelah submit. Ini menurunkan form abandonment signifikan.

Ketiga, apakah keputusan ini bisa di-default-kan? Banyak setting awal SaaS sebenarnya punya default yang masuk akal untuk 80 persen pengguna. Tampilkan default, beri opsi "Sesuaikan" untuk power user. Jangan paksa setiap pengguna jadi power user di hari pertama.

Pendalaman teknis tentang Progressive Disclosure melengkapi Tesler Law. Sementara Tesler memindahkan kompleksitas ke sistem, Progressive Disclosure menunda kompleksitas yang memang harus ada ke saat pengguna siap.

Pertanyaan Umum

Apakah Tesler Law berarti aplikasi profesional harus terlihat sederhana?

Tidak. Aplikasi seperti Adobe Premiere atau Excel memang kompleks karena penggunanya butuh kontrol penuh. Tesler Law mengajarkan untuk memilih siapa yang menanggung kompleksitas, bukan menghilangkannya. Profesional ingin kompleksitas, pemula tidak.

Bagaimana mengukur penerapan Tesler Law di onboarding?

Ukur tiga metrik: completion rate per step, time-to-complete onboarding, dan activation rate (apakah pengguna sampai aha moment). Penurunan time-to-complete 30 persen tanpa kenaikan drop-off adalah sinyal bahwa beban berhasil dipindahkan.

Apakah implementasi Tesler Law mahal di engineering?

Investasi awal lebih tinggi. Tapi kalau jumlah pengguna onboarding lebih dari 1000 per bulan, breakeven biasanya tercapai dalam 2-3 bulan dari kenaikan conversion. ROI tergantung skala dan ARPU produk.

Apa hubungan Tesler Law dengan dark pattern?

Tesler Law tidak boleh dijadikan alasan menyembunyikan informasi penting. Memindahkan kompleksitas berbeda dengan menyembunyikan keputusan dari pengguna. Lihat Dark Pattern untuk membedakan keduanya.

Apakah Tesler Law berlaku untuk produk B2B Indonesia?

Berlaku, bahkan lebih relevan. Pengguna B2B Indonesia sering punya waktu evaluasi terbatas, dan onboarding yang berat membuat tim purchasing memilih produk kompetitor yang lebih ringan, walau fitur kalah lengkap.

Penerapan untuk Tim Anda Minggu Ini

Buka analytics onboarding Anda. Identifikasi step dengan drop-off tertinggi. Tanyakan: apa kompleksitas yang sedang ditanggung pengguna di step ini? Apakah ada cara memindahkannya ke sistem, walau butuh effort engineering tambahan?

Tesler Law tidak menghapus kompleksitas, hanya memindahkannya. Tapi pemindahan itu kadang adalah perbedaan antara conversion 30 persen dan 70 persen. Untuk panduan UX yang lebih luas, lihat juga prinsip dari Nielsen Norman Group tentang interaction cost.