Tasarım Teslimi: Ekran Değil Karar Devretmek
Tasarım teslimi denince akla ekranların geliştiriciye aktarılması geliyor. Oysa asıl devredilen şey ekran değil karar: hangi durumda ne görünecek, genişlik değişince düzen nasıl bozulacak, veri hiç gelmezse sayfa ne diyecek. Teslimde yaşanan sıkıntıların çoğu da tam olarak bu kararların hiç verilmemiş olmasından çıkıyor.
Sorun iletişim değil, verilmemiş karar
Bir teslim aksadığında ilk suçlanan şey iletişim olur. Bunu iletişim eksikliğine bağlamam. Tasarımcıyla geliştiricinin aynı odada oturduğu, günde üç kez konuştuğu ekiplerde de aynı sıkıntılar çıkıyor.
Çıkma nedeni başka: kimse o kararı vermemiş. Liste boş geldiğinde ekranda ne yazacak? Kullanıcı yüklemeyi yarıda keserse dosya ne olacak? Sunucu 503 dönerse kullanıcı geri mi gönderilecek, tekrar denemesi mi istenecek? Bu sorular teslimden sonra geliştiricinin önüne düşer, o da makul bir şey yazar, tasarımcı görünce “ben böyle düşünmemiştim” der. Kaybedilen zaman konuşulmamış olmaktan değil, kararın en ucuz olduğu anda alınmamasından geliyor.
Ekranı değil durumu teslim edin
Sekiz alanlı bir kayıt formu düşünün. Her alanın boş, odaklanmış, dolu, hatalı ve pasif hali var. Tek ekran için kırk varyasyon eder. Bunları ekran ekran çizmeye kalkarsanız dosya şişer ve ikinci sprintte senkronu kaçar, çünkü değişen tek bir hata rengi kırk yerde aranmak zorunda kalır.
Ucuz yol, varyasyonu bileşen düzeyinde bir kez tanımlamak: input bir kere, buton bir kere, uyarı kutusu bir kere. Ekran da hangi bileşeni hangi durumda kullandığını söyler. Maliyet çarpımdan (ekran × bileşen × durum) toplamaya iner. Bu ayrımı yapmayan teslimlerde geliştirici zaten kendi kafasında bir bileşen kütüphanesi kuruyor, sadece sizin haberiniz olmuyor.
Üç kırılım, aradaki bütün genişlikler
Responsive teslim çoğunlukla üç görsel demek: mobil, tablet, masaüstü. Tarayıcı ise sürekli bir aralıkta çalışıyor. 700 ile 1000 piksel arasında yüzlerce olası genişlik var ve tasarımın konuşmadığı her genişlikte kararı CSS veriyor, yani fiilen geliştirici veriyor.
Bu yüzden dördüncü bir görselin faydası sınırlı. İşe yarayan şey kural: kart en fazla kaç sütuna açılır, başlık iki satıra taştığında yükseklik nasıl davranır, yan yana iki buton sığmazsa alt alta mı geçer yoksa etiket mi kısalır. Üç ekran görüntüsü yerine üç cümle yazıldığında teslim daha eksiksiz oluyor. Çeviriyle uzayan bir buton etiketi, üç kırılımda da güzel görünen tasarımı 820 pikselde bozar.
Dokümantasyon iki sprint yaşar
“Her şeyi kapsayan bir doküman hazırlayın” tavsiyesiyle “hızlı geri bildirim döngüsü kurun” tavsiyesi aynı listede yan yana duruyor, oysa birbirini yiyorlar. Doküman ne kadar kapsamlıysa güncellemesi o kadar pahalıdır; döngü ne kadar hızlıysa doküman o kadar çabuk eskir. İkisini birden isteyen ekipler genelde ikincisini seçip ilkini terk ediyor, sonra da dokümantasyon kültürü olmadığından yakınıyor.
Pratikte işleyen ayrım şu: ölçü, renk ve boşluk zaten tasarım dosyasından okunur, Figma'nın inspect paneli tam bunun için var. Aynı değerleri bir de dokümana kopyalamak iki kaynağın çelişmesini garantiler. Dokümanda kalması gereken şey ölçü değil gerekçe. Neden bu akış seçildi, hangi alternatif neden elendi, hangi kısıt yüzünden bu ekran böyle. Ölçü eskiyor, gerekçe eskimiyor.
Kaynaklar