Studi kasus UX: Merancang ulang proses EDOM
Mengimprovisasi UX dalam pengevaluasian dosen di EDOM
Mahasiswa dari beberapa universitas setidaknya mengetahui tentang pengisian EDOM ini. Evaluasi Dosen Oleh Mahasiswa (EDOM) bertujuan untuk menilai kinerja dosen dengan range nilai 1 (kurang baik) sampai 4 (sangat baik).
Dalam studi kasus ini saya mengangkat masalah dari hulu ke hilir mengenai pengisian EDOM khususnya pada kampus Institut Teknologi PLN yang menurut saya bisa diimprovisasi menjadi lebih baik.
Pendapat pribadi mengenai pengisian EDOM
Terlalu banyaknya flow dan tindakan yang harus dilakukan untuk melakukan pengisian EDOM per dosennya. Walaupun hanya dilakukan 1 kali per semester, apa salahnya untuk diimprovisasi guna memberikan pengalaman baik untuk mahasiswa?
Proses pembuatan studi kasus
Dengan perkembangan UX yang begitu cepat, saya memutuskan untuk meng-update alur pembuatan studi kasus saya dengan menggunakan UX Workflow dari UX Bites yang sudah tertata rapih dari proses research hingga testing yang konsepnya sama dengan design thinking process.
Peran saya dalam studi kasus ini
Di sini saya berperan sebagai UX Designer, sehingga output yang saya berikan berupa experience yang saya usahakan memenuhi 7 factor that influence UX.
Alasan di balik pengangkatan masalah ini
Dari zaman pembuatan studi kasus pertama saya, saya selalu mencoba mencari masalah besar untuk dipecahkan, namun pada proses mencari masalah besar tersebut, saya selalu mengabaikan masalah-masalah kecil yang selalu saya alami. Dengan itu saya memutuskan untuk mengangkat masalah ini karena menurut saya, mau masalah itu besar ataupun kecil, jika dapat di-solve akan memberikan output yang sama, yaitu good impact for community.
Studi kasus (iterasi 0) ini saya buka dengan tahap…
Observation
Mengobservasi dilakukan untuk mengetahui pain point atau masalah pada suatu product walaupun masih menggunakan asumsi.
Karena case study ini saya mulai saat mahasiswa dipersilahkan untuk mengisi EDOM, saya menggunakan kesempatan ini untuk sekaligus mengobservasi 2 orang teman saya saat melakukan pengisian EDOM.
🌐 Software pengisian EDOM menggunakan Google Chrome.
Ada beberapa point yang menurut saya membuat pengisian EDOM menjadi kurang baik dari sisi experience setelah mengamati proses saya dan kedua teman saya saat mengisi EDOM, yaitu:
1. Alur yang terlalu banyak
Alur di bawah dimulai dari user login hingga mengevaluasi 2 dosen.
Untuk mengevaluasi atau menilai 1 dosen, terdapat 5 flow. Mulai dari halaman login hingga halaman yang menyatakan sukses atas penyimpanan nilai pada dosen yang telah dievaluasi atau yang saya sebut dengan success page (Gambar 1.1).
Dan untuk mengevaluasi dosen selanjutnya, user harus menekan button “Kembali Isi Quzioner” yang akan membawa user ke halaman EDOM lagi untuk memilih dosen (Gambar 1.2),
Pada 1 semester terdapat kurang lebih 11 dosen. Jadi user harus melakukan flow di atas sebanyak 11 kali, tentu akan terasa sangat lama.
2. Bagian utama yang tidak Findable
Saat kita menekan button “evaluasi”, kita tidak langsung dibawa ke bagian kusioner (Gambar 1.3), melainkan balik lagi ke halaman EDOM bagian daftar dosen. Bedanya, halaman EDOM ini terdapat kusioner di bawah bagian daftar dosen yang tentunya users harus meng-scroll ke bawah terlebih dahulu untuk mulai mengisi.
Bagian ini berkemungkinan besar membuat users baru akan bingung kenapa dibawa ke halaman yang sama. Dan kondisi terburuk adalah users akan mengira button “evaluasi” tersebut error dan malah melakukan refresh page berulang-ulang sampai dia tau mengenai kusioner yang ternyata ada di bawah.
3. Pemilihan komponen yang kurang tepat
Pengimplementasian combo box sebagai pemilihan nilai untuk kasus ini menurut saya kurang tepat karena tiap dosen mempunyai 22 pertanyaannya untuk dievaluasi.
Dan untuk memberikan nilai pada 1 pertanyaannya, user harus terlebih dahulu harus menekan combo box setelah itu baru bisa memilih nilai, yang tentu sudah memakan 2 aksi hanya untuk mengisi 1 pertanyaannya pada 1 dosen. Secara tidak langsung user harus melakukan 44 aksi (tidak termasuk membaca) untuk mengevaluasi 1 dosen.
4. Proses yang membutuhkan waktu lebih
Pengisian EDOM dari halaman login membutuhkan waktu kurang lebih 1 menit, itupun tidak termasuk membaca pertanyaannyanya, dalam kata lain users mengisi EDOM secara asal-asalan hanya pada 1 orang dosen.
Jika termasuk membaca pertanyaan satu per satu, users membutuhkan waktu sekitar 1 menit dan 30 detik hingga 2 menit pada 1 dosen. Per semester terdapat kurang lebih 11 dosen, itu berarti 11 (11x1 menit) sampai 22 menit (11x2 menit) untuk melakukan pengisian EDOM hingga tuntas.
Mari kita buktikan observasi di atas dengan..
🔍 Research
User interview
Pada 2 users yang merupakan teman yang saya observasi sebelumnya, saya melakukan user interview yang menanyakan experience mereka terhadap pengisian EDOM yang sudah 5 semester dilakukan.
Berikut pertanyaannya:
- Informasi diri (nama, umur, jurusan, dan semester)
- Perangkat dan aplikasi yang digunakan untuk mengisi EDOM
- Tujuan utama mengisi EDOM (motivation)?
- Pengalaman atau perasaan yang dialami saat pertama kali mengisi EDOM (Jika bingung, alasannya?)
- Pengalaman atau perasaan yang dialami saat sekarang mengisi EDOM (Jika bingung, alasannya?)
- Dulu (saat menjadi mahasiswa baru), saat mengisi EDOM, apakah membaca pertanyaannya secara komplit satu per satu? (Jika tidak, alasannya?)
- Sekarang, saat mengisi EDOM, apakah membaca pertanyaannya secara komplit satu per satu? (Jika tidak, alasannya?)
- Apa yang disukai tentang pengisian EDOM
- Apa yang tidak disukai tentang pengisian EDOM
- Jika ada yang tidak disukai, kenapa tetap memilih untuk mengisi EDOM
- Berapa waktu yang kamu luangkan untuk mengisi EDOM hingga selesai
- Apa ada alasan yang menghalangi dalam mengisi EDOM
- Menurut kamu, apa yang bisa ditingkatkan untuk membuat kamu lebih mudah dalam mengisi EDOM?
- Bagian apa yang tersulit dalam proses pengisian EDOM?
- Kapan biasanya mengisi EDOM?
- Menurut kamu apakah proses pengisian EDOM bisa lebih mudah? (Jika iya, mengapa menurut kamu bisa? dan Jika tidak, mengapa menurut kamu tidak bisa?)
Dan pertanyaan tambahan disela-sela main question yang menggunakan 5 why method untuk menggali jawaban lebih dalam.
📊 Analyze & Ideate
Analyze research data
Hasil dari riset sebelumnya, saya kumpulkan lalu saya analisa dan kelompokkan.
Hasilnya adalah pain point-pain point yang ada di bawah ini:
1. Pertanyaan untuk dievaluasi terlalu banyak
Solusi: Bagian ini tentu saya harus mengevaluasi pertanyaan-pertanyaan menjadi lebih ringkas namun tetap mempunyai makna yang sama
2. Alur proses pada tahap pengevaluasian yang terlalu banyak
Solusi: Dari bagian ini, yang akan diimprovisasi agar lebih baik adalah userflow-nya
3. Komponen evaluasi membutuhkan banyak aksi
Solusi: Komponen akan diobservasi dan diganti dengan komponen yang lebih tepat dan mendukung goals utama, yaitu proses efisien dan efektif.
4. Melelahkan
Solusi: Experience akan dirombak untuk memberikan proses yang menggunakan sedikit effort namun tetap mencapai goals utama.
5. Membutuhkan waktu yang banyak
Solusi: Experience dalam kecepatan juga akan diimprovisasi dengan melakukan testing agar waktu yang dibutuhkan kurang dari 10 menit untuk mengisi EDOM hingga selesai.
User persona
Hendri adalah seorang mahasiswa semester 5 yang berumur 20 tahun dari IT-PLN yang setiap hari melakukan kewajibannya di kampus.
Motivations and Goals: Mengevaluasi dosen agar dosen mendapatkan penilaian yang adil dengan mudah, cepat, efektif, dan efisien.
Pains and Frustrations: Mengevaluasi EDOM membutuhkan waktu dan aksi yang sangat banyak.
Techs Knowledge: Internet (good), Smartphone (good), Browser (good)
User flow
User flow yang saya rancang adalah sebagai berikut:
Sebagai pembanding, ini user flow pada design saat ini:
Ketika mencari solusi dalam membuat user flow yang efisien, saya memutuskan untuk menghilangkan…
- Halaman success yang muncul setiap menyelesaikan 1 dosen,
- Aksi menekan tombol kembali di halaman success,
- Aksi untuk memilih semester, dan
- Aksi untuk memilih dosen.
Alasannya adalah…
- Karena menunjukkan user bahwa Ia behasil mengevaluasi dosen tidak perlu membawa user ke halaman baru, cukup menggunakan state seperti pop-up.
- Aksi memilih semester menurut saya tidak dibutuhkan karena setelah perpindahan semester, user seharusnya tidak bisa mengevaluasi dosen pada semester sebelumnya. Jadi sudah pasti ketika user membuka EDOM adalah untuk mengevaluasi dosen pada semester user saat ini
- Aksi memilih dosen sebenarnya tidak perlu karena pada ujungnya mahasiswa wajib mengevaluasi semuanya. Ini juga menghindari human error seperti user lupa mengevaluasi seorang dosen (contohnya) yang ujungnya membuat user tidak bisa KRS-an (Membuat kartu rencana studi untuk semester berikutnya).
Jika kamu memikirkan user flow ini lebih banyak, itu tidak sama sekali. Dengan user flow ini, jika terdapat 11 dosen, user hanya melewati 15 page, dan jika menggunakan user flow yang lama, user harus melewati 36 page.
Untuk bagian ini, masalah yang saya solve adalah proses yang melahkan, membutuhkan waktu yang banyak, dan alur pada tahap pengevaluasian terlalu banyak.
🎨 Design
Information architecture & Wireframing
Rancangan informasi dan konsep saya lakukan di selembar kertas. Untuk rancangan informasi, saya kurang lebih mengikuti susunan informasi yang ada sekarang karena saat diobservasi tidak ada masalah sama sekali. Hal ini juga karena user telah terbiasa menggunakan dan melihat informasi di anjungan.
Design & Prototype
Design dari high fidelity dan prototype-nya bisa kalian lihat dan coba di sini (Figma).
Untuk bagian ini, masalah yang saya solve adalah komponen yang membutuhkan banyak aksi
📈 Testing
Success metrics
- Pada halaman pertama, user mengetahui akan mengisi EDOM
- Users mengerti Navigasi pada Design seperti button berikutnya dan sebelumnya
- Meningkatnya kecepatan users dalam mengisi EDOM lebih dari sama dengan 50%
- Users mengetahui sedang mengisi EDOM semester berapa
- Users mengetahui informasi dosen yang sedang dievaluasi seperti Nama, Mata kuliah, hingga Waktu perkuliahan.
- Users aham cara pengevaluasian dari pertanyaan pertama hingga terakhir
- Users paham kegunaan button “cetak bukti”
- Users merasa senang diberikan ucapan terima kasih di akhir pengisian EDOM
Hasil Testing
Testing saat ini masih ditunda karena adanya pandemi. Jika melakukan testing dari jarak jauh, saya rasa akan kurang maksimal dari sisi performa dan interaksi. Jadi, ditunggu ya update-an studi kasus ini!
Dan studi kasus ini pun belum selesai sampai di sini, saya masih harus melakukan iterasi jika setelah testing nanti ternyata masih banyak kekurangan.
Closing dari MC
Mungkin tipe studi kasus yang tidak memberikan output design “spektakuler” seperti ini jadi menurunkan ekspektasi kalian saat membaca, karena memang saya di sini mencoba mengfokuskan bagaimana saya memecahkan masalahnya.
Semoga di sini kalian bisa memetik bagaimana cara saya berfikir, cara saya meng-approach, hingga cara saya memecahkan masalah yang saya hadapi agar bisa menjadi referensi kalian dalam membuat studi kasus.
Dan, mungkin kalian banyak yang merasa saya tidak menggunakan metode ini itu, tidak menggunakan jargon ini itu, tidak menggunakan proses ini itu. Itu karena saya di sini ingin belajar mengfokuskan diri untuk menge-solve masalahnya dulu, namun seiring bertambahnya iterasi, tentu saya akan menggunakan lebih banyak metode atau bahkan proses baru sesuai kebutuhan. Jadi, tidak bosan saya meningatkan untuk tunggu update-an studi kasus ini ya!
