- Yapay zeka araçları tasarım sistemlerini doğrudan kullanarak UI ürettikçe, tasarımcının rolü basit görsel tasarımdan strateji ve koordinasyon odağına kayıyor
- Artık asıl soru “kimin işini kim elinden alıyor” değil, sürecin nasıl değiştiği
- Kod, PRD, özet gibi görünmeyen işler otomasyona daha elverişli; ancak kullanıcıların doğrudan görüp dokunduğu UI ve akış gibi görünen işlerde kalite farkı çok belirgin olduğundan tasarım otomasyonu hâlâ mühendisliğin hızını yakalayamıyor
- Figma maketlerini koda çevirmek en büyük darboğazdı; ancak tasarımcı doğrudan kod ortamında tasarlarsa bu handoff israfı tamamen ortadan kaldırılabilir
- Yapay zeka çağında tasarımcının temel değeri piksel işi değil, orkestrasyon becerisi: neyin yapılacağına karar verme, yapay zeka çıktısını eleştirel biçimde değerlendirme ve işi yönetme yetkinliği
- Küçük, güçlendirilmiş ekiplerle makine tarafından okunabilir tasarım sistemlerine yatırım yapan şirketler, büyük ölçekli özellik fabrikası organizasyonlarını geride bırakacak
Ürün tasarımındaki dönüşümün arka planı
- Yazar, 1999'da Dreamweaver ile ilk web sitesini yaptıktan sonra Photoshop, Sketch, Figma gibi araçlarla tasarlayıp geliştiricilere teslim eden bir çalışma biçimiyle ilerledi
- Son dönemde Claude Code'u şirketin tasarım sistemine bağlayarak yalnızca üç prompt ile gerçekten çalışan bir UI üretti ve önceki görsel tasarım adımını atladı
- Bu deneyim, tasarımcının değerinin uygulama becerisinden “zevk ve stratejik muhakemeye” kaydığını gösterdi
- Yapay zekanın tasarım sistemini temel alarak “prompt → üretim → dağıtım” akışını kurabilmesiyle, ürün tasarımında köklü bir değişim yaşanıyor
Yanlış tartışma: kişi sayısı değil, sürecin değişimi
- Yapay zeka ve ürün rollerine dair mevcut söylem, “tasarımcı işini kaybedecek mi”, “mühendislerin yerini alacak mı” gibi kadro sayısı merkezli alan kavgasına sıkışmış durumda
- Asıl soru süreçle ilgili: yapay zeka bu işlevleri ortadan kaldırmıyor; bunların kim tarafından, ne kadar hızlı yapıldığı ve darboğazın nereye kaydığı belirleyici oluyor
- Kod yazma, PRD hazırlama, veri analizi gibi görünmeyen işler (invisible work), kalite farkı UI'nin arkasında gizlenebildiği için otomasyona daha uygun
- Kod dağınık olsa bile uygulama çalışıyorsa çoğu kişi önemsemiyor; PRD yapay zeka ile oluşturulmuş olsa da problem tanımı doğruysa bu kabul edilebiliyor
- Buna karşılık kullanıcı arayüzü, akış ve deneyim gibi görünen işlerde (visible work) kalite farkı hemen ortaya çıkıyor ve kullanıcı bunu anında fark ediyor
- Üretmek daha hızlı ve ucuz hâle geldikçe, mesele “nasıl yaparız” değil, “yapmaya değer olan nedir” sorusu oluyor
- Yapay zeka destekli tasarımın hız artışı mühendisliğin gerisinde kalmaya mecbur; bu asimetri, tüm ürün geliştirme sürecini ve ekiplerin nasıl kurulduğunu yeniden şekillendirecek
Görünen iş: tasarım duvarın arkası değil, duvarın kendisi
- Mühendislik tesisata benzetilebilir: duvarın arkasında gizlidir; musluktan su akıyorsa iç yapının nasıl olduğu çoğu zaman önemli değildir
- Boris Cherny, aynı anda 4-5 kodlama ajanı çalıştırarak %400'ün üzerinde hız artışı elde etti; Silikon Vadisi'ndeki mühendisler doğrudan kod yazmaktan çok, ajan ekiplerini orkestre etmeye yöneliyor
- Yazılım tasarımı ise hem duvarın kendisi, hem musluk, hem de musluk koludur; dolayısıyla AI üretmiş olsa bile kullanıcılar görünüşe ve kullanım hissine duyarlı tepki verir
- Yapay zeka, eğitim verisindeki standartları ve kalıpları takip edebilir; ancak onlarca kullanıcı görüşmesi, anket sonucu, kullanım analizi, rakip denetimi gibi geniş kapsamlı kullanıcı araştırmasına dayalı kararları işlemekte zorlanır çünkü bağlam çok büyüktür
- Burada bir içeri alma sorunu (ingestion problem) darboğazı var: yapay zeka büyük miktarda kod ya da toplantı özeti üretebilir, ama insanların bunu okuyup içselleştirmesi ve eleştirel değerlendirmesi gerekir ki anlamlı kararlar alınabilsin
- Kod incelemesi fiilî darboğaz hâline gelmiş durumda; bu, insan hızının sınırı olduğu için hiçbir modelin aşamayacağı bir engel
- Yapay zeka içerik üretme ve özetleme konusunda güçlü; ancak gerçekten yeni bir şey yaratma ya da zevk (taste) sahibi olma becerisi henüz kanıtlanmış değil
Figma'da değil, kod içinde tasarlamak
- Ürün geliştirmedeki en büyük darboğaz, Figma maketlerini üretim koduna çevirmekten oluşan tasarımcı-geliştirici handoff süreci
- Yazılımın resmini çizip, pikselleri ince ayarlayıp, bunu mühendise teslim ediyorsunuz; ardından QA, maket ile kodu karşılaştırıyor ve tipografi ya da boşluk uyumsuzlukları yüzünden PR'lar geri çevriliyor — bu da muazzam bir verimsizlik yaratıyor
- Yapay zeka bu darboğazı azaltabiliyor, ama ancak tasarımcı doğrudan kod ortamında tasarladığında
- Bazı tasarımcılar gerçekten Figma aboneliklerini iptal edip yapay zeka araçlarına geçiyor; burada temel argüman, maketlerin ürünün kendisi değil, çeviri, gözden geçirme ve düzeltme gerektiren paralel çıktılar olması
- Figma'da ittirdiğiniz her piksel, mühendisin tamamen başka bir ortamda uyması gereken bir söz hâline geliyor; tasarım aracı üretim kodundan ne kadar uzaksa, handoff sırasında oluşan israf o kadar artıyor
- Claude Code ile tasarım sistemi reposunu gösterip üç prompt üzerinden çalışan bir UI üretme deneyi bunu doğruladı
- Ölçekli güvenilirlik için sağlam dokümantasyon, açık kurallar ve ajan orkestrasyonu gerekiyor; ancak temel altyapı artık hazır
- Monday.com mühendislik ekibinin örneği: Figma bağlantısını Cursor'a yapıştırdıkları ilk denemede ortaya çıkan kod, tasarım sistemi bileşenlerini kullanmadı; renkler hardcode edildi ve tipografi sistem varsayılanlarının üzerine yazıldı
- Çözüm olarak bir tasarım sistemi MCP (Model Context Protocol) kurdular — bileşenleri, token'ları, erişilebilirlik kurallarını ve kullanım kalıplarını makine tarafından okunabilir hâle getirdiler ve 11 düğümlü agentic workflow ile modele yapılandırılmış bağlam sundular
- Yaklaşım, ajanların kodu doğrudan yazması değil; önce kodun nasıl olması gerektiğine dair anlayışı kurup sonra bunu geliştiricinin kodlama ajanına devretmekti: “sihir değil, orkestrasyon”
- Anthropic'teki bir tasarımcı, Claude Code ve konsol ürünü üzerinde doğrudan pull request gönderiyor ve bunu prodüksiyona alıyor — 2026 Şubat itibarıyla bu artık gerçek
İnsana kalan: orkestrasyon ve muhakeme
- Yapay zeka kod üretimi, PRD yazımı, araştırma özeti ve arayüz prototiplemeyi yapabiliyorsa, insana kalan şey orkestrasyon oluyor
- Modeller yeterince yetkin; asıl darboğaz klavyenin başındaki insan — ne isteneceğini, işin nasıl bölüneceğini ve model çıktısının ne zaman reddedileceğini bilmek kilit beceri
- Kyle Zantos, çalışma zamanının %70'ini terminalde geçiren bir tasarımcı; 4 ay önceki tavsiyelerin bile eskidiğini, bu yüzden belirli araç ayarlarından çok felsefe ve yaklaşımın öğrenilmesi gerektiğini vurguluyor
- SAP Chief Design Officer'ı Arin Bhowmick'e göre, görsel olarak cilalı bir arayüz; güvenilmez çıktılar, opak karar alma mekanizmaları ve edge case'lerde kırılgan davranış gibi daha derin sorunları gizleyebilir
- Tasarım liderleri yüzey kalitesi yerine güven, açıklık ve güvenilirliği birinci sınıf tasarım çıktıları olarak ele almalı
- Vlad Derdeicea'ya göre tasarım liderlerinin zamanının yaklaşık %80'i iletişim, hizalama ve gerekçelendirmeye gidiyor; gerçek anlamda uygulamalı tasarım işi yalnızca %20'lik bölümde kalıyor
- Her tasarım kararının bir “gerekçelendirme vergisi” (justification tax) var — başka alanlarda kısa bir konuşmayla geçilecek seçimleri açıklamak, belgelemek ve savunmak için harcanan zaman
- Yapay zeka maket işini değil, bu %80'lik kısmı hedeflemeli: toplantı notlarını birleştirme, paydaş iletişimi taslakları hazırlama, araştırma özetleme ve fikir tartışmalarını veriyle çözmek için hızlı prototipler üretme
- Jan Tegze'nin çerçevesi şu: mevcut işi daha iyi yapmaya çalışma; onun yerine insanların sınırları yüzünden var olan alan kısıtlarını bul ve ajanlarla ortadan kaldır — amaç bugünkü işi hızlandırmak değil, daha önce mümkün olmayanı yapmak
- “Ajanlarla rekabet etmek değil, hem sana hem de ajanlara ihtiyaç duyan yeni bir yetkinlik yaratmak”
- 5 yıldan az deneyime sahip junior tasarımcılar daha büyük risk altında; çünkü yapay zeka çıktısını değerlendirecek muhakeme ve model hatalarını fark edecek deneyim henüz yeterince oluşmamış durumda, yani beceri tabanı yükseliyor
Küçük ekipler, büyük kaldıraç
- Yazılım şirketlerinin çoğu bugün için artık uygun olmayan bir yapıya sahip — özel tasarım desteği olsun ya da olmasın her squad'a PM atayan, PM fazlası özellik fabrikaları
- PM'lerin ZIRP döneminde hızla çoğalmasının nedeni, gelire yakın konumlanmaları ve organizasyon karmaşıklığı arttıkça sayılarının da büyümesi
- Marty Cagan buna “ürün yönetimi tiyatrosu” diyor — roadmap hazırlayıp standup yöneten, aslında fazla maaş alan proje yöneticilerinden pek farkı olmayan etkisiz PM'lerin fazlalığı
- Andrew Ng, Davos'ta yapay zekanın mühendislik verimliliğini patlatmasıyla PM/mühendis oranının 1:8'den 1:1 yönüne dönebileceğini öngördü
- Yapay zeka ajanları üretim kodunun çoğunu yazdığında, geniş mühendislik tabanı küçülecek ve spesifikasyon ile muhakeme kıt kaynak hâline gelecek
- Airbnb, ürün yönetimi ile ürün pazarlamasını tek bir “full-stack” rolünde birleştirdi
- Brian Chesky: “Bir ürün hakkında nasıl konuşacağını bilmiyorsan o ürünü geliştiremezsin” — böylece hikâye anlatımı ve dış iletişim, PM rolünün birinci sınıf unsurları hâline geldi
- Tasarımcıları, mühendislere birlikte ürün liderliği yapan “mimarlar” seviyesine yükseltti; yani ticket alıp işleyen ikincil bir hizmet rolü olmaktan çıkardı
- Mevcut PM kadrolarını şişiren koordinasyon işleri ise ayrı program manager rolüne aktarıldı
- Bu yaklaşım, Apple'ın fonksiyonel organizasyon modeline benziyor: uzmanları uzmanlar yönetiyor, entegrasyon noktası CEO oluyor ve iş birimi işleten “mini CEO” tarzı PM'ler bulunmuyor
- Yapay zeka çağındaki ideal ekip, 2-3 mühendis, 1 PM ve 1 tasarımcıdan oluşan küçük, güçlendirilmiş bir ekip
- Tasarım sistemi çekirdek altyapı hâline geliyor; kod içindeki tasarım sistemi ve dokümantasyon olmadan yapay zeka, UI ve implementasyon konusunda yanlış kararlar veriyor
- Makine tarafından okunabilir tasarım sistemlerine ve küçük, güçlendirilmiş ekiplere yatırım yapan şirketler; 15 kişilik squad'ları ve 3 aşamalı onay süreçlerini sürdüren şirketleri geride bırakacak
Bileşik etki: orkestratörlerle piksel iticiler arasındaki fark
- Claude Code ile tasarım sisteminden çalışan ekranlar üretme denemesi sonrasında, daha iyi dokümantasyon, daha sıkı bileşen kuralları ve daha net birleştirme yönergeleriyle sürekli iyileştirme yapılıyor
- Her turda süreç hızlanıyor ve prodüksiyona daha hazır hâle geliyor; model gelişimi, beceri rafinesi ve yönlendirme yeteneği birlikte bileşik etkiyle birikiyor
- “Yapay zekayı orkestre eden tasarımcı” ile “Figma'da piksel iten tasarımcı” arasındaki farkın 12 ay içinde çok büyük hâle gelmesi bekleniyor
- Bunun nedeni piksel iticilerin yetersiz olması değil; orkestratörlerin temelden farklı bir hız ve kapsamda çalışması — başkaları handoff toplantıları için maket çıkarırken onlar çalışan UI'lar dağıtıyor
- Yazar bu yaklaşımı ekibine öğretiyor; çünkü mesele işlerin yok olması değil, zevk, muhakeme ve işi yönetme becerisinin çizim yapma becerisinden daha önemli olduğu bir mesleğe dönüşmesi
Henüz yorum yok.