Awalnya Hanya Sebuah Window
Awalnya saya hanya ingin membuat Store Window.
Sebuah ruang kecil di dalam website bergaya desktop untuk menampilkan produk. Tidak lebih dari itu. Ada product card, ada kategori, ada detail produk, lalu mungkin cart dan checkout. Secara visual, ia seharusnya tetap terasa seperti bagian dari dunia yang sama: window, toolbar, traffic light, panel, dan interaksi yang tidak terlalu jauh dari bahasa macOS-style yang sudah saya bangun.
Namun store punya cara sendiri untuk menjadi serius.
Begitu sebuah produk mulai memiliki harga, stok, diskon, foto, ukuran, checkout, pembayaran, pengiriman, tracking, dan status order, saya mulai sadar bahwa ini bukan lagi sekadar window.
Ini mulai menjadi sistem.
Dan ketika sebuah fitur mulai menjadi sistem, pertanyaannya berubah.
Bukan lagi hanya:
Bagaimana membuatnya terlihat bagus?
Tetapi:
Bagaimana membuatnya tetap rapi ketika datanya tumbuh?
Bagaimana membuatnya tetap nyaman untuk user?
Bagaimana membuatnya tetap bisa diatur oleh pemilik store?
Bagaimana membuatnya cukup serius untuk menerima order sungguhan, tanpa terasa seperti dashboard yang kaku?
Di titik itu, Store Window berhenti menjadi eksperimen visual. Ia menjadi latihan kecil tentang bagaimana e-commerce bisa hidup di dalam website personal tanpa kehilangan karakter.
Store Bukan Hanya Tempat Produk Ditampilkan
Kesalahan paling mudah ketika membangun store adalah menganggap store hanya sebagai halaman produk.
Padahal dalam praktiknya, produk hanyalah permukaan.
Di bawah satu product card yang terlihat sederhana, ada banyak keputusan kecil:
- apa nama produknya?
- kategori apa yang paling tepat?
- apakah stoknya masih ada?
- apakah sedang diskon?
- apakah harga diskon perlu ditampilkan berbeda?
- apakah foto produk lebih dari satu?
- apakah ukuran dan varian perlu diatur?
- apakah produk ini bisa dikirim dari semua cabang?
- apakah produk ini perlu tetap bisa dibuka ketika stok habis?
Pertanyaan-pertanyaan kecil seperti ini terlihat biasa, tetapi semuanya memengaruhi rasa belanja.
Sebuah produk yang stoknya habis bisa saja disembunyikan. Tetapi bagi user, kadang tetap penting untuk melihat detailnya. Mereka mungkin ingin tahu bentuk produknya, harga normalnya, atau menunggu restock. Maka badge "Out of Stock" bukan sekadar label. Ia adalah cara store berbicara jujur tanpa memutus rasa penasaran user.
Diskon juga begitu.
Harga coret mungkin umum, tetapi belum tentu selalu paling cocok. Untuk store yang ingin terasa clean, cukup menampilkan sale price dengan warna yang berbeda bisa terasa lebih tenang. Badge diskon tidak perlu berteriak. Ia hanya perlu cukup jelas.
Di sinilah saya merasa store yang baik bukan hanya soal menampilkan produk.
Store yang baik adalah percakapan antara visual, data, dan kepercayaan.
Front Office dan Back Office
Ketika Store Window mulai tumbuh, saya mulai membedakan dua sisi yang sebenarnya sangat berbeda.
Sisi pertama adalah front office.
Ini bagian yang dilihat user: daftar produk, kategori, product detail, cart, checkout, order detail, tracking, dan semua interaksi yang terjadi saat seseorang ingin membeli.
Sisi kedua adalah back office.
Ini bagian yang dilihat pemilik store: produk apa saja yang aktif, kategori apa yang tersedia, stok berapa, harga berapa, diskon berapa, foto mana yang dipakai, cabang mana yang menjadi origin, order mana yang sudah paid, shipping mana yang perlu dilihat, dan sebagainya.
Keduanya berhubungan, tetapi tidak boleh terasa sama.
Front office harus terasa ringan, jelas, dan meyakinkan.
Back office harus terasa rapi, akurat, dan bisa diedit tanpa membuat takut.
Di banyak sistem, back office langsung berubah menjadi dashboard besar yang penuh tabel, tombol, dan istilah teknis. Itu tidak salah. Untuk banyak bisnis, justru itu pendekatan yang tepat.
Tetapi untuk website personal yang memang dibangun dengan bahasa desktop, saya merasa pendekatan itu akan terasa seperti tempelan.
Maka muncul pertanyaan yang lebih menarik:
Bisakah CMS store hidup di dalam Settings Window?
Bukan sebagai dashboard asing, tetapi sebagai bagian natural dari sistem yang sama.
Settings Window sebagai CMS
Awalnya Settings Window tidak terlalu penting.
Ia hanya berisi pengaturan kecil, beberapa hal kosmetik, dan fungsi yang tidak terlalu memengaruhi sistem utama. Tetapi ketika store mulai serius, Settings Window justru menjadi tempat yang paling masuk akal untuk back office.
Karena setting, dalam arti yang lebih luas, bukan hanya soal appearance.
Setting adalah tempat sebuah website diatur.
Di sana pemilik store bisa melihat general summary, order, store config, branch, category, product, dan nanti mungkin user atau inventory yang lebih detail. Dengan begitu, Settings Window berubah dari window kosmetik menjadi ruang kendali.
Yang menarik, perubahan ini bukan hanya perubahan fitur. Ini perubahan makna.
Settings Window tidak lagi hanya menjawab pertanyaan:
Apa preferensi tampilan website ini?
Tetapi juga:
Bagaimana website ini beroperasi?
Di dalam konteks e-commerce kecil, itu terasa lebih jujur. Store tidak butuh admin panel yang terasa terlalu enterprise sejak awal. Ia butuh ruang yang cukup serius, tetapi masih menyatu dengan karakter website.
Itu sebabnya saya lebih tertarik menjadikan Settings Window sebagai CMS daripada membuat dashboard terpisah yang desainnya lepas dari dunia utama.
CMS tidak harus selalu terasa seperti CMS.
Yang penting ia aman, jelas, dan bisa dipakai.
Yang Sulit Bukan CRUD
Secara teknis, membuat CRUD bukan bagian paling sulit.
Menambah produk, mengedit harga, mengubah kategori, mengupload foto, atau menyimpan data ke Firestore adalah pekerjaan yang bisa dijelaskan dengan cukup langsung.
Yang lebih sulit adalah membuat semua itu terasa seperti bagian dari satu produk yang sama.
Row height harus konsisten.
Typography harus terasa satu keluarga.
Button edit tidak boleh tiba-tiba terasa seperti button dari halaman admin lain.
Toolbar harus punya ritme yang sama.
Icon plus, refresh, filter, dan search harus terasa familiar.
Detail produk di Settings Window sebaiknya mengikuti rasa Product Detail di Store Window, karena keduanya membicarakan objek yang sama dari sudut pandang yang berbeda.
Ini detail kecil, tetapi justru di detail seperti ini sebuah sistem terasa matang atau terasa tambalan.
CRUD membuat fitur bekerja.
Konsistensi membuat fitur dipercaya.
Dan di e-commerce, rasa percaya itu penting.
User mungkin tidak tahu apakah row height-nya sama dengan Finder. Mereka juga tidak akan menyebut "inline editor" atau "data model". Tetapi mereka bisa merasakan apakah sebuah interface rapi, tenang, dan punya niat.
Begitu juga pemilik store.
Jika halaman admin terasa berantakan, mengedit produk akan terasa melelahkan. Jika editornya terlalu berbeda dari tampilan produk, pemilik store perlu membayangkan ulang hasil akhirnya. Tetapi jika editor mengikuti bentuk detail produk, proses edit terasa lebih dekat dengan hasil yang akan dilihat user.
Itu alasan kenapa inline editing terasa menarik.
Bukan karena terlihat canggih.
Tetapi karena ia mengurangi jarak antara mengatur data dan melihat produk.
Data Model Mulai Menuntut Disiplin
Ketika produk masih statis, struktur bisa terasa sederhana.
Tetapi begitu produk pindah ke Firestore dan gambar pindah ke Storage, data model mulai menuntut disiplin.
Produk tidak cukup hanya punya nama dan harga.
Ia perlu punya slug yang stabil, category, stock, price, salePrice, imageAssets, shipping dimension, content, dan status active. Foto produk tidak cukup hanya menjadi array URL. Lebih baik ada metadata yang cukup jelas: fileName, url, storagePath, dan urutan yang bisa dikontrol.
Kategori juga perlu dipikirkan.
Apakah category hanya field di product?
Atau category punya collection sendiri?
Untuk store yang akan tumbuh, category collection terasa lebih sehat. Ia bisa menyimpan label, status aktif, jumlah produk, dan nanti mungkin urutan atau metadata lain tanpa harus menebak dari produk satu per satu.
Branch juga begitu.
Cabang bukan sekadar alamat. Ia adalah origin pengiriman. Ia punya areaId, latitude, longitude, contact, dan hubungan langsung dengan shipping rate. Kalau nanti stok per branch mulai digunakan, branch akan menjadi bagian penting dari keputusan checkout.
Semakin jauh store berjalan, semakin jelas bahwa data tidak bisa disusun asal cukup jalan.
Data harus disusun agar keputusan berikutnya masih mungkin.
Itu salah satu pelajaran paling penting dari membangun store kecil: jangan membuat data model terlalu besar sejak awal, tetapi jangan juga membuatnya terlalu sempit sampai setiap perubahan kecil menjadi migrasi besar.
Payment dan Shipping Mengubah Rasa Seriusnya
Store mulai terasa sungguhan ketika payment dan shipping masuk.
Sebelum itu, store masih bisa terasa seperti katalog.
Tetapi begitu user bisa checkout, membayar, menerima order number, melihat status payment, memilih shipping, dan membuka tracking, sistemnya masuk ke wilayah trust.
Di sini UI tidak boleh hanya cantik.
Ia harus jelas.
Jika payment pending, user perlu tahu bahwa mereka bisa continue payment.
Jika payment paid, user sebaiknya diarahkan ke order yang relevan.
Jika order punya tracking link, user perlu melihatnya di tempat yang masuk akal.
Jika pengiriman instant punya driver name, phone, plate number, dan photo, data itu perlu tampil dengan rapi di order detail, bukan tersembunyi di Firestore.
Shipping juga punya kompleksitas sendiri. Rate tidak hanya angka. Ia dipengaruhi origin, destination, courier, service type, areaId, weight, dimensi, dan coverage. Jika integrasi eksternal berubah, UI harus cukup fleksibel agar tidak terkunci pada satu vendor secara visual.
Di titik ini, saya semakin merasa bahwa e-commerce bukan hanya soal transaksi.
E-commerce adalah sistem kepercayaan kecil.
Setiap status, setiap label, setiap order detail, setiap email, setiap notifikasi, dan setiap tracking link ikut membangun rasa percaya itu.
Kenapa Tidak Dibuat Seperti Dashboard Biasa?
Pertanyaan ini wajar.
Kenapa tidak membuat admin dashboard biasa saja?
Jawaban paling sederhana: bisa.
Dan untuk banyak bisnis, itu mungkin pilihan terbaik.
Tetapi dalam konteks website ini, saya ingin store terasa sebagai bagian dari dunia yang sama. User melihat Store Window. Pemilik store mengatur dari Settings Window. Keduanya masih berada di bahasa visual yang sama.
Itu membuat sistem terasa lebih utuh.
Bukan berarti semua hal harus dibuat lucu atau eksperimental. Justru sebaliknya: semakin playful permukaannya, semakin disiplin fondasinya perlu dijaga.
Store Window boleh terasa elegan.
Settings Window boleh terasa seperti bagian dari desktop.
Tetapi payment harus aman.
Shipping harus akurat.
Order harus tersimpan benar.
Webhook harus bisa dipercaya.
Email harus jelas.
Status harus dipetakan dari sumber yang benar.
Jadi perbedaannya bukan antara "serius" dan "playful".
Perbedaannya adalah antara sistem yang punya rasa dan sistem yang kehilangan rasa.
Saya ingin yang pertama.
CMS yang Menyatu dengan Produk
Ada satu hal yang saya suka dari pendekatan ini: CMS tidak berdiri sebagai dunia lain.
Ketika mengedit produk, saya ingin bentuknya dekat dengan product detail. Foto tetap terasa seperti carousel. Nama produk tetap berada di posisi yang familiar. Harga, diskon, deskripsi, detail, size chart, dan shipping tetap dibaca seperti bagian dari produk, hanya saja bisa diedit ketika mode edit aktif.
Dengan cara ini, editor tidak terasa seperti form panjang yang jauh dari hasil akhir.
Ia terasa seperti produk yang sedang dibuka lapisannya.
Untuk foto, logikanya juga perlu hati-hati.
Di Add Product, foto sebaiknya menjadi draft dulu. User bisa melihat preview, mengatur urutan, menghapus, lalu saat create barulah file diupload ke Storage dan URL disimpan ke Firestore.
Di Edit Product, pendekatannya bisa lebih fleksibel, tetapi tetap harus menjaga rasa aman: preview lokal tetap penting, minimal satu image tetap perlu dijaga, dan perubahan sebaiknya jelas sebelum disimpan.
Hal-hal seperti ini terdengar kecil, tetapi sangat menentukan apakah CMS terasa nyaman atau melelahkan.
Karena CMS yang baik bukan hanya tentang bisa mengubah data.
CMS yang baik membuat perubahan terasa terkendali.
Pelajaran dari Store Window
Semakin saya membangun Store Window, semakin saya merasa bahwa e-commerce kecil tetap membutuhkan arsitektur yang serius.
Bukan arsitektur yang besar-besaran.
Tetapi arsitektur yang punya batas jelas.
Front office dan back office perlu dibedakan.
Data display dan data editing perlu punya hubungan yang dekat.
Product detail untuk user dan product detail untuk owner perlu terasa satu keluarga.
Category, product, branch, order, payment, dan shipping perlu punya tempat masing-masing.
Integrasi eksternal seperti payment gateway dan shipping API perlu mengikuti dokumentasi resmi, bukan ditebak dari hasil coba-coba.
SEO tetap perlu dijaga, karena produk dan tulisan adalah bagian dari permukaan publik website.
Dan yang tidak kalah penting: UI tidak boleh kehilangan rasa.
Karena untuk store indie, rasa itu bagian dari brand.
Orang tidak hanya membeli barang dari sistem.
Mereka membeli dari pengalaman yang membuat mereka percaya.
Penutup
Membangun Store Window membuat saya melihat e-commerce dengan cara yang sedikit berbeda.
Sebuah store tidak harus langsung terasa seperti dashboard besar.
Ia bisa mulai dari sebuah window kecil.
Ia bisa tumbuh pelan-pelan.
Ia bisa punya product card yang clean, checkout yang serius, order detail yang jelas, dan Settings Window yang berfungsi sebagai CMS.
Ia bisa tetap personal tanpa menjadi asal-asalan.
Ia bisa playful tanpa kehilangan disiplin.
Ia bisa terasa seperti bagian alami dari website, bukan fitur yang ditempel belakangan.
Pada akhirnya, Store Window bukan hanya tentang menjual produk.
Ia tentang bagaimana sebuah website personal mulai belajar menerima transaksi, mengatur data, menjaga kepercayaan, dan tetap mempertahankan karakternya sendiri.
Dan bagi saya, itu jauh lebih menarik daripada sekadar membuat halaman toko biasa.
