← Back to list

Screen Counter — Part 2

Ketika Plugin Sudah Jadi, Tapi Belum Selesai

Andrian Soelistiyo · 2026-05-19 03:58 · 0 claps · 3.2 min read
#figma #figma-plugin #claude
Open on Medium ↗
Wiki topics: LLM · Large Language Models TLS · Design Tools & Workflow

Screen Counter — Part 2

Ketika Plugin Sudah Jadi, Tapi Belum Selesai

Screen Counter — Figma Plugin

Screen Counter — Figma Plugin

Download [New Update] Screen Counter — Figma Plugin: https://drive.google.com/file/d/1kuTNNs99UF6PSYU_WsF0oUxHy7qsc1xh/view?usp=sharing

Konteks Singkat

Di part sebelumnya, saya cerita tentang bagaimana saya membangun Figma plugin untuk menghitung screen dan membedakan mana yang NEW dan mana yang ADJUSTED setiap minggunya — semua berbasis Figma Version History API.

Plugin-nya jadi. Fiturnya bekerja. Saya senang.

Sampai saya mencobanya di file kerja yang sesungguhnya.

Masalah yang Tidak Terlihat Saat Development

Selama proses pengembangan, saya selalu menguji plugin di file kecil — puluhan screen, struktur sederhana. Semua berjalan mulus.

Tapi kondisi kerja nyata berbeda. Satu page di file saya bisa berisi 640 screen. Dan ketika saya membuka tab Per Minggu di file itu, yang terjadi bukan hasil yang ditampilkan — tapi loading yang tidak pernah selesai. Timeout.

Ini adalah momen yang familiar bagi siapa pun yang pernah terlibat dalam proses QA atau user testing: masalah yang tidak terlihat di controlled environment selalu muncul di kondisi nyata.

Kenapa Bisa Timeout?

Saya diskusikan ini dengan Claude, dan penjelasannya cukup mudah dipahami bahkan tanpa latar belakang teknis.

Fitur Per Minggu bekerja dengan cara membandingkan dua snapshot Figma — kondisi file di awal minggu vs kondisi file di akhir minggu. Untuk melakukan itu, plugin perlu mengambil data 640 frame sekaligus dari Figma API, dua kali.

Bayangkan memesan 640 item sekaligus ke dapur — dapur tidak menolak, tapi waktu tunggunya tidak terprediksi dan bisa gagal di tengah jalan. Itulah yang terjadi. Request terlalu besar, koneksi tidak sanggup, timeout.

Sementara tab Semua tetap berjalan lancar karena ia tidak perlu koneksi internet sama sekali — hanya membaca canvas lokal secara langsung.

Solusinya: Batching

Solusi yang diusulkan Claude adalah batching — memecah 640 frame menjadi kelompok-kelompok kecil berisi 50 frame, lalu mengambilnya satu per satu secara berurutan.

Alih-alih satu request raksasa yang rawan gagal, plugin sekarang mengirim 13 request kecil per snapshot. Lebih banyak request, tapi masing-masing jauh lebih ringan dan lebih terprediksi.

Ini trade-off yang disadari: prosesnya memang jadi lebih lama — sekitar 15–25 detik untuk 640 screen. Tapi selesai jauh lebih baik daripada tidak pernah selesai.

Masalah UX Baru yang Muncul

Begitu batching diimplementasi, muncul masalah baru yang lebih halus: plugin terlihat stuck.

User melihat loading spinner, tapi tidak ada indikasi apakah prosesnya sedang berjalan atau sudah mati. Untuk proses yang memakan waktu 15–25 detik, ini adalah pengalaman yang sangat tidak nyaman. Insting pertama user adalah menutup plugin dan membukanya lagi — yang tentu saja akan mengulang proses dari awal.

Ini contoh klasik dari sesuatu yang secara teknis sudah benar, tapi secara pengalaman masih terasa salah.

Solusinya sederhana: progress indicator. Plugin sekarang menampilkan informasi yang cukup untuk membuat user tetap tenang:

Screen Counter sedang diproses

Screen Counter sedang diproses

Tiga elemen itu — teks konteks, posisi saat ini, dan progress bar — cukup untuk mengubah pengalaman dari “ini loading atau crash?” menjadi “oke, masih proses, tinggal sebentar lagi.”

Proses Screen Counter selesai

Proses Screen Counter selesai

Yang Saya Pelajari dari Update Ini

Testing di kondisi nyata tidak bisa digantikan. Plugin yang bekerja sempurna di file kecil tidak otomatis bekerja di file besar. Satu-satunya cara menemukan ini adalah mencobanya langsung di kondisi kerja yang sesungguhnya — bukan di lingkungan yang dibuat untuk testing.

Selesai bukan berarti selesai. Plugin yang “sudah jadi” di part 1 ternyata belum selesai. Dan ini normal. Dalam proses desain pun, prototype pertama yang terlihat bagus di presentasi sering kali menemukan masalah baru begitu disentuh user sungguhan.

Masalah teknis sering punya solusi UX. Timeout adalah masalah teknis. Tapi solusinya bukan hanya memperbaiki cara data diambil — tapi juga memperbaiki bagaimana proses itu dikomunikasikan ke user. Progress bar bukan fitur teknis, tapi ia adalah bagian terpenting dari pengalaman menunggu yang tidak terasa menyebalkan.

AI tetap butuh konteks nyata dari pemakainya. Claude bisa menyarankan batching dan progress indicator. Tapi Claude tidak tahu file saya berisi 640 screen sampai saya mencoba sendiri dan melaporkannya. Temuan itu hanya bisa datang dari pemakaian nyata — dan itu tidak bisa didelegasikan ke AI.

Status Saat Ini

Plugin sekarang bisa menangani ratusan screen tanpa timeout, menampilkan progress yang jelas selama proses berlangsung, dan tetap akurat dalam membedakan screen NEW vs ADJUSTED berdasarkan Figma Version History.

Apakah ini benar-benar selesai sekarang? Mungkin. Atau mungkin ada kondisi nyata berikutnya yang akan mengungkap masalah baru yang belum terlihat hari ini.

Dan kalau itu terjadi — itu bukan kegagalan. Itu proses yang bekerja sebagaimana mestinya.


메타데이터
post_id
b78e211e8a53
slug
screen-counter-part-2-b78e211e8a53
url
https://medium.com/@andriansoelistiyo/screen-counter-part-2-b78e211e8a53
canonical_url
https://medium.com/@andriansoelistiyo/screen-counter-part-2-b78e211e8a53
author_url
https://medium.com/@andriansoelistiyo
status
ok
fetched_at
2026-06-09 15:37:30