Case Study : Building Regional Super-Apps (Part 1)
Bagian 1 — Personal Vacation Guide
Pendahuluan
Melakukan redesign sebuah aplikasi memang memiliki sensasi unik tersendiri, tapi melakukan perubahan konsep aplikasi selalu lebih menantang. Seperti project satu ini yang memiliki tantangan tersendiri yang belum pernah saya dapatkan di project-project sebelumnya.
Nama aplikasi yang akan saya bahas kali ini adalah JogjaKita (bisa di cek di Playstore). Pada awalnya, aplikasi ini hanyalah sebuah aplikasi pembayaran digital regional yang bertujuan untuk mempermudah warga Jogja dalam bertransaksi melalui media smartphone dan cashless.
Secara konsep dasar, sebenarnya aplikasi ini memiliki potensi yang cukup baik mengingat Jogjakarta masih memiliki literasi teknologi yang belum terlalu advanced, sehingga bisa digunakan untuk memberi edukasi teknologi kepada warga Jogja mengenai pembayaran cashless. Sehingga, secara design-pun belum se-advanced aplikasi yang saat ini beredar di masyarakat tanpa mengurangi value dari aplikasi itu sendiri.
Pada versi terdahulu, JogjaKita masih terlalu minim fitur. Mengingat hanya ada fitur pembayaran digital yang bahkan sudah ada di platform lain. Dan oleh karena itu, dan setelah diskusi 3H (Hipster, Hustler, Hacker), maka diputuskan bahwa akan dilakukannya re-vamp terhadap aplikasi ini, baik dari segi design maupun dari segi konsep dasar (target market, UVP, dll).
Berikut adalah main points hasil dari diskusi antara tim product dan tim bisnis :
1. Melakukan perubahan konsep dasar
Pada versi sebelumnya, konsep aplikasi ini hanya sebatas pada pembayaran digital dan cashless saja, sehingga cenderung terlalu stereotype dengan aplikasi sejenis. Dan akhirnya konsep aplikasi ini diubah menjadi super-app yang bisa menjadi aplikasi companion bagi warga lokal Jogja maupun turis yang sedang melakukan wisata maupun hanya sekedar backpacking ke Jogjakarta, mengingat Jogjakarta juga terkenal dengan bidang pariwisata dan kebudayaannya.
2. Melakukan perubahan user persona
Dengan perubahan konsep aplikasi, maka target pasar juga akan sedikit bergeser. Pada versi sebelumnya, yang menjadi target pasar utama adalah warga asli Jogja yang berwirausaha dan membutuhkan inovasi pembayaran cashless. Sedangkan untuk versi terbaru, target pasarnya meluas. Dengan memperkuat dari sisi pariwisata, aplikasi ini juga sangat cocok jika ditargetkan ke backpacker atau orang yang hobi berwisata ke Jogjakarta.
3. Melakukan perubahan UVP (Unique Value Proposition)
Pada versi lama, JogjaKita masih belum terlalu mempertajam dari sisi UVP. Akan tetapi, di versi terbaru ini JogjaKita akan dikenal sebagai aplikasi travel companion bagi turis yang membutuhkan guidance saat backpacking ke Jogja, tanpa meninggalkan fungsi awalnya yaitu sebagai aplikasi pembayaran digital bagi warga Jogja.
4. Penambahan fitur-fitur
Evolusi suatu aplikasi terasa tidak lengkap jika tidak ada penambahan fitur. Oleh karena itu, untuk semakin mempermudah masyarakat yang sedang ada di Jogjakarta, aplikasi ini juga menambahkan beberapa fitur yang telah di-request oleh mayoritas pengguna lama dari aplikasi ini, yaitu salah satunya adalah : Layanan transportasi (ojek motor, ojek mobil, kirim barang, beli makan online, dan beli barang online). Jadi, salah satu tujuan utama dari aplikasi ini adalah menjadikan Jogjakarta sebagai percontohan digitalisasi kehidupan masyarakat, sehingga saat ada orang yang mau ke Jogja maka yang pertama kali akan dilakukan adalah dengan mendownload aplikasi JogjaKita.
Karena semua akan Super-Apps pada waktunya — Tech In Asia
Jadi, pada akhirnya kami putuskan bahwa JogjaKita akan menjadi Super-Apps yang bersifat regional, sehingga warga Jogja dan bahkan orang yang ingin berwisata ke Jogja dapat menggunakan aplikasi ini sebagai Companion. Dan juga, dengan adanya aplikasi ini maka bisa menjadikan Jogjakarta sebagai percontohan dari Smart City dan selanjutnya dapat ditiru oleh daerah-daerah lain, sehingga dapat menjadikan literasi teknologi di Indonesia menjadi lebih baik lagi. Seperti tagline terbaru dari JogjaKita, Dari Jogja untuk Indonesia.
Design Process
Setelah mendapatkan brief berupa perubahan-perubahan yang lumayan signifikan, proses revamp atau redesign dimulai dan dilakukan menggunakan Design Thinking Process untuk menghasilkan design yang User Centered.
1. Problems
Sebelum memulai semua tahapan, alangkah baiknya jika kami menentukan permasalahan apa saja yang kiranya dialami oleh user dan dapat disolusikan dengan aplikasi ini. Adapun tahapan dari proses Defining Problems ini antara lain menentukan User Persona, kemudian menentukan jenis metode riset, dan melakukan riset yang pada akhirnya dapat disimpulkan apa saja yang menjadi pokok permasalahan yang dialami user dan dapat disolusikan dengan aplikasi ini.
User Persona
Karena terdapat perubahan User Persona, maka sangat perlu untuk melakukan riset ulang untuk menentukan kembali permasalahan dasar yang dialami orang yang suka travelling atau backpacking. Oleh karena itu, kami melakukan interview dengan 15 orang dengan kriteria sebagai berikut :
- Usia 21–30 tahun. Universal
- Suka travelling atau backpacking
- Literasi teknologi sedang
- Bukan warga Jogjakarta
- Memiliki interest dengan Jogjakarta
Khusus untuk fitur tentang travelling, kami memutuskan untuk menggunakan pendapat dari responden yang bukan warga Jogjakarta. Hal ini dikarenakan mayoritas warga Jogjakarta mengetahui detail wisata apa yang berada di Jogjakarta bahkan tanpa aplikasi sekalipun. Sehingga kami memutuskan untuk mempersempit kriteria responden.
Tambahan :
Kami melakukan riset per fitur. Jadi kami menggunakan User Persona yang berbeda-beda pada setiap fitur yang ada di aplikasi JogjaKita. Contoh : untuk fitur Ride-Hailing, kami menggunakan persona dari warga lokal di Jogjakarta mengingat fitur tersebut memang ditujukan untuk memudahkan akomodasi dari warga Jogjakarta. Untuk lebih lengkapnya, akan saya buat Case Study baru khusus untuk masing-masing fitur, karena terdapat perbedaan target pasar dan metode riset.
Metode Research
Tahapan research yang kami gunakan adalah dengan menggunakan metode Kualitatif, yaitu dengan menggunakan metode User Interview. Kami memilih interview karena kami dapat mendapatkan apa yang sebenarnya diinginkan user. Mengingat jika menggunakan form, maka kami tidak dapat melihat intonasi dan ekspresi user saat menjawab pertanyaan, sehingga ditakutkan hasil yang didapatkan kurang sesuai dengan apa yang calon user inginkan.
Selain itu, dengan melakukan User Interview langsung, kami bisa make sure bahwa hasil dari riset adalah benar-benar yang sesuai dengan User Persona yang telah kami konsep dan buat di fase awal. Sehingga hasil dari riset tersebut diharapkan akan menjadi sebuah solusi tepat yang dapat menyelesaikan masalah dari calon user.
Kami menggunakan metode interview langsung dan mencatat poin-poin penting dari responden. Berikut adalah beberapa pertanyaan pokok yang kami tanyakan kepada 10 responden :
- Bisa kasih tau kita nggak tentang kendala saat melakukan backpacking ?
- Biasanya saat persiapan sebelum backpacking, hal pertama yang kamu pertimbangkan itu apa aja ?
- Selama melakukan backpacking, pernah nggak sih kecewa dengan destinasi wisatanya ? Bisa dijelaskan lebih detail ?
Selanjutnya kami melakukan pengurutan dan pengelompokan dari permasalahan yang dialami oleh responden dengan metode Card Sorting. Berikut adalah hasil sorting dari masalah-masalah yang seringkali dialami oleh backpackers dalam berwisata. (Gambar 1.1)
Dari hasil Sorting, kami meringkasnya menjadi 3 masalah pokok, yaitu :
- Backpackers merasa lumayan repot saat menentukan destinasi wisata, karena mereka cenderung impromptu saat memutuskan mau liburan kemana. Biasanya, mereka harus mencari dulu di Google dan blog-blog travelling, baru kemudian cari lokasi di Google Map. Sehingga dirasa kurang praktis.
- Backpackers mempertimbangkan Tujuan dan Budget sebagai pertimbangan pertama sebelum melakukan backpacking, sehingga segala informasi yang berhubungan dengan budget akan sangat berharga bagi mereka.
- Backpackers seringkali kecewa dengan destinasi wisata saat destinasinya jauh dan ternyata ga sesuai ekspektasi. Belum lagi kalau tiba-tiba tutup tanpa pemberitahuan.
Nah, dengan data pokok masalah diatas, kami dapat melakukan langkah selanjutnya yaitu merumuskan solusi design.
2. Problem Solving / Design Solutions
Setelah mendapatkan inti dari permasalahan dari para backpackers, langkah selanjutnya yaitu Problem Solving atau mencari penyelesaian dari inti masalah yang telah ditemukan pada step sebelumnya. Proses ini merupakan proses yang paling menguras tenaga jiwa dan raga karena kami harus bisa berpikir bukan hanya sebagai designer, akan tetapi juga harus memikirkan dari segi bisnis (BCR : Budget, Cost, Revenue) dan juga yang paling penting adalah memikirkan deadline production.
Oleh karena itu, solusi yang paling kami cari yaitu solusi yang murah, mudah digunakan oleh user, dan juga yang paling cepat untuk diselesaikan oleh developer. Dan hal ini merupakan salah satu challenge yang paling berat yang harus kami hadapi dalam project ini.
Dikarenakan tenggat waktu produksi aplikasi yang dimampatkan, kami menggunakan metode HMW (How Might We) yang kemudian disortir lagi dengan menggunakan User Needs dan Efficient Development sebagai metrik utama.
Dari hasil sortir dan grouping tersebut, kami bisa mendapatkan beberapa solusi yang dibutuhkan user dan tidak membutuhkan effort berlebih dari sisi development, antara lain :
Problem 1 : Backpackers merasa lumayan repot saat menentukan destinasi wisata, karena mereka cenderung impromptu saat memutuskan destinasi wisata
Penambahan fitur destinasi wisata yang ada di Jogja merupakan solusi yang menurut kami tepat untuk permasalahan di atas. Kami juga menambahkan shortcut menuju Google Maps untuk petunjuk arah menuju destinasi wisata. Dan untuk mempersempit pilihan user, kami menggunakan patokan jarak antara posisi terkini user dengan destinasi wisata. Sehingga user dapat mempertimbangkan destinasi wisata yang berada di sekitarnya terlebih dahulu tanpa perlu browsing ke Google tentunya. Ditambah lagi, pada aplikasi versi baru ini, terdapat fitur baru yakni layanan transportasi antara lain ojek motor dan mobil, sehingga user yang tidak membawa kendaraan pribadi bisa menggunakan layanan transportasi tersebut.
Problem 2 : Backpackers membutuhkan informasi yang berhubungan dengan budget
Masalah ini sebetulnya penyelesaiannya cukup simple, yaitu cukup dengan menampilkan harga detail tentang destinasi wisata tersebut. Misalnya dengan menampilkan harga tiket masuk, harga parkir, harga sewa boat, dll. Akan tetapi dari segi development akan merasa cukup kesulitan jika harus mencari satu-per-satu. Oleh karena itu, harus melibatkan user dengan otoritas khusus yang dapat melakukan input data-data terkait detail wisata, misalnya : detail harga, jam buka, nomor CP, dll.
Problem 3 : Backpackers seringkali kecewa dengan destinasi wisata saat destinasinya jauh dan ternyata ga sesuai ekspektasi. Belum lagi kalau tiba-tiba tutup tanpa pemberitahuan
Penyelesaian dari masalah ini sudah disinggung di penyelesaian dari Problem 2, yaitu dengan mencantumkan detail jam buka dan preview foto dari destinasi wisata tersebut. Kami juga berencana akan menambahkan fitur rate pada destinasi wisata, akan tetapi dari sisi development fitur ini akan butuh waktu development yang lumayan lama, sehingga untuk fitur rate akan disusulkan di update fase kedua.
Setelah ditemukannya solusi, maka langkah berikutnya adalah membuat wireframe dengan menyatukan solusi-solusi yang telah ditemukan menjadi satu kesatuan flow.
3. Wireframe (Low-Fidelity Mockup)
Pembuatan Sitemap
Sebelum ke tahapan pembuatan wireframe dan untuk memudahkan dalam membuat wireframe lo-fi dan pada saat melakukan design hi-fi, kami membuat site-map terlebih dahulu sehingga pekerjaan yang akan dilakukan lebih jelas dan terarah. Pada tahapan ini, kami melibatkan developer untuk ikut serta, karena mereka yang akan membuat dan kami rasa developer juga harus dilibatkan setidaknya untuk di membuat sitemap dan saat setelah jadi user-flow lo-fi. Dan berikut adalah hasil sitemap untuk bagian Destinasi Wisata.
Untuk pada bagian Highlight bisa diinputkan manual pada admin dashboard, mengingat bersifat tematik berdasarkan kategori dan yang paling sering dilihat oleh pengguna, sehingga rekomendasi yang kami berikan bukan hanya sekedar rekomendasi kami. Harapan ke depannya, untuk fitur Highlight ini dapat bersifat personal berdasarkan apa yang sering dikunjungi oleh user dengan fitur machine-learning, sehingga user merasa lebih nyaman ketika kita suguhkan rekomendasi yang sesuai dengan minatnya.
Wireframe — Home Screen
Pada homescreen, kami mendapatkan 2 (dua) alternatif design yang dapat dilihat pada gambar di bawah ini.
Perbedaan yang paling terlihat terletak pada urutan dari menu-menu yang ada pada Home Screen. Pada design kiri (yang selanjutnya disebut design pertama), urutan lebih mengutamakan fitur pembayaran yang telah menjadi konsep dasar pada aplikasi sebelumnya, dimana dari segi bisnis, pembayaran online merupakan salah satu revenue stream (selain Ride-Hailing).
Sedangkan pada design kanan (yang selanjutnya disebut design kedua), dari segi urutan, lebih condong ke aplikasi yang bersifat utilitas yang bertujuan untuk memudahkan user dalam mencari apapun tentang Jogjakarta. Pada design kedua, urutan fitur pembayaran terletak di urutan hampir terakhir. Hal ini telah dipertimbangkan karena pada Bottom Navbar juga sudah terdapat fitur Pembayaran yang isinya jauh lebih lengkap daripada di Home Screen, sehingga menurut kami tidak masalah apabila fitur pembayaran hanya ditampilkan sekelebat saja dan di urutan non-prioritas pada Home Screen.
Selanjutnya, perbedaan kedua terletak pada penggunaan elemen design. Pada design pertama, hampir semua menu menggunakan style Iconal (menggunakan vectorized icons), dengan pertimbangan untuk mengurangi scroll-length sehingga user tidak perlu scrolling terlalu jauh untuk menemukan sebuah menu.
Pada design kedua, menggunakan banyak elemen Image dan banyak menu yang disertai dengan penjelasan singkat. Hal ini dilakukan karena UVP yang ingin kita angkat adalah tentang fitur ulititas, sehingga diperlukan penjelasan lebih tentang beberapa menu yang ingin kita sajikan kepada user. Kelemahan dari design kedua ini terdapat pada scroll-length yang lebih panjang. Akan tetapi, dari pendapat beberapa rekan kami yang kebetulan sesuai dengan kriteria User Persona, scrolling bukan merupakan pain points yang terlalu berarti bagi mereka, mengingat generasi X, Y, dan Z telah sangat mengenal interaksi scrolling dari Instagram dan TikTok.
Pada akhirnya, dengan berbagai pertimbangan tersebut, kami memutuskan bahwa design Home Screen yang akan kami gunakan untuk selanjutnya adalah screen kedua yang notabene lebih intuitive, lebih mudah difahami, dan tidak membosankan (karena pada design pertama terdapat pengulangan elemen desain yang akan membuat user bosan dan terkesan miskin navigasi dan interaksi).
Wireframe —Destinasi Wisata (Landing menu)
Pada halaman landing menu wisata, user akan langsung disajikan kategori dengan menggunakan elemen Image. Selain aethetic, image juga bisa menjadi jembatan visual yang menurut kami tepat karena pilihan kategorinya tidak banyak (kalau banyak, maka image bukan pilihan yang tepat).
Setelah kategori, user akan kita suguhkan highlight wisata yang telah dibahas di bagian sitemap.
Setelah itu barulah user diberi kesempatan untuk explore the app mencari tempat wisata yang banyak dicari (lebih tepatnya sering di-klik oleh user lain). Algoritma yang kami ajukan untuk menu explore adalah sebagai berikut :
- Yang akan ditampilkan terlebih dahulu, adalah wisata dengan jumlah klik >50% jumlah pengguna dan terdekat
- Setelah itu, baru ditampilkan yang paling dekat
Hal ini kami putuskan berdasarkan hasil riset user backpacker yang menyatakan bahwa mereka suka mencari tempat wisata yang populer dan yang tidak terlalu membutuhkan effort banyak (jauh).
Pada menu explore, kami juga menambahkan informasi esensial yang harus diketahui oleh backpacker sebelum melakukan perjalanan, misalnya : Nama wisata, deskripsi singkat, jarak dari lokasi saat ini, dan tentu saja range harga. Hal ini untuk menyelesaikan salah satu masalah inti yang dihadapi backpacker saat merencanakan trip ke Jogjakarta.
Kemudian yang terakhir, kami menggunakan interaksi Clicking untuk memuat list destinasi lain. Hal ini kami putuskan karena untuk menjaga human-interaction agar tetap berjalan pada aplikasi ini.
Wireframe — Detail Destinasi
Pada halaman detail destinasi, kami berkiblat dari Google dengan memberi sedikit modifikasi menyesuaikan resources dan yang kita miliki.
Kami menambahkan beberapa informasi, yang berdasarkan riset, akan sangat dibutuhkan oleh backpacker, antara lain :
- Foto destinasi
- Jam buka saat hari itu (dan hari-hari lainnya)
- Detail lokasi, meliputi alamat lengkap, jarak dari lokasi saat ini, shortcut ke Google Maps, dan integrasi dengan layanan yang kita miliki yaitu fitur Ride-Hailing. Sehingga dari segi bisnis, perusahaan juga bisa mendapatkan revenue stream
- List harga secara detail
- Deskripsi
- Akun sosial media, kontak, website, email, dll
- Dan untuk upcoming update, kami akan enable fitur Live-discussion dan Rating dari pengguna JogjaKita, sehingga bisa membentuk suatu komunitas yang harapannya dapat meningkatkan market-share dan brand-awareness dari aplikasi ini
Wire-Flow
Setelah membuat masing-masing screen, kami membuat Wire-Flow yang akan disampaikan dan didiskusikan kembali dengan pihak developer. Wire-flow sendiri berfungsi untuk menggambarkan bagaimana journey user saat akan menyelesaikan suatu Goals secara lebih detail. Dan dalam case study ini, yang menjadi goals user adalah membuka halaman detail destinasi wisata dan bisa mendapatkan informasi yang berguna bagi trip mereka (dalam hal ini, user adalah backpacker).
Dan berikut adalah User-Flow dari wireframe yang telah kami buat.
4. Design & Prototyping
Pada bagian ini, kami hanya akan menyampaikan sedikit penjelasan dan akan lebih banyak menunjukkan hasil High-Fidelity Design dan video Prototyping dari aplikasi JogjaKita. Mengingat hampir semua penjelasan telah dikemukakan pada bagian 3 (wireframe).
Style Guideline
Warna Primer dan Sekunder yang kami gunakan adalah warna khas dari Jogjakarta, yakni warna Hijau dan Emas yang melambangkan keramahan dan kekayaan kebudayaan yang selalu dijaga oleh masyarakat Jogjakarta. Warna hijau dan emas ini juga digunakan pada beberapa campaign dan atribut di Jogjakarta, antara lain campaign Jogja Heboh dan bus Trans Jogja.
Home Screen
Berikut adalah tampilan high-fidelity dari halaman Home. Kami menggunakan warna Hijau sebagai Primary dan warna Kuning Emas sebagai Accent. Search bar akan selalu berada di atas (fixed-top) agar user dapat dengan mudah mencari apa yang ingin mereka cari saat menggunakan aplikasi ini.
Dan juga pada bagian bawah sendiri, kami memberikan sedikit ilustrasi untuk menandakan bahwa screen tersebut sudah mencapai titik batas scroll.
Destinasi Wisata — Landing Menu
Detail Wisata
Prototype
Kami tidak terlalu concern pada micro-aesthetic-interactions pada tahap ini, karena bagi kami, kenyamanan user adalah hal yang terlebih dahulu harus diperhatikan dalam membangun ulang sebuah produk. Sehingga kami memutuskan untuk tidak menggunakan micro-interactions secara mendetail.
5. Prototype Testing
Pada tahapan ini, kami menggunakan Maze Design sebagai tool utama untuk melakukan prototype testing agar bisa dilakukan secara remote. Akan tetapi, kelemahan dari metode ini adalah tester tidak bisa menyampaikan pendapatnya secara jelas (tidak bisa melakukan Thinking-out-loud) dan kita tidak bisa mendapatkan ekspresi wajah dari tester ketika mencoba menyelesaikan task yang telah kita berikan.
Mekanisme prototype testing yang kami lakukan adalah dengan memberikan suatu Goal(s) kepada tester, yang kemudian harus diselesaikan entah bagaimana-pun cara tester menyelesaikannya. Setelah itu, tester akan kami beri pertanyaan terkait dengan cara tester dalam menyelesaikan task.
Prototype Testing ini kami lakukan dengan menggunakan 15 orang yang memiliki similarity dengan User-Persona yang telah kami buat sebelumnya. Kami juga melibatkan orang-orang yang yang telah mengikuti Initial Testing untuk melihat apakah solusi yang kami buat adalah solusi dari permasalahan yang mereka alami dan ungkapkan sebelumnya.
Berikut adalah Goals yang kami ajukan pada proses Prototype Testing :
- Coba tunjukkan ke kami, dimana kamu bisa menemukan list tempat-tempat wisata di Jogja
- Coba tunjukkan ke kami, berapa harga masuk ke Set Film Bumi Manusia
- Coba tunjukkan ke kami, jam berapa Studio Alam Gamplong buka saat Weekend
Dan berikut adalah hasil Prototype Testing yang kami dapatkan :
Goals 1 : Membuka menu Destinasi Wisata
Pada skenario pertama, kami menginstruksikan kepada tester untuk mencari menu Destinasi Wisata. Test pertama ini kami tujukan untuk melihat reachability dari fitur Destinasi Wisata, adapun yang kami lihat adalah untuk segi wording (pemilihan kata) dan placement (penempatan).
Dari data statistik diatas, menunjukkan bahwa dari 16 tester, tingkat keberhasilannya mencapai 94%. Berarti dari 16 tester, ada 1 tester yang mengalami kesulitan dalam mencari menu tersebut.
Akan tetapi, salah satu kelemahan testing menggunakan Maze adalah tidak mampu melihat dan mendengarkan secara langsung Thinking Out Loud dari user, sehingga kita hanya mampu menganalisa dari Heat-map dan metrik. Dan juga, Maze tergolong salah satu alat testing yang berat jika diakses melalui smartphone. Sehingga seringkali durasi yang lama bisa juga disebabkan faktor device yang kurang mumpuni.
Dari data heatmap, terlihat bahwa 1 tester yang salah tersebut mengeklik pada menu Event Terdekat. Setelah ditelusuri, tester tersebut memilih menu Event karena ia penasaran dan coba-coba ingin melihat apa yang ada pada menu tersebut. Pada hasil tanggapan tester, ada beberapa tester yang mengemukakan bahwa mereka ingin melakukan exploring saat melihat tampilan aplikasi ini.
Dari data Scale diatas, menunjukkan bahwa ada 1 tester yang memberi angka 7, dengan alasan bahwa ia merasa keberatan apabila harus scrolling sedikit untuk dapat mengakses menu tersebut. Akan tetapi, 15 lainnya berada pada angka 9 dan 10, yang mana mereka menyukai peletakan dari menu tersebut.
Dari hasil diatas, dapat disimpulkan bahwa penempatan dan pemilihan kata dari menu Destinasi Wisata layak untuk dilanjutkan ke tahap Production.
Goals 2 & 3 : Melihat harga masuk Set Film Bumi Manusia & melihat jam buka Studio Alam Gamplong saat Weekend
Agar mempercepat proses testing, kami memutuskan untuk menggabungkan antara skenario kedua dan ketiga. Hal ini karena kedua skenario ini jaraknya terlalu dekat dan menurut kami bisa dijadikan satu step testing (agar bisa menyisakan slot untuk testing fitur lain hehe).
Dari hasil statistik diatas, hasilnya lumayan memuaskan, meskipun masih belum sempurna. Pada skenario kedua dan ketiga ini masih ada user yang Bounce (tersesat dan tak tahu arah pulang), dan misclick rate yang lumayan besar. Saat melihat jawaban dari block berikutnya, ada jawaban tentang halaman prototype yang tidak ada tombol backnya, sehingga sangat dimungkinkan bahwa 1 user yang give-up ini mengalami hal tersebut.
Mengingat kebiasaan user saat menggunakan aplikasi yang berhubungan dengan wisata, yaitu exploring, maka menurut kami wajar-wajar saja jika mereka akan mencoba membuka menu atau destinasi wisata yang menurut mereka menarik (padahal tidak ada di prototype). Dan untuk mencari tau dimana screen yang bisa diimprove, kami harus mencari tau terlebih dahulu score breakdown dari masing-masing screen.
Dari segi skor, halaman home memang buruk dari segi waktu membuka. Akan tetapi untuk mencari menu Destinasi Wisata, telah terbukti di skenario pertama bahwa menu Destinasi Wisata dapat ditemukan dengan mudah. Sehingga untuk skenario kedua dan ketiga ini mungkin ada kesalahan penyampaian brief sehingga user menjadi bingung. Atau ada faktor lain, misalnya ada device yang kurang mumpuni saat melakukan testing. Karena hal seperti itu juga akan memakan screen time yang lumayan banyak, bahkan hanya untuk melakukan scrolling.
Metrik kedua yang menjadi pertimbangan selain screen time adalah misclick rate. Misclick rate berguna untuk memastikan bahwa tester dapat menemukan apa yang mereka cari. Semakin banyak misclick, maka itu berarti tester masih merasa kesulitan saat mencari sebuah menu dan akhirnya mengeklik sembarang menu untuk mencari apa yang dicari. Dan misclick rate tertinggi terdapat pada halaman Detail Destinasi, yaitu 15% atau kira-kira 2 tester mengalami misclick. Oleh karena itu, kami perlu melihat heatmap dan clicks agar dapat mengetahui lebih detail dimana saja tester melakukan klik saat akan mencari menu yang mengandung informasi detail (jam buka per hari).
Jika dilihat lebih detail, ada 2 tester yang mengalami misclick beserta dimana mereka melakukannya (MY FAVORITE FEATURE ON MAZE!). Dari heatmap diatas, bisa dilihat bahwa 2 misclick tersebut ada pada bagian Deskripsi dan Back. Menurut kami, jika mereka sampai melakukan back maka tester mulai merasa kebingungan. Solusi dari kami, wording dari button Info Detail akan kami ganti dengan sesuatu yang lebih bisa dimengerti oleh user nantinya. Akan tetapi, dari hasil diatas menunjukkan bahwa mayoritas tester masih mampu menyelesaikan Goal ketiga dengan sangat baik dan cepat. Sehingga kami memutuskan bahwa design diatas sudah layak jika akan dilanjutkan ke proses Production.
Dan tentu saja, proses kami tidak hanya akan sampai disini, karena pada hakikatnya, tugas dari Product Designer adalah untuk terus melakukan improvements dan memberikan pengalaman terbaik bagi user saat menggunakan aplikasi. Sehingga kami akan terus melakukan iterasi seiring aplikasi mulai digunakan di pasar yang lebih luas.
6. Future Improvements
Bagian ini kami tulis pada awal bulan Desember 2020 (sekitar sebulan sejak Sprint), sehingga akan ada beberapa tambahan jangka pendek dan juga jangka panjang (Future Feature). Improvement jangka pendek yang akan kami lakukan dalam waktu dekat antara lain :
- Penambahan fitur Tambah Destinasi Favorit. Fitur ini berguna untuk menandai destinasi yang ingin dikunjungi oleh user, sehingga user bisa merasa “tandai dulu aja lah, kali aja keturutan”, dan saat liburan yg akan datang bisa hanya melihat list destinasi yg sudah ditandai saja. Akan lebih baik jika bisa diurutkan secara otomatis dari jarak terdekat dengan posisi user.
- Penambahan Destinasi Dekat Sini saat user melihat detail suatu destinasi. Pemilihan rekomendasi yang tertampil bisa ditentukan berdasarkan jarak terdekat dari destinasi yang sedang dilihat. Sehingga user dapat dengan mudah menentukan destinasi mana saja yang bisa dikunjungi dalam sekali perjalanan.
Bicara tentang masa depan, setiap Product Designer pasti memiliki bayangan yang luar biasa tentang masa depan sebuah produk, and so do we. Pada fitur Vacation Guide ini, kami memiliki angan-angan tentang fitur Vacation Planner. Jadi dalam fitur ini, user dapat melakukan pemesanan transportasi, pemesanan hotel, hingga pengaturan jadwal perjalanan. Sehingga benar-benar JogjaKita bisa menjadi Vacation Guide dan tentu saja akan sangat memudahkan bagi para backpacker yang lebih suka perjalanan yang terstruktur dan terjadwal.
Fitur ini sebenarnya adalah jawaban dari pokok permasalahan pertama, karena selain masalah destinasi, masalah inti yang sering dialami user adalah masalah budgeting. Dengan fitur ini, backpacker dapat dengan mudah mengetahui total estimasi budget mulai dari untuk keperluan transportasi, penginapan, bahkan sampai lokasi wisata. Belum lagi, mereka juga dapat langsung memesan transportasi dan penginapan saat itu juga melalui fitur Vacation Planner ini.
Di atas merupakan gambaran singkat sitemap dari fitur Vacation Planner yang kami cita-citakan. Mungkin bisa disebut seperti fitur paket wisata, akan tetapi disini user bisa benar-benar melakukannya secara custom sesuai keinginan mereka. Akan tetapi ini hanya angan-angan dari tim Product Design, jadi masih belum sampai masuk ke tahapan diskusi 3H (Hipster, Hustler, Hacker). Tapi apa salahnya berangan-angan kan ? Hehe
Fungsi utama dari fitur ini adalah untuk meringkas semua yang berhubungan dengan pariwisata Jogja agar menjadi satu kesatuan flow, sehingga user diharapkan dapat mendapatkan gambaran jelas total cost/budget yang diperlukan untuk melakukan liburan sekaligus dapat melakukan bundle-booking (ini istilah dari kami sendiri ya hehe) untuk transportasi, penginapan, dan aktifitas sekaligus.
Kami lumayan optimis jika fitur ini bisa di develop (meskipun mungkin bakal butuh waktu yang lumayan panjang), karena semua assets yang diperlukan sudah ada di dalam aplikasi, misalnya fitur pemesanan hotel, ticketing pesawat, kereta, bis, pemesanan wisata, database destinasi wisata, dll. Sehingga banyak sources yang seharusnya dapat di re-use, meskipun banyak yang harus dimodifikasi (at least they not tried too hard).
Oh iya, fitur masa depan ini masih belum melalui proses research dan masih berdasarkan asumsi kami sebagai Designer, sehingga mungkin akan ada Case Study khusus untuk fitur ini setelah melalui serangkaian research.
7. Tambahan, Klarifikasi, dan Penutup
Kata “kami” di UX Case Study ini berarti “saya”, karena saya bekerja sebagai Product Designer tunggal di perusahaan tempat saya bekerja hehe.
Big thanks to dev team yang sudah bersedia meluangkan waktu untuk berdiskusi lebih dalam tentang hal-hal yang berkaitan dengan development produk.
Big thanks juga untuk 16 orang yang bersedia meluangkan waktunya untuk menjadi subjek riset, dan akan saya jadikan subjek lagi untuk fitur berikutnya.
Case study ini semata-mata hanya untuk media edukasi sekaligus portfolio yang saya tulis dengan menggunakan data dari hasil research dan menggunakan pemikiran-pemikiran teori design yang saya ketahui. Semoga membantu dan bisa menginspirasi teman-teman Designer lain yang membutuhkan referensi dalam membuat portfolio.
Bakal ada part-part berikutnya, karena fitur di aplikasi ini tidak hanya sebatas fitur wisata saja. Ada fitur Ride-Hailing yang juga memiliki UVP yang tidak dimiliki oleh produk lain, ada juga fitur ticketing (hotel, pesawat, kereta), pemesanan paket wisata, dll yang bisa saya bahas lebih lanjut di part-part berikutnya.
Terima kasih yang sudah mampir dan membaca Case Study ini. Semoga bermanfaat dan kebaca sampe abis yaa. See ya in next project. Ciao~ 🙌🙌🙌
ps : Capeek yaa bacanya panjang banget. Sama, apalagi saya yang ngetik 😰