Artık Figma’dan çok Claude ile tasarlıyorum
(blog.janestreet.com)- Tasarım iş akışı, spesifikasyon dokümanları yazmak ve Figma mockup’ları hazırlamak yerine, kafadaki fikri doğrudan çalışan bir prototip özelliğe dönüştürmeye kayıyor
- Geçmişte Copilot, Cursor, Gemini gibi LLM’lere şüpheyle yaklaşıyordu; ancak Jane Street’e katıldıktan sonra yapay zeka desteğinin vazgeçilmez olduğunu fark etti
- Claude, ücretsiz ve sınırsız yinelemeye izin vererek, 50 kez fikir değişse bile şikâyet etmeden Submit butonu, kısayollar, metin düzenlemeleri gibi ayrıntılı iyileştirmeleri mümkün kılıyor
- Tasarımcılar da mühendisler gibi, başkalarının doğrudan deneyip değerlendirebileceği çalışan bir kavram kanıtını (POC) kendileri üretebiliyor
- Tüm çabanın doğrudan gerçek çıktının kendisine odaklanması, ara aşamalardaki yan işleri ortadan kaldıran yeni bir iş birliği modeline yol açıyor
LLM’lere dair şüpheden dönüşüme
- Uzun süre LLM’lere şüpheyle yaklaştı ve her kullandığında sonuçlardan hayal kırıklığı duydu
- Geçen yıl kendi yaptığı oyunu düzenlemek için Copilot ve Cursor denedi, ancak ikisi de çalışan değişiklikler üretemedi
- Önceki iş yerinde Gemini ile ürün brifi taslağı ve wireframe hazırladı, fakat hepsi çöpe gitti
- LLM’leri denediği alanların hepsi zaten iyi olduğu işlerdi ve sonuçlar bunu doğrudan kendisinin yapmasından daha kötüydü
- Geçen yaz Jane Street’e katıldıktan sonra yapay zeka desteğinin vazgeçilmez olduğunu hissetti
- Çünkü OCaml ve Bonsai gibi yeni ve henüz yeterince hakim olmadığı alanlar vardı
- En büyük sürpriz ise, en iyi olduğu alan olan tasarım iş akışının değişmesiydi
Prototip odaklı iş akışı
- Spesifikasyon dokümanı, Figma mockup’ı, teklif yazımı ve geliştiricilerle uygulama incelemesi yerine, amaçlanan işlevi doğrudan yerine getiren bir prototip özelliği bizzat inşa ediyor
-
Gerçek çalışma akışı
- Problemi ve öneriyi yazıyla ifade et
- Editörü aç, build, sunucu ve Claude’u çalıştır; yazdığın açıklamayı prompt olarak kullan
- Önce temel işlevi çalıştırarak uygulanabilirliği kanıtla
- İstediğin kadar yinele
- Değişiklikleri geliştirme ortamına push et ve kullanıcı görüşü topla
- Amaçlanan görünüm ve davranışa sahip bir feature gönder; bu şirkette bu,
pull requestkarşılığı
- Gerçek kod tabanı içindeki prototip, mockup ve dokümanlardan neredeyse her açıdan daha iyi çıktı
JSQL girişi prototipi örneği
- Kısa süre önce JSQL girişine LLM prompting ekleyen bir prototip hazırladı
- JSQL, farklı kullanıcı odaklı araçlarda kullanılan dahili bir SQL lehçesi
- Bu gerçekten çalıştı; birkaç gün boyunca kullandı, test etti ve onunla yaşadı
- Claude, ücretsiz ve sınırsız yinelemeye izin verdiği için, 50’nci kez fikir değiştirip ufak düzeltmeler istemesini de dert etmiyor
- Submit butonunu iyileştirme, klavye kısayolu ekleme, metin düzeltme, prompt ayarı yapma, üretici onay mesajı ekleme
- Önceki iş yerinde bunlar birkaç gün ila birkaç hafta sürecek mühendislik-tasarım gidiş gelişleri gerektirirdi ya da hiç yapılmazdı
- Tüm çaba gerçek çıktıyı iyileştirmeye gidiyor; Figma komponenti üretmek veya doküman biçimlendirmek gibi yan işlere değil
İş akışının oturması
- Bu noktaya gelmesi zaman aldı
- İlk katıldığı dönemde yapay zekayı yalnızca küçük UX kusurlarını düzeltmek gibi sınırlı işlerde kullandı
- Daha büyük fikirlerde hâlâ Figma ve dokümanlara başvuruyor, Claude ile denediğinde ise başarısız oluyordu
- Son iki ayda Figma’ya uzanma ihtiyacı ciddi biçimde azaldı
- Model iyileştirmeleri, kendi becerisinin artması ve uygun kapsam seçiminin birleşimiyle büyük işlerde de yapay zeka işe yarar hale geldi
- JSQL prompt’ları dışında da kullanıcıya dönük, veri modeli ve kütüphane değişikliklerini kapsayan çok sayıda prototip yaptı; bunların bazılarında 2000 satırdan fazla diff vardı
- Bazen Figma’da tasarlayıp ardından etkileşimli prototipi uyguluyor; bazı yeni uygulamalarda ise Figma’yı tamamen atlayıp en baştan Claude ile görsel tasarımı yineleyerek ilerliyor
Tasarımcıya verdiği güç
- Mühendisler akıllarına bir fikir geldiğinde çalışan bir kavram kanıtını kendileri üretebilirken, tasarımcıların başkalarını ikna etmesi gerekir
- “JSQL girdisinin içinde doğrudan LLM prompting” gibi bir fikirde, başlangıç anında bunun uygulanabilir olup olmadığı bile belirsiz olabilir; böyle bir prototipi bir başkasına yaptırmak zaman kaybına dönüşebilir
- Bu öneri, kullanıcı ihtiyacını gerçekten açık biçimde karşılamıyor da olabilir
- Claude ile fikri gerçekten hayata geçirince, başkalarının bunu doğrudan deneyip değerlendirmesi çok daha kolay oluyor
İnceleme biçiminin zorlukları
- Dezavantajı, reviewer’ların karşısına tamamlanmış bir özellik çıkması
- Özelliğe dair katkı hakkı olmadan yalnızca kodu mu gözden geçirecekleri sorusu doğuyor
- Bu, tasarım alanında PM’in verdiği ayrıntılı wireframe’i alıp “sadece güzel görünür hale getir” denmesine benziyor
- Öneriler olabildiğince açık ve eksiksiz olmalı; ama mühendis ekip arkadaşlarının da Figma mockup’larında olduğu gibi tasarım alanında birlikte yineleme yapması isteniyor
-
Mevcut çözüm
- Özelliğe farklı bakmaya karar veriyor ve açıklamaya kısa bir yönlendirme ekliyor
- Prototip, yaşayan bir öneri dokümanı; kod tek kullanımlık; reviewer’ın rolü ise tasarım ve kullanıcı deneyimi hakkında geri bildirim vermek
- Sonunda reviewer fikri devralıp ayrı bir feature içinde uyguluyor; prototipi referans alıyor ama production kodunun sahipliğini doğrudan üstleniyor
- Neyin makul ve iyi hissettirdiği konusu hâlâ keşif aşamasında
Kaygılar ve tanıdık gerilim
- Claude ile tasarlamanın, esnek ve yaratıcı düşünceden uzaklaştırıp Claude’un üretebileceği sanılan çıktılara sıkışmış yinelemeci bir düşünce tarzına hapsedebileceğinden korkuyor
- Değişimin kademeli olduğu olgun araçlarda bu sorun olmayabilir, ancak yeni şeylerde bazı fikirler kaçabilir
- Bu tanıdık bir gerilim ve 2011’deki “tasarımcı kod yazmalı mı” tartışmasına bağlanıyor
- Eleştirmenler, programlamaya başlanınca fikirlerde büyük değişiklik yapmanın zorlaştığını savunuyordu
- Buna rağmen hem web sitesi yapmayı hem de programlamayı sevdiği için kod yazmayı sürdürdü
- React gibi frontend framework’leri yaygınlaştıkça ve geliştirme karmaşıklaştıkça uzmanlaşmayı seçti
- Kişisel projelerini hâlâ React ile yapıyor ve bu, geliştiricilerle iletişimine yardımcı oluyor
- Çalışma zamanının büyük kısmı ise Figma ve dokümanlara gidiyordu
- LLM’lerden önce Jane Street’e katılmış olsaydı, muhtemelen Figma’ya daha da derinden gömülecekti
- JavaScript konusunda bir miktar deneyimi vardı, ancak OCaml ve Bonsai tamamen yeniydi; bu yüzden teknik katkı yapmak erişilmez görünebilirdi
- Bunun yerine yeniden gerçek çıktılar üretmeye dönmek, o araca geri dönmek gibi hissettiriyor ve her şeyi deneme özgürlüğünü daha güçlü hissettiriyor
1 yorum
Hacker News yorumları
İş tarafı zaten çoğu zaman gereksinimleri kendi düşündükleri çözüm biçiminde getiriyor ve bu da genelde bir Rube Goldberg düzeneği gibi bir şey oluyor; gerçek gereksinime ulaşmak için konuşarak tersine mühendislik yapmak gerekiyor
Bundan sonra ise ellerinde zaten “hazır” ve “çalışan” bir çözümle gelecekler ve tasarım ile mimariye bütünsel bakma fikrine daha da kapalı olacaklar gibi görünüyor
Muhtemelen “Bunu işte böyle yaparız, neredeyse bitti zaten; neden X içgörüsüne ihtiyacımız var?” diyecekler
Sorun şu ki iş tarafı neden bu uygulamayı olduğu gibi production’a alamayacaklarını anlamıyor
“AI ile daha hızlı gidebiliriz” baskısı artıyor ve sonunda bunun nasıl sonuçlanacağı sağlıklı organizasyon dinamiklerine bağlı olacak gibi görünüyor
İyi tarafı, fikrin peçeteye karalanmış bir eskize kıyasla çok daha kapsamlı doğrulanmış olması
Claude muhtemelen sınır durumları ve tasarım kararları hakkında zaten sorular sormuştur; bir noktada da açıkça “onu dert etme, öyle varsay” ya da “birkaç kez denedim, bu etkileşim iyi değil, başka türlü yap” denmiştir
Şu anda “ne var bunda, direkt yayına al işte” baskısı güçlü, aptalca ve moral bozucu olduğu için net kayba yakın; ama işler oturursa gelecekteki projeler için net kazanca da dönüşebilir
O ufak düzeltmeler ise tarayıcı tam 1920px genişliğinde değilse düzenin bozulması, filtreleme ve sıralamanın bazen düzgün çalışmaması, bazı işlemlerden sonra yeni değerin uygulamada doğru güncellenmemesi gibi şeyler oluyor
Sorun ne olursa olsun iş tarafı zaten işin %95’ini yaptığını düşünüyor ve “kıdemli bir geliştirici bunu hemen düzeltir” diye en baştan varsayıyor
İnsanlar ellerindeki çıktıya alışıyor ve yeni profesyonel bir miksle gelen değişiklikleri kabullenmeleri daha zor oluyor
Müşteri problemini kullanışlı ürün özelliklerine çevirebilen PM, CSM ve TAM’ler var ama problem tanımını atlayıp başka fonksiyonel ekiplerin çözüm üretmesine yol açıldığında bu genelde mühendislik ve diğer kaynaklarda büyük israfa yol açan bir felaket oluyor
Biri elinde çözümle geldiğinde, aylar boyunca işletilebilir yazılım yaptıktan sonra müşterinin bundan hoşlanmadığını, sorunu çözmediğini ya da yeni sorunlar yarattığını öğrenme riski çok yüksek
Benim çalıştığım yerde değil, eski bir iş yerimde oldu; veri kaybı ve güvenlik sorunları olmasına rağmen aynen production’a alındı
Bildiğim kadarıyla Jane Street, Anthropic’in yatırımcılarından biri; bunu da hesaba katmak lazım
Bir de 2025 Temmuz’unda Hindistan Menkul Kıymetler ve Borsa Kurulu SEBI’nin, Jane Street’in çeşitli tüzel kişilikler kullanarak piyasa manipülasyonu yaptığını iddia edip piyasaya erişimini yasakladığı konusu var
Büyük para havuzlarında bolca dashboard gerekse gerek
Burada tasarımcı yanlış bir yaklaşım izliyor gibi; prototipi olabildiğince derin ve gerçekçi yapma isteğiyle bir tür mühendislik özentisine kapılmış görünüyor
Oysa tasarım işinin en önemli kısmı bu değil
En önemli şey doğru şeyin inşa edilmesi
“Neden bir JSQL giriş kutusu gerekli? Aslında istenen şey ne? Başka hangi yollar var?” gibi sorular çoğu zaman kalem kâğıt eskizleri, toplantılar, gözlem ve tartışmalarla daha iyi çözülür
Bu, çok erken aşamada belirli bir tasarıma daralıp düğme solda mı sağda mı olsun ya da LLM’nin ayrıntılı davranışı ne olsun gibi tartışmalara girmekten daha iyidir
Tabii tam da böyle düşünmenizi istiyor olmaları da mümkün
Bazen bunu görüyorum
LLM şu anda yinelemenin ötesini göremiyor; bu yüzden benim kalıpların dışında düşünüp “buna şu açıdan bakarsak ne olur?” demem gerekiyor ki bir anda yeni bir tasarım yaklaşımı ortaya çıksın
Bazen de LLM’nin kendi ilerlediği adımların ötesini görebilmesi için bir akış şeması hazırlamak gerekiyor
“Claude bana 50. kez fikrimi değiştirsem ya da küçük bir düzeltme istesem bile dert etmeyen, ücretsiz ve sınırsız yineleme verdi” deniyorsa, Claude için ödeme yapılmıyor mu?
Küçük tasarım stüdyolarında da benzer oluyor; geliştiricilerdeki gibi saatlik ücretlendirme her zaman yok
Dürüstçe, tasarım konusunda gerçekten kötü olduğumu ve bir tasarım sisteminden ekstrapolasyon yaparken de zorlandığımı söyledim
Kabul edilebilir görünen bir noktaya ulaşmak benim için aşırı zor ve bu süreçte neredeyse her zaman işi daha kötü hale getiriyorum
Mülakattaki tasarımcı bunu kişisel algılayıp üstüme gelmişti
Daha önce de benzerlerini yaşadım
Tasarımcılar bir şeyin nasıl görünmesi gerektiğine dair bitmek bilmeyen sorulardan hoşlanmıyordu ve dosyayı bir kez devredip işin bitmesini istiyorlardı
Pazarlama ve reklam ajanslarında da, tasarım spesifikasyonunda yer almayan şeylerin nasıl görünmesi gerektiğine dair örnek almak için sürekli kavga etmek zorunda kalmıştım
Haklıydım demiyorum ama bu benim için büyük bir Aşil topuğu
O yüzden “ücretsiz, sınırsız yineleme, dert etmiyor” denince aklıma paradan önce zaman ve sabır geliyor
Prototipleme için kullandığım Bolt bana kızmıyor
En iyi tasarımı üretmiyor olabilir ama benim yapabileceğimden çok daha iyisini yapıyor ve iş bittiğinde gerçek bir tasarımcıya daha iyi hale getirtilebiliyor
O zamana kadar da birini kızdırma endişesi taşımam gerekmiyor
Frontend’de Claude Design kullanıyordum
Ortaya çıkan işin görünümü ve hissi yeterince iyi, ama tasarımlar sık sık birbirine benziyor ve genel olarak modern webin kalıplaşmış desenlerini takip ediyor
Bununla alışılmadık yaratıcı denemeler yapan biri olup olmadığını merak ediyorum
Şu ana kadar yaklaşık 3 hafta harcadım ve hâlâ tamamlanmış değil ama fikir verir
Geçtiğimiz 10 yılda SaaS boilerplate’i olduğu gibi, internetten öğrenilmiş bir LLM boilerplate’i de var
Yine de yeterince emek verirseniz hâlâ her şey mümkün
Gereksinim verirsen ona uyması, yön vermezsen de güvenli seçimler yapması ilginç
Çıktının estetiğini ve kullanıcı deneyimiyle içeriği değerlendirecekseniz ama estetik taraf için neredeyse hiç prompt vermiyorsanız, yalnızca güvenli varsayılanları alırsınız
bootstrap/tailwind kopyası hissi veren tasarımlar yapmada iyi ama o tarafı bilinçli şekilde itmeniz gerekiyor
Basit web sayfalarında ilk iterasyonun tek odağını görsel stil yapmaya başladım
Standart görünmemesi için özellikle talimat verip istediğiniz web sitesi stiline örnekler vermeniz yeterli
Biraz uğraşınca biraz daha yaratıcı hissettiriyor ama prompt çalışması gerekiyor
Bana çok saygı gören ve son derece deneyimli tasarımcılar önerdi; onlar artık neredeyse tamamen Claude’da prototip oluşturuyor, beğenirlerse Figma’da cilalıyorlar
En başta ayrıntılı stil prompt’ları olmadan genel bir UI isterseniz genel bir tasarım çıkması zaten normal
Buradaki avantaj, tasarımcının kod yazmayı öğrenmesi
Tasarımcıların yazılımın nasıl üretildiğini bilmeden yazılıma şekil vermesi bana hep tuhaf gelmiştir
Bu arada ben de tasarımcıyım
Yalnız kodla tasarlamak teknoloji öncelikli bir yaklaşım
Tasarımın amacı çıktıyı insan amaçlarına göre şekillendirmekse, kodun katı kurallarından başlamamak daha iyi de görülebilir
Güzel görünen sonuçlar yüzünden değil, düşünceyi ileri itme konusunda kalem ve kâğıdı geçmek hâlâ zor
Artık fiilen sesle kod yazabilir hâle gelince yeniden vibe coding ve ürün yapımına dönüyorum ve bu harika
Patronum bu yeni durumu hâlâ anlamaya çalışıyor ama eski rol ayrımlarının ölmeye başladığını düşünüyorum
Kesişim noktasında olmak bence şu anda en iyi yer
Sanki bütün hayatım beni bu ana hazırlamış gibi geliyor
Tasarımcı için bu, sonuca bakıp görsel düzenleyici yerine dille değişiklik yapılan bir Figma gibi olurdu
Eşim bir FAANG şirketinde ürün yöneticisi; ekibi, normalde Word ya da Excel gibi araçlarla yapacakları yazılım parçalarını AI ile vibe coding yapmaya aşırı derecede bel bağlıyor
Kod yazmayı öğrenmiyorlar ve koda bir saniye bile bakmıyorlar
“Prototip yaşayan bir teklif belgesidir, kod atılabilir, reviewer’ın görevi de mimari ve kullanıcı deneyimi hakkında geri bildirim vermektir.
Sonuçta reviewer fikri devralır ve ayrı bir özellik olarak uygular; prototipi referans alır ama üretim kodunun sahipliğini kendisi üstlenir” yaklaşımı, tüm POC’lerde yaşadığım sorunu çözüyor
Gerçekten çok iyi bir yöntem
Belirli bir ürünün belirli bir sorununu ele alırken buna “teklif belgesi” demek kolaydır
Ama hâlâ çok sayıda tasarımcı Figma’yı ürün ve platform genelindeki tasarım sistemlerini tanımlamak ve sürdürmek için kullanıyor; bu durumda hakikatin kaynağı Figma’dır
Bizim ekip de bunu yapıyor ve ben bir frontend mühendisiyim; dürüst olmak gerekirse eski yöntemi gerçekten özlüyorum
Yazılı spesifikasyonların yerini çalışan prototipler aldığından, artık kodu okuyup amaçlanan değişikliğin ne olduğunu ve atılması gereken gürültünün ne olduğunu ayırt etmek gibi ek bir bilişsel yük var
Oluşturulmuş bir PR’ı devralıp gerekli değişiklikleri mi yapacağıma yoksa baştan mı yazacağıma karar vermem gerekiyor; her iki durumda da sürtünme var
Bir keresinde tonla istenmeyen değişiklik üretilmişti; ben de yeniden uygulamak için zaman harcayıp taşıdıktan sonra sonradan “Aa, özür dilerim, onu değiştirmek istememiştik” denmişti
Yetki vermesini anlıyorum ama eskiden işimde hissettiğim keyfin bir kısmını alıp onu bir baş ağrısına çevirdi
Tasarım ve ürün tarafı Claude ile özellik ya da deneyimi vibe tasarlayıp kodluyor, hızla prototip çıkarıyor ve minimum mühendislik süresiyle müşterinin önüne koyup geri bildirim alıyor
Harika
Ama genel olarak daha hızlı yayın yapmaya pek yardım etmemiş olması şaşırtıcı olabilir
Bence nedeni süreçte düşünmenin kaybolması
Azımsanmayacak miktarda düşünme artık dil modeline outsource edildi
Prompt’lardaki boşlukları kapatıyor, belirtilmemiş davranışları halüsinasyonla dolduruyor
Eskiden “Bu tam oturmuyor”, “Bu fikri nasıl aktaracağım?”, “Bu durumda ne olacak?” deyip duraksayacağımız anlar kayboldu; şimdi o ayrıntılar düzgünce yapılmış gibi göründükten sonraya erteleniyor
Elbette süreci iyileştirip bu yeni tekniği daha iyi kullanmayı yeniden değerlendirebiliriz ama eskisinden daha iyi mi, emin değilim
Geriliyor
Artık backend’ciler de frontend yapıyor
Bu bir yanılsama
Derleyicinin ürettiği assembly’ye bakıyor musunuz? Hayır
O hâlde neden bu koda bakıyorsunuz?
Biz soyutlama katmanını yukarı taşıdık
Ben de aynı yaklaşımı sık kullanıyorum
Yapay zekadan önce de bunu manuel olarak yapıyordum
Önce kullanıcıyla birlikte sadece kalem ve kâğıtla oturuyor, ardından hızlıca bir frontend POC ya da demo hazırlıyor, kullanıcının bunu kurcalamasını sağlıyor ve istedikleri gibi çalışana kadar ayarlıyordum
Benim için, üretim kalitesinde olmayan hızlı bir frontend demosunu kodla yapmak, Figma'da doğru etkileşimleri oluşturmaktan çoğu zaman zaten daha hızlıydı
Tam etkileşim mümkün olduğu için kullanıcı deneyimi tarafındaki uç durumları çok daha fazla yakalayabiliyordum
Artık Claude Code sayesinde çöpe atılacak prototipler yapma hızı arttı, ama fark çok büyük değil
Kullanıcıyla tartışmak ve nasıl çalışması gerektiğini düşünmek toplam sürenin %80'ini aldığı için, Claude doğrudan hızlıca kendim yapmama kıyasla kalan %20'yi yaklaşık yarıya indiriyor
İlk sürüm daha hızlı, ama tamamen anlamadığım durumlarda yineleme daha yavaş
Edwin, yazını burada görmek güzel
2012/2013 civarında birlikte hackathon yaptığımızı hatırlıyorum
Çalışan bir prototipe daha hızlı ulaşabilme yeteneği çok güç veriyor; bu, yarım kalmış fikirleri olduğu gibi yayına alma cazibesi yaratsa bile
Tasarım ve kullanıcı deneyimi gereksinimleri, storyboard ve wireframe'in ötesine geçip gerçek akışı dokunarak ve deneyimleyerek görülebildiğinde büyük fayda sağlıyor