UX Araçları: Not Alma, Lorem Ipsum, Renk Seçici ve Ekran Testi
Tasarım sürecinde kullandığımız küçük araçların çoğu bir işi kolaylaştırmak için var: not tutmak, yer tutucu metin üretmek, ekrandan renk almak, siteyi başka tarayıcıda görmek. Kolaylaştırdıkları iş kadar, sessizce atladıkları şey de var. Aşağıda dört araç ailesine bakıyorum, ama sorusu şu: bu araç bana neyi göstermiyor?
Notu prototipin üzerine mi, yanına mı yazmalı?
Protonotes prototipe küçük bir JavaScript dosyası ekliyor ve sayfanın üzerine yapışkan not bırakmanı sağlıyor. Notlar CSV olarak dışarı alınabiliyor, MySQL'e yazılabiliyor. WebNotes daha geniş bir çözüm; web sayfası ve PDF üzerine ek açıklama koyuyor, kullanıcı rolleri tanımlıyor.
İkisi arasındaki fark araç özelliği değil, notun nereye düştüğü. Prototipin üstündeki not, konuştuğu şeye yapışık durur: "bu buton" derken hangi buton olduğu tartışılmaz. Ekip aracındaki not ise aranabilir ve kalıcıdır, ama iki hafta sonra hangi ekrandan bahsettiği belirsizleşir. Peki ikisini birden tutmak? Denemeye değer, fakat aynı geri bildirimin iki yerde farklı sürümü oluşuyor ve hangisinin güncel olduğu belli olmuyor. Tek yer seçmek, iyi seçilmemiş tek yerden daha iyi çalışıyor.
Lorem ipsum Türkçe arayüzü test etmez
Yer tutucu metnin işi düzeni doldurmak: satır yüksekliği, sütun genişliği, başlık altındaki paragrafın hacmi. Bunun için yeterli. Ama Latince bir metinle Türkçe bir arayüzü onaylıyorsan, kontrol etmediğin şeyler var.
En bilineni karakter kümesi. Lorem ipsum içinde ğ, ı, ş, ç, ö, ü yok. Fontta bu glifler eksikse mockup tertemiz görünür, gerçek metin geldiğinde tarayıcı eksik harfleri başka bir fonttan tamamlar ve başlığın ortasında farklı bir yazı tipi belirir. Bunu bir projede tam böyle gördüm: onay alınmış tasarımda sorun yoktu, canlıda başlıklardaki ş harfleri komşu fonttan geldi.
İkincisi kelime uzunluğu. Türkçe eklerle uzayan bir dil; "ayarlar" ile "ayarlarınızı" arasındaki fark bir menü öğesinde satır kaydırır. Yer tutucu metnin bunu size haber verme ihtimali yok. Onay öncesi son turda gerçek metnin en uzun üç örneğini yerleştirip bakmak, jeneratörün yaptığı işten daha çok şey söylüyor.
Renk seçici ekranı okur, dosyayı değil
ColorPic ve benzerleri ekrandaki herhangi bir pikselin değerini alıp palete ekler, CMYK ve RGB arasında geçiş yapar. Basit ve işe yarar. Yalnız aldığı değer, kaynak dosyadaki değer değil; ekranda o an görünen değer.
Arada neler oluyor: görsel JPEG olarak sıkıştırılmışsa kenarlarda birkaç basamaklık sapma normaldir, işletim sistemi bir renk profili uyguluyorsa dönüşüm zaten yapılmıştır, tarayıcı opaklık veya harmanlama modu kullanıyorsa gördüğünüz renk hesaplanmış bir sonuçtur. Yani markanın #0B5FFF'i ekrandan alındığında #0C5EFE dönebilir ve bu hata değil, beklenen davranıştır. Marka renkleri için doğru kaynak stil dosyasıdır, ekran değil. Seçiciyi elinizde kaynağı olmayan şeylerde kullanın: bir ekran görüntüsü, bir rakip sitenin arayüzü, taranmış bir baskı.
Tarayıcı ekran görüntüsü etkileşimi göstermez
Browser Shots tarzı servisler sayfanızı birden çok tarayıcıda açıp fotoğrafını çeker. Uyum sorunlarının bir kısmını gerçekten yakalar: bozulan yerleşim, uygulanmamış bir CSS özelliği, yanlış hizalanan bir grid.
Yakalayamadığı ise sayfanın hareketli yarısı. Hover ve focus durumları, açılan menüler, klavyeyle gezinme sırası, ekran okuyucunun okuduğu etiket, formun hata mesajı, hiçbiri tek karede yok. Erişilebilirlik kontrolünün neredeyse tamamı bu ikinci grupta. O yüzden ekran görüntüsü servisi ilk elemedir, test değil. Asıl kontrolü Chrome DevTools veya Firefox Developer Tools içindeki cihaz emülasyonuyla, sayfayla oynayarak yapmak gerekiyor; en azından bir turu klavyeden çıkmadan, sekme tuşuyla gezerek atmak.
Kaynaklar