Ini adalah tips untuk meningkatkan UX proyek Anda TANPA jam pengalaman pengguna, prototipe kertas, atau kata kunci lainnya.

(Serius, cari “pemikiran desain.” 100.500 hasil!)

Untuk siapa artikel ini?

Pengembang Anda telah membuat aplikasi Anda sendiri, tetapi setiap pengguna tersiksa karenanya. Dan Anda tahu: jika mereka memberi tahu Anda secara langsung, maka masalahnya benar - benar buruk.
Desainer grafis . Mempelajari UX pada artikel di Internet adalah beberapa ... cara yang sangat menyakitkan untuk mati.
Manajer proyek . Anda sudah menjadi perempat desainer UX. Akan menyenangkan untuk mempelajari sisa keterampilan.
Dan penjahat lainnya . Setiap orang yang menumpuk proyek mereka di malam hari dan akhir pekan. Anda juga akan berguna.

Jika Anda sudah menjadi desainer UX, kemungkinan artikel itu tidak cocok untuk Anda. Saya melewatkan seluruh area untuk berkonsentrasi penuh pada keterampilan utama yang tidak dimiliki oleh desainer UX baru (atau orang-orang dari bidang terkait yang harus melakukan ini).

Keterampilan ini adalah untuk "memahami bahasa antarmuka . "

Pada awal karir saya, saya dikejutkan oleh seberapa sering klien melewati konsep awal (atau hidup, prototipe yang berfungsi) dengan kesalahan UX yang sangat jelas . Saya tidak berbicara tentang kesalahan yang dapat diidentifikasi setelah pengujian A / B yang lama. Saya berbicara tentang kesalahan sederhana, paling bodoh .

Karena tidak ada contoh yang lebih baik:

Di suatu tempat ada sekelompok pengembang yang tahu HTML tetapi tidak tahu perbedaan antara tombol radio dan kotak centang

Klien saya tidak begitu buruk, tetapi sialnya, Anda tidak perlu tujuh bentang di dahi Anda untuk memahami: jika Anda dapat memilih SATU elemen dari daftar, Anda perlu SAKLAR, bukan bendera. Untuk memahami ini , Anda hanya perlu tahu bahasa antarmuka. Dan bagi saya itu yang paling gila. Kefasihan dalam antarmuka tersedia untuk semua orang . Anda tidak perlu kuliah, tidak perlu kursus dan sebagainya.

Sejujurnya, Anda hanya perlu kehadiran semangat untuk (A) berhenti dan berpikir ketika aplikasi memalukan atau mengganggu Anda, (B) verbalisasi apa yang mengganggu / mengganggu Anda di antarmuka, dan kemudian (C) mencari cara untuk menghindari ini bug spesifik dalam proyek Anda sendiri.

Ulangi prosedur ini terus-menerus - dan menjadi profesional dalam waktu sesingkat mungkin.

Hari ini saya ingin berbicara tentang empat aturan kecil yang akan membantu menghilangkan titik-titik rasa sakit ini dalam proyek Anda sendiri. Heuristik ini satu atau dua tingkat lebih dalam dari "gunakan sakelar jika pengguna hanya dapat memilih satu item." Tetapi, jika Anda mematuhi persyaratan daftar ini, maka proyek Anda akan menjadi lebih mudah digunakan sejak awal, yang akan meluangkan waktu untuk hal-hal lain yang lebih penting.

(Saat itu mulai mendengarkan ceramah oleh desainer UX lain tentang metode penelitian pengguna akademik terbaru!)

Inilah yang kami bahas:

Tidak ada pertanyaan? Lalu, lanjutkan.

1. Hukum lokalitas

Tempatkan elemen antarmuka di mana mereka menyebabkan perubahan.

Semua hal lain dianggap sama, elemen antarmuka harus ditempatkan di sebelah tempat perubahan terjadi . Karena ketika pengguna ingin membuat perubahan pada sistem, ia tanpa sadar melihat tempat di mana perubahan ini akan terjadi .

Katakanlah Anda memiliki daftar barang. Di mana harus meletakkan tombol “ADD NEW ITEM”?

Pertanyaan: Nah, di mana perubahannya ?

Jawab: Di akhir daftar.

Ok, letakkan tombol di akhir daftar.

TUNGGU. Anda pikir ini cukup sederhana. Tapi ada godaan.

Godaannya adalah dengan menempatkannya di tempat yang ada ruang kosong.

Misalnya, jika Anda memiliki menu, maka Anda mungkin berpikir: “Kami punya menu! Mengapa tidak menaruhnya di menu!? ”

Pelanggaran hukum lokalitas di antarmuka musik

Jawabannya jelas: karena tidak ada yang akan mencarinya di sana.

(Dan jawaban lengkapnya adalah jika Anda cukup meletakkan elemen di tempat gratis, maka aplikasi akan menjadi tidak cocok untuk digunakan oleh kekacauan, dari mana orang akan melarikan diri sesegera mungkin).

Kamu pikir aku bercanda? Pernah bertemu antarmuka ini ?

Pelanggaran hukum lokalitas di antarmuka Evernote

Alternatif yang sama buruk dan meluasnya adalah membuat keputusan yang Anda lihat di Perusahaan Teknis yang Terhormat, tanpa memikirkan apakah ini masuk akal bagi Anda . “Perlu tombol“ Tambah ”? Tidak ada pertanyaan Saya melihat satu tombol seperti itu. Pegang birnya! ”

Lihatlah. Tombol lain di mana pengguna tidak akan pernah mencarinya . Secara umum, mereka akan curiga bahwa tombol ini menambahkan sesuatu yang baru ke ruang putih kosong yang besar. Karena di sanalah dia.

Pengguna Anda ingin Anda mengikuti hukum lokalitas.

Jadi sekarang mari kita gunakan.

Bam.

Mungkin Anda terlahir sebagai desainer UX dan selalu membayangkan secara visual apa yang akan terjadi jika ada ribuan elemen, bukannya lima elemen , dan Anda memahami bahwa akan ada masalah. Jika pengguna membuat satu ton daftar putar, tombolnya akan turun ratusan piksel!

Karena itu, mungkin lebih baik menyematkan tombol di bagian bawah daftar sehingga selalu terlihat, terlepas dari jumlah daftar putar.

Cemerlang! Itulah yang dilakukan Spotify.

Untuk bonus (1) gunakan tombol bawaan sampai keluar dari layar, dan pada saat itu beralihlah ke item yang disematkan dan (2) membuatnya lebih terlihat daripada tombol Spotify, yang secara pribadi saya perhatikan hanya beberapa bulan kemudian, tanpa mengklik kanan tanpa mengklik kanan klik untuk menambahkan masing-masing lagu ke daftar putar!

Pilihan lain adalah mengakui bahwa kami tidak dapat secara andal dan konsisten menunjukkan tombol di bagian bawah daftar. Di mana tempat terdekat yang paling cocok untuknya?

Dan jawabannya (saya pikir cukup jelas) ada di bagian atas daftar .

Ini adalah keinginanku

Sialan! Itulah yang dilakukan Rdio, pesaing Spotify, sebelum Pandora membelinya.

Rekonstruksi dari ingatan (seperti semua kenyataan, jika Anda memikirkannya)

Kesimpulannya jelas. Jangan pernah menjual perusahaan Anda dan selalu, selalu ikuti hukum setempat.

(Sebenarnya, ada tiga hukum lokalitas, dan "untuk menempatkan elemen UI di mana mereka mempengaruhi perubahan" hanyalah yang pertama. Jika tertarik, baca di sini ).

Selanjutnya!

2. Apa pun kecuali daftar drop-down

Setiap kali Anda tergoda untuk menggunakan daftar drop-down, pikirkan semua alternatif yang mungkin.

Satu pelajaran yang tidak jelas dalam desain UX adalah bahwa daftar drop-down biasanya merupakan pilihan terburuk .

Selamat datang di neraka!

Mereka tidak selalu buruk, tetapi faktor-faktor berikut bermain melawan Anda:

Daftar drop-down membutuhkan terlalu banyak klik / klik . Satu untuk dibuka, beberapa lagi untuk menggulir ke opsi yang diinginkan (pada ponsel), yang lain untuk memilih opsi yang benar dan (pada ponsel) yang terakhir ditutup (bandingkan dengan satu klik untuk memilih dari opsi yang tercantum).
Daftar drop-down tidak menunjukkan opsi ! Untuk melihatnya, Anda harus terlebih dahulu mengklik daftar, dan pada ponsel sering kali tidak seluruh daftar ditampilkan pada satu waktu.
Dalam daftar tarik turun yang panjang , sulit dinavigasi . Ada lebih dari 195 item dalam daftar drop-down negara. Pada titik tertentu, hampir semua versi UI lainnya akan lebih cepat daripada menggulir daftar drop-down.

Ini cukup sederhana, jadi mari kita lihat alternatif utama dari daftar drop-down.

Jika pilihannya antara dua opsi ...

Kami memiliki beberapa cara fantastis untuk memilih satu dari dua opsi. Semuanya (a) segera menampilkan opsi dan (b) membutuhkan lebih sedikit klik / klik.

Untuk pertanyaan yang tidak memiliki jawaban "default", coba tombol tersegmentasi .

Jika ada status default yang cocok dengan 'OFF', coba centang kotak . Ini juga baik untuk pengaturan yang tidak mempengaruhi perubahan sampai pengguna mengklik "Simpan" atau "Kirim" .

Switch bekerja dengan cara yang sama: itu baik untuk perubahan yang harus diterapkan segera .

Bendera dan sakelar masuk akal hanya jika ada dua opsi. Item-item berikut berguna ketika jumlah opsi dari dua hingga sekitar lima, sehingga Anda dapat mencobanya.

Jika pilihannya antara 2-5 opsi ...

Di atas, kami melihat tombol tersegmentasi (di sini juga digunakan). Perlu dicatat bahwa dengan lebih banyak opsi, tombol tersegmentasi vertikal memberikan fleksibilitas yang lebih besar di sepanjang teks.

Sakelar (tombol radio) beroperasi dengan cara yang serupa, tetapi sangat berguna untuk menampilkan sub-elemen dari setiap pilihan.

Untuk tampilan rinci beberapa opsi, kartu sangat cocok.

Saya suka trik menampilkan opsi visual secara harfiah, bukan daftar.

Rupanya Tesla juga menyukainya.

Jika pilihannya antara banyak pilihan ...

Ketika ada banyak opsi dan penggulirannya menjengkelkan, pertimbangkan untuk menyelesaikan jenis ketik. Sepertinya bilah pencarian yang menunjukkan hasil terbaik saat memasukkan karakter.

Jika Anda memilih tanggal ...

Untuk kencan, daftar drop-down adalah yang terburuk. Jika saya pernah melakukan itu, maka saya benar-benar gagal sebagai desainer UX.

Alternatif apa? Yah, itu tergantung keadaan. Pertanyaan pertama: jenis tanggal apa yang Anda pilih ?

Tanggal Poisson . Pertama, tanggal yang lebih mungkin , dan kemudian turun daftar, tanggal yang kurang mungkin. Misalnya, tanggal pertemuan atau penerbangan yang dijadwalkan.
Tanggal dengan volatilitas tinggi . Tanggal yang memiliki probabilitas yang kira-kira sama untuk rentang waktu yang luas . Misalnya, ulang tahun.

(Ya, saya memanggil "Tanggal Poisson" untuk menghormati distribusi matematika :-)

Berbagai jenis kontrol cocok untuk jenis yang berbeda.

Untuk tanggal Poisson, kami ingin melakukan sebanyak mungkin untuk MENYEDERHANAKAN pilihan tanggal dalam rentang yang paling mungkin (misalnya, untuk menjadwalkan rapat, itu bisa menjadi yang berikutnya, katakanlah, 14 hari). Sangat normal untuk memilih tanggal di luar rentang ini akan sedikit lebih sulit.

Kontrol kalender sepenuhnya memenuhi persyaratan ini untuk tanggal Poisson. Jika Anda tahu bahwa tanggalnya kemungkinan besar akan jatuh dalam 2-4 minggu ke depan, Anda menggunakan cokelat.

Cukup kreatif, Penerbangan Google secara default menawarkan penerbangan dalam waktu sekitar dua minggu, yang kadang-kadang menyebabkan kebingungan ("Saya tidak memilih ini!"), Tapi ini mungkin pilihan yang paling mungkin untuk distribusi Poisson.

Kotak teks tanggal mungkin merupakan opsi terbaik untuk tanggal dengan variabilitas tinggi, di mana (A) tidak ada alasan untuk lebih memilih satu tanggal daripada yang lain, yaitu (B) semua opsi sama sulitnya untuk memilih.

Ingat bahwa input [type = date] adalah teman Anda ... setidaknya di desktop

Jika Anda memilih nomor ...

Angka datang dalam berbagai bentuk. Kemungkinan besar, Anda akan tergoda untuk meletakkan daftar drop-down untuk jumlah sesuatu: tiket, orang, kamar, dll.

Seberapa sering Anda membutuhkan 1 tiket? Sangat sering .

Seberapa sering Anda membutuhkan 10 tiket? Tidak terlalu banyak .

Seberapa sering Anda membutuhkan 10.000 tiket? Apakah ini semacam lelucon kejam?

Di sini kita kembali berurusan dengan distribusi Poisson dan harus menggunakan kontrol bergeser ke angka yang lebih rendah: misalnya, stepper .

Untuk angka dalam rentang yang luas (misalnya, nomor jaminan sosial), Anda masih tidak akan menggunakan daftar drop-down ... Saya harap .

Bisakah saya menggunakan daftar drop-down setidaknya di suatu tempat?

Tentu saja

Ingat bahwa mereka berfungsi dengan baik ketika ...

Pengguna jarang perlu mengubah nilai default.
Ada beberapa opsi . Misalnya, dalam kontrol iOS, hanya tiga opsi yang terlihat secara default.
Pengguna tidak di ponsel (di desktop, banyak dari masalah ini dikurangi)

Mungkin yang paling jeli di antara Anda telah memperhatikan bahwa di antarmuka Google Flights, yang saya puji di atas, sebenarnya ada tiga daftar drop-down yang nyata !

Yang luar biasa, di antarmuka seluler tidak ada daftar drop-down 'Ekonomi'

Mereka benar-benar melakukan pekerjaan dengan baik di sini. Masalah kegunaan potensial cepat dikurangi dengan yang berikut:

Kontrol khusus yang, ketika ditekan, menunjukkan semua parameter (termasuk pada ponsel) - dan mengganti empat daftar drop-down (dewasa, anak-anak, bayi di kursi, bayi di lengan mereka) dengan empat stepper dalam satu daftar drop-down .
Menghapus daftar drop-down 'Ekonomi' di antarmuka seluler
Beberapa opsi dan default pintar untuk setiap item

Baiklah Mari kita melangkah lebih jauh.

3. Tes juling

Jika Anda menyipitkan mata, hal yang paling penting adalah yang pertama harus diperhatikan, dan elemen yang paling tidak penting - yang terakhir.

Pertanyaan keamanan: apa yang harus dilakukan pengguna untuk menggunakan halaman ini ?

(Catatan: Saya mengatakannya, jadi ikuti naluri saya, tapi saya bisa memberi petunjuk: ini adalah formulir entri data)

Saya akan menyarankan dua hal :

Tetapkan semua kotak centang yang relevan (??) di area kuning
Klik tombol Kirim biru

Anda juga berpikir begitu?

Kesalahan dan kesalahan.

"Bendera" sebenarnya adalah bidang yang sangat kecil untuk memasukkan data tekstual (jika Anda membaca bagian sebelumnya, Anda tahu bahwa harus ada stepper).
Yang paling penting ("Temukan Opsi" - ngomong-ngomong, ini adalah cara yang sangat membingungkan untuk mengatakan "Kirim") dibingkai oleh tombol abu-abu dan tidak mencolok. Suatu hal yang jauh kurang penting ("Bantuan") tepat di sebelahnya, tetapi lebih besar dan lebih terlihat.

Tes juling mengatakan bahwa hal yang paling penting adalah yang paling terlihat . Apa hal terpenting di sini? Ini adalah kotak teks (atau stepper;) dan tombol "Kirim".

Jika Anda melangkah lebih jauh, halaman berikutnya bahkan lebih buruk.

Apa yang akan Anda tekan: tombol abu-abu di sebelah kiri atau tombol abu-abu yang sama di kanan ?

Saya harap Anda memilih yang kiri!

Terburu-buru pada formulir ini, saya sebenarnya pertama kali mengklik tombol Bantuan. Aduh Ketika saya memasuki kedua kalinya, saya mengklik "Kembali", bahkan memindai nama kedua tombol dengan lancar, karena pada 99,999% situs lain (dengan arah huruf dari kiri ke kanan), tombol "Kembali" selalu kiri

Sekali lagi, jika Anda memicingkan mata, saya tidak bisa mengatakan apa yang penting.

Seperti hukum lokalitas dan pengecualian daftar drop-down, tes juling cukup sederhana. Koreksi skema dalam 30 detik.

Dalam desain ulang nyata, saya ingin menempatkan pilihan jumlah tiket pada HALAMAN SAMA. Tetapi ini adalah hukum yang berbeda untuk waktu yang berbeda

Apakah ini berhasil?

Katakan sendiri. Empat sakelar dan satu tombol. Dan tautan kecil di bawah ini.

Saya tidak mencoba mencari kesalahan dengan situs AlaskaTrain.com , ini biasa terjadi.

Ini adalah layar pendaftaran untuk jejaring sosial favorit saya berdasarkan rekomendasi Foursquare (tentu saja diawasi dengan baik).

Bagaimana sebenarnya mengirim data yang dimasukkan (yang paling penting)?

Petunjuk: tombolnya tersembunyi di balik teks biasa di sudut kanan atas.

Tapi Foursquare di sini hanya mengikuti standar desain Apple. Sayangnya, pelanggaran tes juling sering ditemukan bahkan di antara para pemimpin industri.

Salah satu cara untuk mengidentifikasi elemen utama pada halaman adalah dengan mempertimbangkan seberapa banyak tampilan halaman termasuk tindakan tertentu. Berikut adalah indikator yang relevan dari program Anki (program untuk menghafal kata-kata, ekspresi, dan informasi lainnya menggunakan pengulangan interval - sekitar Per.).

Untuk setiap seratus kartu yang saya lihat, maka saya akan pergi ke ...

Tampilkan jawaban (sekitar 95 kali)
Kembali ke daftar kartu (dua kali)
Mulai menambahkan kartu (dua kali)
Beberapa fitur lain (sangat jarang)

Analisis seperti itu benar-benar mengisyaratkan antarmuka mana yang akan bekerja lebih baik di sini.

Menekankan fungsi yang paling sering digunakan (dalam perkiraan pertama, "paling sering digunakan" sama dengan "paling penting")
Longgarkan, sembunyikan, atau hapus fitur yang jarang digunakan

Tapi ini hanya permulaan (misalnya, saya ingin melihat apakah pengguna memahami bahwa tombol dengan plus tanpa tanda tangan menambahkan kartu ). Tetapi dengan hanya beberapa heuristik sederhana, kami telah mengurangi antarmuka sepuluh elemen UI yang berantakan dan membingungkan menjadi hanya lima. Ini ... periksa di sini kalkulasi saya ... setengahnya.

Untuk informasi lebih lanjut tentang tes juling, Anda dapat menonton video saya yang menunjukkan desain ulang aplikasi web Timezon.es . Atau, jika Anda tidak punya waktu sepuluh menit, berikut adalah artikel blog bergambar dengan desain ulang langkah-demi-langkah yang sama.

4. Studi kasus

Jika Anda memperkenalkan konsep baru kepada pengguna, maka beberapa contoh bernilai ribuan kata yang belum dibaca orang.

Kami memiliki kecenderungan aneh untuk mencoba menjelaskan semuanya dengan kata-kata, ketika contohnya jauh lebih jelas.

Ambil startup Teeming.ai yang baru, yang baru-baru ini menghubungi saya untuk berkonsultasi tentang desain halaman utama. Judul di halaman ini:

“Beras menghilangkan isolasi dalam pekerjaan jarak jauh ”
“Membantu dengan membangun tim jarak jauh ”, itu juga “ belajar, menyelesaikan masalah, bersenang-senang dan saling memotivasi ”
“Penuh dan video untuk sinkron [komunikasi] ”
“Bekerja dengan semua platform video favorit Anda”

Tapi ini pertanyaannya. Apa yang benar-benar dilakukan oleh teeming?

Sulit dikatakan. Jelas bahwa ini entah bagaimana terhubung dengan ... positif untuk pekerja jarak jauh ? Tapi saya tidak punya ide konkret bagaimana ini akan membantu saya secara pribadi, jadi saya tidak akan mencoba layanan ini, merekomendasikannya, dll.

(Maaf, Teeming, kau tahu, aku mencintaimu).

Selanjutnya, lihatlah IFTTT . Mungkin Anda sudah tahu apa yang mereka lakukan - lalu pura-pura tidak tahu , dan coba pahami ini dari judul di halaman utama:

Secara otomatis menerangi jalan untuk seorang pria dengan pengiriman pizza (Domino + Hue)
(Instagram+Twitter)
(Google Assistant+iOS Calendar)

Anda tidak perlu mencantumkan banyak contoh untuk menggambar yang cukup jelas: IFTTT menghubungkan aplikasi bersama untuk melakukan apa yang tidak dapat mereka lakukan secara terpisah .

Yang gila adalah bahwa pada halaman utama mereka pertama kali menjelaskannya dengan teks:

IFTTT membantu aplikasi dan perangkat Anda bekerja bersama dengan cara yang baru. IFTTT adalah cara gratis untuk membuat semua aplikasi dan perangkat saling berbicara. Tidak semua yang ada di Internet berfungsi dengan baik, jadi misi kami adalah membangun dunia yang lebih terhubung.

Bliiin.

Pertanyaan: apa yang lebih baik menjelaskan ide aplikasi ? Contoh atau deskripsi?

Pikirkan contoh. Uraiannya sepenuhnya jelas hanya ketika saya melihat beberapa contoh bagaimana ini dapat membantu saya.

Namun dibutuhkan contoh tidak hanya di halaman arahan. Inilah yang kami lihat ketika kami pertama kali memasuki alat manajemen proyek Basecamp .

Alih-alih halaman yang benar-benar kosong, Anda melihat dua proyek yang disiapkan dengan jelas yang mengajarkan dengan contoh bagaimana seluruh aplikasi bekerja (dan juga memberikan gambaran tentang bagaimana sistem akan terlihat ketika Anda menggunakannya untuk sementara waktu).

Serius, saya bisa membaca obrolan palsu dari pengguna palsu yang membahas unduhan file palsu dan tugas palsu di penjadwal .

Apakah ada gunung ... yang bersahabat ? ... yang mengatakan saya bisa menonton video penjelasan dua menit tentang tutorial ini.

Dan terima kasih, Tn. Gora, untuk panduannya: video demo adalah cara lain untuk belajar dengan contoh ! Contoh-contoh menunjukkan bagaimana proyek saya akan terlihat, dan video menunjukkan bagaimana menggunakan perangkat lunak.

Cemerlang.

Jika aplikasi Anda memberi pengguna sesuatu untuk dibuat , maka demo adalah cara yang bagus untuk menunjukkan kemungkinan dengan contoh.

Aplikasi Menggambar Great Procreate memenangkan Apple Design Award, Pilihan Editor di App Store dan App Store Essential, dan John Gruber menyebutnya "terobosan," dan seterusnya - tetapi tidak ada penghargaan yang menggembirakan seperti contoh kehidupan nyata dari karya yang dibuat dalam editor ini.

Ini bukan aplikasi menggambar biasa

.

Ini bukan MS Paint.

Demonstrasi adalah alat yang ampuh untuk memahami kemampuan aplikasi Anda.

Jadi, jika aplikasi Anda melakukan sesuatu yang baru dan asing atau mengandalkan konsep baru dan asing - Anda harus belajar cara belajar dengan contoh . Jika pengguna belum melihat aplikasi ini sebelumnya, maka Anda perlu segera mengajukan pertanyaan: bagaimana memberi contoh agar lebih jelas?

Singkatnya, cara favorit saya untuk melakukan ini adalah:

Pada halaman apa saja yang mencoba menawarkan fungsi / aplikasi kepada pengguna, dll., Tunjukkan contoh apa yang dapat dilakukan dengan alat ini.
Gunakan metode "bootstrap", tampilkan data sampel dan contoh tampilan aplikasi yang berfungsi dengan benar.
Sematkan informasi latar belakang (seperti artikel, video, atau tip) bersama dengan contoh penggunaan.
Apakah aplikasi Anda memungkinkan Anda membuat sesuatu yang kreatif? Tampilkan galeri karya untuk memacu imajinasi.

Apakah ini masuk akal? Ayo dan cepatlah.

Empat aturan UX intuitif