TIF22 – Interaksi Manusia dan

Komputer
Analisis Kebutuhan

Pertemuan ke 15-16
 Sub-CPMK
• Mahasiswa mampu membuat rancangan pre design
user interface sesuai hasil riset pengguna (C3, A3)

Materi
1. What, How and Why?
2. What are Requirements?
3. Data Gathering for Requirements
4. Bringing Requirements to Life : Personas and
Scenarios
5. Capturing Interaction with Use Cases
6. Pre Design
1. What, How and Why?
 1.1 What, How and Why?
• Apa saja yang harus dicapai dalam UX Research?
– Memahami pengguna, task, dan konteks
penggunaan secara menyeluruh
– Menghasilkan sekumpulan requirements yang
pasti (stable)
 1.1 What, How and Why?
(Lanj.)

• Bagaimana caranya?
– Melakukan pengumpulan data
– Melakukan analisis data Dilakukan secara iteratif

– Mengamati “Ekspresi”
Analisis Requirements

Sumber: Sharp, Peerce & Rogers (2019)

2. What are Requirements?
 Mendefinisikan
Requirements

• Apa yang diperlukan pengguna? Apa yang diinginkan

pengguna?
- Perlu dilakukan klarifikasi, perbaikan,
penyelesaian, dan re-scoping
- Input : Dokumen requirements
- Output : Kebutuhan pengguna yang stabil
 Mendefinisikan
Requirements (Lanj.)

• Mengapa kita perlu mendefinisikan kebutuhan?

- Requirements dihasilkan dari pemahaman akan
kebutuhan pengguna
- Requirements dipertanggungjawabkan
berdasarkan data yang diperoleh
2.1 Tujuh Dimensi Produk

Sumber: Sharp, Peerce & Rogers (2019)

 2.2 Tipe-Tipe Requirements
• Fungsional
- Apa Yang bisa dilakukan sistem

• Non-Fungsional
- Keamanan , respone time dll

• Data
- Apa jenisnya dan bagaimana disimpannya ?
 2.2 Tipe-tipe Requirements
(Lanj.)
• Berdasarkan Lingkungan atau konteks penggunaan,
mengacu pada keadaan dimana produk interaktif akan
beroperasi.
• Fisik : tingkat kebisingan, getaran, cahaya,
kelembapan, bentuk fisik dll (Misalny, di Rumah
Sakit).

• Sosial : kolaborasi dan koordinasi, berbagi data,

mendukung file sharing, komunikasi synchronous,
privasi pengguna.
 2.2 Tipe-tipe Requirements
(Lanj.)
• Organisasi : dukungan pengguna, adakah fasilitas
atau sumber daya untuk pelatihan, komunikasi
Hierarki, struktur komunikasi dan infrastruktur.

• Teknik : teknologi apa yang kompatibel dan

mungkin relevan?
 2.2 Tipe-tipe Requirements
(Lanj.)
• Users — siapa pengguna?
• Karakteristik: kebangsaan, latar belakang
pendidikan, kemampuan dan keterampilan,
keadaan pribadi pengguna, cacat fisik atau mental,
dan sebagainya.
 2.2 Tipe-tipe Requirements
(Lanj.)
• Penggunaan sistem:
a. Pemula: meminta bantuan langkah demi
langkah
b. Ahli: interaksi yang fleksibel dengan kekuatan
kendali yang lebih luas
c. Sering: navigasi pintasan
d. Santai / jarang: jalur menu yang jelas

• Profil pengguna, setiap orang berbeda dengan

lainnya.
 2.2 Tipe-tipe Requirements
(Lanj.)

• Usability goals

• User experience goals

• Produk yang berbeda memiliki persyaratan yang

berbeda dan dapat diterapkan dengan cara yang
berbeda, misalnya, kepercayaan
 2.2.1 Keamanan Yang
Digunakan
• Cara membuat keamanan kuat tanpa mengurangi
pengalaman pengguna
• Jika keamanan diabaikan, maka mekanisme
keamanan akan lemah
• Kata sandi sebagai contoh,
• Terlalu banyak saran tentang cara memilih kata
sandi
• Strategi menyalin dapat membahayakan
keamanan
3. Data Gathering for
Requirements
 3.1 Pengumpulan Data
untuk Requirements
• Wawancara
- Dapat menggunakan properti berupa contoh
skenario dan prototype.
- Bagus untuk mengeksplorasi isu.
- Tim pengembang dapat berdiskusi dengan
pengguna.
 3.1 Pengumpulan Data
untuk Requirements (Lanj.)
• Observasi Langsung
- Memperoleh gambaran lengkap mengenai task
yang dilakukan.
- Bagus untuk mengeksplorasi isu.
- Tim pengembang dapat berdiskusi dengan
pengguna.
 3.1 Pengumpulan Data
untuk Requirements (Lanj.)
• Observasi Tidak Langsung
- Jarang digunakan dalam aktivitas pendefinisian
kebutuhan
- Bagus untuk logging task yang sudah dilakukan
 3.1 Pengumpulan Data
untuk Requirements (Lanj.)

• Kuesioner
- Umumnya digunakan bersama teknik pengumpulan
data lainnya.
- Dapat memberikan data kuantitatif dan kualitatif.
- Bagus untuk menjawab pertanyaan yang spesifik
dari banyak responden.
 3.1 Pengumpulan Data
untuk Requirements (Lanj.)
• Focus Group
- Dapat berupa wawancara kelompok.
- Bagus untuk mencapai kesepakatan mengenai
requirements.
- Ada resiko dominasi individu tertentu.

• Meneliti produk serupa :

- Bagus untuk mendorong pendefinisian
requirements.
 3.1 Pengumpulan Data
untuk Requirements (Lanj.)
• Mempelajari dokumentasi :
– Prosedur dan aturan sering kali ditulis dalam
dokumentasi.
– Digunakan apabila stakeholder tidak memiliki waktu
yang cukup.
– Sumber data yang bagus untuk memahami tahapan
dalam task tertentu.
– Baik untuk memahami peraturan hukum dan
mendapatkan informasi latar belakang.
– Tidak ada pembatasan waktu.
 3.1.1 Pengumpulan Data
Gabungan
• Buku harian dan wawancara: mengunakan berbagai
perangkat informasi.

• Wawancara, think aloud evaluation, kuesioner,

evaluation of working prototype:
Misalnya; diterapkan pada pasien dengan cedera otak
traumatis sebagai bantuan memori.
 3.1.1 Pengumpulan Data
Gabungan (Lanj.)
• Mempelajari dokumentasi, mengevaluasi sistem lain,
observasi pengguna, dan wawancara kelompok :
Misalnya; sistem manuver kapal.

• Studi etnografi, wawancara, tes kegunaan, dan

partisipasi pengguna :
Misalnya; pada pengguna antarmuka tampilan 3D.
 3.2 Contextual Inquiry
• Bagian dari Desain Kontekstual, tetapi juga digunakan
sendiri untuk mengumpulkan requirements.

• Wawancara lapangan (wawancara kontekstual)

• 1,5 hingga 2 jam.
• Fokus pada kehidupan sehari-hari di rumah atau
pekerjaan yang relevan dengan proyek tersebut.
• Wawancara yang memposisikan user sebagai expert
dan researcher sebagai apprentice.
 3.2 Contextual Inquiry (Lanj.)
• Empat prinsip utama:
• Konteks : Menuju pengguna, di mana pun mereka
berada, dan melihat kegiatan yang mereka
lakukan.
• Kerjasama : User dan researcher berkolaborasi.
• Interpretasi : Interpretasi dilakukan bersama-sama
oleh user dan researcher.
• Fokus : Fokus pada proyek untuk memahami apa
yang perlu diperhatikan.
 3.3 Isu dalam Pengumpulan
Data
Beberapa hal yang perlu diperhatikan;
• Mengidentifikasi dan melibatkan responden
• Memastikan responden merupakan user yang
sebenarnya
• Dampak perubahan bisnis dan lingkungan yang ada
• Menyeimbangkan usability dengan fungsionalitas
 3.3 Isu dalam Pengumpulan
Data (Lanj.)
Beberapa hal yang perlu diperhatikan;
• Dominasi stakeholder tertentu yang mungkin terjadi
• Komunikasi antar pihak : dengan user, tim
pengembang, dsb.
• Domain knowledge yang bersifat terdistribusi dan
implisit
• Ketersediaan partisipan utama
 3.4 Panduan Pegumpulan
Data
Beberapa hal yang perlu diperhatikan;
• Fokus pada pendefinisian kebutuhan stakeholder
• Libatkan semua stakeholder dalam penelitian
• Libatkan lebih dari seorang perwakilan dari
stakeholder group
• Gunakan berbagai teknik pengumpulan data
• Gunakan task descriptions dan prototype
4. Bringing Requirements to Life
: Personas and Scenarios
 Implementasi Kebutuhan
• Menambah persyaratan dasar yang diekspresikan
sebagai cerita, dalam bentuk suatu rumusan.

• Persona
• Deskripsi yang kaya tentang pengguna biasa,
bukan orang tertentu.

• Skenario
• Cerita naratif informal, sederhana, 'alami', pribadi,
dan tidak dapat digeneralisasikan.
 4.1 Persona

• Persona adalah sebuah representasi pengguna

dalam bentuk individu imajiner yang memuat
rangkuman singkat mengenai karakteristik,
pengalaman, tujuan, tasks, pain points, dan kondisi
lingkungan pengguna yang sebenarnya.
 4.1 Persona (Lanj.)

• Setiap persona menggambarkan sekelompok orang

di dunia nyata
- Memudahkan desainer untuk fokus pada sebuah
ringkasan penggambaran sekelompok orang. Hal
ini lebih mudah dibandingkan dengan fokus pada
ribuan individu dengan perbedaan karakteristik
yang spesifik.
 4.1 Persona (Lanj.)

• Tujuan Persona
- Membuat sebuah penggambaran yang realistis
dan dapat diandalkan mengenai segmen
pengguna untuk dijadikan referensi
 4.1.1 Asal Muasal
Konsep Persona
Dari manakah konsep persona berasal ?
• Dikembangkan secara informal oleh Alan Cooper
pada dekade 1980an.
• Persona digunakannya untuk menginternalisasi
mindset pengguna.
• Menjadikan pengguna sebagai fokus utama dalam
perancangan aplikasi.
 4.1.1 Asal Muasal
Konsep Persona (Lanj.)
Persona menurut Alan Cooper,
• A model of our users, represented by composite
archetypes, based on behavioral data gathered from
the many actual users encountered in ethnographic
interviews.
• Personas are not real people, but they are based on
the behaviors and motivations of real people we
have observed and represent them throughout the
design process.
4.1.2 Contoh Persona

Sumber: Sharp, Peerce & Rogers (2019)

 4.1.3 Manfaat Persona
• Membangun empati
• Membangun fokus
• Berkomunikasi dan mencapai konsensus
• Membuat keputusan
• Mengukur efektifitas
 4.1.3 Manfaat Persona (Lanj.)
Bagi Profesional
• Project Leader : Mengevaluasi ide fitur baru pada
sebuah desain web Info.

• Architect : Acuan dalam mendesain wireframe,

interface behavior, dan labeling.

• UI Designer : Acuan dalam mendesain ‘look and

feel’ tampilan.
 4.1.3 Manfaat Persona (Lanj.)
Bagi Profesional
• System Engineer : Menentukan pendekatan yang
tepat sesuai user behavior.

• Copy Writer : Menulis konten yang tepat untuk

orang yang tepat.
 4.1.3 Manfaat Persona (Lanj.)
Mengatasi tiga isu “ dalam desain interaksi
• Elasctic User
- Kurangnya pengetahuan yang presisi mengenai
pengguna dapat mengakibatkan ketidakjelasan
pada bagaimana suatu produk seharusnya bekerja
- Setiap kali pengguna meminta sesuatu, desain
berubah
- Sulit menentukan fitur yang akan diprioritaskan
(Apa tujuan utama pengguna)
 4.1.3 Manfaat Persona (Lanj.)
• Self-referential Design
- Terjadi ketika desainer atau pengembang
menggunakan mental model, cara pandang, tujuan,
motivasi dan keahliannya sendiri ketika mendesain
suatu produk.
- Umumnya programmer akan melakukan hal ini
dalam membuat implementation-model product
sebab mereka faham akan struktur data dan cara
kerja software.
- Sedikit non-programmer akan sepakat dalam hal ini.
 4.1.3 Manfaat Persona (Lanj.)
• Edge Case
- Persona menyediakan reality check untuk desain.
- Kita dapat bertanya : “Apakah pengguna sering
menggunakan fitur X?” “Seberapa sering pengguna
melakukan proses X?”
- Edge cases terjadi ketika fitur yang dikembangkan
tidak pernah dipakai oleh pengguna.
 4.1.4 Elemen Dasar Persona
• Technology Comfort Level
Tingkat kenyamanan dalam menggunakan TI.

• Motivasi
Menjelaskan mengapa pengguna ingin mencapai
tujuannya.

• Attitude
Sikap pengguna yang relevan dan menjelaskan
behavior.
 4.1.5 Tipe Persona Lainnya
• Marketing Persona
Fokus pada informasi demografis, buying behaviour,
preferensi dan motivasi.

• Design Persona
Fokus pada user goals, behaviour saat ini, dan pain points.

• Proto Persona
Dibuat ketika ada keterbatasan sumber daya dan
berdasarkan riset sekunder yang dilakukan tim.
 4.2 Skenario

Mulai Aktifitas 1 Aktifitas 2 Tujuan

• Sebuah narasi yang menjelaskan konteks

penggunaan sistem oleh persona.
• Menjelaskan urutan aktivitas yang dilakukan persona
serta sikapnya selama melakukannya
- Memberikan persona suatu konteks dan
memudahkan kita memahami user flow.
 4.2.1 Manfaat Skenario
• Sebuah cerita dan konteks yang mendasari kenapa
seorang user mengunjungi website kita.

• Memuat tujuan dan juga, seringkali, penjelasan

bagaimana user dapat mencapai tujuannya
- Menjelaskan cerita bagaimana suatu produk
digunakan Dibuat .
- berdasarkan kebutuhan dan tujuan persona,
bukan dari kapabilitas system.
- Skenario mempermudah menjelaskan dan
memprioritaskan fitur yang dimiliki system.
 4.2.2 Konsep Skenario
Bersifat
naratif

Skenario Goal 1
Goal 2
Goal 3
Persona Goal 4
Storyboard

Bersifat
Visual
 4.2.3 Hal yang Perlu
Diperhatikan Ketika
Menulis Skenario
• Siapakah Penggunanya?
Gunakan persona yang telah dibuat untuk
merefleksikan major user yang sebenarnya.

• Mengapa Pengguna Datang ke Situs Kita?

Temukan apa yang memotivasi user untuk datang
dan ekspektasi mereka.
 4.2.3 Hal yang Perlu
Diperhatikan Ketika
Menulis Skenario (Lanj.)
• Apa Tujuan Mereka?
Melalui task analysis kita dapat mengetahui tujuan
user dan merancang sistem agar dapat memenuhi
kebutuhan mereka.

• Bagaimana Pengguna Dapat Mencapai Tujuannya?

Menjelaskan cara user untuk mencapai tujuannya.
Memuat rincian kemungkinan dan tantangan yang
mungkin dihadapi.
 4.2.4 Tipe-Tipe Skenario

• Goal/Task-Based Scenario
- Hanya menjelaskan apa yang ingin dilakukan oleh
pengguna
- Tidak memuat informasi tentang cara pengguna
mencapai tujuannya
- Bagus untuk menentukan arsitektur situs web dan
kontennya
 4.2.4 Tipe-Tipe Skenario
(Lanj.)
• Elaborated Scenario
- Diceritakan secara lebih mendetail, seperti
memuat karakteristik user
- Pemahaman karakteristik user, dapat membantu
merancang interaksi sistem
- Bagus untuk menentukan konten, fungsionalitas,
dan site behaviour
 4.2.4 Tipe-Tipe Skenario
(Lanj.)
• Full Scale Scenario
- Memuat langkah-langkah untuk menyelesaikan
task
- Langkah dapat merupakan langkah yang dijalankan
user saat ini ataupun langkah usulan
- Menjelaskan bagaimana sistem dapat mendukung
goal-oriented scenario yang dirancang
5. Capturing Interaction with
Use Cases
 Task Description

Skenario Use Cases Essential Use

Sebuah cerita Menggambarkan case
naratif informal interaksi dalam Menggambarkan
sistem interaksi secara
garis besar
 5.1 Contoh Skenario – Travel
Organizer
“The Thomson family enjoy outdoor activities and want
to try their hand at sailing this year. There are four
family members: Sky (8 years old), Eamonn (12 years
old), Claire (32), and Will (35). One evening after dinner
they decide to start exploring the possibilities. They
want to discuss the options together but Claire has to
visit her elderly mother so will be joining the
conversation from her mother’s house down the road.
As a starting point, Will enters an idea they had been
discussing over dinner – a sailing trip for four novices in
the Mediterranean.
 5.1 Contoh Skenario – Travel
Organizer (Lanj.)
The system supports users to log on from different
locations and use different devices so that all members
of the family can interact easily and comfortably with it
wherever they are. The system's initial suggestion is a
flotilla, where several crews (with various levels of
experience) sail together on separate boats. Sky and
Eamonn aren't very happy at the idea of going on
vacation with a group of other people, even though the
Thomson’s would have their own boat.
 5.1 Contoh Skenario – Travel
Organizer (Lanj.)
The travel organizer shows them descriptions of flotillas
from other children their ages and they are all very
positive, so eventually, everyone agrees to explore
flotilla opportunities. Will confirms this
recommendation and asks for detailed options. As it's
getting late, he asks for the details to be saved so
everyone can consider them tomorrow. The travel
organizer emails them a summary of the different
options available.”
5.1.1 Skenario dan Persona

Sumber: Sharp, Peerce & Rogers (2019)

 5.1.2 Contoh Use Case
Use case for travel organizer
1. The system displays option for investigating visa and
vaccination requirements
2. The user chooses the option to find out about visa
requirements
3. The system prompts user for the name of the
destination country
4. The user centers the country’s name
5. The system checks that the country is valid.
 5.1.2 Contoh Use Case (Lanj.)
Use case for travel organizer
6. The system prompts the user for her nationality.
7. The user enters her nationality.
8. The system checks the visa requirements of the
entered country for a passport holder of her
nationality.
9. The system displays the visa requirements.
10.The system displays the option to print out the visa
requirements.
11.The user chooses to print the requirements.
5.1.3 Use Case Diagram
 5.1.4 Contoh Langkah
Alternatif
Some alternative courses:
6. If the country name is invalid:
6.1: The system displays an error message
6.2: The system returns to step 3
8. If the nationality is invalid:
8.1: The system displays an error message
8.2: The system returns to step 6
9. If no information about visa requirements is found:
9.1: The system displays a suitable message
9.2: The system returns to step 1
 5.1.5 Contoh Essential
Use Case
RetrieveVisa
USER INTENTION SYSTEM RESPONSIBILITY

Find visa requirements Request destination and nationality

Supply required information Obtain appropriate visa info

Obtain copy of visa info Offer info in different formats

Choose suitable format Provide info in chosen format

 5.2 Task Analysis
• Digunakan untuk menggambarkan penggunaan sistem
baru.
• Digunakan untuk menginvestigasi situasi penggunaan
saat ini.
• Ada beberapa hal yang perlu diperhatikan antara lain :
- Apa yang ingin dicapai pengguna ?
- Bagaimana cara mencapainya ?
- Bagaimana mereka melakukannya ?
 5.2.1 Hierarchical Task
Analysis
Example Hierarchical Task Analysis
0. In order to buy a DVD
1. Locate DVD
2. Add DVD to shopping basket
3. Enter payment details
4. Complete address
5. Confirm order
Plan 0 : if regular user do 1-2-5
if new user do 1-2-3-4-5
5.2.2 Contoh Hierarchical
Task Analysis

Sumber: Sharp, Peerce & Rogers (2019)

6. Pre Design
 6.1 Langkah-Langkah
Membuat Persona
• Persona adalah produk riset sehingga
kompleksitasnya bergantung pada kerumitan riset.

• Persona haruslah benar-benar menggambarkan

pengguna yang sebenarnya.

• Persona harus didasari pemahaman mengenai

pengguna, tujuannya, dan prioritasnya.
 6.1 Langkah-Langkah
Membuat Persona (Lanj.)
• Riset dan metode task analysis dilakukan melalui,
- Contextual Interview
- Individual Interview
- Survey
- Focus Group
- Usability Testing
 6.1.1 Riset Pengumpulan Data
1. Melakukan riset pengguna
Observasi atau wawancara sejumlah orang.

2. Mengerucutkan Riset
Temukan tema yang spesifik, relevan dan universal
terhadap sistem dan penggunanya.

3. Brainstroming
Kelompokkan elemen ke dalam grup persona yang
merepresentasikan kelompok yang spesifik.
 6.1.1 Riset Pengumpulan Data
(Lanj.)
4. Refine
Kombinasikan dan tentukan prioritas persona.
Pisahkan ke dalam beberapa kategori

5. Jadikan Persona Realistis

Dengan menambahkan deskripsi latar belakang,
motivasi dan ekspektasi
 6.1.1 Riset Pengumpulan Data
(Lanj.)
6. Bagikan Persona
Bagikan dan diskusikan persona dengan tim
pengembang.
6.1.2 Contoh Pertanyaan
Riset

Sumber: Sharp, Peerce & Rogers (2019)

6.1.3 Contoh Desain Persona
Nama yang realistis
Foto

Data demografi
Umur, gender,
pendidikan dll
Tujuan

Latar belakang
Pain Points

Sumber: Sharp, Peerce

& Rogers (2019)
 6.1.4 Persona yang Efektif
• Representatif
• Menggambarkan dengan jelas
• Deskripsi sesuai kenyataan
• Realistis, tidak imajiner
• Fokus pada major needs
• Fokus pada important users
• Fokus pada current state
• Membantu memahami user
 6.1.5 Isu dalam Pembuatan
Persona
• Ketersediaan Data
- UX Researcher mungkin tidak memiliki akses ke
end users.
- Variasi
• Jika akses ke end user tidak ada, persona dapat
dibuat dengan bantuan user expert.
• Sulit menentukan fitur yang akan diprioritaskan
(Apa tujuan utama pengguna).
 6.1.5 Isu dalam Pembuatan
Persona (Lanj.)
• Kuantitas
- Tidak jelas berapa persona yang perlu dibuat dan
sampai sedalam apa.
- Jumlah persona tergantung pada jumlah target
audience. Kompleksitasnya tergantung kedalaman
riset yang dilakukan.
- Umumnya tim memulai dengan membuat banyak
persona untuk semua kelompok individu
pengguna.
 6.1.5 Isu dalam Pembuatan
Persona (Lanj.)
• Kuantitas
- Setelah itu, persona-persona tersebut dieliminasi
hingga diperoleh satu primary persona yang
menggambarkan important user.
- Secondary persona diperhatikan dalam proses
desain setelah primary persona diperhatikan.
 6.1.6 Mengevaluasi Persona
• Apakah persona dibuat berdasarkan wawancara
dengan user ?
• Apakah persona menjelaskan product-relevant high-
level key goal?
• Apakah persona tampak realistis bagi yang
berinteraksi dengan end user ?
• Apakah setiap persona yang dibuat unik satu sama
lain ?
• Dapatkah persona digunakan tim desainer untuk
menentukan desain ?
 6.2 Pembuatan Skenario
Skenario untuk mendesain Web;
• Menjelaskan 10 - 30 alasan mengapa user mengunjungi
dan melakukan task pada website
- Apa saja yang diharapkan akan dicapai oleh persona
dengan mengunjungi website ?
- Karakteristik persona yang mana yang dapat merintangi
atau membantu interaksinya dengan sistem ?

• Fokus pada user dan task yang dilakukannya ketimbang

pengaturan dan struktur internal situs.
 6.2 Pembuatan Skenario (Lanj.)
Skenario untuk Usability Testing;
• Ketika mengidentifikasi skenario UT, batasi test
sehingga hanya 10 - 12 task saja
- Tanyakan user bagaimana alur yang mereka
lakukan sendiri pada sistem
- Tanyakan mengapa mereka mau mengunjungi
sistem
- Tanyakan apa yang akan mereka lakukan selama
berinteraksi dengan sistem
 6.2 Pembuatan Skenario (Lanj.)
• Seluruh skenario UT yang disampaikan ke user tidak
boleh memuat cara menyelesaikan suatu task
- Skenario UT hanya membantu user memahami
konteks penggunaan saja
- Bandingkan skenario yang tidak disampaikan ke
user dengan alur yang dijalankan oleh user. Apakah
user dapat menyelesaikan task nya ?
 6.3 Storyboard

• Berfungsi untuk menjelaskan secara visual user story

atau skenario yang dibuat
- Dengan penjelasan secara visual, konteks
penggunaan sistem lebih mudah dipahami.
- Dapat digunakan sebagai alat untuk memahami
kebutuhan user secara komprehensif.
 6.3 Storyboard (Lanj.)

• Storyboard dapat dibuat dengan tiga cara,

1.Sketch, Sketsa sederhana diatas kertas
2.Template, Seperti pada tool StoryboardThat
3.Graphic Design tool, Adobe illustrator & Inkscape
6.3.1 Tool : StoryboardThat

Sumber: https://www.storyboardthat.com/
 Latihan Studi Kasus
• Mahasiswa menentukan requirements dari
hasil analisis data pada Latihan studi kasus
pertemuan 6 dan 7.
• Membuat skenario dan persona untuk desain
interaksi dari topik yang dipilih
 Ringkasan
• Requirements adalah pernyataan mengenai
kebutuhan yang dimaksudkan yang menentukan apa
yang diharapkan untuk dilakukan atau bagaimana
kinerjanya.

• Requirements dilakukan untuk menghindari

miskomunikasi dan mendukung pengembang teknis
dan kontribusi pengguna.
 Ringkasan (Lanj.)
• Jenis requirements : fungsional, data, lingkungan
(konteks penggunaan), karakteristik pengguna,
usability goals, dan user experience goals.

• Pengumpulan data untuk requirements

menggunakan: angket, wawancara, observasi, studi
dokumentasi, dan produk sejenis.
 Ringkasan (Lanj.)

• Skenario adalah narasi berbasis cerita untuk

mengeksplorasi perilaku yang ada, potensi konsep
baru, dan visi penggunaan futuristik.

• Persona menangkap karakteristik pengguna tipikal

yang relevan dengan konsep yang sedang
dikembangkan.
 Ringkasan (Lanj.)

• Skenario dan persona keduanya merupakan

implementasikan requirements ke konsep nyata.

• Use case menangkap detail interaksi yang ada atau

menggambarkan pengguna dan produk.
Terima Kasih