Studi kasus UX: Aplikasi self-service untuk berbelanja
Akhir-akhir ini saya berfikir tentang: Kenapa antrian di supermarket tetap panjang? Apakah karena masih banyak yang belum mau menggunakan uang elektronik sebagai metode pembayaran? Dan apa alasannya?
Padahal yang kita tau, sekarang sudah banyak sekali uang elektronik yang seharusnya mempersingkat waktu pembayaran dan memperpendek antrian.
The Problem I’m assuming is...
Saat seseorang sedang berbelanja, mereka pasti ingin proses transaksi yang cepat dan tentu juga antrian yang sedikit. Mungkin bagi kita menunggu sedikit lebih lama untuk melakukan transaksi itu tidak apa-apa, namun bagaimana jika ada seseorang hanya ingin membeli 1 botol air mineral namun harus mengantre sama lamanya dengan yang membeli 10 barang?
Bagi kalian yang sedang terburu-buru karena dikejar waktu atau sekedar hanya ingin membeli 1 bungkus cemilan pasti tidak mau menunggu 20 menit hanya untuk membayar 1 bungkus cemilan bukan?
Tapi kan.. supermarket di Indonesia sudah ada yang menggunakan metode self checkout. Menurut saya self checkout hanya menyelesaikan masalah jika semua pengantre hanya membeli satu atau dua barang, mungkin 5? Jika salah satu pelanggan membeli lebih dari itu, yang mengantre tentu saja tetap harus menunggu sama lamanya dengan yang melakukan proses trasaksi di kasir biasa.
Jadi dalam studi kasus ini saya mengasumsikan 2 kemungkinan yang membuat antrian panjang dan proses transaksi yang lama, yaitu:
- Pelanggan masih tidak mau menggunakan uang elektronik
Kenapa? Menurut saya karena:
- Jika uang elektronik yang berbentuk kartu hilang dan ditemukan oleh orang yang tidak bertanggung jawab, orang tersebut bisa memakainya.
- Uang yang terdapat di dalamnya tidak bisa disetorkan lagi ke ATM lagi. Di Indonesia, masih banyak pengguna uang elektronik yang masih membutuhkan uang kartal untuk proses transaksi untuk membeli makanan atau barang di UKM-UKM atau sekedar untuk membayar tukang parkir.
Namun yang kalian perlu ketahui, untuk masalah nomor 1, layanan uang elektronik seperti GOPAY dari GOJEK telah menangani masalah ini dengan fitur withdraw dan kerjasama antar UKM dengan memberikan barcode yang ditempatkan oleh pemilik UKM tersebut di gerobak (misalnya) agar pembeli bisa melakukan transaksi dengan menggunakan GOPAY.
2. Proses pembayaran sudah dipermudah dengan uang elektronik namun proses saat di kasir terlalu banyak dan lama, mulai dari proses peng-scanan dan pembayaran.
Mari kita buktikan asumsinya. Research section!
Sebelum mendesain tentunya kita harus melakukan proses ini terlebih dahulu agar mengetahui apakah masalah yang diasumsikan benar dirasakan oleh pelanggan.
Karena asumsi saja tidak cukup, bisa saja kesulitan yang saya rasakan tidak dirasakan orang lain.
Dengan itu saya membuat survey online yang berisikan pertanyaan-pertanyaan seputar studi kasus ini.
Terdapat 22 Responden yang mengisi survey saya, mulai dari yang masih bersekolah (54,5%) hingga yang sudah berkerja (45,5%), dan sudah dapat dipastikan pernah berbelanja di supermarket.
Dari hasil survey yang saya terima, banyak responden yang jarang (1–7x dalam sebulan) dan banyak juga yang sering (8–15x dalam sebulan) berbelanja di supermarket.
Setelah itu saya coba menanyakan payment method yang sering dipakai oleh responden. Saya mendapatkan hasil yang menunjukan bahwa 18 dari 22 orang lebih sering menggunakan tunai, 4 dari 22 orang lebih sering menggunakan uang elektronik, dan 0% yang menggunakan debit/credit card sebagai payment method-nya.mI come up with an idea
Bagaimana jika ada sebuah Uang elektronik berbasis mobile bernama Mollet yang bisa meminimkan proses di kasir dengan cara memindahkan proses di kasir tersebut ke bentuk mobile, seperti peng-scanan dan pembayaran.
Dan karena ada beberapa pain point pada user saat menggunakan uang elektronik, saya menyimpulkan untuk membuat uang elektronik ini harus
- Praktis dan fleksibel saat digunakan
- Uang yang terdapat di dalamnya bisa diuangkan kembali
- Top-up bisa dari aplikasi yang terhubung dengan bank
- Bisa membayar dalam keadaan offline (Berguna jika internet sedang tidak stabil)
- Proses scan cepat, tidak perlu banyak yang harus diklik untuk melakukan pengscanan
- Dan tentunya terdapat fitur seperti pembayaran listrik, Pengisian pulsa, dll.
Shopping flow
Flow di bawah ini adalah flow berbelanja menggunakan sistem berbelanja pada umumnya dilakukan setiap orang, mulai dari mencari barang yang ingin dibeli sampai proses transaksi selesai.
Keterangan: Flow yang berwarna merah adalah flow yang memakan waktu dan berdampak pada panjang dan lamanya antrian.
Shopping Flow: Tunai & uang elektronik
Jika diperhatikan memang terjadi banyak flow hanya untuk seseorang yang menggunakan tunai.
Dan untuk seseorang yang menggunakan uang elektronik tentu mempunyai banyak flow yang sama dengan Mollet.
Lalu apa pembedanya? Tentu saja lamanya waktu saat mengantre.
Dengan Mollet tentu saja antreannya tidak membutuhkan waktu yang lama, karena tidak ada proses peng-scanan barang saat di kasir.
Kan bisa buat kasir khusus pengguna uang elektronik? Tentunya proses peng-scanan barang oleh pegawai kasir tetap ada, yang membuat waktu antrean tetap lebih lama.
Shopping Flow: Mollet
Mungkin jika diperhatikan, Mollet tentu memiliki flow yang sedikit dan tidak banyak aksi yang dilakukan saat di kasir. Namun saya memikirkan kemungkinan terburuk yang bisa saja terjadi di beberapa flow di atas, yaitu :
- Bagaimana jika terdapat segerombolan orang yang ingin mengscan barcode dari sebuah produk yang sama dalam waktu yang bersamaan? Bukankah itu bisa menyebabkan terjadinya sebuah antrean pada tempat diambilnya barang? Jika difikirkan, hal ini akan sangat minim terjadi karena meng-scan sebuah barcode tidak dibutuhkan waktu sampai 30 detik. Namun jika terjadi sebuah antrian, tentunya tidak akan memakan waktu yang lama.
Pada formulir survey yang sama, saya menanyakan kepada reponden, Apa yang lebih mereka pilih? Mengantre lama untuk meng-scan barcode atau melakukan pembayaran di kasir? Dan saya mendapatkan Data berupa 15 dari 22 orang lebih suka mangntre lama untuk mengscan barcode.
Alasan 15 orang tersebut beralasan jika hanya meng-scan barcode, prosesnya tidak banyak, tentunya lebih efisien dan tidak memakan waktu yang lama.
- Bagaimana dengan plastiknya? User sudah seharusnya membeli tote bag khusus berbelanja, sudah saatnya kita mengurangi sampah plastik.
Dari hasil survey yang sama, sebagian besar responden setuju untuk tidak menggunakan plastik dan membawa tas khusus untuk berbelanja.
User Persona
Persona ini saya dapatkan setelah mengumpulkan dan menyimpulkan semua goals yang diinginkan dan frustration yang dialami oleh responden yang telah menjawab kuesioner pada survey yang saya sebarkan.
Jihan adalah sebuah persona yang saya gambarkan sebagai seorang karyawan di salah satu startup dengan umur 25 tahun yang memiliki hobi berbelanja.
User Flow
Dalam bagian ini saya membaginya menjadi 2 kondisi tempat, yaitu:
Tempat yang mengharuskan user mengambil barangnya sebelum ke kasir
Tempat yang dimaksudkan di sini adalah tempat yang user-nya harus mengambil barang yang ingin dibeli sebelum ke kasir. Contohnya: Supermarket, Mini market, dan lain-lain.
Tempat yang usernya langsung memesan dan membayar barangnya di kasir
Tempat yang dimaksudkan di sini adalah tempat yang user-nya langsung ke kasir untuk memesan dan membayar barangnya. Contohnya: Kafe, Tempat makan, dan lain-lain.
Grid
Bagian ini hanya berisikan penjelasan tentang jarak antar grid yang saya gunakan. Jika dirasa tidak perlu diketahui, silahkan lanjut ke bagian selanjutnya yaa..
Grid ini saya buat untuk proses pembuatan low fidelity agar panjang dan lebar dari suatu komponen di dalam UI ini konsisten dan balance.
Grid ini tentunya terdapat kejanggalan di bagian kolom ke 3 dari kanan yang hanya memiliki lebar kolom sebesar 63, namun yang lainnya 64.
Itu disebabkan oleh artboard dari Iphone X/XS yang ganjil. Angka 63 saya dapatkan dari perhitungan yang matang, sehingga saya mendapatkan perbandingan yang sangat pas, yaitu hanya berbeda 1px dari yang lain.
namun walaupun berbeda 1px, saya yakin user tidak akan menyadari perbedaan tersebut, tentunya karna hanya 1px.
Untuk bagian yang saya berikan angka 2, itu menandakan panjang dari kolom tersebut adalah 20px dan untuk bagian yang lebih kecil dari angka 2, sudah dipastikan berukuran 10px.
Dan untuk bagian yang saya berikan warna abu-abu gelap di atas, itu adalah status bar, jadi komponen untuk UI-nya sendiri tidak melebihi batas status bar.
Untuk bagian berwarna abu-abu gelap di bawah, itu adalah bagian yang tidak berfungsi, yang saya maksudkan adalah bagian tersebut adalah bagian untuk user kembali ke home iPhone X/XS, karena iPhone X/XS menggunakan gesture swipe up untuk kembali ke home pada bagian yang memiliki tinggi 13px tersebut. Jadi walaupun di bagian tersebut terdapat sedikit bagian dari button, tetap bagian 13px tersebut tidak berfungsi.
Wireframing and Low Fidelity
Bagian ini hanya berisikan preview dari Beberapa hasil lo-fi. Jadi jika kalian ingin langsung melihat penjelasan tiap halaman, silahkan langsung menuju bagian high fidelity.
Seperti pada studi kasus sebelumnya, dalam pembuatan wireframe, saya hanya membuatnya di secarik kertas untuk menentukan flow dan apa saja informasi yang akan ditampilkan pada tiap halaman. Jadi di Adobe XD saya langsung membuat low fidelity-nya untuk menyusun konten, informasi, dan sekaligus copywriting.
Sebenarnya saya lebih suka langsung membuat ke high fidelity-nya karena ketika langsung membuat high fidelity saya merasa lebih cepat mendapat gambaran bagaimana hasilnya nanti dan sekaligus bisa langsung dilihat lewat prototype pada Adobe XD apakah ukuran font, icon, dan tombolnya terlalu kecil, terlalu besar, atau bahkan tidak cocok jika desainnya sudah diterapkan.
Perlu diketahui, Bahwa hasil hi-finya akan lumayan berbeda dengan yang desain lo-finya, mulai dari letak informasi, letak button, dan lain-lain. Namun untuk informasi dan tujuan dibuatnya halamannya tersebut tetap sama dengan lo-fi.
Color and Typography Guideline
Favorite part, High Fidelity!
Sebelum mulai, saya ingin memberitahukan bahwa ilustrasi dan icon yang saya gunakan di design ini adalah bukan karya saya.
Ilustrasi yang saya gunakan, kalian bisa dapatkan di ICONS8 https://icons8.com/ouch.
Dan Icon yang saya gunakan, kalian bisa dapatkan di Feather https://feathericons.com.
Baiklah, Mari kita mulai.
Login
Bagian login ini saya desain sesimpel mungkin dan tentunya menggunakan rangkaian susunan informasi yang familiar diketahui oleh semua orang, mulai dari yang muda hingga yang sudah berumur.
Halaman ini sekaligus berguna sebagai splash screen. Jadi pengguna tentunya tidak melewatkan bagian splash screen yang memberikan informasi penting tentang keuntungan jika menggunakan Aplikasi ini.
Home
Untuk feature icon, saya belum membuatnya. Kenapa? Menurut saya akan lebih bagus jika icon pada deretan fitur tersebut menggunakan icon sama seperti yang Bukalapak, Tokopedia, dll gunakan. Yang tentunya perlu Adobe Illustrator, dsb untuk membuatnya.
Kenapa saya perlu membuatnya seperti para unicorn tersebut? Agar nantinya icon tersebut bisa lebih menonjol untuk merepresentasikan fungsi dari fiturnya. Jadi saya akan mengupdate hi-fi khusus home setelah saya belajar menggunakan Illustrator.
Oke kalau begitu, Mari kita mulai.
Mungkin kalian bingung kenapa saya membuat home yang langsung mengaktifkan kamera. Jadi dengan kamera yang langsung aktif saat user membuka aplikasi, user tidak perlu melakukan banyak aksi hanya untuk meng-scan barang. Jika kamera perlu diaktifkan melalui satu button terlebih dahulu, tentunya aksi tersebut memakan 1 flow.
Sekaligus menerapkan goals yang saya ingin implementasikan, yaitu fleksibel yang tentu tidak membutuhkan banyak aksi hanya untuk meng-scan barang. Fleksibelitas ini tentunya terinspirasi dari uang elektronik berbentuk kartu yang memungkinkan user melakukan pembayaran dengan sedikit aksi.
Untuk penyusunan informasi tentunya dimulai dari informasi mengenai jumlah saldo. Jumlah saldo saya buat se-eye catching mungkin agar user selalu melihat informasi tersebut untuk mengecek jumlah saldonya.
Lanjut kebagian bottom sheet, kita mulai dengan deretan fitur di paling atas. Dari susunan fitur tersebut saya susun dari yang paling penting yaitu paling kanan sampai yang mungkin jarang dipakai, yaitu paling kiri.
Kenapa saya meletakan fitur yang paling penting di sebelah kanan?
Karena fitur yang paling kanan akan lebih mudah dijangkau ketimbang yang paling kiri. Walaupun begitu, tetap saja fitur-fitur ini saya tempatkan di safe area untuk dua tipe pengguna, tipe penggunaan tangan kanan dan tipe penggunaan tangan kiri.
Safe areas ini adalah salah satu alasan saya meletakan tombol kembali di luar safe areas, tepatnya di sebelah kiri dari informasi saldo.
Agar user tidak menekan tombol tersebut atas dasar ketidaksengajaan. Karena saat di halaman cart, jika user menekan tombol kembali, itu akan membuat cart menjadi kosong kembali. Jadi dengan tombol yang tidak ada di dalam safe areas, tentunya untuk menekan tombol tersebut memerlukan pemikiran yang matang.
Setelah itu ada bagian untuk promo banner. Saya membuatnya terlihat tanpa perlu di-scroll ke bawah yang tentunya memudahkan user untuk melihat promo dan informasi yang tersedia.
My QR
Pada Halaman My QR ini, user diberikan QR Code-nya dan beberapa informasi mengenai cara penggunaan QR Code. Informasi cara penggunaannya saya sisipkan di baris keempat yang berbunyi “How? Simple, Just give this to Cashier”. Kenapa hanya itu? Karena hanya itulah langkah yang diperlukan untuk melakukan transaksi menggunakan aplikasi ini.
Dan satu lagi, karena hasil research menyebutkan bahwa aplikasi ini harus bisa melakukan pembayaran walaupun sedang mengalami error atau internet user sedang tidak stabil, dengan itu saya membuat tombol “Save” yang berguna untuk menyimpan QR Code user ke gallery yang dapat digunakan untuk melakukan pembayaran yang nantinya saldo akan otomatis terpotong jika internet user telah stabil.
Cart
Halaman cart akan muncul jika user telah meng-scan suatu QR Code dari sebuah barang. Jika diperhatikan, di sebelah informasi balance mulai muncul tombol untuk kembali yang menggeser 20px informasi balance ke kanan.
Mengapa ketika bottom sheet diswipe-up, kamera dioverlay oleh kotak berwarna abu-abu? Ini bertujuan membuat user lebih fokus untuk melihat dan melakukan action pada barang yang ada di dalam cart. User juga tentunya tidak akan melakukan peng-scanan dengan keadaan kamera tertutup 80% oleh bottom sheet bukan?
Informasi yang saya berikan mulai dari atas bottom sheet halaman ini yaitu:
- Total Price: Yaitu bagian yang memberikan informasi kepada user besarnya uang yang harus dibayarkan.
- Total Item: Yaitu bagian yang memberikan informasi kepada user jumlah quantity barang yang ada di dalam cart.
Di bagian bawah dari informasi di atas adalah barang-barang yang telah di-scan oleh user. Di kontainer berwarna abu-abu pada setiap barang, terdapat infomasi, yaitu:
- Gambar barang: Saya memutuskan untuk memberikan gambar di setiap barang yang dibeli user agar user mudah mencari barang yang ada di dalam cart-nya. Karena yang saya tau, manusia lebih gampang mencari melalui sisi visual.
- Nama barang: Tentunya nama barang yang dibeli user perlu ditampilkan agar user tau barang apa saja yang masuk kedalam cart-nya. Di sini saya membuat nama barang terlihat lebih jelas ketimbang harga dan jumlahnya, karena jika di dalam cart sudah berisikan sangat banyak barang, user akan gampang mencarinya, untuk sekedar mengecek jumlahnya, harganya, mengarchieved atau mungkin mengapusnya.
- Harga Barang: Bagian ini yang akan memberikan informasi kepada user harga dari barang yang dibeli. Jika barang ditambah kuantitasnya, Informasi ini tidak akan bertambah sesuai kuantitasnya. Karena yang akan berubah hanya bagian total price. Kenapa? agar user mengetahui jumlah uang yang akan berkurang di total price jika user ingin mengurangi kuantitas barang yang ingin kuranginya.
- Kuantitas barang: Agar user tau berapa jumlah kuantitas pada satu merek barang yang dibelinya. Kenapa perlu? Misalnya kita membeli 3 buah barang, dengan informasi ini kita tau bahwa 2 barangnya adalah susu misalnya dan 1 barangnya lagi adalah permen. Tapi kan kalau hanya sedikit, user tinggal melihat di keranjangnya secara langsung? Oke, tapi bagaimana jika di keranjang user terdapat 30 Barang dan setiap barangnya ada barang yang dibeli lebih dari 1? Tentunya sangat sulit untuk mengetahui kuantitas dari satu barang yang ingin diketahui kuantitasnya.
Apa yang terjadi pada barang di dalam cart jika User menekan tombol kembali? Barang yang ada di dalam cart tentunya akan hilang. Karena itu tombol kembali diletakan di ujung kiri atas yang lumayan susah dijangkau untuk menghindari aksi menekan tanpa disengaja.
Selanjutnya, di bawah ini adalah gambaran setelah user meng-scan barang yang ingin dibelinya, ada yang tampilan jika success (kiri) dan juga jika failed (kanan).
Bagian success (kiri) akan muncul untuk menginformasikan user bahwa barang yang di-scan telah berhasil dimasukan ke dalam cart. Dan Bagian failed (kanan) akan muncul jika barang yang di-scan user gagal dimasukan ke dalam cart.
Mengapa barang yang discan bisa failed atau gagal dimasukan ke dalam cart? Hal ini bisa terjadi jika barang tersebut belum didaftarkan oleh pihak supermarket atau barang tersebut telah kadaluarsa.
Action yang bisa dilakukan di dalam Cart
Di dalam cart saya menambahkan action untuk menghapus atau meng-archieve barang.
Untuk apa fitur archieve? fitur archieve dibutuhkan jika user dalam kondisi kurang yakin untuk membeli barang tersebut namun user tidak ingin mengembalikan barang tersebut ke tempat asalnya. Karena jika berubah pikiran dan ingin memasukan barang tersebut ke cart lagi, user perlu kembali ke tempat barang tersebut diambil dan harus mengscan ulang.
High fidelity di sebelah kanan adalah gambaran letak barang yang di-archieve berada. User hanya perlu swipe ke kanan lagi untuk mengembalikannya ke dalam cart.
Receipt
Receipt adalah halaman yang akan muncul setelah user menekan tombol “pay” di halaman cart sebelumnya. Jika user sudah berada di dalam halaman ini, sudah dipastikan user telah menyetujui jumlah, total harga, dan kuantitas barang untuk melakukan pembayaran, sehingga pada halaman ini tidak terdapat tombol untuk menambahkan kuantitas dari suatu barang dan juga user di halaman ini mendapatkan QR Code khusus yang digunakan untuk melakukan pembayaran sesuai jumlah total harga.
Seperti namanya, receipt, halaman ini menginformasikan user apa saja barang yang telah dibeli beserta jumlahnya dan juga menginformasikan jumlah total yang harus dibayarkan oleh user.
Untuk apa tombol “?” di dekat QR Code tersebut? Itu akan membawa user ke halaman di bawah ini yang menginfomasikan user apa dan bagaimana cara menggunakan QR Code tersebut.
Bagaimana jika user menekan tombol kembali? Apakah semua barang yang ingin dibayarkan hilang dari cart atau receipt?
Jawabannya tidak, user akan dibawa ke halaman home namun dengan kamera yang digantikan QR Code yang ada di halaman receipt sebelumnya seperti desain di bawah ini.
Apa yang akan terjadi jika user menekan tombol “X” yang berada di dalam lingkaran merah tersebut? Yang terjadi adalah halaman di bawah ini akan muncul untuk memberitahukan kepada user apa gunanya tombol tersebut dan juga menanyakan kembali ke user apakah mereka yakin untuk menghapus receipt tersebut. Karena jika terhapus, QR Code yang berisikan barang yang akan dibeli akan hilang, sehingga pembayaran tentu dibatalkan.
Penghujung acara..
Dalam studi kasus ini sebenarnya saya menawarkan solusi baru untuk proses transaksi di supermarket yang bertujuan membuat proses transaksi yang cepat dan fleksibel.
Seperti halnya Lippo Group yang menggandeng OVO sebagai solusi untuk pembayaran parkir, solusi saya yang ada di dalam studi kasus ini juga harus adanya kerja sama antar dengan pihak supermarket (Khusus fitur scan, cart dan receipt) agar solusi ini berjalan dengan baik. Karena jika tidak, tentunya user yang tidak menggunakan aplikasi ini akan teteap membuat antrian panjang dengan melakukan peng-scanan dan pembayaran di kasir.
Dari membuat studi kasus ini, saya pikir masih banyak kekurangan saya dalam membuat studi kasus mulai dari sisi UX, UI, research, maupun copywriting. Dengan selesainya studi kasus ini, mungkin saya akan mulai belajar lebih dalam lagi mengenai reserch, UI, UX, dll. agar studi kasus selanjutnya lebih memuaskan dari semua sisi.
Dan juga desain ini dibuat Based on data, sesuai hasil research yang saya harapkan bisa memenuhi kebutuhan user dan calon user.
Sekian studi kasus dari saya, semoga di studi kasus ini bisa menginspirasi orang-orang yang ingin membuat studi kasus juga dan juga untuk menambah ilmu dan pengalaman saya dalam memecahkan masalah melalui desain.
Tertarik membuat Studi kasus?
Untuk kamu yang ingin memulai membuat studi kasus, Perlu diketahui membuat studi kasus dalam bidang UI & UX Design tidak hanya tentang mengeksplorasi desain dari visual loh! Melainkan dari semua sisi, mulai dari copywriting, research, hingga prototyping. Selain mengasah kemampuan kita dalam mempercantik visual, menurut saya membuat studi kasus juga mengasah kemampuan kita dalam problem solving.
Jika kalian butuh inspirasi dan referensi dalam membuat studi kasus, ini adalah dua designer yang menurut saya sangat patut dijadikan inspirasi dalam membuat studi kasus: Dwinawan dan Briandito Priambodo.
