School of Information Systems

Memahami Persyaratan dalam Mendesain UX

Dalam melakukan desain UX, teknologi dapat digunakan secara maksimal, tentunya harus disertai dengan tujuan dari pembuatan UX, sehingga desainer harus terlebih dahulu memikirkan apakah produk ini bekerja dengan efektif dan efisien bagi pengguna dan apakah UX ini menyenangkan untuk digunakan oleh pengguna. Oleh karena itu, desainer UX akan menentukan persyaratan yang dibutuhkan dalam UX yang akan dibuat. Persyaratan atau requirement dalam UX sama dengan persyaratan dalam membuka lowongan pekerjaan. Di mana ada syarat khusus tertentu yang harus terpenuhi. Dalam desain UX ini, ada yang disebut dengan persyaratan atas produk untuk desain yang akan dibuat. Desainer UX perlu mencari tahu apa yang diinginkan klien mereka dari produk/ layanan tertentu /sistem. Mereka akan mengekspresikan keinginan dan keinginan ini akan menjadi standar atau persyaratan. Sebuah persyaratan dalam UX adalah sesuatu yang harus dilakukan produk atau kualitas yang harus dimiliki produk.

Salah satu yang dapat dilakukan desainer adalah mempelajari aktivitas dari target pengguna dan mengumpulkan rangkaian pegunaan produk yang akan menghasilkan banyak informasi tentang kebutuhan untuk saat ini yang berkaitan dengan tujuan dari yang dibutuhkan oleh para pengguna produk. Atas adanya keinginan dari calon pengguna atau pengguna produk ini, desainer UX akan mendapat persyaratan atas produk/sistem/lainnya yang baru untuk dibuat. Untuk menciptakan hal baru yang menjadi inovasi dari produk desainer perlu melakukan proses ideation, dan oleh karena itulah dibutuhkan analisis–desain–evaluasi dalam menjalani proses dan menciptakan prototype. Dalam proses menentukan persyaratan yang digunakan oleh desainer UX, dapat menggunakan beberapa cara sebagai berikut:

  • Pengumpulan persyaratan, yang menunjukkan bahwa persyaratan sudah ada dan desainer dapat memilih untuk mengambil persyaratan yang akan digunakan. Cara ini akan membentuk sedikit interaksi antara desainer dan stakeholder.
  • Pembuatan persyaratan, yang menyarankan aktivitas yang lebih kreatif, yang cenderung tidak menekankan adanya hubungan dengan praktik yang sedang dilakukan
  • Persyaratan elisitasi, yang menunjukkan beberapa interaksi antara stakeholder dan desainer untuk menentukan keinginan dan kebutuhan dari stakeholder.
  • Rekayasa persyaratan, sering digunakan dalam proyek rekayasa perangkat lunak, biasanya sebagai pendekatan yang sangat formal.

Seringkali dalam menentukan persyaratan UX desain ini, terjadi perdebatan atau perbedaan keinginan antara desainer, klien, stakeholder, dan pihak lainnya. Oleh karena itu, ada beberapa langkah yang dapat memudahkan untuk semua pihak dapat terlibat dan dapat menentukan persyaratan UX yang diibutuhkan dengan tepat, di antaranya adalah:

1. Brainstorming dan Ideation

Dalam brainstorming tidak punya ide adalah hal yang paling buruk. Brainstorming memicu pemikiran kreatif dan merupakan metode yang baik untuk menghasilkan persyaratan di awal. Pada bagian ini, hasil tidak bergantung pada penelitian apa pun. Pada tahap ini desainer dapat melibatkan semua orang mulai dari anggota tim eksekutif hingga direktur. Saat desainer mulai mendengar ide yang diulang-ulang atau terdengar konyol, mungkin yang terbaik adalah mengakhiri sesi ide.

2. Stakeholder Interviews (Wawancara Stakeholder)

Setelah desainer memindai persyaratan yang diperlukan dari sesi brainstorming, desainer ingin membuat persyaratan lebih lanjut dengan melakukan wawancara stakeholder. Sesi wawancara dilakukan dengan lebih formal daripada saat desainer melakukan brainstorming. Di sini desainer dapat mencari informasi dari stakeholder utama untuk menghasilkan persyaratan yang lebih substansial. Desainer UX dapat mengajukan pertanyaan seperti:

  • Bagaimana produk ini cocok dengan strategi keseluruhan?
  • Siapa pesaing terbesar kita?
  • Siapa pelanggan kami hari ini dan bagaimana Anda ingin itu berbeda dalam 5 atau 10 tahun?
  • Kualitas apa yang Anda ingin pengguna kami kaitkan dengan produk kami?
  • Bagaimana kita dapat memenuhi kebutuhan bisnis ini atau itu?
  • Siapa yang akan menggunakan fitur ini?

Dari jawaban para pemangku kepenting, desainer UX dapat memutuskan sendiri akan menggunakan ide dari stakeholder atau tidak dengan tetap memberikan laporan ke atasan, atas hasil yang diperoleh dari wawancara dan memberikan alasan yang baik mengapa ide dari desainer lebih menarik dari ide stakeholder. Desainer dapat menanyakan masalah apa yang dipecahkan berhasil dipecahkan, karena ini dapat mengidentifikasi masalah utama lebih cepat.

3. Create Low-fidelity prototype (Membuat prototype atau sketsa dengan tingkat fidelitas yang rendah).

Tujuan dari pembuatan prototype dengan fidelitas yang rendah adalah untuk membantu para stakeholder memahami beberapa hal penting. Yang pertama adalah fungsionalitas dasar dan yang kedua adalah kendala penting dalam produknya. Alasan prototype pada tahap ini harus memiliki fidelitas yang rendah adalah untuk mendapat kritik dan mendapat perhatian atas hal yang salah. Dengan ini juga biaya yang dibutuhkan lebih murah dan menghemat waktu. Saat desainer mencoba menghasilkan persyaratan UX, dengan prototype yang memiliki fidelitas rendah tidak akan membebankan desainer karena proses tidak memakan waktu yang lama, dan desainer akan lebih baik terus merevisi prototype untuk mendapat hasil yang sempurna. Di akhir, desainer dapat membuat dokumen spesifikasi dari hasil prototype. Dengan menunjukkan fungsionalitas dasar dan batasan yang terlibat dalam proyek, desainer akan dapat menghasilkan persyaratan yang lebih fokus dan relevan, yang akan membantu saat desainer melanjutkan ke langkah berikutnya. Ciri-ciri dari Low-fidelity prototype adalah:

  • Sketsa yang dibuat cepat dari awal hingga akhir
  • Memiliki fungsi dan interaksi yang terbatas
  • Umumnya mempresentasikan konsep, rancangan, alternatif, dan layout dibandingkan dengan model interaksi pengguna dengan sistem
  • Mempresentasikan secara umum “feel and look” dari user interface
  • Tidak menampilkan secara rinci operasi sistem
  • Digunakan pada awal perancangan
  • Dapat menunjukkan konsep pendekeetan secara umum tanpa membuang waktu, biaya dan tenaga.

4. User interviews (Wawancara pengguna)

Pada tahap ini, desainer bisa memperoleh informasi dari orang-orang yang belum terlibat dalam proyek, yaitu orang asing. Wawancara pengguna sangat mirip dengan wawancara stakeholder, tetapi dilakukan dengan percakapan yang ringan. Tahap ini biasanya melibatkan peneliti dan pengguna. Peneliti berguna sebagai pembimbing pengguna melalui wawancara. Merekam dalam bentuk video maupun audio atas wawancara berguna jika bagian UX kekurangan peneliti tambahan. Dari wawancara pengguna, desainer akan memperoleh pemahaman tentang data etnografis pengguna. Dari hasil wawancara ini desainer mungkin juga mendapatkan wawasan tentang:

  • Penggunaan produk
  • Memahami kekurangan dari sisi pengguna
  • Mengetahui tujuan dan motivasi pengguna
  • Mengetahui cara pengguna berinteraksi dengan teknologi

Peneliti tentu saja bisa lebih detail untuk mendapatkan pengetahuan yang lebih dalam dari orang yang diwawancarai. Skrip dapat berguna untuk memandu peneliti selama proses wawancara dan membuat ptetap pada jalurnya, sehingga peniliti dapat mengekstrak informasi yang butuhkan. Wawancara sebisa mungkin tetap dilakukan secara singkat karena jika terlalu panjang maka minat akan berkurang dan data mungkin terbukti tidak dapat diandalkan. Seringkali pengguna akan hebat dalam mengidentifikasi masalah tetapi tidak begitu hebat dalam menyarankan solusi. Sehingga peniliti dapat membantu pengguna dengan memberikan pertanyaan seperti:

  • Apa yang paling Anda benci dari interface ini?
  • Di bagian mana Anda membuang-buang waktu?
  • Di bagian mana Anda membuat kesalahan?

5. Scenarios dan personas

Setelah desainer melalui proses pembuatan ide, wawancara, dan pembuatan prototipe, langkah selanjutnya adalah mempraktikkan informasi yang sudah ada dengan menggunakan skenario, cerita, dan persona pengguna. User persona adalah representasi konkret dari orang yang telah diwawancara. Dalam definisi lain, persona adalah dokumentasi yang berisi penjelasan tentang karakteristik pengguna yang digabungkan dengan tujuan, kebutuhan dan ketertarikannya yang yang sesuai target pengguna. Lalu, user story adalah abstrak singkat yang mengidentifikasi pengguna dan tujuan mereka, tentang siapa pengguna, apa yang mereka butuhkan dan mengapa mereka membutuhkan produk atau layanan ini. Sedangkan, skenario adalah situasi yang menangkap bagaimana pengguna melakukan tugas pada produk atau layanan yang dirancang. Saat bagian UX membuat persona, user story dan skenario, desainer juga dapat memastikan bahwa hal tersebut sudah sesuai dengan rancangan produk sehingga dapat terebntuk persyaratan fungsional yang benar.

Tidak ada standar tertentu dalam membuat user persona, user story, maupun scenario. Namun, setidaknya dalam pembuatannya dicantumkan identitas dan kebutuhan yang mengacu kepada kebutuhan pada UX produk seperti nama, usia, jenis kelamin, tujuan, kesulitan, dan lainnya.

6. Documentation (dokumentasi)

Langkah terakhir adalah menyiapkan dokumentasi. Setelah desainer berhasil membuat persyaratan UX, maka desainer akan melakukan dokumentasi dengan cara menyatukan apa yang sudah dilakukan dari awal sehingga nantinya atas persyaratan UX ini, dessainer dapat menindaklanjutkan UX.

Namun, enam langkah yang telah disebutkan tidak menjadi acuan bagi desainer UX maupun entitas dalam menentukan persyaratan UX. Tentunya ada banyak langkah cara dan metode yang dapat digunakan untuk menentukan persyaratan UX ini agar produk/sistem yang dibuat mencapai tujuan entitas, dan menyenangkan pengguna.

Reference:

Benyon, David. (2019). Designing user experience: A guide to HCI, UX and interaction design (4th Edition).04. Pearson. United Kingdom. ISBN: 978-1292155517.

Capturing UX requirements in 6 simple steps. (31 Januari 2019). UX Planet. https://uxplanet.org/capturing-ux-requirements-in-6-simple-steps-3bf6e0abee9c

Beatrice Madeline, Ferdianto

    Deprecated: Function get_option was called with an argument that is deprecated since version 5.5.0! The "comment_whitelist" option key has been renamed to "comment_previously_approved". in /var/www/html/public_html/sis.binus.ac.id/wp-includes/functions.php on line 6031