POLE vs POLS: Dua Prinsip Psikologi di Balik Desain Software yang Hebat

Pernahkah kamu menulis kode atau menggunakan API yang terasa “aneh tapi jalan”?
Atau sebaliknya — ada sistem yang terasa alami dipakai, meskipun kamu belum pernah baca dokumentasinya?

Itulah perbedaan antara dua prinsip klasik dalam desain perangkat lunak:
POLE (Principle of Least Effort) dan POLS/POLA (Principle of Least Surprise / Astonishment).

Keduanya sering disalahpahami, padahal keduanya adalah dua sisi dari desain software yang manusiawi.
Mari kita bahas secara mendalam — agar kamu tahu kapan menerapkan masing-masing dan bagaimana menggunakannya secara bersamaan.

🧩 Apa Itu POLE — Principle of Least Effort

Konsep ini berasal dari psikolog George Zipf (1949) yang mengatakan:

Manusia cenderung memilih jalan yang membutuhkan usaha paling sedikit untuk mencapai hasil yang sama.

Dalam konteks software engineering, prinsip ini berarti:

Developer (atau pengguna sistem) akan memilih cara tercepat, paling mudah, dan paling intuitif untuk menyelesaikan tugasnya.

💡 Fokus POLE:

• Kurangi jumlah langkah atau kompleksitas.

• Sediakan shortcut yang masuk akal.

• Hilangkan friksi dalam workflow.

• Buat alat yang mengikuti naluri alami manusia.

🧠 Contoh:

❌ Melanggar POLE

# Untuk menjalankan project
npm run build
npm run serve
npm run start:prod

✅ Sesuai POLE

npm start

Satu perintah cukup. Tidak perlu berpikir dua kali.
Less effort, more flow.

💬 Apa Itu POLS / POLA — Principle of Least Surprise / Astonishment

Prinsip ini muncul dari dunia desain antarmuka (UI dan API).

Sebuah sistem seharusnya tidak membuat pengguna terkejut terhadap hasil atau perilakunya.

Artinya:

• Nama fungsi, tombol, dan endpoint harus berperilaku seperti yang diharapkan pengguna.

• Hindari hasil yang tidak konsisten atau bertolak belakang dengan ekspektasi umum.

💡 Fokus POLS:

• Konsistensi.

• Prediktabilitas.

• Perilaku yang “masuk akal.”

• Tidak menipu pengguna dengan nama atau efek yang berbeda dari harapan.

🧠 Contoh:

❌ Melanggar POLS

function deleteUser(id) {
  // ternyata hanya menonaktifkan user
  updateUserStatus(id, 'inactive');
}

✅ Sesuai POLS

function deactivateUser(id) {
  updateUserStatus(id, 'inactive');
}

Nama dan perilaku sejalan. Tidak ada kejutan.
Least surprise = predictable experience.

⚖️ POLE vs POLS: Apa Bedanya?

🧠 Analogi Sederhana

💡 Contoh Kombinasi yang Ideal

Framework modern seperti Next.js, Laravel, dan React memadukan dua prinsip ini secara halus:

Hasilnya: framework yang mudah digunakan (least effort) sekaligus tidak membingungkan (least surprise).

🧩 Kapan Menggunakan Masing-Masing

🔧 Keterkaitan Keduanya

Meskipun berbeda fokus, sebenarnya POLE dan POLS saling memperkuat.

Sistem yang mengejutkan pengguna (melanggar POLS)
→ otomatis membuat mereka bekerja lebih keras (melanggar POLE juga).

Dan sebaliknya, sistem yang terlalu minimalis tanpa kejelasan

bisa jadi efisien tapi membingungkan.

Jadi, the best design adalah yang tidak mengejutkan dan tidak melelahkan.

🧭 Prinsip Umum untuk Developer

1. Pakai POLS lebih dulu:
   Pastikan perilaku sistem selalu sesuai ekspektasi.

2. Lalu terapkan POLE:
   Buat interaksi dan implementasi seefisien mungkin.

3. Uji dengan perspektif manusia:
   Jika seseorang baru pertama kali pakai kode atau API kamu,

   • apakah dia tahu apa yang akan terjadi? (POLS)

   • apakah dia bisa melakukannya dengan mudah? (POLE)

Kalau jawabannya “ya” untuk keduanya — kamu sudah menulis great software.

💬 Kesimpulan

💡 Sistem terbaik bukan hanya yang cepat atau pintar — tapi yang terasa alami.
Tidak mengejutkan, tidak melelahkan. Itulah titik keseimbangan antara POLE dan POLS.

🧱 “Great software is invisible — because it behaves exactly as you expect, and costs you almost no effort.”