Figma Tasarımını Yazılım Ekibine Devrederken Eksik Kalan Teslimler

Figma dosyasındaki ekranların onaylanması, tasarımın yazılım ekibine devredilmeye hazır olduğu anlamına gelmez. Geliştiricinin renkleri, ölçüleri ve varlıkları inceleyebilmesi önemlidir; ancak çalışan bir dijital ürün oluşturmak için bundan fazlasına ihtiyaç vardır. Ekranın farklı veri koşullarında nasıl değişeceği, kullanıcının bir işlem sırasında ne göreceği, mobil yerleşimin nasıl davranacağı ve hangi sonucun doğru kabul edileceği de açıklanmalıdır.

Eksik Figma teslimi, tasarım ile geliştirme arasında görünmeyen bir yorum alanı oluşturur. Geliştirici boşlukları kendi varsayımlarıyla doldurur, ürün yöneticisi başka bir davranış bekler ve tasarımcı uygulanan ekranı gördüğünde yeni revizyonlar ister. Bu durum yalnızca görsel uyumsuzluk üretmez; bütçeyi, takvimi, kullanılabilirliği ve test sürecini de etkiler.

Sağlıklı bir devir, tek seferlik dosya paylaşımı değil; tasarım kararlarını uygulanabilir ve doğrulanabilir ürün kurallarına dönüştüren ortak bir süreçtir. Aşağıdaki çerçeve, web sitesi, e-ticaret, portal ve mobil uygulama projelerinde bu süreci planlamak için kullanılabilir.

Figma linki neden tek başına yeterli değildir?

Bir arayüz dosyası çoğunlukla ürünün ideal anını gösterir: içerikler eksiksizdir, ağ bağlantısı çalışır, kullanıcı doğru veriyi girer ve servisler başarılı yanıt verir. Gerçek kullanımda ise içerik uzar, ürün görseli bulunmaz, form hatalı doldurulur, API gecikir veya kullanıcının belirli bir işleme yetkisi olmaz. Bu koşullar tasarımda görünmüyorsa geliştirici hem davranışı hem de görünümü tahmin etmek zorunda kalır.

Figma’nın Dev Mode rehberi; özellik inceleme, varlık indirme, değişiklik karşılaştırma, açıklama ekleme ve geliştirmeye hazır durumlarını yönetme gibi olanaklar sunar. Bunlar devri kolaylaştırır, fakat ürün kurallarını kendiliğinden oluşturmaz. Araç ölçüyü gösterebilir; o ölçünün hangi ekran genişliğinde değişeceğini veya başarısız ödeme sonrasında hangi mesajın gösterileceğini proje ekibi tanımlar.

Bu nedenle teslim paketi, piksel değerlerinin yanında kararların bağlamını da taşımalıdır. Geliştiricinin “Burada ne olmalı?” diye sorması gereken her kritik nokta, olası bir eksik teslimdir.

Eksiksiz tasarım devri hangi sırayla hazırlanır?

Devir sürecini projenin sonunda yapılan bir kontrol olarak görmek yerine tasarım boyunca olgunlaşan bir çalışma olarak planlamak gerekir. Aşağıdaki sıra, ekran listesinden test edilebilir bir geliştirme paketine geçiş sağlar.

1. Kapsamı ve ekran envanterini sabitleyin

Önce hangi platformların, kullanıcı rollerinin, sayfaların ve akışların teslim kapsamında olduğunu kaydedin. Her ekran için benzersiz ve anlaşılır bir adlandırma kullanın. Benzer görünen ancak farklı yetkilere veya veri kaynaklarına sahip ekranları tek tasarım altında gizlemeyin. Kapsam dışı işlevleri ve sonraki faza bırakılan özellikleri de belirtin.

2. Akışları ve iş kurallarını eşleştirin

Ekranları yalnızca yan yana dizmek yeterli değildir. Başlangıç noktası, karar adımları, geri dönüşler ve tamamlanma koşulları prototipte veya bağlantılı bir akış belgesinde gösterilmelidir. Üyelik, sepet, teklif onayı veya belge yükleme gibi işlemlerde rol, doğrulama, zaman aşımı ve iptal kuralları eklenmelidir.

3. Bileşenleri ve tüm durumları tamamlayın

Buton, alan, kart, modal, tablo ve navigasyon gibi tekrar eden parçalar bileşen olarak düzenlenmeli; varyantların adları anlaşılır olmalıdır. Varsayılan görünümün yanı sıra hover, focus, disabled, loading, error, success ve boş durumlar hazırlanmalıdır. Böylece ekip yalnızca ekranı değil, arayüzün davranış sözlüğünü de devralır.

4. Responsive ve erişilebilirlik kurallarını yazın

Masaüstü ve mobil örnekler arasındaki değişim kuralları açıklanmalıdır. İçeriğin hangi sıraya geçeceği, tablonun nasıl küçüleceği, menünün ne zaman dönüşeceği ve dokunma alanlarının nasıl korunacağı belirtilmelidir. Klavye sırası, odak görünümü, alternatif metin ihtiyacı ve hata bildirimleri de teslimin parçasıdır.

5. Teknik inceleme ve kabul toplantısı yapın

Tasarımcı, geliştirici, ürün sorumlusu ve gerekiyorsa içerik yöneticisi dosyayı birlikte gözden geçirmelidir. Açık sorular kayda alınmalı, yanıtlanan kararlar ilgili ekranlara bağlanmalı ve yalnızca tamamlanan bölümler geliştirmeye hazır olarak işaretlenmelidir. Son olarak örnek kabul senaryoları oluşturulmalıdır.

Ekran durumları ve içerik senaryoları eksiksiz gösterilmeli

En sık atlanan teslim, mutlu yol dışındaki durumlardır. Bir liste ekranının dolu hali tasarlanırken ilk kullanım, sıfır sonuç, filtre sonucunun boş olması, yüklenme, kısmi veri ve servis hatası unutulabilir. Oysa bunların her biri kullanıcıya farklı açıklama ve eylem sunar.

Formlarda yalnızca boş ve doldurulmuş alanlar değil; zorunlu alan, yanlış biçim, karakter sınırı, sunucu hatası, işlem sürüyor ve başarı durumları da gösterilmelidir. Hata mesajının alan altında mı yoksa sayfa düzeyinde mi yer alacağı; girilen verinin korunup korunmayacağı açıkça yazılmalıdır. E-ticarette stok bitmesi, kuponun geçersiz olması, fiyatın değişmesi ve ödemenin reddedilmesi gibi ticari senaryolar ayrıca ele alınmalıdır.

Gerçek içerik sınırları da tasarımla birlikte verilmelidir. Başlık için önerilen uzunluk, görsel oranı, eksik profil resmi, uzun para birimi, farklı tarih biçimleri ve çok dilli içerik genişlemeleri test edilmelidir. Yer tutucu metinle dengeli görünen bir kart, gerçek ürün adıyla bozulabilir.

Bu durumlar için ekran üretmek yalnızca tasarım hassasiyeti değildir. Storybook dokümantasyonu, bir bileşenin farklı koşullardaki görünümünü ayrı “story”lerle kaydetmenin geliştirme ve kontrol açısından nasıl kullanılabileceğini açıklar. Bileşen durumlarını ayrı örneklerle belgeleme yaklaşımı, Figma varyantlarıyla kod tarafındaki bileşenlerin eşleştirilmesine yardımcı olabilir.

Responsive davranış yalnızca üç ekran çizmek değildir

Masaüstü, tablet ve mobil ekranların hazırlanması başlangıçtır; asıl teslim, bu örneklerin arasındaki davranışın tarifidir. Sabit bir kırılım değeri vermek her zaman yeterli olmaz. Bileşenin kullanılabilir alan daraldığında nasıl tepki verdiği, hangi öğenin önce küçüldüğü, gizlendiği veya yeni satıra geçtiği belirtilmelidir.

Grid yapısı, maksimum içerik genişliği, dış boşluklar ve sütun ilişkileri açıklanmalıdır. Bir ürün listesinin dört sütundan ikiye, ardından bire geçmesi kolaydır; ancak filtrelerin çekmeceye dönüşmesi, karşılaştırma tablosunun yatay kayması veya aksiyonların sabitlenmesi ayrıca karar gerektirir. Uzun tablolar için hangi sütunların öncelikli olduğu ve mobilde satırların karta dönüşüp dönüşmeyeceği yazılmalıdır.

Görsel kırpma, video oranı, klavye açıldığında form davranışı, cihaz güvenli alanları ve yatay kullanım gibi koşullar özellikle mobil uygulamalarda önemlidir. React Native ile geliştirilecek bir üründe iOS ve Android arasındaki yerel davranış farkları da tasarım incelemesinde konuşulmalıdır. Bu konudaki kapsamı genişletmek için mobil uygulama tasarımı kontrol listesi kullanılabilir.

Etkileşim, animasyon ve geri bildirim ayrıntıları aktarılmalı

Prototipte bir ekranın diğerine bağlanması, etkileşimin tamamını açıklamaz. Tetikleyici, süre, koşul ve sonuç birlikte tanımlanmalıdır. Bir modalın dışına tıklandığında kapanıp kapanmayacağı, geri tuşunun ne yapacağı, kaydedilmemiş değişikliklerde uyarı gösterilip gösterilmeyeceği ve işlem tekrarlanırsa sistemin nasıl davranacağı belirtilmelidir.

Animasyonlar için yalnızca görsel örnek değil; amaç, süre yaklaşımı, başlangıç ve bitiş hali ile azaltılmış hareket tercihi düşünülmelidir. Yükleme göstergesinin ne zaman belireceği, kısa işlemlerde titreşimi önlemek için gecikme kullanılıp kullanılmayacağı ve tamamlanma mesajının ne kadar kalacağı netleştirilmelidir.

Kullanıcı geri bildirimi erişilebilir biçimde aktarılmalıdır. W3C’nin WCAG 2.2 standardı, arayüz bileşenlerinin ad, rol ve değerlerinin programatik olarak belirlenebilmesini; durum mesajlarının yardımcı teknolojiler tarafından algılanabilmesini ister. Bu nedenle odak sırası, klavye davranışı, hata ilişkilendirmesi ve başarı bildirimleri yalnızca yazılım ekibinin sonradan çözeceği teknik ayrıntılar olarak bırakılmamalıdır.

Tasarım sistemi ve varlık tesliminde hangi bilgiler bulunmalı?

Renk, tipografi ve boşluk değerlerinin dağınık ekranlardan çıkarılması yerine değişkenler ve stiller üzerinden sunulması tutarlılığı artırır. Renk adları görsel tona göre değil kullanım amacına göre düzenlenebilir: metin-birincil, yüzey-uyarı veya kenarlık-pasif gibi. Tipografi ölçeğinde yazı tipi, ağırlık, satır yüksekliği ve harf aralığı birlikte tanımlanmalıdır.

Her bileşenin anatomy, boyut, varyant, durum ve kullanım kuralı bulunmalıdır. Örneğin birincil butonun hangi aksiyonlarda kullanılacağı, aynı ekranda kaç kez yer alabileceği ve ikonlu sürümde hizalamanın nasıl olacağı açıklanabilir. Tasarım dosyasındaki bileşen adlarıyla kod deposundaki karşılıkların eşleştirilmesi, sonraki revizyonları kolaylaştırır.

İkon, illüstrasyon ve fotoğraflar için dosya biçimi, çözünürlük, ölçekleme ve kırpma kuralları belirtilmelidir. SVG dosyalarında gereksiz katmanlar temizlenmeli; lisans veya kullanım kısıtı bulunan varlıklar işaretlenmelidir. Geliştiricinin ekrandan rastgele dışa aktardığı görselin nihai kaynak haline gelmesi önlenmelidir.

Teknik beklentiler ve veri modeli tasarımla ilişkilendirilmeli

Arayüz, veri ve iş kurallarından bağımsız değildir. Liste sıralaması, filtre seçenekleri, sayfalama, para ve tarih biçimi, rol bazlı görünürlük, dosya sınırları ve entegrasyon yanıtları ilgili ekranlara bağlanmalıdır. Tasarım “onaylandı” rozeti gösteriyorsa bu durumun hangi sistemden geldiği ve değiştiğinde kullanıcıya nasıl yansıyacağı bilinmelidir.

API henüz hazır değilse örnek veri sözleşmesi oluşturulabilir. Alan adı, veri tipi, zorunluluk, olası değerler ve boş değer davranışı yazılı hale getirildiğinde ön yüz ile arka uç ekipleri aynı beklenti üzerinden çalışır. Hassas verilerin maskelenmesi, kullanıcı rollerinin ayrılması ve loglarda tutulmaması gereken bilgiler de bu aşamada konuşulmalıdır.

Projeye özgü portal, yönetim paneli veya entegrasyon gereksinimleri bulunuyorsa tasarım devri, özel web yazılım geliştirme kapsamıyla birlikte planlanmalıdır. Böylece arayüz kararları veri kaynağı, yetkilendirme, güvenlik, performans ve yönetilebilirlik ihtiyaçlarından kopmaz.

Değişiklik yönetimi ve kabul ölçütleri tanımlanmalı

Geliştirme başladıktan sonra Figma üzerinde sessizce yapılan değişiklikler, en düzenli dosyayı bile güvenilmez hale getirir. Teslim edilen bölümler sürüm veya durum etiketiyle işaretlenmeli; değişikliğin tarihi, nedeni, etkilenen ekranları ve sorumlusu kaydedilmelidir. Kritik güncellemeler yalnızca yorumla bırakılmamalı, görev yönetim sistemindeki ilgili kayıtla ilişkilendirilmelidir.

Her önemli akış için doğrulanabilir kabul ölçütleri hazırlanmalıdır. “Mobil uyumlu olacak” yerine, “Dar ekranda filtreler çekmece içinde açılır, seçili filtre sayısı tetikleyicide görünür ve seçimler uygulandığında liste güncellenir” gibi gözlenebilir ifadeler kullanılmalıdır. Görsel yakınlık kadar işlev, hata durumu, erişilebilirlik ve içerik dayanıklılığı da kabul kapsamına alınmalıdır.

Devir toplantısının sonunda açık soru listesi, karar sahipleri ve hedef tarihler paylaşılmalıdır. Tasarım onayı ile geliştirme kabulü ayrı kavramlardır: ilki görsel ve deneyim kararını, ikincisi çalışan ürünün belirlenen kuralları karşıladığını gösterir.

Figma devir kontrol listesi

• Kapsamdaki platformlar, roller, ekranlar ve akışlar listelendi mi?
• Boş, yükleniyor, hata, başarı, yetkisiz ve çevrimdışı durumlar gösterildi mi?
• Gerçek içerik uzunlukları ve eksik veri senaryoları test edildi mi?
• Responsive dönüşüm ve içerik önceliği kuralları açıklandı mı?
• Bileşen varyantları, tasarım değişkenleri ve varlık biçimleri düzenlendi mi?
• Form doğrulama, geri bildirim, klavye ve odak davranışları tanımlandı mı?
• Veri alanları, roller, entegrasyonlar ve güvenlik beklentileri ilişkilendirildi mi?
• Değişiklik kaydı, sorumlular ve kabul ölçütleri oluşturuldu mu?
• Geliştiriciyle teknik inceleme yapılıp açık sorular kapatıldı mı?

Tasarım ve geliştirmeyi aynı ürün süreci olarak yönetin

Eksiksiz teslim, daha fazla ekran çizmekten ibaret değildir. Amaç; tasarım niyetini, sistem davranışını ve iş beklentisini ekiplerin aynı biçimde yorumlayabileceği bir yapıya dönüştürmektir. Bu yaklaşım tekrar işleri azaltır, testleri somutlaştırır ve ürünün farklı cihazlar ile gerçek veri koşullarında tutarlı çalışmasını destekler.

Kumsal Ajans, Art Director liderliğindeki markaya özel web ve dijital tasarım yaklaşımını; projeye özel web yazılım, React Native mobil uygulama, e-ticaret ve kullanıcı deneyimi planlama yetkinlikleriyle birlikte ele alır. Bilgi mimarisinden responsive davranışlara, bileşenlerden veri güvenliğine ve sürdürülebilir teslime kadar tasarım ile yazılımı ayrı çıktılar olarak değil, aynı ürünün birbirini tamamlayan parçaları olarak planlar.

Figma tasarımınızın yazılım ekibine eksiksiz aktarılması ve projenizin tasarım-geliştirme sürecinin birlikte planlanması için Kumsal Ajans ile iletişime geçin.