Redesain Arsitektur Informasi untuk Memangkas Load Time hingga 75%

Salah satu hal yang menjadikan user nyaman menggunakan aplikasi web adalah load speed. Bayangkan,ketika user setelah melakukan login harus menunggu sekitar 8-12 detik untuk melihat tampilan pertama mereka. Membuat frustasi bukan?

Hal inilah yang dialami Privy. Untuk load document list secara utuh perlu waktu hingga 8-12s. Dengan branding trusted digital identity, hal ini bisa mempengaruhi nilai kepercayaan user terkait slogan "apakah ini benar-benar aman dan terpercaya?".

1. Problem Statement

Document list adalah halaman yang pertama dibuka user setelah login. Halaman ini me-load banyak data terkait document sehingga perlu waktu cukup lama untuk siap ditampilkan. Hal ini menimbulkan impresi pertama yang buruk dan melanggar core dari prinsip UX perceived performance. Meskipun sudah diberi "loading skeleton" namun jika terlalu lama hal itu justru bisa menjadi boomerang.

Apa yang bisa kita lakukan? : Mencari akar masalah apa penyebab dari loading ini. Apakah masalah teknis? atau non teknis yang bisa diselesaikan melalui design approach.

Sebelum di optimasi ❌ . Load status memakan waktu lebih dari 12 detik.

2. Research & Discovery

Menganalisa menggunakan inspect element
Interview beberapa pengguna aktif terkait informasi apa yang menjadi prioritas saat page pertama kali di-load
Konsolidasi dengan tim engineering terkait hal yang berpengaruh terhadap load speed
Tercampurnya logic status dokumen dengan status penerima dokumen. Misal kondisi status dokumen adalah "Menunggu recipient menandatangani dokumen" dan status user sebagai penerima adalah "Perlu menandatangani document ini". Pada kondisi ini status document nya adalah "Waiting" (Menunggu untuk diberi action). Jika user sudah menandatangani document nya tapi recipient lain belum maka berubah menjadi "In progress".
Engineer menggunakan metode ini karena untuk menampilkan status document secara realtime (tidak menuliskan status ini dalam database karena tercampurnya logic status document dengan penerima document).

Key Insight: Kita menampilkan data yang terlalu banyak (tidak terlalu dibutuhkan user). Meringkas hal-hal dengan metode yang kurang efektif. Status document menjadi hal utama terkait lambatnya speed load.

Gambar document yang memiliki status "Waiting" (Menunggu anda melakukan aksi).

3. Solution Approach

Mengubah bagaimana Status document "bekerja".

Masalah pertama adalah mengapa status document membuat load menjadi lama. Karena sistem perlu melihat bagaimana status recipient dalam dokumen tersebut. Jika recipient A sudah tanda tangan namun recipient B belum, maka status document nya adalah "In progress". Jika kedua nya sudah tanda tangan maka sistem menulis status document nya "Completed". Jika penerima dokumennya ratusan, betapa beratnya sistem memeriksa status document ini hanya untuk menampilkan "completed" , "in progress" dll.
Setelah melakukan wawancara dengan user. Prioritas utama user terkait status dokumen adalah 'Apa status saya terhadap dokumen ini'. Selaras dengan issue di atas dan menjawab hipotesa kita, akhirnya status document kita split menjadi 2 status. "Status document" dan "Status user terhadap document".
Dengan terpisahnya status document. Maka menyimpan "status document" dan "status user terhadap document" menjadi relevan karena tidak ada dualisme makna dalam column database "Status Document".
Document List hanya fokus pada status user + visual hierarchy yang lebih clean dan scannable.
Detail summary, status, dipindah ke document detail view dengan micro-interaction yang lebih baik.

Design Decisions & Trade-offs . Memutuskan untuk membagi 2 status. "Status dokumen tersebut" dan "Status user terhadap dokumen". Trade-off nya adalah user memerlukan step tambahan untuk melihat summary dari status dokumen (karena sebelumnya digabung).

Letak informasi terkait status user & document setelah improvement dengan cara meng-klik document yang ada di list.

4. Results

Dengan dihilangkannya extra logic untuk memeriksa status document melalui load status langsung dari database. Loading page yang awalnya hingga 12 detik sekarang cukup 3 detik untuk menampilkan semuanya. Yang berarti mempercepat loading page hingga 75%.

Meniadakan tiket keluhan (Zero ticket escalation) terkait performa dashboard selama satu Quartal setelah fitur ini rilis.
Meningkatkan User satisfaction score (CSAT) terkait load page dari 2.3 → 4.5 (skala 5).

Sesudah di optimasi ✅ hanya butuh 3 detik untuk mendapatkan semua status document dan status user terhadap document.

5. Key Learnings

Tidak semua issue load speed itu mutlak karena masalah technical. Bisa jadi dengan improvement dari sisi design dan UX dapat menyelesaikan masalah tersebut.

Case ini membuat perubahan mindset dari yang awalnya "Bagaimana semua data ini bisa ditampilkan secara langsung agar dapat dilihat oleh user" menjadi "Data apa yang benar-benar dibutuhkan oleh user".

User-centered approach menjadi prinsip saya kedepannya untuk mengetahui bagaimana mengkompromikan antara menampilkan data secara lengkap dengan optimasi perfoma.