Tasarımdan koda: design handoff'ta ne kaybolur?

Kısaca: tasarım devri nedir

Tasarım devri, Figma'daki bir ekranın koda dönüşmeden önce geliştiriciye teslim edildiği andır. İngilizcede design handoff denir. Kâğıt üzerinde basit bir iştir: dosyanın linki gider, geliştirici bakıp kodu yazar.

Sorun şu: ekran bir resimdir, kod ise bir davranış. Resimde bir butonun tek hali görünür. Kodda aynı butonun odakta, yükleniyor ve devre dışı halleri de yazılmak zorundadır.

Geliştirici eksik kalan her kararı kendisi verir. Bu karar çoğu zaman makuldür, ama tasarımcının verdiği karar değildir. Birkaç sprint sonra ürün, Figma'daki haline pek benzemez.

Handoff'ta ne kaybolur

Audit'lerde ve kendi işlerimde kaybın hep aynı yerlerde olduğunu görüyorum. Ortak noktaları basit: hiçbiri ekran görüntüsünde görünmüyor.

1. Tokenlar

Figma'da bir buton rengi yalnızca #1A1916 olarak görünebilir. Bu değer bir renk kararıdır, ama adı yoksa geliştirici onu koda olduğu gibi yapıştırır. Marka rengi değiştiğinde o satırı kimse bulamaz.

Bir değere ad verildiğinde ona design token denir. Figma tarafında bu adlar değişken olarak tutulur, kodda CSS değişkeni olur. İki tarafta aynı ad kullanılıyorsa o renk için devirde konuşacak bir şey kalmaz.

Kontrolü kolay. Figma'da bir dolguya tıkladığınızda ham bir renk kodu mu görüyorsunuz, yoksa bir ad mı? Ham değer görüyorsanız o karar devirde kaybolabilir.

2. Bileşen durumları

Tasarım dosyalarında en sık eksik olan şey durumlardır. Buton çizilir, ama klavyeyle odaklanınca ya da yüklenirken nasıl görüneceği çizilmez.

Etkileşimli her bileşende şu durumlara bakarım: varsayılan, üzerinde, basılı, odakta, yükleniyor, devre dışı ve hatalı. Hepsi her bileşende gerekmez. Ama hangisinin gerekmediğine tasarımcı karar vermeli, geliştirici tahmin etmemeli.

Figma'da durumlar bir bileşenin varyantları olarak tutulabilir. Varyant adı koddaki durum adıyla aynıysa, geliştirici neyi neye bağlayacağını sormaz.

3. Boşluk ve tipografi

Boşluk, devirde en sessiz kaybolan karardır. Tasarımcı 24 piksel bırakır, geliştirici göz kararı 20 yazar. Tek ekranda fark edilmez, yirmi ekran sonra sayfa dağınık görünür.

Çözüm, boşlukları bir ölçeğe bağlamaktır. Bu sitede boşluklar 4, 8, 12, 16, 24 piksel diye büyüyen bir ölçekten seçilir. Her basamağın bir adı vardır. Tasarımda ölçek dışı bir değer görürsem onu ya hata ya da bilinçli istisna olarak yazarım.

Tipografide kaybolan şey çoğu zaman yazı boyutu değil, satır yüksekliği ve harf aralığıdır. Tasarım ve kod yan yana konduğunda fark hemen görünür. Yazı stillerini de adlı tutun: "gövde" ya da "başlık 2" gibi.

4. Erişilebilirlik notları

Ekran görüntüsü klavyeyi göstermez. Tab tuşuyla hangi sırayla gezinileceği resimde yazmaz. İkon butonunun ekran okuyucuda nasıl okunacağı da yazmaz.

WCAG 2.2 bunları açıkça ister. 2.4.7 ölçütüne (AA) göre klavyeyle kullanılabilen her arayüzde, klavye odağının görünür olduğu bir kullanım biçimi bulunmalı. 4.1.2 ölçütü (A) ise her bileşenin adının ve rolünün programatik olarak belirlenebilmesini ister.

Bu yüzden devirde odak sırasını, ikonların erişilebilir adını ve hata mesajının nerede okunacağını not olarak yazarım. Ölçütlerin hangi seviyede olduğunu WCAG rehberinde anlattım.

5. Kenar durumları

Tasarım dosyası genelde en güzel veriyle çizilir. Ad kısadır, liste beş satırda biter. Gerçek üründe ise soyad iki satıra taşar, liste boş gelir, istek zaman aşımına uğrar.

Her ekran için şunları sorarım: hiç veri yoksa ne görünür, istek başarısız olursa ne olur, metin iki kat uzarsa ne kırılır? Boş ekranlar için boş durum kalıbına, hatalar için hata mesajı kalıplarına bakabilirsiniz.

Bu soruların cevabı Figma'da yoksa, geliştirici cevabı kodu yazarken verir. Genellikle de en hızlı yazılan cevabı verir: boş bir beyaz alan ya da "Bir hata oluştu".

Bir bileşen Figma'dan CSS'e nasıl geçer

Aşağıda bu sitedeki bir butonun beş kararını tek tek eşledim. İlk sütun Figma'daki karşılık, ikincisi token, üçüncüsü koddaki satır.

Deneyin

Ödemeyi onayla

• OnaylaVarsayılan
• OnaylaÜzerinde
• OnaylaOdakta
• OnaylaDevre dışı

1. Figma'daDolgu: surface/inverse değişkeni
   Token--surface-inverse
   CSSbackground: var(--surface-inverse);
2. Figma'daKöşe yarıçapı: 18, radius/md
   Token--r-md
   CSSborder-radius: var(--r-md);
3. Figma'daOtomatik yerleşim iç boşluğu: 12 ve 24
   Token--sp-3 --sp-5
   CSSpadding: var(--sp-3) var(--sp-5);
4. Figma'daYazı stili: Instrument Sans, kalın, 17
   Token--fs-3 --font-body
   CSSfont: 700 var(--fs-3)/1 var(--font-body);
5. Figma'daVaryant: Durum = Odakta, Devre dışı
   Token--focus --surface-sunken
   CSS:focus-visible { outline: 3px solid var(--focus); } :disabled { background: var(--surface-sunken); }

Bu sitedeki bir butonun beş tasarım kararı. Bir özelliğe basın: karşılık gelen token ve CSS satırı vurgulanır, bileşende ilgili kısım çerçevelenir. Tokenlar sitenin gerçek tokenları, Figma tarafındaki adlar örnektir.

CSS satırlarının hiçbirinde ham değer yok, her satır bir ada işaret ediyor. Renk ya da boşluk değişirse yalnızca tokenın değeri değişir. CSS satırlarına dokunmak gerekmez.

Bu eşlemeyi bileşen bileşen tutmanın adı tasarım sistemidir. Nasıl kurulacağını tasarım sistemi rehberinde adım adım anlattım.

Figma Dev Mode ne yapar

Dev Mode, Figma'nın geliştiriciler için ayırdığı çalışma alanıdır. Figma yardım merkezine göre tasarım dosyasında araç çubuğundaki Dev Mode düğmesiyle ya da Shift D kısayoluyla açılır. Professional, Education, Organization, Government ve Enterprise planlarında bulunur.

Devirde işe yarayan özellikler aşağıda. Adları Figma'daki gibi bıraktım.

• Ready for dev: Tasarımcı bir çerçeveyi, bileşeni ya da bölümü "Mark as ready for dev" ile hazır işaretler. İşaretlenenler katman panelinde "Ready for development" başlığı altında toplanır.
• Changed: Hazır işaretlenmiş bir tasarım sonradan değişirse Figma bu durumu kendisi koyar. Elle konamaz. Tasarımcı değişikliği bitirince "Done with changes" ile işareti kaldırır.
• Completed: İşin bittiğini gösteren ikinci durum. Yardım sayfasına göre yalnızca bazı planlarda var.
• Inspect sekmesi: Seçilen katmanın yerleşimini, rengini, yazı özelliklerini, stillerini ve değişkenlerini gösterir. "Code" bölümünde otomatik üretilmiş kod parçaları çıkar, dil ya da codegen eklentisi açılır listeden seçilir.
• Değişkenler: Bir değişkenin değerini ve modunu görürsünüz, takma ad zincirini ham değere kadar izlersiniz. Figma, ham değerlere uyan değişkenleri de önerir.
• Ölçüm ve not: Dosyada düzenleme yetkisi olan biri, Design ya da Dev Mode'da Shift M ile ölçüm, Shift T ile not (annotation) ekler. Notların hazır kategorileri Development, Interaction, Accessibility ve Content'tir.
• Compare changes: Değişen bir çerçeveyi önceki sürümleriyle karşılaştırır. Bir bileşen örneği (instance) için ana bileşenle karşılaştırma çıkar.
• Focus view: Hazır işaretlenmiş tasarımlardan yalnızca birini açar. Diğer Dev Mode araçları bu görünümde de kullanılabilir.
• Figma for VS Code: Tasarım dosyasını kod editöründen gezmeye ve incelemeye yarayan eklenti. Yorumları anlık görürsünüz, kod dosyalarını tasarımdaki bileşenlere bağlarsınız.
• Code Connect: Kod tabanınızdaki gerçek bileşen kodunu Dev Mode'a getirir. Professional, Organization ve Enterprise planlarında var.

Erişilebilirlik notlarının doğal yeri Accessibility kategorisidir. Odak sırasını ve erişilebilir adları orada yazarsanız geliştirici aradığı yerde bulur.

İki küçük ayrıntı daha işe yarar. Kod yerine özelliklerin düz listesini görmek isterseniz "Code" yerine "List" görünümüne geçersiniz. İki katman arasındaki mesafeyi ölçmek için Option (Mac) ya da Alt (Windows) tuşunu basılı tutup ikinci katmanın üzerine gelirsiniz.

Notlarda sevdiğim bir ayrıntı da var. Figma'ya göre nota bir katman özelliği eklenirse, tasarım sonradan değişse de o özellik güncel kalır.

Dev Mode'un göstermediği

Dev Mode dosyada olanı gösterir. Çizilmemiş bir hata durumu ya da yazılmamış bir odak sırası, Inspect sekmesinde de yoktur.

Otomatik üretilen kod tasarım kararını bilmez, yalnızca değeri bilir. Katman bir değişkene bağlı değilse kod parçasında ham renk çıkar. Bu yüzden Dev Mode, tokenları ve durumları önceden düzgün kurulmuş bir dosyada iyi çalışır.

Devirden önce kontrol listesi

Bir ekranı "Ready for dev" yapmadan önce bu listeden geçiririm. Bir maddeye evet diyemiyorsam ekran henüz hazır değildir.

• Her renk, boşluk, köşe ve yazı değeri bir değişkene ya da stile bağlı.
• Etkileşimli her bileşenin gereken durumları çizilmiş, gerekmeyenler not edilmiş.
• Boşluklar ölçekten seçilmiş, istisnalar notla açıklanmış.
• Odak sırası, ikonların erişilebilir adı ve hata mesajının yeri Accessibility notunda yazılı.
• Boş, yükleniyor, hata ve uzun metin halleri çizilmiş.
• Mobil ve masaüstü genişlikler ayrı ayrı gösterilmiş.
• Figma'daki bileşen ve varyant adları koddakilerle aynı.

Bu listede en çok takılan yer formlardır, çünkü her alanın kendi hata hali vardır. Alan alan neye bakılacağını form tasarımı kalıbında topladım.

Örnek: bir para gönderme ekranının devri

Bir banka uygulamasında para gönderme ekranı düşünün. Figma'da tek bir ekran var: alıcı adı, IBAN, tutar ve "Gönder" butonu. Ekran temiz görünüyor ve geliştiriciye bu haliyle gidiyor.

Kodlama başlayınca sorular gelir. IBAN yanlış girilirse hata nerede çıkar? Bakiye yetmezse buton kapanır mı, yoksa basınca mı uyarır? Gönderim sürerken buton ne gösterir?

Bunların hiçbiri ekranda yok. Geliştirici her birine kendi cevabını verir. Hata sayfanın en üstünde çıkabilir, buton gönderim sürerken hiçbir şey göstermeyebilir. O zaman kullanıcı butona ikinci kez basabilir.

Aynı ekranı devirden önce beş başlıktan geçirirseniz dosyada şunlar olur:

• Butonun yükleniyor ve devre dışı varyantları, adlarıyla.
• IBAN alanının hatalı hali ve hata metninin alanın hemen altındaki yeri.
• Bakiye yetmediğinde gösterilecek mesaj ve tutar alanının hali.
• Bir Accessibility notu: hata mesajı ekran okuyucuya nasıl iletilecek, odak hata sonrasında nereye gidecek.
• Uzun bir alıcı adının iki satıra nasıl kırılacağı.

Bu liste dosyaya birkaç varyant ve birkaç not ekler. Karşılığında geliştiricinin tek başına vereceği kararların çoğu ortadan kalkar.

Mobil bankacılıkta kullanıcıların en çok neye takıldığını mobil bankacılık şikayetleri yazısında topladım.

Devri ne zaman yapmalı?

Devri işin sonunda tek seferde yapmak en riskli yoldur. Geliştirici yirmi ekranı birden alır ve hangisinin kesinleştiğini bilemez.

Ben ekranları parça parça hazır işaretlemeyi öneririm. Bir akış bittiğinde o akışı "Ready for dev" yaparsınız, gerisi tasarımda kalır. Hazır işaretlenen ekran değişirse Figma bunu kendisi gösterir, kimsenin elle haber vermesi gerekmez.

Linki de dosyaya değil, çerçeveye verin. "Dosyada bir yerde" demek, geliştiricinin yanlış çerçeveye bakma ihtimalini artırır.

Benim notum

Benim işlerimde devir neredeyse yok, çünkü tasarlayan ve kodlayan aynı kişi. Figma'da bir buton çizerken onun CSS'ini de benim yazacağımı bilirim. Tokenı tasarımda adlandırır, kodda aynı adla açarım.

Bunun açıklaması basit: araya bir el değiştirme girmiyor. Tasarım ve kod aynı kafada kalınca "burada ne demek istedin" diye soran kimse olmuyor. Kaybolan karar sayısı da azalıyor.

Yine de kendime devir yapıyormuş gibi çalışırım. Kenar durumlarını ve erişilebilirlik notlarını Figma'ya yazarım, çünkü projeyi sonra ekibiniz devralacak. Tasarla & Yayınla Sprinti sonunda işi reponuza bu notlarla birlikte bırakırım.

Ekibinizde tasarımcı ve geliştirici ayrıysa en çok işe yarayan alışkanlık şu. Devirden önce birlikte oturun ve bir ekranı yalnızca Tab tuşuyla gezin. Ekran görüntüsünde görünmeyen eksikler bu turda hızla ortaya çıkar.