Wireframing dan Prototaip yang Bertahan dalam Kejuruteraan

Kali pertama ia berlaku kepada saya, saya hampir berhenti kerja.

Saya telah menghabiskan tiga minggu pada aliran tetapan. Fail Figma yang cantik. Setiap skrin. Keadaan kursor pada muat naik avatar kerana saya peduli. Jurutera membinanya. Keadaan kosong adalah kotak kelabu yang malang dengan perkataan "Empty" dalam Arial 12px. Toast ralat adalah bar merah lalai pelayar. Pemuatan adalah pemintal generik yang muncul serta-merta, walaupun pada dev tempatan di mana permintaan mengambil masa 40ms. Mesej pengesahan? Tooltip HTML <input> asli yang berkata "sila padankan format yang diminta."

Saya menghubungi jurutera. Dia berkata, dengan tenang, "anda tidak menyatakan spesifikasinya." Saya marah. Saya kembali ke Figma. Dia betul. Memang saya tidak menyatakan spesifikasinya.

Perbualan itu adalah keseluruhan sebab panduan ini wujud. Kejuruteraan bukan musuh. Jurang spesifikasi adalah musuh. Dan jurang spesifikasi adalah masalah UX, bukan masalah jurutera.

Mengapa ini penting sekarang

Kira kos satu kerja semula. Satu ciri. Satu sprint. Keadaan kosong salah, pengendalian ralat tiada, jurutera perlu memfaktorkan semula komponen kerana varian tidak ada dari awal. Dari empat kerja terakhir saya, kos purata satu kerja semula seperti ini adalah sekitar 40 jam pereka dan 60 jam jurutera. Itu 100 jam orang, kos campuran lebih kurang $12,000 hingga $15,000 bergantung kepada pasukan anda. Satu kerja semula sesuku dan anda telah membakar $50,000 setahun untuk kerja ulang yang dokumen penyerahan yang lebih baik akan mencegahnya.

Itu hanya dari segi wang. Kos kepercayaan lebih teruk. Selepas kerja semula kedua, jurutera berhenti mempercayai spesifikasi anda dan mula membina apa yang mereka fikir anda maksudkan. Selepas yang ketiga, PM anda berhenti mempercayai garis masa anda kerana "reka bentuk sentiasa memerlukan satu pusingan lagi." Penyerahan bukan sekadar penyerahan. Ia adalah kontrak. Layani ia seperti kontrak dan kebanyakan ini akan hilang.

Kesetiaan rendah berbanding kesetiaan tinggi: bila setiap satu berbaloi

Kesilapan terbesar yang saya lihat pereka junior lakukan adalah melompat ke kesetiaan tinggi terlalu awal. Mock piksel-sempurna sebelum aliran dikunci. Jurutera melihatnya, teruja, mula membina. Kemudian penyelidikan datang kembali dan aliran berubah. Kini jurutera telah menghantar separuh perkara yang salah dalam kod pengeluaran dan seseorang perlu menerangkan kepada PM mengapa sprint terlewat.

Kesetiaan rendah adalah untuk logik aliran dan sokongan pihak berkepentingan. Lakaran kertas, Balsamiq, bingkai Figma yang kasar dengan segi empat tepat pemegang tempat. Soalan yang dijawab adalah "adakah ini idea yang betul?" Jangan sempurnakan piksel skrin yang mungkin anda buang esok. Hasilnya adalah prototaip yang boleh diklik yang membuktikan laluan dari A ke B masuk akal, ditambah diagram aliran. Itu sahaja.

Kesetiaan tinggi adalah untuk pembinaan. Piksel-sempurna, salinan sebenar (tiada lorem ipsum, sekali-kali, kerana jurutera akan salin-tampalnya dan anda akan menemui "Lorem ipsum dolor" pada halaman log masuk langsung, tanya saya bagaimana saya tahu), bentuk data sebenar, semua keadaan. Hanya selepas aliran dikunci. Jika anda mendapati diri anda membetulkan butiran susun atur pada skrin yang alirannnya masih diperdebatkan, berhenti. Kembali ke kesetiaan rendah. Kunci aliran dahulu.

Ujian jujur: jika pihak berkepentingan masih bertanya "tunggu, mengapa pengguna pergi ke sini?" anda belum bersedia untuk kesetiaan tinggi. Tidak kira betapa cantiknya segi empat tepat itu.

Jurang spesifikasi yang akan ditanya jurutera (dan yang tidak anda reka bentuk)

Ini adalah bahagian yang tidak diajar di sekolah reka bentuk. Setiap skrin mempunyai lebih kurang lapan keadaan. Anda mungkin telah mereka bentuk dua daripadanya. Inilah senarai yang akan dilemparkan jurutera kembali kepada anda saat mereka duduk untuk membina:

Lapan keadaan yang diperlukan setiap skrin

1. Lalai / diisi. Laluan gembira. Anda mereka bentuk yang ini.
2. Kosong. Sifar item, sifar keputusan, pengguna pertama kali. Apa yang dilihat pengguna apabila tiada apa-apa untuk dilihat? "Tiada item lagi" bukan reka bentuk. Tunjukkan ilustrasi, salinan CTA, tindakan sekunder.
3. Memuatkan. Skeleton, pemintal, UI optimistik. Dan peraturan masa: berapa lama sebelum pemintal muncul? (200ms adalah ambang piawai; tunjukkan tiada apa-apa di bawahnya.)
4. Ralat. Kegagalan API, pengesahan, akses dinafikan, rangkaian di luar talian. Setiap satu adalah berbeza. Ralat 500 tidak kelihatan seperti 403, yang tidak kelihatan seperti "kata laluan anda terlalu pendek."
5. Separa / terdegradasi. Separuh data dimuatkan, beberapa imej rosak, widget pihak ketiga tidak berfungsi. Sistem sebenar sentiasa mencapai ini.
6. Varian kebenaran. Pentadbir, ahli, penonton, tetamu. Apa yang disembunyikan berbanding dilumpuhkan berbanding ditunjukkan-dengan-tooltip?
7. Data tepi. Nama panjang yang berbungkus, nombor 0 / null / negatif, 47 item dalam senarai yang direka bentuk untuk 5, ID cukai dengan 32 aksara.
8. Mudah alih / titik putus. Jika reka bentuk adalah desktop-dahulu, apa yang berlaku pada 768px dan 375px? "Responsif" bukan spesifikasi.

Saya menyimpan senarai ini bersebelahan monitor saya. Sebelum mana-mana penyerahan, saya memeriksa setiap skrin terhadap lapan keadaan. Jika sesuatu keadaan adalah "sama seperti lalai," saya tulis itu. Jika ia adalah "di luar skop untuk sprint ini," saya tulis itu juga. Tujuannya bukan untuk mereka bentuk semua lapan sentiasa. Tujuannya adalah untuk memutuskan semua lapan, dengan sengaja, dan meletakkan keputusan itu dalam fail.

Jurang lapan-keadaan adalah kegagalan paling biasa yang saya lihat. Betulkan satu perkara ini dan anda telah menghapuskan mungkin 60% momen "anda tidak menyatakan spesifikasinya."

Disiplin Auto-Layout Figma

Auto-Layout bukan pilihan. Jika fail anda tidak dibina di atasnya, jurutera tidak dapat melihat apa yang merupakan komponen dan apa yang merupakan bingkai, tidak dapat membezakan padding dari margin, tidak dapat meramalkan apa yang berlaku apabila salinan bertambah panjang. Mereka meneka. Mereka meneka salah. Kemudian ia menjadi kesalahan anda.

Empat peraturan yang telah menjimatkan berjam-jam untuk saya:

1. Komponen, bukan bingkai yang dilepaskan. Setiap elemen yang boleh digunakan semula adalah komponen dengan nama yang boleh dibaca jurutera. Butang adalah Button/Primary/Default, bukan Rectangle 47. Jika jurutera tidak dapat melihat nama komponen dalam pemeriksaan, mereka meneka.
2. Token jarak sebenar, bukan margin yang dikira mata. 4, 8, 12, 16, 24, 32. Itu sahaja. Jika anda mendapati diri anda menaip padding: 13px anda melakukan perkara yang salah. Pilih satu dan teruskan.
3. Kekangan ditetapkan supaya pengubahan saiz benar-benar berfungsi. Uji setiap komponen pada saiz terbesar dan terkecil yang boleh dimilikinya. Jika kad pecah apabila tajuk mempunyai 80 aksara, jurutera akan menemui pepijat itu dalam pengeluaran.
4. Varian untuk keadaan. Lalai, kursor, aktif, dilumpuhkan, memuatkan, ralat. Semuanya dalam satu komponen, boleh ditukar melalui sifat. Jurutera menghubungkan varian kepada mesin keadaan dan fail menjadi mendokumentasikan dirinya sendiri.

Ujian bau yang berguna: buka fail anda, klik mana-mana elemen, dan lihat panel sebelah kanan. Jika anda tidak dapat tahu secara sekilas komponen apa itu, varian apa yang ada padanya, dan token jarak apa yang digunakannya, jurutera juga tidak dapat. Betulkan sebelum penyerahan.

Token reka bentuk: kontrak dengan jurutera

Token reka bentuk adalah perkara paling berpengaruh yang boleh dihantar pereka UX. Warna, skala taip, jarak, jejari, bayang, tempoh gerakan: semuanya dinamakan, semuanya ditakrifkan sekali, semuanya dirujuk dengan nama dalam setiap komponen.

Kontraknya mudah. Apabila token berubah (katakan, jenama dikemas kini dari #0066FF ke #0052CC), jurutera mengubah satu pemboleh ubah, bukan 40 komponen. Begitu juga untuk skala taip, jejari, setiap bayang.

Sistem pemasangannya sudah benar-benar baik. Figma Variables untuk sumber kebenaran. Tokens Studio (atau eksport Variables asli) untuk menolak ke JSON. JSON diimport ke dalam konfigurasi Tailwind, pemboleh ubah CSS, atau binaan Style Dictionary. Jurutera tidak pernah menaip nilai hex secara manual. Anda tidak pernah memilih semula warna dari ingatan.

Jika anda belum menggunakan token, ini adalah pelaburan dengan ROI tertinggi yang boleh anda buat suku ini. Migrasi pertama mengambil masa seminggu. Setiap penyerahan selepas itu menjadi lebih murah.

Dokumen penyerahan: Loom ditambah anotasi

Dokumen penyerahan adalah kontrak. Penyerahan lisan adalah tidak. "Saya hanya akan bercakap dengan jurutera" adalah jalan pintas yang paling mahal dalam reka bentuk. Perbualan di lorong adalah hebat untuk menjelaskan. Ia mengerikan untuk menentukan spesifikasi, kerana tiga minggu kemudian apabila QA menemui jurang, tiada siapa yang ingat apa yang anda katakan.

Inilah rupa dokumen penyerahan, dalam tiga bahagian.

Bahagian 1: Loom 5 minit melalui aliran. Buka Figma, kongsi skrin, tekan rekod. Lalui aliran pada kadar pembangun yang tidak pernah melihatnya. Nyatakan: titik masuk, setiap skrin, tingkah laku yang tidak jelas ("perhatikan toast meluncur masuk, bukan memudar, 200ms ease-out"), dan setiap logik pertukaran keadaan ("ini dikosongkan apabila pengguna mempunyai sifar invois, tetapi jika mereka mempunyai invois dan memadam semuanya, kami tunjukkan varian 'semua dipadam', bukan kosong pertama kali"). Saya mengekalkan ini kepada struktur 3 minit: 30 saat konteks, 2 minit pandangan aliran, 30 saat isu penting, 30 saat soalan-kepada-jurutera.

Bahagian 2: Bingkai Figma beranotasi. Anotasi bernombor pada setiap skrin. Bukan nota pelekat merah. Anotasi bernombor sebenar yang dibaca seperti kontrak. "1: Avatar. Klik membuka modal muat naik. Modal ditutup pada Esc, pada klik hamparan, dan pada muat naik yang berjaya." Setiap interaksi. Setiap masa animasi. Setiap kes tepi yang ditemui pandangan lapan-keadaan.

Bahagian 3: Kriteria penerimaan dalam bahasa jurutera. Ini adalah bahagian yang dilepaskan oleh pereka dan tidak sepatutnya. Kriteria penerimaan kelihatan seperti:

Apabila pengguna mengklik "Simpan" dengan e-mel tidak sah, maka dalam masa 200ms ralat sebaris muncul di bawah medan dengan teks "Sila masukkan alamat e-mel yang sah," medan mendapat sempadan merah (token: border-error), dan fokus kekal pada medan.

Itu adalah tiga fakta tingkah laku (masa, salinan, keadaan fokus) yang boleh disahkan oleh QA dan boleh dibina oleh jurutera. Tulis lima hingga sepuluh ini setiap skrin untuk mana-mana interaksi yang tidak remeh. Ya, ia lambat. Ia lambat dengan sengaja. Bahagian yang lambat itulah tempat jurang spesifikasi mati.

Satu peraturan terakhir: pautan ke satu bingkai Figma sumber kebenaran tunggal. Bukan 12 fail. Bukan "lihat exploration v3 dan v5 tapi bukan v4." Satu bingkai. Satu URL. Jika anda perlu menunjuk kepada berbilang fail, jurutera akan memilih yang salah dan anda patut menerimanya.

Mod kegagalan "Saya hanya akan bercakap dengan jurutera"

Saya kenal pereka yang berbangga dengan hubungan jurutera yang rapat dan menganggap penyerahan bertulis sebagai beban tambahan. Saya faham. Saya pernah menjadi salah seorang daripada mereka. Hubungan itu sebenar dan patut dilaburkan. Tetapi hubungan itu bukan pengganti dokumen.

Tiga masalah dengan penyerahan lisan:

1. Tiada rekod. Enam minggu kemudian apabila QA menemui jurang, anda dan jurutera akan separuh ingat perbualan yang berbeza. Sesiapa yang mempunyai lebih banyak modal politik menang. Itukan cara bahagian reka bentuk sepatutnya berfungsi.
2. Tiada pemahaman bersama. Jurutera meninggalkan panggilan dengan tafsiran mereka. Anda meninggalkan dengan tafsiran anda. Pertindihan mungkin 70%. Jurang 30% itu adalah tempat pepijat hidup.
3. Tiada cara untuk mengesahkan selepas penghantaran. Apabila anda duduk untuk QA pembinaan, tiada apa-apa untuk disemak. Anda sedang melakukan QA terhadap perasaan.

Peraturan yang kini saya ikuti: jika tidak ditulis, ia tidak berlaku. Loom ditulis (ia adalah rakaman). Anotasi ditulis. Kriteria penerimaan ditulis. Perbualan di lorong "hei, boleh anda juga lakukan X" mendapat susulan bertulis dalam masa sejam, atau X tidak akan dibina.

Ulasan selepas penghantaran

Penyerahan tidak selesai apabila jurutera menggabungkan. Ia selesai apabila anda telah melakukan QA ke atas pembinaan langsung terhadap Figma, bersama-sama, dan merekodkan jurang.

Cara saya menjalankannya: mesyuarat 30 minit pada persekitaran sandbox atau peringkat. Pereka dan jurutera berkongsi skrin. Lalui setiap skrin dan setiap keadaan. Untuk setiap satu, tiga kemungkinan hasil:

• Padanan. Teruskan.
• Jurang, betulkan sprint ini. Rekodkannya, failkan pepijat, jurutera berkomitmen untuk pembaikan. Biasanya 1-2 daripadanya sesatu ciri.
• Jurang, terima dan kemaskini Figma. Kadangkala versi jurutera sebenarnya lebih baik, atau jurang terlalu kecil untuk bernilai satu sprint. Kemaskini Figma supaya sepadan dengan realiti. Jangan biarkan fail berbohong tentang apa yang ada dalam pengeluaran.

Dosa besar adalah pembaikan senyap. Jangan kemaskini secara pasif-agresif keluaran seterusnya tanpa memberitahu jurutera. Jangan buat-buat jurang tidak wujud. Rekodkan ia, putuskan bersama, teruskan. Selepas beberapa kitaran ini, jurutera mula mempercayai bahawa QA adalah kerjasama, bukan permusuhan. Mereka akan mula memberi amaran awal tentang kebimbangan mereka semasa pembinaan.

Sasaran yang munasabah: tidak lebih daripada 3 jurang yang direkodkan sesatu ciri yang dihantar, semakin kurang dari masa ke masa apabila disiplin lapan-keadaan semakin kukuh.

Mengukur kejayaan

Tiga isyarat memberitahu anda disiplin penyerahan berfungsi.

1. Sifar momen "anda tidak menyatakan spesifikasinya" sesprint. Ini adalah penunjuk lewat. Jika anda mengalami ini, panduan lapan-keadaan tidak dilakukan.
2. Jurutera memetik nama bingkai Figma dalam PR. "Melaksanakan Settings/Profile/Avatar-Upload v2." Apabila jurutera menulis mesej komit dan penerangan PR yang merujuk bingkai anda dengan nama, fail anda telah menjadi sumber kebenaran. Itulah matlamatnya.
3. Ulasan selepas penghantaran merekodkan tidak lebih 3 jurang sesatu ciri. Dan jurang itu arah ke arah kemasan visual kecil, bukan keadaan yang hilang atau tingkah laku yang salah.

Jika ketiga-tiga ini benar, anda telah menyelesaikan masalah penyerahan. Peranan anda beralih dari mempertahankan reka bentuk kepada memperluasnya. Yang akhirnya, itulah kerja yang sepatutnya dilakukan oleh UX.

Fail Figma bukan seni. Ia adalah kontrak. Tulis segala-galanya. Lalui lapan keadaan. Rekodkan Loom. Anotasi bingkai. Tulis kriteria penerimaan dalam bahasa jurutera. Jalankan ulasan selepas penghantaran. Lakukan ini lima kali berturut-turut dan kadar kerja semula anda jatuh hampir kepada sifar, dan anda berhenti takut Jumaat penyerahan.

Camellia

Ketahui Lebih Lanjut

• Peranan pendamping: templat JD Product Designer
• Bekerja dengan PM tanpa kehilangan jiwa reka bentuk anda
• Sehari dalam Kehidupan Pereka UX
• Penyelidikan Pengguna yang Menggerakkan Pelan Tindakan