Tasarım Devri: Figma'ı Tasarımı Kaybetmeden Geliştiricilere Nasıl Devredersiniz?

Çoğu tasarım teslimi aynı şekilde kötü sonuçlanır. Tasarımcı bir Figma dosyası gönderir. Geliştirici dosyayı açar, üç soru sorar, iki cevap alır ve yaklaşık bir tasarım oluşturmaya başlar. İki hafta sonra, dağıtılan ürün %80 oranında prototipe benzer, tasarımcı sinirlenir, geliştirici savunmaya geçer ve proje yöneticisi bu farkı "tekrarlama" olarak yeniden adlandırır. Bu iş akışında on yıldır hiçbir gelişme olmadı.

Bu kılavuz, bu iş akışının yerini alıyor. 2026'da gerçek bir teslim, bir toplantı değil, bir sistemdir. Belirsizliği önleyen Figma dosya yapısı, tasarımı makine tarafından okunabilir hale getiren belirteç disiplini, kodlama ajanlarının tasarımı doğrudan okumasını sağlayan Figma MCP kablolama ve gönderilmeden önce sapmaları yakalayan inceleme döngüsü.

Tasarım Devri Gerçekte Nedir?

Tasarım devri, bir tasarımın uygulanabilir koda dönüştüğü andır. Bu andan önceki her şey tasarımdır. Sonrasındaki her şey geliştirmedir. Devir, iki sistem arasındaki arayüzdür ve tasarımın makine tarafından okunabilirliğine bağlı olarak başarılı veya başarısız olur.

Eski tanım (tasarımcının geliştiriciye dosyayı adım adım anlattığı bir toplantı) bir başarısızlık modelidir. Adım adım anlatımlar ölçeklenebilir değildir, personel değişikliklerine dayanamaz ve kodlama ajanlarının gerçekte ihtiyaç duyduğu şeyle örtüşmez. 2026 tanımı farklıdır. Devir, bir geliştiricinin (veya bir Claude Code ajanının) neyin amaçlandığını kimseye sormadan tasarımı oluşturmasına olanak tanıyan yapılandırılmış bir yapıdır.

Bu yapı Figma dosyasında bulunur. Dosyanın kalitesi, devrin kalitesini belirler. Ayrı bir devir belgesi, açıklamalı PDF veya boşlukları dolduran bir Notion özeti yoktur. Dosya, özetin kendisidir.

Teslimata Hazır Dört Katmanlı Figma Dosyası

Teslimata hazır bir Figma dosyası dört katmandan oluşur. Herhangi bir katmanı atlarsanız, geliştirici tahmin etmek zorunda kalır. Dört katmanı da oluşturursanız, geliştiricinin (veya yapay zeka ajanının) soracak hiçbir şeyi kalmaz.

Katman 1: Tokenlar

Tokenlar, tasarımdaki her değer için doğruluk kaynağıdır. Renk, aralık, tipografi, yarıçap, gölge, hareket. Her kompozisyondaki her görünür değer bir tokena geri döner.

Tokenlar Figma Değişkenlerinde (veya ekibiniz eski iş akışındaysa Token Stüdyosunda) bulunur. Görsel olarak değil, anlamsal olarak adlandırılırlar. color/background/primary, gray-50 değil. spacing/lg, 24px değil. Anlamsal isimler yeniden tasarımdan sonra da geçerliliğini korur. Kelime anlamı taşıyan isimler ise birisi değerini değiştirdiği gün bozulur.

Token içermeyen bir teslimat dosyası, her geliştiricinin hangi renk, hangi aralık, hangi yarıçap ve her birinin nereye yerleştirileceği konusunda yüzlerce mikro karar verdiği bir teslimat dosyasıdır. Bu yüzlerce kararı bir düzine bileşene yaydığınızda, dağıtılan ürün artık bileşenle eşleşmez. Çözüm "daha dikkatli olmak" değil. Çözüm, baştan itibaren uygulanan tokenlardır. tasarım sistemleri kılavuzu açıklaması, tüm token taksonomisini kapsar.

Katman 2: Bileşenler

Bileşenler, tasarım sisteminin gönderdiği yeniden kullanılabilir birimlerdir. Her düğme, giriş alanı, kart, modal, gezinme ve temel öğe, tüm varyantları, tüm durumları ve tüm duyarlı davranışlarıyla birlikte bir Figma bileşeni olarak yaşar.

Kural: Bileşen olmayan hiçbir şey sayfa katmanına ulaşmaz. "Gevşek" bir öğe (kahraman içinde elle stillendirilmiş tek seferlik bir düğme) gelecekteki bir hatadır. Marka rengi ilk kez değiştiğinde, o gevşek öğe güncellenmez. İkinci kez değiştiğinde de bir sonraki de güncellenmez. Altı ay sonra tasarım sistemi Gruyere peyniri gibi olur.

Varyantlar, bileşenler kadar önemlidir. Bir düğme tek bir bileşen değildir, boyut varyantları, tip varyantları (birincil, ikincil, hayalet, yıkıcı) ve durum varyantları (varsayılan, üzerine gelindiğinde, aktif, devre dışı, yükleniyor) içeren bir düğme ailesidir. Geliştiricinin oluşturması gereken her varyant dosyada mevcut olmalıdır. Eğer yoksa, geliştirici onu icat eder ve icat edilen sürüm, bir sonraki tasarımcının nasıl görünmesi gerektiği fikrinden sapar.

Katman 3: Desenler

Desenler, bileşenlerin yeniden kullanılabilir düzen bloklarına bir araya getirilmesidir. Kahraman bölümleri, özellik ızgaraları, gezinme çubukları, altbilgiler, fiyat tabloları. Bunlar tam sayfalar değildir, sayfaların oluşturduğu makrolardır.

Desenler, bileşenler ve sayfalar arasında yer alır. "Tasarım amacı"nın büyük bir kısmı bu seviyede yer alır, çünkü bir kalıp sadece bileşenlerin ne olduğunu değil, nasıl ilişkili olduklarını da belirler. Bir kahraman kalıbı şöyle der: başlık, alt başlık, harekete geçirici mesaj (CTA) ve destekleyici görsel, bu sırayla, bu aralıkla, her kırılma noktasında bu boyut ilişkileriyle.

Kalıplar ayrıca duyarlı davranışı da belgeler. Bir kalıp, en az üç kırılma noktası varyantına (mobil, tablet, masaüstü) sahip olana kadar gerçekten belgelenmiş sayılmaz. Kırılma noktası olmayan kalıplar, sistem bileşenleri gibi davranan dekoratif tel çerçevelerdir.

Katman 4: Sayfalar

Sayfalar nihai kompozisyonlardır. Kalıpları kullanırlar, kalıplar bileşenleri kullanır, bileşenler de belirteçleri kullanır. Bir sayfa var olduğunda, her değer, her temel öğe ve her blok zaten belirlenmiştir.

Teslimata hazır bir sayfa, kalıplardan oluşur ve yeni hiçbir şey eklemez. Bir sayfa sistemde mevcut olmayan yeni bir renk, yeni bir aralık değeri veya yeni bir düğme stili tanıttığı anda, dört katmanlı model bozulur ve geliştirici sayfayı kesin olarak yeniden üretemez.

Sayfalar ayrıca amaçlarıyla da işaretlenmelidir. Kahraman, başlık, birincil harekete geçirici mesaj (CTA), dönüşüm yolu. Burada açıklama, "geliştiriciye ne inşa edeceğini söylemek" değil, "uygulama gerçek dünya kısıtlamasıyla karşılaştığında doğru ödün verme kararları alınabilmesi için ajana (insan veya yapay zeka) sayfanın ne için olduğunu söylemek"tir.

Token disiplini taşıyıcı duvardır

Dört katmandan tokenlar, çoğu ekibin atladığı ve yokluğunun teslimatı en hızlı şekilde bozduğu katmandır. Kusurlu bileşenlere sahip token disiplinli bir dosya yine de yaklaşık olarak bir bileşene gönderilir. Kusursuz bileşenlere sahip token açısından özensiz bir dosya, yaklaşık bir yaklaşımın yaklaşık bir yaklaşımını gönderir.

Üç kural token disiplinini korur.

Her görünür değer bir tokena dönüşür. Çoğu değil. Hepsi. Bir renk, boşluk, yarıçap veya tipografi değeri bir token değilse, bu gelecekteki bir hatadır.

Token'lar anlamsal olarak adlandırılır. surface/raised, text/muted, border/strong. gray-100, gray-400, gray-700 değil. Anlamsal adlar amaca karşılık gelir. Kelime anlamı taşıyan adlar ise belirli bir gri tonuna karşılık gelir ve marka güncellendiği anda bozulur.

Token'ların tek bir doğruluk kaynağı vardır. Tek bir Figma kütüphanesinde yaşarlar, bir kez dışa aktarılırlar ve her yerde kullanılırlar. Üç yerde tanımlanmış bir token, sıfır yerde tanımlanmış bir token'dır, çünkü hangi sürümün güncel olduğunu kimse bilmez.

Tasarımcılar için renk teorisi açıklaması, sıfırdan token dostu bir palet oluşturmayı ele almaktadır. tipografi sistemi tasarımı bölümü ise aynı şeyi tür token'ları için yapmaktadır.

Figma MCP, Devir Teslim Sürecini Değiştiriyor

2026 yılında devir teslim iş akışındaki en yüksek kaldıraç etkisine sahip değişiklik Figma MCP'dır. Figma tarafından yayınlanan Model Bağlam Protokolü sunucusu, kodlama aracılarına (Claude Code, Cursor, Claude Desktop) belirteçler, bileşenler, değişkenler ve Code Connect eşlemeleri de dahil olmak üzere Figma dosyasını doğrudan okuma olanağı sağlar.

Bu, matematiği değiştirir. Geliştirici artık tasarımı gözle kopyalamaz. Aracı dosyayı okur, bileşeni oluşturur ve geliştirici inceler. Yaklaşım azalır. Hız artar. Devir teslim artık bir çeviri adımı değil, bir derleme adımıdır.

Sorun şu: MCP yalnızca altındaki dosya kadar iyi çalışır. Temiz belirteçlere, gerçek bileşenlere ve Code Connect bağlamalarına sahip dört katmanlı bir dosya temiz kod üretir. Belirteç içermeyen gevşek bir dosya, daha önce olduğu gibi aynı yaklaşık sonucu üretir, sadece daha hızlıdır. MCP dosyayı güçlendirir. Onu kurtarmaz.

Kurulum hakkında daha detaylı bilgi için, figma mcp kılavuzu, Claude Code, İmleç ve Claude Masaüstü arasındaki tüm bağlantıyı kapsar. Claude tasarımcılar için kod açıklaması, ajanın çalışan tasarımcının günlük işlerine nasıl uyduğunu ele alır.

Code Connect katmanı

Code Connect, bir Figma bileşeni ile onu uygulayan üretim kodu bileşeni arasındaki açık bağlantıdır. Onsuz, MCP tarafından yönlendirilen üretim, bileşen adını, prop API'sini ve içe aktarma yolunu tahmin etmek zorunda kalır. Bununla birlikte, üretim kesindir.

Gerçek bir ürün arayüzü gönderen bir ekip, Code Connect'i olmazsa olmaz olarak görmelidir. Kurulum maliyeti düşüktür (bileşen başına bir eşleme) ve getirisi her gelecek üretimde katlanarak artar. Kodlama ajanları, Storybook entegrasyonları, tasarım kalite kontrol araçları ve görsel fark sistemleri bundan faydalanır.

Eşleme, bileşen başına küçük bir .figma.tsx dosyasında bulunur ve React bileşenini, prop'larını ve Figma varyantlarının bu prop'lara nasıl eşlendiğini bildirir. Bundan sonra, ajan veya geliştirici, bileşen örneklerini Figma'den çeker ve tamamen tiplendirilmiş React'yi geri alır.

Teslim inceleme döngüsü

Dosya gönderildiğinde teslim işlemi tamamlanmaz. Dağıtılan ürün, bileşenle eşleştiğinde işlem tamamlanır. Üç inceleme kontrol noktası, ürün piyasaya sürülmeden önce sapmaları yakalar.

Kontrol Noktası 1: Teslimat Öncesi Tasarım Öz Denetimi

Dosyayı geliştirmeye göndermeden önce, tasarımcı beş kontrol gerçekleştirir.

Her görünür değer bir belirtece karşılık gelir. Her sayfa düzeyindeki öğe bir bileşen örneğidir, serbest ilkel türler yoktur. Her bileşen, sayfanın kullandığı tüm varyantlara sahiptir. Sayfadaki her desen için her duyarlı kırılma noktası belgelenmiştir. Her sayfa, birincil amacı ve dönüşüm yoluyla açıklanmıştır.

Beş kontrolden herhangi birinde başarısız olan sayfalar, geliştirmeye değil, tasarıma geri gönderilir. Bu, sapmaları yakalamanın en ucuz yoludur, çünkü henüz hiçbir şey inşa edilmemiştir.

Kontrol Noktası 2: İlk Oluşturulan Bileşen İncelemesi

Geliştirici (veya temsilci), sayfalardan önce bileşenleri oluşturur. Tasarımcı, herhangi bir sayfa çalışması başlamadan önce bileşenleri Figma kütüphanesine karşı inceler.

Bu, belirteç sapmasını, eksik varyantları ve prop API uyumsuzluklarını yakalama anıdır. Bileşen düzeyinde düzeltmek, her yerdeki sorunları çözer. Sayfa düzeyinde düzeltmek ise bir kez çözer ve bir sonraki sayfada tekrar ortaya çıkarır.

Bu kontrol noktasında 30 dakikalık bir bileşen incelemesi, daha sonra sayfa düzeyinde yapılacak 30 saatlik yeniden çalışmayı önler. Matematiksel olarak ekip lehine acımasız bir durum söz konusudur.

Kontrol Noktası 3: Tasarıma Karşı Görsel Kalite Kontrolü

Sayfa test ortamına gönderildikten sonra, tasarımcı tasarıma karşı görsel kalite kontrolü yapar. "İyi görünüyor mu?" değil, "tasarımın piksel piksel amacına uygun mu?" sorusuna cevap aranır. Tokenlar, boşluklar, ağırlıklar, kırılma noktaları, durumlar, hareketler.

Kalite kontrolü, ufak tefek hataların bir listesi değildir. Dört katmanlı dosyaya karşı yapılandırılmış bir karşılaştırmadır. Farklı olan her şey ya bir hata, geliştiricinin kısıtlama altında aldığı bir tasarım kararı ya da daha iyi gerçek dünya uygulamasına uyması için güncellenmesi gereken bir tasarımdır. Her üçü de geçerli sonuçlardır. Amaç, farkı görünür ve karara bağlanmış hale getirmek, görünmez ve gönderilmiş hale getirmemek.

Bu döngüyü iki ayrı ekip yerine tek bir iş akışı olarak yürüten bir ekip istiyorsanız, Brainy'ı işe alın'i kullanın. Marka, web ve ürün arayüzü, devir teslim sapması olmadan teslim edilir.

Devir teslim hile sayfası

Bunu kaydedin. Tasarım operasyonları belgesine sabitleyin.

| Katman | Bulunduğu yer | Teslim edilenler | Hata modu |

|-------|----------|---------------|--------------|

| Jetonlar | Figma Değişkenler | Renk, aralık, tip, yarıçap, gölge, hareket | Jetonlara çözümlenmeyen gevşek değerler |

| Bileşenler | Figma Kütüphane | Düğmeler, giriş alanları, kartlar, tüm varyantlarıyla temel öğeler | Sayfalar içinde elle stillendirilmiş gevşek öğeler |

| Desenler | Figma Kütüphane | Kesme noktalarına sahip kahraman, gezinme, özellik, altbilgi derlemeleri | Duyarlı davranıştan yoksun tek kesme noktası kalıpları |

| Sayfalar | Figma dosyası | Kalıplar ve bileşenlerden oluşan nihai kompozisyonlar | Sistemde olmayan yeni değerler sunan sayfalar |

| Araçlar | Rol | Ne zaman fayda sağlar |

|---------|------|------------------|

| Figma Değişkenler | Doğruluk kaynağı belirteci | Her proje, istisnasız |

| Kod Bağlantısı | Figma bileşenlerini React bileşenlerine eşleyin | MCP sizin için ilk kez bir bileşen oluşturduğunda |

| Figma MCP | Kodlama ajanlarının dosyayı okumasına izin verin | Claude Code'ün ilk kez bir ekran oluşturmasını istediğinizde |

| Storybook | Geliştiriciler için canlı bileşen referansı | Birden fazla geliştiriciyle ekipler arası geçiş |

| Görsel fark (Kromatik, Percy) | Dağıtımdan sonra sapmayı yakalayın | Birden fazla tasarımcının çalışmasını gönderen herhangi bir ekip |

2026'da neler değişiyor

Son 18 ayda geçişi değiştiren üç değişiklik oldu.

Yapay zeka ajanları dosyayı doğrudan okuyor. Claude Code, Cursor, Claude Desktop ve v0'ın tümü Figma'ten MCP'ye kadar olan bileşenleri kullanıyor. Geçiş artık "tasarımcı açıklıyor, geliştirici uyguluyor" değil, "tasarımcı yapılandırılmış bir dosya gönderiyor, ajan kod üretiyor, geliştirici inceliyor ve entegre ediyor" şeklinde. Darboğaz çeviriden dosya kalitesine kaydı.

Code Connect, prop API açığını kapattı. 2026 yılına kadar, MCP tarafından yönlendirilen üretim, prop adlarını tahmin etmek zorundaydı. Code Connect eşlemeleri, bağlantıyı belirleyici hale getirdi; bu da yapay zeka tarafından üretilen bileşenleri demo seviyesinde değil, gerçekten entegre edilebilir hale getirdi.

Token'lar olmazsa olmaz hale geldi. Üç yıl önce, token disiplini üst düzey tasarım ekipleri için bir olgunluk göstergesiydi. Bugün ise yapay zeka araçlarına dokunan herhangi bir şeyi piyasaya sürmek için bir ön koşuldur. Token'sız bir tasarım sistemi, MCP için görünmezdir, Code Connect için görünmezdir ve dosyayı okuyan her kodlama ajanı için görünmezdir.

2026'da en temiz ürünleri piyasaya süren ekipler, en güzel tasarımlara sahip ekipler değil. En sıkı dört katmanlı dosyalara, en katı token disiplinine ve en temiz Code Connect bağlamalarına sahip ekiplerdir. Güzellik hala önemlidir. Yapının yerine değil, üzerine eklenir.

---

SSS

Tasarım devri nedir?

Tasarım devri, bir tasarımın bir tasarım aracından (genellikle Figma) üretim koduna aktarılması işlemidir. 2026 yılında, devir, geliştiricilerin ve yapay zeka kodlama ajanlarının tasarımı yaklaşık olarak değil, kesin olarak uygulamasına olanak tanıyan dört katmanlı bir Figma dosyası (tokenlar, bileşenler, kalıplar, sayfalar) etrafında yapılandırılmıştır.

Figma'ü geliştiricilere devretmenin en iyi yolu nedir?

Dört katmanlı bir dosya oluşturun. Her görünür değer için tokenlar. Tüm varyantlara sahip bileşenler. Tüm kırılma noktalarına sahip kalıplar. Yalnızca mevcut kalıplardan ve bileşenlerden oluşan sayfalar. Ekip MCP tabanlı kodlama ajanları kullanıyorsa, Code Connect eşlemelerini katmanlayın. Üç aşamalı bir kontrol döngüsü çalıştırın (teslim öncesi denetim, bileşen öncelikli derleme incelemesi, bileşene karşı görsel kalite kontrolü).

Figma Geliştirici Modu nedir?

Figma Geliştirici Modu, bir dosyayı görüntüleyen geliştiricilere tasarım özelliklerini (CSS, iOS, Android), kod parçacıklarını ve Code Connect eşleme panelini sunan ücretli bir katmandır. Yerel kod gönderen veya Figma içinde birinci sınıf geliştirici ergonomisi isteyen ekipler için kullanışlıdır. Değerin çoğu, belirteç disiplini ve bileşen varyantlarıyla eşleştirildiğinde artar.

Tasarım teslimi için Figma MCP'ya ihtiyacım var mı?

Kesin olarak değil, ancak matematiği değiştiriyor. MCP ile kodlama aracıları Figma dosyasını doğrudan okur ve gerçek belirteçlere ve bileşen varyantlarına göre bileşenler oluşturur. MCP olmadan, geliştirici tasarımı gözle kopyalar, bu da daha yavaş ve sapmaya daha yatkındır. Üretim çalışmalarında Claude Code veya Cursor kullanan ekipler, MCP'u entegre ederek büyük bir ivme kazanırlar.

Teslimattan sonra tasarım sapmasını nasıl önlerim?

Üç kural. Kaynakta belirteç disiplini (her görünür değer bir belirtece dönüşür). Bileşen öncelikli derlemeler (geliştirici sayfalardan önce bileşenleri oluşturur, tasarımcı herhangi bir sayfa çalışmasından önce bunları inceler). Dağıtımdan sonra yapılandırılmış görsel kalite kontrolü (dört katmanlı dosyaya göre karşılaştırın, vibes'a göre değil). Sapma bir kişilik sorunu değil, bir süreç sorunudur.

Modern tasarım teslimatı için hangi araçlara ihtiyacım var?

Minimum gereksinim, Değişkenler ve Bileşenler içeren Figma'tır. Bir sonraki adım, Figma Geliştirici Modu ve yazılı React eşlemeler için Code Connect'tir. Gelişmiş adım ise, ekibinizin kullandığı kodlama aracılarına (Claude Code, Cursor, Claude Desktop) entegre edilmiş Figma MCP'tir. Storybook ve görsel fark araçları (Chromatic, Percy), daha büyük ekipler için yığını tamamlar.

Devir teslim, toplantı değil sistemdir

Tasarım devir teslimi eskiden bir an meselesiydi. Bir toplantı, bir Loom, bir Notion doküman, "sorularınız varsa bana bildirin" Slack mesajı. Bu model asla ölçeklenemedi ve şimdi yapılandırılmış girdiye ihtiyaç duyan, insan rehberliğine ihtiyaç duymayan yapay zeka aracıları tarafından yutuluyor.

2026 modeli farklı. Devir teslim dosyadır. Dosya, sistemin kendisidir. Sistem dört katmandan oluşur: Tokenlar, bileşenler, desenler ve sayfalar. Katmanları doğru ayarlarsanız, geliştirici tasarımı olduğu gibi teslim eder, ajan derlenebilir kod üretir ve kalite kontrol süreci kısa sürer. Bunları yanlış ayarlarsanız, bileşen tek başına ne kadar iyi görünürse görünsün, her bir alt katman bozulur.

Bir proje seçin. Dosyayı dört katmana göre denetleyin. En büyük açığı bulun. Önce onu düzeltin. Ardından yeni yapıyla teslimatı tekrar çalıştırın ve uygulamanın ne kadar daha hızlı, temiz ve doğru bir şekilde gerçekleştiğini izleyin.

Tasarım ve geliştirmeyi tek bir işlem olarak yürüten, dosyayı sözleşme olarak kullanan ve teslimatta sapma olmayan bir ekip istiyorsanız, Brainy'ı işe alın'ya bakın. Aynı ekip, aynı sistem, aynı teslim edilen ürün.