Geçen ay, 2026’nın mart sonunda, Maslak’ta bir ajans toplantısında yine aynı sahne yaşandı: müşteri “bir önceki dosyayı baz alalım” dedi, ekipte biri final_final2 klasörünü açtı, diğeri Figma linkini aradı, üçüncüsü de “hangi versiyon onaylıydı ya?” diye sordu (inanın bana). Tanıdık geldi mi? İşte tam o an. İşin aslı şu — tasarım işi, çoğu zaman yaratıcı olmaktan çok dosya kovalamacasına dönüşüyor; ve bu, açıkçası, insan bıktırıyor (bizzat test ettim)
Ken Deng’in anlattığı fikir tam bu noktada anlam kazanıyor. AI destekli bir sürüm takibi kurduğunuzda, revizyonları tek tek elle eşleştirmek yerine sistem sizin yerinize not düşüyor, link üretiyor, değişiklikleri işaretliyor. Müşteriye giden akışı — hiç uyumadan, hiç şikayet etmeden — düzenliyor. Kağıt üstünde sade görünüyor; pratikte ise, valla, bayağı rahatlatıcı bir şey bu.
Durun, bir saniye.
Asıl Dert Tasarım Değil, Dağınık Versiyonlar
Bir tasarımcı için en sinir bozucu şey iyi iş çıkarmak değil. Hayır. O işi kimin hangi yorumla geri gönderdiğini çözmeye çalışmak — işte asıl dert o. Bilhassa freelance çalışanlarda bu daha da belirgin çünkü tek projede bile üç farklı kanaldan gelen feedback var: e-posta, WhatsApp ve bazen de “şuraya bir bakar mısın?” diye atılan, ne demek istediği belirsiz bir ekran görüntüsü.
Bunu 2024’ün kasım ayında Kadıköy’de çalışan küçük bir ürün ekibinde bizzat gördüm. Maalesef. Tasarımcı arkadaşım her yeni revizyonda dosya adını değiştiriyor. Müşteri tarafı eski link üzerinden yorum yapmaya devam ediyordu. Sonuç? Beşinci versiyonun üzerine ikinci versiyon notu düşülmüş, kimse ne olduğunu anlamıyor, herkes birbirine bakıyor. Hani insanın kafası karışır ya — aynen öyle, sadece daha da kötüsü.
Hmm, bunu nasıl anlatsamdı…
Buradaki temel sorun sadece sürüm kontrolünün olmaması değil; sürüm kontrolünün tasarım akışına uymaması. Yazılım dünyasında Git nasıl bir düzen (belki yanılıyorum ama) sağlıyorsa, tasarım tarafında da benzer bir disiplin gerekiyor — ama burada kod yok, renk paletleri var, artboard’lar var, layer isimleri var. E peki, sonuç ne oldu? Her şey biraz daha görsel olduğu için karmaşa da daha çabuk, daha sessizce büyüyor.
Neden “Release Library” fikri işe yarıyor?
Bu yaklaşımın kalbi merkezi bir yayın kütüphanesi kurmak. Yani her şeyi masaüstüne savurmak yerine proje bazlı tek bir kaynak oluşturuyorsunuz: örneğin CLIENT-ACME-RELEASES. Bu klasör ya da kütüphane sizin — itiraz edebilirsiniz tabi — “doğru kabul edilen son nokta”nız oluyor. AI aracı da orayı izliyor; yeni sürüm geldi mi, anlıyor.
Çok konuştum, örnekle göstereyim.
Bana göre buradaki güzellik şu: yaratıcı iş ile operasyonel iş birbirinden ayrılıyor. Siz çizimi yapıyorsunuz; sistem ise isimlendirme, paylaşım linki üretme. Kayıt tutma kısmını hallediyor — bir nevi stajyer gibi ama hiç uyumuyor, hiç “ya ben bilmiyorum” demiyor. Tabii kusursuz değil; ilk kurulumda biraz disiplin istiyor, bu gerçek.
Tasarım Araçlarına Bağlanınca Ne Değişiyor?
Şöyle ki, Figma, Adobe Creative Cloud. Sketch gibi araçlara doğrudan bağlanan AI katmanı işi hızlandırıyor — ama asıl mesele hız değil, güvenilirlik. Mesela Figma’da OAuth ile izin veriyorsunuz; araç takım kütüphanelerinizi izleyebiliyor ama editöre burnunu sokmuyor (en azından benim deneyimim böyle). Bu ayrım önemli. İlginç, değil mi? Çünkü kimse yaratıcı akışının tam ortasında robot müdahalesi istemez, ben de istemezdim.
Yani, Şimdi gelelim pratik tarafa. Diyelim ki ana sayfa artboard’unu onayladınız ve proje kütüphanesine kaydettiniz; sistem bunu otomatik olarak Version beş diye etiketleyebiliyor, paylaşılabilir bağlantıyı çıkarıyor ve müşteri portalını güncelliyor — siz başka sekmede kaybolmadan, iş kapanıyor. Bu kadar.
Açık konuşayım: bu tür otomasyonlar ilk bakışta “küçük ayrıntı” gibi duruyor. Duruyor ama yanıltıcı. Haftalık tempo sıklaşınca, aynı gün içinde beş müşteriye revizyon giden ajanslarda, bu küçük otomasyonlar resmen nefes aldırıyor — abartmıyorum.
| Aşama | Elle Yapılan Akış | AI Destekli Akış |
|---|---|---|
| Sürüm kaydı | Klasör adı değiştirme + not yazma | Kayıt otomatik tutuluyor |
| Müşteri bağlantısı | E-postaya manuel ekleme | Sistem link üretiyor |
| Takip | Ekran görüntüsüyle hatırlama çabası | Sürüm geçmişi tek yerde duruyor |
| Zaman maliyeti | Saatler sürebiliyor | Dakikalar içinde bitiyor |
| Hata riski | Yüksek — insan unutabiliyor | Daha düşük — süreç sabitleniyor |
Küçük ekip için ayrı, enterprise için ayrı anlam taşıyor
Aslında — hayır dur, daha doğrusu, Küçük bir startup’ta bu sistemin faydası basit: kimse gereksiz yere operasyon yükü taşımıyor. Bir iki kişiyle yürüyen ekiplerde herkes hem tasarımcı hem proje yöneticisi gibi çalışıyor zaten, her dakika kıymetli — orada otomasyon doğrudan, elle tutulur biçimde zaman kazandırıyor.
Kurumsal tarafta ise konu başka. Enterprise seviyede asıl değer denetlenebilirlik: hangi versiyon ne zaman çıktı, kim onayladı, müşteriye hangi link gitti? Bu soruların cevabı hazır olunca hem iç iletişim rahatlıyor hem yanlış teslimat ihtimali düşüyor. Ama gel gelelim — kurulum tarafı daha zahmetli olabiliyor; izinler, entegrasyonlar, güvenlik politikaları işi uzatabiliyor (ki bu çoğu kişinin gözünden kaçıyor). Bunu baştan bilmek lazım. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Bunu Kurarken Üç Şey Belinizi Kurtarır
Küçük bir detay: Biri: net isimlendirme. Dosya adıyla kavga etmeyin. Artboard isimlerini düzenli tutun. Çünkü AI sistemi çöp veri görürse çöp sonuç üretir — bu biraz acı gerçek ama doğru, kaçış yok. Bu konuyla ilgili Bilibili İndirmenin Perde Arkası: DASH, M4S ve FFmpeg yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Açık konuşayım, İkincisi: yayın öncesi kısa kontrol listesi. Kullanılmayan layer’ları silmek, gereksiz export’ları temizlemek, yeni component adlarını güncellemek… bunlar ufak işler gibi görünür. Görünür ama sonra büyük rahatlık verir, inanın. Bilibili İndirici Mimarisine Yakından Bakış: Hız, DASH ve FFmpeg yazımızda bu konuya da değinmiştik.
Ne yalan söyleyeyim, Üçüncüsü: save olayını tetikleyici olarak kullanmak. Dur, burada kritik nokta şu: sistemi manuel başlatıyorsunuz ama sonrası otomatik gidiyor. Bu hibrit yapı bana daha mantıklı geliyor — çünkü büyük ölçüde otonom kurulumlarda hata çıktığında insan eliyle düzeltmek zorlaşıyor, deneyimle söylüyorum.
# Örnek akış
1) Tasarım final hale gelir
2) CLIENT-ACME-RELEASES içine kaydedilir
3) AI watcher yeni sürümü algılar
4) Version etiketi eklenir
5) Paylaşım linki oluşturulur
6) Müşteri portalı güncellenir
7) Ekip bildirim alır
Nerede Güzel Çalışır, Nerede Tıkanır?
Neyse, küçük bir detay: Bence en güçlü olduğu yer tekrar eden revizyon işleri. E-ticaret banner setleri, sosyal medya kreatifleri, hızlı kampanya döngüleri — buralarda sistem resmen yağ gibi akıyor, itiraz etmiyorum. Daha fazla bilgi için TikTok’ta Aynı Videoyu Farklı Kılmanın Akıllı Yolları yazımıza bakabilirsiniz.
Şöyle söyleyeyim, Ama özel illüstrasyon veya çok aşamalı sanat yönetimi olan projelerde biraz ham kalabiliyor. Müşterinin geri bildirimi bazen çizginin üstünde olur, bazen alt metinde saklanır; aynı anda hepsini makineye yedirmek kolay değil (evet, doğru duydunuz). Gerçekçi olalım.
Bir de güvenlik meselesi var. Eğer dış servisler kullanıyorsanız erişim izinlerini ince ince ayarlamak gerekiyor — kaba saba açılmış API anahtarları ileride baş ağrıtıyor. Başta hızlı kurulur ama sonra temizlik gerekir (ciddiyim). Kaçınılmaz.
Mesele yalnızca dosya takibini otomatize etmek değil; asıl kazanım tasarımcının zihinsel yükünü azaltmakta yatıyor. Müşteri revizyonu ile operasyon arasındaki köprüyü sağlam kurarsanız iş akışı dağılmıyor. Kaos azalınca kalite konuşmaya başlıyor. Ve evet, bu sandığınızdan daha büyük fark yaratıyor!
Bence En Mantıklı Kullanım Şekli Nasıl?
Ben olsam önce küçük başlarım. Tek proje, tek müşteri, tek Release Library. Sonra süreç oturursa diğer projelere yayarım — aynısını 2025’in ağustosunda İzmir’de danışmanlık verdiğim minik bir ekipte denedik; iki hafta içinde yanlış link gönderme vakaları yarıya indi. Yarıya. Başka bir şey yapmadan.
Bir de şunu söyleyeyim: her şeyi AI’a bırakmayın. Onay zinciri hâlâ insanda kalsın. Makine kayıt tutsun, etiketlesin, hatırlatsın — ama son söz yine ekipte olsun (bu beni çok şaşırttı). Çünkü müşteri ilişkisi dümdüz teknik mesele değil; arada ton var, niyet var, biraz da his var. Bunu makine henüz tam okuyamıyor.
Eğer freelance çalışıyorsanız bu yaklaşım size ekstra profesyonellik de kazandırıyor, bunu da ekleyeyim. Müşteriye “işte son hali” demek yerine, versiyon geçmişi düzgün tutulmuş bir panel göstermek bayağı fena olmayan duruyor. Kusura bakmayın ama insanlar düzen görünce rahatlıyor — bu psikoloji değişmiyor.
- Düzgün klasör yapısı kurun;
- Library/release adlarını standartlaştırın;
- Müşterinin göreceği tek resmi kanal belirleyin;
- Mümkünse bildirimleri sade tutun;
- Zorunlu alanları azaltmayın ama gereksiz form doldurtmayın;
- Erişim izinlerini üç kez kontrol edin.
Sıkça Sorulan Sorular”>
Aynı yöntem freelance işlerde işe yarar mı?
p>Evet, hatta en çok orada işe yarar diyebilirim.
fazla ekip kalabalığı olmayan yapılarda düzen kurmak daha kolay oluyor ve sonuç hemen hissediliyor.”
Tasarım aracına API bağlamak güvenli mi?
p>Eğer OAuth ve doğru yetkilendirme kullanıyorsanız evet,
ama erişimleri minimumda tutmanız şarttır.
yaşanan çoğu sorun fazla izin verilmesinden çıkıyor.”
Müşteri geri bildirimlerini de otomatik eşleştirebilir mi?
p>Belli ölçüde evet.
yorumların tarihini,
bağlantılı sürümü ve ilgili dosyayı ilişkilendirebilir;
ama nüanslı kreatif kararları yine insan okumalı.”
Bunun kurulumu zor mu?
p>Kurmaya başlamak kolay,
düzgün işletmek orta zorlukta.
ilk birkaç projede süreç oturtulunca sonraki işler belirgin şekilde rahatlıyor.”
Kaynaklar ve İleri Okuma”>
\
\
Adobe Developer Portalı (ciddiyim)
\
Sketch Developer Documentation
\
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
