Figma tasarımı koda nasıl aktarılır? Tasarımcı-geliştirici devir süreci

Figma tasarımı koda aktarılırken yalnızca ekranların görüntüsü değil; tasarım token'ları, bileşen yapısı, responsive kurallar ve etkileşim durumları da devredilmelidir. Sağlıklı bir devir süreci, ortak bir token sistemi, Figma bileşenlerinin koddaki karşılıklarıyla eşlenmesi, Dev Mode ile ölçü aktarımı ve eksik durumların kodlamadan önce tasarlanmasıyla yürür.

Tasarımcı-geliştirici devir süreci neden sorun çıkarır?

Tasarımcı-geliştirici devir süreci, Figma'daki statik ekranların tarayıcıdaki dinamik davranışı tam anlatamaması nedeniyle sorun çıkarır. Figma'da her kartın başlığı aynı uzunluktadır, her form doğru doldurulmuştur ve ekran tam 1440 piksel genişliktedir. Gerçek içerik, gerçek veri ve farklı cihazlar devreye girdiğinde tanımlanmamış kararlar geliştiriciye kalır.

• —Uzun bir ürün adı kartı taşırıyor ve düzen kırılıyor.
• —Tasarımda olmayan bir hata mesajı için geliştirici kendi rengini ve yazı boyutunu seçiyor.
• —Tablet genişliğinde menü ne masaüstü ne mobil davranışı gösteriyor.
• —Aynı gri tonu dosyada yedi farklı değerle kullanılmış; hangisinin doğru olduğu bilinmiyor.

Tasarım token'ları nedir ve neden önce onlar tanımlanmalı?

Tasarım token'ları; renk, tipografi, boşluk, köşe yarıçapı ve gölge gibi görsel kararların isimlendirilmiş değişkenler olarak saklanmasıdır, örneğin color-primary-600 veya space-4. Tasarım token'ları önce tanımlanmalıdır, çünkü tasarım ve kod aynı sözlüğü konuştuğunda bir rengi değiştirmek, yüzlerce ekranı tek tek düzeltmek yerine tek bir değeri güncellemek demektir.

• —Temel (primitive) token'lar: Ham değerler; örneğin blue-600 için belirli bir hex kodu, 16 piksellik boşluk birimi.
• —Anlamsal (semantic) token'lar: Kullanım amacını anlatan isimler; örneğin arka plan birincil rengi, hata metni rengi.
• —Bileşen token'ları: Belirli bir bileşene özgü değerler; örneğin birincil düğme arka planı veya kart iç boşluğu.

Figma'da Variables ve modlar (örneğin açık ve koyu tema) ile tanımlanan token'lar, kod tarafında CSS özel değişkenlerine veya Tailwind gibi bir yapılandırma dosyasına birebir aktarılabilir. Token isimleri iki tarafta da aynı tutulduğunda, tasarımcı 'bu alan space-6 olmalı' dediğinde geliştiricinin tahmin yapmasına gerek kalmaz.

Figma bileşenleri koddaki bileşenlerle nasıl eşlenir?

Figma bileşenleri, koddaki bileşenlerle aynı adı, aynı varyantları ve aynı özellik mantığını paylaşacak şekilde eşlenir. Figma'daki Button bileşeninin size ve variant özellikleri varsa, React'teki Button bileşeni de size ve variant prop'larını aynı değerlerle almalıdır. Bu eşleme, geliştiricinin her ekranı sıfırdan kodlamak yerine hazır parçaları birleştirmesini sağlar.

• —Figma kütüphanesindeki her bileşen için koddaki karşılığının adını ve dosya yolunu listeleyin.
• —Varyant özelliklerini (size, variant, state) prop isimleriyle birebir eşleyin.
• —Figma'da ayrılmış ama kodda tek bileşen olabilecek parçaları birleştirin.
• —Tek seferlik, bir ekrana özgü tasarımları kütüphaneye değil sayfa düzeyinde bırakın.
• —Yeni bileşen gerektiğinde önce Figma kütüphanesine ekleyin, sonra kodlayın.

Figma'nın Code Connect özelliği, Dev Mode'da bir bileşen seçildiğinde otomatik üretilmiş CSS yerine ekibin gerçek kod kütüphanesindeki kullanım örneğini göstermeye yarar. Kurulumu ek emek ister, ancak bileşen kütüphanesi büyük ve birden fazla geliştirici çalışıyorsa tutarlılığı ciddi biçimde artırır.

Responsive breakpoint'ler nasıl devredilir?

Responsive breakpoint'ler yalnızca mobil ve masaüstü çizimleriyle değil, aradaki davranışı tanımlayan kurallarla devredilir. Tasarımcı en az üç genişlik (örneğin 375, 768 ve 1440 piksel) çizmeli; geliştirici ise hangi öğenin esnek, hangisinin sabit olduğunu Auto Layout ayarlarından okuyabilmelidir. 1024 piksel gibi ara genişlikler hataların çoğunun kaynağıdır.

• —Breakpoint değerlerini token olarak tanımlayın ve koddaki değerlerle eşleyin.
• —Auto Layout'ta fill ve hug ayarlarını doğru kullanın; sabit genişlik yalnızca gerçekten gerektiğinde olsun.
• —Maksimum içerik genişliğini ve kenar boşluklarını her breakpoint için belirtin.
• —Grid sütun sayısının hangi genişlikte değiştiğini not edin.
• —Görsellerin hangi oranla kırpılacağını ve mobilde hangi görselin gizleneceğini yazın.

Figma Dev Mode devir sürecinde ne sağlar?

Figma Dev Mode, geliştiricilere ölçüleri, boşlukları, renk token'larını ve tipografi değerlerini doğrudan inceleme, CSS veya platforma özel kod parçacıkları alma ve görselleri dışa aktarma imkânı verir. Ekranların 'geliştirmeye hazır' olarak işaretlenmesi hangi tasarımın kesinleştiğini netleştirir ve henüz değişecek bir taslağın kodlanmasını önler.

Dev Mode'un ürettiği CSS bir başlangıç noktasıdır, üretim kodu değildir. Mutlak konumlandırma, sabit genişlikler ve katman adlarından türetilmiş sınıflar içerebilir. Doğru yaklaşım, Dev Mode'dan ölçü ve token bilgisini okuyup düzeni projenin kendi bileşenleri ve yardımcı sınıflarıyla kurmaktır. Sürüm karşılaştırma özelliği de 'geliştirmeye hazır' işaretinden sonra nelerin değiştiğini görmek için kullanılmalıdır.

Hover, boş ve hata durumları neden ayrıca tasarlanmalı?

Hover, boş ve hata durumları ayrıca tasarlanmalıdır, çünkü kullanıcılar arayüzde ciddi zaman geçirdikleri anların önemli kısmını 'mutlu senaryo' dışındaki durumlarda yaşar. Tasarlanmamış her durum geliştiricinin anlık kararıyla doldurulur ve marka dilinden kopar. Her etkileşimli bileşen için varsayılan, hover, focus, aktif, devre dışı ve yükleniyor durumları tanımlanmalıdır.

• —Hover ve focus: Klavyeyle gezinen kullanıcılar için görünür bir focus halkası şarttır.
• —Yükleniyor: İskelet ekran mı, dönen simge mi; ne kadar süreden sonra gösterileceği.
• —Boş durum: Henüz veri yokken ekranda ne görüneceği ve kullanıcıya hangi eylemin önerileceği.
• —Hata durumu: Form alanı hataları, sunucu hatası, bağlantı kopması için ayrı mesaj ve görünüm.
• —Başarı durumu: Form gönderildikten sonra kullanıcının ne göreceği.
• —Uç içerik: Çok uzun başlık, eksik görsel, tek öğeli liste.

Devir sırasında en çok ne kaybolur?

Devir sırasında en çok kaybolan bilgiler; animasyon zamanlamaları, gerçek içerik uzunluğuna göre davranış, erişilebilirlik gereksinimleri ve tasarımcının kafasındaki gerekçelerdir. Figma dosyası neyin çizildiğini gösterir ama neden öyle çizildiğini göstermez. Bu boşluk kısa bir devir toplantısı ve bileşen açıklamalarına yazılan notlarla büyük ölçüde kapatılır.

• —Animasyon süresi ve easing değerleri (örneğin 200 ms, ease-out).
• —Renk kontrastı ve dokunma alanı boyutu gibi erişilebilirlik kuralları.
• —Görsellerin alternatif metinleri ve dekoratif olanların hangileri olduğu.
• —Metinlerin hangi durumda kısaltılacağı veya satır kaydırılacağı.
• —Bir kararın arkasındaki iş gerekçesi; örneğin çağrı düğmesinin neden o konumda olduğu.

Figma'dan koda devir için pratik kontrol listesi

Figma'dan koda devir için pratik bir kontrol listesi, tasarımın geliştirmeye hazır olup olmadığını hızlıca test eder. Aşağıdaki maddelerin hepsi işaretlenmeden kodlamaya başlamak, genellikle proje sonunda uzun bir revizyon listesi olarak geri döner. Listeyi tasarımcı ve geliştiricinin devir toplantısında birlikte gözden geçirmesi en iyi sonucu verir.

• —Renk, tipografi, boşluk ve köşe yarıçapı token'ları Variables olarak tanımlı.
• —Tüm bileşenler kütüphanede ve varyant isimleri koddaki prop'larla eşleşiyor.
• —En az mobil, tablet ve masaüstü genişlikleri çizilmiş.
• —Auto Layout kullanılmış; sabit genişlikler bilinçli.
• —Hover, focus, devre dışı, yükleniyor, boş, hata ve başarı durumları tasarlanmış.
• —Gerçekçi içerikle (uzun başlık, eksik görsel) test edilmiş ekranlar var.
• —Animasyon süreleri ve easing değerleri not edilmiş.
• —Görseller dışa aktarım ayarlarıyla işaretlenmiş, SVG ikonlar temiz.
• —Hazır ekranlar Dev Mode'da 'geliştirmeye hazır' olarak işaretlenmiş.
• —Açık sorular için bileşen üzerinde yorum bırakılmış ve sorumlu kişi atanmış.