Perubahan Visual dalam Sistem Desain

Kami Menghormati API Kode. Tapi Bagaimana dengan Warna, Jenis dan Ruang?

# 4 dari 6 seri Melepaskan Sistem Desain:
Keluaran | Irama | Versi | Breaking | Ketergantungan | Proses

Sistem desain menetapkan gaya visual dasar yang merupakan ketergantungan esensial. Pilihan-pilihan ini - warna, tipografi, ruang dan banyak lagi - ditentukan dengan kuat dan diharapkan secara stabil, dapat diprediksi mengubah rilis dengan rilis. Saat adopter meningkatkan, sistem desain seharusnya tidak merusak barang-barang mereka secara tidak terduga.

Jadi, tanyakan pada diri sendiri ...

Dapatkah pengguna meng-upgrade ke rilis kecil yakin bahwa UI mereka tidak akan rusak karena perubahan visual sistem?

Semantic Versioning (SemVer) menawarkan kriteria yang jelas untuk mengkomunikasikan perubahan lintas rilis menggunakan penunjukan mayor, minor, dan patch. Setiap sistem desain yang saya temui menggunakan SemVer dan memantau perubahan pada antarmuka pemrograman aplikasi atau API paket mereka. Ini adalah wilayah yang biasa bagi pengembang yang mengkode alat peraga JavaScript dan markup HTML. Hancurkan API Anda, dan versi Anda berikutnya harus meningkatkan versi ke rilis utama berikutnya, seperti dari 1.4.0 ke 2.0.0.

Menentukan antarmuka untuk gaya visual komposisional sulit bagi kami. Rasanya sulit untuk mendefinisikan aturan yang jelas dan sederhana untuk memantau perubahan gaya. Pembuat sistem berjuang untuk mengartikulasikan apa atau mengapa "Mengubah gaya ini mematahkan UI pengadopsi" versus "Mengubah gaya yang tidak." Beberapa tim sistem mendokumentasikan kriteria tersebut. Saya bertanya, “Jenis perubahan visual apa yang memicu versi utama untuk Anda?” Tanggapan mereka: ¯ \ _ (ツ) _ / ¯.

Dalam artikel ini, saya mengusulkan bahwa setidaknya kriteria Warna, Tipografi, dan Space menjamin perubahan melanggar. Ada properti lain yang perlu dipertimbangkan juga. Sistem desain dapat mendefinisikan, mendokumentasikan dan mengkomunikasikan kriteria ini sehingga pengadopsi dapat meningkatkan rilis dengan rilis dengan percaya diri.

Warna putus

Sebagian besar tim sistem merasa aman dalam menyetel warna latar tombol utama. Mungkin motivasi mereka adalah untuk meningkatkan kontras terhadap label teks putih yang biasanya. "Mari kita menggelapkannya sedikit," kata mereka. "Kami akan meningkatkan kontras warna yang dapat diakses tombol dari peringkat AA ke AAA."

Menyesuaikan warna latar belakang tombol utama

Tentu saja, tim adopsi tidak boleh mengesampingkan set warna tombol primer standar. Mengganti pilihan sistem akan memutus koneksi dengan sistem. Pada titik itu, seorang pengadopsi adalah milik mereka sendiri. Oleh karena itu, menyesuaikan naungan warna latar belakang tombol utama adalah aman dan bukan merupakan perubahan besar.

Namun, mengubah warna di tempat lain dapat membahayakan pengadopsi. Pertimbangkan skenario berikut.

Contoh: Teks Sistem pada Latar Belakang Kustom

Bayangkan sebuah tim sistem menyempurnakan biru interaktif untuk meningkatkan kontras warna. Biru interaktif dari v1.4.0 dapat diakses dengan latar belakang putih tetapi gagal pada latar belakang arang.

Pengecekan kontras warna melalui contrast-grid.eightshapes.com

Jadi, untuk v1.5.0, tim menyesuaikan warna interaktif-biru ke nada yang lebih ringan dan lebih jenuh yang bekerja pada warna putih dan arang.

Menyesuaikan warna teks label tombol hantu pada latar belakang yang tidak terduga

Namun, seorang pengadopsi telah menggunakan tombol Ghost tergantung pada warna itu pada latar belakang abu-abu terang. Setelah sistem berubah, kontras warna teks label tidak dapat diakses. Sistem Anda merusak produk mereka.

Contoh: Latar Belakang Sistem dengan Teks Overlay Kustom

Demikian pula, bayangkan suatu sistem menggelapkan warna latar belakang komponen Kartu. Area konten Kartu mencakup zona wadah konten "aman" tempat pengadopsi memasukkan konten dan markup apa pun yang mereka inginkan.

Menyesuaikan warna latar belakang Kartu yang memungkinkan konten khusus yang terkandung

Di zona yang mungkin aman itu, pengguna mengadopsi teks sekunder yang, meskipun abu-abu sedang, lulus uji kontras warna. Setelah sistem berubah, kontras warna tidak lagi dapat diakses. Sistem Anda merusak produk mereka.

Bayangkan rilis minor sistem Anda termasuk penyesuaian itu. Kompatibel ke belakang, katamu? Tidak ada risiko dalam peningkatan, mereka percaya? Nggak! Sistem Anda merusak produk mereka!

Oleh karena itu, evaluasi properti warna yang berubah untuk menentukan apakah suatu sistem berubah, seperti:

  • Warna teks yang dapat muncul di atas warna latar belakang, gambar, atau tekstur pengadopsi.
  • background-color di mana warna teks pengadopsi dilapis.
  • warna latar, warna batas, warna teks, bayangan kotak, atau properti lainnya yang disusun di samping, di atas, atau di bawah tepi atau konten komponen lain sehingga mengurangi kontras antara elemen.

Aksesibilitas mendorong contoh-contoh ini. Ada risiko estetika juga, bahwa perubahan sistem yang dilakukan dengan baik dapat mengganggu harmoni warna-warni yang dicapai oleh seorang desainer produk. Interaksi warna berlimpah di seluruh UI bahwa perancang sistem tidak mengontrol atau memiliki visibilitas ke dalamnya.

Bawa pulang: Mulai pecahkan perubahan pembicaraan dengan kriteria warna. Lebih mudah untuk menyampaikan risiko, dapat diukur secara obyektif, dan terkait dengan aksesibilitas yang membangkitkan gairah. Berbekal beberapa kriteria, Anda bisa beralih ke masalah lain.

Breaking Tipography (By Wrapping)

Tipografi adalah aspek inti dari gaya visual apa pun. Tim ingin melakukannya dengan benar. Dan ada begitu banyak tombol untuk disetel: font-family, font-weight, font-size, text-transform, line-height, spasi huruf, dan banyak lagi.

Tidak semua mengalami risiko pemutusan jika sistem menyesuaikan tipografi. Untuk pengalaman berat konten, konten setiap elemen dapat tidak dapat diprediksi, dengan panjang yang bervariasi, dan dirancang untuk membungkus dan menanggapi perubahan dalam lebar viewport.

Untuk antarmuka yang lebih rapat, tipografi harus tepat. Desainer menggiling selama berjam-jam tipografi fine-tuning, mengatur label agar sesuai di area yang kompak. Jika Anda menyesuaikan tipografi sistem, elemen-elemennya dapat membungkus atau memotong dengan cara yang tidak terduga.

Contoh: Tab Pembungkus Mengerikan

Bayangkan sistem Anda menyesuaikan tab labelfont-weight dari normal menjadi bold.

Setelah pemutakhiran versi minor, tab yang tidak merespons membungkus. Tidak baik.

Peningkatan adopter. Tab tidak responsif yang ada melebihi ruang yang dialokasikan, jadi mereka membungkus. Mengerikan! Sistem Anda merusak produk mereka.

Contoh: Surat Spacing Mayhem

Pedoman merek berkembang, menghasilkan hierarki dan gaya tajuk baru. Dengan demikian, sistem Anda beradaptasi dengan meningkatkan spasi huruf setiap pos.

Pengadopsi meningkatkan aplikasi radiologi satu halaman yang padat yang diterjemahkan ke dalam 14 bahasa, terdiri dari berbagai panel kontrol, masing-masing penuh dengan elemen bentuk dan judul. Mereka meningkatkan, dan UI dibanjiri dengan pos yang dipangkas tidak terduga. Mereka menyebut pertemuan krisis. Mereka mengundang para insinyur data back-end, demi Tuhan! Sistem Anda merusak produk mereka!

Menyesuaikan tipografi sistem bisa berbahaya. Bagi Anda, ini adalah evolusi tipografi yang menyegarkan yang disebarkan dengan mudah di perpustakaan. Bagi mereka, teks mulai nakal. Mereka menyalahkanmu. Mungkin mereka memecat Anda di saluran Slack # system-design. Tidak ada yang membutuhkan itu.

Takeaway: Sebelum 1.0.0, bekerja dengan rajin untuk bereksperimen, memperbaiki, dan menyelesaikan jenis gaya yang sesuai dengan variasi pelanggan. Setelah 1.0.0 berlalu, pertahankan basis stabil dan pertimbangkan untuk berubah dengan hati-hati. Pertimbangkan untuk memesan shift berbahaya untuk rilis besar berikutnya. Sampai saat itu, secara bertahap tambahkan fitur yang terkandung, seperti komponen Teks Bentuk Panjang untuk menata hanya salinan artikel.

Memecah Ruang dan Ukuran

Paling tidak Anda bisa melihat warna dan tipografi. Ruang dan ukuran? Itu lebih sulit untuk didefinisikan sebagai dapat digunakan kembali secara konkret, apalagi memantau untuk memecahkan perubahan.

Dalam HTML, ketika Anda mengubah properti model kotak komponen - padding, margin, lebar, tinggi, tampilan, ukuran kotak, posisi, kiri, kanan, atas, bawah - Anda berisiko memengaruhi komposisi tata letak yang mengatur komponen itu dengan elemen halaman lainnya.

Contoh 1: Menghapus Jarak Vertikal

Tim sistem Anda memutuskan untuk menghapus kendali bentuk spasi yang diterapkan dalam bentuk margin-bottom. Ini berdampak pada , ,

Awalnya diatur dengan jarak vertikal bawaan, sistem menghilangkan margin. Dan bentuk-bentuk terlihat seperti smooshed.

Seorang pengadopsi telah meletakkan 38 bentuk berbeda dengan mengandalkan jarak itu. Setelah sistem berubah, semua bentuknya tidak lagi terpisah secara vertikal. Sistem Anda merusak produk mereka.

Contoh 2: Ukuran Ubahsuaian Berdasarkan Asumsi Jarak

Setelah debat komunitas desain yang luas, sistem Anda mengakui untuk memperluas bantalan blok konten Kartu.

Bilah alat ikon kustom membungkus setelah perubahan padding. Ewww.

Pengadopsi telah mengatur dan mengukur Kartu berdasarkan pengaturan perangkat keras pelanggan mereka. Mereka juga menambahkan bilah alat hanya ikon di baris bawah. Setelah sistem berubah, ikon membungkus menjadi dua baris. Sistem Anda merusak produk mereka.

Takeaway: Pertama, hindari aturan spasial (biasanya margin) di luar batas komponen. Kedua, melakukan penyesuaian spasial dengan sangat, sangat hati-hati. Merendahkan tata letak pengguna adalah cara yang pasti untuk menciptakan gesekan, menghilangkan kepercayaan, dan menghasilkan PR buruk yang dapat dibenarkan di seluruh komunitas.

Perubahan Tata Ruang yang Terkandung dan Tidak Melanggar

Beberapa perubahan spasial tidak memengaruhi elemen atau komposisi halaman yang berdekatan. Misalnya, mengencangkan atau memperluas margin inset atau tumpukan di antara item dalam Menu tidak akan menjadi perubahan besar karena penyesuaian ini terkandung dalam blok yang sepenuhnya ditentukan oleh sistem, tidak termasuk elemen yang dapat disesuaikan lainnya, dan dilapisi dengan cara yang sebaliknya tidak memengaruhi tata letak halaman saat dibuka dan ditutup.

Apa Lagi yang Bisa Mematahkan Gaya Visual?

Secara umum, perubahan dalam gaya visual dapat ditentukan sebagai perubahan pada sejumlah properti CSS, kisaran yang dicontohkan oleh koleksi token desain di Salesforce Lightning, Morningstar, REI, dan Open Table.

Properti apa lagi yang bisa Anda pantau selain dari warna, tipografi, ruang, dan ukuran yang dijelaskan di atas? z-index diterapkan pada komponen-komponen seperti Popovers, Dialogs, Modals, dan Tooltips adalah pusat komposisi di dimensi tata letak berlapis ketiga. opacity diterapkan secara luas ke lapisan semi-transparan (seperti di bawah Modal) juga tampaknya kandidat yang kuat. Bahkan perubahan halus seperti batas bawah memiliki dampak.

Menyesuaikan warna tepi komponen yang disusun di dekat komponen lain
  • Sistem Anda membuat batas-bawah item terakhir daftar vertikal menjadi transparan. Seorang pengadopsi telah memposisikan daftar itu tepat di atas blok lain, mengandalkan garis untuk membuat kontras. Setelah sistem berubah, header blok bercampur dengan label item terakhir daftar dengan cara yang tidak jelas untuk dibedakan.
    Jika demikian, sistem Anda merusak produk mereka.

Tetapi bagaimana dengan menyesuaikan bayangan kotak? Atau fine tuning border-radius? Isyarat ambivalensi desainer. Sulit untuk meyakinkan bahwa penyesuaian itu akan menghancurkan pengalaman pengadopsi.

Takeaway: Tinjau koleksi luas kemungkinan properti CSS dan diskusikan konsekuensi dari properti kandidat dengan tim Anda. Sesi kerja akan membuahkan toleransi kelompok untuk melindungi pengguna dan mendorong ke arah dokumentasi seberapa jauh Anda akan melangkah.

Jadi, Apa yang dimaksud dengan Visual Breaking Change?

Pada titik ini, apakah Anda berpikir: apakah ini benar-benar penting? Bukankah kita seharusnya menggunakan sistem kita untuk mengontrol bahasa visual kita? Apakah pengadopsi benar-benar peduli?

Insinyur mungkin peduli. Desainer PASTI peduli. Mereka menghabiskan waktu berjam-jam mengatur tata letak, membuat anotasi, dan mengkomunikasikan detail kepada para dev. Oleh karena itu, sistem desain harus menjelaskan bagaimana perubahannya. Dan, setiap kali itu berubah, jika itu akan menjadi perubahan yang menurunkan desain mereka.

Dalam percakapan dengan kolega sistem desain, sentimen adalah:

"Kami agak tahu apa itu perubahan yang melanggar visual."
"Kami membahas perubahan pemecah visual ketika insting seseorang menyarankan juga."
"Saya setuju ini adalah suatu hal, kami tidak akan melakukannya dengan keras, dan ini penting."

Dalam pekerjaan kami di Sistem Desain Morningstar, kami telah mendokumentasikan perubahan apa yang dianggap sebagai besar, kecil, dan tambalan. Tim kami mengajukan pendapat dengan percaya diri dalam diskusi kritik, komentar pada permintaan tarik, dan dalam diskusi kami dengan mengadopsi dan meningkatkan tim.

Bidang kami akan beradaptasi dengan versi karena sangat tertanam dalam praktik kami. Kami akan melakukan apa yang kami bisa untuk berkomunikasi dengan baik dan melindungi pengguna kami.

# 3. Versi ← Sebelumnya | Berikutnya → # 5. Ketergantungan