Tasarımdan Koda Uçtan Uca Çalışmanın Avantajları

Devir teslim, bir projenin en kırılgan anıdır

Bir tasarım dosyası "hazır" damgasını yiyip geliştirme tarafına geçtiği an, projede en çok değerin buharlaştığı andır. O noktaya kadar alınmış onlarca karar — bir boşluğun neden 24 değil 32 piksel olduğu, ana eylemin neden ikinci ekrandan önce göründüğü, formun neden beş değil iki alan istediği — birinin kafasının içindedir. Karşı tarafa geçen şeyse çoğu zaman yalnızca görüntüdür.

Ben bu devri yıllardır kendi kendime yapıyorum: aynı projede hem tasarımı hem kodu üretiyorum. Bu yazıda "ikisi de aynı kişide olsun" tavsiyesinin arkasındaki gerçek mekanizmayı anlatmak istiyorum. Neyin kaybolduğunu, neyin kazanıldığını ve bu modelin nerede zayıf kaldığını olduğu gibi yazıyorum.

Tasarım dosyası kararı değil, kararın fotoğrafını taşır

Bir ekran tasarımı, alınmış kararların tek bir görüntüye sıkıştırılmış hâlidir. Görüntü devredilebilir; kararların gerekçesi devredilemez. Klasik akışta gerekçe üç yoldan taşınmaya çalışılır: uzun bir teslim dokümanı, bir devir toplantısı ya da mesajlaşma. Üçü de eksik taşır, çünkü bir gerekçe genellikle sorulmadan önce kimsenin aklına gelmez.

Pratikte en sık kaybolan bilgiler şunlar:

• Hiyerarşi niyeti: İki başlık görsel olarak benzerdir ama biri sayfanın vaadi, diğeri destekleyici bilgidir. Kodda ikisi de aynı bileşene dönüşünce sayfa "düz" hissettirir; kimse nedenini söyleyemez.
• Ara durumlar: Boş liste, tek satırlık içerik, çok uzun kurum adı, yavaş bağlantı, hata mesajı, yükleniyor hâli. Tasarımda genelde ideal veri vardır; gerçek üründe asla olmaz.
• Hareketin anlamı: Bir geçişin süresi estetik değil, geri bildirim kararıdır. "Güzel dursun" diye uzatılan animasyon, algılanan hızı doğrudan düşürür.
• Esneme kuralı: Bir kart daraldığında ne kırılır, önce hangi eleman gizlenir, hangi metin kısalır? Tasarımda üç kırılma noktası vardır, tarayıcıda sonsuz genişlik.
• Erişilebilirlik kararları: Odak sırası, klavye ile gezinme, ekran okuyucunun duyacağı etiket. Bunlar görüntüde hiç görünmez, dolayısıyla hiç devredilmez.

Bu bilgiler kaybolduğunda çıkan sonuç genelde şu cümleyle ifade edilir: "Tasarıma benziyor ama olmamış." Sorun yetenek değil, aktarım kaybıdır.

Aynı kişide toplanınca fiilen ne değişir

Geri bildirim döngüsü saatlerden dakikalara iner

Ayrık ekipte "bu başlık bir tık küçülse daha iyi olur mu?" sorusunun bedeli bir mesaj, bir bekleme, bir revizyon ve yeni bir devirdir. Uçtan uca çalışırken aynı soru doğrudan tarayıcıda denenir ve otuz saniyede cevaplanır. Bu, günde onlarca kez tekrarlanan küçük bir kazanç gibi görünür; proje sonunda ise haftalarca fark yaratır.

Daha önemlisi, ucuzlayan deneme sayısı artırır. Denemenin bedeli düştükçe daha çok alternatif denenir, daha iyi olana ulaşma ihtimali artar.

Tasarım kararı, üretilebilirliğiyle birlikte doğar

Kod yazan biri tasarlarken, ekranı zaten bir bileşen ağacı olarak görür. Bu, yaratıcılığı kısıtlamaz; tam tersine hangi cesur fikrin gerçekten uygulanabilir olduğunu erken gösterir. "Bu efekti yaparsak mobilde kaydırma takılır" bilgisi, uygulama aşamasında değil eskiz aşamasında devreye girer.

Aynı şekilde ters yönde de çalışır: kod tarafında bir kısıt çıktığında tasarımı yeniden pazarlık masasına götürmek gerekmez. Kısıtı bilen kişi, tasarım niyetini koruyan alternatifi anında üretir. Karar kalitesi düşmez, sadece yol değişir.

Tek muhatap, tek sorumluluk sınırı

Müşteri açısından en somut fark budur. Bir sorun çıktığında "tasarımdan mı kaynaklanıyor, koddan mı?" tartışması hiç başlamaz. Tek bir kişiye sorulur, tek bir kişi çözer. Toplantı sayısı azalır, brief tekrar tekrar anlatılmaz, sorumluluk dağılmaz.

Bu, projede en çok zamanı yiyen görünmez işi ortadan kaldırır: koordinasyon.

Tasarım sistemi bu modelin omurgasıdır

Uçtan uca çalışmak "her ekranı tek tek elle çizmek" demek değil. Tam tersi: aynı kişi hem tasarladığı hem kodladığı için, tekrar eden kararları bir kez tanımlayıp her yerde kullanmak çok daha doğal hâle gelir.

Renk, tipografi, boşluk ve yarıçap gibi kararları token olarak tek kaynakta tutup bileşenleri bu kaynağa bağladığında, marka kararı değiştiğinde tüm ürün aynı anda değişir. Bunun nasıl kurulduğunu tasarım sisteminden production'a tutarlılık yazısında adım adım anlattım; kavramın kısa tanımı için tasarım sistemi maddesine bakabilirsin.

Buradaki kritik nokta şu: tasarım sistemi, ayrık ekiplerde iki yerde yaşamaya başlar ve zamanla sapar. Tek elde ise sapmanın kaynağı ortadan kalkar, çünkü ikinci bir kopya hiç oluşmaz.

Erişilebilirlik ve hız sonradan eklenmiyor

Ayrık akışta erişilebilirlik ve performans genelde en sona kalır; çünkü ikisi de "tasarımın işi mi, kodun işi mi?" sorusunun cevabı belirsiz olan alanlardır. Sonuç olarak kimse sahiplenmez.

Uçtan uca çalışırken bunlar tasarım anında karar hâline gelir:

• Renk paletini seçerken kontrast oranı zaten kontrol edilir; sonradan "bu gri okunmuyor" düzeltmesi olmaz.
• Odak halkası bileşenin bir parçası olarak tasarlanır, sonradan yamanmaz.
• Hero görselinin boyutu ve formatı, görsel seçilirken belirlenir; yükleme davranışı tasarımın parçasıdır.
• Animasyon süreleri, algılanan hız düşünülerek verilir; hareket azaltma tercihi baştan planlanır.

Bu yaklaşımın ölçülebilir karşılığı için erişilebilirlik ilkelerine ve performans tarafında Next.js'te Core Web Vitals'ı yeşile çekmek yazısına bakabilirsin.

Süreç pratikte nasıl işliyor

Uçtan uca çalışmanın en büyük farkı, aşamaların birbirini beklememesi. Benim izlediğim akış kabaca şöyle:

1. Keşif ve hedef: Sitenin kime, ne için hizmet ettiğini netleştiriyoruz. Bu aşamada tek bir piksel çizilmiyor; hangi eylemin dönüşüm sayıldığını konuşuyoruz.
2. İçerik ve akış iskeleti: Sayfaların hiyerarşisi, mesaj sırası ve URL yapısı çıkıyor. İçerik olmadan tasarım yapmak, ölçü almadan dikiş yapmaktır.
3. Yön ve token'lar: Tipografi ölçeği, renk paleti, boşluk ritmi ve hareket dili belirleniyor. Bunlar hem tasarımın hem kodun kaynağı oluyor.
4. Tarayıcıda tasarım: Kilit ekranlar doğrudan gerçek kodla, gerçek içerikle ve gerçek cihazda kuruluyor. Onay statik bir görselden değil, dokunulabilir bir sayfadan alınıyor.
5. Ölçüm ve devir: Hız, erişilebilirlik ve teknik SEO ölçülüyor; yönetim paneli teslim ediliyor. Sürecin tamamını sürecim sayfasında da özetledim.

Dördüncü adımdaki "tarayıcıda tasarım" kısmı, bu modelin en büyük getirisi. Müşteri, gerçekte ne alacağını hayal etmek zorunda kalmıyor; hover'ıyla, mobil davranışıyla, yükleme hissiyle birlikte görüyor.

Dürüst olalım: bu modelin zayıf tarafları

Her yaklaşımın bedeli var ve bunları saklamanın anlamı yok.

• Kapasite sınırı: Tek kişi aynı anda sınırlı sayıda proje yürütür. Çok paralel akışa ihtiyaç duyan büyük programlar için doğru model değil.
• Kör nokta riski: Kendi tasarımını kendi denetleyen kişi, bir süre sonra hatayı göremez hâle gelebilir. Bunu kırmak için dış göz, kullanıcı testi ve yazılı kontrol listeleri şart. Ben bu yüzden yayın öncesi denetimleri kişisel yorumdan değil, sabit maddelerden yürütüyorum; teknik tarafın listesi kurumsal sitelerde teknik SEO kontrol listesi yazısında.
• Uzmanlık derinliği: Çok özel alanlarda (üç boyutlu görselleştirme, ileri düzey illüstrasyon, karmaşık veri mühendisliği) tek kişi yerine uzman gerekir. Bunu baştan söylemek, sonradan idare etmeye çalışmaktan iyidir.
• Süreklilik: Tek kişiye bağlı bir işte devredilebilirlik önemlidir. Bu yüzden kodun okunabilirliği, dokümantasyon ve yönetim panelinin sadeliği lüks değil, zorunluluktur.

Kimin için doğru, kimin için değil

Uçtan uca model şu durumlarda açık ara kazanıyor: markaya özel bir tasarım gerekiyorsa, sayfa sayısı orta ölçekteyse, hız ve dönüşüm ölçülebilir bir hedefse, ve iş sahibi az sayıda muhatapla hızlı ilerlemek istiyorsa.

Şu durumlarda ise kalabalık bir ekip daha doğru: çok sayıda paralel ürün akışı, çok dilli ve çok ülkeli devasa bir katalog, ya da kendi içinde ayrı uzmanlık isteyen alt sistemler.

Özet

• Devir teslim, tasarım niyetinin en çok kaybolduğu yerdir; kaybolan şey görüntü değil, gerekçedir.
• Aynı kişide toplanan tasarım ve kod, geri bildirim döngüsünü dakikalara indirir ve deneme sayısını artırır.
• Kararlar üretilebilirliğiyle birlikte doğduğu için "yapılamaz" sürprizi ortadan kalkar.
• Tasarım sistemi bu modelin omurgasıdır; ikinci kopya olmadığı için sapma da olmaz.
• Erişilebilirlik ve hız, sonradan eklenen bir düzeltme değil, tasarım anının kararı hâline gelir.
• Model her iş için doğru değil; kapasite ve kör nokta riskleri açıkça yönetilmelidir.

Projende tasarım ile kod arasındaki bu boşluğu daha önce yaşadıysan, muhtemelen ne demek istediğimi biliyorsun. UI/UX tasarım yaklaşımıma göz atabilir ya da mevcut siteni birlikte gözden geçirmek için bana yazabilirsin.