Satuan 3 / 11

Desain Antarmuka dan Pembuatan Kode UI dengan Kecerdasan Buatan

Keuntungan:

  • Kemampuan untuk menghasilkan kode antarmuka yang kuat untuk Jetpack Compose dan SwiftUI dalam urutan tujuan, komponen, empat status (memuat/kosong/kesalahan/penuh), sistem desain, dan aksesibilitas
  • Kemampuan untuk menghasilkan antarmuka yang terbuka untuk semua pengguna dengan mendefinisikan aksesibilitas sejak awal, dengan pelabelan yang benar, kontras yang memadai, dan sentuhan yang sesuai.
  • Kemampuan untuk membuat antarmuka yang konsisten, multi-bahasa dan tema terang/gelap dengan membaca warna dan ruang dari tema sentral

Keberhasilan aplikasi seluler sangat ditentukan oleh antarmuka penggunanya (UI — layar yang dilihat dan disentuh pengguna) dan pengalaman pengguna (UX — seberapa lancar dan menyenangkan penggunaannya). Pengguna tidak melihat kode yang buruk, tetapi merasakan antarmuka yang buruk di detik pertama. AI memainkan dua peran penting dalam pengembangan antarmuka: di satu sisi, AI menghasilkan ide desain, alur, dan teks (penulisan UX); Di sisi lain, ini secara langsung mengubah desain ini menjadi kode antarmuka yang berfungsi. Dalam unit ini, kita akan mempelajari cara menghasilkan antarmuka yang cepat, mudah diakses, dan konsisten dengan AI, dengan fokus pada alat antarmuka deklaratif modern Jetpack Compose (Android) dan SwiftUI (iOS). "Deklaratif" berarti bahwa alih-alih menjelaskan langkah demi langkah cara menggambar layar, Anda menjelaskan "seperti inilah seharusnya tampilan layar dalam situasi ini"; Alat ini akan melakukan sisanya.

Dari desain hingga kode: urutan yang benar

Menyuruh AI untuk "membuat layar yang indah" tidaklah jelas karena "keindahan" tidak dapat diukur. Pembuatan antarmuka yang baik mengikuti urutan ini:

  1. Tujuan dan konten. Apa yang dilakukan layar, informasi apa yang ditampilkan, apa yang akan dilakukan pengguna?
  2. Daftar komponen. Bagian seperti judul, daftar, tombol, bidang formulir.
  3. Situasi. Memuat, kosong (tidak ada data), kesalahan, penuh — empat status dasar layar.
  4. Sistem desain. Warna, tipografi, aturan spasi; umumnya mematuhi Pedoman Antarmuka Manusia Material 3 (Android) atau iOS.
  5. Aksesibilitas. Label pembaca layar, kontras memadai, ukuran target sentuh.
  6. Kode. Karena itu semua, generasi Tampilan Composable atau SwiftUI.

Langkah yang paling sering dilewati adalah langkah ketiga. Pengembang hanya mempertimbangkan keadaan "penuh"; sedangkan dalam aplikasi nyata pengguna kebanyakan menghadapi situasi "loading" dan "error". Mencetak keempat status ke AI adalah rahasia antarmuka yang kuat.

Tip: Tambahkan "hasilkan pemuatan, kosong, kesalahan, dan penuh secara terpisah" di akhir perintah. Kalimat tunggal ini membuat antarmuka Anda siap untuk dunia nyata dan secara signifikan mengurangi jumlah kesalahan dalam fase QA (pengujian kualitas).

Aksesibilitas tidak dapat dinegosiasikan

Aksesibilitas — kemampuan untuk menggunakan aplikasi oleh pengguna dengan disabilitas penglihatan, pendengaran, atau motorik — merupakan tanggung jawab etis sekaligus ekspektasi hukum. AI menghasilkan kode yang dapat diakses jika diinginkan; Mengembalikan antarmuka tanpa tag dan kontras rendah jika tidak diinginkan. Tiga aturan praktis: berikan setiap elemen interaktif label yang bermakna bagi pembaca layar (contentDescription/accessibilityLabel), kontras warna yang memadai antara teks dan latar belakang (setidaknya rasio 4,5:1), dan target sentuh minimal 48x48 dp/44x44 pt. Tanyakan kepada AI hal-hal ini secara eksplisit.

Perhatian: AI juga dapat menambahkan tag aksesibilitas panjang ke ikon dekoratif; Ini membuat pengguna pembaca layar kewalahan dengan obrolan yang tidak perlu. Elemen dekoratif murni harus "disembunyikan dari aksesibilitas" (diizinkan dilewati oleh pembaca layar). Tinjau kembali label yang dihasilkan: biarkan yang bermakna berbicara, biarkan yang dekoratif tetap diam.

Konsistensi: sistem desain dan tema

Aplikasi profesional tidak menggunakan warna dan spasi acak; mengikuti sistem desain (kumpulan standar warna, font, spasi, dan komponen). Jika Anda memberi AI nilai tema Anda (warna utama, warna sekunder, radius sudut, skala tipografi), semua layar akan terlihat konsisten. Jika tidak, setiap layar akan menggunakan warna biru yang berbeda dan aplikasi akan terlihat berantakan. Cara paling efisien adalah dengan terlebih dahulu meminta AI untuk membuat file token tema/desain, lalu mengikat semua layar ke tema tersebut.

Subyek

pendekatan yang buruk

Pendekatan yang kuat

Warna

Beri kode warna secara manual pada setiap layar

Tema sentral, layar dibaca dari tema

situasi

Hanya layar "penuh".

Memuat/kosong/kesalahan/empat status penuh

aksesibilitas

Ditambahkan nanti

Hal ini didefinisikan dalam klaim sejak awal

teks

tertanam dalam kode

Sumber terpisah, siap multi-bahasa

tiga kasus mini

Kasus 1 — Kasus kosong disimpan. Tim aplikasi berita meminta AI mencetak status layar individual. Berkat layar “status menganggur” (“Belum ada berita yang disimpan”), 70% peserta pengujian pengguna tidak meninggalkan aplikasi di layar kosong; Pada versi sebelumnya, layar kosong tetap berwarna putih dan pengguna mengira itu "rusak" dan dibiarkan. Salinan kecil meningkatkan tingkat retensi.

Kasus 2 — Penolakan kontras. Satu tim melamar ke App Store dengan layar dengan teks berwarna abu-abu terang, warna merek. Apple mengeluarkan peringatan atas dasar aksesibilitas karena kontras yang rendah. Ketika AI diberitahu untuk "meningkatkan kontras latar belakang teks di atas 4,5:1", warna menjadi lebih gelap dan masalahnya terpecahkan. Kalau sudah diminta dari awal, tidak akan ada penundaan.

Kasus 3 — Kebisingan label dekoratif. Seorang penguji tunanetra melaporkan bahwa setiap ikon ornamen (“garis”, “titik”, “bayangan”) dibacakan dengan lantang di layar yang dihasilkan AI, sehingga layar tidak dapat digunakan. Pengalaman pembaca layar menjadi lancar ketika elemen dekoratif disembunyikan dari aksesibilitas. Pelajaran: aksesibilitas berarti “tag yang tepat”, bukan “terlalu banyak tag”.

Perintah lemah / Perintah kuat

Perintah lemah: "Rancang layar profil."

Prompt yang kuat: "Buat layar profil pengguna untuk iOS/SwiftUI. Konten: avatar, nama, email, tombol 'Edit profil', daftar pengaturan. Status: memuat (kerangka), kesalahan (tombol coba lagi), penuh. Desain: Non-Material, sesuai dengan iOS HIG; warna sistem, Tipe Dinamis. Aksesibilitas: aksesibilitasLabel ke setiap elemen, ikon dekoratif disembunyikan, target sentuh min 44pt. Baca nilai tema dari file terpisah, jangan sematkan kode warna di layar. Pertama gambar komponennya pohon, lalu ekspor kodenya."

Templat yang dapat disalin

Templat pembuatan layar: "Buat [nama layar] untuk [platform/alat]. Konten: [elemen]. Tindakan pengguna: [tindakan]. Hasilkan empat status secara terpisah: memuat, kosong, kesalahan, penuh. Sistem desain: [Material 3 / iOS HIG], dibaca dari token tema. Aksesibilitas: label, kontras >=4,5:1, standar target sentuh."

Templat sistem tema/desain:"Hasilkan definisi tema sentral untuk aplikasi saya ([Tulis Tema /struktur token desain di SwiftUI]):- Warna primer [hex], [hex] sekunder, warna kesalahan, warna permukaan- Skala tipografi (judul, isi, deskripsi)- Skala jarak (4,8,16,24)- Standar radius sudutTambahkan dukungan tema terang dan gelap."

Templat audit aksesibilitas:"Periksa kode layar ini untuk aksesibilitas:1) Apakah ada elemen interaktif yang tidak diberi tag?2) Apakah rasio kontras memadai?3) Apakah target sentuh cukup besar?4) Apakah elemen dekoratif disembunyikan dari pembaca layar?Sarankan perbaikan untuk setiap masalah. [kode]"

Desain ke templat kode: "Saya menjelaskan desain berikut: [deskripsi layar atau tangkapan layar]. Terjemahkan ini ke dalam kode [Tulis/SwiftUI]. Pertahankan spasi dan perataan sesuai dengan desain, tetapi tambahkan keempat status."

Kesalahan umum

  • Hanya memikirkan situasi selengkapnya. Seringkali pengguna sebenarnya melihat layar pemuatan/kesalahan.
  • Menanamkan warna dan spasi dalam kode. Jika temanya tidak sentral, konsistensi akan hilang dan pemeliharaan menjadi sulit.
  • Meninggalkan aksesibilitas untuk yang terakhir. Menambahkannya nanti itu mahal; Ini gratis jika diminta dari awal.
  • Memberi label berlebihan. Membaca elemen dekoratif juga mengganggu pengalaman pembaca layar.
  • Menyematkan teks dalam kode. Ketika dukungan multibahasa diperlukan, setiap layar perlu diubah secara manual; Pisahkan teks.
  • Mengharapkan salinan persis dari tangkapan layar. Desain AI menghasilkan sekitar. Presisi piksel diatur secara manual.

Singkatnya

AI sangat kuat dalam produksi antarmuka, tetapi memerlukan panduan. Urutan yang benar: tujuan, komponen, empat status (memuat/kosong/kesalahan/penuh), sistem desain, aksesibilitas, lalu kode. Aksesibilitas tidak dapat dinegosiasikan dan berarti “label yang tepat”, bukan “terlalu banyak label”. Untuk konsistensi, baca warna dan spasi dari tema sentral, jangan sematkan dalam kode. Kemauan yang kuat menentukan semua ini sejak awal; Dengan demikian, antarmuka siap untuk dunia nyata, persetujuan toko, dan semua pengguna.

Tugas aplikasi

Dengan menggunakan “Template pembuatan layar” untuk layar pengaturan, minta AI untuk kode Compose atau SwiftUI dan minta keempat status. Kemudian periksa kode yang sama dengan "Templat pemeriksaan aksesibilitas". Temukan dan perbaiki setidaknya satu peningkatan aksesibilitas (label hilang, kontras rendah, atau target sentuh kecil) dan catat status mana (memuat/kosong/kesalahan) yang menurut Anda paling sering muncul dalam penggunaan sebenarnya.

daftar periksa

  • [ ] Saya memperjelas tujuan dan komponen tampilan di prompt
  • [ ] Saya membuat empat status (memuat/kosong/kesalahan/penuh) secara terpisah
  • [ ] Saya membuat warna dan ruang dibaca dari tema sentral, saya tidak menyematkannya ke dalam kode.
  • [ ] Saya menginginkan label aksesibilitas dan kontras sejak awal
  • [ ] Saya memverifikasi bahwa elemen dekoratif disembunyikan dari pembaca layar
  • [ ] Saya menyimpan teksnya secara terpisah, siap untuk berbagai bahasa