STATUS IS UPWIKI OPTIMASI SITUS WEB
06Aktifkan
Desain dan UX / Aktifkan

Daftar Periksa Desain Web Responsif untuk Perangkat Nyata

Proses QA praktis untuk membuktikan bahwa halaman penting tetap terbaca, dapat digunakan, dan cepat di berbagai layar nyata, metode input, dan kondisi jaringan.

Daftar Periksa Desain Web Responsif untuk Perangkat Nyata — PANDUAN VISUAL
BACA
8 menit
SUMBER
6
VALIDASI ULANG
2027-03-27
ditinjau
Front-End Accessibility and Performance Reviewer
JAWABAN SINGKAT

Mulai dengan keputusan.

Anggap desain responsif sebagai QA rilis, bukan sekadar kumpulan tangkapan layar ponsel. Uji jalur pelanggan yang penting pada lebar sempit, sedang, dan lebar; pada orientasi yang relevan; dengan input sentuh, keyboard, dan pointer; serta pada sejumlah kecil perangkat nyata. Sebuah halaman lulus ketika orang dapat menyelesaikan tugas tanpa pengguliran horizontal yang tidak diinginkan, informasi yang hilang, atau cara kerja khusus perangkat.

Gunakan emulasi browser untuk menemukan batas tata letak dengan cepat, lalu konfirmasi jalur kritis pada perangkat fisik. Chrome menyatakan Device Mode adalah pendekatan perkiraan, bukan kode yang berjalan pada perangkat seluler. Catat setiap cacat dengan rute, viewport atau perangkat, orientasi, input, hasil yang diharapkan, hasil aktual, dan bukti yang aman privasinya. Perbaiki aturan bersama bila memungkinkan, lalu uji ulang kasus asli dan lebar di dekatnya.

PANDUAN VISUAL

Lihat pekerjaan sebagai sebuah sistem.

Gunakan peta ini untuk menghubungkan keputusan dalam artikel sebelum menerapkan taktik individual.

SIUAktifkan
01Bangun cakupan di sekitar tugas pelanggan
02Buktikan reflow, keterbacaan, dan zoom
03Tekan konten dan formulir
04Jalankan setiap jalur input
01

Bangun cakupan di sekitar tugas pelanggan

Daftar rute dan hasil yang menciptakan nilai: menemukan layanan, pencarian, menambahkan item, pemesanan, masuk, meminta bantuan, atau membayar. Untuk masing-masing, sebutkan komponen yang dapat berubah bentuk atau gagal: navigasi, filter, kartu, tabel, gambar, banner, formulir, drawer, dan widget tersemat. Uji lebar di mana konten Anda menjadi terbatas, bukan sekadar katalog model ponsel saat ini. Uji sedikit di bawah, pada, dan sedikit di atas setiap breakpoint.

Gunakan set cakupan kecil

Sertakan ponsel berlebar sempit dan sedang, lebar mirip tablet, laptop, desktop lebar, dan lanskap bila itu mengubah tugas.

Uji keadaan nyata

Gunakan judul panjang, hasil kosong, kesalahan validasi, badge harga, alamat lengkap, dan label lebih panjang bila keadaan itu ada.

02

Buktikan reflow, keterbacaan, dan zoom

Konfirmasi halaman memiliki pengaturan viewport yang tepat, lalu periksa pengguliran horizontal di tingkat halaman. Gambar tetap, field lebar, margin negatif, panel off-canvas, dan banner adalah penyebab umum. Kriteria Reflow WCAG 2.1 menggambarkan konten yang dapat digulir secara vertikal pada lebar ekuivalen 320 CSS pixels, termasuk viewport 1280-pixel pada zoom 400%. Jika kriteria itu masuk ruang lingkup, uji skenario zoom sebenarnya. Peta, video, atau tabel data mungkin memerlukan tata letak dua dimensi, tapi jaga agar pengguliran tetap berada dalam komponen dan biarkan halaman di sekitarnya melakukan reflow.

Inspeksi setiap tepi

Periksa header, konten utama, footer, sticky bar, dialog, dan ringkasan kesalahan pada setiap batas yang diuji.

Pertahankan konten yang diperlukan

Atur ulang informasi untuk layar sempit; jangan diam-diam menghapus persyaratan, detail harga, atau jalur bantuan.

03

Tekan konten dan formulir

Operasi konten dapat menyebabkan kegagalan responsif tanpa rilis CSS. Uji judul terpanjang yang disetujui, beberapa badge, gambar yang hilang, filter terpilih, catatan hukum panjang, dan field yang diisi browser. Saat kolom menumpuk, konfirmasi bahwa urutan bacaan dan keyboard masih masuk akal. Lengkapi formulir nyata pada perangkat kecil: buka kontrol, koreksi kesalahan, dan kirim. Uji widget pihak ketiga pada halaman yang mirip produksi karena container, status persetujuan, font, dan gaya mereka dapat mengubah hasil.

Gunakan data uji yang aman

Cerminkan panjang dan kombinasi maksimum yang mungkin, tetapi jangan sertakan data pelanggan atau pembayaran dalam bukti QA.

Periksa overlay bersama-sama

Buka notifikasi, chat, promosi, dan pesan validasi bersama; tidak satu pun boleh menutupi aksi utama atau field yang sedang fokus.

04

Jalankan setiap jalur input

Layar besar tidak menjamin mouse, dan layar kecil tidak menjamin hanya sentuhan. Media feature hover menguji apakah input utama dapat meng-hover dengan mudah, jadi hover harus meningkatkan pengalaman dan bukan menjadi satu-satunya jalan menuju aksi atau penjelasan. Uji penggunaan keyboard dan pointer di desktop, ketukan dan pengguliran pada perangkat sentuh, dan perangkat input campuran bila relevan. Tinjau tombol tutup kompak, steppers, chip, kalender, dan aksi ikon. WCAG 2.2 Target Size (Minimum) menentukan ukuran target 24 by 24 CSS-pixel dengan pengecualian yang didefinisikan, termasuk spasi dan tautan inline. Itu adalah kriteria dengan ruang lingkup dan pengecualian, bukan janji bahwa setiap kontrol 24-piksel sama mudahnya untuk semua orang.

Ikuti fokus

Tab melalui halaman. Fokus harus tetap terlihat, mengikuti urutan yang masuk akal, dan masuk serta keluar menu dan dialog secara dapat diprediksi.

Hindari tugas hanya-berbasis-hover

Buat pengungkapan hover penting tersedia melalui fokus, ketukan, atau kontrol yang terlihat, dan cegah perilaku ketukan-pertama yang membingungkan.

05

Verifikasi aset dan kinerja di bawah keterbatasan

Sebuah gambar bisa pas di kontainernya namun tetap file yang salah untuk perangkat. Periksa bahwa media tetap tertata dalam kontainer, menyisakan ruang tata letak bila perlu, mempertahankan crop yang berguna, dan meminta kandidat yang sesuai. srcset dan sizes memberi browser informasi untuk memilih antara sumber gambar yang disediakan; itu tidak menjamin permintaan tertentu. Gunakan throttling DevTools untuk menemukan masalah lebih awal, tetapi kontrol CPU dan jaringan-nya mensimulasikan kondisi relatif terhadap komputer pengembangan. Periksa ulang jalur kunci pada perangkat nyata dan koneksi nyata. Inspeksi font, hero media, carousel, pekerjaan sisi-klien, dan skrip pihak ketiga untuk keterlambatan, pergeseran, atau ketukan yang tertutup.

Tinjau permintaan

Tangkap rute, viewport, koneksi nyata atau disimulasikan, dan apa yang menjadi lambat atau tidak stabil; bandingkan kondisi yang sepadan.

Uji inti tanpa tambahan

Jika aman, tunda embed yang tidak penting di build uji untuk mengetahui apakah tugas inti tetap dapat digunakan.

06

Tindaklanjuti sebagai pekerjaan kesiapan uptime proaktif

Untuk Status Is UP, kesiapan responsif adalah optimasi uptime proaktif: identifikasi jalur perangkat yang memblokir pengguna, koreksi penyebabnya, buktikan perbaikan, dan cegah berulang. Ini bukan klaim bahwa alert pemantauan dapat menilai setiap cacat tata letak atau interaksi. Prioritaskan menurut dampak tugas dan jangkauan. Sebelum penyebaran, uji lebar yang berdekatan dan perjalanan yang diubah pada perangkat nyata. Rencanakan rollback untuk perubahan pada navigasi bersama, gaya, skrip, pembayaran, atau integrasi. Setelah rilis, ulangi langkah pembuktian dan lampirkan bukti pada catatan perubahan.

Tulis cacat yang dapat direproduksi

Nyatakan rute, perangkat atau viewport, orientasi, input, status, hasil yang diharapkan, hasil aktual, dan tangkapan layar yang disunting (redacted).

Perbaiki sumbernya

Utamakan perbaikan komponen, aturan tata letak, token, atau pengiriman gambar daripada override hanya pada rute; berikan pengecualian pemilik dan rencana penghapusannya.

TINDAKAN / VERIFIKASI

Panduan tugas praktis Anda.

  1. 01

    Pilih jalur dan keadaan

    Sebutkan rute bernilai tinggi dan menu, formulir, drawer, media, tabel, banner, embed, serta jalur masuk atau pembayaran mereka.

    VERIFIKASI: Lembar uji mengidentifikasi rute, hasil tugas, komponen, pemilik, dan keadaan konten.
  2. 02

    Tetapkan cakupan lebar dan orientasi

    Uji lebar sempit, sedang, mirip tablet, laptop, dan desktop lebar, plus kedua sisi setiap breakpoint yang didorong konten.

    VERIFIKASI: Setiap breakpoint utama memiliki hasil segera di bawah dan di atasnya, plus hasil lanskap yang relevan.
  3. 03

    Periksa viewport, reflow, dan zoom

    Ubah ukuran secara kontinu dan cari pengguliran horizontal, pemotongan, tumpang tindih, konten tersembunyi, dan UI tetap yang menutupi tugas.

    VERIFIKASI: Teks dan kontrol biasa tetap dapat digunakan; dokumentasikan uji 320 CSS-pixel dan zoom yang berlaku ketika menargetkan Reflow WCAG.
  4. 04

    Tekan konten seperti produksi

    Jalankan keadaan panjang, kosong, error, terpilih, media hilang, dan diisi browser menggunakan data uji yang aman.

    VERIFIKASI: Informasi yang diwajibkan tetap tersedia dan urutan visual, bacaan, serta fokus tetap logis.
  5. 05

    Selesaikan tugas dengan keyboard dan sentuh

    Tab melalui desktop dan ketuk melalui perangkat sentuh nyata, termasuk menu, dialog, kontrol terdekat, error, dan pengiriman.

    VERIFIKASI: Fokus terlihat, aksi penting tidak memerlukan hover, dan ketukan tidak memicu aksi tetangga.
  6. 06

    Inspeksi aset dan kinerja terbatas

    Tinjau gambar, font, video, konten tersemat, dan permintaan pada ukuran yang dirender; gunakan emulasi dan pemeriksaan ulang perangkat nyata.

    VERIFIKASI: Aset tidak menyebabkan overflow atau pergeseran tata letak yang dapat dihindari, dan bukti membedakan simulasi dari pengujian perangkat fisik.
  7. 07

    Catat dan perbaiki penyebab bersama

    Tangkap kegagalan yang dapat direproduksi, lalu perbaiki komponen, aturan aset, atau aturan tata letak daripada menutupi satu rute.

    VERIFIKASI: Bukti sebelum-dan-sesudah menunjukkan masalah asli dan pemeriksaan lebar-adjacent atau komponen yang digunakan ulang lulus.
  8. 08

    Rilis dengan kontrol pemulihan

    Gunakan kontrol perubahan normal untuk gaya bersama, skrip, pembayaran, identitas, atau perubahan vendor dan tentukan cara membalik kerusakan.

    VERIFIKASI: Catatan rilis menyebutkan pemilik, langkah validasi, titik keputusan rollback, dan recheck pasca-rilis.
TOPIK DISKUSI

Bandingkan kompromi, bukan data pribadi.

Gunakan prompt ini dengan tim Anda atau komunitas pemilik situs. Bagikan metode dan pelajaran, tetapi jangan pernah menempelkan kredensial, data pelanggan, atau detail infrastruktur yang tidak bersifat publik.

  1. 01

    Jalur pelanggan mana yang mengekspos cacat responsif paling berguna bagi Anda, dan kondisi uji apa yang membuatnya dapat direproduksi?

  2. 02

    Bagaimana tim Anda memutuskan bahwa sebuah breakpoint didorong oleh konten daripada oleh model perangkat tertentu?

  3. 03

    Bukti apa yang Anda simpan agar perubahan tema, konten, atau vendor berikutnya tidak memperkenalkan kembali masalah responsif yang terpasang?

SUMBER POPULER / TERPERCAYA

Buka materi sumber.

web.devResponsive web design basics ↗

Panduan praktis tentang viewport, tata letak fleksibel, breakpoint yang didorong konten, kemampuan input, dan overflow.

Ditinjau 2026-09-27
W3C Web Accessibility InitiativeUnderstanding Success Criterion 1.4.10: Reflow ↗

Menjelaskan kondisi reflow WCAG 2.1 AA dan pengecualian tata letak dua dimensi yang terbatas.

Ditinjau 2026-09-27
W3C Web Accessibility InitiativeUnderstanding Success Criterion 2.5.8: Target Size (Minimum) ↗

Mendefinisikan uji ukuran target 24 by 24 CSS-pixel, aturan spasi, dan pengecualian WCAG 2.2.

Ditinjau 2026-09-27
Chrome for DevelopersSimulate mobile devices with Device Mode ↗

Membahas viewport, orientasi, sentuh, throttling, dan batasan simulasi desktop.

Ditinjau 2026-09-27
web.devDescriptive syntaxes ↗

Menjelaskan bagaimana srcset dan sizes mendeskripsikan sumber gambar responsif agar browser memilihnya.

Ditinjau 2026-09-27
MDN Web Docshover CSS media feature ↗

Mendefinisikan apa yang diuji media feature hover sehingga tim tidak menganggap hover bersifat universal.

Ditinjau 2026-09-27

Kebijakan sumber. Artikel ini menggunakan standar resmi, dokumentasi vendor browser, dan dokumentasi platform web yang dibaca selama penelitian. Tautan navigasi bukan sumber bukti. Dapatkan tinjauan yang memenuhi syarat untuk keputusan khusus situs terkait aksesibilitas, pembayaran, keamanan, hukum, atau browser yang didukung.

PENJELASAN SINGKAT

Pertanyaan umum.

Perangkat mana yang harus saya uji untuk desain responsif?

Gunakan set cakupan daripada mencoba mencakup setiap model: lebar sempit, sedang, mirip tablet, laptop, dan desktop lebar, plus breakpoint tempat konten berubah. Tambahkan perangkat nyata yang mewakili jalur pelanggan penting dan gunakan lanskap saat itu mengubah pengalaman.

Apakah Chrome Device Mode cukup untuk QA responsif?

Tidak. Ia secara efisien menyoroti masalah viewport, orientasi, event sentuh, dan throttling, tetapi Chrome menggambarkannya sebagai perkiraan, bukan kode yang berjalan pada perangkat. Gunakan untuk cakupan luas, lalu selesaikan tugas kritis pada perangkat fisik.

Apakah saya perlu situs seluler terpisah untuk menjadi responsif?

Biasanya, tidak. Desain responsif menyesuaikan satu pengalaman melalui tata letak fleksibel, media queries bila perlu, dan aset responsif. Ujiannya adalah apakah tugas pelanggan yang didukung, konten, aksesibilitas, dan kinerja bekerja dalam konteks yang Anda dukung.

Status Is UP Editorial Team · Uptime Enablement Editors

Ditinjau oleh Front-End Accessibility and Performance Reviewer. Diterbitkan 2026-09-27; diperbarui 2026-09-30.