Lecture 6

Interaction Design Support

Introduction
Desain beberapa alternatif, dievaluasi dan dipilih Hindari evolusionary prototyping (merubah perlahan-lahan) Dokumentasikan ide-ide yang pernah ada (jangan hanya diingat-ingat) Design Rationale
2

Supporting the Design Process

Untuk mendukung proses desain, gunakanlah teknik dan tools
Gunakan software diagramming (ER/DFD editors) Diskusikan dalam team Mengevaluasi dan memilih alternatif Gunakan software yang mendukung misal untuk buat tampilan layar, icons, dsb.
3

Supporting Designers (1)

Cari desainer yang berpengalaman Gunakan pengalaman dari proyekproyek yang sebelumnya Bagi masalah menjadi modul-modul yang cukup sederhana

Supporting Designers (2)

Buat desain alternatif, dievaluasi dan dipilih yang terbaik Buat prototype Memahami masalah utama sehingga hasilnya bisa usable Desain berdasarkan ide yang ada

Supporting Design Teams

Komunikasikan dalam team Masalah komunikasi disebabkan karena penulisan dokumentasi saja tidaklah cukup Perlu meeting untuk membicarakan

Berbagai Macam Dukungan

Pedoman mulai dari yang umum sampai yang detail Dukungan komunikasi dan catatan keputusan ambil ide dan kembangkan alternatif Software pendukung ambil ide, kembangkan alternatif, catat keputusan dan buat programnya
7

Perbedaan: Principles and Rules

Principles lebih general, harus diinterprestasikan dan diartikan sebagai strategi (misal: harus konsisten) Rules lebih khusus (straight forward) pasti dipatuhi dan mudah dimengerti (misal: format tanggal harus mm/dd/yyyy)
8

Dukungan berasal dari:

Practical dari orang yang berpengalaman dibidang tersebut Psycological biasanya dari hasil research
(misal background gelap, tulisan harus terang)
9

Design Rationale (1)

Design Rationale adalah alasan yang menjadi latar belakang dari suatu software Design Rationale didokumentasikan sebagai sebuah deskripsi yang terpadu dari sistem yang kita kembangkan (mengapa dipilih desain ini atau itu?)
10

Design Rationale (2)

Design Rationale diperlukan oleh:
Software maintainers Trainers Marketing Personnel New staff in development team Design team members End users

11

Kegunaan Design Rationale (1)

Bagi user baru, untuk mempelajari keputusan-keputusan yang sudah dibuat saat desain. (supaya tidak mengambil keputusan yang bertentangan) Bagi anggota team desain, untuk mengetahui apa yang menjadi alasan pada saat sistem dikembangkan sehingga bisa membuat aplikasi yang tidak bertentangan.
12

Kegunaan Design Rationale (2)

Bagi end user, supaya mengerti bagaimana sistem dibangun. Untuk mendapatkan sebuah desain dan catatan keputusan. Bagi software mantainer, untuk mengetahui bagaimana merubah sistem tanpa mengubah stabilitas sistem.
13

Kegunaan Design Rationale (3)

Bagi marketing, supaya bisa menjelaskan ke customer tentang sistem. Bagi trainer, supaya bisa membantu user dengan baik.

14

Design Rationale Tips

Jangan mendokumentasikan terlalu mendetail. Dokumentasikan yang utama. Mendokumentasikan keputusankeputusan yang sulit (pro-kontra). Dokumentasikan analisa dari masingmasing alternatif.
15

Dokumentasi Design Rationale

IBIS (Issue-Based Information Systems): cara dokumentasi yang tertua. Design Space Analysis: mendokumentasikan desain-desain yang patut dikembangkan dan alasan memilih desain terakhir. Claims Analysis: mendokumentasikan desain yang dikembangkan terus hingga dapat mengalami evolusionary desain.
16

IBIS (1)
Dokumentasi dilakukan bersamaan dengan proses desain. Titik beratnya adalah mempertimbangkan pendapat yang pro dan kontra.

17

IBIS (2)
Issues pertanyaan Positions jawaban Arguments pendapat (pro kontra)

18

IBIS (3)
IBIS dimulai dari pertanyaan
Misal: sebaiknya pakai warna apa?

Positions adalah jawaban dari issues (jawaban bisa pro dan kontra)
Misal: warna merah atau putih?

Bisa juga timbul pertanyaan lainnya, bisa juga timbul pendapat

Misal: kalau merah lebih menarik tetapi sulit cari foreground, kalau putih lebih netral
19

Design Space Analysis

Lebih disukai / lebih banyak dipakai. Desain dapat ditampilkan dalam beberapa alternatif. Proses dari desain termasuk mengidentifikasi tujuan dan hambatanhambatannya.

20

Design Space Analysis Notation

QOC (Questions, Options, and Criteria)
Questions pertanyaan. Options jawaban dari pertanyaan. Criteria tujuan yang digunakan untuk memberikan argument pada alternatifalternatif

21

Contoh Design Space Analysis

Desain UNDO pada multi-user text editor. Dua versi undo:
Relative to the individual: user individual dapat melakukan UNDO hanya pada kegiatannya sendiri. Relative to the document: UNDO dapat dilakukan tanpa memandang siapa yang melakukan kegiatan sebelumnya.

Dua versi software:

first release: single insertion point, dengan control users dengan suatu action yang eksplisit. second release: multiple insertion points, setiap user bisa melakukan aksi secara simultan

22

Contoh Design Space Analysis

C: User predictability

O: Individual user
Q: What is UNDO relative to? C: Learnability O: Document C: Ease of Implementation C: Awareness of others work O: One Q: How many simultaneous insertion points? C: Low cognitive load O: Many

C: Accessibility

23

Claims Analysis (1)

Claim Analysis adalah membuat dokumentasi dengan menuliskan skenario dari kegunaan sistem dan analisanya. Tujuan utamanya adalah mengidentifikasi bagaimana sistem dapat memberikan support yang positif pada pemakai.
24

Claims Analysis (2)

Claim dengan desain ini keuntungannya apa? Analysis claim yang dianalisa misal: cepat, jika programnya kecil atau sederhana. Kalau mau yang komplex, pemrogramannya lama.

25

Bacaan
Preece, chapter 23, 24, 26

26