- AI ürün tasarımında 8 yılı aşkın deneyime sahip Barron Webster, Figma’da dünyanın ilk 'model tasarımcısı' rolünü yürütüyor; bu da tasarımcıların LLM’lerle doğrudan çalıştığı yeni bir hibrit mesleğin ortaya çıktığını gösteriyor
- Model tasarımcısının temel görevi, foundation model’lerin sınırlarını telafi etmek ve AI özellikleri tasarlamak için yeni araçlar ile düşünme biçimlerini tasarım organizasyonuna taşımak
- Geleneksel UI tasarımından farklı olarak AI ürün tasarımında önce model davranışının prototiplenmesi, ardından UI’ın tasarlanması gerekiyor; aksi halde gerçek çalışma biçimiyle uyuşmayan bir UI üretme riski var
- Değerlendirme (Evals) sistemi kurmak, AI ürünlerinde kalite yönetiminin merkezinde yer alıyor; tasarımcıların hızlı geri bildirim döngüleriyle değerlendirme vakalarını düzenleyip çalıştırabileceği araçlara ihtiyaç var
- AI çağında tasarımcıların, modelin girdi-çıktı yapısını derinlemesine anlaması ve sistemin tamamını kavrama becerisine sahip olması şart; artık sadece UI üreten kişiler değil, karar alma sürecinin katılımcıları olmaları gerekiyor
Barron Webster’a giriş
- 8 yılı aşkın süredir AI ürünlerinin içinde derin biçimde yer alan bir tasarımcı ve hype döngülerini görebilen bir içgörüye sahip
- Google Creative Lab’de 2017’de çıkan Teachable Machine tasarımında yer aldı; bu, tüketicilerin bir AI modelini eğitebildiği ilk araçtı
- Sonrasında Replit’te AI özellikleri üzerinde çalıştı ve şirketin startup’tan unicorn’a dönüşümüne katkıda bulundu
- Yakın zamanda Figma’ya dünyanın ilk model tasarımcısı olarak katıldı
Model tasarımcısının rolü
- Figma AI araştırma ekibinde yer alıyor ve iki ana görev üstleniyor
- Foundation model’den alınabilecek en yüksek performansın bile yetmediği durumları çözmek
- Figma’nın verisi özel bir formatta olduğu için foundation model’lerin bunu iyi işleyemediği noktada aradaki boşluğu kapatmak
- Tasarım organizasyonuna yeni araçlar ve AI öncelikli bir düşünme biçimi getirmek
- Figma büyük bir şirket olduğu için birçok tasarımcının AI deneyimi tasarlama tecrübesi yok
- AI özelliği tasarlamak, geleneksel ürün tasarımından farklı
- Amaç, tasarımcıların mühendise dönüşmeden sürecin erken aşamasında AI özelliğinin özünü prototiplemesini sağlayacak araçlar kurmak
- Bizzat deneyimlenmemiş bir özelliğin UI’ını tasarlamak, yalnızca kusursuz senaryolara uyan ama gerçekte nasıl çalıştığıyla örtüşmeyen bir UI üretme riski taşıyor
AI tasarım araçlarının geleceği
- En çok heyecan duyduğu araç, tasarımcıların hızlı geri bildirim döngüleriyle değerlendirme vakalarını düzenleyip çalıştırabildiği bir araç
- Figma dosyasında bir AI özelliği düzgün çalışmıyorsa, bunun anında bir test vakasına eklenebilmesi gerekiyor
- Sistem prompt’unu ayarlamak ya da farklı bir model denemek gibi işlemler hemen yapılabilmeli
- Bugünkü sorun, geri bildirim döngüsünün fazla yavaş olması
- Tüm iyi tasarım araçlarının özü, geri bildirim döngüsünü kaldırmak ya da küçültmektir
- Değerlendirme seti kurma işinin büyük kısmı, veriyi temizlemeye yönelik el emeğinden oluşuyor
- Figma’da AI özelliklerini nasıl farklılaştırabileceklerini de düşünüyor
- Bir tasarım platformu olduğu için Claude Code ya da Cursor’dan daha iyi tasarlanmış çıktılar bekleniyor
- Belirleyici unsur, hedefli değerlendirme stratejileri ve iyi tasarım için bir proxy bulmak
- Bu aynı zamanda sanat okulu seviyesinde felsefi bir soru
Barron’un AI ile ilk tanışması
- 2014-2015 RISD Computer Utopias dersi: LLM öncesi dönem; makine öğrenimi araştırmalarının sınıflandırıcı merkezli olduğu zamanlar
- En ilginç alan görüntü sınıflandırma modelleriydi; Snapchat yüz filtrelerini ve Google görsel aramayı bunlar çalıştırıyordu
- İçerik moderasyonu ve öneri sistemleri temel gündem maddeleriydi
- Facebook, Twitter ve Cambridge Analytica döneminin zirvesiydi; algoritmik akışın icadı, tasarlanacak yeni bir malzeme yarattı
- 2016-2018 Google Creative Lab: Google Lens, Google Assistant ve Teachable Machine üzerinde çalıştı
- Neredeyse tüm projeler model yeniliklerinin uygulanmasına dayanıyordu
- Modeller, metin üretmekten çok mevcut içeriği sıralamak ya da açıklama eklemek için kullanılıyordu
- TensorFlow ile salatalıkları sınıflandıran Japon bir salatalık çiftçisinin örneğini tanıtan çalışmalar yaptı
Replit deneyimi
- 3 yılı aşkın süre çalıştı; hiç AI özelliği olmayan bir noktadan başlayıp AI’ın nasıl kullanılabileceğini değerlendirme görevini üstlendi
- Modeller sürekli geliştikçe, yeni yeteneklerden yararlanırken güvenilir kalan AI özellikleri eklemenin yollarını aradı
- Başlangıç noktası, temel manuel tetiklenen özelliklerdi: kod seçip AI’dan açıklama isteme ya da mevcut dosyaya kod üretme
- Her özellik yayınlandıktan sonra kullanıcı beklentilerinin yükseldiği bir döngü tekrarlandı
- Kod parçacığı üretimi açıldı → kullanıcılar tüm dosyayı/projeyi istemeye başladı
- Tüm üretim mümkün oldu → belirli düzenleme istekleri geldi
- Belirli düzenlemeler mümkün oldu → bu kez en baştan sıfırdan başlama talebi oluştu
- Tipik örüntü şuydu: mevcut modelle özelliği dene → olmazsa bekle → yeni bir foundation model çıkınca tekrar dene
- Programlama ortamının ürün kısıtları da vardı
- Model kod yazmakta iyi olsa bile, doğru yerde nasıl düzenleme yapacağını bilmesi gerekiyor
- Sonnet 3.5 öncesine kadar modeller satır numaralarıyla çalışmakta zayıftı
- Düzenleme doğruluğu, içerik tekrarını önleme ve fonksiyon değiştirme için geçici çözümler geliştirmek gerekti
- Bu çalışmaların çoğu, 6 ay ila 1 yıl sonra gelen yeni modellerle anlamsız hale geldi
Kullanıcı doğrulamasına geçiş örneği
- Replit ajanı otomatik olarak dosya oluşturup kod yazdığında, ajanın oluşturduğu uygulamayı test etmek büyük bir teknik sorundu
- Örneğin giriş sayfasının gerçekten çalışıp çalışmadığını doğrulamak
- Mühendislik yaklaşımı: sandbox çalıştırmak, ekran görüntüsü alma özelliği kurmak ve ekran görüntülerini multimodal modele vererek nereye tıklanacağına ya da ne yazılacağına karar vermek
- Özünde, modele benzer bir bilgisayar kullanımı inşa etmek
- Barron ve başka bir mühendisin önerisi: web sitesini kullanıcıya gösterip testi doğrudan kullanıcıdan istemek
- Doğrulama ve test işini kullanıcıya devrederek tüm karmaşık teknik sorunu baypas etmek
- Teknik probleme değil de kullanıcı problemine odaklanan biri olduğunda, birçok adımı atlamak ya da basitleştirmek mümkün oluyor
Product-market fit keşfi
- AI öncesi geleneksel ürün stratejisinde; plan yapılır, mevcut kullanıcı tabanı dikkate alınır, pazar ve kategori genişleme stratejisi belirlenirdi
- AI’daki hızlı değişim nedeniyle Replit’in stratejisi çok daha reaktif hale geldi
- Eğitim pazarında güçlü bir product-market fit yakalamıştı; özellikle COVID sonrası uzaktan eğitim döneminde
- AI özellikleri geliştikçe bir ikilem ortaya çıktı
- Bağımsız geliştiriciler ve hacker’lar AI’ı seviyordu
- Öğretmenler ise öğrencilerin temel öğrenmeyi atlayabilmesi nedeniyle buna karşı çıkıyordu
- Replit ajanı çıktığında hedef kullanıcının kim olduğu net değildi
- Yukarıdan aşağıya planlanan projeler yerine, özelliği çıkarıp tepkileri gözlemlemek daha başarılı oldu
- Yayın sonrası konuşmalarla kullanıcı keşfi yapıldı: teknoloji şirketlerinde operasyon ekipleri; satış verisi toplama ya da dashboard kurma ihtiyacı olan, Zapier veya Retool kullanıcılarına benzeyen kişiler
Değerlendirme (Evals) sistemi
- Replit’in ilk iki yılında çok fazla değerlendirme yapılmadı; o dönemde bu pratik yaygın değildi
- Ajan tarafında değerlendirmeler daha aktif kullanılmaya başlandı; çoğunlukla ürün geliştirme metriği olarak
- Yeni model çıktığında, uygulama testi yapılıp yapılmayacağına programlama değerlendirme performansına bakılarak karar veriliyordu
- Sandbar’da ise modelin karakterine dair değerlendirmeler yazmaya çok zaman ayrıldı
- Sektör genelindeki geniş benchmark’ların ötesinde, ürüne özgü değerlendirmeler oluşturmak yeni bir tasarım işi haline geldi
- İş akışı şöyleydi: prompt yaz → prompt’u ayarla → değerlendirme oluştur → performansa bak → manuel test ve öznel geri bildirimle birleştir
- Değerlendirme olmadan, AI’ın düzgün çalıştığını doğrulamak için gereken el emeği büyük ölçüde artıyor
- Sandbar değerlendirme örnekleri
- Cevabı bilmiyorsa halüsinasyon üretmek yerine tek ve net bir açıklayıcı soru sormalı
- Aynı anda ikiden fazla soru sormamalı
- Yanıtları kısa tutmalı, ancak istisnalar olabilir
Değerlendirmenin zorlukları
- Yalakalık (Sycophancy), değerlendirme yazımındaki en zor konulardan biri
- Modelin gerektiğinde kullanıcıya karşı çıkması gerektiği fikri
- Kabul edilebilir hata oranını belirlemek, bir ürün ve tasarım kararı haline geliyor; yani ürünün tasarım felsefesinin parçası oluyor
- Düşük değerlendirme sonuçlarının nedeni çoğu zaman performans düşüşü değil, kötü yazılmış değerlendirmeler oluyor
- Örneğin “çok kısa olmalı” değerlendirmesinde kullanıcı “Annem öldü” derse, “Buna üzüldüm” yüksek puan alabilir ama bu aslında istenen yanıt değildir
- Değerlendirmeler çoğunlukla regresyon önleme amacıyla kullanılıyor
- Programlamadaki test coverage’a benzer
- Geleneksel programlamadaki test odaklı geliştirme (TDD) yaklaşımının AI mühendisliğinde hâlâ nadir olduğu belirtiliyor
- Önce değerlendirmeyi yazıp sonra onu geçecek kodu üretmek
- Gelecekte değerlendirme tasarımcısı diye bir rol ortaya çıkabilir
- Takımın AI performansını anlayabilmesi için dashboard tasarlayan bir design system rolüne benzer şekilde
Figma’da AI özelliği kurgulamak
- “Hizmet olarak tasarım eleştirisi” fikri değerlendiriliyor
- AI’dan bir tasarım eleştirisi istenmesi
- Bu, sistemin karakteri hakkında ilginç sorular doğuruyor
- Seçilebilir tutumlar sunmak (ör. “Dieter Rams” tarzı) ile varsayılan bir tavır belirlemek arasında seçim yapılması gerekebilir
- Erişilebilirlik ya da kontrast gibi daha nesnel geri bildirimlere odaklanmak ile daha geniş kapsama yönelmek arasında bir denge var
- Bunun gerçek ürün deneyimine ne kadar yansıyacağı henüz net değil
Değerlendirme araçlarının gelişim yönü
- Değerlendirme üretimi iterasyon süresini kısaltan araçlar isteniyor
- Bugün değerlendirme yapan herkesin temelde yapmak zorunda olduğu işler var
- Mapping, format, pipeline ve çıktıyı tek yerde görebileceği bir arayüzü birbirine bağlamak
- Metin için araçlar oldukça iyi ama diğer formatlar için yetersiz
- Design Arena benzeri değerlendirme platformları mevcut
- İnsanların en iyi çıktıya oy verdiği kör, yan yana karşılaştırmalı testler
- Benzer işlerin doğrudan Figma dosyası içinde yapılabilmesi isteniyor
- Yorum eklemek, sorun işaretlemek dahil
- Hızla test seti oluşturup tek seferde çalıştırabilmek, 100 yanıt alıp 30 saniye içinde yeniden yineleyebilmek gerekiyor
- Bugün tüm parçalar teoride çalışıyor ama toplam süre çok uzun
Model üretiminde tasarımcının rolü
- Sıfırdan eğitim ve fine-tuning olmak üzere iki farklı yaklaşımı deneyimledi
- Sıfırdan eğitimde, kullanıcı ihtiyacının en büyük ve acının en yoğun olduğu yeri organizasyona anlatmak, tasarımcının en büyük katkısı
- Replit’te Python’daki yaygın ve basit kod hataları için özel bir model eğitildi
- Kendisi, gerçek eğitim sürecinden çok problemi tanımlama ve eğitilmiş modelin ürüne nasıl uygulanacağını anlama kısmında rol aldı
- Fine-tuning’de ise; ortada mevcut model, ürün ve değerlendirmeler varken performansı artırmak amaçlanıyor
- Prompt yazan, değerlendirme hazırlayan ve kullanıcılarla konuşan kişi, beklentilerin karşılanıp karşılanmadığını en net görebiliyor
- Prompt engineering sınırına gelindiğinde bir sonraki adım fine-tuning oluyor
- Tasarımcının temel çeviri rolü, kullanıcı varsayımlarını akılda tutmak
- Modelle çok yakın çalışan mühendisler ve tasarımcılar, kullanıcıların ayrıntıları bilmediğini unutabiliyor
- “İçindeki aptal”ı kullanarak, AI modelinin özelliklerini bilmeyen saf bir kullanıcının ne deneyeceğini ve nerede takılacağını anlatmak gerekiyor
AI ürün tasarımcılarına öneriler
- En sürdürülebilir ve etkili yatırım, modelin girdilerini ve çıktıları gerçekten anlamaya ciddi zaman ayırmak
- Prompt nedir, hangi kullanıcı bilgileri girdiye girer, hangi araçlar çağrılabilir, hangi değerlendirmeler vardır
- Bu düğmeler oynatıldığında ne olacağını sezgisel olarak kavramak gerekir
- Derinlemesine anlamadığı bir çıktının sadece UI üreticisi olunmamalı
- “Model bunu veriyor, sen de arayüzü tasarla” denirse yapılabilir; ama kullanıcı içgörüsüne dayalı geliştirme önerileri sunulamaz
- Böyle olursa sonraki model değişikliklerine aşırı reaktif çalışmak kaçınılmaz olur
- Yeni bir özelliğin gerçekten istenip istenmediğine dair karar sürecinin parçası olunmalı; sadece teslim alan taraf değil
- Koda alışık olmayan tasarımcılar için bu zor olabilir
- Langsmith benzeri bir arayüz kullanmak ya da geliştirme ortamını doğrudan çalıştırmayı öğrenmek gerekebilir
En büyük etki yaratan örnekler
- Replit ajanı: üretilen uygulamanın çalışıp çalışmadığını kullanıcıya doğrudan doğrulatma fikrine ekibi ikna etti
- Kullanıcı doğrulamasına giden en basit yola odaklanarak büyük emek tasarrufu sağlandı
- LaMDA çıkışı (Google’ın erken dönem LLM’i): farklı model denemelerine çok zaman ayırıp hangisinin en iyi çalıştığını buldu
- O dönemde buna “prompting” denmiyordu ama modele başka bir şeymiş gibi davranmasını güvenilir şekilde yaptırmaya çalışıyordu
- Pluto ya da uydularıyla konuşulabilen demo, sayısız deneme sonunda en iyi çalışan yaklaşımın bulunmasının sonucuydu
- Geniş ölçekli deneyler olmadan stratejik seçim yapmak mümkün değildi
Tasarımcıların prompting yapması
- “Tasarımcı prompt yazmalı mı?” sorusu, “tasarımcı kod yazmalı mı?” sorusundan karakter olarak farklı
- Kod yazma konusunda cevap daha kolay sınanabilir: ABC teknolojisiyle XYZ yapılabiliyor mu? Bunu mühendise sormak, doğrudan bilmeye oldukça yakın bir sonuç verebilir
- AI model davranışı ise doğası gereği daha öznel ve daha nüanslı
- Bu malzemeyi derin bir seviyede bizzat anlamanın yerini hiçbir şey tutmuyor
Bu hâlâ tasarım mı?
- Bu, davranış tasarlamak anlamına geliyor; hiçbir zaman kusursuz olmayabilir ve bunun sorun olmaması gerekir
- Her pikselin tamamen kontrol edildiği ve kusursuzluğun ödüllendirildiği UI tasarımından farklı bir zihniyet gerektiriyor
- Yine de mockup hazırlanıyor, tasarım araçları kullanılıyor
- Figma’da değerlendirme vakaları oluşturuluyor, çıktılar inceleniyor ve tuhaf yerler düzeltiliyor
- Bu iş neredeyse terapötik; fidget spinner gibi
- Elinize bir web sitesi mockup’ı ve 30 dakika verildiğinde tipografiyle oynayarak mutlu olabiliyorsunuz
- Özellik kaldırılmadığı sürece bu iş asla tamamlanmayan bir çalışma türü; her zaman iyileştirilebilecek bir şey var
Henüz yorum yok.