Pertemuan 6) The - Elements - of - User - Experience - TRanslate

Machine Translated by Google
ELEMEN DARI _
PENGALAMAN PENGGUNA
EDISI KEDUA
DESAIN YANG BERPUSAT PENGGUNA

UNTUK WEB DAN SELANJUTNYA
Ditulis dan diilustrasikan oleh

Jesse James Garrett
Elemen Pengalaman Pengguna: Desain yang Berpusat pada Pengguna untuk Web dan Lebih Jauh,
Edisi kedua
Jesse James Garrett
Penunggang Baru1249 Eighth Street

Berkeley, CA 94710
510/524-2178
510/524-2221 (faks)
Temukan kami di Web di: www.newriders.com

Untuk melaporkan kesalahan, silakan kirim catatan ke errata@peachpit.com Penunggang
Baru adalah jejak Peachpit, sebuah divisi dari Pearson Education.
Hak Cipta © 2011 oleh Jesse James Garrett
Editor Proyek: Michael J. Nolan

Editor Pengembangan: Rose Weiburd
Editor Produksi: Tracey Croom Copyeditor:
Doug Adrianson Proofreader: Gretchen
Dykstra Pengindeks: Valerie Perry
Desainer Sampul: Aren Howell Straiger
Desainer Interior: Kim Scott
Komposer: Kim Scott
Pemberitahuan Hak
Seluruh hak cipta. Tidak ada bagian dari buku ini yang boleh direproduksi atau ditransmisikan dalam bentuk apa pun dengan
cara apa pun, elektronik, mekanis, fotokopi, rekaman, atau lainnya, tanpa izin tertulis sebelumnya dari penerbit. Untuk
informasi tentang mendapatkan izin untuk mencetak ulang dan kutipan, hubungi permissions@peachpit.com.
Pemberitahuan Tanggung Jawab
Informasi dalam buku ini didistribusikan berdasarkan “Apa Adanya” tanpa jaminan. Sementara setiap tindakan pencegahan telah
diambil dalam persiapan buku ini, baik penulis maupun Peachpit tidak bertanggung jawab kepada orang atau badan mana pun
sehubungan dengan kehilangan atau kerusakan yang disebabkan atau diduga disebabkan secara langsung atau tidak langsung oleh
instruksi yang terkandung dalam buku ini. atau oleh produk perangkat lunak dan perangkat keras komputer yang dijelaskan di
dalamnya.
Merek Dagang
Banyak sebutan yang digunakan oleh produsen dan penjual untuk membedakan produk mereka diklaim sebagai merek dagang. Di
mana sebutan tersebut muncul dalam buku ini, dan Peachpit mengetahui adanya klaim merek dagang, penunjukan tersebut muncul
seperti yang diminta oleh pemilik merek dagang.
Semua nama produk dan layanan lain yang disebutkan dalam buku ini hanya digunakan dalam gaya editorial dan untuk
keuntungan perusahaan tersebut tanpa maksud melanggar merek dagang. Tidak ada penggunaan semacam
itu, atau penggunaan nama dagang apa pun, yang dimaksudkan untuk menyampaikan dukungan atau afiliasi lain dengan buku ini.
ISBN 13: 978-0-321-68368-7

ISBN 10: 0-321-68368-4
987654321
Dicetak dan dijilid di Amerika Serikat

Untuk istri saya, Rebecca Blood Garrett, yang

membuat segalanya menjadi mungkin.
iv UNSUR PENGALAMAN PENGGUNA
Daftar isi
BAB 1
Pengalaman Pengguna dan Mengapa Itu Penting 2
Kesengsaraan Sehari-hari 3
Memperkenalkan Pengalaman Pengguna 4
Dari Desain Produk hingga Desain Pengalaman Pengguna 7
Merancang (untuk) Pengalaman: Penggunaan Penting 8
Pengalaman Pengguna dan Web 9
Pengalaman Pengguna yang Baik Adalah Bisnis Yang Baik 12
Memperhatikan Pengguna Anda 17
BAB 2
Memenuhi Elemen 18
Lima Pesawat 19
Pesawat Permukaan 20
Pesawat Kerangka 20
Pesawat Struktur 20
Pesawat Lingkup 21
Pesawat Strategi 21
Membangun dari Bawah ke Atas 21
Dualitas Dasar 25
Elemen Pengalaman Pengguna 28
Pesawat Strategi 28
Pesawat Lingkup 29
Pesawat Struktur 30
Pesawat Kerangka 30
Pesawat Permukaan 30
Menggunakan Elemen 31
UNSUR PENGALAMAN PENGGUNA v
BAGIAN 3
Pesawat Strategi
Tujuan Produk dan Kebutuhan Pengguna 34
Mendefinisikan Strategi 36
Tujuan Produk 37
Tujuan bisnis 37
Identitas merek 38
Metrik Sukses 39
Kebutuhan Pengguna 42
Segmentasi Pengguna 42
Kegunaan dan Riset Pengguna 46
Membuat Persona 49
Peran dan Proses Tim 52
BAB 4
Pesawat Lingkup
Spesifikasi Fungsional dan Persyaratan Konten 56
Mendefinisikan Ruang Lingkup 58

Alasan #1: Jadi Anda Tahu Apa
Anda sedang membangun 59

Alasan #2: Jadi Anda Tahu Apa
Anda Tidak Membangun 60
Fungsionalitas dan Konten 61
Mendefinisikan Persyaratan 65
Spesifikasi Fungsional 68
Menuliskannya 69
Persyaratan Konten 71
Memprioritaskan Persyaratan 74
vi UNSUR PENGALAMAN PENGGUNA
BAB 5
Pesawat Struktur
Desain Interaksi dan Arsitektur Informasi 78
Mendefinisikan Struktur 80
Desain Interaksi 81
Model Konseptual 83
Penanganan Kesalahan 86
Arsitektur Informasi 88
Penataan Konten Pendekatan 89
Arsitektur Prinsip 92
Pengorganisasian Bahasa dan 96
Metadata 98
Peran dan Proses Tim 101
BAB 6
Pesawat Kerangka
Desain Antarmuka, Desain Navigasi, dan
Desain Informasi 106
Mendefinisikan Kerangka 108
Konvensi dan Metafora 110
Desain antarmuka Desain 114
Navigasi 118
Desain Informasi 124

Pencarian jalan 127
Gambar rangka 128
UNSUR PENGALAMAN PENGGUNA vii
BAB 7
Pesawat Permukaan
Desain Sensorik 132
Mendefinisikan Permukaan 134
Memahami Perasaan Bau 135

dan Rasa 135
Menyentuh 135
Pendengaran 136
Penglihatan 136
Ikuti Mata 137
Kontras dan Keseragaman Konsistensi 139
Internal dan Eksternal Palet Warna dan 143
Tipografi 145
Komps Desain dan Panduan Gaya 148
BAB 8
Elemen yang Diterapkan 152
Mengajukan Pertanyaan yang Tepat 157
Marathon dan Sprint 159
Indeks 164
viii
UNSUR PENGALAMAN PENGGUNA
tentang Penulis
Jesse James Garrett adalah salah satu pendiri Adaptive Path, a
konsultasi pengalaman pengguna yang berbasis di San Francisco. Sejak tahun 1995, Jesse telah
mengerjakan proyek Web untuk perusahaan seperti AT&T,
Intel, Boeing, Motorola, Hewlett-Packard, dan Publik Nasional Radio.

Foto oleh: Colin Peck
Kontribusinya di bidang pengalaman pengguna termasuk:
Kosakata Visual, sistem notasi terbuka untuk arsip informasi dokumentasi
struktur yang sekarang digunakan oleh organisasi di sekitar Dunia. Situs
pribadinya di www.jjg.net adalah salah satu Web
tujuan paling populer untuk sumber daya arsitektur informasi,
dan dia sering menjadi pembicara tentang arsitektur informasi dan pengguna masalah
pengalaman.
UNSUR PENGALAMAN PENGGUNA ix
Ucapan Terima Kasih untuk Edisi Kedua

Michael Nolan menghabiskan bertahun-tahun mendorong saya untuk membuat edisi kedua. Miliknya
ketekunan — dan kecerdikannya dalam akhirnya datang dengan tawaran aku tidak
bisa dilewatkan—adalah alasan mengapa hal itu ada.
Di Penunggang Baru, tim Rose Weisburd, Tracey Croom, dan Kim
Scott membuat saya tetap di jalur. Nancy Davis, Charlene Will, Hilal Sala, and
Mimi Vitetta membantu membuat semuanya berjalan lancar. Terima kasih juga untuk Samantha
Bailey dan Karl Fast atas dukungan mereka.
Istri saya, Rebecca Blood Garrett, tetap menjadi yang pertama, terakhir, dan paling utama bagi saya
editor tepercaya, penasihat, dan orang kepercayaan.
Tambahan baru untuk skor musik kali ini adalah Jepang kue,
Mono, Maserati, Tarentel, Orang Tidur, Kode di
Awan, dan (terutama) Ledakan di Langit. Terima kasih yang sangat istimewa
kepada Steve Scarborough dari Maserati untuk bimbingan musik.
Ucapan Terima Kasih untuk Edisi Pertama

Jangan biarkan jumlah nama di sampul membodohi Anda — dibutuhkan banyak orang
untuk membuat sebuah buku terjadi.
Pertama, saya harus berterima kasih kepada mitra saya di Adaptive Path: Lane Becker, Janice
Fraser, Mike Kuniavsky, Peter Merholz, Jeffrey Veen, and
Indi Muda. Melalui kegemaran mereka, saya bisa menerima
proyek ini sama sekali.
Lalu ada semua orang di New Riders, terutama Michael Nolan,
Karen Whitehouse, Victoria Elzey, Deborah Hittel-Shoaf, John
Rahm, dan Jake McFarland. Bimbingan mereka sangat penting untuk ini
proses.
x UNSUR PENGALAMAN PENGGUNA
Kim Scott dan Aren Howell memberikan perhatian dan perhatian yang tajam pada
desain buku ini. Kesabaran mereka dengan saran dari
penulis sangat terpuji.
Molly Wright Steenson dan David Hoffer memberikan yang tak ternilai wawasan
dalam ulasan mereka tentang naskah saya. Setiap penulis harus sangat beruntung.
Jess McMullin ternyata menjadi kritikus terberat saya dalam banyak hal, dan buku ini
meningkat tak terkira oleh pengaruhnya.
Terima kasih juga kepada penulis yang lebih berpengalaman yang memberi
saya saran tentang cara menangani proyek seperti ini dan mempertahankan saya kewarasan:
Jeffrey Veen (lagi), Mike Kuniavsky (lagi), Steve Krug,

June Cohen, Nathan Shedroff, Louis Rosenfeld, Peter Morville, and
(terutama) Steve Champeon.
Orang lain yang menawarkan saran berharga atau moral yang baik dukungan
termasuk Lisa Chan, George Olsen, Christina Wodtke, Jessamyn West,
Samantha Bailey, Eric Scheid, Michael Angeles,
Javier Velasco, Antonio Volpon, Vuk Cosic, Thierry Goulet, dan Dennis Woudt.
Mereka memikirkan hal-hal yang tidak saya pikirkan, dan itu membuat mereka
adalah rekan kerja terbaik.
Iringan musik untuk proses penulisan disediakan oleh
Man or Astro-man?, Pell Mell, Mermen, Dirty Three, Trans Am, Tortoise, Turing
Machine, Don Caballero, Mogwai, Ui, Shadowy
Men on a Shadowy Planet, Do Make Say Think, dan (terutama)
Astaga, Anda Kaisar Hitam!

UNSUR PENGALAMAN PENGGUNA xi
Akhirnya, ada tiga orang yang tanpanya buku ini
belum pernah terjadi: Dinah Sanders, yang di pesta yang hangat
Texas night bersikeras bahwa ada seseorang yang harus kutemui; istriku, Rebecca Blood,
yang membuatku lebih kuat dan lebih bijaksana dalam segala hal; dan Daniel Grassam,
yang tanpa persahabatan, dorongan,
dan dukungan Saya mungkin tidak menemukan jalan saya ke bisnis ini di
semua. Terima kasih.

halaman ini sengaja dibiarkan kosong

Pengantar
Edisi kedua
Mari kita potong untuk mengejar: Ini adalah edisi kedua. Apa yang berbeda?
Perbedaan utama antara edisi ini dan yang pertama adalah ini
buku tidak lagi hanya tentang situs Web. Ya, sebagian besar contohnya adalah
masih terkait Web, tetapi secara keseluruhan, tema, konsep, dan prinsip berlaku untuk semua jenis produk
dan layanan.
Ada dua alasan untuk ini, keduanya berkaitan dengan apa yang terjadi selama sepuluh tahun terakhir. Salah
satunya adalah apa yang terjadi pada Elements,
dan salah satunya adalah apa yang terjadi pada pengalaman pengguna itu sendiri.
Selama bertahun-tahun, saya telah mendengar dari (atau mendengar tentang) orang yang memiliki
menerapkan model Elemen ke produk yang tidak ada hubungannya dengan Web. Dalam beberapa kasus
mereka adalah desainer Web yang diminta untuk mengambil
sesuatu yang baru, seperti aplikasi seluler. Dalam kasus lain, mereka adalah desainer dari jenis
produk lain yang entah bagaimana menemukan
Elemen dan melihat koneksi ke pekerjaan mereka sendiri.

xiv PENGANTAR
Sementara itu, bidang pengalaman pengguna telah memperluas cakrawalanya. Praktisi
sekarang secara teratur berbicara tentang dampak dan nilai pengguna pengalaman
desain di area yang jauh melampaui konteks terbatas
Web atau bahkan aplikasi interaktif berbasis layar yang mendominasi

percakapan kembali ketika buku ini pertama kali ditulis.
Edisi baru buku ini memiliki pandangan yang sama luasnya. Web masih
menjadi pusat buku, jika hanya untuk mengakui akar model
dalam media itu. Tapi buku ini tidak membutuhkan pengetahuan orang dalam tepi
bagaimana pengembangan Web terjadi—bahkan jika Anda tidak membuat
makan situs Web, Anda harus dapat melihat bagaimana menerapkan ide-ide ini dalam
pekerjaan Anda sendiri.
Terlepas dari semua ini, Anda yang telah membaca edisi pertama harus
yakinlah: Ini bukan penemuan kembali yang radikal. Ini mengasah dan
penyempurnaan dari model Elemen yang Anda kenal (dan harap sepenuhnya
cinta), dengan ide inti dan filosofi yang sama. Itu
hal-hal kecil berubah, tetapi hal-hal besar benar-benar tidak
Saya tetap bersyukur dan rendah hati dengan apa yang telah diambil orang
Elemen. Saya tidak sabar untuk melihat apa yang terjadi selanjutnya!
Jesse James Garrett
November 2010
Pengantar Edisi
Pertama
Ini bukan buku petunjuk. Ada banyak, banyak buku di luar sana
yang menjelaskan bagaimana situs Web dibuat. Ini bukan salah satunya.
Ini bukan buku tentang teknologi. Tidak ada satu baris pun
kode yang dapat ditemukan di antara sampul-sampul ini.
Ini bukan buku jawaban. Sebaliknya, buku ini adalah tentang menanyakan
pertanyaan yang tepat.
Buku ini akan memberi tahu Anda apa yang perlu Anda ketahui sebelum Anda membaca
buku-buku lain itu. Jika Anda membutuhkan gambaran besar, jika Anda perlu di bawah
berdiri konteks untuk keputusan yang pengalaman pengguna praktek
ners buat, buku ini untuk Anda.
Buku ini dirancang untuk dibaca dengan mudah hanya dalam beberapa jam. Jika kamu
pendatang baru di dunia pengalaman pengguna—mungkin Anda seorang
eksekutif yang bertanggung jawab untuk mempekerjakan tim pengalaman pengguna, atau mungkin
Anda seorang penulis atau desainer yang baru saja menemukan jalan Anda ke bidang ini—ini
buku akan memberi Anda fondasi yang Anda butuhkan. Jika Anda sudah menjadi keluarga
iar dengan metode dan keprihatinan bidang pengalaman pengguna,

xvi PENGANTAR
buku ini akan membantu Anda mengomunikasikannya dengan lebih efektif kepada
orang yang bekerja dengan Anda.
Kisah Dibalik Buku

Karena saya sering ditanya, beginilah cerita The Ele
ments dari Pengalaman Pengguna datang untuk menjadi.
Pada akhir 1999, saya menjadi arsitek informasi pertama yang dipekerjakan
konsultan desain Web yang sudah lama berdiri. Dalam banyak hal, saya adalah
bertanggung jawab untuk menentukan posisi saya dan mendidik orang keduanya
tentang apa yang saya lakukan, dan bagaimana itu cocok dengan apa yang mereka lakukan. Mulanya,
mereka mungkin berhati-hati dan sedikit waspada, tetapi segera mereka sadar
menyadari bahwa saya ada di sana untuk membuat pekerjaan mereka lebih mudah, bukan lebih sulit, dan
bahwa kehadiran saya tidak berarti otoritas mereka berkurang.
Secara bersamaan, saya sedang menyusun koleksi pribadi online
materi yang berhubungan dengan pekerjaan saya. (Ini pada akhirnya akan menemukan jalannya
ke Web sebagai halaman sumber daya arsitektur informasi saya di
www.jjg.net/ia/.) Selama saya melakukan penelitian ini, saya terus-menerus
frustrasi oleh penggunaan yang tampaknya sewenang-wenang dan acak dari yang berbeda
istilah untuk konsep dasar di lapangan. Apa yang disebut satu sumber? desain
informasi tampaknya sama dengan apa yang disebut orang lain
arsitektur informasi. Sepertiga menggulung semuanya bersama-sama di bawah
desain antarmuka.
Selama akhir 1999 dan Januari 2000, saya berjuang untuk tiba
pada seperangkat definisi yang konsisten untuk masalah ini dan untuk menemukan
cara untuk mengekspresikan hubungan di antara mereka. Tapi aku sibuk dengan
pekerjaan pembayaran yang sebenarnya juga, dan model yang saya coba rumuskan tidak benar-
benar berhasil; jadi pada akhir Januari saya punya
menyerah pada seluruh ide.

UNSUR PENGALAMAN PENGGUNA xvii
Maret itu saya pergi ke Austin, Texas, untuk acara tahunan South by
Festival Interaktif Barat Daya. Itu menarik dan berpikir
minggu yang memprovokasi di mana saya tidak banyak tidur—kon jadwal
kegiatan siang dan malam hari mulai menyerupai
maraton setelah beberapa hari.
Pada akhir minggu itu, saat saya berjalan melewati terminal bandara di
Austin bersiap untuk naik pesawat kembali ke San Fran cisco, tiba-tiba
muncul di kepalaku: matriks tiga dimensi
yang menangkap semua ide saya. Saya menunggu dengan sabar sampai kami naik
pesawat. Segera setelah saya mencapai tempat duduk saya, saya mengeluarkan buku catatan dan
membuat sketsa semuanya.
Sekembalinya saya ke San Francisco, saya segera dibaringkan
dengan kepala dingin yang melemahkan. Saya menghabiskan sekitar satu minggu meluncur masuk dan
dari delirium demam. Ketika saya merasa sangat jernih, saya bekerja mengubah sketsa
buku catatan saya menjadi diagram jadi yang sesuai
dengan rapi pada selembar kertas berukuran letter. Saya menyebutnya “Elemen dari
Pengalaman pengguna." Kemudian saya akan mendengar tentang bagaimana, bagi banyak orang,
judul itu membangkitkan ingatan tentang tabel periodik dan Strunk and White.
Sayangnya, tidak satu pun dari asosiasi ini ada dalam pikiran saya ketika saya memilih
judul itu—saya memilih elemen dari tesaurus untuk menggantikan komponen yang
lebih canggung dan terdengar teknis .
Pada tanggal 30 Maret, saya memposting produk akhir di Web. (Itu masih ada;
Anda dapat menemukan diagram aslinya di www.jjg.net/ia/elements.

pdf.) Diagram mulai mendapat perhatian, pertama dari Peter Merholz dan
Jeffrey Veen, yang kemudian menjadi mitra saya di
Jalur Adaptif. Segera setelah itu, saya berbicara dengan lebih banyak orang tentang hal itu di
KTT Arsitektur Informasi pertama. Akhirnya saya mulai mendengar
ing dari orang-orang di seluruh dunia tentang bagaimana mereka telah menggunakan
xviii PENGANTAR
diagram untuk mendidik rekan kerja mereka dan untuk memberikan organisasi mereka
kosakata umum untuk membahas masalah ini.
Pada tahun setelah pertama kali dirilis, “Elemen Pengalaman Pengguna
rience” telah diunduh dari situs saya lebih dari 20.000 kali. Saya
mulai mendengar tentang bagaimana itu digunakan di organisasi besar
dan kelompok pengembangan Web kecil untuk membantu mereka bekerja dan berkomunikasi
nikasi lebih efektif. Pada saat ini, saya mulai merumuskan
ide untuk sebuah buku yang akan menjawab kebutuhan ini lebih baik daripada satu buku
selembar kertas bisa.
Maret lainnya bergulir, dan sekali lagi saya menemukan diri saya di Austin
untuk Selatan oleh Barat Daya. Di sana saya bertemu Michael Nolan dari New Riders
Menerbitkan dan memberitahunya ide saya. Dia sangat antusias tentang hal itu, dan
untungnya, bosnya ternyata juga begitu.
Jadi, sebanyak keberuntungan dan juga niat, buku ini menemukan jalannya ke
tanganmu. Saya harap apa yang Anda lakukan dengan ide-ide yang disajikan di sini sama
mencerahkan dan bermanfaat bagi Anda seperti menyatukannya
dalam buku ini telah untuk saya.
Jesse James Garrett
Juli 2002

bab 1
Pengalaman Pengguna
dan Mengapa Itu
Hal-hal
UNSUR PENGALAMAN PENGGUNA 3
Kami memiliki hubungan bermata dua dengan produk dan layanan
keburukan yang kita gunakan. Mereka memberdayakan kita dan membuat kita frustrasi; mereka menyederhanakan dan
mempersulit hidup kita; mereka memisahkan kita dan mendekatkan kita.
Tetapi meskipun kami berinteraksi dengan produk dan layanan yang tak terhitung jumlahnya setiap
hari, kita dengan mudah lupa bahwa itu dibuat oleh orang-orang, dan itu
seseorang, di suatu tempat harus mendapatkan pujian ketika mereka bekerja dengan baik untuk
kita—atau disalahkan saat mereka tidak melakukannya.
Kesengsaraan Sehari-hari
Setiap orang, sesekali, memiliki salah satu dari hari-hari itu.
Anda tahu jenis hari yang saya bicarakan: Anda bangun untuk matahari
cahaya mengalir di jendela Anda dan bertanya-tanya mengapa jam alarm Anda
belum padam. Anda melihat ke atas untuk melihat bahwa jam Anda berpikir itu
3:43 pagi Anda tersandung dari tempat tidur untuk menemukan jam lain, yang menunjukkan
Anda bahwa Anda masih bisa membuatnya bekerja tepat waktu — jika Anda pergi 10
menit.
Machine Translated by
4 BAB 1 PENGALAMAN PENGGUNA DAN MENGAPA PENTING
Anda menyalakan pembuat kopi dan bergegas untuk berpakaian, tetapi ketika
Anda pergi untuk mengambil dosis kafein yang menopang hidup Anda, tidak ada
kopi di dalam panci. Tidak ada waktu untuk mencari tahu mengapa—Anda harus mendapatkan
bekerja!
Anda mendapatkan sekitar satu blok dari rumah Anda ketika Anda menyadari bahwa
mobil membutuhkan bensin. Di SPBU, Anda mencoba menggunakan satu pompa yang
mengambil kartu kredit, tapi kali ini tidak akan menerima Anda. Jadi kamu punya
untuk masuk ke dalam dan membayar kasir, tetapi pertama-tama Anda harus mengantri
sementara kasir sangat lambat membantu semua orang di depan Anda.
Anda harus mengambil jalan memutar karena kecelakaan lalu lintas, jadi mengemudilah
membutuhkan waktu lebih lama dari yang Anda harapkan. Ini resmi: Terlepas dari semua upaya Anda,
Anda sekarang terlambat untuk bekerja. Akhirnya, Anda sampai di meja Anda. kamu adalah
gelisah, tergesa-gesa, lelah, dan mudah tersinggung—dan hari Anda belum genap
benar-benar dimulai belum. Dan Anda masih belum minum kopi.
Memperkenalkan Pengalaman Pengguna
Sepertinya serangkaian nasib buruk—hanya salah satu dari hari-hari itu. Tapi mari kita
putar ulang rangkaian peristiwa itu, lihat lebih dekat, dan lihat apakah, entah bagaimana, semuanya
nasib buruk itu bisa dihindari.
Kecelakaan: Kecelakaan di jalan terjadi karena
Sopir mengalihkan pandangannya dari jalan sejenak untuk menyalakan radio turun. Dia
harus melihat ke bawah karena tidak mungkin untuk mengidentifikasi
yang merupakan kontrol volume dengan sentuhan saja.
Register: Jalur di register di pom bensin pindah jadi
perlahan karena mesin kasir itu rumit dan membingungkan, dan
kecuali petugas memberikan perhatian ekstra saat membunyikan sesuatu

up, dia akan membuat kesalahan dan harus memulai dari awal lagi. jika
register lebih sederhana dan tata letak serta warna tombol
berbeda, garis itu tidak akan pernah terbentuk.
Pompa: Anda tidak perlu berdiri di garis itu sama sekali jika
pompa telah menerima kartu Anda. Itu akan terjadi jika Anda memiliki
membalikkan kartu ke arah lain untuk menggeseknya, tetapi tidak ada yang aktif
pompa menunjukkan ke arah mana kartu harus diputar, dan Anda
terburu-buru sehingga Anda tidak berpikir untuk mencoba setiap orientasi.
Pembuat kopi: Pembuat kopi tidak membuat kopi karena
Anda tidak menekan tombol power sepenuhnya. Mesin
tidak melakukan apa pun untuk memberi tahu Anda bahwa itu telah diaktifkan: tidak
ringan, tidak ada suara, tidak ada hambatan yang bisa Anda rasakan saat tombol dibuat
kontak. Anda pikir Anda telah menyalakannya, tetapi Anda salah.
Masalahnya bisa dihindari sama sekali jika Anda telah mengatur
pembuat kopi untuk mulai menyeduh secara otomatis di pagi hari
ing, tetapi Anda tidak pernah belajar cara menggunakan fungsi itu—jika Anda mengetahuinya
ada sama sekali. Layar di bagian depan masih berkedip 12:00.
Jam: Dan sekarang kita sampai pada faktor yang memulai semuanya rantai
peristiwa: jam alarm. Alarm tidak berbunyi karena
waktunya salah. Waktunya salah karena kucingmu melangkah
pada jam di tengah malam dan mengatur ulang untuk Anda. (Jika ini
kedengarannya tidak masuk akal bagi Anda, jangan tertawa—itu telah terjadi pada saya.
Saya harus pergi sejauh yang mengejutkan untuk menemukan jam yang tidak tidak
suka campur tangan kucing.) Konfigurasi tombol yang sedikit berbeda
akan mencegah kucing mengatur ulang jam, dan akibatnya
akhirnya Anda akan bangun dari tempat tidur dengan banyak waktu — tidak
perlu terburu-buru sama sekali.

Singkatnya, setiap kasus "nasib buruk" sebelumnya bisa terjadi
dihindari jika seseorang membuat pilihan yang berbeda dalam mendesain produk atau
layanan. Semua contoh ini menunjukkan kurangnya perhatian terhadap pengalaman
pengguna: pengalaman yang diciptakan produk untuk orang yang menggunakannya di
dunia nyata. Ketika suatu produk sedang
dikembangkan, orang menaruh banyak perhatian pada apa yang dilakukannya. Pengguna
pengalaman adalah sisi lain yang sering diabaikan—

cara kerjanya—yang sering kali dapat membuat perbedaan antara sukses
produk cessful dan kegagalan.
Pengalaman pengguna bukan tentang cara kerja bagian dalam suatu produk atau layanan
keburukan. Pengalaman pengguna adalah tentang cara kerjanya di luar, di mana seseorang
bersentuhan dengannya. Ketika seseorang bertanya padamu apa seperti menggunakan
produk atau layanan, mereka bertanya tentang pengguna
pengalaman. Apakah sulit untuk melakukan hal-hal sederhana? Apakah mudah untuk mengetahuinya?
Bagaimana rasanya berinteraksi dengan produk?
Interaksi itu sering kali melibatkan menekan banyak tombol, seperti di
kasus produk teknologi seperti jam alarm, pembuat kopi,
atau mesin kasir. Terkadang, ini hanya masalah fisik yang sederhana
mekanisme kal, seperti tutup gas pada mobil Anda. Namun, setiap
produk yang digunakan oleh seseorang menciptakan pengalaman pengguna: buku, botol
kecap, kursi malas, sweater kardigan.
Untuk segala jenis produk atau layanan, hal-hal kecillah yang diperhitungkan.
Memiliki klik tombol saat Anda menekannya sepertinya tidak banyak,
tetapi ketika klik itu membuat perbedaan antara get
ting kopi dan tidak mendapatkan kopi, itu sangat penting. Bahkan jika Anda tidak
pernah menyadari bahwa desain tombol itu menyebabkan Anda masalah,
bagaimana perasaan Anda tentang pembuat kopi seperti Anda?
dapat menggunakan berhasil hanya sebagian dari waktu? Bagaimana perasaanmu?

tentang produsen? Apakah Anda akan membeli produk lain dari itu?
perusahaan di masa depan? Mungkin tidak. Jadi, untuk kebutuhan tombol yang mengklik, pelanggan hilang.
Dari Desain Produk hingga Desain Pengalaman Pengguna
Ketika kebanyakan orang berpikir tentang desain produk (jika mereka berpikir tentang
desain produk sama sekali), mereka sering memikirkannya dalam hal estetika
daya tarik: produk yang dirancang dengan baik adalah produk yang terlihat bagus di mata
dan terasa enak saat disentuh. (Indera penciuman dan rasa tidak
ikut bermain untuk sebagian besar produk. Suara sering diabaikan tapi
dapat menjadi bagian penting dari daya tarik estetika suatu produk.)
Entah itu lekuk bodi mobil sport atau tekstur a
pegangan bor listrik, dimensi estetika desain produk adalah a
pasti penarik perhatian.
Cara umum lain orang berpikir tentang desain produk adalah dalam
istilah fungsional: Produk yang dirancang dengan baik adalah produk yang melakukan apa yang
berjanji untuk dilakukan. Dan produk yang dirancang dengan buruk adalah produk yang entah bagaimana
tidak: gunting yang tidak memotong meskipun bilahnya tajam,
pena yang tidak menulis meskipun penuh dengan tinta, printer yang
terus-menerus macet.
Semua ini tentu bisa menjadi kegagalan desain. Produk-produk ini
mungkin terlihat bagus dan berfungsi dengan baik secara fungsional, tetapi merancang produk
ucts dengan pengalaman pengguna sebagai hasil eksplisit berarti mencari
di luar fungsi atau estetika.
Beberapa orang yang bertanggung jawab untuk menciptakan produk mungkin tidak berpikir
hal desain sama sekali. Bagi mereka, proses menciptakan produk adalah
tentang pengembangan: terus membangun dan menyempurnakan fitur

dan fungsi produk sampai mereka menambahkan sesuatu yang layak di

pasar.
Dalam pandangan ini, desain produk ditentukan oleh fungsinya—

atau, seperti yang kadang-kadang dikatakan desainer, "bentuk mengikuti fungsi." Ini
pendekatan masuk akal untuk cara kerja bagian dalam suatu produk,
bagian yang disembunyikan dari pengguna. Tapi ketika datang ke bagian dari
produk yang menghadap pengguna—tombol, tampilan, label, dan seterusnya—bentuk
yang “benar” tidak ditentukan oleh fungsionalitas sama sekali.
Sebaliknya, itu ditentukan oleh psikologi dan perilaku pengguna diri.
Desain pengalaman pengguna sering berhubungan dengan pertanyaan konteks.
Desain estetis memastikan tombol pada pembuat kopi adalah

bentuk dan tekstur yang menarik. Desain fungsional memastikannya trigonometri
melakukan tindakan yang sesuai pada perangkat. Desain pengalaman pengguna
memastikan aspek estetika dan fungsional tombol berfungsi

dalam konteks sisa produk, mengajukan pertanyaan seperti, "Apakah"
tombolnya terlalu kecil untuk fungsi penting seperti itu?” pengalaman pengguna
desain rience juga memastikan tombol berfungsi dalam konteks

apa yang ingin dicapai pengguna, mengajukan pertanyaan seperti, “Apakah
tombol di tempat yang tepat relatif terhadap yang lain mengontrol pengguna akan
digunakan pada saat yang sama?”
Merancang (untuk) Pengalaman: Penggunaan Penting
Apa perbedaan antara mendesain produk dan mendesain?

pengalaman pengguna? Lagi pula, setiap produk yang ditujukan untuk manusia memiliki
pengguna, dan setiap kali produk digunakan, itu memberikan pengalaman.

Pertimbangkan produk sederhana seperti kursi atau meja. Untuk menggunakan
kursi Anda duduk di atasnya; untuk menggunakan meja Anda menempatkan benda-benda lain di atasnya. Di
kedua kasus, produk dapat gagal memberikan pengalaman yang memuaskan: jika
kursi tidak akan menopang berat seseorang, misalnya, atau
meja tidak stabil.
Tetapi produsen kursi dan meja cenderung tidak mempekerjakan pengguna desainer
berpengalaman. Dalam kasus sederhana ini, persyaratan untuk memberikan
pengalaman pengguna yang sukses dibangun ke dalam definisi
dari produk itu sendiri: Dalam beberapa hal, kursi yang tidak dapat Anda duduki bukanlah sebuah
kursi sama sekali.
Namun, dengan produk yang lebih kompleks, persyaratan untuk memberikan
pengalaman pengguna yang sukses tidak tergantung pada definisi dari
produk. Telepon ditentukan oleh kemampuannya untuk menempatkan dan/atau menerima
panggilan; tetapi ada variasi yang praktis tak terbatas di telepon yang
dapat memenuhi definisi dasar ini—dengan variasi yang luas tingkat
pengalaman pengguna yang sukses.
Dan semakin kompleks suatu produk, semakin sulit untuk
mengidentifikasi dengan tepat bagaimana memberikan pengalaman yang sukses kepada pengguna.
Setiap fitur, fungsi, atau langkah tambahan dalam proses penggunaan a produk
menciptakan peluang lain bagi pengalaman untuk gagal.
Ponsel modern memiliki lebih banyak fungsi daripada a
telepon meja, katakanlah, tahun 1950-an. Akibatnya, proses penciptaan
produk yang sukses harus sangat berbeda. Di situlah produk
desain harus didukung oleh desain pengalaman pengguna.
Pengalaman Pengguna dan Web
Pengalaman pengguna sangat penting untuk semua jenis produk dan layanan. Ini buku ini
terutama tentang pengalaman pengguna dari satu jenis tertentu
produk: situs Web. (Saya menggunakan istilah situs di sini untuk merujuk keduanya
produk Web berorientasi konten dan aplikasi Web interaktif.)

Di Web, pengalaman pengguna menjadi lebih penting daripada
itu untuk jenis produk lainnya. Tapi pelajaran yang telah kita pelajari
menciptakan pengalaman pengguna di Web dapat diterapkan jauh melampauinya batasan.
Situs web adalah bagian teknologi yang rumit, dan semacamnya
lucu terjadi ketika orang kesulitan menggunakan potongan yang rumit
teknologi: Mereka menyalahkan diri mereka sendiri. Mereka merasa harus
telah melakukan sesuatu yang salah. Mereka merasa seperti tidak membayar
perhatian yang cukup. Mereka merasa bodoh. Tentu, itu tidak rasional. Lagipula,
itu bukan salah mereka situs tidak bekerja seperti yang mereka harapkan.
Tapi mereka tetap merasa bodoh. Dan jika Anda berniat mengusir orang
dari situs Anda (atau produk apa pun), sulit membayangkan yang lebih efektif
pendekatan daripada membuat mereka merasa bodoh ketika mereka menggunakannya.
Terlepas dari jenis situs, dalam hampir setiap kasus, situs Web
adalah produk swalayan. Tidak ada instruksi manual untuk dibaca
sebelumnya, tidak ada seminar pelatihan yang harus dihadiri, tidak ada layanan pelanggan
perwakilan untuk membantu memandu pengguna melalui situs. Ada saja
pengguna, menghadapi situs sendirian hanya dengan akal dan pengalaman pribadinya
rience untuk membimbingnya.
Dihadapkan dengan beragam
pilihan, pengguna adalah
diserahkan ke perangkatnya sendiri
untuk menentukan fea mana yang
tures dari sebuah situs akan bertemu
kebutuhannya.
Sudah cukup buruk bahwa dia terjebak dalam posisi harus
mencari tahu situsnya sendiri. Fakta bahwa sebagian besar situs bahkan tidak
mengakui kondisinya yang tidak berdaya hanya memperburuk keadaan.
Terlepas dari pentingnya strategis yang vital dari pengalaman pengguna untuk sukses, cess
dari situs Web, masalah sederhana memahami apa yang orang
keinginan dan kebutuhan telah menjadi prioritas rendah untuk sebagian besar sejarah media.
Jika pengalaman pengguna adalah bagian penting dari situs Web mana pun, mengapa demikian?
sering diabaikan dalam proses pembangunan? Banyak situs Web yang
dibangun dengan gagasan bahwa menjadi yang pertama ke pasar adalah kunci sukses.
Pada hari-hari awal Web, situs seperti Yahoo! membangun petunjuk awal
yang kemudian berjuang untuk diatasi oleh pesaing. Perusahaan yang sudah mapan
berlomba untuk membuat situs Web, bertekad untuk tidak dianggap jatuh
dibalik waktu. Tetapi dalam banyak kasus, perusahaan hanya mempertimbangkan telah
menyebarkan situs ini merupakan pencapaian yang luar biasa; apakah situs benar-benar
bekerja untuk orang-orang, paling banter, sebuah renungan.
Untuk mendapatkan pangsa pasar melawan penggerak pertama ini, pesaing sering
tambahkan lebih banyak konten dan fungsionalitas dengan harapan menarik mendapatkan
pelanggan baru (dan mungkin mencuri beberapa pelanggan dari
sebuah kompetisi). Perlombaan untuk menjejalkan lebih banyak fitur ke dalam produk adalah
hampir tidak unik untuk Web; mulai dari jam tangan hingga handphone,
featuritis endemik untuk banyak kategori produk.
Namun, memiliki lebih banyak fitur ternyata hanya sementara sumber
keunggulan kompetitif. Dengan kompleksitas tambahan yang
hadir dengan set fitur yang terus berkembang, situs menjadi meningkat
sangat berat, sulit digunakan, dan tidak menarik untuk pertama kali
pengatur waktu yang seharusnya mereka gunakan. Dan tetap saja, banyak organisasi
kurang memperhatikan apa yang disukai, dianggap berharga, atau benar-benar disukai pengguna
dapat digunakan.
Semakin banyak bisnis kini menyadari penyediaan itu
ing pengalaman pengguna yang berkualitas adalah kompetisi yang penting dan berkelanjutan
keuntungan tive—tidak hanya untuk situs Web, tetapi untuk semua jenis produk
dan layanan. Pengalaman penggunalah yang membentuk kesan pelanggan
sion dari penawaran perusahaan; itu adalah pengalaman pengguna yang membedakan
memakan perusahaan dari pesaingnya; dan itu adalah pengalaman pengguna yang
menentukan apakah pelanggan Anda akan kembali.
Pengalaman Pengguna yang Baik Adalah Bisnis Yang Baik
Mungkin Anda tidak menjual apa pun di situs Anda. Yang Anda berikan hanyalah
informasi tentang perusahaan Anda. Tampaknya Anda memiliki
memonopoli informasi itu—jika orang menginginkannya, mereka harus mendapatkannya
itu dari Anda. Anda tidak memiliki persaingan dengan cara yang sama seperti
toko buku online melakukannya. Namun demikian, Anda tidak dapat mengabaikan
pengalaman pengguna situs Anda.
Jika situs Anda sebagian besar terdiri dari apa yang disebut pro Web sebagai konten—yaitu ,
informasi—maka salah satu tujuan utama situs Anda adalah com
mengkomunikasikan informasi tersebut seefektif mungkin. Itu tidak cukup
hanya untuk meletakkannya di sana. Itu harus disajikan dengan cara yang membantu orang
menyerap dan memahaminya. Jika tidak, pengguna mungkin tidak
pernah mengetahui bahwa Anda menawarkan layanan atau produk yang mereka cari untuk. Dan
bahkan jika mereka berhasil menemukan informasi itu, mereka
cenderung menarik kesimpulan bahwa jika situs Anda sulit untuk bekerja
dengan, perusahaan Anda mungkin juga.
Bahkan jika situs Anda adalah aplikasi berbasis Web yang dapat digunakan orang untuk
menyelesaikan tugas-tugas tertentu (seperti membeli tiket pesawat atau mengelola rekening
bank), komunikasi yang efektif merupakan faktor kunci dalam

kesuksesan produk Anda. Fungsionalitas paling kuat di dunia
terputus-putus dan gagal jika pengguna tidak tahu bagaimana membuatnya bekerja.
Sederhananya, jika pengguna Anda memiliki pengalaman buruk, mereka tidak akan datang
kembali. Jika mereka memiliki pengalaman yang baik dengan situs Anda tetapi lebih baik pengalaman
dengan situs pesaing Anda, mereka akan kembali ke situs tersebut
pemohon, bukan Anda. Fitur dan fungsi selalu penting, tetapi pengguna
pengalaman memiliki efek yang jauh lebih besar pada loyalitas pelanggan. Semua milik mu
teknologi canggih dan pesan merek tidak akan membawa itu
pelanggan kembali untuk kedua kalinya. Pengalaman pengguna yang baik akan—dan
Anda tidak mendapatkan banyak kesempatan kedua untuk melakukannya dengan benar.
Loyalitas pelanggan bukan satu-satunya cara yang berfokus pada pengalaman pengguna
rience situs Anda dapat melunasi. Bisnis dengan pengawasan bot tom line
ingin tahu tentang laba atas investasi, atau ROI.
ROI biasanya diukur dalam bentuk uang: Untuk setiap dolar yang Anda
habiskan, berapa dolar nilai yang Anda dapatkan kembali? Itu adalah
ROI. Tetapi laba atas investasi tidak harus dinyatakan dalam
istilah moneter yang ketat. Yang Anda butuhkan hanyalah ukuran yang menunjukkan
bahwa uang Anda keluar diterjemahkan menjadi nilai bagi perusahaan Anda.
Salah satu ukuran umum pengembalian investasi adalah tingkat konversi.
Kapan pun Anda ingin mendorong pelanggan Anda untuk mengambil yang berikutnya langkah dalam
membangun hubungan dengan Anda—apakah itu melibatkan
sesuatu yang serumit menyesuaikan situs dengan preferensi mereka
atau sesederhana mendaftar untuk menerima buletin email—ada tingkat
konversi yang dapat Anda ukur. Dengan melacak apa yang
persentase pengguna yang Anda konversi ke tingkat berikutnya, Anda dapat mengukur bagaimana
efektif situs Anda memenuhi tujuan bisnis Anda.

Tingkat konversi adalah cara umum untuk mengukur efektivitas

pengalaman pengguna.
Tingkat konversi menjadi lebih penting dalam kasus com
situs rahmat. Jauh lebih banyak orang menelusuri situs perdagangan daripada membeli dari
dia. Pengalaman pengguna yang berkualitas adalah faktor kunci dalam mengonversi ini
browser biasa menjadi pembeli aktif. Bahkan sedikit peningkatan dalam
tingkat konversi dapat diterjemahkan menjadi lompatan dramatis dalam pendapatan. Ini bukan
jarang terjadi untuk perubahan tingkat konversi sekecil sepersepuluh dari
satu persen untuk menghasilkan peningkatan pendapatan sepuluh persen atau lebih.
Di situs mana pun di mana pengguna memiliki kesempatan untuk memberi Anda beberapa
uang, Anda memiliki tingkat konversi yang terukur, apakah Anda menjual ing
buku, makanan kucing, atau langganan konten situs itu sendiri.
Tingkat konversi dapat memberi Anda gambaran yang lebih baik tentang laba atas Anda
investasi pengalaman pengguna daripada angka penjualan sederhana. Penjualan bisa suf
fer jika Anda tidak berhasil menyebarkan berita tentang situs Anda.
Tingkat konversi melacak seberapa sukses Anda dalam mendapatkan mereka yang
mengunjungi untuk menghabiskan uang.
Bahkan jika situs Anda tidak cocok dengan metrik ROI seperti
tingkat konversi, itu tidak berarti efek dari pengalaman pengguna pada
bisnis Anda kurang signifikan. Apakah mereka digunakan oleh Anda
pelanggan, mitra Anda, atau karyawan Anda, situs Web dapat memiliki semuanya
jenis efek tidak langsung pada garis bawah.
Tidak seorang pun di luar perusahaan Anda mungkin pernah melihat situs yang Anda jalankan (sebagai
dalam kasus alat internal atau intranet), tetapi pengalaman pengguna
ence masih membuat perbedaan besar. Seringkali, itu bisa berarti perbedaan hubungan
antara proyek yang menciptakan nilai bagi organisasi dan
proyek yang menjadi mimpi buruk yang memakan sumber daya.
Setiap upaya pengalaman pengguna bertujuan untuk meningkatkan efisiensi. Dasar ini
Cally hadir dalam dua bentuk utama: membantu orang bekerja lebih cepat dan membantu
membuat mereka membuat lebih sedikit kesalahan. Meningkatkan efisiensi dari alat yang
Anda gunakan meningkatkan produktivitas bisnis secara keseluruhan.
Semakin sedikit waktu yang dibutuhkan untuk menyelesaikan tugas apa pun, semakin banyak Anda
bisa selesai dalam sehari. Sesuai dengan gagasan lama bahwa waktu adalah
uang, menghemat waktu karyawan Anda berarti langsung menghemat
uang bisnis Anda.

Efisiensi tidak hanya mempengaruhi garis bawah. Orang orang suka
pekerjaan mereka lebih banyak ketika alat mereka alami dan mudah digunakan, bukan frustasi
dan kompleks yang tidak perlu. Jika orang itu adalah kamu, jenis ini
alat membuat perbedaan antara pulang ke rumah puas di
akhir hari dan pulang ke rumah lelah dan membenci pekerjaan Anda.
(Atau setidaknya, jika Anda pulang dengan kelelahan, itu untuk yang benar alasan
—bukan karena Anda telah berjuang dengan alat Anda.)
Produk teknologi
itu tidak bekerja dengan cara
orang mengharapkan make
mereka merasa bodoh—
bahkan jika mereka akhirnya
mencapai apa yang mereka
berangkat untuk dilakukan.

Jika orang itu adalah karyawan Anda, sediakan alat semacam ini
meningkatkan tidak hanya produktivitas mereka, tetapi juga kepuasan kerja mereka, membuat karyawan cenderung tidak mencari pekerjaan baru. Ini, pada giliran
dibawa karyawan ke pekerjaannya.
Memperhatikan Pengguna Anda
Praktik menciptakan pengalaman pengguna yang menarik dan efisien adalah
disebut desain yang berpusat pada pengguna. Konsep desain yang berpusat pada pengguna
sangat sederhana: Perhitungkan pengguna setiap langkahnya sebagai
Anda mengembangkan produk Anda. Implikasi dari konsep sederhana ini,
Namun, sangat kompleks.
Segala sesuatu yang dialami pengguna harus merupakan hasil dari kesadaran
keputusan di pihak Anda. Secara realistis, Anda mungkin harus membuat com
janji di sana-sini karena waktu atau biaya yang terlibat
dalam menciptakan solusi yang lebih baik. Tetapi proses desain yang berpusat pada pengguna
memastikan bahwa kompromi tersebut tidak terjadi secara kebetulan. Oleh
memikirkan pengalaman pengguna, memecahnya menjadi bagian-bagiannya elemen
ponent, dan melihatnya dari beberapa perspektif, Anda
dapat memastikan bahwa Anda mengetahui semua konsekuensi dari keputusan Anda.
Alasan terbesar pengalaman pengguna harus penting bagi Anda adalah karena itu
penting bagi pengguna Anda. Jika Anda tidak memberi mereka hal positif
pengalaman, mereka tidak akan menggunakan produk Anda. Dan tanpa pengguna, semua yang Anda
miliki adalah server Web yang berdebu (atau gudang yang penuh dengan produk)
di suatu tempat, iseng menunggu untuk memenuhi permintaan yang tidak akan pernah datang. Untuk
pengguna yang datang, Anda harus berangkat untuk menyediakannya
dengan pengalaman yang kohesif, intuitif, dan bahkan mungkin
menyenangkan—pengalaman di mana segala sesuatu berjalan sebagaimana mestinya Sebaiknya.
Tidak peduli bagaimana sisa hari mereka telah berlalu.

bab 2
Temui
Elemen
Proses desain pengalaman pengguna adalah tentang memastikan bahwa tidak ada aspek
pengalaman pengguna dengan produk Anda terjadi tanpa
Anda sadar, niat eksplisit. Ini berarti mempertimbangkan
setiap kemungkinan dari setiap tindakan yang kemungkinan akan diambil dan dilakukan oleh pengguna
mempertahankan harapan pengguna di setiap langkahnya
proses itu. Kedengarannya seperti pekerjaan besar, dan dalam beberapa hal memang demikian. Tetapi
dengan memecah tugas menyusun pengalaman pengguna menjadi elemen
komponen, kita dapat lebih memahami tugas secara keseluruhan.
Lima Pesawat
Kebanyakan orang, pada satu waktu atau lainnya, telah membeli fisik produk
melalui Web. Pengalamannya hampir sama
setiap kali: Anda pergi ke situs, Anda menemukan item yang Anda inginkan (mungkin
dengan menggunakan mesin pencari atau mungkin dengan menelusuri katalog), Anda memberi
situs nomor kartu kredit Anda dan alamat Anda, dan situsnya mengkonfirmasi
bahwa produk akan dikirimkan kepada Anda.

20 BAB 2 MEMENUHI ELEMEN
Pengalaman yang rapi dan rapi itu sebenarnya hasil dari keseluruhan rangkaian
keputusan—sebagian kecil, sebagian besar—tentang bagaimana tampilan situs, bagaimana
berperilaku, dan apa yang memungkinkan Anda untuk melakukan. Keputusan ini dibangun di atas
satu sama lain, menginformasikan dan mempengaruhi semua aspek pengalaman pengguna
rience. Jika kita mengupas lapisan pengalaman itu, kita bisa mulai
untuk memahami bagaimana keputusan itu dibuat.
Pesawat Permukaan
Di permukaan Anda melihat serangkaian halaman Web, terdiri dari gambar
dan teks. Beberapa dari gambar-gambar ini adalah hal-hal yang dapat Anda klik, per
membentuk semacam fungsi seperti membawa Anda ke keranjang belanja.
Beberapa gambar ini hanya ilustrasi, seperti foto
produk untuk dijual atau logo situs itu sendiri.
Pesawat Kerangka
Di bawah permukaan itu adalah kerangka situs: penempatan tombol,
kontrol, foto, dan blok teks. Kerangka itu dirancang
untuk mengoptimalkan pengaturan elemen-elemen ini untuk efek maksimum dan
efisiensi—sehingga Anda mengingat logo dan dapat menemukannya
tombol keranjang belanja saat Anda membutuhkannya.
Pesawat Struktur
Kerangka adalah ekspresi konkret dari struktur yang lebih abstrak dari
situs. Kerangka mungkin menentukan penempatan antarmuka
elemen di halaman checkout kami; struktur akan menentukan bagaimana
pengguna sampai ke halaman itu dan ke mana mereka bisa pergi ketika mereka baik-baik saja
ada di sana. Kerangka mungkin menentukan pengaturan naviga
elemen nasional yang memungkinkan pengguna menelusuri kategori produk; struktur akan
menentukan apa kategori-kategori itu.

Pesawat Lingkup
Struktur mendefinisikan cara di mana berbagai fitur dan
fungsi situs cocok bersama. Apa saja fitur-fitur itu dan
fungsi yang merupakan ruang lingkup situs. Misalnya, beberapa
situs perdagangan menawarkan fitur yang memungkinkan pengguna untuk menyimpan sebelumnya
menggunakan alamat pengiriman agar dapat digunakan kembali. Apakah itu fitur—
atau fitur apa pun—disertakan di situs adalah masalah ruang lingkup.
Pesawat Strategi
Cakupan pada dasarnya ditentukan oleh strategi situs.
Strategi ini tidak hanya menggabungkan apa yang dilakukan oleh orang-orang yang menjalankannya
situs ingin keluar darinya tetapi apa yang ingin keluar dari pengguna situs
juga. Dalam kasus contoh toko kami, beberapa strategi tujuannya cukup
jelas: Pengguna ingin membeli produk, dan kami ingin menjual mereka.
Tujuan lain—seperti peran yang diiklankan
ing atau konten yang diproduksi oleh pengguna kami diputar dalam model bisnis kami,
misalnya—mungkin tidak begitu mudah untuk diartikulasikan.
Membangun dari Bawah ke Atas

Kelima bidang ini—strategi, ruang lingkup, struktur, kerangka, dan permukaan— memberikan
kerangka kerja konseptual untuk berbicara tentang pengalaman pengguna
masalah dan alat yang kita gunakan untuk menyelesaikannya.
Di setiap pesawat, masalah yang harus kita tangani menjadi sedikit berkurang abstrak
dan sedikit lebih konkrit. Di pesawat terendah, kita tidak
berkaitan dengan bentuk akhir dari situs, produk, atau layanan di
semua—kami hanya peduli tentang bagaimana situs akan cocok dengan strategi kami (sementara
memenuhi kebutuhan pengguna kami). Di pesawat tertinggi, kita hanya
berkaitan dengan detail paling konkret dari penampilan
produk. Pesawat demi pesawat, keputusan yang harus kita buat menjadi sedikit
lebih spesifik dan melibatkan tingkat detail yang lebih baik.

Konkret
Abstrak
Setiap pesawat tergantung pada pesawat di bawahnya. Jadi, permukaan
tergantung pada kerangka, yang tergantung pada struktur, yang tergantung pada
ruang lingkup, yang tergantung pada strategi. Ketika
pilihan yang kita buat tidak sesuai dengan yang di atas dan di bawah, proyek
tergelincir, tenggat waktu terlewati, dan biaya mulai meroket karena
tim pengembangan mencoba menyatukan komponen yang tidak
cocok secara alami. Lebih buruk lagi, ketika produk akhirnya diluncurkan,
pengguna sering membencinya, karena tidak memberikan pengalaman yang memuaskan.
Ketergantungan ini berarti bahwa keputusan pada bidang strategi akan memiliki
semacam "efek riak" sepanjang rantai. Sebaliknya,
pilihan yang tersedia bagi kita di setiap pesawat dibatasi oleh keputusan
yang kita buat tentang masalah di bidang di bawahnya.

berbagai pilihan tersedia di pesawat berikutnya
Pilihan yang Anda buat di
setiap pesawat mempengaruhi

pilihan yang tersedia untuk
Anda di pesawat berikutnya di

atasnya.
opsi yang Anda pilih
berbagai pilihan yang mungkin
Efek riak ini berarti
bahwa memilih opsi "di luar
batas" pada bidang atas akan
membutuhkan pemikiran ulang
keputusan lebih rendah
pesawat.
Itu tidak berarti, bagaimanapun, bahwa setiap keputusan tentang yang lebih rendah
pesawat harus dibuat sebelum pesawat di atasnya dapat diatasi.
Dependensi berjalan di kedua arah, dengan keputusan dibuat di atas
pesawat kadang-kadang memaksa evaluasi ulang (atau evaluasi yang dibuat untuk pertama
kali!) masalah di pesawat yang lebih rendah. Di setiap level, kami membuat
keputusan sesuai dengan apa yang dilakukan pesaing, industri terbaik
praktik, apa yang kami ketahui tentang pengguna kami, dan hal-hal umum biasa
nalar. Keputusan ini dapat memiliki efek riak di kedua arah.
Membutuhkan pekerjaan di
setiap pesawat untuk diselesaikan
sebelum bekerja pada
selanjutnya dapat mulai mengarah ke
hasil yang tidak memuaskan bagi Anda
dan pengguna Anda.
waktu
Pendekatan yang lebih baik adalah
memiliki pekerjaan pada masing-masing
pesawat selesai sebelum bekerja
selanjutnya bisa selesai.
waktu
Jika Anda mempertimbangkan keputusan Anda di bidang yang lebih rendah untuk ditetapkan dalam batu
sebelum Anda mengambil keputusan di bidang yang lebih tinggi, Anda hampir akan pasti
membuang jadwal proyek Anda—dan mungkin berhasil
cess dari produk akhir Anda—dalam bahaya.
Sebaliknya, Anda harus merencanakan proyek Anda sehingga bekerja di bidang apa pun
tidak dapat diselesaikan sebelum pekerjaan pada bidang yang lebih rendah selesai. impor
Pertimbangannya disini adalah untuk tidak membangun atap rumah terlebih dahulu
Anda tahu bentuk fondasinya.

Dualitas Dasar
Tentu saja, ada lebih dari lima elemen pengalaman pengguna, dan seperti bidang khusus lainnya,
yang satu ini telah mengembangkan kosa kata
semua miliknya sendiri. Bagi seseorang yang baru pertama kali terjun ke bidang ini,
pengalaman pengguna mungkin tampak seperti bisnis yang rumit. Semua ini
istilah yang tampaknya identik dilemparkan: desain interaksi, desain informasi, arsitektur
informasi. Apa yang mereka maksud?
Apa pun? Atau apakah itu hanya kata kunci industri yang tidak berarti?
Untuk lebih memperumit masalah, orang akan menggunakan istilah yang sama dalam
cara yang berbeda. Satu orang mungkin menggunakan “desain informasi” untuk merujuk
dengan apa yang orang lain ketahui sebagai "arsitektur informasi." Dan apa
perbedaan antara "desain antarmuka" dan "desain interaksi?"
Apakah ada satu?
Ketika Web dimulai, itu semua tentang informasi. Orang dapat membuat dokumen, dan
mereka dapat menautkannya ke dokumen lain.
Tim Berners-Lee, penemu Web, menciptakannya sebagai cara bagi para peneliti di
komunitas fisika energi tinggi, yang
tersebar di seluruh dunia, untuk berbagi dan merujuk pada temuan masing-masing. Dia tahu
Web memiliki potensi untuk menjadi lebih dari
itu, tetapi hanya sedikit orang lain yang benar-benar mengerti betapa hebatnya potensinya.
Orang-orang awalnya memanfaatkan Web sebagai media penerbitan baru,
tetapi seiring kemajuan teknologi dan fitur baru ditambahkan ke Web
browser dan server Web sama, Web mengambil fungsi baru
kemampuan. Setelah Web mulai populer di komunitas Internet yang lebih besar, ia
mengembangkan serangkaian fitur yang lebih kompleks dan kuat yang
akan memungkinkan situs Web tidak hanya untuk mendistribusikan informasi tetapi juga untuk
mengumpulkan dan memanipulasinya. Dengan ini, Web menjadi lebih

interaktif, menanggapi masukan pengguna dengan cara yang dibangun di atas dan
terkadang melampaui aplikasi desktop tradisional.
Dengan munculnya kepentingan komersial di Web, aplikasi ini fungsi
tion menemukan berbagai kegunaan, seperti elektronik perdagangan,
media sosial, dan jasa keuangan, antara lain. Sementara itu, Web terus
berkembang sebagai media penerbitan,
dengan situs surat kabar dan majalah yang tak terhitung jumlahnya menambah gelombang blog
Web-only dan "e-zine" yang diterbitkan. teknologi
ogy terus maju di kedua bidang karena semua jenis situs dibuat
transisi dari kumpulan informasi statis yang berubah
jarang ke situs dinamis berbasis database yang terus-menerus
berkembang.
Ketika komunitas pengalaman pengguna Web mulai terbentuk,
anggota berbicara dua bahasa yang berbeda. Satu kelompok melihat setiap masalah lem
sebagai masalah desain aplikasi, dan pemecahan masalah terapan pendekatan dari
desktop tradisional dan perangkat lunak mainframe
dunia. (Ini, pada gilirannya, berakar pada praktik umum yang diterapkan hingga
menciptakan semua jenis produk, dari mobil hingga sepatu lari.) The kelompok
lain melihat Web dalam hal distribusi informasi dan
pengambilan, dan menerapkan pendekatan pemecahan masalah dari tradisi dunia
penerbitan, media, dan ilmu informasi.
Ini menjadi batu sandungan yang cukup besar. Sangat sedikit kemajuan yang bisa terjadi
dibuat ketika komunitas bahkan tidak bisa menyetujui terminol dasar ogy.
Perairan semakin diperkeruh oleh fakta bahwa sebagian besar Web situs tidak
dapat dikategorikan dengan rapi sebagai aplikasi fungsional
informasi atau sumber daya informasi—sejumlah besar tampaknya menjadi semacam
hibrida, menggabungkan kualitas dari setiap dunia.

Untuk mengatasi dualitas dasar ini dalam sifat Web, mari kita berpisah
lima pesawat kami di tengah. Di sebelah kiri, kami akan menempatkan elemen itu
khusus untuk Web sebagai platform untuk fungsionalitas. pada
benar, kami akan menempatkan elemen khusus ke Web sebagai informasi sedang.
produk sebagai fuankgssioionnaaliltiatass produk sebagai informasi
Konkret
Abstrak
Di sisi fungsionalitas, kami terutama memperhatikan tugas—
langkah-langkah yang terlibat dalam suatu proses dan bagaimana orang berpikir tentang
pleting mereka. Di sini, kami menganggap produk sebagai alat atau seperangkat alat yang
digunakan pengguna untuk menyelesaikan satu atau lebih tugas.
Di sisi yang berlawanan, perhatian kami adalah informasi produk apa?
menawarkan dan apa artinya bagi pengguna kami. Menciptakan informasi yang kaya
pengalaman pengguna adalah tentang memungkinkan orang untuk menemukan, menyerap, dan membuat
pengertian dari informasi yang kami berikan.
Elemen Pengalaman Pengguna

Sekarang kita dapat memetakan seluruh rangkaian istilah yang membingungkan ke dalam
model. Dengan memecah setiap bidang menjadi elemen-elemen komponennya,
kita akan dapat melihat lebih dekat bagaimana semua bagian cocok bersama
dalam merancang seluruh pengalaman pengguna.
Pesawat Strategi
Kekhawatiran strategis yang sama ikut bermain untuk kedua fungsi
berorientasi pada produk dan sumber daya yang berorientasi pada informasi. kebutuhan pengguna
adalah tujuan situs yang berasal dari luar organisasi kami—
khusus dari orang-orang yang akan menggunakan situs kami. Kita harus di bawah
tahan apa yang diinginkan audiens kami dari kami dan bagaimana itu cocok dengan
tujuan lain yang mereka miliki.
Seimbang dengan kebutuhan pengguna adalah tujuan kami sendiri untuk situs ini.
Tujuan produk ini dapat menjadi tujuan bisnis (“Hasilkan $1 juta
dalam penjualan melalui Web tahun ini") atau jenis tujuan lainnya ("Informasikan
pemilih tentang calon pada pemilihan berikutnya”). Di Bab 3
kita akan membahas lebih detail tentang elemen-elemen ini.

Konkret
permukaan
kerangka
struktur
cakupan
strategi
Abstrak
Pesawat Lingkup
Di sisi fungsionalitas, strategi diterjemahkan ke dalam ruang lingkup
melalui pembuatan spesifikasi fungsional: detail
deskripsi "set fitur" produk. Pada informasi
sisi, ruang lingkup berbentuk persyaratan konten: deskripsi dari
berbagai elemen konten yang akan dibutuhkan. Bab 4 akan mencakup
elemen ruang lingkup.
Pesawat Struktur
Lingkup diberikan struktur di sisi fungsionalitas melalui
desain interaksi, di mana kita mendefinisikan bagaimana sistem berperilaku
dalam menanggapi pengguna. Untuk sumber informasi, strukturnya adalah arsitektur
informasi: pengaturan elemen konten
untuk memudahkan pemahaman manusia. Anda akan menemukan lebih banyak detail
ini di Bab 5.
Pesawat Kerangka
Pesawat kerangka dipecah menjadi tiga komponen. Pada
kedua belah pihak, kita harus membahas desain informasi: presentasi
informasi dengan cara yang memfasilitasi pemahaman. Untuk
produk berorientasi fungsionalitas, kerangka juga mencakup inter
desain wajah, atau mengatur elemen antarmuka untuk memungkinkan pengguna untuk
berinteraksi dengan fungsionalitas sistem. Antarmuka untuk
sumber informasi adalah desain navigasinya: set layar
elemen yang memungkinkan pengguna untuk menelusuri informasi
Arsitektur. Ada lebih banyak tentang bidang kerangka di Bab 6.
Pesawat Permukaan
Akhirnya, kita memiliki permukaan. Terlepas dari apakah kita berurusan
dengan produk berorientasi fungsionalitas atau sumber informasi,
perhatian kami di sini adalah sama: pengalaman indrawi yang diciptakan oleh
produk jadi. Ini lebih sulit daripada kedengarannya; kamu bisa mengetahuinya semua
tentang itu di Bab 7.

Menggunakan Elemen
Model ini, dibagi menjadi kotak dan bidang yang rapi, adalah cara yang nyaman untuk
memikirkan masalah pengalaman pengguna. Pada kenyataannya, tentu saja, garis-garis
antara daerah-daerah ini tidak begitu jelas ditarik. Seringkali, sulit untuk mengidentifikasi
apakah pengalaman pengguna tertentu
masalah paling baik diselesaikan melalui perhatian pada satu elemen daripada yang
lain. Bisakah perubahan pada visual berhasil, atau akankah
desain navigasi yang mendasari harus dikerjakan ulang? Beberapa masalah memerlukan
perhatian di beberapa area sekaligus, dan beberapa tampaknya mengangkangi perbatasan

yang diidentifikasi dalam model ini.
Beberapa produk atau layanan jatuh secara eksklusif di satu sisi model ini
atau yang lain. Dalam setiap bidang, elemen harus bekerja sama untuk mencapai tujuan
bidang itu. Memisahkan efek dari keputusan
Anda membuat sekitar satu elemen dari semua elemen lain di pesawat sangat sulit.
Misalnya, desain informasi, desain navigasi,
dan desain antarmuka bersama-sama menentukan kerangka suatu produk. Semua elemen
pada setiap bidang memiliki fungsi yang sama dalam menentukan pengalaman pengguna
yang lebih besar—dalam hal ini, mendefinisikan kerangka produk—bahkan jika mereka
menjalankan fungsi itu dengan cara yang berbeda.
Cara organisasi mendelegasikan tanggung jawab untuk masalah pengalaman pengguna
sering kali semakin memperumit masalah. Di beberapa organisasi, Anda akan bertemu
orang-orang dengan jabatan seperti arsitek informasi atau desainer antarmuka. Jangan
bingung dengan ini. Orang-orang ini menghasilkan
ally memiliki keahlian yang mencakup banyak elemen pengalaman pengguna, bukan hanya
spesialisasi yang ditunjukkan oleh gelar mereka. Itu tidak perlu memiliki anggota tim Anda
yang ahli di masing-masing bidang ini; sebagai gantinya, Anda hanya perlu memastikan
bahwa seseorang menghabiskan setidaknya sebagian waktu mereka memikirkan masing-
masing masalah ini.

Beberapa faktor tambahan digunakan untuk membentuk pengalaman pengguna akhir
ence bahwa Anda tidak akan menemukan tercakup secara rinci di sini. Yang pertama adalah
isi. Pepatah lama (yah, lama di tahun Web) adalah bahwa "konten adalah"
raja” di Web. Ini benar sekali—satu-satunya yang paling penting
Hal utama yang dapat ditawarkan sebagian besar situs Web kepada penggunanya adalah konten yang
para pengguna akan merasa berharga.
Pengguna tidak mengunjungi situs Web untuk mengalami kesenangan navigasi. Itu
konten yang tersedia untuk Anda (atau bahwa Anda memiliki sumber daya untuk diperoleh)
dan kelola) akan memainkan peran besar dalam membentuk situs Anda. Dalam kasus ini
toko online, kami mungkin memutuskan bahwa kami ingin pengguna menjadi
dapat melihat gambar sampul semua buku yang kami jual. Jika kita bisa mendapatkannya,
akankah kita memiliki cara untuk membuat katalognya, melacaknya, dan menyimpannya?
mereka mutakhir? Dan bagaimana jika kita tidak bisa mendapatkan foto buku cov
sama sekali? Pertanyaan konten ini penting bagi pengguna akhir
pengalaman situs.
Kedua, teknologi bisa sama pentingnya dengan konten dalam kre
menikmati pengalaman pengguna yang sukses. Dalam banyak kasus, sifat
pengalaman yang dapat Anda berikan kepada pengguna Anda sangat ditentukan oleh
teknologi. Pada hari-hari awal Web, alat untuk terhubung
Situs web ke database cukup primitif dan terbatas. sebagai
teknologi telah maju, namun database telah menjadi lebih
banyak digunakan untuk mengarahkan situs Web. Ini pada gilirannya telah memungkinkan lebih banyak dan
pendekatan pengalaman pengguna yang lebih canggih, seperti dinamis
sistem navigasi yang berubah sebagai respons terhadap cara pengguna bergerak
melalui situs. Teknologi selalu berubah, dan bidang
pengalaman pengguna selalu harus beradaptasi dengannya. Meskipun demikian, funda
elemen mental pengalaman pengguna tetap sama.

Meskipun saya mengembangkan model Elemen dalam pekerjaan saya
di situs Web, yang lain sejak itu menerapkannya ke berbagai produk
ukt dan layanan. Jika Anda bekerja di Web, semua yang ada di buku ini
berlaku untuk Anda. Jika Anda mengerjakan jenis produk teknologi lainnya,
Anda akan melihat kesejajaran yang kuat dengan pertimbangan yang sudah dikenal. Bahkan jika kamu
mengerjakan produk atau layanan yang tidak ada hubungannya dengan teknologi
ogy, Anda dapat memetakan konsep-konsep ini ke proses Anda sendiri.
Bagian selanjutnya dari buku ini membahas elemen-elemen ini, bidang demi bidang, dalam
lebih rinci. Kami akan melihat lebih dekat beberapa alat dan teknologi
niques yang biasa digunakan untuk menangani setiap elemen. Sepanjang jalan,
kita akan melihat bagaimana elemen-elemen ini berperan dalam produk yang tidak
Situs web sama sekali. Kita akan melihat apa yang dimiliki elemen di setiap bidang
umum, apa yang membuat masing-masing berbeda, dan bagaimana mereka mempengaruhi masing-masing
lainnya untuk membantu kami menciptakan pengalaman pengguna total.

bab 3
Strategi
Pesawat terbang
Tujuan Produk dan Kebutuhan Pengguna

Permukaan
Kerangka
Dasar dari pengalaman pengguna yang sukses adalah Struktur
strategi yang diartikulasikan dengan jelas. Mengetahui keduanya

Cakupan
kami ingin produk mencapai untuk organisasi kami
Strategi
ization dan apa yang kita ingin capai untuk kami
pengguna menginformasikan keputusan yang harus kita buat tentang
setiap aspek dari pengalaman pengguna. Tapi jawab
menjawab pertanyaan sederhana ini bisa lebih rumit daripada
terlihat.
36 BAB 3 STRATEGI PLANE
Mendefinisikan Strategi
Alasan paling umum untuk kegagalan situs Web bukanlah teknologi
nologi. Ini juga bukan pengalaman pengguna. Situs web paling sering gagal
karena — sebelum baris kode pertama ditulis, piksel pertama didorong, atau server
pertama diinstal — tidak ada yang peduli
menjawab dua pertanyaan yang sangat mendasar:
. Apa yang ingin kita dapatkan dari produk ini?
. Apa yang ingin didapatkan oleh pengguna kami?
cakupan
strategi
Dengan menjawab pertanyaan pertama, kami menggambarkan tujuan produk yang
berasal dari dalam organisasi. Pertanyaan kedua
alamat kebutuhan pengguna, tujuan yang dikenakan pada produk dari luar. Bersama-
sama, tujuan produk dan kebutuhan pengguna membentuk strata
egy plane, fondasi untuk setiap keputusan dalam proses kami saat kami merancang
pengalaman pengguna. Namun, luar biasa, banyak pengalaman pengguna
proyek tidak dimulai dengan pemahaman yang jelas dan eksplisit tentang strategi yang
mendasarinya.
Kata kuncinya di sini adalah eksplisit. Semakin jelas kita bisa mengartikulasikan
persis apa yang kita inginkan, dan persis apa yang diinginkan orang lain dari kita,
lebih tepatnya kita dapat menyesuaikan pilihan kita untuk memenuhi tujuan tersebut.
Tujuan Produk
Bagian pertama dari membuat strategi kami eksplisit adalah memeriksa strategi kami sendiri
tujuan untuk produk atau jasa. Terlalu sering, tujuan produk
hanya ada sebagai pemahaman yang tak terucapkan di antara mereka yang membangun
produk. Ketika pemahaman itu tetap tak terucapkan, berbeda
orang sering memiliki ide yang berbeda tentang apa yang didukung oleh produk tersebut
berpose untuk dicapai.
Tujuan bisnis
Orang biasanya menggunakan istilah seperti tujuan bisnis atau pendorong bisnis
untuk menggambarkan tujuan strategis internal. Saya akan menggunakan istilah
tujuan produk karena istilah-istilah lain ini terlalu sempit dan
terlalu luas: Terlalu sempit karena tidak semua tujuan internal adalah bisnis
tujuan (bagaimanapun juga, tidak setiap organisasi memiliki jenis tujuan yang sama
yang dilakukan bisnis), dan terlalu luas karena perhatian kami di sini benar-benar
adalah untuk mengidentifikasi dalam istilah yang paling spesifik mungkin apa yang kita harapkan
produk itu sendiri untuk dicapai, terlepas dari sisa bisnis kami
kegiatan.
Kebanyakan orang mulai menjelaskan tujuan untuk produk mereka di
istilah yang sangat umum. Dalam kasus situs Web, mereka pada dasarnya
melayani salah satu dari dua tujuan: untuk menghasilkan uang perusahaan atau untuk menabung
uang perusahaan. Terkadang keduanya. Tapi persis bagaimana ini
situs yang seharusnya melakukan itu tidak selalu jelas.

Di sisi lain, tujuan yang terlalu spesifik tidak cukup
menggambarkan masalah strategis yang dipermasalahkan. Misalnya, menyatakan bahwa
salah satu tujuan Anda adalah “untuk menyediakan pesan teks real-time kepada pengguna
alat komunikasi” tidak menjelaskan bagaimana alat tersebut membantu kemajuan tujuan
organisasi Anda, atau bagaimana hal itu membantu memenuhi kebutuhan
pengguna Anda.
Dalam mencoba untuk mencapai keseimbangan antara menjadi terlalu spesifik dan menjadi
terlalu umum, kami ingin menghindari melompat ke depan untuk mengidentifikasi solusi
ketika kita belum sepenuhnya memahami masalah. Untuk membuat sukses
pengalaman pengguna yang sukses, kami harus memastikan bahwa setiap keputusan
yang kita buat berakar pada pemahaman yang kuat tentang konsekuensinya.
Mendefinisikan dengan jelas kondisi untuk sukses—tanpa mendefinisikan
jalan menuju ke sana—memastikan bahwa kita tidak mendahului diri kita sendiri.
Identitas merek
Salah satu pertimbangan penting dalam merumuskan tujuan untuk setiap
produk adalah identitas merek. Ketika kebanyakan dari kita melihat kata branding,
kita memikirkan hal-hal seperti logo, palet warna, dan tipografi. Ketika
aspek visual merek ini penting (kami akan meninjaunya kembali di lebih
detail ketika kita sampai ke bidang permukaan di Bab 7), the
konsep merek jauh melampaui visual. Identitas merek—a
seperangkat asosiasi konseptual atau reaksi emosional—penting
karena tidak bisa dihindari. Di benak pengguna Anda, sebuah kesan tentang
organisasi Anda pasti diciptakan oleh interaksi mereka
dengan produk Anda.
Anda harus memilih apakah kesan itu terjadi secara tidak sengaja atau sebagai
hasil dari pilihan sadar yang telah Anda buat dalam merancang
produk. Sebagian besar organisasi memilih untuk menggunakan beberapa kontrol atas
persepsi merek mereka, itulah sebabnya mengkomunikasikan merek
identitas adalah tujuan produk yang sangat umum. Branding bukan hanya untuk
entitas komersial baik—setiap organisasi dengan situs Web,
dari yayasan nirlaba hingga lembaga pemerintah hingga individu,
menciptakan kesan melalui pengalaman pengguna. Dengan mengkodifikasikan
kualitas tertentu dari kesan itu sebagai tujuan eksplisit, Anda
meningkatkan peluang Anda bahwa itu akan menjadi kesan positif.
Metrik Sukses
Balapan memiliki garis finish. Bagian penting dari memahami
tujuannya adalah memahami bagaimana Anda akan tahu kapan Anda mencapai
mereka.
Ini dikenal sebagai metrik keberhasilan: indikator yang dapat kita lacak setelahnya
produk telah diluncurkan untuk melihat apakah itu memenuhi kami
tujuan sendiri dan kebutuhan pengguna kami. Mendefinisikan metrik keberhasilan yang baik tidak
hanya mempengaruhi keputusan yang dibuat selama proyek berlangsung;
mencapainya memberikan bukti nyata tentang nilai pengguna
mengalami upaya jika Anda menemukan diri Anda menghadapi audiens yang skeptis
saat meminta persetujuan anggaran untuk proyek pengalaman pengguna Anda berikutnya.
Terkadang metrik ini terkait dengan produk itu sendiri dan bagaimana
itu digunakan. Berapa banyak waktu yang dihabiskan rata-rata pengguna di situs Anda selama setiap
kunjungan? (Alat analisis dapat membantu Anda menentukan hal ini.) Jika
Anda ingin mendorong pengguna Anda untuk merasa nyaman dengan situs tersebut,
nongkrong, dan jelajahi apa yang Anda tawarkan, Anda pasti ingin melihatnya waktu per
kunjungan meningkat. Di sisi lain, jika Anda ingin memberikan
akses cepat, masuk-keluar ke informasi dan fungsionalitas, Anda mungkin ingin
mengurangi waktu per kunjungan.

Metrik keberhasilan adalah

10
indikator konkrit dari
seberapa efektif pengalaman 9

pengguna memenuhi tujuan
strategis. Dalam contoh ini, 8 target
mengukur
7
jumlah kunjungan
per pengguna terdaftar per 6

bulan menunjukkan bagaimana situs
yang berharga adalah untuk 5
audiens intinya.
4
2
peluncuran
1 situs yang didesain ulang
Jan Feb Mar Apr Mei Jun Jul Agu Sep Okt Nov Des
kunjungan per bulan (hanya pengguna terdaftar)
Untuk situs yang bergantung pada pendapatan iklan, tayangan—
berapa kali setiap hari iklan ditayangkan kepada pengguna—adalah peningkatan metrik
yang sangat penting. Tetapi Anda harus berhati-hati untuk menyeimbangkan tujuan dan
kebutuhan pengguna Anda. Menambahkan beberapa lapisan
halaman navigasi antara halaman beranda dan pengguna konten
inginkan pasti akan meningkatkan tayangan iklan Anda, tetapi apakah itu ditayangkan?
kebutuhan pengguna? Mungkin tidak. Dan dalam jangka panjang, itu akan menunjukkan: Seperti Anda
pengguna menjadi frustrasi dan memutuskan untuk tidak kembali, kesan Anda akan
turun dari tinggi awal itu dan mungkin akan berakhir lebih rendah dari mereka ketika
Anda mulai.
Tidak semua metrik keberhasilan harus diturunkan langsung dari situs Anda.
Anda juga dapat mengukur efek tidak langsung dari situs tersebut. Jika situs Anda
memberikan solusi untuk masalah umum yang dihadapi orang
produk Anda, jumlah panggilan telepon yang masuk ke pelanggan Anda
garis dukungan tomer harus turun. Intranet yang efektif dapat menghasilkan
vide akses siap ke alat dan sumber daya yang dapat mengurangi
waktu yang dibutuhkan tenaga penjualan Anda untuk menutup penjualan—yang, pada gilirannya,
diterjemahkan langsung ke dalam peningkatan pendapatan.
Agar metrik keberhasilan dapat mendorong keputusan pengalaman pengguna secara bermakna
sions, metrik tersebut harus jelas terkait dengan aspek perilaku pengguna
yang dapat dibentuk oleh pilihan desain kita. Tentu saja, ketika rede
tanda peluncuran dan pendapatan harian dari transaksi online melonjak 40
persen, mudah untuk melihat hubungan antara sebab dan akibat.
Tetapi untuk perubahan yang terjadi dalam jangka waktu yang lebih lama, itu bisa
sulit untuk mengidentifikasi apakah perubahan itu berasal dari pengguna
pengalaman atau dari faktor lain.
Misalnya, pengalaman pengguna situs Anda tidak dapat berbuat banyak dengan sendirinya
untuk membawa pengguna baru ke situs Anda—Anda harus mengandalkan berita dari mulut
atau upaya pemasaran Anda untuk itu. Tapi pengalaman pengguna
memiliki banyak pengaruh pada apakah pengunjung tersebut kembali.
Mengukur kunjungan kembali bisa menjadi cara yang bagus untuk menilai apakah Anda
memenuhi kebutuhan pengguna, tetapi berhati-hatilah: Terkadang pengguna tersebut tidak
kembali karena pesaing Anda meluncurkan iklan raksasa
kampanye atau karena perusahaan Anda baru saja mendapat pers yang buruk. Setiap
metrik yang dilihat secara terpisah dapat menyesatkan; pastikan untuk mengambil langkah kembali
dan lihat apa yang terjadi di luar situs Web untuk memastikan
Anda mendapatkan keseluruhan cerita.

Kebutuhan Pengguna
Sangat mudah untuk jatuh ke dalam perangkap pemikiran bahwa kita sedang merancang produk
atau layanan kita untuk satu pengguna ideal—seseorang yang persis seperti
kita. Tapi kami tidak mendesain untuk diri kami sendiri; kami mendesain untuk orang lain, dan jika
orang lain itu akan menyukai dan menggunakan apa yang kami
membuat, kita perlu memahami siapa mereka dan apa yang mereka butuhkan.
Dengan menghabiskan waktu untuk meneliti kebutuhan tersebut, kita dapat keluar dari
memiliki perspektif terbatas dan melihat situs dari sudut pandang
para pengguna.
Mengidentifikasi kebutuhan pengguna rumit karena pengguna bisa sangat beragam. Bahkan jika kita
membuat situs Web untuk digunakan di dalam organ kita
nization, kita mungkin masih harus mengatasi berbagai kebutuhan. Jika kami membuat aplikasi seluler
yang ditujukan untuk audiens konsumen,
kemungkinan meningkat secara eksponensial.
Untuk mencapai dasar kebutuhan itu, kita harus mendefinisikan siapa
pengguna kami. Setelah kami tahu siapa yang kami coba jangkau, kami dapat melakukan penelitian
dengan mereka — dengan kata lain, ajukan pertanyaan kepada mereka
dan mengamati perilaku mereka. Riset tersebut dapat membantu kami menentukan dan
memprioritaskan apa yang dibutuhkan orang saat mereka menggunakan produk kami.
Segmentasi Pengguna
Kami dapat memecah massa kebutuhan pengguna ini menjadi beberapa bagian yang dapat dikelola
melalui segmentasi pengguna. Kami membagi audiens kami menjadi
kelompok (atau segmen) yang lebih kecil yang terdiri dari pengguna dengan karakteristik kunci tertentu
yang sama. Ada banyak cara untuk memisahkan
ment kelompok pengguna karena ada jenis pengguna, tetapi berikut adalah beberapa
pendekatan yang paling umum.

Segmentasi pengguna membantu
kami memahami kebutuhan
pengguna dengan
lebih baik dengan membagi keseluruhannya penonton
menjadi lebih kecil
kelompok orang dengan
kebutuhan bersama.
Peneliti pasar biasanya membuat segmen pemirsa berdasarkan kriteria demografis : jenis kelamin,
usia, tingkat pendidikan, status perkawinan,
pendapatan, dan sebagainya. Profil demografis ini bisa sangat umum (laki-laki 18-49) atau sangat
spesifik (belum menikah, perempuan berpendidikan perguruan tinggi).
25–34 menghasilkan lebih dari $50.000 setahun).

Demografi bukan satu-satunya cara Anda dapat melihat pengguna Anda.
Profil psikografis menggambarkan sikap dan persepsi yang
yang dimiliki pengguna Anda tentang dunia atau tentang materi pelajaran
situs Anda secara khusus. Psikografis sering berkorelasi kuat dengan
demografi: Orang-orang dalam kelompok usia, lokasi, dan pendapatan yang sama
tingkat sering memiliki sikap yang sama. Namun dalam banyak kasus, demografi
Orang yang sama persis memiliki cara pandang dan interaksi yang sangat berbeda
bertindak dengan dunia. (Pikirkan semua orang yang Anda tuju
sekolah dengan.) Itu sebabnya mengungkap psikografis Anda
pengguna dapat memberi Anda wawasan yang tidak dapat Anda peroleh dari demografi.
Saat mengembangkan situs Web atau produk teknologi apa pun, ada
seperangkat sikap lain yang sangat penting untuk dipertimbangkan: sikap pengguna
ke arah Web dan teknologi itu sendiri. Berapa banyak waktu?
yang dihabiskan pengguna Anda menggunakan Web setiap minggu? Apakah teknologi merupakan bagian dari
kehidupan sehari-hari mereka? Apakah mereka suka bekerja dengan produk teknologi?
Apakah mereka selalu memiliki produk terbaru dan terbaik, atau apakah mereka?
hanya meng-upgrade ketika mereka harus? Technophobia dan pengguna listrik
mendekati situs Web dengan cara yang sangat berbeda, dan desain kami perlu
mengakomodasi mereka. Jawaban atas pertanyaan seperti ini dapat membantu kami
lakukan saja.
Selain memahami keakraban dan kenyamanan pengguna kami
tingkat dengan teknologi, kita perlu memahami apa dan berapa banyak
mereka tahu tentang pokok bahasan situs kami. Menjual peralatan masak ke
orang-orang yang baru belajar di sekitar dapur harus ditangani
sangat berbeda dari menjual ke koki profesional. Demikian pula, saham
aplikasi perdagangan yang digunakan oleh mereka yang tidak terbiasa dengan pasar saham
akan membutuhkan pendekatan yang berbeda dari satu untuk investor berpengalaman.
Perbedaan pengalaman atau keahlian ini dapat menjadi dasar untuk
segmentasi audiens kita.

Cara orang menggunakan informasi sering kali bergantung pada sosial atau
peran profesional. Kebutuhan informasi orang tua siswa
melamar ke perguruan tinggi berbeda dengan mahasiswa itu sendiri.
Mengidentifikasi peran yang berbeda dari pengguna produk Anda dapat membantu Anda
memisahkan mereka dan menganalisis kebutuhan mereka yang berbeda.
Setelah Anda melakukan beberapa penelitian pada grup pengguna Anda, Anda
mungkin perlu merevisi segmen yang Anda kerjakan. Untuk ujian
ple, jika Anda meneliti wanita berusia 25-34 tahun, berpendidikan perguruan tinggi,
Anda mungkin menemukan bahwa kebutuhan anak berusia 30–34 tahun berbeda dari
mereka dari kelompok usia 25-29. Jika perbedaannya cukup besar, Anda
mungkin ingin memperlakukan ini sebagai kelompok yang terpisah, bukan sebagai satu-satunya
25–34 grup tempat Anda memulai. Di sisi lain, jika 18-24
grup tampaknya sangat mirip dengan grup 25–34, mungkin Anda bisa
menggabungkan mereka. Membuat segmen pengguna hanyalah sarana untuk mencapai tujuan
untuk mengungkap kebutuhan pengguna. Anda benar-benar hanya membutuhkan banyak yang berbeda
segmen karena Anda memiliki rangkaian kebutuhan pengguna yang berbeda.
Ada alasan penting lainnya untuk membuat segmen pengguna: Tidak hanya
akankah kelompok pengguna yang berbeda memiliki kebutuhan yang berbeda, tetapi terkadang
kebutuhan tersebut akan bertentangan secara langsung. Ikuti ujian sebelumnya
ple dari aplikasi perdagangan saham. Para pemula mungkin adalah
paling baik dilayani oleh aplikasi yang memecah proses menjadi
urutan langkah sederhana. Namun, bagi para ahli, urutan seperti itu
akan menjadi penghalang. Para ahli membutuhkan antarmuka terpadu yang
menyediakan akses cepat ke berbagai fungsi.
Jelas, kami tidak dapat memenuhi kedua rangkaian kebutuhan pengguna dengan satu solusi tion.
Pilihan kami saat ini adalah fokus pada satu segmen pengguna untuk
pengecualian yang lain, atau untuk menyediakan dua cara terpisah bagi pengguna
untuk mendekati tugas yang sama. Kursus mana pun yang kami pilih, jalur ini
keputusan tegic akan memiliki konsekuensi untuk setiap pilihan tambahan
kami membuat tentang pengalaman pengguna.
Kegunaan dan Riset Pengguna

Untuk memahami apa yang dibutuhkan pengguna kami, pertama-tama kami harus memahami
siapa mereka. Bidang riset pengguna dikhususkan untuk mengumpulkan
data yang dibutuhkan untuk mengembangkan pemahaman itu.
Beberapa alat penelitian—seperti survei, wawancara, atau kelompok fokus—
paling cocok untuk mengumpulkan informasi tentang sikap umum
dan persepsi pengguna Anda. Alat penelitian lainnya—seperti pengguna
tes atau studi lapangan—lebih tepat untuk memahami
aspek tertentu dari perilaku pengguna dan interaksi dengan produk Anda.
Umumnya, semakin banyak waktu yang Anda habiskan dengan masing-masing pengguna, semakin
lebih rinci informasi yang akan Anda dapatkan dari studi penelitian.
Namun, waktu tambahan yang dihabiskan dengan setiap pengguna tentu saja
berarti Anda tidak akan dapat menyertakan banyak pengguna dalam penelitian (jika
hanya karena produk atau layanan harus diluncurkan pada akhirnya).
Metode riset pasar seperti survei dan kelompok fokus dapat sumber
informasi umum yang berharga tentang pengguna Anda. Ini
metode paling efektif ketika Anda dengan jelas mengartikulasikan untuk diri sendiri
informasi apa yang Anda coba dapatkan dari mereka. Apakah kamu mau
cari tahu apa yang dilakukan pengguna Anda saat mereka menggunakan fitur tertentu
produk Anda? Atau mungkin Anda sudah tahu itu, tetapi Anda perlu
untuk mengetahui mengapa mereka melakukannya. Semakin jelas Anda dapat menggambarkan
apa yang Anda inginkan, semakin sempit dan efektif Anda dapat merumuskan
pertanyaan yang Anda ajukan untuk memastikan bahwa Anda mendapatkan informasi yang benar.
Penyelidikan kontekstual mengacu pada seluruh rangkaian metode yang,
secara selektif, bentuk toolkit yang paling kuat dan komprehensif untuk
memahami pengguna Anda dalam konteks kehidupan sehari-hari mereka
(maka nama). Teknik-teknik ini berasal dari metode
digunakan oleh para antropolog untuk mempelajari budaya dan masyarakat. Diterapkan pada
skala yang lebih kecil, metode yang sama digunakan untuk memeriksa, misalnya,
bagaimana fungsi suku nomaden, juga dapat digunakan untuk memeriksa bagaimana
orang yang membeli suku cadang pesawat berfungsi. Satu-satunya downside adalah bahwa
penyelidikan kontekstual bisa sangat memakan waktu dan sangat mahal
sip. Jika Anda memiliki sumber daya, dan masalah Anda membutuhkan perhatian yang mendalam
pemahaman tentang pengguna Anda, studi penyelidikan kontekstual yang lengkap
dapat mengungkapkan seluk-beluk perilaku pengguna yang tidak dapat ditemukan
melalui metode lain.
Dalam kasus lain, metode kontekstual dapat menjadi ringan dan tidak relevan
termenung, meskipun cenderung tidak menghasilkan pemahaman yang mendalam
dari studi penelitian penuh. Salah satu contoh metode yang terkait erat dengan
penyelidikan kontekstual adalah analisis tugas. Gagasan di balik analisis tugas adalah bahwa
setiap interaksi pengguna dengan produk terjadi di
konteks beberapa tugas yang dilakukan pengguna. Terkadang tugas sangat
fokus (seperti membeli tiket film) dan terkadang
lebih luas (seperti belajar tentang peraturan perdagangan internasional)
tion). Analisis tugas adalah metode untuk memeriksa secara cermat
langkah-langkah yang dilalui pengguna dalam menyelesaikan tugas-tugas tersebut. Ujian ini
tion dapat dilakukan baik melalui wawancara di mana Anda mendapatkan pengguna
untuk menceritakan kisah tentang pengalaman mereka atau melalui pengamatan langsung
di lapangan, mempelajari pengguna di habitat aslinya.
Pengujian pengguna adalah bentuk pengguna yang paling umum digunakan
riset. Pengujian pengguna bukan tentang menguji pengguna Anda; sebagai gantinya, itu
tentang membuat pengguna Anda menguji apa yang telah Anda hasilkan. Kadang-kadang
tes pengguna bekerja dengan produk jadi, baik dalam persiapan untuk a
mendesain ulang atau untuk membasmi masalah kegunaan apa pun sebelum diluncurkan. Di lain
kasus, pengguna dapat menguji pekerjaan yang sedang berlangsung atau bahkan prototipe kasar
dari produk jadi.
Jika Anda pernah membaca tentang desain Web sama sekali, Anda mungkin
menemukan konsep kegunaan. Kata ini berarti berbeda
hal-hal untuk orang yang berbeda. Beberapa orang menggunakannya untuk merujuk pada latihan
pengujian desain dengan pengguna yang representatif. Bagi orang lain, itu berarti
mengadopsi metodologi pengembangan yang sangat spesifik.
Setiap pendekatan kegunaan berusaha untuk membuat produk lebih mudah digunakan.
Banyak definisi dan daftar aturan yang berbeda ditetapkan untuk mengkodifikasikan apa
merupakan desain situs Web yang dapat digunakan. Beberapa dari mereka bahkan setuju dengan
satu sama lain. Tetapi mereka semua memiliki prinsip yang sama pada intinya: Pengguna
membutuhkan produk yang dapat digunakan. Ini adalah kebutuhan pengguna yang paling universal.
Pengujian dengan situs Web yang beroperasi penuh bisa sangat luas atau sangat
sempit dalam ruang lingkup. Seperti halnya survei atau kelompok fokus, sebaiknya Anda
memiliki pemahaman yang jelas tentang apa yang ingin Anda selidiki sebelum Anda duduk
turun dengan pengguna. Namun, itu tidak berarti bahwa tes pengguna memiliki dibatasi
secara ketat untuk menilai seberapa berhasil pengguna menyelesaikan
tugas yang didefinisikan secara sempit. Pengujian pengguna juga dapat menyelidiki lebih luas,
masalah yang kurang konkrit. Misalnya, tes pengguna dapat digunakan untuk menemukan
apakah modifikasi pada desain memperkuat atau melemahkan
pesan merek perusahaan.
Pendekatan lain untuk pengujian pengguna adalah meminta pengguna bekerja dengan pro
totipe. Ini dapat mengambil berbagai bentuk, dari sketsa kasar pada kertas,
hingga maket "lo-fi" menggunakan desain antarmuka yang dilucuti,
untuk "klik-tayang" prototipe yang menciptakan ilusi selesai
produk. Proyek skala besar menggunakan berbagai jenis prototipe

pada tahap yang berbeda untuk mengumpulkan masukan pengguna sepanjang jalan
proses desain.
Terkadang tes pengguna tidak melibatkan situs sama sekali. Anda dapat merekrut
pengguna untuk melakukan berbagai latihan yang dapat memberi Anda wawasan
tentang bagaimana mereka mendekati materi pelajaran situs Anda. Untuk informasi
situs berorientasi mation, penyortiran kartu adalah salah satu metode yang digunakan untuk mengeksplorasi
bagaimana pengguna mengkategorikan atau mengelompokkan elemen informasi. Pengguna adalah
diberi setumpuk kartu indeks, yang masing-masing memiliki nama, deskripsi,
tion, atau gambar dari sepotong atau jenis konten di atasnya. Pengguna kemudian mengurutkan
kartu menjadi tumpukan sesuai dengan kelompok atau kategori yang dirasakan
paling alami. Menganalisis hasil sortir kartu yang dilakukan dengan
beberapa pengguna dapat membantu kami memahami pendapat mereka tentang
informasi yang disediakan situs kami.
Membuat Persona
Mengumpulkan semua jenis data tentang pengguna Anda bisa sangat berharga
bisa, tapi terkadang kamu bisa melupakan orang-orang di balik semua itu
statistik. Anda dapat membuat pengguna Anda lebih nyata dengan mengubahnya
menjadi persona (kadang-kadang disebut model pengguna atau profil pengguna). SEBUAH
persona adalah karakter fiksi yang dibangun untuk mewakili kebutuhan
dari berbagai macam pengguna nyata. Dengan memasang wajah dan nama di
potongan data yang terputus dari riset dan segmentasi pengguna Anda
berfungsi, persona dapat membantu memastikan bahwa Anda mengingat pengguna selama
proses desain.
Mari kita lihat sebuah contoh. Misalkan situs kami dirancang untuk menyediakan
informasi untuk orang-orang yang memulai bisnis mereka sendiri. Kita
tahu dari penelitian kami bahwa audiens kami sebagian besar jatuh di 30-45
rentang usia. Pengguna kami cenderung cukup nyaman dengan Web dan
teknologi secara umum. Beberapa dari mereka memiliki banyak pengalaman dalam
dunia bisnis; untuk orang lain, ini adalah paparan pertama mereka untuk semua
masalah yang terlibat dalam menjalankan bisnis.
Dalam hal ini, mungkin tepat untuk membuat dua persona. Sehat
panggil yang pertama Janet. Dia berusia 42 tahun, dia sudah menikah, dan dia memiliki dua
anak. Dia menghabiskan beberapa tahun terakhir sebagai wakil presiden
di sebuah kantor akuntan besar. Dia menjadi frustrasi dengan bekerja
untuk orang lain, dan sekarang dia ingin membangun perusahaannya sendiri.
Persona kedua adalah Frank. Dia berusia 37 tahun dan menikah dengan
satu anak. Pengerjaan kayu telah menjadi hobi akhir pekan Frank untuk
bertahun-tahun. Beberapa temannya terkesan dengan beberapa furnitur
dia buat, jadi dia berpikir dia bisa berbisnis untuknya
sendiri menjual karyanya. Dia tidak yakin apakah dia harus berhenti dari pekerjaannya sebagai
sopir bus sekolah untuk meluncurkan bisnis barunya.
Dari mana semua informasi ini berasal? Baik, untuk sebagian besar,
kami membuatnya. Kami ingin persona kami konsisten dengan apa yang kami
tahu tentang pengguna dari penelitian kami, tetapi detail spesifik dari
persona kita adalah penemuan fiksi, digunakan untuk menghembuskan kehidupan ke dalamnya
karakter yang akan mendukung pengguna kami yang sebenarnya dan langsung.
Janet dan Frank mewakili berbagai kebutuhan pengguna yang harus kami
perlu diingat saat kami membuat keputusan tentang pengalaman pengguna
dari situs kami. Untuk membantu kami mengingat mereka dan kebutuhan mereka, kami akan mengambil
beberapa stok foto untuk memberi sedikit identitas pada Janet dan Frank,
dan gabungkan foto-foto itu dengan informasi tentangnya yang kami miliki
mengumpulkan. Profil ini dapat dicetak dan diposting di sekitar
kantor sehingga ketika kami memiliki keputusan untuk dibuat, kami dapat bertanya kepada kami
diri (dan satu sama lain): “Apakah itu akan berhasil untuk Janet? Bagaimana
Frank bereaksi terhadapnya?” Persona membantu kami mengingat pengguna kami
setiap langkah.
Persona adalah fiksi
Janet karakter yang diambil dari
riset pengguna siapa

“Saya tidak punya waktu untuk memilah-milah banyak menjadi contoh kasus selama
informasi. Saya butuh jawaban cepat.”
pengembangan pengalaman
Janet frustrasi bekerja di lingkungan perusahaan dan ingin pengguna.

memulai praktik akuntansinya sendiri.
Usia: 42 Profil teknis: Cukup nyaman dengan teknologi; Dell laptop
Pekerjaan: Wakil presiden kantor akuntan (sekitar satu tahun) menjalankan Windows; 5 Mbit Koneksi
Keluarga: Menikah, dua anak internet; 15-20 jam/minggu online
Pendapatan rumah tangga: $180,000/tahun Penggunaan internet: 75% di rumah; berita dan informasi, belanja
Situs favorit:
WSJ.com
salon.com Travelocity.com
jujur
“Barang ini semua baru bagi saya. Saya ingin situs
itu akan menjelaskan segalanya.”
Frank tertarik untuk mempelajari bagaimana dia bisa mengubahnya
hobi membuat furniture menjadi bisnis.
Usia: 37 Profil teknis: Agak tidak nyaman dengan teknologi;

Pekerjaan: Sopir bus sekolah Apple iMac (sekitar dua tahun); koneksi Internet DSL;
Keluarga: Menikah, satu anak 8-10 jam/minggu online
Pendapatan rumah tangga: $60,000/tahun Penggunaan internet: 100% di rumah; hiburan, belanja
Situs favorit:
ESPN.com
moviefone.com eBay.com
Peran dan Proses Tim

Isu-isu strategis mempengaruhi semua orang yang terlibat dalam proses desain
pengalaman pengguna. Namun terlepas dari fakta ini (atau mungkin karena itu), tanggung
jawab untuk merumuskan tujuan-tujuan ini sering kali gagal. Perusahaan konsultan
terkadang akan mempekerjakan ahli strategi
pada proyek klien untuk mengelola masalah ini—tetapi karena keahlian yang langka seperti
itu cenderung mahal, dan karena ahli strategi tidak
bertanggung jawab langsung untuk membangun setiap bagian dari produk itu sendiri, item baris
ini sering kali menjadi salah satu yang pertama dipotong dari anggaran proyek.
Ahli strategi akan berbicara dengan banyak orang di seluruh organisasi untuk
mendapatkan perspektif sebanyak mungkin tentang pertanyaan tentang produk
tujuan dan kebutuhan pengguna. Stakeholder adalah pengambil keputusan senior yang
bertanggung jawab atas bagian-bagian organisasi yang akan
dipengaruhi oleh arah strategis akhir produk. Misalnya, dalam kasus situs Web yang
dirancang untuk menyediakan pelanggan
dengan akses ke informasi dukungan produk, pemangku kepentingan dapat mencakup
perwakilan dari komunikasi pemasaran dan pelanggan
layanan tomer serta manajer produk. Itu tergantung pada struktur pengambilan keputusan formal
(dan realitas politik informal) dari
organisasi.
Satu kelompok yang sering diabaikan dalam merumuskan strategi adalah peringkat
dan arsip—orang-orang yang bertanggung jawab untuk menjaga organisasi tetap berjalan dari hari
ke hari. Tapi orang-orang ini sering bertaruh
lebih memahami apa yang berhasil dan apa yang tidak daripada yang dilakukan manajer mereka. Mereka
dapat menginformasikan strategi dengan cara para pembuat keputusan senior tidak bisa—terutama dalam
hal kebutuhan pengguna. Tidak ada yang tahu apa yang pelanggan mengalami masalah lebih baik
daripada orang-orang yang
berbicara dengan pelanggan tersebut setiap hari. Saya sering terkejut dengan caranya
jarang umpan balik pelanggan menemukan jalannya ke desain produk dan tim
pengembangan yang membutuhkannya.
Tujuan produk dan kebutuhan pengguna sering didefinisikan secara formal
dokumen strategi atau dokumen visi. Dokumen ini bukan hanya sebagai daftar
tujuan-ini memberikan analisis hubungan antara
berbagai tujuan dan bagaimana tujuan tersebut sesuai dengan tujuan yang lebih besar konteks
organisasi. Tujuan dan analisisnya adalah
sering didukung oleh kutipan langsung dari pemangku kepentingan, peringkat dan file karyawan,
dan pengguna itu sendiri. Kutipan ini dengan jelas menggambarkan
isu-isu strategis yang terlibat dalam proyek. Kebutuhan pengguna terkadang didokumentasikan
dalam laporan penelitian pengguna yang terpisah (meskipun ada keuntungan tertentu untuk
memiliki semua informasi Anda di satu tempat).
Lebih besar belum tentu lebih baik dalam hal mendokumentasikan strategi.
Anda tidak harus memasukkan setiap titik data dan setiap sup porting kutipan
untuk menyampaikan ide Anda. Tetap singkat dan untuk titik. Ingat bahwa
banyak orang yang akan terkena doc
ument tidak akan punya waktu atau minat untuk mengarungi ratusan
halaman materi pendukung, dan itu jauh lebih penting bahwa mereka
memahami strategi daripada itu mereka terkesan dengan volumenya
dari verbiage Anda telah menghasilkan. Dokumen strategi yang efektif tidak hanya
berfungsi sebagai batu ujian untuk pengembangan pengalaman pengguna
tim; itu juga dapat digunakan untuk membangun dukungan untuk proyek di tempat lain bagian
dari organisasi.
Hal terburuk yang dapat Anda lakukan dengan dokumen strategi Anda adalah
membatasi akses tim Anda ke sana. Dokumen tidak dibuat untuk menjadi diajukan ke
suatu tempat atau dibagikan hanya dengan segelintir senior anggota staf—jika upaya
yang dilakukan akan membuahkan hasil,
dokumen harus digunakan secara aktif selama proyek. Semua

peserta—desainer, pengembang, manajer proyek—membutuhkan dokumen
strategi untuk membuat keputusan tentang pekerjaan mereka.
Dokumen strategi sering kali berisi materi sensitif, tetapi organisasi
tions bisa pergi terlalu jauh dan menjauhkan strategi dari yang bertanggung jawab tim,
yang melemahkan kemampuan mereka untuk menyadarinya.
Strategi harus menjadi awal dari desain pengalaman pengguna Anda
proses, tetapi itu tidak berarti strategi Anda harus kaku
sebelum proyek dapat bergerak maju. Meskipun mencoba melakukan gerakan
ing target dapat membuang-buang waktu dan sumber daya yang luar biasa (tidak untuk
menyebutkan sumber besar frustrasi internal), strategi dapat dan
harus berkembang dan disempurnakan. Ketika sistem direvisi dan disempurnakan Pada
dasarnya, kerja strategi dapat menjadi sumber inspirasi yang berkelanjutan sepanjang
proses desain pengalaman pengguna.


bab 4
Ruang Lingkup
Pesawat terbang
Spesifikasi Fungsional dan

Persyaratan Konten
Permukaan
Kerangka
Dengan pengertian yang jelas tentang apa yang kita inginkan dan apa yang kita Struktur
diinginkan pengguna, kita bisa mencari cara untuk memuaskan semua itu
Cakupan
tujuan strategis. Strategi menjadi ruang lingkup ketika
Strategi
Anda menerjemahkan kebutuhan pengguna dan tujuan produk menjadi
persyaratan khusus untuk konten dan fungsi apa?
kualitas yang akan ditawarkan produk kepada pengguna.

58 BAB 4 BIDANG LINGKUP
Mendefinisikan Ruang Lingkup
Kami melakukan beberapa hal karena ada nilai dalam prosesnya, seperti joging atau berlatih
tangga nada pada piano. Kami melakukan hal lain karena
ada nilai dalam produk, seperti membuat kue keju atau memperbaiki mobil. Mendefinisikan ruang
lingkup proyek Anda adalah keduanya: proses yang berharga
yang menghasilkan produk yang berharga.
Prosesnya berharga karena memaksa Anda untuk mengatasi potensi
konflik dan bintik-bintik kasar dalam produk sementara semuanya masih hipotetis. Kami dapat
mengidentifikasi apa yang dapat kami atasi sekarang dan
apa yang harus menunggu sampai nanti.
Produk ini berharga karena memberikan seluruh tim referensi
titik untuk semua pekerjaan yang harus dilakukan di seluruh proyek dan bahasa umum untuk
membicarakan pekerjaan itu. Menentukan kebutuhan Anda
ments mendorong ambiguitas keluar dari proses desain.
Saya pernah mengerjakan aplikasi Web yang sepertinya dalam keadaan
dari beta abadi: hampir, tetapi tidak cukup, siap diluncurkan ke pengguna sebenarnya.
Banyak hal yang salah dengan pendekatan kami—teknologi
ogy goyah, kami sepertinya tidak tahu apa-apa tentang pengguna kami, dan saya adalah satu-
satunya orang di seluruh perusahaan yang memiliki
pengalaman sama sekali dengan pengembangan untuk Web.
Tapi semua ini tidak menjelaskan mengapa kami tidak bisa mendapatkan produk tersebut
meluncurkan. Batu sandungan besar adalah keengganan untuk menentukan persyaratan. Lagi
pula, sangat merepotkan untuk menulis semuanya
turun ketika kita semua bekerja di kantor yang sama, dan selain itu, manajer produk perlu
memfokuskan energinya untuk menghasilkan fitur
baru.
Hasilnya adalah produk yang merupakan campuran yang selalu berubah dari fitur
dalam berbagai tahap kelengkapan. Setiap artikel baru beberapa
membaca tubuh atau setiap pemikiran baru yang muncul saat seseorang
sedang bermain dengan produk yang mengilhami fitur lain untuk dipertimbangkan
asi. Ada aliran pekerjaan yang konstan, tetapi tidak ada
jadwal, tidak ada tonggak, dan tidak ada akhir yang terlihat.
Karena tidak ada yang tahu ruang lingkup proyek, bagaimana mungkin ada orang tahu
kapan kita selesai?
Ada dua alasan utama untuk repot-repot mendefinisikan persyaratan.
Alasan #1: Agar Anda Tahu Apa yang Anda Bangun

Ini sepertinya sudah jelas, tapi itu mengejutkan tim
membangun aplikasi Web itu. Jika Anda dengan jelas mengartikulasikan apa
Anda mulai membangun, semua orang akan tahu apa proyeknya
tujuan dan kapan tercapai. Produk akhir berhenti menjadi
gambaran amorf di kepala manajer produk, dan
itu menjadi sesuatu yang konkret bahwa setiap orang di setiap level
organisasi, dari eksekutif puncak hingga insinyur tingkat pemula, dapat
bekerja dengan.
Dengan tidak adanya persyaratan yang jelas, proyek Anda mungkin akan
menjadi seperti permainan "Telepon" di halaman sekolah—setiap orang menyala
tim mendapat kesan produk dari mulut ke mulut, dan
deskripsi setiap orang berakhir sedikit berbeda. Atau lebih buruk lagi,
semua orang menganggap orang lain yang mengelola desain dan pengembangan opment
beberapa aspek penting dari produk, padahal sebenarnya tidak ada.

Memiliki serangkaian persyaratan yang ditentukan memungkinkan Anda untuk membagikannya
tanggung jawab untuk pekerjaan lebih efisien. Melihat seluruh ruang lingkup
dipetakan memungkinkan Anda untuk melihat hubungan antar individu
persyaratan yang mungkin tidak terlihat. Sebagai contoh,
dalam diskusi awal, dokumentasi dukungan dan produk
lembar spesifikasi mungkin tampak seperti fitur konten yang terpisah, tapi
mendefinisikannya sebagai persyaratan mungkin membuatnya jelas bahwa ada
banyak tumpang tindih dan kelompok yang sama harus bertanggung jawab
untuk keduanya.
Alasan #2: Agar Anda Tahu Apa yang Tidak Anda Bangun
Banyak fitur terdengar seperti ide yang bagus, tetapi belum tentu
menyelaraskan dengan tujuan strategis proyek. Selain itu, semua
berbagai kemungkinan fitur muncul setelah proyek berjalan dengan baik
berlangsung. Memiliki persyaratan yang diidentifikasi dengan jelas memberi Anda
dengan kerangka kerja untuk mengevaluasi ide-ide tersebut saat muncul,
membantu Anda memahami bagaimana (atau jika) mereka cocok dengan apa yang Anda miliki
sudah berkomitmen untuk membangun.
Mengetahui apa yang tidak Anda bangun juga berarti mengetahui apa yang Anda bangun tidak
membangun sekarang. Nilai sebenarnya dalam mengumpulkan semua yang hebat itu
ide-ide datang dari menemukan cara yang tepat untuk menyesuaikannya dengan ide Anda
rencana jangka panjang. Dengan menetapkan serangkaian persyaratan yang konkret, dan
menimbun permintaan yang tidak sesuai sebagai kemungkinan untuk rilis mendatang,
Anda dapat mengelola seluruh proses dengan cara yang lebih disengaja.
Januari (sekarang)
April Juli Oktober (berikutnya) Januari Persyaratan itu

tidak bisa bertemu di
jadwal saat ini bisa
membentuk dasar untuk
Versi 1.0 Versi 1.1 tonggak berikutnya dalam siklus
pengembangan Anda.
Jika Anda tidak secara sadar mengelola kebutuhan Anda, Anda akan terjebak dalam "scope creep"
yang ditakuti. Gambar ini selalu membawa
yang kupikirkan adalah bola salju yang menggelinding ke depan satu inci—dan kemudian
yang lain—mengambil sedikit salju ekstra di setiap belokan sampai benar-benar
meluncur menuruni bukit, semakin besar dan sulit untuk berhenti sepanjang jalan turun.
Demikian juga, setiap persyaratan tambahan mungkin tidak terlihat
seperti itu banyak pekerjaan ekstra. Tetapi satukan semuanya, dan Anda memiliki proyek yang
lepas kendali, menghancurkan tenggat waktu, dan
perkiraan anggaran dalam perjalanan menuju kehancuran akhir yang tak terelakkan.
Fungsionalitas dan Konten
Pada bidang lingkup, kita mulai dari pertanyaan abstrak “Mengapa
apakah kita membuat produk ini?” yang kami tangani dalam bidang strategi dan
membangunnya dengan pertanyaan baru: “Apa yang akan kita lakukan
untuk membuat?"

struktur
cakupan
strategi
Pemisahan antara Web sebagai kendaraan untuk fungsionalitas dan Web
sebagai media informasi mulai berperan di
pesawat ruang lingkup. Di sisi fungsionalitas, kami memperhatikan apa akan
dianggap sebagai kumpulan fitur dari produk perangkat lunak. Pada sisi
informasi, kita berurusan dengan konten, tradisional
domain kelompok komunikasi editorial dan pemasaran.
Konten dan fungsionalitas tampak sama berbedanya dengan keduanya
hal-hal bisa saja, tetapi ketika harus mendefinisikan ruang lingkup, itu bisa menjadi ditangani
dengan cara yang sangat mirip. Sepanjang bab ini, saya akan menggunakan istilah fitur untuk
merujuk pada fungsi dan konten perangkat lunak
persembahan.
Dalam pengembangan perangkat lunak, ruang lingkup didefinisikan melalui persyaratan
fungsional atau spesifikasi fungsional. Beberapa organisasi
gunakan istilah ini untuk mengartikan dua dokumen berbeda: persyaratan
di awal proyek untuk menggambarkan apa yang seharusnya dilakukan oleh sistem
lakukan, dan spesifikasi di bagian akhir untuk menggambarkan apa yang sebenarnya dilakukannya.
Dalam kasus lain, spesifikasi dikembangkan segera setelah

persyaratan, mengisi rincian pelaksanaan. Tapi kebanyakan
waktu, istilah-istilah ini dapat dipertukarkan — pada kenyataannya, beberapa orang menggunakan
spesifikasi persyaratan fungsional jangka hanya untuk memastikan mereka sudah
menutupi semua pangkalan. Saya akan menggunakan spesifikasi fungsional untuk merujuk ke
dokumen itu sendiri, dan persyaratan untuk mengacu pada isinya.
Bahasa bab ini sebagian besar adalah bahasa perangkat lunak perkembangan.
Tetapi konsep di sini berlaku sama untuk konten.
Pengembangan konten sering kali melibatkan persyaratan yang kurang formal proses
definisi daripada perangkat lunak, tetapi prinsip-prinsip yang mendasarinya adalah sama.
Pengembang konten akan duduk dan berbicara dengan
orang atau meneliti materi sumber, apakah itu database atau laci penuh
kliping berita, untuk menentukan informasi apa mation perlu
disertakan dalam konten yang dia kembangkan. Ini
proses untuk mendefinisikan persyaratan konten sebenarnya tidak semua itu
berbeda dari fitur brainstorming teknolog dengan stake
pemegang dan meninjau dokumentasi yang ada. Tujuan dan
pendekatan adalah sama.
Persyaratan konten sering kali memiliki implikasi fungsional. Ini hari,
situs konten murni biasanya ditangani melalui konten
sistem manajemen (CMS). Sistem ini datang dalam segala bentuk
dan ukuran, dari sistem yang sangat besar dan kompleks yang secara dinamis hasilkan
halaman dari selusin sumber data berbeda hingga ringan
alat yang dioptimalkan untuk mengelola satu jenis fitur konten tertentu di
cara yang paling efisien. Anda mungkin memutuskan untuk membeli kepemilikan sistem
manajemen konten, gunakan salah satu dari banyak sumber terbuka alternatif, atau bahkan
membangunnya dari awal. Bagaimanapun, itu akan mengambil beberapa mengutak-atik untuk
menyesuaikan sistem untuk organisasi Anda dan konten Anda.

Sebuah manajemen konten editor konten Pemeriksa naskah
sistem dapat mengotomatisasi alur
kerja yang diperlukan untuk
memproduksi dan mengirimkan
konten kepada pengguna.
penulis pengguna
pemangku kepentingan pengacara
Fungsionalitas yang Anda butuhkan dalam sistem manajemen konten Anda akan
bergantung pada sifat konten yang akan Anda kelola. Akan
Anda memelihara konten dalam berbagai bahasa atau format data?

CMS harus mampu menangani semua jenis konten tersebut
elemen. Apakah setiap siaran pers harus disetujui oleh enam eksekutif? wakil
presiden dan pengacara? CMS perlu mendukung
proses persetujuan semacam itu dalam alur kerjanya. Akankah elemen konten
digabungkan secara dinamis sesuai dengan preferensi masing-masing pengguna, atau
perangkat yang mereka gunakan? CMS harus mampu mencapai tingkat pengiriman
yang kompleks.
Demikian pula, persyaratan fungsional dari setiap produk teknologi
memiliki implikasi konten. Apakah akan ada instruksi di pref
menampilkan layar konfigurasi? Bagaimana dengan pesan kesalahan? Beberapa tubuh
harus menulis mereka. Setiap kali saya melihat pesan kesalahan di a
Situs web seperti "Pengecualian bidang input nol", saya tahu beberapa insinyur pesan
placeholder berhasil menjadi produk akhir karena tidak ada orang menjadikan pesan
kesalahan itu sebagai persyaratan konten. Tak terhitung diduga proyek teknis dapat
ditingkatkan secara tak terukur jika
pengembang hanya meluangkan waktu untuk meminta seseorang melihat aplikasi
dengan memperhatikan konten.

Mendefinisikan Persyaratan
Beberapa persyaratan berlaku untuk produk secara keseluruhan. Persyaratan branding adalah
salah satu contoh umum dari hal ini; teknis tertentu
persyaratan, seperti browser dan sistem operasi yang didukung,
adalah yang lain.
Persyaratan lain hanya berlaku untuk fitur tertentu. Sebagian besar waktu ketika orang merujuk
pada suatu persyaratan, mereka memikirkan a
deskripsi singkat tentang fitur tunggal yang harus dimiliki produk.
Tingkat detail dalam kebutuhan Anda akan sering bergantung pada
lingkup proyek tertentu. Jika tujuan proyek adalah untuk mengimplementasikan satu
subsistem yang sangat kompleks, tingkat detail yang sangat tinggi
mungkin diperlukan, meskipun ruang lingkup proyek relatif terhadap situs yang lebih besar
mungkin cukup kecil. Sebaliknya, skala yang sangat besar
proyek konten mungkin melibatkan basis konten yang homogen (seperti sejumlah besar PDF
produk yang identik secara fungsional
manual) bahwa persyaratan konten hanya bisa sangat umum.
Sumber persyaratan yang paling produktif akan selalu menjadi milik Anda
pengguna itu sendiri. Tetapi lebih sering, kebutuhan Anda akan datang dari pemangku
kepentingan, orang-orang di organisasi Anda yang memiliki pendapat
atas apa yang masuk ke produk Anda.
Dalam kedua kasus tersebut, cara terbaik untuk mengetahui apa yang diinginkan orang hanyalah
untuk bertanya kepada mereka. Teknik penelitian pengguna yang diuraikan dalam Bab 3 semuanya dapat digunakan
untuk membantu Anda mendapatkan pemahaman yang lebih baik tentang jenis-jenisnya
fitur yang ingin dilihat pengguna di produk Anda.
Apakah Anda mendefinisikan persyaratan dengan bantuan dari pemangku kepentingan di dalam
organisasi Anda atau bekerja secara langsung dengan pengguna,

persyaratan yang keluar dari proses akan jatuh ke dalam tiga gen
kategori umum. Pertama, dan yang paling jelas, adalah hal-hal yang dikatakan orang
mereka ingin. Beberapa di antaranya jelas merupakan ide yang bagus dan akan ditemukan
jalan mereka ke dalam produk akhir.
Terkadang hal-hal yang orang katakan mereka inginkan bukanlah hal yang mereka inginkan
sebenarnya ingin. Ini tidak biasa bagi siapa pun, ketika mereka bertemu
beberapa kesulitan dengan proses atau produk, untuk membayangkan solusi.
Terkadang solusi itu tidak bisa dijalankan, atau mengatasi gejala
daripada penyebab yang mendasari masalah. Dengan menjelajahi
saran-saran ini, Anda terkadang bisa sampai pada hal yang sama sekali berbeda
persyaratan yang memecahkan masalah nyata.
Jenis persyaratan ketiga adalah fitur yang tidak diketahui orang
mereka ingin. Ketika Anda membuat orang berbicara tentang tujuan strategis
dan persyaratan baru yang mungkin memenuhinya, terkadang mereka akan
menemukan ide-ide hebat yang sama sekali tidak terpikirkan oleh siapa pun selama
pemeliharaan produk yang berkelanjutan. Ini sering keluar dari
latihan brainstorming, ketika peserta memiliki kesempatan untuk berbicara
melalui dan mengeksplorasi kemungkinan untuk proyek tersebut.
Ironisnya, terkadang orang yang paling terlibat dalam menciptakan
dan bekerja dengan suatu produk adalah yang paling tidak bisa membayangkan hal baru
petunjuk untuk itu. Ketika Anda menghabiskan seluruh waktu Anda tenggelam dalam main
mempertahankan produk yang sudah ada, Anda sering lupa yang mana dari Anda
kendala adalah nyata, dan yang hanya produk dari sejarah
pilihan. Untuk alasan ini, sesi brainstorming kelompok yang membawa
bersama-sama orang-orang dari berbagai bagian organisasi atau mewakili
kelompok pengguna yang beragam dapat menjadi alat yang sangat efektif dalam membuka pikiran
peserta untuk kemungkinan mereka tidak akan dipertimbangkan sebelumnya.
Mendapatkan insinyur, agen layanan pelanggan, dan pemasaran
orang di ruangan bersama-sama untuk berbicara tentang situs Web yang sama dapat
mencerahkan bagi semua orang. Mendengar perspektif yang tidak dikenal—dan
memiliki kesempatan untuk menanggapinya—mendorong orang untuk
berpikir dalam istilah yang lebih luas tentang kedua masalah yang terlibat dalam pembangunan
ing produk dan solusi yang mungkin.
Perangkat apa pun yang kami rancang—atau jika kami sedang merancang
perangkat itu sendiri — set fitur kami harus diperhitungkan dengan keras
persyaratan gudang juga. Apakah perangkat memiliki kamera? GPS?
Sensor posisi giroskopik? Pertimbangan ini akan menginformasikan dan
membatasi kemungkinan fungsional Anda.
Menghasilkan persyaratan sering kali merupakan masalah menemukan cara untuk
menghilangkan hambatan. Misalnya, asumsikan Anda memiliki pengguna
yang telah memutuskan untuk membeli suatu produk—mereka hanya belum
memutuskan apakah produk Anda adalah produk yang akan mereka beli. Apa yang bisa situs Anda?
lakukan untuk membuat proses ini—pertama pilih produk Anda, lalu beli
ing produk Anda—lebih mudah bagi mereka?
Di Bab 3, kita melihat teknik membuat karakter fiksi
aktor yang disebut persona untuk membantu kami lebih memahami kebutuhan pengguna. Di
menentukan persyaratan, kita dapat menggunakan persona itu lagi dengan menempatkan
mengubah karakter fiksi kita menjadi cerita kecil yang disebut skenario. SEBUAH
Skenario adalah narasi pendek dan sederhana yang menggambarkan bagaimana seseorang dapat
pergi tentang mencoba untuk memenuhi salah satu kebutuhan pengguna tersebut. Dengan membayangkan
proses yang mungkin dilalui pengguna kami, kami dapat menemukan potensi
persyaratan untuk membantu memenuhi kebutuhan mereka.
Kita juga dapat mencari inspirasi dari pesaing kita. Siapa lagi di
bisnis yang sama hampir pasti mencoba untuk bertemu dengan pengguna yang sama
kebutuhan dan mungkin mencoba untuk mencapai tujuan produk serupa
tif juga. Apakah pesaing menemukan fitur yang sangat efektif?
untuk memenuhi salah satu tujuan strategis ini? Bagaimana mereka menanganinya?
trade-off dan kompromi yang sama yang kita hadapi?

Bahkan produk yang bukan pesaing langsung bisa menjadi subur
sumber untuk kemungkinan persyaratan. Beberapa platform game, untuk
misalnya, menawarkan pengguna kemampuan untuk membuat grup sosial sesama
pemain. Mengadopsi atau membangun pendekatan mereka saat melingkupi a
fitur serupa untuk perekam video digital kami dapat memberi kami keuntungan
tage atas kompetisi langsung kami.
Spesifikasi Fungsional
Spesifikasi fungsional memiliki reputasi buruk di
kuartal tertentu. Pemrogram sering membenci spesifikasi karena mereka cenderung
menjadi sangat membosankan, dan waktu yang dihabiskan untuk membacanya adalah waktu yang terbuang
jauh dari memproduksi kode. Akibatnya, spesifikasi tidak terbaca, yang
pada gilirannya memperkuat kesan bahwa memproduksinya adalah pemborosan
waktu—karena memang begitu! Pendekatan yang buruk terhadap spesifikasi menjadi diri sendiri
memenuhi nubuat.
Satu keluhan tentang spesifikasi fungsional adalah bahwa mereka tidak
mencerminkan produk yang sebenarnya. Hal-hal berubah selama implementasi.
Semua orang memahami ini—inilah sifat bekerja dengan teknologi
nologi. Terkadang sesuatu yang Anda pikir akan berhasil tidak, atau
kemungkinan besar tidak bekerja seperti yang Anda pikirkan. Ini,
namun, bukan alasan untuk mengabaikan spesifikasi penulisan sebagai tujuan yang hilang.
Sebaliknya, ini menyoroti pentingnya spesifikasi yang benar-benar berfungsi.
Ketika hal-hal berubah selama implementasi, jawabannya bukan untuk
angkat tangan dan nyatakan kesia-siaan spesifikasi penulisan. Itu
jawabannya adalah membuat proses mendefinisikan spesifikasi menjadi ringan cukup
bahwa spesifikasi tidak menjadi proyek yang terpisah dari pengembang
membuka produk itu sendiri.

Dengan kata lain, dokumentasi tidak akan menyelesaikan masalah Anda. definisi
akan. Ini bukan tentang volume atau detail. Ini tentang kejelasan dan akurasi
bersemangat. Spesifikasi tidak harus mewujudkan setiap aspek produk—hanya
yang membutuhkan definisi untuk menghindari kebingungan dalam desain dan
proses pengembangan. Dan spesifikasi tidak perlu menangkap beberapa ideal
keadaan masa depan yang ditentukan untuk produk—hanya keputusan yang telah
dibuat selama pembuatannya.
Menuliskannya
Tidak peduli seberapa besar atau kompleks proyek itu, beberapa jenderal
aturan berlaku untuk menulis segala jenis persyaratan.
Menjadi positif. Alih-alih menggambarkan hal buruk yang seharusnya tidak dilakukan oleh sistem
lakukan, jelaskan apa yang akan dilakukan untuk mencegah hal buruk itu. Sebagai contoh,
bukannya ini:
Sistem tidak akan mengizinkan pengguna untuk membeli layang-layang tanpa
tali layang-layang.
Ini akan lebih baik:
Sistem akan mengarahkan pengguna ke halaman string layang-layang jika pengguna mencoba
untuk membeli layang-layang tanpa tali.
Jadilah spesifik. Meninggalkan sesedikit mungkin terbuka untuk interpretasi adalah
satu-satunya cara kita dapat menentukan apakah suatu persyaratan telah terpenuhi.
Bandingkan contoh-contoh ini:
1. Video paling populer akan disorot.
2. Video dengan penayangan terbanyak dalam seminggu terakhir akan muncul di
bagian atas daftar.

Contoh pertama tampaknya mengidentifikasi persyaratan yang jelas, tetapi memang demikian
tidak perlu banyak penyelidikan untuk mulai menyodok lubang di dalamnya. Berapa jumlahnya
sebagai populer? Video dengan komentar terbanyak? Mereka yang memiliki
suara "suka" terbanyak? Dan apa yang dimaksud dengan menyoroti mereka?
Contoh kedua mendefinisikan tujuan kita secara spesifik, mendefinisikan
apa yang kami maksud dengan populer dan menggambarkan mekanisme untuk high
Petir. Dengan menghilangkan kemungkinan interpretasi yang berbeda,
persyaratan kedua dengan rapi menutupi jenis argumen yang mungkin
muncul selama atau setelah implementasi.
Hindari bahasa subyektif. Ini benar-benar hanya cara lain
menjadi spesifik dan menghilangkan ambiguitas—dan karena itu kemungkinan
untuk salah tafsir—dari persyaratan.
Inilah persyaratan yang sangat subjektif:
Situs ini akan memiliki gaya yang trendi dan mencolok.
Persyaratan harus dapat dipalsukan—yaitu, harus memungkinkan untuk
menunjukkan ketika persyaratan belum terpenuhi. Sulit untuk
menunjukkan apakah kualitas subjektif seperti pinggul dan mencolok memiliki
telah terpenuhi. Ide saya tentang hipness mungkin tidak cocok dengan Anda, dan
kemungkinan besar CEO punya ide lain sama sekali.
Ini tidak berarti Anda tidak dapat mengharuskan situs Anda menjadi trendi. Anda hanya
harus menemukan cara untuk menentukan kriteria mana yang akan diterapkan:
Situs ini akan memenuhi harapan keren Wayne, petugas surat.
Wayne biasanya tidak akan mengatakan apa pun tentang proyek itu, tetapi kami sponsor
proyek jelas menghormati rasa kehipnotisannya. Semoga itu
pengertian yang sama yang dimiliki pengguna kami. Tapi persyaratannya masih agak
sewenang-wenang karena kami mengandalkan persetujuan Wayne alih-alih cri kriteria yang
dapat didefinisikan secara lebih objektif. Jadi mungkin ini membutuhkan
ment akan menjadi yang terbaik dari semuanya:
Tampilan situs akan sesuai dengan pedoman branding perusahaan
dokumen.
Seluruh konsep hipness kini telah hilang sepenuhnya dari
yang dibutuhkan. Sebaliknya, kami memiliki referensi yang jelas dan tidak ambigu
terhadap pedoman yang telah ditetapkan. Untuk memastikan pedoman branding adalah
cukup keren, VP pemasaran dapat berkonsultasi dengan Wayne the mail
petugas, atau dia mungkin berkonsultasi dengan putri remajanya, atau dia bahkan mungkin—
berkonsultasi dengan beberapa temuan penelitian pengguna. Terserah dia. Tapi sekarang kita bisa
mengatakan secara pasti apakah persyaratan telah terpenuhi.
Kami juga dapat menghilangkan subjektivitas dengan mendefinisikan beberapa persyaratan
secara kuantitatif. Sama seperti metrik keberhasilan membuat tujuan strategis menjadi penting dapat
dibenarkan, mendefinisikan persyaratan dalam istilah kuantitatif dapat membantu kita
mengidentifikasi apakah kami telah memenuhi persyaratan. Misalnya, sebagai gantinya
mensyaratkan bahwa sistem memiliki "tingkat kinerja yang tinggi," kami
dapat mengharuskan sistem dirancang untuk mendukung setidaknya 1.000 pengguna
simultan. Jika produk akhir hanya memungkinkan pengguna tiga digit
angka, kami dapat memberitahu persyaratan belum terpenuhi.
Persyaratan Konten
Sebagian besar waktu, ketika kita berbicara tentang konten, kita mengacu pada
teks. Tapi gambar, audio, dan video bisa lebih penting daripada
teks yang menyertai. Jenis konten yang berbeda ini juga dapat berfungsi
bersama-sama untuk memenuhi satu kebutuhan. Misalnya, konten

fitur yang meliput acara olahraga mungkin disertai artikel
dilengkapi dengan foto dan klip video. Mengidentifikasi semua konten jenis
yang terkait dengan fitur dapat membantu Anda menentukan apa
sumber daya akan dibutuhkan untuk menghasilkan konten (atau apakah dapat
diproduksi sama sekali).
Jangan bingung antara format konten dan isinya
tujuan. Saat mendiskusikan persyaratan konten dengan pemangku kepentingan,
salah satu hal pertama yang biasanya saya dengar adalah, "Kita harus memiliki FAQ." Tetapi
istilah FAQ benar-benar hanya mengacu pada format konten: seri sederhana dari
pertanyaan dan jawaban. Nilai sebenarnya dari FAQ bagi pengguna adalah
menyediakan akses siap ke informasi yang umum dibutuhkan. Lainnya persyaratan
konten dapat memenuhi tujuan yang sama; tapi ketika
fokusnya pada formatnya, tujuannya sendiri bisa dilupakan. Lagi
sering daripada tidak, FAQ mengabaikan bagian "sering" dari persamaan,
sebagai gantinya menawarkan jawaban atas pertanyaan apa pun yang diberikan penyedia konten
bisa memikirkan untuk memenuhi persyaratan FAQ.
Ukuran yang diharapkan dari setiap fitur konten Anda sangat besar berpengaruh
pada keputusan pengalaman pengguna yang harus Anda buat. Persyaratan konten
Anda harus memberikan perkiraan kasar tentang ukuran setiap fitur: jumlah kata
untuk fitur teks, dimensi piksel
untuk gambar atau video, dan ukuran file untuk diunduh, berdiri sendiri
elemen konten seperti file audio atau dokumen PDF. Estimasi ukuran ini
pasangan tidak harus tepat—perkiraan boleh saja. Hanya kita
harus mengumpulkan informasi penting yang diperlukan untuk merancang pendekatan
kendaraan yang tepat untuk konten tersebut. Merancang situs untuk menyediakan akses ke
gambar mini kecil berbeda dari mendesain situs untuk disediakan akses
ke foto layar penuh; mengetahui terlebih dahulu ukuran

elemen konten yang harus kami akomodasi memungkinkan kami untuk membuat
keputusan yang cerdas dan terinformasi di sepanjang jalan.
Penting untuk mengidentifikasi siapa yang akan bertanggung jawab untuk setiap konten
elemen sedini mungkin. Setelah divalidasi terhadap kami
tujuan strategis, fitur konten apa pun pasti terdengar seperti
ide yang sangat bagus — selama orang lain bertanggung jawab untuk menciptakan
dan memeliharanya. Jika kita terlalu jauh ke dalam pro pengembangan
cess tanpa mengidentifikasi siapa yang akan bertanggung jawab untuk setiap yang diperlukan
fitur konten, kami cenderung berakhir dengan lubang menganga di situs kami
karena fitur-fitur itu disukai semua orang ketika mereka masih hipotetis
cal ternyata terlalu banyak pekerjaan bagi siapa pun untuk benar-benar mengambil.
Dan itulah yang sering dilupakan orang ketika berkembang membutuhkan
ment: Konten adalah kerja keras. Anda mungkin bisa menyewa dengan kontrak
sumber daya (atau, lebih mungkin, menurunkan seseorang dalam pemasaran dengan
pekerjaan) untuk membuat konten tepat waktu untuk peluncuran awal, tetapi siapa
akan tetap up to date? Konten—yah, konten yang efektif, toh—
membutuhkan perawatan yang konstan. Mendekati konten seolah-olah Anda bisa
posting dan lupakan itu mengarah ke situs yang, seiring waktu, meningkat
pekerjaan yang sangat buruk dalam memenuhi kebutuhan pengguna.
Inilah sebabnya, untuk setiap fitur konten, Anda harus mengidentifikasi caranya
sering akan diperbarui. Frekuensi pembaruan harus
berasal dari tujuan strategis Anda untuk situs: Berdasarkan produk Anda
tujuan, seberapa sering Anda ingin pengguna kembali? Berdasarkan
kebutuhan pengguna Anda, seberapa sering mereka mengharapkan informasi yang diperbarui
tion? Namun, perlu diingat bahwa frekuensi pembaruan yang ideal untuk
pengguna Anda (“Saya ingin tahu segalanya secara instan, 24 jam sehari!”)
mungkin tidak praktis untuk organisasi Anda. Anda harus tiba di

frekuensi yang mewakili kompromi yang masuk akal antara
harapan pengguna Anda dan sumber daya yang tersedia.
Jika situs Anda harus melayani banyak audiens dengan kebutuhan yang berbeda,
mengetahui audiens mana yang dimaksudkan untuk suatu konten dapat
membantu Anda membuat keputusan yang lebih baik tentang cara menyajikan konten tersebut.
Informasi yang ditujukan untuk anak-anak memerlukan pendekatan yang berbeda
dari informasi yang ditujukan untuk orang tua mereka; informasi untuk keduanya
dari mereka membutuhkan pendekatan ketiga.
Untuk proyek yang melibatkan bekerja dengan banyak konten yang ada,
banyak informasi yang akan memenuhi kebutuhan Anda adalah
dicatat dalam inventaris konten. Menginventarisir semua
konten di situs Anda yang ada mungkin tampak seperti proses yang membosankan—dan
itu biasanya. Tetapi memiliki inventaris (yang biasanya membutuhkan
bentuk spreadsheet sederhana, meskipun sangat besar) penting untuk alasan
yang sama bahwa memiliki persyaratan konkret itu penting: jadi
semua orang di tim tahu persis apa yang harus mereka kerjakan
dalam menciptakan pengalaman pengguna.
Memprioritaskan Persyaratan
Mengumpulkan ide untuk persyaratan yang mungkin tidak sulit. Hampir
setiap orang yang secara teratur melakukan kontak dengan suatu produk—apakah
mereka berada di dalam atau di luar organisasi—setidaknya akan memiliki satu
ide untuk fitur yang dapat ditambahkan. Bagian yang sulit adalah memilah
fitur apa yang harus disertakan dalam cakupan proyek Anda.

Terkadang strategis objektif
akan menghasilkan beberapa
persyaratan (kiri). Dalam
kasus lain, satu syarat bisa
melayani beberapa strategis
tujuan (kanan).
Sebenarnya cukup jarang Anda melihat korelasi satu-ke-satu yang sederhana antara
tujuan strategis Anda dan kebutuhan Anda. Beberapa
kali satu persyaratan dapat diterapkan ke beberapa strategi tujuan.
Demikian pula, satu tujuan akan sering dikaitkan dengan beberapa
persyaratan yang berbeda.
Karena ruang lingkup dibangun di atas strategi, kita perlu mengevaluasi
kemungkinan persyaratan berdasarkan apakah persyaratan tersebut memenuhi strategi kami
tujuan (baik tujuan produk dan kebutuhan pengguna). Selain itu
dua pertimbangan, mendefinisikan ruang lingkup menambahkan yang ketiga: Seberapa layak
apakah akan benar-benar membuat barang ini?

Beberapa fitur tidak dapat diimplementasikan karena secara teknis
tidak mungkin—misalnya, tidak ada cara untuk mengizinkan pengguna mencium
produk melalui Web, tidak peduli seberapa buruk yang mereka inginkan
kemampuan itu. Fitur lain (terutama dalam hal konten)
tidak layak karena mereka akan menuntut lebih banyak sumber daya — manusia
atau keuangan—daripada yang kita miliki. Dalam kasus lain, itu hanya
masalah waktu: Fitur ini akan membutuhkan waktu tiga bulan untuk diterapkan,
tapi kami memiliki persyaratan eksekutif untuk meluncurkan dalam dua.
Dalam hal keterbatasan waktu, Anda dapat mendorong fitur ke lain waktu
rilis atau tonggak proyek. Untuk kendala sumber daya, teknologi
atau perubahan organisasi terkadang bisa—tetapi, yang penting, tidak
selalu—kurangi beban sumber daya, memungkinkan fitur untuk diimplementasikan
disebutkan. (Namun, hal-hal yang tidak mungkin akan tetap tidak mungkin. Maaf.)
Beberapa fitur ada dalam ruang hampa. Bahkan fitur konten di situs Web
mengandalkan fitur di sekitar mereka untuk memberi tahu pengguna tentang cara terbaik untuk
menggunakan konten yang disediakan. Ini pasti mengarah pada konflik antara
fitur. Beberapa fitur akan membutuhkan trade-off dengan yang lain secara berurutan
untuk menghasilkan keseluruhan yang koheren dan konsisten. Misalnya, pengguna mungkin
menginginkan proses pengiriman pesanan satu langkah — tetapi jalinan warisan
database yang digunakan situs tidak dapat menampung semua data sekaligus. Apakah itu
lebih baik untuk pergi dengan proses beberapa langkah, atau harus Anda ulang
sistem basis data? Itu tergantung pada tujuan strategis Anda.
Perhatikan saran fitur yang menunjukkan kemungkinan perubahan dalam
strategi yang tidak terlihat selama pengembangan
dokumen visi. Saran fitur apa pun yang tidak sesuai dengan proj
dll strategi, menurut definisi, di luar ruang lingkup. Tetapi jika fitur yang disarankan yang
berada di luar ruang lingkup tidak sesuai dengan jenis kendala apa pun
di atas dan masih terdengar seperti ide yang bagus, Anda mungkin ingin memeriksa kembali
beberapa tujuan strategis Anda. Jika Anda menemukan diri Anda meninjau kembali
banyak aspek dari strategi Anda, namun, Anda mungkin telah melompat
dalam mendefinisikan persyaratan terlalu cepat.
Jika strategi atau dokumen visi Anda mengidentifikasi hierarki yang jelas dari
prioritas di antara tujuan strategis Anda, prioritas ini harus
menjadi faktor utama dalam menentukan prioritas usulan
fitur. Namun, kadang-kadang, kepentingan relatif dari dua
tujuan strategis yang berbeda tidak jelas. Dalam kasus ini, apakah
fitur berakhir di ruang lingkup proyek terlalu sering turun ke
politik perusahaan.
Ketika pemangku kepentingan berbicara tentang strategi, mereka biasanya memulai dengan
ide fitur, dan kemudian harus dibujuk kembali ke yang mendasarinya
faktor strategis. Karena pemangku kepentingan sering kesulitan memisahkan fitur dari
strategi, fitur tertentu akan sering memiliki juara.
Dengan demikian proses definisi persyaratan menjadi masalah nego
hubungan antara pemangku kepentingan yang termotivasi.
Mengelola proses negosiasi ini bisa jadi sulit. Terbaik
pendekatan untuk menyelesaikan konflik antara pemangku kepentingan adalah untuk menarik
strategi yang ditentukan. Fokus pada tujuan strategis, bukan cara yang diusulkan
dari mencapai mereka. Jika Anda dapat meyakinkan pemangku kepentingan dengannya
hati tertuju pada fitur tertentu yang menjadi tujuan strategis fitur tersebut
dimaksudkan untuk memenuhi dapat diatasi dengan cara lain, dia tidak akan merasa
kebutuhan konstituennya diabaikan. Memang,
ini sering lebih mudah diucapkan daripada dilakukan. Menunjukkan empati dengan
kebutuhan pemangku kepentingan sangat penting untuk menyelesaikan konflik fitur. Siapa
mengatakan pekerja teknologi tidak membutuhkan keterampilan orang?

bab 5
Struktur
Pesawat terbang
Desain Interaksi dan

Arsitektur Informasi
Permukaan
Kerangka
Struktur
Setelah persyaratan ditentukan dan
diprioritaskan, kami memiliki gambaran yang jelas tentang apa yang akan
Cakupan
termasuk dalam produk akhir. Persyaratan,
namun, jangan jelaskan bagaimana potongan-potongan itu cocok bersama Strategi
untuk membentuk satu kesatuan yang kohesif. Ini adalah level selanjutnya
dari ruang lingkup: mengembangkan struktur konseptual untuk
situs.
80 BAB 5 STRUKTUR BIDANG
Mendefinisikan Struktur
Ranah struktur adalah yang ketiga dari lima bidang, dan dengan tepat inilah titik
di mana perhatian kita bergeser dari yang lebih
masalah abstrak strategi dan ruang lingkup hingga faktor konkret yang akan
menentukan apa yang akhirnya dialami pengguna. Tapi garis antara abstrak dan
konkret bisa kabur—walaupun banyak dari apa yang kami putuskan di sini akan
memiliki pengaruh nyata dan nyata pada final
produk, keputusan itu sendiri masih melibatkan sebagian besar konseptual

penting.
kerangka
struktur
cakupan
Dalam pengembangan perangkat lunak tradisional, disiplin yang terlibat dalam
menciptakan pengalaman terstruktur bagi pengguna dikenal sebagai interaksi desain
tion. Dulu disamakan di bawah judul "antarmuka"
desain, "tetapi desain interaksi sekarang diakui sebagai yang terpisah
disiplin.
Dalam pengembangan konten, penataan pengalaman pengguna adalah sebuah pertanyaan
tion arsitektur informasi. Bidang ini mengacu pada nomor
disiplin ilmu yang secara historis berkaitan dengan organisasi
nization, pengelompokan, pemesanan, dan penyajian konten: perpustakaan
sains, jurnalistik, dan komunikasi teknis, antara lain.
Desain interaksi dan arsitektur informasi berbagi penekanan
tentang menentukan pola dan urutan di mana opsi akan lebih dulu
dikirim ke pengguna. Desain interaksi menyangkut pilihan yang terlibat dalam
melakukan dan menyelesaikan tugas. Penawaran arsitektur informasi
dengan pilihan yang terlibat dalam menyampaikan informasi kepada pengguna.
Desain interaksi dan arsitektur informasi terdengar seperti esoterik,
bidang yang sangat teknis, tetapi disiplin ini tidak benar-benar tentang
teknologi sama sekali. Itu tentang memahami orang—caranya
mereka berperilaku dan berpikir. Dengan membangun pemahaman ini ke dalam struktur
produk kami, kami membantu memastikan pengalaman yang sukses bagi yang
menggunakannya.
Desain Interaksi
Desain interaksi berkaitan dengan menggambarkan kemungkinan perilaku pengguna ior dan
mendefinisikan bagaimana sistem akan mengakomodasi dan merespons
perilaku itu. Setiap kali seseorang menggunakan produk, semacam tarian
berlangsung di antara mereka berdua. Pengguna bergerak, dan
sistem merespon. Kemudian pengguna bergerak sebagai respons terhadap sistem,
dan begitulah tarian itu berlanjut. Tetapi cara khas yang dimiliki perangkat lunak telah
dirancang tidak benar-benar mengakui tarian ini. Pemikirannya

tampaknya jika setiap aplikasi menari sedikit berbeda
Lagi pula, itu tidak masuk akal untuk mengharapkan pengguna untuk beradaptasi.
Sistem dapat melakukan tugasnya, dan jika beberapa jari kaki terinjak,
Yah, itu adalah bagian dari proses pembelajaran. Tapi setiap penari akan
memberitahu Anda bahwa agar tarian benar-benar berhasil, setiap peserta harus
mengantisipasi gerakan yang lain.
Pemrogram secara tradisional berfokus pada dan paling peduli tentang
dua aspek perangkat lunak: apa yang dilakukannya dan bagaimana ia melakukannya. Ada
alasan bagus untuk ini — justru hasrat mereka untuk detail ini
yang membuat programmer pandai dalam apa yang mereka lakukan. Tapi fokus ini
berarti bahwa programmer akan tertarik untuk membangun sistem
dengan cara yang paling efisien secara teknis tanpa memperhatikan
apa yang paling berhasil bagi pengguna. Terutama saat daya komputasi
adalah sumber daya yang terbatas, pendekatan terbaik adalah yang mendapatkan pekerjaan
yang dilakukan dalam batasan teknis tersebut.
Pendekatan yang paling cocok untuk teknologi hampir tidak pernah
pendekatan yang paling cocok untuk orang yang menggunakannya. Jadi, perangkat lunak
memperoleh reputasi yang telah menghantui sebagian besar keberadaannya:
Perangkat lunak rumit, membingungkan, dan sulit digunakan. Ini sebabnya,
selama bertahun-tahun, "melek komputer"—mengajarkan orang tentang batin
cara kerja komputer—secara luas dianggap sebagai satu-satunya cara
untuk membuat pengguna dan perangkat lunak akur.
Butuh waktu lama, tetapi saat kami belajar lebih banyak tentang bagaimana orang menggunakannya
teknologi, akhirnya kami mulai menangkap gagasan bahwa,
alih-alih merancang perangkat lunak yang paling sesuai untuk mesin,
kami dapat merancang perangkat lunak yang paling sesuai untuk orang yang menggunakannya
itu, dengan demikian melewatkan seluruh bisnis pengiriman pegawai file ini ke
kelas pemrograman untuk meningkatkan literasi komputer mereka. Yang baru
disiplin yang muncul untuk membantu pengembang perangkat lunak melakukan ini disebut
desain interaksi.
Model Konseptual
Kesan pengguna tentang bagaimana komponen interaktif yang kami buat akan
berperilaku dikenal sebagai model konseptual. Misalnya, apakah
sistem memperlakukan fitur tertentu sebagai sesuatu yang dikonsumsi pengguna,
tempat yang dikunjungi pengguna, atau objek yang diperoleh pengguna? Situs yang berbeda
mengambil pendekatan yang berbeda. Mengetahui model konseptual Anda memungkinkan
Anda untuk membuat keputusan desain yang konsisten. Tidak masalah apakah
elemen konten adalah tempat atau objek; yang penting itu
situs berperilaku secara konsisten, alih-alih memperlakukan elemen sebagai tempat
kadang-kadang dan objek di lain waktu.
Misalnya, model konseptual untuk komposisi keranjang belanja
Salah satu ciri khas situs e-niaga adalah wadah. meta ini
konsep phorical mempengaruhi desain komponen dan
bahasa yang kita gunakan dalam antarmuka. Sebuah wadah memegang benda; sebagai
hasilnya, kami "memasukkan barang ke dalam" dan "mengeluarkan barang dari" "kereta",
dan sistem harus menyediakan fungsi untuk menyelesaikan tugas-tugas ini.
Misalkan model konseptual untuk komponen tersebut berbeda
ent analog dunia nyata, seperti formulir pemesanan katalog. Sistem
mungkin menyediakan fungsi edit yang akan menggantikan kedua add dan hapus
fungsi gerobak tradisional, dan alih-alih menggunakan a
metafora checkout untuk menyelesaikan proses, pengguna mungkin mengirim
pesanan masuk
Baik model toko ritel maupun model katalog tampak sempurna
cocok untuk memungkinkan pengguna melakukan pemesanan melalui Web. Yang mana
memilih? Model toko ritel sangat banyak digunakan di Web sehingga
itu diambil pada status konvensi. Jika pengguna Anda melakukan banyak hal
berbelanja di situs Web lain, Anda mungkin ingin tetap berpegang pada itu
Konvensi. Menggunakan model konseptual orang sudah akrab
dengan membuatnya lebih mudah bagi mereka untuk beradaptasi dengan situs yang tidak dikenal. Dari
Tentu saja, tidak ada yang salah dengan melepaskan diri dari konvensi
baik—selama Anda memiliki alasan yang baik untuk melakukannya dan memiliki
model konseptual alternatif yang akan memenuhi kebutuhan pengguna Anda saat
masih masuk akal bagi mereka. Model konseptual yang tidak dikenal hanyalah
efektif ketika pengguna dapat memahami dan menafsirkannya dengan benar.
Model konseptual dapat merujuk hanya pada satu komponen sistem atau
ke sistem secara keseluruhan. Ketika situs berita dan komentar Slate
diluncurkan, model konseptualnya adalah majalah dunia nyata: Situs
memiliki bagian depan dan belakang, dan setiap halaman memiliki nomor halaman
dan elemen antarmuka yang memungkinkan pengguna untuk "membalik halaman." Seperti
ternyata, model konseptual majalah tidak terlalu menerjemahkan
efektif ke Web, dan Slate akhirnya menjatuhkannya.
Kami tidak perlu mengomunikasikan model konseptual kami kepada pengguna kami
secara eksplisit—bahkan, terkadang ini hanya membingungkan pengguna
membantu mereka. Lebih penting bahwa model konseptual adalah
digunakan secara konsisten sepanjang pengembangan interaksi rancangan.
Memahami model yang dibawa pengguna sendiri ke
situs (Apakah ini berfungsi seperti toko ritel? Apakah berfungsi seperti katalog?)
membantu kita memilih model konseptual yang paling efektif
secara aktif. Idealnya, pengguna tidak perlu diberi tahu apa yang konseptual
model yang kami ikuti; mereka akan memahaminya secara intuitif saat mereka menggunakannya
situs karena perilaku situs akan cocok dengan implisitnya harapan.
Mendasarkan model konseptual kami pada metafora yang melibatkan dunia nyata
analog dengan fungsi sistem bisa berharga, tetapi penting bukan
untuk mengambil metafora kami terlalu harfiah. Halaman beranda situs untuk
Southwest Airlines dulu hanya terdiri dari gambar pelanggan
meja layanan, dengan setumpuk brosur di satu sisi, telepon
ke sisi lain, dan seterusnya. Selama bertahun-tahun, situs itu dianggap sebagai contoh
model konseptual yang terlalu jauh—menempatkan cadangan
tion mungkin dianalogikan dengan melakukan panggilan telepon, tetapi itu tidak berarti
sistem reservasi harus benar-benar diwakili oleh a
telepon. Southwest pasti sudah bosan digunakan sebagai yang buruk contoh;
situsnya kemudian menjadi ringan pada metafora dan kon jauh lebih
fungsional.
Barat Daya lama
Situs maskapai adalah klasik
contoh konseptual
model diikat juga
dekat dengan dunia nyata
rekan-rekan.
Penanganan Kesalahan
Sebagian besar dari setiap proyek desain interaksi melibatkan berurusan dengan
kesalahan pengguna—apa yang dilakukan sistem ketika orang membuat kesalahan,
dan apa yang dapat dilakukan sistem untuk mencegah kesalahan itu terjadi
pening di tempat pertama?
Pertahanan pertama dan terbaik terhadap kesalahan adalah merancang sistem sehingga
bahwa kesalahan tidak mungkin terjadi. Sebuah contoh yang baik dari jenis ini
pertahanan dapat dilihat di setiap mobil dengan transmisi otomatis.
Menghidupkan mobil saat transmisi diaktifkan dapat merusak
mekanisme transmisi yang sensitif dan kompleks; apalagi mobilnya
tidak benar-benar mulai, tetapi malah meluncur ke depan dengan tiba-tiba. Buruk
untuk mobil, buruk untuk pengemudi, dan mungkin buruk untuk orang yang tidak bersalah
pengamat yang kebetulan berada di jalur mobil yang meluncur.
Untuk mencegah hal ini, setiap mobil dengan transmisi otomatis dirancang
jadi starter tidak akan aktif kecuali transmisi dilepas.
Karena tidak mungkin menyalakan mobil dengan transmisi
terlibat, kesalahan tidak pernah terjadi. Sayangnya, tidak begitu
mudah untuk membuat sebagian besar kesalahan pengguna menjadi tidak mungkin dengan cara ini.
Hal terbaik berikutnya untuk membuat kesalahan menjadi tidak mungkin adalah membuatnya
hanya sulit. Tetapi bahkan dengan tindakan seperti itu, beberapa kesalahan
pasti terjadi. Pada titik ini, sistem harus melakukan apa yang seharusnya
bisa untuk membantu pengguna mengetahui kesalahan dan memperbaikinya. Dalam beberapa kasus,
sistem bahkan dapat memperbaiki kesalahan atas nama pengguna. Tetapi berhati-hatilah- beberapa
perilaku yang paling menjengkelkan dari hasil produk perangkat lunak
dari upaya niat baik untuk memperbaiki kesalahan pengguna. (Jika Anda pernah
menggunakan Microsoft Word, Anda tahu persis apa yang saya bicarakan.
Setiap lapisan kesalahan
penanganan di desain
interaksi
memastikan bahwa lebih tinggi
persentase pengguna akan

positif pengalaman.
Word menawarkan banyak fitur yang dimaksudkan untuk memperbaiki kesalahan umum;
selalu, saya mendapati diri saya mematikannya sehingga saya bisa berhenti mengoreksi
koreksi dan menyelesaikan beberapa pekerjaan.)
Pesan kesalahan yang membantu dan antarmuka yang mudah ditafsirkan dapat membantu
pengguna menangkap banyak jenis kesalahan setelah itu terjadi. Tetapi beberapa
tindakan pengguna mungkin tidak tampak sebagai kesalahan sampai terlambat untuk
sistem untuk menangkap mereka. Dalam kasus ini, sistem harus menyediakan
cara bagi pengguna untuk pulih dari kesalahan. Contoh yang paling terkenal dari
ini adalah fungsi undo yang terkenal, tetapi pemulihan kesalahan bisa memakan banyak waktu
bentuk yang berbeda. Untuk kesalahan yang tidak dapat dipulihkan, berikan
banyak peringatan adalah satu-satunya cara pencegahan yang dapat dilakukan sistem
menyediakan. Tentu saja, peringatan ini hanya efektif ketika pengguna bertindak
sekutu memperhatikannya. Termasuk terlalu banyak "Apakah Anda yakin?" konfirmasi
dapat menyebabkan hal-hal yang sangat penting terabaikan—dan seringkali
mengganggu lebih banyak pengguna daripada membantu.
Arsitektur Informasi
Arsitektur informasi adalah ide baru, tetapi praktik lama—di
Bahkan, bisa dibilang setua komunikasi manusia itu sendiri. Untuk selama
orang memiliki informasi untuk disampaikan, mereka harus
membuat pilihan tentang bagaimana mereka menyusun informasi itu sehingga yang lain
orang dapat memahami dan menggunakannya.
Karena arsitektur informasi berkaitan dengan bagaimana orang
memproses informasi secara kognitif, arsitektur informasi mempertimbangkan
erasi muncul dalam produk apa pun yang mengharuskan pengguna untuk masuk akal dari
informasi yang disajikan. Jelas, pertimbangan ini adalah

penting dalam hal produk berorientasi informasi (seperti perusahaan
situs informasi) tetapi mereka dapat memiliki dampak besar bahkan di lebih banyak lagi
produk berorientasi fungsionalitas (seperti ponsel).
Penataan Konten
Di situs konten, arsitektur informasi berkaitan dengan penciptaan
ing skema organisasi dan navigasi yang memungkinkan pengguna untuk menelusuri
konten situs secara efisien dan efektif. Informasi
arsitektur di Web terkait erat dengan bidang informasi
retrieval: desain sistem yang memungkinkan pengguna menemukan informasi dengan
mudah. Tetapi arsitektur situs web sering diminta untuk melakukannya
lebih dari sekadar membantu orang menemukan sesuatu; dalam banyak kasus, mereka harus
mendidik, menginformasikan, atau membujuk pengguna.
Paling umum, masalah arsitektur informasi memerlukan
ing skema kategorisasi yang akan sesuai dengan tujuan kita sendiri untuk situs,
kebutuhan pengguna yang ingin kami penuhi, dan kontennya
yang akan dimasukkan ke dalam situs. Kami dapat menangani pembuatan seperti itu skema
kategorisasi dalam dua cara: dari atas ke bawah, atau dari
bawah ke atas.
Pendekatan top-down untuk arsitektur informasi melibatkan kre makan
arsitektur langsung dari pemahaman tentang strategi pertimbangan bidang:
tujuan produk dan kebutuhan pengguna. Mulai dengan kategori konten dan
fungsionalitas seluas mungkin
diperlukan untuk mencapai tujuan strategis ini, kami kemudian menghancurkan kucing
egori ke dalam subbagian logis. Hirarki kategori ini
dan subkategori berfungsi sebagai cangkang kosong tempat konten dan
fungsionalitas akan ditempatkan.

Pendekatan bottom-up untuk arsitektur informasi juga berasal
kategori dan subkategori, tetapi melakukannya berdasarkan analisis
konten dan persyaratan fungsional. Mulai dari sumbernya
materi yang ada (atau yang akan ada pada saat situs diluncurkan),
kami mengelompokkan item bersama ke dalam kategori tingkat rendah dan kemudian mengelompokkan
mereka ke dalam kategori tingkat yang lebih tinggi, membangun menuju struktur yang
mencerminkan tujuan produk dan kebutuhan pengguna kami.
Sebuah atas-bawah
arsitektural
pendekatan didorong oleh

pertimbangan dari
pesawat strategi.
kategori
isi
Sebuah bottom-up
arsitektural
kategori
pendekatan didorong oleh
pertimbangan dari
pesawat ruang lingkup.
isi
Tidak ada pendekatan yang lebih baik dari yang lain. Mendekati arsitektur dari atas ke bawah
terkadang dapat menyebabkan detail penting
tentang konten itu sendiri untuk diabaikan. Di sisi lain,
pendekatan bottom-up terkadang dapat menghasilkan arsitektur sehingga
disetel dengan tepat dan disesuaikan dengan konten yang ada sehingga tidak cukup fleksibel
untuk mengakomodasi perubahan atau penambahan. Menyerang bal Perbedaan antara
pemikiran top-down dan bottom-up adalah satu-satunya cara untuk memastikan hasil akhir
dapat menghindari perangkap ini.

Tidak perlu mematuhi sejumlah kategori tertentu
pada setiap tingkat atau di setiap bagian dari arsitektur. kategori
hanya harus menjadi yang tepat untuk pengguna Anda dan kebutuhan mereka. Beberapa
orang lebih suka menghitung jumlah langkah yang diperlukan untuk menyelesaikan a
tugas atau jumlah klik yang diperlukan pengguna untuk mencapai tujuan tertentu
tujuan sebagai cara untuk mengevaluasi kualitas struktur situs. Itu
tanda kualitas yang paling penting, bagaimanapun, bukanlah berapa banyak langkah
prosesnya, tetapi apakah setiap langkah masuk akal bagi pengguna dan
apakah itu mengikuti secara alami dari langkah sebelumnya. Pengguna akan
selalu mendukung proses tujuh langkah yang didefinisikan dengan jelas daripada kebingungan
alternatif tiga langkah yang sangat terkompresi.
Situs web adalah entitas hidup. Mereka membutuhkan perawatan dan pakan yang konstan
ing. Tak pelak, mereka tumbuh dan berubah seiring waktu. Dalam kebanyakan kasus,
beberapa persyaratan baru yang diperoleh di sepanjang jalan seharusnya tidak memerlukan
memikirkan kembali keseluruhan struktur situs. Salah satu sifat yang efektif
struktur adalah kemampuannya untuk mengakomodasi pertumbuhan dan beradaptasi dengan perubahan.
Tapi akumulasi konten baru pada akhirnya akan membutuhkan re
pemeriksaan prinsip-prinsip pengorganisasian yang digunakan di situs. Untuk
contoh, arsitektur yang memungkinkan pengguna untuk membuka halaman melalui pers
rilis hari demi hari mungkin baik-baik saja ketika Anda hanya memiliki beberapa
bulan, tetapi mengaturnya berdasarkan topik mungkin lebih praktis
kal setelah beberapa tahun.
Seluruh pengalaman pengguna, termasuk struktur situs, adalah
dibangun di atas pemahaman tentang tujuan Anda dan kebutuhan
pengguna. Jika apa yang ingin Anda capai dengan situs ini didefinisikan ulang atau
kebutuhan yang Anda inginkan untuk dipenuhi oleh situs, bersiaplah untuk mengerjakan ulang
struktur situs Anda sesuai. Kebutuhan akan struktur seperti itu
perubahan jarang mengumumkan dirinya terlebih dahulu; sering, oleh
waktu Anda dapat mengatakan bahwa Anda perlu mengerjakan ulang arsitektur, Anda
pengguna sudah menderita.

Mudah beradaptasi arsitektur
bisa mengakomodasi
penambahan konten baru
dalam satu bagian (atas)

dan juga baru
bagian (bawah).
Pendekatan Arsitektur
Unit dasar dari struktur informasi adalah node. Sebuah simpul dapat
sesuai dengan bagian atau kelompok informasi apa pun — itu bisa sekecil
sebagai nomor tunggal (seperti harga produk) atau sebesar seluruh perpustakaan. Dengan
berurusan dengan node daripada dengan halaman, dokumen
atau komponen, kita dapat menerapkan bahasa yang sama dan seperangkat konsep struktural
yang sama untuk beragam masalah.
Abstraksi node juga memungkinkan kita untuk secara eksplisit mengatur tingkat detail yang
akan kita perhatikan. Sebagian besar proyek arsitektur situs Web
dll hanya berkaitan dengan pengaturan halaman di situs; dengan mengidentifikasi
halaman sebagai simpul tingkat dasar kami, kami membuatnya eksplisit
bahwa kita tidak akan berurusan dengan sesuatu yang lebih kecil. Jika halaman itu sendiri adalah
terlalu kecil untuk proyek yang ada, kita dapat memiliki setiap node yang sesuai ke
seluruh bagian situs. Jika halaman terlalu besar, kita dapat menentukan node sebagai
elemen konten individual dalam halaman, dan halaman
sebagai kumpulan node.
Node-node ini dapat diatur dengan berbagai cara, tetapi ini
struktur benar-benar jatuh ke dalam hanya beberapa kelas umum.
Dalam struktur hierarki —terkadang disebut pohon atau hub-dan
struktur bicara —simpul memiliki hubungan orang tua/anak dengan yang lain node
terkait. Node anak mewakili konsep yang lebih sempit dalam
kategori yang lebih luas diwakili oleh simpul induk. Tidak setiap simpul memiliki
anak, tetapi setiap simpul memiliki induk, yang mengarah ke atas ke simpul induk
dari seluruh struktur (atau akar pohon,
jika kamu memilih). Karena konsep hubungan hierarkis adalah
dipahami dengan baik oleh pengguna dan karena perangkat lunak cenderung bekerja dalam
hierarki, jenis struktur ini adalah yang paling jauh
umum.
Struktur hierarki.
Struktur matriks memungkinkan pengguna untuk berpindah dari node ke node
sepanjang dua atau lebih dimensi. Struktur matriks sering digunakan
ful untuk memungkinkan pengguna dengan kebutuhan yang berbeda untuk menavigasi melalui
konten yang sama, karena setiap kebutuhan pengguna dapat dikaitkan dengan satu
sumbu matriks. Misalnya, jika beberapa pengguna Anda benar-benar menginginkan
untuk menelusuri produk berdasarkan warna, tetapi yang lain perlu menelusuri berdasarkan ukuran,
matriks dapat menampung kedua kelompok. Matriks lebih dari
tiga dimensi dapat menyebabkan masalah, namun, jika Anda mengharapkan pengguna
mengandalkannya sebagai alat navigasi utama mereka. Otak manusia
hanya tidak dilengkapi dengan baik untuk memvisualisasikan gerakan dalam empat atau
lebih banyak dimensi.
Struktur matriks.
Struktur organik tidak berusaha mengikuti pola yang konsisten.
Node terhubung bersama berdasarkan kasus per kasus, dan
arsitektur tidak memiliki konsep bagian yang kuat. Struktur organik
bagus untuk menjelajahi serangkaian topik yang hubungannya tidak jelas
atau berkembang. Tetapi struktur organik tidak memberi pengguna a
rasa yang kuat di mana mereka berada dalam arsitektur. jika kamu mau
untuk mendorong perasaan eksplorasi bentuk bebas, seperti pada beberapa
hiburan atau situs pendidikan, struktur organik dapat menjadi
pilihan bagus; namun, ini dapat menghadirkan tantangan jika pengguna Anda membutuhkan
untuk menemukan jalan kembali ke konten yang sama dengan andal.

Struktur organik.
Struktur berurutan adalah yang paling Anda kenal
dari media offline—sebenarnya, Anda sedang mengalaminya sekarang.
Aliran sekuensial bahasa adalah jenis informasi yang paling dasar
arsitektur yang ada, dan fakultas yang dibutuhkan untuk memprosesnya adalah
dibangun langsung ke otak kita. Buku, artikel, audio, dan video adalah
semua dirancang untuk dialami secara berurutan. Sekuensial struktur di
Web paling sering digunakan untuk struktur skala kecil
tures seperti artikel individu atau bagian; sekuensial skala besar
struktur cenderung terbatas pada aplikasi di mana urutan
presentasi konten sangat penting untuk memenuhi kebutuhan pengguna, seperti dalam
bahan instruksional.
Struktur berurutan.
Prinsip Pengorganisasian
Node dalam struktur informasi diatur menurut organisasi
prinsip-prinsip pengayaan. Pada tingkat yang paling dasar, prinsip pengorganisasian
adalah kriteria yang digunakan untuk menentukan node mana yang dikelompokkan bersama-
sama dan yang disimpan terpisah. Prinsip pengorganisasian yang berbeda
ciples akan diterapkan di daerah yang berbeda dan pada tingkat yang berbeda dari situs.
Misalnya, dalam kasus situs informasi perusahaan, kami mungkin
memiliki kategori di dekat bagian atas pohon kami seperti "Konsumen", "Busi
ness,” dan “Investor.” Pada tingkat ini, prinsip pengorganisasian adalah audiens
yang menjadi tujuan konten tersebut. Situs lain mungkin memiliki kategori tingkat
atas seperti "Amerika Utara", "Eropa", dan "Afrika".
Menggunakan geografi sebagai prinsip pengorganisasian adalah salah satu pendekatan untuk
memenuhi kebutuhan audiens global.
Umumnya, prinsip-prinsip pengorganisasian yang Anda terapkan pada tingkat tertinggi el dari
situs Anda terkait erat dengan tujuan produk dan pengguna
kebutuhan. Pada tingkat yang lebih rendah dalam arsitektur, isu-isu khusus untuk con tenda
dan persyaratan fungsional mulai memiliki pengaruh yang lebih besar
pada prinsip-prinsip pengorganisasian yang harus digunakan.
Misalnya, situs dengan konten berorientasi berita akan sering memiliki
kronologi sebagai prinsip pengorganisasian yang paling menonjol. Ketepatan waktu
adalah satu-satunya faktor terpenting bagi pengguna (yang, bagaimanapun juga, melihat ke
situs berita untuk informasi tentang peristiwa terkini, bukan sejarah) serta untuk
pembuat situs (yang harus menekankan ketepatan waktu
konten mereka agar tetap kompetitif).

Pada tingkat berikutnya dalam arsitektur, faktor-faktor lain lebih dekat terikat
dengan konten ikut bermain. Untuk situs berita olahraga, konten dapat dibagi
menjadi beberapa kategori seperti “Baseball”, “Tenis”, dan "Hoki"; situs yang
lebih umum mungkin memiliki kategori seperti

”Berita Internasional”, ”Berita Nasional”, dan ”Berita Lokal”.
Setiap kumpulan informasi—apakah itu terdiri dari dua item,
200, atau 2.000—memiliki struktur konseptual yang melekat. Sebenarnya, itu biasanya
memiliki lebih dari satu. Itu bagian dari masalah yang harus kita
menyelesaikan. Tantangannya bukanlah menciptakan struktur, tetapi menciptakan yang tepat
struktur untuk tujuan kami dan kebutuhan pengguna kami.
Misalnya, situs kita berisi gudang informasi
tion tentang mobil. Salah satu prinsip pengorganisasian yang mungkin adalah mengatur
informasi sesuai dengan berat mobil yang bersangkutan. Jadi
hal pertama yang akan dilihat pengguna adalah informasi tentang

mobil terberat di database kami, lalu yang terberat kedua, dan seterusnya
ke yang paling ringan.
Untuk situs informasi konsumen, ini mungkin cara yang salah
untuk mengatur informasi. Kebanyakan orang, sebagian besar waktu, tidak berkaitan
dengan berat mobil. Mengorganisir informasi
menurut merek, model, atau jenis mobil mungkin akan lebih banyak
cocok untuk audiens ini. Di sisi lain, jika pengguna kami adalah
profesional yang berurusan setiap hari dengan bisnis pengiriman
mobil di luar negeri, bobot menjadi faktor yang sangat penting. Untuk ini orang,
kualitas seperti ekonomi bahan bakar dan jenis mesin dipertimbangkan
mungkin kurang penting, jika mereka penting sama sekali.

Atribut-atribut ini, dalam bahasa ilmu perpustakaan, dikenal sebagai
aspek, dan mereka dapat menyediakan seperangkat pengorganisasian yang sederhana dan fleksibel
prinsip untuk hampir semua konten. Tapi seperti contoh sebelumnya
menunjukkan, menggunakan faset yang salah bisa lebih buruk daripada tidak menggunakan faset
sama sekali. Salah satu tanggapan umum untuk masalah ini adalah memposisikan setiap
aspek yang dapat dibayangkan sebagai prinsip pengorganisasian dan biarkan pengguna memilih
yang penting bagi mereka.
Sayangnya, kecuali jika Anda berurusan dengan informasi yang sangat sederhana
hanya terdiri dari beberapa aspek, pendekatan ini segera mengubah arsitektur
tecture menjadi berantakan berat. Pengguna memiliki begitu banyak pilihan untuk
memilah-milah sehingga tidak ada yang dapat menemukan apa pun. Beban tidak seharusnya
berada di pengguna untuk memilah-milah semua atribut dan memilih apa yang
penting—bebannya ada pada kita. Strategi memberitahu kita apa yang
kebutuhan pengguna, dan ruang lingkupnya memberi tahu kita informasi apa yang akan memenuhinya
kebutuhan. Dalam membuat struktur, kami mengidentifikasi aspek-aspek spesifik dari
bahwa informasi yang akan menjadi yang utama di benak pengguna. sukses
pengalaman pengguna yang sukses adalah pengalaman di mana harapan pengguna adalah
diantisipasi dan diperhitungkan.
Bahasa dan Metadata

Bahkan jika strukturnya adalah representasi akurat yang sempurna dari
cara orang berpikir tentang materi pelajaran Anda, pengguna Anda tidak akan
dapat menemukan jalan mereka di sekitar arsitektur jika mereka tidak dapat di bawah
tahan nomenklatur Anda: deskripsi, label, dan lainnya
terminologi yang digunakan situs. Untuk alasan ini, penting untuk menggunakan
bahasa pengguna Anda dan melakukannya dengan cara yang konsisten. Itu
alat yang kami gunakan untuk menegakkan konsistensi itu disebut terkontrol
kosakata.
Kosakata yang terkontrol tidak lebih dari seperangkat standar
istilah untuk digunakan di situs. Ini adalah area lain di mana penelitian pengguna
sangat penting. Berbicara dengan pengguna dan memahami bagaimana mereka berkomunikasi
nicate adalah cara paling efektif untuk mengembangkan sistem nomenklatur
yang akan terasa alami bagi mereka. Membuat dan mengikuti yang dikendalikan
kosakata yang mencerminkan bahasa pengguna Anda adalah cara terbaik
untuk mencegah jargon internal organisasi Anda merayap ke
situs, di mana itu hanya akan membingungkan pengguna Anda.
Kosakata yang terkontrol juga membantu menciptakan konsistensi di seluruh
isi. Apakah orang yang bertanggung jawab untuk memproduksi konten
duduk tepat di samping satu sama lain atau di kantor di benua yang berbeda, the
kosakata terkontrol menyediakan sumber daya definitif untuk memastikan bahwa
semua orang berbicara dalam bahasa pengguna.
Pendekatan yang lebih canggih untuk mengendalikan kosa kata adalah dengan menciptakan makan
tesaurus. Tidak seperti daftar sederhana istilah yang disetujui, tesau
rus juga akan mendokumentasikan istilah alternatif yang umum digunakan
tetapi tidak disetujui untuk digunakan di situs. Dengan tesaurus, Anda bisa
memetakan jargon internal, steno, istilah slang, atau akronim ke bahasa mereka
rekanan yang disetujui. Tesaurus mungkin juga mencakup tipe lain
hubungan antar istilah, memberikan rekomendasi untuk
istilah yang lebih luas, lebih sempit, atau terkait. Mendokumentasikan hubungan ini
kapal dapat memberi Anda gambaran yang lebih lengkap tentang seluruh jajaran
konsep yang ditemukan dalam konten Anda, yang pada gilirannya dapat menyarankan tambahan
pendekatan arsitektur nasional.
Memiliki kosakata atau tesaurus yang terkontrol dapat sangat membantu
ful jika Anda memutuskan untuk membangun sistem yang menyertakan metadata. Syarat
metadata berarti hanya "informasi tentang informasi." Ini mengacu pada
pendekatan terstruktur untuk menggambarkan bagian konten tertentu.

Misalkan kita sedang berhadapan dengan artikel tentang bagaimana terbaru Anda produk
sedang digunakan oleh pemadam kebakaran sukarela. Beberapa dari metadata untuk
artikel itu mungkin termasuk
. Nama penulis
. Tanggal artikel itu diposting
. Jenis karya (misalnya, studi kasus atau artikel)
. Nama produk
. Jenis produk
. Industri pelanggan (misalnya, kebakaran sukarela
departemen)
. Topik terkait (misalnya, lembaga kota atau
layanan darurat)
Memiliki informasi ini memungkinkan kami untuk mempertimbangkan berbagai kemungkinan
pendekatan arsitektur yang akan sulit (jika tidak benar-benar) mustahil)
untuk diterapkan tanpanya. Singkatnya, lebih detail informasi yang Anda
miliki tentang konten Anda, semakin fleksibel Anda miliki dalam
menyusunnya. Jika layanan darurat tiba-tiba muncul
potensial sebagai pasar baru yang menguntungkan bagi perusahaan untuk berkembang,
memiliki metadata ini akan memungkinkan kami membuat bagian baru dengan cepat
untuk memenuhi kebutuhan para pengguna tersebut dengan konten yang sudah kami miliki.
Tetapi membuat sistem teknis untuk mengumpulkan dan melacak semua meta ini
data tidak akan membantu kami jika data itu sendiri tidak konsisten. Di situlah
kosakata terkontrol masuk Dengan hanya menggunakan satu istilah untuk masing-masing konsep
unik dalam konten Anda, Anda dapat mengandalkan otomatisasi untuk membantu
menentukan hubungan antara elemen konten Anda. Milikmu
situs dapat secara dinamis menautkan semua halaman pada topik tertentu
tanpa ada yang harus melakukan apa pun selain menggunakan yang sama
istilah secara konsisten dalam metadata mereka.


101
Selain itu, metadata yang baik dapat memberikan yang lebih cepat dan lebih dapat diandalkan
cara bagi pengguna Anda untuk menemukan informasi di situs Anda daripada cara yang lengkap
mesin pencari teks dapat menyediakan. Mesin pencari bisa menjadi kuat,
tetapi secara umum mereka sangat, sangat bodoh—Anda memberi mereka serangkaian
karakter, dan mereka cukup banyak mencari string itu
dari karakter. Mereka tidak mengerti apa artinya semua itu.
Menghubungkan mesin pencari Anda dengan tesaurus dan menyediakan
metadata untuk konten Anda dapat membantu membuat mesin lebih pintar. Itu
mesin pencari dapat menggunakan tesaurus untuk memetakan pencarian untuk disal
istilah yang diturunkan ke istilah yang disukai; maka dapat memeriksa metadata untuk
istilah yang disukai itu. Alih-alih tidak mendapatkan hasil sama sekali, pengguna mendapatkan
hasil yang sangat bertarget dan relevan—dan bahkan mungkin beberapa rekomendasi
rekomendasi untuk mata pelajaran terkait lainnya yang mungkin menarik.
Peran dan Proses Tim

Dokumen yang diperlukan untuk menggambarkan struktur situs—mulai dari
detail spesifik nomenklatur dan metadata untuk gambaran besar
arsitektur informasi secara keseluruhan dan desain interaksi—dapat bervariasi
secara substansial tergantung pada kompleksitas proyek. Untuk proyek dll
yang melibatkan banyak konten dalam struktur hierarki, sederhana
garis besar teks dapat menjadi cara yang efektif untuk mendokumentasikan arsitektur.
Dalam beberapa kasus, alat seperti spreadsheet dan database akan ditekan
ke dalam layanan untuk membantu menangkap nuansa arsitektur yang kompleks.
Tetapi alat dokumentasi utama untuk arsitektur informasi atau
desain interaksi adalah diagram. Mewakili struktur visu
ally adalah cara paling efisien bagi kita untuk mengomunikasikan cabang,
kelompok, dan hubungan timbal balik di antara komponen situs kami.

Struktur situs web pada dasarnya adalah hal yang rumit; mencoba
menyampaikan kerumitan ini dengan kata-kata cukup menjamin bahwa tidak
seseorang akan membacanya.
Pada hari-hari awal Web, diagram semacam ini disebut situs
peta; tetapi karena peta situs juga merupakan istilah yang digunakan untuk jenis tertentu
alat navigasi di situs (yang akan Anda baca lebih lanjut di Bab
ter 6), diagram arsitektur sekarang menjadi istilah yang disukai untuk alat yang kami gunakan
secara internal untuk menggambarkan struktur situs.
Diagram tidak harus mendokumentasikan setiap tautan di setiap halaman
di situs Anda. Faktanya, dalam banyak kasus tingkat detail itu hanya berfungsi
untuk membingungkan dan mengaburkan informasi yang benar-benar dibutuhkan tim. Dia
lebih penting untuk mendokumentasikan hubungan konseptual: Kucing mana
ego pergi bersama, dan mana yang tetap terpisah? Bagaimana langkah-langkahnya?
dalam urutan interaksi yang diberikan cocok bersama?
Di awal karir saya, saya mendapati diri saya harus mengekspresikan dasar yang sama struktur
interaksi berulang-ulang dari proyek ke proyek.
Seiring waktu, saya mulai membakukan cara saya mengilustrasikan ide-ide saya
diagram situs saya. Saya memilih satu set bentuk tertentu yang saya gunakan,
dan mendefinisikan apa arti masing-masing bentuk tersebut.
Sistem yang saya buat untuk membuat diagram struktur situs disebut Visual
Kosakata. Sejak saya pertama kali mempostingnya ke Web pada tahun 2000, informasi
Arsitek dan desainer interaksi di seluruh dunia memiliki
mengadopsinya. Anda dapat mempelajari lebih lanjut tentang Kosakata Visual, lihat
contoh diagram, dan unduh alat untuk menggunakannya di situs Web saya:
www.jjg.net/ia/visvocab/.

103
Kosakata Visual
rumah adalah sistem untuk
membuat diagram
arsitektur mulai
dari yang sangat sederhana
(atas) ke sangat kompleks

informasi media produk mendukung (bawah). Lihat
www.jjg.net/ia/
visvocab/ untuk lebih banyak lagi
rincian.
rumah
produk
mengajukan
siaran pers
arsip
kantor
produk
lanjutkan dari:
rumah alur masuk berita terbaru
(2c)
lanjutkan ke:
halaman masuk
(2a)
Daftar anggota
teknis
dokumen
Banyak organisasi mempekerjakan desainer pengalaman pengguna penuh waktu yang
bertanggung jawab atas masalah struktural. Di organisasi lain,
namun, tanggung jawab untuk struktur sering kali berada di pangkuan seseorang secara
default daripada melalui perencanaan sadar. Siapa yang berakhir? bertanggung jawab
atas struktur sering kali bergantung pada budaya organisasi nization atau sifat proyek.
Untuk situs konten-berat atau dalam organisasi di mana membuat a
kehadiran di Web pada awalnya dilihat sebagai aktivitas pemasaran,
tanggung jawab untuk menentukan struktur situs telah
berada dalam pengembangan konten, editorial, atau komunikasi pemasaran
kelompok komunikasi. Jika organisasi secara historis dipimpin
oleh orang-orang teknis atau memiliki budaya internal yang berorientasi teknologi,
tanggung jawab untuk struktur umumnya jatuh ke teknis
manajer proyek yang bekerja di situs Web.
Setiap proyek dapat memperoleh manfaat dari memiliki dedikasi spesialis penuh waktu
disesuaikan dengan masalah struktural. Terkadang orang ini melakukan pekerjaannya desainer
interaksi judul, tetapi yang lain lebih suka disebut sebagai
arsitek informasi. Jangan biarkan judulnya membingungkan Anda — meskipun
memang benar bahwa beberapa arsitek informasi mengkhususkan diri secara eksklusif dalam
menciptakan skema organisasi dan struktur navigasi untuk
situs konten, lebih sering daripada tidak, seorang arsitek informasi akan
memiliki beberapa tingkat pengalaman dengan masalah desain interaksi dan dan
sebaliknya. Karena arsitektur informasi dan desain interaksi
masalah seringkali sangat terkait erat, desainer pengalaman pengguna memiliki

menjadi gelar yang lebih umum untuk seseorang dengan keterampilan ini.
Organisasi Anda mungkin tidak memiliki volume pekerjaan yang berkelanjutan untuk
menjamin mempekerjakan desainer pengalaman pengguna penuh waktu sebagai permanen
anggota staf Anda. Jika sebagian besar upaya pengembangan Web Anda adalah
terbatas untuk menjaga agar konten yang Anda miliki tetap terbarui dan Anda tidak
melakukan banyak pengembangan baru antara proyek desain ulang seluruh situs
setiap beberapa tahun, desainer pengalaman pengguna staf mungkin tidak
cara yang baik untuk menghabiskan uang Anda. Tetapi jika Anda memiliki aliran yang stabil
konten dan fungsionalitas baru yang ditambahkan ke situs Anda, pengguna
desainer pengalaman dapat membantu Anda mengelola proses itu dengan cara
yang paling efektif untuk memenuhi kebutuhan pengguna Anda dan
untuk memenuhi tujuan strategis Anda sendiri.
Apakah Anda memiliki spesialis untuk mengatasi masalah struktural tidak?
penting, tetapi penting bahwa kekhawatiran tersebut ditangani oleh
seseorang. Situs Anda akan memiliki struktur apakah Anda merencanakannya atau tidak
keluar. Situs yang dibangun sesuai dengan rencana struktur yang jelas cenderung
menjadi orang-orang yang membutuhkan perbaikan lebih jarang, menghasilkan kon
crete hasil untuk pemiliknya, dan memenuhi kebutuhan pengguna mereka.

bab 6
Kerangka
Pesawat terbang
Desain Antarmuka, Desain Navigasi, dan

Desain Informasi
Permukaan
Kerangka
Struktur konseptual mulai memberi bentuk pada Struktur
banyak persyaratan yang muncul dari strategi kami

Cakupan
tujuan. Di bidang kerangka, kami lebih menyempurnakan
struktur itu, mengidentifikasi aspek-aspek tertentu dari Strategi
wajah, navigasi, dan desain informasi yang akan
membuat struktur tidak berwujud beton.

108 BAB 6 PENERBANGAN KERANGKA
Mendefinisikan Kerangka
Bidang struktur yang dibahas dalam bab sebelumnya mendefinisikan bagaimana produk kita
akan bekerja; bidang kerangka mendefinisikan bentuk apa itu
fungsionalitas akan mengambil. Selain membahas masalah presentasi yang lebih konkret, bidang
kerangka berhubungan dengan hal-hal yang
melibatkan tingkat detail yang lebih halus. Pada bidang struktur, kami melihat masalah
arsitektur dan interaksi berskala besar; pada
bidang kerangka, keprihatinan kami ada hampir secara eksklusif pada skala yang lebih kecil
dari komponen individu dan hubungan mereka.
Di sisi fungsionalitas, kami mendefinisikan kerangka melalui desain antarmuka— bidang
tombol, bidang, dan antarmuka lainnya yang sudah dikenal
komponen. Tetapi produk informasi memiliki serangkaian masalah yang unik. Desain
navigasi adalah bentuk khusus dari
desain antarmuka yang disesuaikan untuk menyajikan ruang informasi. Akhirnya, melintasi
kedua sisi, kami memiliki desain informasi, presentasi
informasi untuk komunikasi yang efektif.
permukaan
kerangka
struktur
Ketiga elemen ini terikat erat — lebih dari
salah satu elemen lain yang tercakup dalam buku ini. Ini bukan uncom mon
untuk menghadapi masalah desain navigasi yang mulai kabur
ke dalam masalah desain informasi, atau untuk menghadapi pertanyaan tentang desain
informasi yang berubah menjadi masalah desain antarmuka.
Meskipun garis terkadang menjadi kabur, mengidentifikasi ini sebagai
area perhatian yang terpisah membantu kami menilai dengan lebih baik apakah kami telah menetap
pada solusi yang sesuai. Desain navigasi yang baik tidak dapat dikoreksi desain informasi yang
buruk. Jika kita tidak bisa membedakan antara
jenis masalah, kami tidak tahu apakah kami benar-benar menyelesaikannya.
Jika itu melibatkan penyediaan kemampuan bagi pengguna untuk melakukan sesuatu, itu adalah inter
desain wajah. Antarmuka adalah sarana di mana pengguna benar-benar
bersentuhan dengan fungsi yang ditentukan dalam spesifikasi
dan terstruktur dalam desain interaksi.
Jika ini melibatkan penyediaan kemampuan bagi pengguna untuk pergi ke berbagai tempat, itu adalah navigasi
desain gerbang. Arsitektur informasi menerapkan struktur untuk persyaratan
konten yang kami kembangkan; desain navigasinya adalah lensa di mana
pengguna dapat melihat struktur itu, dan merupakan sarana dimana pengguna
dapat bergerak melaluinya.
Jika melibatkan mengkomunikasikan ide kepada pengguna, itu adalah informasi
rancangan. Ini adalah yang terluas dari tiga elemen di pesawat ini,
berpotensi menggabungkan atau menggambar pada aspek hampir semua
yang telah kita lihat sejauh ini di sisi fungsionalitas dan
sisi informasi. Desain informasi melintasi batas
antara fungsionalitas berorientasi tugas dan sistem berorientasi informasi tems karena
baik desain antarmuka maupun desain navigasi tidak dapat sepenuhnya berhasil tanpa
desain informasi yang baik untuk mendukungnya.

Konvensi dan Metafora

Kebiasaan dan refleks adalah dasar dari sebagian besar interaksi kita
dengan dunia — memang, jika kita tidak dapat mengurangi begitu banyak
apa yang kita lakukan untuk refleks, kita akan mencapai jauh lebih sedikit setiap hari.
Dapatkah Anda bayangkan jika mengendarai mobil tidak pernah menjadi lebih mudah dari sebelumnya pertama
kali coba? Kemampuan Anda mengemudi, memasak makanan, atau menggunakan ponsel
—tanpa benar-benar lelah oleh
konsentrasi luar biasa yang dibutuhkan untuk tugas itu—tergantung pada akumulasi banyak
refleks kecil.
Konvensi memungkinkan kita untuk menerapkan refleks-refleks itu dalam berbagai
keadaan. Saya dulu memiliki mobil yang selalu menyebabkan masalah ketika pernah ada
teman saya yang mengendarainya. Ketika mereka menyalakan mobil, hal pertama yang
mereka lakukan adalah mencuci kaca depan. Ini bukan karena mereka mengira kaca depan
kotor (walaupun mungkin demikian); melainkan, itu karena mereka mencoba menyalakan
lampu depan.
Kontrol di mobil saya berbeda dari konvensi mereka sudah

terbiasa.
Telepon adalah contoh bagus lainnya tentang pentingnya konvensi. Dari waktu ke waktu,
produsen telah bereksperimen dengan
penyimpangan dari tata letak tiga kali empat standar untuk tombol pada telepon, seperti
dua baris masing-masing enam tombol, atau tiga baris
dari empat. Pengaturan melingkar masih muncul dari waktu ke waktu, tetapi ini
menjadi semakin langka karena telepon putar aktif
yang menjadi dasar mereka memudar ke dalam kabut pelupaan teknologi.
Sepertinya tata letak seharusnya tidak membuat banyak perbedaan,
tapi memang begitu. Jika Anda mengukur waktu yang dihabiskan pengguna untuk mencoba menghitung
keluar tombol mana yang harus ditekan pada telepon yang tidak standar, itu mungkin berubah
menjadi sesuatu seperti tiga detik per panggilan. Tidak terlalu besar
perbedaan—tetapi bagi pengguna, tiga detik itu tidak hilang begitu saja
waktu. Tiga detik itu dipenuhi dengan frustrasi murni, sebagai
tugas refleksif menjadi sangat lambat hanya karena permadani
konvensi telah ditarik keluar dari bawah kaki pengguna.
Faktanya, matriks angka tiga kali empat telepon sangat bagus
mendarah daging bahwa itu telah menjadi standar untuk perangkat lain yang
tidak ada hubungannya dengan telepon, seperti oven microwave
atau kendali jarak jauh. Menariknya, pad ponsel bukan satu-satunya
standar di area ini: Standar "10-kunci" yang digunakan oleh penambahan lama
mesin, yang membalikkan urutan angka di telepon
keypad, digunakan pada kalkulator, keyboard, ATM, mesin kasir, dan
dalam aplikasi entri data khusus seperti sistem inventaris.
Karena kedua standar menggunakan matriks tiga kali empat, orang dapat
beradaptasi dengan baik dengan relatif mudah, meskipun standar tunggal akan
benar-benar menjadi solusi terbaik dari semuanya.
Ini bukan untuk mengatakan bahwa jawaban untuk setiap masalah antarmuka adalah
kepatuhan budak terhadap konvensi. Sebaliknya, Anda seharusnya menjadi
berhati-hati untuk menyimpang dari konvensi dan hanya melakukannya ketika a
pendekatan yang berbeda menawarkan manfaat yang jelas. Membuat pengguna yang sukses
pengalaman membutuhkan memiliki alasan yang didefinisikan secara eksplisit untuk setiap
pilihan yang Anda buat.
Membuat antarmuka Anda konsisten dengan orang lain seperti pengguna Anda
sudah akrab dengan itu penting, tetapi yang lebih penting adalah
membuat antarmuka Anda konsisten dengan dirinya sendiri. Modus konseptual els untuk
fitur produk Anda dapat membantu Anda memastikan internal

konsistensi. Jika Anda memiliki dua fitur dengan konsep yang sama
model, mereka cenderung memiliki persyaratan antarmuka yang serupa. Menggunakan
konvensi yang sama di kedua tempat memungkinkan pengguna yang akrab
dengan satu untuk beradaptasi dengan cepat ke yang lain.
Meskipun model konseptual untuk fitur berbeda, ide yang
berlaku di berbagai model konseptual harus diperlakukan
sama (jika tidak identik) di mana pun mereka muncul. Konsep seperti
"mulai", "selesai", "kembali", atau "simpan" dapat ditemukan dalam berbagai macam
konteks. Memberikan ini perawatan yang konsisten di seluruh memungkinkan pengguna
menerapkan apa yang sudah mereka ketahui setelah menggunakan bagian lain dari
sistem, membawa mereka ke tujuan mereka lebih cepat dan dengan lebih sedikit kesalahan.
Sama seperti Anda seharusnya tidak mengambil model konseptual yang mendasari Anda
desain interaksi terlalu harfiah, Anda harus menahan dorongan untuk
membangun produk Anda di sekitar serangkaian metafora konkret.
Metafora untuk fitur produk Anda lucu dan menyenangkan, tapi
mereka hampir tidak pernah bekerja sebaik yang seharusnya. Bahkan, mereka
sering tidak bekerja sama sekali.
Dalam beberapa kasus, Anda mungkin cenderung untuk membuat pola desain antarmuka untuk
fungsi tertentu setelah antarmuka objek dunia nyata.
Ingat navigasi Slate di mana Anda dapat "membalik" halaman
seperti di majalah nyata? Sebagian besar antarmuka dan navigasi
perangkat di dunia nyata adalah produk dari kendala
dunia nyata: fisika, sifat-sifat bahan, dan sebagainya. Layar
produk berbasis seperti situs Web dan perangkat lunak lain memiliki sedikit
kendala yang sama.

Menggambar analogi antara fitur situs Anda dan pengalaman
orang-orang di dunia nyata mungkin tampak seperti cara yang baik untuk membantu
orang memahami tentang fitur-fitur tersebut. Namun,
pendekatan semacam ini biasanya mengaburkan sifat fitur
bukannya mengungkapkannya. Meskipun hubungan antara
fitur dan representasi metaforisnya jelas bagi Anda, hanya saja
salah satu dari sejumlah asosiasi yang mungkin diterapkan pengguna Anda—terutama
terutama jika pengguna tersebut berasal dari latar belakang budaya yang berbeda dari
Anda lakukan. Apa arti gambar kecil telepon itu? Akan
itu memungkinkan saya untuk membuat panggilan telepon? Periksa pesan suara saya? Bayar saya
tagihan telepon?
Tentu saja, konten situs Anda harus memberikan beberapa tingkat
konteks untuk membantu pengguna membuat tebakan yang lebih baik tentang fitur apa Anda
metafora dimaksudkan untuk mewakili. Namun semakin beragam
berbagai konten dan fungsionalitas yang Anda tawarkan, semakin tidak dapat diandalkan ini
tebakan menjadi — dan bagaimanapun, beberapa bagian dari audiens Anda adalah
selalu akan salah menebak. Akan lebih baik (dan lebih sederhana)
untuk menghilangkan dugaan itu sama sekali.
Menggunakan metafora secara efektif sebenarnya hanya tentang mengurangi mental
upaya yang diperlukan bagi pengguna untuk berkeliling dan menggunakan fungsionalitas
produk Anda. Memiliki ikon buku telepon untuk mewakili
direktori nomor telepon yang sebenarnya mungkin baik-baik saja; memiliki
gambar kedai kopi untuk mewakili area obrolan Anda sedikit lebih banyak
bermasalah.
Desain antarmuka
Desain antarmuka adalah tentang memilih elemen antarmuka yang tepat untuk tugas yang coba
diselesaikan pengguna dan mengaturnya
di layar dengan cara yang mudah dipahami dan mudah
digunakan. Tugas akan sering membentang di beberapa layar, masing-masing berisi
ing set yang berbeda dari elemen antarmuka bagi pengguna untuk bersaing dengan.
Fungsi mana yang berakhir di layar mana yang merupakan masalah interaksi desain ke
bawah di bidang struktur; bagaimana fungsi-fungsi itu diwujudkan di layar adalah ranah
desain antarmuka.
Antarmuka yang sukses adalah antarmuka di mana pengguna segera memperhatikan hal-hal
penting. Hal-hal yang tidak penting, di sisi lain, tidak
diperhatikan—terkadang karena tidak ada sama sekali. Salah satu tantangan terbesar dalam
merancang antarmuka untuk sistem yang kompleks adalah
mencari tahu aspek mana yang tidak perlu dihadapi pengguna dan mengurangi visibilitas
mereka (atau mengabaikannya sama sekali).
Untuk orang-orang dengan latar belakang pemrograman, cara berpikir ini mungkin
memerlukan beberapa penyesuaian. Seringkali sangat berbeda dari apa
mereka terbiasa. Pemrogram yang baik selalu memperhitungkan skenario yang paling tidak
mungkin (disebut "kasus tepi" dalam jar pemrograman
pergi). Bagaimanapun, pencapaian tertinggi bagi programmer adalah menciptakan
perangkat lunak yang tidak pernah rusak; tetapi pemrograman yang tidak memperhitungkan
kasus tepi kemungkinan akan melakukan hal itu dalam keadaan ekstrem itu. Jadi
programmer dilatih untuk memperlakukan setiap
kasus sama, apakah itu mewakili satu pengguna atau seribu.
Pendekatan ini tidak bekerja untuk desain antarmuka. Sebuah antarmuka yang memberikan
sejumlah kecil kasus ekstrim bobot yang sama dengan kebutuhan

dari sebagian besar pengguna akhirnya tidak dilengkapi dengan baik untuk membuat
penonton senang. Antarmuka yang dirancang dengan baik mengenali kursus
tindakan yang paling mungkin dilakukan pengguna dan membuat antarmuka tersebut
elemen yang paling mudah diakses dan digunakan.
Ini tidak berarti bahwa solusi untuk setiap masalah antarmuka adalah
untuk membuat tombol, pengguna kemungkinan besar akan menekan yang terbesar.
Desain antarmuka dapat menggunakan berbagai trik untuk memudahkan pengguna
jalan menuju tujuan mereka. Salah satu trik sederhana adalah memikirkannya dengan hati-hati
opsi default yang dipilih saat antarmuka pertama kali disajikan
pengguna. Jika pemahaman Anda tentang tugas dan sasaran pengguna Anda mengarah
Anda berpikir kebanyakan dari mereka lebih suka hasil pencarian yang mendetail daripada
yang singkat, biarkan kotak centang Perlihatkan Saya Lebih Detail dicentang oleh
default berarti lebih banyak orang secara otomatis akan senang dengan apa
mereka dapatkan, terlepas dari apakah mereka meluangkan waktu untuk membaca labelnya
pada kotak centang dan membuat keputusan untuk diri mereka sendiri. Lebih baik lagi adalah
sistem yang secara otomatis mengingat opsi yang dipilih pengguna
terakhir kali mereka mampir, tetapi ini terkadang membutuhkan lebih banyak
akrobat teknis daripada yang tampak diperlukan di permukaan,
dan akibatnya tidak praktis untuk diterapkan oleh beberapa tim pengembangan
berhasil.
Alat dan kerangka kerja teknologi memiliki konteks teknis yang melekat
strain yang membatasi opsi antarmuka yang tersedia bagi kami. Ini adalah tindakan
sekutu baik buruk maupun baik. Itu buruk karena membatasi peluang kita untuk
inovasi—beberapa pendekatan antarmuka yang mungkin dilakukan
menggunakan teknologi tertentu mungkin tidak mungkin diwujudkan dengan yang lain
er. Tapi situasi ini juga bagus, karena pengguna yang belajar caranya
untuk bekerja dengan seperangkat kontrol standar yang cukup kecil dapat menerapkannya
pengetahuan di berbagai produk.

Konvensi antarmuka sepertinya tidak boleh berubah, tetapi mereka

lakukan, jika sangat lambat. Teknologi baru terkadang membawa kebutuhan untuk
memeriksa kembali konvensi yang ada atau membuat beberapa yang baru.
Desainer pengalaman pengguna terus mencari konvensi baru untuk teknologi
seperti kontrol gestur dan perangkat layar sentuh. Paling
kontrol standar yang kami lihat di berbagai layar berbasis
produk yang berasal dari sistem operasi komputer desktop seperti MacOS
atau Windows. Sistem operasi ini menawarkan beberapa elemen antarmuka
standar:
Kotak centang memungkinkan pengguna untuk memilih opsi secara independen dari satu
lain.
Tombol radio memungkinkan pengguna untuk memilih satu opsi dari antara satu set
dari pilihan yang saling eksklusif.
Bidang teks memungkinkan pengguna—menunggunya—memasukkan teks.

Daftar dropdown menyediakan fungsi yang sama seperti tombol radio,
tetapi mereka melakukannya di ruang yang lebih kompak, memungkinkan lebih banyak lagi
pilihan untuk disajikan secara efisien.
Kotak daftar menyediakan fungsionalitas yang sama seperti kotak centang, tetapi mereka
melakukannya di ruang yang lebih ringkas (karena kotak daftar bergulir). Seperti dropdown, ini
memungkinkan kotak daftar dengan mudah mendukung sejumlah besar opsi.
Tombol tindakan dapat melakukan banyak hal berbeda. Biasanya, mereka memberi tahu sistem
untuk mengambil semua informasi lain yang dimiliki pengguna
disediakan melalui elemen antarmuka lain dan lakukan sesuatu—ambil
tindakan—dengan itu.
Beberapa teknologi menyediakan kumpulan elemen dasar yang sama ini, tetapi jangan
memaksa desainer untuk tetap menggunakannya, memungkinkan tingkat yang lebih besar
fleksibilitas dalam bagaimana antarmuka dapat merespons pengguna. Menipu
secara berurutan, antarmuka ini melibatkan lebih banyak pilihan yang harus dibuat
selama proses desain, dan mereka cenderung lebih sulit untuk diperbaiki.
Daftar dropdown dapat
menghalangi pengguna dengan
menyembunyikan opsi penting dari
tampilan (kiri). Radio
tombol dengan mudah
menampilkan semua opsi yang
tersedia (kanan), tetapi mereka
mengambil lebih banyak ruang di

Menyulap semua elemen antarmuka yang berbeda dan memilih dari di
antarmuka.
antara mereka pasti melibatkan trade-off. Benar, tarik-turun itu akan
menghemat ruang di layar relatif terhadap satu set radio
tombol, tetapi juga akan menyembunyikan pilihan yang tersedia dari pengguna.
Membuat orang mengetik dalam kategori yang ingin mereka cari mungkin
memberi lebih sedikit beban pada database, tetapi memberi lebih banyak beban pada pengguna; jika
hanya ada enam untuk dipilih, mungkin beberapa kotak centang akan
lebih baik.
Desain Navigasi
Merancang navigasi untuk Web tampak seperti bisnis sederhana: Put
link pada setiap halaman yang memungkinkan pengguna untuk berkeliling di situs. Jika kamu
menggores permukaan, bagaimanapun, kompleksitas desain navigasi menjadi jelas.
Desain navigasi situs mana pun harus memenuhi
plish tiga tujuan simultan:
. Pertama, itu harus memberi pengguna sarana untuk mendapatkan dari satu menunjuk
ke yang lain di situs. Karena biasanya tidak praktis
cal (dan bahkan ketika praktis, itu umumnya bukan ide yang baik)
untuk menautkan ke setiap halaman dari setiap halaman lainnya, elemen navigasi
harus dipilih untuk memfasilitasi perilaku pengguna nyata—
dan omong-omong, itu berarti tautan itu harus benar-benar
bekerja juga.
. Kedua, desain navigasi harus mengkomunikasikan hubungan antar elemen yang dikandungnya.
Itu tidak cukup
untuk hanya memberikan daftar tautan. Apa hubungan tautan itu satu sama lain?
Apakah beberapa lebih penting daripada yang lain?
Apa perbedaan yang relevan di antara mereka? Kom ini
komunikasi diperlukan bagi pengguna untuk memahami pilihan apa tersedia
untuk mereka.
. Ketiga, desain navigasi harus mengkomunikasikan hubungan
mengirimkan antara kontennya dan halaman yang sedang dilihat pengguna. Apa hubungan
semua ini dengan apa?
Aku sedang melihat sekarang? Mengkomunikasikan hal ini membantu pengguna memahami
mana dari pilihan yang tersedia yang mungkin paling mendukung
tugas atau tujuan yang mereka kejar.
Bahkan untuk produk yang tidak berorientasi informasi—atau bukan Web
situs sama sekali—tiga pertimbangan ini ikut bermain. Kecuali semua fungsi Anda cocok dengan satu
antarmuka, Anda memerlukan beberapa
navigasi untuk membantu pengguna menemukan jalan mereka. Dalam ruang fisik, orang dapat
mengandalkan sampai tingkat tertentu pada arah bawaan untuk
mengorientasikan diri. (Tentu saja, beberapa orang tampaknya terus-menerus tersesat.) Tetapi
mekanisme di otak kita yang membantu kita menemukan
jalan di dunia fisik ("Mari kita lihat, saya pikir pintu masuk tempat saya masuk harus berada di
belakang saya dan ke kiri") benar-benar
tidak berguna dalam membantu kita menemukan jalan di sekitar ruang informasi.
Itulah mengapa sangat penting bahwa setiap halaman situs Web
berkomunikasi dengan jelas kepada pengguna di mana mereka berada di situs dan ke mana mereka
dapat pergi. Sejauh mana pengguna mengorientasikan diri mereka dalam informasi
ruang adalah masalah perdebatan: Beberapa orang sangat menyukai gagasan bahwa pengguna
membuat peta kecil di kepala mereka ketika mereka berkunjung
Situs web, seperti yang mereka lakukan di toko perangkat keras dan perpustakaan; yang lain
mengklaim pengguna hampir sepenuhnya bergantung pada navigasi dan wayfind
ing isyarat di depan mereka, seolah-olah setiap langkah yang mereka ambil melalui situs
memudar dari ingatan mereka tak lama setelah mereka meminumnya.
Sulit bagi kita untuk mengetahui bagaimana (atau berapa banyak) orang menyimpannya
struktur situs Web di kepala mereka. Tanpa pengetahuan itu,
pendekatan terbaik adalah dengan mengasumsikan bahwa pengguna tidak membawa pengetahuan dengan
mereka dari halaman ke halaman. (Lagi pula, jika mesin pencari publik seperti
Google mengindeks situs Anda, halaman apa pun bisa menjadi titik masuk ke . Anda
situs pula.)
Sebagian besar situs sebenarnya menyediakan beberapa sistem navigasi, masing- masing
memenuhi peran tertentu dalam memungkinkan pengguna untuk menavigasi situs
berhasil dalam berbagai situasi. Beberapa jenis umum dari
sistem navigasi bermunculan dalam praktik.
Navigasi global.
Navigasi global menyediakan akses ke sapuan luas seluruh
lokasi. Penggunaan istilah global di sini tidak serta merta menyiratkan bahwa navigasi ini muncul
di setiap halaman situs—walaupun itu
bukan ide yang buruk. (Kami menggunakan istilah persisten untuk merujuk pada elemen
navigasi yang muncul di seluruh situs; sekali lagi, perlu diingat bahwa
elemen persisten belum tentu global.) Sebaliknya, navigasi global menyatukan set kunci titik
akses yang pengguna
mungkin perlu berpindah dari satu ujung situs ke ujung lainnya. Navigasi

121
bilah yang menghubungkan ke semua bagian utama situs adalah contoh klasik
navigasi global. Ke mana pun Anda ingin pergi, Anda bisa mendapatkannya sana
(akhirnya) dengan navigasi global.
Navigasi lokal.
Navigasi lokal memberi pengguna akses ke apa yang "terdekat"
dalam arsitektur. Dalam arsitektur hierarkis yang ketat, navigasi lokal mungkin
menyediakan akses ke induk halaman, saudara kandung, dan
anak-anak. Jika arsitektur Anda dibuat untuk mencerminkan cara berpikir pengguna
tentang konten situs, navigasi lokal biasanya akan
mendapatkan lebih banyak penggunaan daripada sistem navigasi lainnya.
Tambahan
navigasi.
Navigasi tambahan menyediakan pintasan ke konten terkait
yang mungkin tidak mudah diakses melalui navigasi global atau lokal
gerbang. Jenis skema navigasi ini menawarkan beberapa keuntungan
klasifikasi segi dibahas dalam Bab 5 (memungkinkan pengguna untuk
mengalihkan fokus eksplorasi konten mereka tanpa memulai
di awal), sambil tetap mengizinkan situs untuk mempertahankan a
terutama arsitektur hierarkis.

Navigasi kontekstual.
Navigasi kontekstual (terkadang disebut navigasi sebaris) tertanam dalam konten halaman itu
sendiri. Jenis ini
navigasi—misalnya, hyperlink di dalam teks halaman—sering kali kurang dimanfaatkan atau
disalahgunakan. Saat mereka membaca teks
sering kali saat pengguna memutuskan bahwa mereka membutuhkan informasi tambahan. Alih-alih
memaksa pengguna Anda untuk memindai halaman untuk
elemen navigasi yang tepat—atau lebih buruk lagi, mengirim mereka bergegas ke mesin pencari—mengapa tidak
meletakkan tautan yang relevan di sana?
Mencapai semua jalan kembali ke bidang strategi, semakin baik Anda memahami pengguna Anda dan
kebutuhan mereka, semakin efektif Anda
dapat menggunakan navigasi kontekstual. Jika tidak jelas mendukung tugas dan tujuan pengguna
Anda—jika teks Anda penuh dengan begitu banyak
hyperlink yang tidak dapat dipilih oleh pengguna yang relevan dengan kebutuhan mereka—
navigasi kontekstual akan (benar) dilihat sebagai kekacauan.
Navigasi kesopanan menyediakan akses ke item yang tidak dibutuhkan pengguna secara teratur,
tetapi biasanya disediakan sebagai con
Venesia. Di dunia fisik, toko ritel biasanya akan memposting jam operasinya di pintu
masuknya. Untuk sebagian besar pelanggan, sebagian besar
waktu, informasi ini tidak terlalu membantu: Siapa saja dapat mengetahui dengan cepat apakah
toko buka untuk bisnis atau tidak. Tapi mengetahui
bahwa informasi yang tersedia membantu mereka ketika mereka membutuhkannya. Tautan ke
informasi kontak, formulir umpan balik, dan kebijakan
pernyataan biasanya ditemukan dalam navigasi kesopanan.


123
Navigasi sopan.
Beberapa perangkat navigasi tidak tertanam di dalam struktur halaman
Anda, tetapi berdiri sendiri, terlepas dari kontennya
atau fungsionalitas situs Anda. Ini adalah alat navigasi jarak jauh
yang digunakan pengguna ketika mereka merasa frustrasi dengan navigasi lain sistem
nasional yang Anda berikan, atau ketika mereka melihatnya
sistem navigasi Anda dan dengan cepat sampai pada kesimpulan bahwa mereka
lebih baik bahkan tidak mencoba untuk mencari tahu mereka.
Peta situs adalah alat navigasi jarak jauh umum yang memberi pengguna
ringkas, snapshot satu halaman dari keseluruhan arsitektur situs. Situs peta
biasanya disajikan sebagai garis besar hierarki situs, pro
memberikan tautan ke semua bagian tingkat atas dengan tautan ke detik utama bagian
level yang menjorok di bawahnya. Peta situs biasanya tidak muncul lebih dari dua
tingkat hierarki — di luar itu lebih detail
dari yang biasanya dibutuhkan pengguna (dan jika tidak, mungkin ada sesuatu salah
dengan arsitektur tingkat tinggi Anda).
Indeks adalah daftar topik berdasarkan abjad dengan tautan ke yang relevan
halaman, seperti indeks di bagian belakang buku. Jenis alat ini
paling efektif untuk situs yang memiliki banyak konten yang mencakup beragam mata
pelajaran. Dalam kebanyakan kasus lain, peta situs dan sumur arsitektur yang
direncanakan harus memadai. Indeks terkadang dikembangkan untuk masing-masing
bagian situs, daripada mencoba
untuk menutupi seluruh isi situs; pendekatan ini dapat
berguna ketika Anda memiliki bagian yang dimaksudkan untuk melayani audiens yang berbeda
dengan kebutuhan informasi yang berbeda.

Desain Informasi
Desain informasi bisa jadi sulit untuk dilakukan. Tapi itu sering berfungsi sebagai lem yang
menahan komponen lain dari
desain bersama. Dalam semua kasus, desain informasi bermuara pada pengambilan keputusan
tentang bagaimana menyajikan informasi sehingga orang
dapat menggunakannya atau memahaminya dengan lebih mudah.
Terkadang desain informasi bersifat visual. Apakah diagram lingkaran adalah cara terbaik?
untuk menyajikan data itu, atau akankah diagram batang berfungsi lebih baik untuk pengguna kami?
Apakah ikon teropong cukup menyampaikan konsep pencarian?
ing situs, atau kaca pembesar akan lebih dipahami?
Terkadang desain informasi melibatkan pengelompokan atau pengaturan potongan
informasi. Kami sering menganggap remeh aspek desain ini karena kami terbiasa melihat
informasi umum
dikelompokkan dengan cara-cara tertentu. Misalnya, lihat daftar item ini:
. Negara
. Judul pekerjaan
. Nomor telepon
. alamat jalan
. Nama
. Kode Pos
. Organisasi
. Kota
. Alamat email
Tampaknya sedikit membingungkan, karena biasanya terlihat seperti ini:
. Nama
. Judul pekerjaan
. Organisasi
. alamat jalan
. Kota
. Negara
. Kode Pos
. Nomor telepon
. Alamat email
Bahkan pengaturan ini dapat diperjelas lebih lanjut:
. Informasi pribadi
. Nama
. Judul pekerjaan
. Organisasi
. Informasi alamat
. alamat jalan
. Kota
. Negara
. Kode Pos
. Informasi kontak lainnya
. Nomor telepon
. Alamat email
Contoh ini tampaknya cukup mudah, tetapi sedikit berbeda
daftar item akan terbukti lebih menantang:
. Batas daya
. Ukuran rotor
. Kapasitas tangki
. Tipe transmisi
. Kecepatan sudut rata-rata
. Gaya sasis
. Keluaran maksimum
Kuncinya, tentu saja, adalah mengelompokkan dan mengatur elemen informasi
dengan cara yang mencerminkan cara berpikir pengguna Anda dan mendukung tugas mereka
dan tujuan. Hubungan konseptual antara elemen-elemen ini
benar-benar merupakan arsitektur informasi tingkat mikro; informasi
desain ikut bermain ketika kita harus mengomunikasikan struktur itu di
halaman.
Desain informasi berperan dalam masalah desain antarmuka karena antarmuka
tidak hanya harus mengumpulkan informasi dari pengguna, tetapi
mengkomunikasikan informasi kepada pengguna juga. Pesan kesalahan adalah masalah
desain informasi klasik dalam menciptakan antarmuka yang sukses; memberikan
informasi instruksional adalah satu lagi, jika hanya karena tantangan terbesar adalah
membuat pengguna benar-benar membaca instruksinya
tion. Setiap saat sistem harus memberikan beberapa informasi kepada pengguna bagi
mereka untuk menggunakan antarmuka dengan sukses — apakah itu karena mereka
membuat kesalahan atau karena mereka baru memulai—itu
masalah desain informasi.

Pencarian jalan
Salah satu fungsi penting yaitu desain informasi dan navigasi
desain bekerja sama untuk melakukan mendukung wayfinding—
membantu orang memahami di mana mereka berada dan ke mana mereka dapat pergi. Ide
wayfinding berasal dari desain ruang publik di
dunia fisik. Taman, toko, jalan, bandara, dan tempat parkir
semua manfaat dari penggabungan perangkat wayfinding. Taman
ing garasi, misalnya, kadang-kadang akan menggunakan kode warna untuk memberi
isyarat orang untuk membantu mereka mengingat di mana mereka meninggalkan mobil mereka. Di
bandara, tanda, peta, dan indikator lainnya membantu orang menemukan
jalan sekitar.
Di situs Web, wayfinding biasanya melibatkan kedua desain navigasi
dan desain informasi. Sistem navigasi yang digunakan oleh sebuah situs
tidak hanya harus menyediakan akses ke berbagai area situs,
mereka juga harus mengomunikasikan pilihan-pilihan itu dengan jelas. Cara yang baik
temuan memungkinkan pengguna untuk dengan cepat mendapatkan gambaran mental tentang di mana mereka
adalah, ke mana mereka bisa pergi, dan pilihan mana yang akan mendekatkan mereka
tujuan mereka.
Komponen desain informasi dari wayfinding melibatkan elemen halaman
yang tidak menjalankan fungsi navigasi. Misalnya saja
seperti di garasi parkir, beberapa situs Web telah sangat sukses
dalam menggunakan kode warna untuk menunjukkan bagian mana yang dilihat pengguna.
(Namun, kode warna hampir tidak pernah digunakan dengan sendirinya—sebaliknya, itu
memperkuat sistem pencarian jalan lain juga di tempat.) Ikon, label
sistem, dan tipografi adalah pilihan desain informasi lainnya
terkadang digunakan untuk membantu memperkuat rasa "Anda di sini" bagi pengguna.
128 BAB 6 TENGKORAK PESAWAT
Gambar rangka
Tata letak halaman adalah tempat desain informasi, desain antarmuka, dan desain navigasi bersatu
untuk membentuk kerangka yang terpadu dan kohesif
eton. Tata letak halaman harus menggabungkan semua berbagai sistem navigasi, masing- masing
dirancang untuk menyampaikan pandangan arsitektur yang berbeda
masa depan; semua elemen antarmuka yang diperlukan oleh fungsionalitas apa pun di
halaman; dan desain informasi yang mendukung keduanya, sebagai
serta desain informasi dari konten halaman itu sendiri.
Ini banyak untuk menyeimbangkan sekaligus. Itu sebabnya tata letak halaman tercakup dalam
detail dalam dokumen yang disebut skema halaman atau gambar rangka. Gambar rangka adalah
penggambaran tanpa tulang (seperti namanya) dari semuanya
komponen halaman dan bagaimana mereka cocok bersama-sama.
Pengambilan gambar rangka
semua kerangka
NAV
LOGO
keputusan dalam satu dokumen
NAV GLOBAL
yang melayani
sebagai referensi untuk CARA PENEMUAN CARA
pekerjaan desain visual dan

PERMINTAAN PENCARIAN
GRAFIS KEPALA
implementasi situs.
Wireframe bisa tarik-turun

LOKAL Kemasi kotak saya dengan lima lusin kendi minuman keras.
mengandung berbagai tingkat Bagaimana katak lompat silet bisa naik level enam pesenam bidang teks
NAV gelisah! Kami tidak suka bertukar
detail—ini adalah
pekerjaan banyak ukuran bervariasi dari seperempat ke atas. Pekerjaan itu
tombol
membutuhkan keberanian dan semangat ekstra dari setiap penerima upah
cukup ringan.
muda.
ISI MITRA
Sebotol minyak yang dicampur dengan seng oksida
menghasilkan cat yang sangat cerah. Enam besar juicy steak Pekerjaan itu membutuhkan ekstra
mendesis di wajan saat lima pekerja pergi tambang. Musik memetik dan semangat dari setiap
kotak juke membingungkan pengunjung lembut dari kota pencari nafkah muda. SEBUAH quart
lembah kuno.
SUP. NAV jar minyak dicampur dengan seng
oksida membuat sangat

Kemasi kotak saya dengan lima lusin kendi minuman keras.
cat cerah. Kemas kotak saya
Bagaimana katak lompat silet bisa naik level enam pesenam
dengan lima lusin kendi minuman keras.
gelisah!
NAV
Gambar garis sederhana ini biasanya banyak diberi anotasi, mengacu
pembaca ke diagram arsitektur atau desain interaksi lainnya dokumentasi,
persyaratan konten atau spesifikasi fungsional,
atau jenis dokumentasi terperinci lainnya sesuai kebutuhan. Sebagai contoh, jika
gambar rangka merujuk ke elemen konten tertentu yang ada, itu mungkin memberikan
petunjuk ke tempat mereka dapat ditemukan. Selain itu, kawat bingkai akan sering
berisi catatan tambahan tentang perilaku yang dimaksudkan itu mungkin tidak jelas
hanya dengan melihat gambar rangka dan
diagram arsitekturnya.
Dalam banyak hal, diagram arsitektur yang kita lihat kembali di struktur
pesawat masa depan adalah visi besar untuk proyek tersebut; di sini di kerangka
pesawat, gambar rangka adalah dokumen terperinci yang menunjukkan betapa visi itu
akan terpenuhi. Wireframes terkadang akan lentur
disebutkan oleh spesifikasi navigasi yang komprehensif, menjelaskan dalam lebih
detail komposisi yang tepat dari masing-masing berbagai naviga komponen
nasional.
Untuk produk yang lebih kecil atau kurang kompleks, satu wireframe saja sudah cukup cient
untuk dijadikan sebagai template untuk semua layar yang akan dibangun. Untuk banyak
proyek, namun, beberapa gambar rangka diperlukan untuk menyampaikan kompleksitas hasil
yang diinginkan. Anda mungkin tidak perlu
wireframe untuk setiap layar, namun. Sama seperti pro arsitektur
cess memungkinkan kami untuk mengklasifikasikan elemen konten ke dalam kategori luas
atau jenis, sejumlah kecil layar standar akan muncul
dari pengembangan wireframe, berdasarkan fungsional atau naviga
keragaman nasional produk Anda.
Wireframes adalah langkah pertama yang diperlukan dalam proses formal
membangun desain visual untuk situs, tetapi hampir semua orang
terlibat dalam proses pengembangan akan menggunakannya di beberapa titik.

130 BAB 6 TENGKORAK PESAWAT
Orang yang bertanggung jawab atas strategi, ruang lingkup, dan struktur dapat merujuk ke:
gambar rangka untuk mengonfirmasi bahwa produk akhir akan memenuhi mereka
harapan. Orang yang bertanggung jawab untuk benar-benar membangun produk
dapat merujuk ke gambar rangka untuk menjawab pertanyaan tentang bagaimana situs
harus berfungsi.
Wireframe, menjadi tempat di mana arsitektur informasi dan
desain visual datang bersama-sama, sering menjadi bahan perdebatan dan perdebatan
pute. Desainer pengalaman pengguna mengeluh bahwa desainer visual yang
buat gambar rangka mengaburkan arsitektur mereka di belakang navigasi
sistem yang tidak mencerminkan prinsip-prinsip yang mendasari arsitektur
tur. Desainer visual mengeluh bahwa gambar rangka diproduksi oleh pengguna
desainer berpengalaman mengurangi peran mereka menjadi cat-by-numbers
seniman, menyia-nyiakan pengalaman dan keahlian dalam komunikasi visual
nication mereka membawa ke masalah desain informasi.
Ketika Anda memiliki desainer pengalaman pengguna dan visual yang terpisah
desainer, satu-satunya cara untuk menghasilkan gambar rangka yang sukses adalah melalui
kolaborasi. Proses harus mengerjakan detail dari
wireframe bersama-sama memungkinkan masing-masing pihak untuk melihat masalah dari pihak lain
sudut pandang, dan dapat membantu mengungkap masalah di awal proses
(bukannya nanti, ketika produk sedang dibuat dan semua orang
bertanya-tanya mengapa itu tidak bekerja seperti yang direncanakan).
Semua ini membuat gambar rangka terdengar seperti banyak pekerjaan. Mereka
tidak harus. Dokumentasi tidak pernah menjadi tujuan itu sendiri; itu hanya
sarana untuk mencapai tujuan. Membuat dokumentasi untuk kepentingannya sendiri bukanlah
hanya membuang-buang waktu—itu bisa menjadi kontraproduktif dan demoral
ukuran. Memproduksi tingkat dokumentasi yang tepat untuk kebutuhan Anda—
dan tidak membodohi diri sendiri bahwa Anda bisa bertahan dengan lebih sedikit — giliran
dokumentasi dari suatu masalah menjadi suatu keuntungan.

Beberapa wireframe paling sukses yang pernah saya tangani memiliki
tidak lebih dari sketsa pensil dengan catatan tempel terlampir.
Untuk tim kecil tempat desainer dan programmer duduk
tepat di samping satu sama lain, tingkat dokumentasi itu sempurna memadai.
Tetapi ketika pemrograman adalah tanggung jawab keseluruhan tim dan bukan
hanya satu orang — dan tim itu berada di tengah jalan dunia—sesuatu yang
sedikit lebih formal mungkin dibutuhkan.
Nilai wireframes adalah cara mereka mengintegrasikan ketiga elemen dari
bidang struktur: desain antarmuka, melalui pengaturan
dan pemilihan elemen antarmuka; desain navigasi, melalui
identifikasi dan definisi sistem navigasi inti; dan
desain informasi, melalui penempatan dan prioritas komponen
informasi. Dengan menyatukan ketiganya menjadi
dokumen tunggal, gambar rangka dapat menentukan kerangka yang dibangun pada
struktur konseptual yang mendasarinya sambil menunjukkan jalan
maju ke arah desain permukaan.

bab 7
Permukaan
Pesawat terbang
Desain Sensorik
Permukaan
Kerangka
Di bagian atas model lima bidang, kami mengalihkan perhatian kami Struktur
tion ke aspek-aspek produk pengguna kami akan

Cakupan
perhatikan terlebih dahulu: desain sensorik. Di sini, konten, fungsi
Strategi
nasionalitas, dan estetika datang bersama-sama untuk menghasilkan
desain jadi yang menyenangkan indra sambil memenuhi
semua tujuan dari empat pesawat lainnya.

134 BAB 7 PESAWAT PERMUKAAN
Mendefinisikan Permukaan
Di bidang kerangka, kami terutama berurusan dengan pengaturan. Desain
antarmuka menyangkut pengaturan elemen untuk
memungkinkan interaksi; desain navigasi, pengaturan elemen untuk memungkinkan
pergerakan melalui produk; dan informasi
desain, pengaturan elemen untuk mengkomunikasikan informasi

kepada pengguna.
Pindah ke bidang permukaan, kita sekarang berurusan dengan desain sensorik
dan penyajian pengaturan logis yang
membuat kerangka produk. Misalnya, melalui perhatian pada desain informasi, kami
menentukan bagaimana kami harus mengelompokkan dan
mengatur elemen informasi halaman; melalui perhatian pada desain visual, kami
menentukan bagaimana pengaturan itu seharusnya
disajikan secara visual.
permukaan
kerangka

135
Memahami Perasaan
Setiap pengalaman yang kita miliki—tidak hanya dengan produk dan layanan, tetapi
dengan dunia dan satu sama lain—pada dasarnya datang ke
kita melalui indera kita. Dalam proses desain, ini adalah perhentian terakhir dalam
memberikan pengalaman kepada pengguna kami: menentukan bagaimana segala sesuatu
tentang desain kami akan terwujud ke indra orang. Manakah dari panca indera (penglihatan,
pendengaran, sentuhan, penciuman, dan rasa) kami dapat mempekerjakan tergantung pada
jenis produk yang kami rancang.
Bau dan Rasa

Kecuali untuk makanan, wewangian, atau produk beraroma, bau dan rasa adalah jarang
pertimbangan untuk desainer pengalaman pengguna. Memang benar bahwa orang
terkadang mengembangkan asosiasi yang kuat dengan bau a produk—seperti “bau mobil
baru”, yang telah terbukti sangat populer sehingga dapat ditambahkan sebagai wewangian
lama setelah mobil melampaui
definisi siapa pun tentang "baru"—tetapi bau ini biasanya merupakan hasil dari pilihan
bahan dalam konstruksi produk, bukan
keputusan desainer berpengalaman.
Menyentuh
Pengalaman sentuhan produk fisik terletak dalam ranah
desain industri. Desainer industri terutama memperhatikan keterlibatan fisik
pengguna dengan suatu produk. Ini memerlukan ele
desain antarmuka dan interaksi (seperti pengaturan tombol pada ponsel) tetapi juga
mencakup sensor murni
pertimbangan, seperti bentuk perangkat (bulat? persegi?), tekstur yang digunakan (halus?
kasar?) dan bahan yang digunakan

(plastik? logam?). Berkat perangkat bergetar, pengalaman berbasis layar ences dapat
memiliki dimensi sentuhan juga. Ponsel dan video
pengontrol game sama-sama menggunakan getaran untuk berkomunikasi dengan pengguna.
Pendengaran
Suara memainkan peran dalam pengalaman berbagai jenis produk.
Pikirkan semua bunyi bip dan dengungan yang berbeda di mobil biasa
dan pesan yang mereka kirim: Lampu depan Anda menyala. Sabuk pengaman Anda tidak
diikat. Pintu Anda terbuka, tetapi Anda meninggalkan kunci Anda di igni
tion. Suara dapat digunakan tidak hanya untuk memberi tahu pengguna, tetapi juga untuk mengilhami
produk dengan rasa kepribadian. Misalnya, setiap pengguna TiVo dapat
dengan mudah mengingat berbagai bing, boops, dan gundukan yang menyertainya navigasi
melalui pengalaman TiVo.
Penglihatan
Ini adalah area yang paling banyak dimiliki oleh desainer pengalaman pengguna
kecanggihan, karena desain visual berperan dalam hampir setiap
jenis produk yang ada. Untuk alasan ini, sisa bab ini akan
fokus pada bagaimana desain visual mendukung pengalaman pengguna.
Awalnya, Anda mungkin berpikir desain visual adalah masalah sederhana
tetik. Setiap orang memiliki selera yang berbeda, dan setiap orang memiliki selera yang berbeda
gagasan tentang apa yang membentuk desain yang menarik secara visual, jadi setiap argumen
keputusan desain hanya bermuara pada preferensi pribadi,
Baik? Yah, setiap orang memang memiliki selera estetika yang berbeda, tapi itu tidak
berarti keputusan desain harus didasarkan pada apa yang terlihat keren untuk semua
orang yang terlibat.
Alih-alih mengevaluasi ide-ide desain visual hanya dalam hal apa
tampaknya estetis, Anda harus memusatkan perhatian Anda pada


137
seberapa baik mereka bekerja. Seberapa efektif desain mendukung
tujuan yang ditentukan oleh masing-masing bidang yang lebih rendah? Misalnya, apakah
tampilan produk membuat perbedaan antara bagian dari
arsitektur tidak jelas atau ambigu, merusak struktur? Atau
apakah desain visual memperjelas opsi yang tersedia bagi pengguna, kendalikan
memaksa struktur?
Mengkomunikasikan identitas merek, misalnya, adalah strategi umum
tujuan gic untuk situs Web. Identitas merek muncul di banyak cara—dalam
bahasa yang Anda gunakan atau dalam desain interaksi
fungsionalitas situs—tetapi salah satu alat utama yang digunakan untuk berkomunikasi
identitas merek adalah desain visual. Jika identitas yang ingin Anda sampaikan bersifat teknis
dan otoritatif, menggunakan font buku komik dan cerah
warna pastel mungkin bukan pilihan yang tepat. Ini bukan hanya soal
estetika, ini masalah strategi.
Ikuti Mata
Salah satu cara sederhana untuk mengevaluasi desain visual suatu produk adalah dengan bertanya:
Kemana mata pertama pergi? Apa elemen desain awalnya?
menarik perhatian pengguna? Apakah mereka tertarik pada sesuatu yang penting? dengan
tujuan strategis produk? Atau apakah objek pertama mereka
perhatian gangguan dari tujuan mereka (atau Anda)?
Peneliti terkadang menggunakan peralatan eyetracking yang canggih
untuk menentukan dengan tepat subjek tes apa yang dilihat dan bagaimana mereka mata
bergerak di sekitar layar. Jika Anda hanya menyempurnakan visual
desain produk, bagaimanapun, Anda biasanya dapat lolos dengan sim
bertanya kepada orang-orang—bahkan hanya bertanya pada diri sendiri. Pendekatan ini tidak akan
memberikan hasil yang paling akurat, dan tidak akan pernah menangkap semua
nuansa yang dapat disediakan oleh peralatan eyetracking. Tapi kebanyakan
waktu, hanya mengajukan pertanyaan sangat cocok. Cara lain untuk
temukan elemen desain yang dominan adalah menyipitkan mata ke halaman atau mengaburkan
mata Anda sampai Anda tidak dapat melihat detailnya — atau berjalan ke yang lain
ujung ruangan dan lihat dari sana.
Kemudian cobalah untuk menentukan kemana mata pergi. Jika Anda melayani sebagai Anda
subjek tes sendiri, coba perhatikan gerakan bawah sadar Anda
mata di sekitar halaman. Jangan terlalu memikirkan siapa dirimu
melihat ke; biarkan mata Anda melihat halaman secara alami. Jika seseorang
lain adalah subjek tes Anda, minta mereka untuk menyebutkan elemen-elemen dari
halaman dalam urutan yang menarik perhatian mereka.
Umumnya, Anda akan menemukan pola yang cukup konsisten dalam cara orang bergerak
mata mereka — lagipula, ini sebagian besar tidak disadari, naluriah
gerakan. Jika subjek melaporkan mata mereka mengikuti yang sangat berbeda
pola dari orang lain, mereka mungkin tidak benar-benar menyadarinya
gerakan mata alami, atau mereka hanya memberi tahu Anda apa yang mereka pikirkan
Anda ingin mendengar (atau keduanya).
Jika desain Anda berhasil, pola yang diikuti mata pengguna akan
memiliki dua kualitas penting:
. Pertama, mengikuti arus yang lancar. Ketika orang berkomentar itu
sebuah desain "sibuk" atau "berantakan", mereka benar-benar bereaksi terhadap
fakta bahwa desainnya tidak menuntun mereka dengan lancar halaman.
Sebaliknya, mata mereka memantul bolak-balik di antara
berbagai elemen semua berteriak-teriak untuk perhatian mereka.


139
. Kedua, ini memberi pengguna semacam tur berpemandu tentang kemungkinan
tersedia bagi mereka tanpa membebani mereka dengan detail. Sebagai selalu,
kemungkinan tersebut harus mendukung tujuan dan tugas yang coba diselesaikan
pengguna pada titik ini dalam interaksi mereka
hubungannya dengan produk. Mungkin yang lebih penting, pos itu
sibilities seharusnya tidak mengalihkan perhatian dari informasi atau fungsi yang
pengguna akan perlu untuk memenuhi tujuan tersebut.
Pergerakan mata pengguna di sekitar halaman tidak terjadi dengan
kecelakaan. Ini adalah hasil dari serangkaian respons naluriah yang tertanam dalam terhadap
rangsangan visual yang dimiliki semua manusia. Untung
bagi kami sebagai desainer, respons ini juga tidak sepenuhnya di luar kendali kami—selama berabad-
abad, kami telah mengembangkan berbagai
teknik visual yang efektif untuk menarik dan mengarahkan perhatian.
Kontras dan Keseragaman
Dalam desain visual, alat utama yang kami gunakan untuk menarik perhatian pengguna
tion adalah kontras. Sebuah desain tanpa kontras terlihat sebagai massa abu-abu, tanpa ciri,
menyebabkan mata pengguna melayang-layang tanpa
menetap pada sesuatu yang khusus. Kontras sangat penting untuk menarik perhatian pengguna ke
aspek penting dari antarmuka, kontras membantu
pengguna memahami hubungan antara elemen navigasi pada halaman, dan kontras adalah cara utama
untuk com
mengkomunikasikan kelompok konseptual dalam desain informasi.
Ketika elemen dalam sebuah desain berbeda, pengguna memperhatikan. Mereka
tidak bisa membantu. Anda dapat menggunakan perilaku naluriah ini untuk keuntungan
Anda dengan membuat bagian yang benar-benar dibutuhkan pengguna untuk dilihat menonjol
sisa elemen. Pesan kesalahan di antarmuka Web sering kali
fer dari berbaur dengan sisa halaman; membandingkannya dengan
menempatkan teks dalam warna yang berbeda (seperti, katakanlah, merah) atau sorot mereka
dengan grafik yang berani dapat membuat semua perbedaan.
Dalam tata letak yang netral secara
visual (dekat kanan, atas),
tidak ada yang menonjol.
Kontras dapat digunakan
untuk mengarahkan pandangan
pengguna ke sekitar halaman (paling
kanan, atas) atau menarik perhatian
mereka ke beberapa
elemen kunci (dekat kanan, bawah).
Terlalu sering menggunakan
kontras mengarah ke
tampilan berantakan (paling kanan,
bawah).
Namun, agar strategi ini berhasil, perbedaannya harus signifikan
cukup bagus bagi pengguna untuk dengan jelas mengatakan bahwa pilihan desainnya adalah
dimaksudkan untuk mengkomunikasikan sesuatu. Ketika perawatan desain
dari dua elemen serupa tetapi tidak persis sama, pengguna mendapatkan kon
tergabung. “Mengapa mereka berbeda? Apakah mereka seharusnya sama?
Mungkin itu hanya sebuah kesalahan. Atau apakah saya harus memperhatikan sesuatu
di sini?" Sebagai gantinya, kami ingin menarik perhatian pengguna dan memastikan
mereka bahwa itu disengaja.
Mempertahankan keseragaman dalam desain Anda adalah bagian penting dari
memastikan bahwa desain Anda berkomunikasi secara efektif tanpa kon
menggabungkan atau membanjiri pengguna Anda. Keseragaman berperan dalam
banyak aspek yang berbeda dari desain visual.
Menjaga agar ukuran elemen tetap seragam dapat mempermudah recom
gabungkan mereka ke dalam desain baru saat Anda membutuhkannya. Misalnya, jika semua
tombol grafik yang Anda gunakan untuk navigasi memiliki ketinggian yang sama,
mereka dapat dicampur dan dicocokkan sesuai kebutuhan tanpa membuat ikatan
tata letak tered atau mengharuskan grafik baru diproduksi.
Tata letak berbasis grid merupakan salah satu teknik dari desain cetak yang mengusung lebih
efektif ke Web. Pendekatan ini memastikan keseragaman
desain melalui tata letak master yang digunakan sebagai template untuk kreasi ing variasi
tata letak. Tidak setiap tata letak akan menggunakan setiap bagian dari
kisi—pada kenyataannya, sebagian besar tata letak mungkin hanya akan menggunakan sedikit—tetapi setiap
penempatan elemen di grid harus seragam dan konsisten.

Tata letak berbasis kisi

memastikan bahwa beragam
desain memiliki berbagi

urutan visual.
Namun, karena perangkat, ukuran layar, dan resolusi layar dapat sangat
bervariasi, menerapkan kisi ke desain berbasis layar tidak selalu
sesederhana dalam desain cetak. Sangat mudah untuk jatuh ke dalam perangkap
mengikuti sistem grid—atau standar apa pun yang dimaksudkan untuk memastikan
keseragaman — bahkan ketika itu jelas tidak berfungsi lagi. anar
chy bekerja tanpa standar desain itu buruk, tapi pengekangnya


143
mencoba bekerja dalam standar desain yang tidak memadai untuk
kebutuhan Anda bisa lebih buruk. Mungkin produk telah mengambil yang baru
fungsionalitas yang tidak pernah dibayangkan siapa pun pada saat grid
Dikembangkan; mungkin grid tidak pernah bekerja dengan baik di
posisi pertama. Apapun alasannya, penting untuk bisa
kenali kapan saatnya untuk meninjau kembali dasar-dasar visual Anda sistem
desain.
Konsistensi Internal dan Eksternal

Karena cara situs Web sering dibuat—sedikit demi sedikit,
ad hoc, dan terisolasi dari pekerjaan desain lain yang terjadi di organisasi
nization—mereka telah diganggu dengan masalah konsistensi dalam desain visual.
Masalah-masalah ini mengambil dua bentuk:
. Ada masalah konsistensi internal, di mana perbedaan
bagian dari produk mencerminkan pendekatan desain yang berbeda.
. Lalu ada masalah konsistensi eksternal, di mana
produk tidak mencerminkan pendekatan desain yang sama yang digunakan dalam
produk lain dari organisasi yang sama.
Solusi yang baik untuk masalah konsistensi internal berakar pada
pemahaman tentang kerangka situs. Kuncinya adalah mengidentifikasi tify
elemen desain berulang yang muncul dalam konteks yang berbeda di seluruh
berbagai antarmuka, navigasi, dan informasi
masalah desain pada produk. Dengan mengisolasi setiap elemen desain dari
konteks yang berbeda sebelum mendesainnya, kita bisa lebih
melihat dengan jelas masalah skala kecil yang kami coba selesaikan, alih-alih
terganggu oleh masalah skala besar yang dipaksakan oleh konteks.
Daripada mendesain elemen yang sama berulang-ulang, kami
dapat mendesainnya sekali dan menggunakan desain itu di seluruh produk.

Untuk pendekatan seperti itu untuk bekerja, kita harus memeriksa pekerjaan kita
terhadap konteks yang berbeda di mana elemen itu muncul. Mungkin
tombol STOP besar, bulat, merah akan berfungsi dengan baik untuk halaman checkout, tetapi
mungkin tidak efektif secara visual pada produk yang ramai
halaman kustomisasi. Pendekatan terbaik adalah merancang setiap elemen,
mencobanya dalam berbagai konteks, dan kemudian ulang desain sesuai kebutuhan.
Meskipun banyak elemen desain akan dibuat secara terpisah
tion dari satu sama lain, mereka masih harus bekerja sama. Sebuah kesuksesan
desain bukan hanya kumpulan benda-benda kecil yang dirancang dengan baik;
Sebaliknya, objek harus membentuk sistem yang beroperasi sebagai kohesif,
keseluruhan yang konsisten.
Menegakkan konsistensi desain di seluruh media menghadirkan audio Anda
ence—pelanggan, prospek, pemegang saham, karyawan, atau karyawan biasa
pengamat—dengan kesan seragam identitas merek Anda. Ini
konsistensi identitas merek harus ada di setiap tingkat
desain visual produk Anda, dari elemen navigasi
muncul di setiap layar hingga tombol sederhana yang muncul
hanya sekali.
Menyajikan gaya di situs Web Anda yang tidak sesuai dengan gaya Anda
gaya di media lain tidak hanya mempengaruhi kesan penonton
dari produk itu; itu memengaruhi kesan mereka tentang perusahaan Anda sebagai
utuh. Orang-orang merespons secara positif perusahaan dengan definisi yang jelas
identitas. Gaya visual yang tidak konsisten merusak kejernihan gambar Anda citra
perusahaan dan meninggalkan kesan kepada penonton bahwa
ini adalah perusahaan yang belum cukup tahu siapa itu.


145
Palet Warna dan Tipografi

Warna dapat menjadi salah satu cara paling efektif untuk mengkomunikasikan identitas
merek. Beberapa merek sangat terkait erat dengan warna sehingga sulit memikirkan
perusahaan tanpa warna yang secara otomatis muncul di benak
—pertimbangkan Coca-Cola, UPS, atau Kodak. com ini
panies telah menggunakan warna tertentu (merah, coklat, kuning) secara
konsisten selama bertahun-tahun untuk menciptakan rasa identitas yang lebih kuat dalam pikiran
publik.
Itu tidak berarti mereka menggunakan warna-warna ini dengan mengesampingkan semuanya yang
lain. Warna merek inti biasanya merupakan bagian dari palet warna yang lebih luas
yang digunakan di semua bahan perusahaan. Warna dalam com
palet standar pany dipilih secara khusus untuk seberapa baik mereka bekerja
bersama, saling melengkapi tanpa bersaing.
Palet warna harus menggabungkan warna yang cocok untuk berbagai kegunaan. Dalam
kebanyakan kasus, warna yang lebih cerah atau lebih berani dapat digunakan untuk latar
depan desain Anda—elemen yang ingin Anda tarik perhatiannya. Lebih banyak warna
yang diredam lebih baik digunakan untuk elemen latar belakang yang tidak perlu
melompat dari halaman. Memiliki berbagai warna untuk dipilih memberi kami alat untuk
membuat
pilihan desain yang efektif.
Sama seperti kontras dan keseragaman yang penting untuk area lain dari desain visual,
mereka memainkan peran penting dalam penciptaan palet warna
juga. Ketika digunakan dalam konteks yang sama, warna yang sangat dekat dengan satu
sama lain, tetapi tidak persis sama, merusak efektivitas palet warna Anda. Ini tidak berarti
Anda hanya mendapatkan satu warna merah,

Orbitz telah menggunakan
palet warna terbatas (atas)

untuk membedakan fitur dan
fungsionalitas di situs
r:102 r:0 r:0 r:0 r:255
Web (bawah). g:153 g:102 g:51 g:153 g:153

b:204 b:204 b:153 b:0 b:0
r:255 r:204 r:153 r:51 r:204

g:255 g:204 g:153 g:51 g:204
b:204 b:153 b:102 b:51 b:204
satu warna biru, dan seterusnya. Artinya jika Anda ingin menggunakan dif
nuansa merah yang berbeda, pastikan warnanya cukup berbeda sehingga pengguna
dapat membedakannya, dan pastikan Anda menggunakannya dengan cara yang konsisten.
Untuk beberapa perusahaan, tipografi— penggunaan font atau tipografi untuk
menciptakan gaya visual tertentu—sangat penting bagi merek mereka
identitas bahwa mereka telah menugaskan tipografi khusus untuk menjadi
diproduksi khusus untuk digunakan. Organisasi mulai dari
Apple ke Volkswagen ke London Underground dan bahkan Martha
Stewart telah menggunakan tipografi khusus untuk menciptakan kesan yang lebih kuat tentang identitas
dalam komunikasi mereka. Bahkan jika Anda memilih untuk tidak mengambil
langkah luar biasa ini, tipe masih dapat berfungsi sebagai bagian yang efektif dari
mengkomunikasikan identitas Anda melalui desain visual.
Untuk teks isi—materi apa pun yang akan disajikan dalam blok yang lebih besar
atau yang akan dibaca oleh pengguna dalam jangka waktu yang lebih lama—lebih sederhana lebih baik.
Mata kita cepat lelah mencoba menerima banyak teks dengan lebih banyak
jenis huruf hiasan. Itu sebabnya font sederhana seperti Helvetica atau Times adalah
begitu banyak digunakan. Mereka bukan satu-satunya pilihan Anda; kamu tidak
harus mengorbankan gaya untuk mengakomodasi keterbacaan.
Untuk elemen teks yang lebih besar atau label pendek seperti yang terlihat di naviga
elemen nasional, tipografi dengan sedikit lebih banyak kepribadian adalah per sangat
sesuai. Tapi salah satu tujuan kami bukan untuk membanjiri kami
pengguna dengan kekacauan visual, dan menggunakan variasi yang tidak perlu
font—atau bahkan menggunakan sejumlah kecil font secara tidak konsisten
cara-dapat berkontribusi pada rasa kekacauan itu. Dalam kebanyakan kasus, Anda
tidak perlu lebih dari beberapa font untuk memenuhi semua komunikasi Anda
kebutuhan nikasi.
Prinsip-prinsip menggunakan tipe secara efektif benar-benar sama dengan itu
untuk aspek lain dari desain visual: Jangan gunakan gaya yang terlalu
mirip tapi tidak persis sama. Gunakan gaya yang berbeda hanya untuk indi
temukan perbedaan dalam informasi yang Anda coba komunikasikan.
Berikan kontras yang cukup antara gaya yang dapat Anda gambar
perhatian pengguna sesuai kebutuhan, tetapi jangan membebani desain dengan a
berbagai gaya yang beragam.
Komps Desain dan Panduan Gaya
Analog paling langsung ke wireframe untuk ranah visual
desain adalah mock-up visual atau desain comp. Comp adalah singkatan dari
komposit, karena itulah tepatnya: visualisasi dari
produk jadi dibangun dari komponen yang telah
terpilih. Komp menunjukkan bagaimana semua bagian bekerja sama untuk membentuk
keseluruhan yang kohesif; atau, jika tidak, itu menunjukkan di mana kerusakannya
sedang terjadi dan menunjukkan kendala bahwa solusi apa pun akan harus
memperhitungkan.
Anda harus dapat melihat korelasi satu-ke-satu yang sederhana antara
komponen gambar rangka dan komponen desain
komp. Comp mungkin tidak dengan setia mereproduksi tata letak
wireframe—bahkan, mungkin tidak. Bingkai gambar tidak
memperhitungkan masalah desain visual, dengan fokus pada dokumen
dalam kerangka. Membangun wireframe sebelum kita menangani
design comp memungkinkan kita untuk melihat masalah kerangka secara terpisah terlebih dahulu,
kemudian lihat bagaimana masalah permukaan ikut bermain. Namun demikian, intinya
ide-ide dalam wireframe, khususnya mengenai desain informasi
masalah, harus jelas terlihat dalam desain comps, meskipun
mereka mungkin tidak mengikuti pengaturan yang tepat yang disajikan dalam
bingkai gambar.

149
Desain visualnya
MEREK AREA NAV
LOGO
tidak harus
NAV GLOBAL
cocok dengan gambar rangka
tepatnya—hanya memiliki
untuk memperhitungkan
kepentingan relatif dan
pengelompokan elemen yang

BARANG-BARANG SPESIAL
disajikan dalam
bingkai gambar.
NAV TAMBAHAN
CERITA NASIONAL TOP CERITA LOKAL TOP

Semua dokumentasi ini, tentu saja, banyak pekerjaan, tetapi itu terjadi untuk
alasan yang bagus: Seiring waktu, alasan keputusan kami memudar
dari ingatan. Keputusan ad-hoc yang dibuat untuk mengatasi masalah tertentu
lem dalam keadaan tertentu mendapatkan semua campur aduk dengan keputusan
dimaksudkan untuk membentuk dasar untuk pekerjaan desain masa depan.
Alasan lain untuk mendokumentasikan sistem desain Anda adalah bahwa orang-orang
akhirnya berhenti dari pekerjaan mereka. Ketika mereka melakukannya, mereka pergi dengan
banyak pengetahuan tentang bagaimana suatu produk dirancang dan dibangun sehari-
hari. Tanpa panduan gaya yang tetap up-to
dengan standar dan praktik terbaru, pengetahuan itu hilang.
Seiring waktu, ketika orang berganti posisi, seluruh organisasi
secara bertahap menderita semacam amnesia, seperti cara-cara yang dilakukan dan
alasan untuk keputusan tersebut beralih ke bagian lain dari
perusahaan atau kembali ke dunia kerja.
Dokumentasi definitif dari keputusan desain yang kami miliki
dibuat adalah panduan gaya. Ringkasan ini mendefinisikan setiap aspek
desain visual, dari skala terbesar hingga terkecil. Global
standar yang mempengaruhi setiap bagian produk—seperti kisi-kisi desain, palet
warna, standar tipografi, atau pedoman perawatan logo—
biasanya hal pertama yang masuk ke panduan gaya.
Panduan gaya juga akan mencakup standar khusus untuk partiku bagian
atau fungsi suatu produk. Dalam beberapa kasus, standar
didokumentasikan dalam panduan gaya akan turun ke level antarmuka
individu dan elemen navigasi. Tujuan keseluruhan
dari panduan gaya adalah untuk memberikan detail yang cukup untuk membantu orang membuat
keputusan cerdas di masa depan—karena sebagian besar pemikiran telah sudah
dilakukan untuk mereka.

Membuat panduan gaya juga membantu dalam memaksakan konsistensi desain di
seluruh organisasi yang terdesentralisasi. Jika operasi Web Anda con serangkaian
beragam proyek independen yang sedang dimulai dan
dikerjakan oleh orang-orang di kantor yang tersebar di seluruh dunia, situs Anda
cenderung terlihat seperti campuran gaya dan standar yang acak.
Membuat semua orang itu mengikuti serangkaian standar yang terpadu bisa banyak
pekerjaan, itulah sebabnya tanggung jawab untuk menegakkan panduan gaya desain
sering berada lebih tinggi dalam organisasi
dari yang Anda harapkan. Memiliki panduan gaya yang dapat Anda rujuk adalah satu-
satunya cara paling efektif untuk membuat produk Anda terlihat kohesif utuh, bukan
hanya potongan-potongan yang ditempelkan.

bab 8
Elemen-elemen
Terapan

153
Elemen pengalaman pengguna tetap konsisten bagaimanapun caranya
kompleks produk Anda. Tapi meletakkan ide di balik elemen
ke dalam praktek kadang-kadang bisa tampak seperti sebuah tantangan dengan sendirinya. Dia
bukan hanya soal waktu dan sumber daya—seringkali soal
kerangka berpikir.
Melihat kembali lima bidang—strategi, ruang lingkup, struktur, kerangka
ton, dan permukaan—semuanya terdengar seperti banyak pekerjaan. Pasti seperti itu
perhatian yang cermat terhadap semua detail ini harus memakan waktu berbulan-bulan untuk dikembangkan
waktu dan pasukan kecil spesialis yang sangat terlatih, bukan?
Belum tentu. Tentu saja, untuk beberapa proyek dan beberapa organisasi tions,
mempekerjakan tim spesialis yang berdedikasi adalah yang paling efektif
cara untuk membagi tanggung jawab atas produk yang terlalu nyaman
plex untuk menangani cara lain. Juga, karena spesialis dapat fokus
secara eksklusif pada bagian dari pengalaman pengguna yang lengkap, mereka sering
membawa pemahaman yang lebih dalam tentang isu-isu untuk menanggung dalam pekerjaan mereka.
154 BAB 8 ELEMEN YANG DITERAPKAN
Namun, sebagian besar waktu, tim kecil dengan sumber daya terbatas dapat
mencapai hasil yang serupa. Terkadang sekelompok hanya beberapa orang bisa sebenarnya
menghasilkan hasil yang lebih baik daripada tim besar, karena lebih mudah bagi mereka untuk
tetap sinkron pada visi bersama tentang pengalaman pengguna.
Merancang pengalaman pengguna benar-benar tidak lebih dari sekadar
kumpulan besar masalah yang sangat kecil untuk dipecahkan. Perbedaan
antara pendekatan yang sukses dan pendekatan yang benar-benar gagal

bermuara pada dua ide dasar:
. Pahami masalah apa yang Anda coba selesaikan. Jadi
Anda telah menemukan tombol ungu besar di rumah layar
bermasalah. Apakah itu kebesaran dan keunguan tombol
yang perlu diubah (permukaan)? Atau apakah itu
tombol berada di tempat yang salah pada halaman (kerangka) atau itu
fungsi yang diwakili tombol tidak melakukan apa yang dilakukan pengguna
harapkan (struktur)?
. Pahami konsekuensi dari solusi Anda terhadap
masalah. Ingatlah bahwa ada potensi efek riak naik dan turun melalui
elemen dari setiap keputusan yang Anda
membuat. Desain navigasi yang bekerja sangat baik di satu bagian
produk Anda mungkin tidak cukup memenuhi kebutuhan detik lain tion
arsitektur. Desain interaksi untuk produk
penyihir seleksi uct mungkin merupakan pendekatan yang inovatif,
tetapi apakah itu akan memenuhi kebutuhan pengguna teknofobia Anda?


155
Hanya dengan meminta
seseorang
di organisasi Anda berpikir

tentang masing-masing dari lima
pesawat dapat Anda alamat

semua pertimbangan
penting untuk menciptakan
pengguna yang sukses
pengalaman. Bagaimana
tanggung jawab ini
didistribusikan di organisasi Anda
tidak sepenting membuat

yakin semua elemen
pengalaman pengguna adalah
dicatat.
Anda akan terkejut melihat betapa banyak keputusan kecil yang dibuat proses
desain pengalaman pengguna tidak dibuat secara sadar di
semua. Sebagian besar waktu, pilihan yang dibuat tentang pengalaman pengguna
jatuh ke dalam salah satu skenario ini:
. Desain secara default. Hal ini terjadi ketika struktur pengalaman
pengguna mengikuti struktur yang mendasarinya teknologi atau
organisasi Anda. Menjaga pelanggan
riwayat pesanan dan informasi penagihan dalam basis data terpisah mungkin
bekerja lebih baik untuk sistem teknis Anda yang ada, tetapi itu tidak berarti
memisahkannya dalam pengalaman pengguna adalah
juga ide yang bagus. Demikian pula, konten yang berasal dari berbagai departemen
di perusahaan dapat melayani pengguna dengan lebih baik jika dipertemukan,
bukan dipisahkan.
. Desain dengan mimikri. Ini terjadi ketika pengalaman pengguna
jatuh kembali pada konvensi akrab dari produk lain, publik
kation, atau aplikasi perangkat lunak, terlepas dari seberapa tepat makan
konvensi itu mungkin untuk pengguna Anda (atau bahkan untuk
Web itu sendiri).
. Desain oleh fiat. Ini terjadi ketika preferensi pribadi
alih-alih kebutuhan pengguna atau tujuan produk mendorong pengalaman pengguna
keputusan-keputusan. Jika oranye mendominasi palet warna Anda karena
salah satu wakil presiden senior menyukainya, atau jika semua elemen
navigasi Anda adalah menu tarik-turun karena
itulah yang disukai oleh kepala teknisi Anda, Anda telah melupakannya sasaran
strategis dan wawasan pengguna yang harus mendorong pilihan yang Anda
buat.
Mengajukan Pertanyaan yang Tepat
Menghadapi jalinan masalah kecil yang harus dipecahkan dalam merancang pengalaman
pengguna terkadang bisa mengecewakan. Kadang-kadang
solusi untuk satu masalah akan memaksa Anda untuk memikirkan kembali masalah lain yang
Anda pikir telah Anda pecahkan. Banyak kali, Anda akan memiliki
untuk membuat kompromi dan mengevaluasi trade-off antara pendekatan yang berbeda.
Ketika Anda berada di tengah-tengah harus membuat ini
jenis keputusan, mudah untuk menjadi frustrasi dan mempertanyakan apakah Anda
mengambil pendekatan yang tepat. Pendekatan yang tepat adalah
untuk mendasarkan setiap keputusan dalam pemahaman Anda tentang masalah
mendasar yang dimainkan. Pertanyaan pertama yang harus Anda tanyakan pada diri sendiri (dan
pertanyaan pertama yang harus Anda jawab) tentang aspek apa pun dari pengalaman
pengguna adalah: Mengapa Anda melakukannya seperti itu?
Memiliki kerangka berpikir yang benar tentang mendekati masalah yang paling Anda hadapi
adalah hal yang paling penting. Setiap aspek lain dari pengalaman pengguna
proses desain rience dapat disesuaikan agar sesuai dengan waktu, uang, dan orang yang
Anda inginkan. Tidak ada waktu untuk mengumpulkan data riset pasar tentang audiens
Anda? Mungkin Anda dapat menemukan cara untuk melihat informasi yang sudah Anda
miliki, seperti log server atau pesan umpan balik, untuk mendapatkan
rasa kebutuhan pengguna Anda. Tidak mampu menyewa lab uji kegunaan? Rekrut teman,
keluarga, atau rekan kerja untuk berpartisipasi dalam
pengujian tidak resmi.
Tahan godaan untuk mengabaikan pengalaman pengguna yang mendasar
ence isu proyek atas nama menghemat waktu atau uang. Pada beberapa proyek,
seseorang akan dengan serius memasang beberapa bentuk pengguna
mengalami evaluasi hingga akhir proses—lama setelah

waktu untuk benar-benar mengatasi masalah tersebut telah habis. Berlomba menuju
meluncurkan tanpa melihat ke belakang mungkin tampak seperti ide yang bagus
kembali ketika tanggal peluncuran ditetapkan, tetapi hasilnya mungkin adalah
produk yang memenuhi semua persyaratan teknis untuk proyek tetapi
tidak berfungsi untuk pengguna Anda. Lebih buruk lagi, dengan memanfaatkan pengalaman pengguna
evaluasi pada akhirnya, Anda mungkin akhirnya meluncurkan produk
yang Anda tahu rusak tetapi tidak memiliki kesempatan (atau uang tersisa)
memperbaiki.
Beberapa organisasi menyukai pendekatan ini, menyebutnya "penerimaan pengguna"
pengujian.” Kata penerimaan sangat jitu di sini—pertanyaannya
bukan apakah mereka menyukai produk atau akan menggunakan produk, tetapi
bukannya mereka bisa menerima produk? Jenis pengujian ini terlalu sering
terjadi di akhir proses, di mana waktu tak terhitung
asumsi telah membentuk pengalaman pengguna tanpa pernah menjadi
diperiksa. Asumsi-asumsi itu bisa sangat sulit untuk
terungkap dalam pengujian pengguna produk jadi, karena mereka
tersembunyi di balik lapisan antarmuka dan interaksi.
Banyak orang menganjurkan pengujian pengguna sebagai sarana utama untuk
memastikan pengalaman pengguna yang baik. Garis pemikiran ini tampaknya
bahwa Anda harus membuat sesuatu, letakkan di depan beberapa orang untuk
lihat bagaimana mereka menyukainya, dan kemudian perbaiki apa pun yang mereka keluhkan.
Tetapi pengujian tidak pernah menggantikan pengguna yang bijaksana dan terinformasi
mengalami proses desain.
Mengajukan pertanyaan kepada pengguna Anda yang berfokus pada elemen tertentu dari
pengalaman pengguna dapat membantu Anda mengumpulkan masukan yang lebih relevan. Tes pengguna
dibangun tanpa memperhatikan unsur-unsur pengalaman pengguna
ence dapat berakhir dengan mengajukan pertanyaan yang salah, yang pada gilirannya dapat
mengarah pada jawaban yang salah. Misalnya, ketika menguji prototipe,

mengetahui masalah apa yang ingin Anda selidiki sangat penting untuk menyajikan subjek uji Anda dengan pengalaman yang tidak mendung
masalah dengan masalah yang tidak terkait. Apakah masalah dengan navigasi itu?
tion bar benar-benar hanya warna? Atau apakah itu kata-kata yang digunakan pengguna Anda menanggapi?
Anda tidak dapat bergantung pada pengguna Anda untuk mengartikulasikan kebutuhan mereka. Tantangan dalam menciptakan pengalaman pengguna apa pun ad
diri. Pengujian dapat membantu Anda memahami kebutuhan pengguna Anda,
tapi itu hanya salah satu dari banyak alat yang dapat membantu mencapai tujuan yang sama.
Marathon dan Sprint

Sama seperti Anda tidak boleh meninggalkan aspek pengalaman pengguna apa pun untuk
kesempatan, Anda tidak boleh meninggalkan proses pengembangan Anda sendiri untuk
kesempatan baik. Terlalu banyak tim pengembangan yang beroperasi dalam keadaan
darurat permanen. Setiap proyek dipahami sebagai respons terhadap
beberapa krisis yang dirasakan, dan sebagai hasilnya, setiap proyek ketinggalan jadwal
ule bahkan sebelum dimulai.
Berikut adalah metafora untuk proses pengembangan pengalaman pengguna yang
Saya sering menggunakan ketika menjelaskan masalah kepada klien: Sebuah maraton tidak lari cepat.
Ketahui jenis balapan yang Anda ikuti dan jalankan sesuai dengan itu.
Sprint adalah perlombaan pendek. Sprinter harus memanggil cadangan besar
energi pada saat pistol awal ditembakkan — dan mereka menghabiskan semua
energi itu dalam waktu beberapa menit. Langsung dari awal
garis, sprinter harus berlari secepat yang dia bisa dan terus berlari sebagai
secepat yang dia bisa sampai dia mencapai garis finish.

Marathon adalah perlombaan yang panjang. Pelari maraton membutuhkan sebanyak itu
energi seperti yang dilakukan sprinter, tetapi mereka mengeluarkannya dengan sangat berbeda. Suc
cess dalam maraton tergantung pada seberapa efektif kecepatan pelari
diri. Semua faktor lain dianggap sama, pelari siapa yang tahu
kapan harus mempercepat dan kapan harus melambat jauh lebih mungkin untuk
menang—atau bahkan menyelesaikan balapan sama sekali.
Strategi sprint—berlari secepat mungkin dari awal hingga
akhir—bisa menjadi satu-satunya pendekatan yang masuk akal untuk balapan. Dia
sepertinya kamu harus bisa berlari maraton seolah-olah itu
serangkaian sprint—tetapi tidak seperti itu. Sebagian alasannya
tidak bekerja seperti itu adalah batas fisik sederhana dari ketahanan manusia ance. Ada
faktor lain di sini juga: Untuk mengakomodasi batas itu,
pelari maraton terus memantau kinerja mereka, perhatikan
apa yang berhasil dan apa yang tidak berhasil, dan sesuaikan pendekatan mereka
demikian.
Pengembangan produk jarang merupakan sprint. Lebih sering, akan ada
saat-saat ketika Anda mendorong maju, membangun prototipe dan menghasilkan
ide, diikuti saat Anda menarik kembali, menguji apa yang Anda miliki
dibangun, melihat bagaimana bagian-bagiannya cocok bersama, dan menyempurnakan gambaran besarnya
untuk proyeknya. Beberapa tugas paling baik dilakukan dengan penekanan
pada kecepatan; yang lain membutuhkan pendekatan yang lebih disengaja. baik mara
pelari thon tahu yang mana-begitu juga seharusnya Anda.
Keputusan desain yang bijaksana dan disengaja akan menghabiskan waktu Anda dalam jangka
pendek, tetapi mereka akan menghemat lebih banyak waktu dalam jangka panjang
ketentuan. Desainer dan pengembang sering mengeluhkan kurangnya perhatian
untuk strategi, ruang lingkup, dan struktur dalam proyek yang mereka kerjakan. saya memiliki
terlibat dalam lebih dari satu proyek di mana kegiatan ini
terus-menerus di bawah ancaman tersingkir. Beberapa orang mendapatkan


161
tidak sabar dengan tugas-tugas yang tidak melibatkan produksi aktual komponen
situs seperti grafik atau potongan kode. Tugas-tugas ini adalah seringkali item baris
pertama dipotong dari proyek yang terlambat dari jadwal
atau melebihi anggaran.
Konkret
permukaan
kerangka
struktur
cakupan
strategi
Abstrak
Tapi tugas-tugas ini termasuk dalam lingkup proyek di tempat pertama
karena mereka berfungsi sebagai persiapan penting untuk kiriman nanti untuk
datang. (Itulah mengapa lima pesawat dibangun dari bawah ke atas, masing-masing
berfungsi sebagai dasar bagi mereka yang di atasnya.) Ketika tugas-tugas ini adalah
dihilangkan, tugas dan hasil yang tersisa dalam jadwal proyek
merasa tidak mendapat informasi tentang konteks proyek yang lebih besar dan kebingungan
disambung satu sama lain.
Ketika Anda sampai pada akhir, Anda memiliki produk yang kurang
harapan semua orang. Anda tidak hanya gagal memecahkan masalah Anda
masalah asli, Anda sebenarnya telah menciptakan masalah baru untuk Anda
diri sendiri karena sekarang proyek besar berikutnya di cakrawala adalah mencoba
untuk mengatasi kekurangan dari proyek terakhir. Dan begitulah siklusnya
mengulang.
Melihat produk dari luar—atau masuk ke dalam pengembangan
proses ment untuk pertama kalinya—mudah untuk fokus pada yang lebih jelas
elemen di dekat bagian atas model lima bidang dengan mengorbankan
mereka yang lebih dekat ke bawah. Ironisnya, bagaimanapun, adalah bahwa elemen
yang paling sulit dilihat—strategi, ruang lingkup, dan strukturnya produk—
memainkan peran paling penting dalam kesuksesan keseluruhan atau
kegagalan pengalaman pengguna.
Dalam banyak kasus, kegagalan pada bidang atas dapat mengaburkan keberhasilan pada
pesawat yang lebih rendah. Masalah dengan desain visual—tata letak yang tampak rumit
tered atau sibuk, atau warna yang tidak konsisten atau bentrok—bisa berubah
pengguna begitu cepat sehingga mereka tidak pernah menemukan semua pilihan cerdas
Anda buat dengan navigasi atau desain interaksi. Dikandung dengan buruk pendekatan desain
navigasi dapat membuat semua pekerjaan Anda menjadi
suara, arsitektur informasi yang fleksibel tampak seperti buang-buang waktu.


163
Demikian pula, membuat semua keputusan yang tepat di bidang atas berarti apa-apa
jika keputusan itu didasarkan pada pilihan buruk yang dibuat di pesawat yang lebih
rendah. Sejarah Web penuh dengan situs yang gagal karena, meskipun indah,
mereka sama sekali tidak dapat digunakan.
Berfokus pada desain visual dengan mengesampingkan elemen lain dari
pengalaman pengguna mendorong lebih dari satu perusahaan rintisan ke dalam kebangkrutan dan
membuat perusahaan lain bertanya-tanya mengapa mereka repot-repot dengan

Web sama sekali.
Tidak harus seperti itu. Jika Anda mendekati pengembangan produk Anda proses opment
dengan pengalaman pengguna yang lengkap dalam pikiran, Anda bisa keluar dari itu
dengan produk yang merupakan aset, bukan kewajiban.
Dengan menjadikan semua pengalaman pengguna dengan produk Anda hasil dari
keputusan yang sadar dan eksplisit, Anda dapat memastikan bahwa produk berfungsi
untuk memenuhi tujuan strategis Anda dan kebutuhan
pengguna Anda.

165
SEBUAH C
tombol tindakan, dijelaskan, 117 penyortiran kartu, 49
pendekatan arsitektur. kotak centang, dijelaskan, 116,
Lihat juga informasi 118
Arsitektur CMS (manajemen konten
struktur hierarkis, 93 sistem), 63–64
struktur hub-and-spoke, palet warna, mempertimbangkan dalam
93 desain sensorik, 145-148
struktur matriks, 93–94 komunikasi, pentingnya, 12–13
struktur organik, 94–95
struktur berurutan, 95 comp, ditentukan, 148
struktur pohon, 93 pesaing, mendapatkan
sikap pengguna, inspirasi dari, 67–68
mengingat, 44 model konseptual, 83–85, 97,
penonton, mempertimbangkan konten 111-112
untuk, 74 konsistensi
segmen audiens, berdasarkan mempertimbangkan dalam
demografi, 43–44 desain sensorik, 143-144
internal versus eksternal,
143-144
B
isi
identitas merek, mengingat, 38–39
mempertimbangkan penonton untuk,
74
persyaratan branding,
ditentukan, 12
mengingat, 65
format versus tujuan, 72
tujuan bisnis, menentukan, 37– 38
berdampak pada pengalaman pengguna,
32
penataan, 89–92
versus teknologi, 32
166 INDEKS
fitur konten, pembaruan, 73–74

merancang sistem, mendokumentasikan,
150
inventaris konten, pengambilan, 74
mendokumentasikan. Lihat juga
persyaratan konten, 71-74. gambar rangka
Lihat juga persyaratan
sistem desain, 150
proyek; persyaratan
spesifikasi fungsional, 69–71
mengingat, 29
mempertimbangkan pada
daftar dropdown, dijelaskan, 117–
bidang lingkup, 61–64 118
menentukan, 63
penyelidikan kontekstual, 47
navigasi kontekstual, 122 E
kontras dan keseragaman,
efisiensi, peningkatan, 15–16
mengingat dalam desain
Model elemen. Lihat pesawat
sensorik, 139-143 penanganan kesalahan, 86–88
kosakata terkontrol, menggunakan, koreksi, 86–87
98–99
pencegahan, 86–87
konvensi dan metafora, pemulihan, 86–87
110-113
batalkan fungsi, 88
konvensi
pesan kesalahan, terjadinya, 64
mengingat, 84
berkembang, 116 eyetracking, mempertimbangkan
tingkat konversi, pengukuran, 13– 15 dalam desain sensorik, 137–139
navigasi kesopanan, 122–123
loyalitas pelanggan, 13
F
segi
D manfaat dari, 121
demografi, berlaku untuk segmen ditentukan, 98
audiens, 43–44 FAQ, mengingat, 72
rancangan. Lihat juga desain fitur
produk; desain yang berpusat pada pengguna konflik antara, 76
secara default, 156 menggambar analogi
oleh fiat, 156 dengan pengalaman, 113
dengan mimikri, 156 implementasi, 76
desain comps, mempertimbangkan saran, 76–77
dalam desain sensorik, 148-151 batasan waktu aktif, 76
konsistensi desain, penegakan, 144 penggunaan terminologi, 62
lima pesawat. Lihat juga bidang
lingkup; pesawat kerangka;
pesawat strategi; struktur

167
pesawat terbang; bidang permukaan; pengalaman

kemampuan beradaptasi, 91–92
pengguna
pendekatan, 92–95
bangunan dari bawah ke atas,
pendekatan bottom-up, 90
162
kategori dalam, 90–91
pilihan terkait dengan, 23
struktur konseptual dari, 97
mengingat, 155
mempertimbangkan, 30
keputusan terkait, 24
kosakata terkontrol, 98–99
dependensi dari, 22–23
kegagalan aktif, 162-163
diagram, 101–105
ruang lingkup, 21, 29
mendokumentasikan, 101–105
kerangka, 20, 30
aliran bahasa di, 95
strategi, 21, 28
bahasa, 98-101
struktur, 20, 30
metadata, 98-101
permukaan, 20, 30 menggunakan
simpul di, 92–93
elemen dari, 31–33 sedang bekerja,
prinsip pengorganisasian,
24 96–98
spesifikasi fungsional, 29, 62–64,
menyusun konten, 89–92
68–71
pendekatan top-down, 89–90
penggunaan tesaurus, 99
G Kosakata Visual, 102–
103
navigasi global, 120-121 teknik
desain informasi, 108–109.
tata letak berbasis grid,
Lihat juga desain antarmuka
141-142
mengingat, 30, 45
H 124–126
peran dalam desain antarmuka,
pengalaman mendengar, 136
126
struktur hierarkis, 93
tipe visual, 124
struktur hub-and-spoke, 93 hyperlink,
pencarian jalan, 127
kurang dimanfaatkan, 122
navigasi sebaris, 122
desain interaksi, 81–82
model konseptual, 83–85
Saya
konsistensi, 111-112
tayangan, ditentukan, 40
konvensi dan metafora,
indeks, menggunakan untuk navigasi, 123
110
arsitektur informasi, 81, 88-89. Lihat
konvensi, 84
juga pendekatan arsitektur
penanganan kesalahan, 86–88
konvensi antarmuka,
perubahan, 116
168 INDEKS
desain antarmuka, 108–109. Lihat juga

indeks, 123
desain informasi
sebaris, 122
lokal, 121
sukses, 114 elemen
elemen persisten, 120
antarmuka
peta situs, 123
tombol aksi, 117
tambahan, 121
kotak centang, 116, 118
alat navigasi, 123
daftar tarik-turun, 117–118
simpul
kotak daftar, 117
anak dan orang tua, 93
tombol radio, 116, 118
dalam struktur hierarki,
bidang teks, 116
93
dalam struktur matriks, 93–94
L dalam struktur organik, 94
bahasa dan metadata, 98-101
96
berperan dalam informasi
kotak daftar, dijelaskan, 117
struktur, 92–93
navigasi lokal, 121
nomenklatur, 98
M HAI
maraton dan lari cepat, 159–
tujuan. Lihat tujuan produk
163
metode riset pasar, 46 struktur
sistem operasi, elemen antarmuka, 116–118
matriks, 93–94 metadata dan
Palet warna Orbitz, 146 struktur
bahasa, 98-101
organik, 94–95 prinsip
pengorganisasian,
metafora dan konvensi,
110-113 penerapan, 96–98
N P
tata letak halaman, 128-131
desain navigasi, 108–109.
elemen navigasi persisten, 120
Lihat juga pencarian jalan
persona
menciptakan, 49–51
gol dari, 118–119
termasuk dalam persyaratan, 67
pentingnya, 119–120
sistem navigasi, 120 telepon, konvensi yang terkait
kontekstual, 122 dengan, 110–111
kesopanan, 122–123
global, 120-121

169
pesawat. Lihat juga bidang lingkup;

persyaratan proyek. Lihat juga
pesawat kerangka; pesawat strategi;
persyaratan konten; persyaratan
pesawat struktur; bidang
permukaan; pengalaman pengguna
klarifikasi, 59–61
bangunan dari bawah ke atas, 162
menentukan, 65–68
pilihan terkait dengan, 23
pembangkit, 67 termasuk
mengingat, 155
persona di, 67 mengelola,
keputusan terkait, 24
61
dependensi dari, 22–23
proyek, perencanaan, 24
kegagalan aktif, 162-163
prototipe, 48–49
ruang lingkup, 21, 29
profil psikografis, 44
kerangka, 20, 30
strategi, 21, 28
struktur, 20, 30 Q
permukaan, 20, 30 menggunakan
pertanyaan, berpose kepada pengguna,
elemen dari, 31–33 sedang bekerja, 158–159
24
pemecahan masalah, 157–159
desain produk, konsep, 7-8. Lihat juga R
desain; desain yang berpusat pada tombol radio, dijelaskan, 116, 118
pengguna persyaratan. Lihat juga persyaratan konten;
tujuan produk, klarifikasi, 61–64 persyaratan proyek
tujuan produk mengumpulkan ide untuk, 74 berkembang,

identitas merek, 38–39 73
tujuan bisnis, 37–38 mengevaluasi, 75
mengingat, 28, 36, 91 memprioritaskan, 74–77 tujuan
metrik keberhasilan, 39–41 strategis untuk, 75
produk alat penelitian
menggambarkan set fitur, penyortiran kartu, 49
29
penyelidikan kontekstual, 47
sebagai fungsionalitas, 27–29, metode riset pasar,
161 46
sebagai informasi, 27–29, 161 prototipe, 48–49
perencanaan, 59–60 analisis tugas, 47
sukses, 12–13 pengujian pengguna, 47–48 kunjungan
kembali, pengukuran, 41 pendapatan,
meningkat, 14–15
ROI (laba atas investasi), 13
170 INDEKS
S pesawat kerangka, 20, 30. Lihat

juga pesawat
ruang lingkup, mendefinisikan, 58–59
konvensi, 110-113
bidang lingkup, 21, 29. Lihat juga
desain informasi, 30, 108–
pesawat terbang
109, 124–127
konten, 61–64
desain antarmuka, 30, 108–
persyaratan konten, 29,
109, 114–118
71–74
metafora, 110-113
mendefinisikan konten
desain navigasi, 30, 108–
persyaratan, 63
109, 118–123
menentukan persyaratan, 65–
gambar rangka, 128-131
68
bau dan rasa, mempertimbangkan
spesifikasi fungsional,
dalam desain sensorik, 135
29, 62, 68–71
perangkat lunak, fokus, 82–83
fungsionalitas, 61–64
solusi, mencari masalah,
memprioritaskan persyaratan,
157–159
74–77
Situs Southwest Airlines, 85
peran dalam arsitektur
lari cepat
bottom-up, 90
ditentukan, 159
komponen strategi dari, 75
strategi, 160
desain sensorik, 134
pemangku kepentingan
palet warna, 145-148
kekhawatiran tentang strategi, 77
konsistensi, 143-144 kontras
ditentukan, 52
dan keseragaman,
menyelesaikan konflik
139-143
antara, 77
perusahaan desain, 148-151
tujuan strategis, rapat, 40
pelacakan mata, 137–139
tujuan strategis,
pendengaran, 136
persyaratan untuk, 75
bau dan rasa, 135 panduan
ahli strategi, pekerjaan,
gaya, 148-151
52
sentuh, 135–136
dokumen strategi
tipografi, 145-148
isi, 53–54
penglihatan, 136–137
hierarki, 77
pengalaman indrawi,
pesawat strategi, 21, 28. Lihat juga
mengingat, 30
pesawat terbang
struktur berurutan, 95
tujuan produk, 28 peran
situs, penggunaan terminologi, 9–10
dalam arsitektur
peta situs, penggunaan, 102, 123
top-down, 90
kerangka, mendefinisikan, 108–109
kebutuhan pengguna, 28

171
bidang struktur, 20, 30. Lihat juga

bidang T
arsitektur informasi, 30, 81, 88-101 analisis tugas, 47
rasa dan bau, mempertimbangkan
desain interaksi, 30, 80–88 peran dalam desain sensorik, 135
peran dan proses tim
dan proses tim, 101–105 untuk pesawat strategi, 52–54
untuk bidang struktur,
struktur 101–105
menentukan, 80–81 alat teknologi, kendala, 115
struktur hierarkis, 93
struktur hub-and-spoke, teknologi versus konten, 32
93 telepon, konvensi yang terkait
struktur matriks, 93–94 dengan, 110–111
struktur organik, 94–95 elemen teks, mempertimbangkan,
struktur berurutan, 95 147
struktur pohon, 93 bidang teks, dijelaskan, 116
panduan gaya, mempertimbangkan tesaurus, menggunakan, 99
dalam desain sensorik, 148-151 pengalaman sentuh, 135–136
metrik keberhasilan, 39–41 struktur pohon, 93
navigasi tambahan, tipografi, mempertimbangkan dalam
121 desain sensorik, 147-148
permukaan, mendefinisikan, 134
bidang permukaan, 20, 30. Lihat juga
kamu
pesawat terbang
batalkan fungsi, gunakan dalam
palet warna, 145-148
penanganan kesalahan, 88
konsistensi, 143-144 kontras
keseragaman dan kontras,
dan keseragaman,
mengingat dalam desain
139-143
sensorik, 139-143
perusahaan desain, 148-151
kegunaan, ditentukan, 48
pelacakan mata, 137–139
pengujian penerimaan pengguna, 158
pendengaran, 136 perilaku pengguna. Lihat desain interaksi
indra, 135–137
pengalaman sensorik, 30
pengalaman pengguna. Lihat juga
bau dan rasa, 135
pesawat terbang
panduan gaya, 148-151

pilihan dibuat tentang, 156
sentuh, 135–136
ditentukan, 6
tipografi, 145-148
mendelegasikan tanggung jawab untuk, 31
penglihatan, 136–137
desain, 7-8
172 INDEKS
pengalaman pengguna (lanjutan )

desain secara default, 156 desain V
berdasarkan fiat, 156 desain dengan isi dokumen visi, 53–
mimikri, 156 desain untuk, 8–9 54 hierarki, 77
detail, 6 gambar analogi dengan pengalaman visi, 136–
fitur, 113 137 desain visual, pencocokan
dengan gambar rangka, 149 tata
letak netral visual, 140
pembentukan komunitas,
26 Kosakata Visual, 102-103
dampak konten pada, 32 dampak pada
bisnis, 12–17 termasuk dalam proses
W
pengembangan, 11 metafora
untuk, 159 kualitas, 12–17 desain wayfinding, 127. Lihat juga
yang berhasil, 154 di Web, 9–12 desain navigasi Web

kepentingan komersial di,
model pengguna, pembuatan, 49– 51
kebutuhan pengguna
26
persyaratan konten, 62 evolusi,
25-26 spesifikasi fungsional,
mempertimbangkan, 28, 62
36 menciptakan persona, 49-51
pengalaman pengguna aktif, 9–12
mengidentifikasi, 42 profil elemen web
psikografis, 44 alat penelitian yang
fungsionalitas, 27-28 media
terkait dengan,
informasi,
46
27–28
pemahaman, 46–49 kegunaan,
Situs web, kegagalan, 36
46–49 profil pengguna, gambar rangka. Lihat juga
membuat, 49–51 penelitian pengguna, 46–
mendokumentasikan desain visual
49, 51 segmen pengguna, 42–46
yang cocok dengan, 149
pentingnya, 45 merevisi setelah penelitian,
bidang kerangka, 128-131
45 pengujian pengguna, 47–48
berpusat pada pengguna
desain, 17. Lihat juga desain; desain
produk
pengguna
pilihan disajikan kepada, 10

mengajukan pertanyaan, 158–
159

Pertemuan 6) The - Elements - of - User - Experience - TRanslate

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Pertemuan 6) The - Elements - of - User - Experience - TRanslate

Diunggah oleh

Hak Cipta:

Format Tersedia

Machine Translated by Google

Machine Translated by Google

DESAIN YANG BERPUSAT PENGGUNA

Ditulis dan diilustrasikan oleh

Penunggang Baru1249 Eighth Street

Temukan kami di Web di: www.newriders.com

Hak Cipta © 2011 oleh Jesse James Garrett

Editor Proyek: Michael J. Nolan

Pemberitahuan Tanggung Jawab

ISBN 13: 978-0-321-68368-7

Dicetak dan dijilid di Amerika Serikat

Untuk istri saya, Rebecca Blood Garrett, yang

iv UNSUR PENGALAMAN PENGGUNA

Memperkenalkan Pengalaman Pengguna 4

Dari Desain Produk hingga Desain Pengalaman Pengguna 7

Merancang (untuk) Pengalaman: Penggunaan Penting 8

Pengalaman Pengguna dan Web 9

Pengalaman Pengguna yang Baik Adalah Bisnis Yang Baik 12

Memperhatikan Pengguna Anda 17

Membangun dari Bawah ke Atas 21

Elemen Pengalaman Pengguna 28

UNSUR PENGALAMAN PENGGUNA v

Kegunaan dan Riset Pengguna 46

Peran dan Proses Tim 52

Mendefinisikan Ruang Lingkup 58

Anda sedang membangun 59

Anda Tidak Membangun 60

Fungsionalitas dan Konten 61

vi UNSUR PENGALAMAN PENGGUNA

Mendefinisikan Kerangka 108

Konvensi dan Metafora 110

Desain antarmuka Desain 114

Desain Informasi 124

UNSUR PENGALAMAN PENGGUNA vii

Mendefinisikan Permukaan 134

Memahami Perasaan Bau 135

Ikuti Mata 137

Kontras dan Keseragaman Konsistensi 139

Internal dan Eksternal Palet Warna dan 143

Komps Desain dan Panduan Gaya 148

Mengajukan Pertanyaan yang Tepat 157

Marathon dan Sprint 159

UNSUR PENGALAMAN PENGGUNA

Jesse James Garrett adalah salah satu pendiri Adaptive Path, a

mengerjakan proyek Web untuk perusahaan seperti AT&T,

Intel, Boeing, Motorola, Hewlett-Packard, dan Publik Nasional Radio.

Kosakata Visual, sistem notasi terbuka untuk arsip informasi dokumentasi

struktur yang sekarang digunakan oleh organisasi di sekitar Dunia. Situs

pribadinya di www.jjg.net adalah salah satu Web

tujuan paling populer untuk sumber daya arsitektur informasi,

UNSUR PENGALAMAN PENGGUNA ix

Ucapan Terima Kasih untuk Edisi Kedua

bisa dilewatkan—adalah alasan mengapa hal itu ada.

Di Penunggang Baru, tim Rose Weisburd, Tracey Croom, dan Kim

Bailey dan Karl Fast atas dukungan mereka.

editor tepercaya, penasihat, dan orang kepercayaan.

Mono, Maserati, Tarentel, Orang Tidur, Kode di

kepada Steve Scarborough dari Maserati untuk bimbingan musik.

Ucapan Terima Kasih untuk Edisi Pertama

untuk membuat sebuah buku terjadi.

Fraser, Mike Kuniavsky, Peter Merholz, Jeffrey Veen, and

Indi Muda. Melalui kegemaran mereka, saya bisa menerima

proyek ini sama sekali.