Tasarım onaylanır, geliştirme başlar, ürün yayına girer. Sonra biri iki ekranı yan yana koyar: aralıklar farklı, bir düğmenin üzerine gelindiğinde hiçbir şey olmuyor, uzun bir başlık kartı taşırmış, telefonda tablo ekrandan çıkmış. Kimse bilerek yanlış yapmamıştır. Fark, tasarım dosyasının söylemediği yerlerde oluşmuştur.
Bu yazı o yerleri sırayla anlatıyor: ilk yedi başlık farkın nerede doğduğunu, son ikisi nasıl yakalandığını gösteriyor.
1. Eksik durum tasarımları #
Tasarım dosyaları çoğunlukla ekranın ideal hâlini gösterir: veri dolu, her şey yüklenmiş, hata yok. Gerçek üründe ise her ekranın başka hâlleri vardır.
- Yükleniyor: veri gelene kadar ne görünüyor?
- Boş: hiç kayıt yokken ne gösteriliyor, kullanıcı ne yapabilir?
- Hata: istek başarısız olduğunda mesaj ne diyor?
- Kısmi: verinin bir kısmı varken düzen nasıl davranıyor?
- Etkileşim: üzerine gelme, odak, basılı ve devre dışı hâller.
Bu durumlar çizilmediğinde geliştirici kendi çözümünü üretir ve her geliştirici farklı üretir. Üründeki tutarsızlığın önemli bir kısmı buradan gelir.
2. Responsive kuralların tanımlanmaması #
İki ya da üç ekran genişliğinde çizilmiş bir tasarım, aradaki bütün genişlikler için bir tahmin bırakır. Hangi öğe esner, hangisi sabit kalır, sütunlar hangi noktada alt alta geçer, bir tablo dar ekranda ne olur?
Çözüm her genişliği çizmek değil, kuralı yazmaktır. Bileşenin en küçük ve en büyük genişliği, kırılma noktaları ve içeriğin taşma davranışı tanımlandığında geliştirici aradaki genişlikleri doğru doldurur.
3. Bileşen varyantları #
Bir düğmenin kaç boyutu, kaç türü ve kaç durumu var? Tasarım dosyasında dört varyant, kodda yedi varyant varsa ikisi birbirini tutmuyor demektir. Fark çoğunlukla sessizce büyür: tasarımcı yeni bir ekranda küçük bir değişiklik yapar, bu değişiklik kütüphaneye işlenmez, geliştirici o ekrana özel bir stil yazar.
Varyantların tasarım ve kod tarafında aynı adla ve aynı sayıda bulunması gerekir. Yeni bir varyant ihtiyacı doğduğunda karar bileşen düzeyinde verilir, ekran düzeyinde değil.
4. İçerik sınırları #
Tasarımda başlık iki kelimedir, kullanıcı adı kısadır, fiyat üç hanelidir. Gerçek içerik böyle davranmaz: uzun ürün adları, çevirisi uzayan düğme metinleri, boş kalan alanlar, çok büyük sayılar.
Her metin alanı için en az ve en çok uzunluk, taşma durumunda ne olacağı (kısaltma, alt satıra geçme, küçülme) ve boş değer davranışı belirtilmelidir. Tasarımı gerçek ya da gerçeğe yakın içerikle yapmak bu sorunların birçoğunu teslimden önce ortaya çıkarır.
5. Erişilebilirlik #
Erişilebilirliğin bir kısmı tasarım dosyasında görünür: kontrast, dokunma hedeflerinin boyutu, odak göstergesi. Bir kısmı ise görünmez: klavyeyle gezinme sırası, ekran okuyucunun okuyacağı etiketler, hata mesajlarının nasıl duyurulacağı.
Görünmeyen kısım teslimde yazılmazsa uygulanmaz. Odak sırası, simge düğmelerinin metin karşılıkları ve form alanlarının etiketleri, ekranla birlikte not olarak aktarılmalıdır.
6. Tasarım tokenları #
Tasarımda bir renk "marka kırmızısı", kodda onaltılık bir değerdir. Aralıklar tasarımda gözle ayarlanmış, kodda rastgele piksel değerleri olarak yazılmıştır. Bu durumda en küçük görsel değişiklik bile ürünün her yerine tek tek dokunmayı gerektirir.
Token, bu değerlerin iki tarafta da aynı adla tanımlanmasıdır: renk, aralık, yazı ölçeği, köşe yarıçapı. Geliştirici değeri kopyalamaz, adı kullanır. Tokenların ve bileşenlerin ne zaman kapsamlı bir sisteme dönüşmesi gerektiğini tasarım sistemi ne zaman gereklidir yazısında anlattık.
7. Tasarım ve geliştirme iletişimi #
Tasarımın duvarın üzerinden atıldığı düzende geliştirici sorusunu soracak kimse bulamaz ve tahmin eder. Tersi de olur: tasarımcı teknik sınırı bilmeden çizdiği için tasarım olduğu gibi uygulanamaz.
İşe yarayan düzen basittir. Geliştirici tasarımı teslimden önce görür ve uygulanması zor yerleri söyler. Geliştirme sırasında sorular için açık bir kanal ve cevap verecek bir tasarımcı vardır. Tasarım değiştiğinde değişiklik not edilir. Canlı ürünlerde bu sürekliliği Ürün Tasarım Desteği ile sağlıyoruz: tasarım, sprint ve geliştirme akışının içinde ilerler.
8. Uygulama sonrası Design QA #
Yukarıdaki boşluklar kapatılsa da uygulanan ekran tasarımla karşılaştırılmadan yayına girmemelidir. Design QA, işlevsel testten farklıdır. İşlevsel test düğmenin çalışıp çalışmadığına bakar. Design QA düğmenin doğru yerde, doğru boyutta, doğru durumlarla ve doğru bileşenle uygulanıp uygulanmadığına bakar.
Design QA çalışmasında canlı ürünü tasarım, davranış, içerik, responsive yapı ve erişilebilirlik açısından sistematik olarak tarıyoruz. Kontrol gerçek cihazlarda ve farklı ekran genişliklerinde yapılır; boş, hata ve yüklenme durumları ayrıca denenir.
9. Önceliklendirilmiş hata raporu #
"Tasarıma uymuyor" bir hata kaydı değildir. İşe yarar bir kayıt şunları içerir: ekran ve adım, beklenen davranış, görülen davranış ve ekran görüntüsü. Geliştirici kaydı okuduğunda ne yapacağını sormak zorunda kalmamalıdır.
Kayıtlar eşit önemde de değildir. Etki, efor, risk ve bağımlılığa göre sıralanır.
- Kullanıcının işini engelleyen ya da erişilebilirliği bozan sorunlar önce gelir.
- Birçok ekranı etkileyen bileşen düzeyindeki sorunlar tek düzeltmeyle çözülür ve öne alınır.
- Yalnız görsel olan küçük farklar gruplanır ve toplu ele alınır.
Düzeltmeden sonra aynı ekran yeniden kontrol edilir. Kaydın kapatılmış olması, beklenen davranışın sağlandığı anlamına gelmez.
Farkı kalıcı olarak küçültmek #
Design QA sorunu yakalar ama kaynağını ortadan kaldırmaz. Aynı türden farklar her sürümde yeniden çıkıyorsa eksik olan şey bir kontrol turu değil, bir standarttır: durumların çizilmesi, kuralların yazılması, tokenların eşlenmesi ve kararların tek bir yerden verilmesi.
Birden çok geliştirici ekip ya da ajans aynı ürüne dokunuyorsa bu standardı koruyacak bir sahip gerekir. Tasarım Liderliği hizmetinde kalite standardını ve gözden geçirme ritmini bu amaçla kuruyoruz. Kararların nasıl yönetildiğini ürün ekiplerinde tasarım kararları yazısında anlattık.
Kaynaklar #
- Design Systems 101, Nielsen Norman Group; tasarım ve kod arasında ortak bileşen dili
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C; erişilebilirlik kontrollerinin dayandığı ölçütler
