Pelajaran yang Saya Peroleh dari Mendesain Homepage Aplikasi Traveloka

Riska Fadilla
Traveloka Design
Published in
4 min readJul 22, 2016

Akhir bulan Mei lalu, app Traveloka memperbarui tampilan homepage-nya. Proyek ini dikerjakan oleh tim tempat saya berkontribusi sebagai UID (User Interface Designer), sehingga proyek ini jadi tugas utama saya. Secara personal, ini adalah proyek yang cukup menantang. Mengapa? Homepage merupakan pintu masuk utama user untuk menemukan apa yang mereka cari, hal pertama yang akan mereka lihat saat membuka app. Saat user menemukan kesulitan di homepage, besar peluang mereka akan “lari” atau keluar dari app.

Mengapa tampilan app homepage perlu diredesain? Apa masalah yang akan diselesaikan dengan desain yang baru?

Pertanyaan-pertanyaan di atas memenuhi kepala saya ketika mendapat kabar tentang proyek ini. Setelah ngobrol lebih lanjut dengan stakeholder, dapat disimpulkan bahwa kebutuhan redesign didorong oleh keinginan untuk meningkatkan user awareness terhadap fitur-fitur yang dimiliki Traveloka. Sejalan dengan itu, redesign ini juga harus mendukung plan jangka panjang Traveloka.

Tampilan homepage di versi sebelumnya

Lebih konkretnya, desain homepage lama dinilai tidak cukup fleksibel untuk memuat skenario dan fitur baru. Isu lainnya mengenai discoverability konten promo yang rendah (akses ke konten promo di navbar kiri atas).

Proses desain MVP homepage berlangsung selama satu bulan dan berikut adalah beberapa pelajaran yang saya peroleh dari kacamata saya sebagai UID:

1. Hindari tergesa-gesa memindahkan sketsa ke bentuk high fidelity

Brainstorm desain pertama kali dilakukan dengan menggunakan metode Crazy8 bersama beberapa rekan desainer. Output dari proses ini adalah terpilihnya satu ide awal untuk dieksplor lebih lanjut. Kemudian saya memindahkan hasil sketsa tersebut ke dalam file Sketch, memberi warna abu pada setiap elemen desain, dan mengotak-atik Sketch untuk mengeksplor ide terpilih tadi.

Impact-nya, desain high fidelity yang berwarna abu tersebut dianggap sudah final oleh orang yang melihatnya meskipun di awal saya telah berulang kali menekankan bahwa “ini belum versi final ya”. Hal ini terlihat dari pertanyaan-pertanyaan yang dilontarkan cenderung terkait hal visual, ketimbang apakah desain tersebut benar sudah memecahkan masalah. Akhirnya, saya mundur satu langkah untuk kembali membuat wireframe dengan Balsamiq.

Berbicara soal wireframe, dulu saya sempat mengira bahwa wireframe adalah versi “setengah jadi” dari desain dan harus selalu bewarna abu. Padahal wireframe adalah alat komunikasi ide yang dapat berupa apapun, bisa berupa coretan, flow chart, atau bahkan tempelan Post It. Jadi, daripada membuang tenaga dan waktu mengeksplor ide lewat versi high fidelity, lebih baik menggunakan wireframe yang lebih gampang dibuat dan diubah.

2. Pentingnya mengoptimalkan kolaborasi sejak awal dengan developer

Selain brainstorm menggunakan metode Crazy8, pada proyek ini desainer bersama developer juga melakukan brainstorm untuk mematangkan konsep desain selama 5 hari berturut-turut (1 jam setiap sore). Proses ini terinspirasi dari Google Design Sprint yang kami sesuaikan dengan kebutuhan proyek.

Seperti apa kegiatan yang saya lakukan selama 5 hari itu? Pagi dan siang adalah waktu saya mengeksplor ide desain untuk kemudian sorenya didiskusikan bersama dengan developer. Kemudian pada malam atau keesokan paginya rekan IxD (Interaction Designer) membantu validasi desain visual lewat usability testing. Siklusnya pun berlanjut dengan saya memperbaiki desain sesuai hasil usability testing.

Bentuk kolaborasi ini membantu saya menjalin hubungan yang harmonis dengan developer. Sejak awal developer dapat men-spot desain atau elemen apa yang mungkin tidak works dan membantu memikirkan solusinya bersama-sama. Bagi developer, proses ini bisa digunakan untuk memprediksi tingkat kesulitan desain yang akan dikerjakan.

Walaupun proses kolaborasi seperti ini tidak mungkin dilakukan pada setiap proyek (karena keterbatasan waktu dan resource), validasi ide desain kepada developer tetap perlu dilakukan di awal. Bentuk validasi bisa sesederhana mengonfirmasi dengan bertanya ke developer.

3. Jangan baper terhadap feedback

Poin ini lebih menyangkut ke hal personal. Saya termasuk orang yang tidak suka meminta feedback hasil desain dari rekan desainer lain. Ada rasa takut mereka akan menjudge kemampuan desain visual dan problem solving skill saya. Di proyek ini saya mencoba memberanikan diri meminta feedback kepada beberapa rekan desainer dan memperoleh beberapa pertanyaan:

Kenapa promo harus ditunjukkan di homepage lewat banner? bukankah itu akan terlihat seperti ads?

Kenapa semua fitur harus ditunjukkan di homepage? memberikan terlalu banyak pilihan bukannya akan membingungkan user?

Pertanyaan di atas dan pertanyaan lain yang senada entah kenapa seringkali saya anggap sebagai “serangan” terhadap desain saya. Belakangan saya menyadari bahwa pertanyaan tersebut bisa jadi mereka lontarkan karena mereka berusaha memahami desain saya atau sebagai bentuk tantangan karena mereka juga sangat peduli dengan pengalaman user yang dipengaruhi oleh solusi desain yang baik.

Yang seharusnya saya lakukan adalah berusaha untuk tidak baper dan menjawab pertanyaan dengan jelas. Kesulitan dalam menjawab pertanyan “serangan” di atas dapat dijadikan indikator apakah saya sudah benar-benar yakin dengan solusi yang saya tawarkan. Ada kemungkinan pertanyaan-pertanyaan tersebut memang belum terpikirkan solusinya, berterimakasihlah kepada mereka yang bertanya karena sudah membantu mengidentifikasi isu baru.

Proses desain homepage ini tentu tidak berakhir setelah release. Ada banyak asumsi dan solusi yang butuh divalidasi lagi untuk versi selanjutnya. Semoga saya bisa belajar lebih banyak dari sana.

--

--